6-Aug-86 20:08:39-PDT,10264;000000000000 Mail-From: NEUMANN created at 6-Aug-86 20:06:21 Date: Wed 6 Aug 86 20:06:21-PDT From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS-3.32 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest, Wednesday, 6 August 1986 Volume 3 : Issue 32 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: DC-10 Crash (Chuck Weinstock) Earthquake Reporting (AP) The Recent Near-Disaster for the Shuttle Columbia (Peter G. Neumann) Traffic lights in Austin (Alan Wexelblat) Re: Laserprinter dangers (Graeme Hirst) The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, nonrepetitious. Diversity is welcome. (Contributions to RISKS@CSL.SRI.COM, Requests to RISKS-Request@CSL.SRI.COM) (Back issues Vol i Issue j available in CSL.SRI.COM:RISKS-i.j. Summary Contents in MAXj for each i; Vol 1: RISKS-1.46; Vol 2: RISKS-2.57.) ---------------------------------------------------------------------- Date: 6 Aug 1986 09:19-EDT From: Chuck.Weinstock@sei.cmu.edu To: RISKS@CSL.SRI.COM Subject: DC-10 Crash I have also heard the stories about pilots following the procedures in the manual not being able to save the aircraft. In the case of the American Airlines DC-10 accident, the pilot executed the correct maneuver for loss of engine power, but the effects of the missing engine caused it to go into a stall. However, the correction for the stall is 180 degrees different from the correction for the loss of engine power, and thus the plane was lost. The pilot possibly could have saved the aircraft had he known what was going on. The reason the pilot didn't correct for the stall is that he didn't know about it (or knew too late) -- because the missing engine supplied power to the stall warning device. Interestingly, at the time stories were circulating that some airlines (e.g., United) had ordered their DC-10's with dual-redundant stall-warning devices, powered off of multiple engines. (I'm afraid I don't have a reference. Probably Aviation Week and Space Technology.) Chuck ------------------------------ Date: Wed 6 Aug 86 11:55:55-PDT From: Peter G. Neumann Subject: Earthquake Reporting To: RISKS@CSL.SRI.COM From the AP, Tuesday, 5 August 1986, Los Angeles: Three of five earthquakes that state agencies said rattled California on Sunday never happened, officials acknowledged yesterday. The false reports by California's Office of Emergency Services and Department of Water Resources were blamed on static in the microwave system that transmits data from monitoring devices around the state to Sacramento. Don Irwin, deputy director of Emergency Services, said his agency was trying to decide whether to change procedures and stop publicizing what he termed ``preliminary, unofficial information''. U.S. Geological Survey seismologists said yesterday that three small quakes shook the state on Sunday, two near San Jose and a third in the eastern Sierra Nevada. No damage or injuries were reported. The state agencies never reported one of the San Jose-area quakes, and reported three others that did not happen. ------------------------------ Date: Wed 6 Aug 86 13:22:33-PDT From: Peter G. Neumann Subject: The Recent Near-Disaster for the Shuttle Columbia To: RISKS@CSL.SRI.COM From the San Francisco Chronicle, Wednesday, 6 August 1986: WASHINGTON - The space shuttle Columbia (the launch preceding the Challenger disaster) came within 31 seconds of being launched without enough fuel to reach its planned orbit on January 6 after weary Kennedy Space Center workers mistakenly drained 18,000 gallons of liquid oxygen from the craft, according to documents released yesterday by the White House panel that probed the shuttle program. Although [NASA] said at the time that computer problems were responsible for the scrubbed launch, Representative Bill Nelson, D-Fla., who flew on the mission, said yesterday that he was informed of the fuel loss while aboard the spacecraft that day... According to the appendix [to the panel report], Columbia's brush with disaster ... occurred when Lockheed Space Operations Co. workers "inadvertently" drained super-cold oxygen from the shuttle's external tank 5 minutes before the scheduled launch. The workers misread computer evidence of a failed valve and allowed a fuel line to remain open. The leak was detected when the cold oxygen caused a temperature gauge to drop below approved levels, but not until 31 seconds before the launch was the liftoff scrubbed. NASA said then that the liftoff was scrubbed [until January 12] because computer problems delayed the closing of a valve. Space agency spokeswoman Shirley Green said yesterday that the fuel loss did not become apparent until much later. The NY Times (same day) noted that the potentially catastrophic launch of the Columbia without adequate fuel to reach its intended orbit could be blamed on human error caused by fatigue. "Investigators also concluded that many key people working for NASA and its contractors work an excessive amount of overtime that has the potential for causing catastrophic errors in judgment." The Chronicle article goes on to state, quoting the panel report, that fatigue may also have contributed "significantly" to the disputed decision by NASA and Thiokol officials to launch the Challenger in cold weather -- despite strong evidence that the O-ring booster seals were ineffective. The panel said "certain key managers obtained only minimal sleep the night before the teleconference" in which the fatal decision was made. Furthermore, a study of 2900 workers' timecards in the weeks before that showed an "unusally high amount of overtime", during which time there were five aborted launches and two actual launches. I am astounded to look back over my list of computer-related disasters (an update will appear in RISKS at the beginning of Volume 4 -- it is now up to 5 pages) and find only one other space/missile/defense/aviation case that could easily have been linked to fatigue. That case was the KAL 007, whose real cause is still a matter of much speculation. (See ACM Software Engineering Notes 9 1 and 10 3.) One would expect that to be a more common cause... ------------------------------ Date: Wed, 6 Aug 86 14:01:12 CDT From: Alan Wexelblat To: risks@csl.sri.com Subject: Traffic lights in Austin Yesterday, Austin experienced a sudden thunderstorm and some small power failures. One of the things knocked out by the power loss was the central computer that coordinates the traffic lights in the downtown area. The central controller is backed up by isolated controllers at each intersection. By my guesstimate, there are about 125 of these intersections. Two of the site controllers failed to operate, causing the light at those two intersections to go out. Is this a success or a failure for the system as a whole? Of course we'd like it if the backup was 100%, but is 2% an acceptable failure rate? (Side note: the only adverse effect of the two failures was that humans -- policemen - were required to stand in the downpour and direct traffic.) Alan Wexelblat UUCP: {ihnp4, seismo, harvard, gatech, pyramid}!ut-sally!im4u!milano!wex [Success -- like failure -- is relative. Even the greatest successes can be disasters if we become overconfident. Even the worst disasters can have some benefits if we learn from them. In this case, the result was clearly a qualified success, but would have been quite different if someone had been killed when the lights went out at one intersection. PGN] ------------------------------ Date: Tue, 5 Aug 86 15:27:52 edt From: Graeme Hirst To: risks@CSL.SRI.COM Subject: Re: Laserprinter dangers > Increasingly, large and "official" organisations [...] are using laser > printers to print the bills and other requests for money [...] I cannot believe this will be a serious problem. In fact, most organizations are still using pre-printed stock, even if they use the laser printer to do smarter things on it. For example, my Ontario motor vehicle registration is laser-printed on banknote-style paper. My credit card bills and bank statements are laser-printed on pre-printed paper that is virtually identical in design to the paper used when they were impact-printed. (This also has programming advantages.) Similarly, a new ATM at my bank prints its receipts on a role of paper like that of a cash register, instead of the pre-printed cards used by older models. But the paper used has the bank's logo printed on the back to prevent easy forgery. The one exception I can think of is my city tax and water bills, which have (on plain colored paper) the most ornate laser-printing imaginable -- which required some amazing hacking on the Xerox 9700. Duplicating this would be of the same level of complexity as forging pre-printed stock -- which was always possible even in the days of hand-writing and typewriters. \\\\ Graeme Hirst University of Toronto Computer Science Department //// utcsri!utai!gh / gh@ai.toronto.edu / 416-978-8747 ------------------------------ End of RISKS-FORUM Digest ************************ -------