8-Mar-87 16:56:26-PST,16915;000000000000 Mail-From: NEUMANN created at 8-Mar-87 16:55:05 Date: Sun 8 Mar 87 16:55:05-PST From: RISKS FORUM (Peter G. Neumann -- Coordinator) Subject: RISKS DIGEST 4.59 Sender: NEUMANN@CSL.SRI.COM To: RISKS-LIST@CSL.SRI.COM RISKS-LIST: RISKS-FORUM Digest Sunday, 8 March 1987 Volume 4 : Issue 59 FORUM ON RISKS TO THE PUBLIC IN COMPUTER SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator Contents: Safe software (Geraint Jones) Computer Problem causes airline financial loss (Rob Horn) Re: Altitude Encoders... expensive for some (Ronald J Wanttaja) Influence of goal selection on safety (Henry Spencer) Re: Puget Sound Ferry Boats (Dennis Anderson, Robert Frankston, Bjorn Freeman-Benson) GOES satellites, Scotchbrite, Gnomic Maxims, and Mr. Bill (Martin Harriman) Spreadsheet budget helping legislators (Scot E. Wilcoxon) 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. MAXj: Summary Contents Vol 1: RISKS-1.46; Vol 2: RISKS-2.57; Vol 3: RISKS-3.92.) WARNING: NET TABLES ARE CHANGING ON 1 APRIL. FULL ADDRESSES ARE REQUIRED. THIS IS NO APRIL FOOLS PRANK. THE RISKS LIST HAS BEEN RUN THROUGH THE ADDRESS-UPGRADE PROGRAM. IF YOU STOP RECEIVING RISKS, PLEASE LET US KNOW. ---------------------------------------------------------------------- Date: Sat, 7 Mar 87 00:41:38 GMT From: Geraint Jones To: Risks Forum <@Cs.Ucl.AC.UK,@sevax.prg.oxford.ac.uk:RISKS@csl.sri.com> Subject: Safe software IN RISKS 4:56, Hal Guthery makes the laudable plea that we component makers should take into account that some applications programmer will eventually want to make a `safe' system out of our components. He does not expect a painter to be responsible for the structural integrity of the bridge; he wants to be able to take that for granted. At risk of straining his metaphor, I would not expect the painter to complain at the architect's specifying rust-retarding paint for a steel bridge standing in salt water. He suggests that modern parallel architectures (transputer systems) and languages (Ada, occam) are unsuitable, presumably less suitable than others, for building safe systems: the assumption being that ``deterministic'' is a part of ``safe''. The fault with this argument is that often one does not require entirely deterministic behaviour from a system, and that constraining a design to be deterministic in every detail may make it harder to understand. The harder it is to understand something, the less likely one is to build it correctly. Sadly, the real world out there beyond the interface chips is not particularly predictable in its behaviour, and does not take too kindly to being told to wait, and to do things just so and not in some other order. While the ``world'' is a part of one's system, one must be able to reason about non-deterministic systems. Would you really rather use a sequential programming language, and not be able to write some parts of the system (device drivers, interrupt routines, the Lord preserve us even operating system kernels) in the most natural and lucid notation? If one is writing real-time programs, and there really is more than one thing going on at once, then it turns out to be very much easier to tell how long it will take to run a piece of code on the right multi-processor machine than when multiprogramming a uni-processor. At risk of sounding like an INMOS salesman (usual disclaimers apply, not a penny do I get from them, more's the pity) they _do_ sell tools for measuring execution times, and in terms of the programmer's source code, not in terms of the execution times of instructions. Leave the instructions to the machine, it knows more about them than you do or ever wanted to. There _are_ hooks in languages like occam to make it possible to reason about the real-time performance of a program. (I would refer you in passing to a discussion in ``Programming in occam'', G.Jones, Prentice-Hall 1987, but you might think I had an ulterior motive :-) The answer to questions like ``why can't I install my own scheduler?'' has surely to be that this is not a question that an applications programmer should know how to ask! In particular, if one is writing real-time programs, then the correctness of one's code had better not depend on how it is scheduled. If we really want to build reduced risk systems, we should use those (intellectual and mechanical) tools which make it easiest to convince ourselves and others that we are making the right system. I counter the slur (that parallel means slippery) with the observation that you should not necessarily complain if your toolmaker offers you a nutcracker when you asked for a sledgehammer. There may be more moving parts in the nutcracker, it may require more dexterity to use, but the humble tool fitter thinks he has learnt something about eating nuts, and he may well not be entirely wrong. gj ------------------------------ Date: Fri, 6 Mar 87 11:30:31 est From: wanginst!infinet!rhorn@harvard.harvard.edu (Rob Horn) To: risks@sri-csl.arpa Subject: Computer Problem causes airline financial loss From Wall Street Journal report of Florida Express CEO's statement: ``... computers in our own reservations office accurately displayed the availability of discount seats throughout our system, but the computers used by travel agents, who sell 65% of our tickets, erroneously indicated no availability of the cheaper fares on many of our flights.'' This apparently caused a significant drop in sales that may cause the airline to lose money this quarter. They indicate that the problem seems to have been solved but give no indication of what the nature of the computer problem was. Rob Horn UUCP: ...{decvax, seismo!harvard}!wanginst!infinet!rhorn Snail: Infinet, 40 High St., North Andover, MA ------------------------------ Date: Thu, 5 Mar 87 09:52:32 pst From: ames!uw-beaver!ssc-vax!wanttaja@cad.Berkeley.EDU (Ronald J Wanttaja) To: uw-beaver!CSL.SRI.COM!RISKS Subject: Re: Altitude Encoders... expensive for some > From: jbrown@jplpub1.uucp (Jordan Brown) > Subject: Re: Altitude encoders: $1500 for Mode C? No, $750. I hate seeing notices like this, because of the fear that, a month from now, I'll hear Ted Koppel say "... The devices will cost aircraft owners $750..." I suspect that the aircraft already had a transponder installed, and added an altitude encoder to it. And I'm all-fired certain that it had an electrical system. For those not familiar with General Aviation, many aircraft do not have batteries or alternators. Ignition spark is provided by magnetos. The folks advocating mandatory altitude encoding transponders seem to forget that fact. These aircraft are not that rare... at the airport where I kept my Cessna, I estimate that 5% did not have electrical systems. This airport is ten miles from Sea-Tac International. Let's see... $750 for the basic transponder, $750 for the altitude encoder, $2000 for an electrical system, 25 hours labor at $40/hr... $4500 upgrade cost for an airplane worth $6000. Sure, and let's require everyone to install airbags in their older cars, too. Relying on technology to solve a particular problem is nice, as long as you don't ignore real world conditions. Let the aviation community solve the problem, using its own expertise. There are too many self-appointed aviation safety experts out there, like Ann Landers, whose only qualification is that they fly on airliners a lot. Ron Wanttaja (ssc-vax!wanttaja) ------------------------------ Date: Fri, 6 Mar 87 20:51:46 pst From: pyramid!utzoo!henry@hplabs.HP.COM To: pyramid!hplabs!CSL.SRI.COM!RISKS@hplabs.HP.COM Subject: Influence of goal selection on safety I've been reading the NTSB report on the Delta Tristar crash -- the one prominently featured in "Why Planes Crash" -- as it's been serialized in Aviation Week, and recently noticed something that hasn't received much attention that I'm aware of. After the Challenger disaster, it became clear that NASA was compromising safety because the goal of getting the flight rate up was inconsistent with taking all necessary time to ensure safety. The NTSB report pointed out something similar in the matter of airliners vs. windshear. Stripped of the aviation technospeak, one part of the report says essentially: "We are disturbed that most existing windshear-procedures training tells pilots that the ultimate goal is to continue the landing. We feel that once control is regained, the proper action is to abandon the landing and climb immediately to a safe altitude." It seems to me that there is a significant general principle here: if safety is not part of the primary objectives, there will be a strong tendency to treat safety problems as temporary aberrations, rather than as indications of fundamental danger that may require abandoning the primary objectives. Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry ------------------------------ Date: Wed, 4 Mar 87 15:18:19 pst From: ames!uw-beaver!ssc-vax!dma@cad.Berkeley.EDU (Dennis Anderson) Subject: Re: Puget Sound Ferry Boats To: nike!CSL.SRI.COM!RISKS Here is a little more background about the ferry control problems. This may not be suitable for publication in mod.risks, but the USA Today article seems to have missed some important issues. The problem is as much political as technical. A big part of the problem is that the State of Washington doesn't have schematics or software documentation for the control system. Under terms of the contract, those items are proprietary information and remain the property of the subcontractor that designed them. That subcontractor also went bankrupt and was bought out by Marine Power & Equipment. As I understand it, it would be impossible to fix the computer systems without the design info. Another failure mode: When loading and unloading, the ferry is held in its slip by running the engines at idle. The prop pitch control systems would occasionally shift into reverse pitch, causing the vessel to move away from the dock. One car went into the sound in one such incident. Others have nearly done so. I have ridden several of the Issaquah class ferries, and survived. Dennis Anderson @ Boeing Aerospace ...uw-beaver!ssc-vax!dma ------------------------------ Date: Sat, 7 Mar 87 01:50 EST From: Frankston@MIT-MULTICS.ARPA Subject: Re: Puget Sound Ferry Boats To: bnfb@BEAVER.CS.WASHINGTON.EDU (Bjorn Freeman-Benson) cc: RISKS@CSL.SRI.COM How does one go about purchasing a computer control system for a ferry boat? I keep looking for general significance in these failures and keep coming back to the social inertia inherent in adopting or adapting to a new technology. There is simply not yet an infrastructure that can fully manage computerization. In general, I believe that in critical areas such as optimizing the behavior of wheels in a car or landing an airplane, the computer has a large advantage. The issue is not one of whether these system will and should be used. It is a question of when we will have enough understanding to apply these systems effectively with the proper engineering principles to deal with failure modes, intuitiveness of interface etc. ------------------------------ Date: Sat, 7 Mar 87 02:01 EST From: Frankston@MIT-MULTICS.ARPA Subject: Re: Puget Sound Ferry Boats To: bnfb@BEAVER.CS.WASHINGTON.EDU (Bjorn Freeman-Benson) cc: RISKS@CSL.SRI.COM In reading through the rest of the letters this week, I should amend my previous letter by noting that we don't really do a good job of engineering noncomputer systems. Bridges used to fall down 40% of the time until we learned to build them. I was told (but have not verified) that when building the Hancock building in Boston, the people spraying concrete (or whatever) over the riveted beams would often get ahead of the riveters and would not wait. The building is still standing, though did go through a period of plywood windows. ------------------------------ Date: Fri, 6 Mar 87 14:53 PDT From: Martin Harriman <"SRUCAD::MARTIN%sc.intel.com"@RELAY.CS.NET> To: neumann@CSL.SRI.COM [ReSent-To: risks@CSL.SRI.COM] Subject: GOES satellites, Scotchbrite, Gnomic Maxims, and Mr. Bill My vague memory is that the GOES satellites started failing prematurely because of an unauthorized change to a component; specifically, that a subcontractor changed the type of light bulb used in an optical encoder on a gyroscope. Someone with more spare time than I have could find this in Aviation Week and Space Technology. Another major incident of this type was when, once upon a time, some helicopters started falling out of the sky (I believe they were large Sikorsky helicopters--my memory is getting vaguer by the second). This was somewhat upsetting (especially for those killed as a result)--the cause turned out to be an unauthorized (untested) change in a manufacturing step. The races for the main rotor bearing were supposed to be deburred with a wire brush; the bearing manufacturer switched to Scotchbrite pad, since it was easier to use, and seemed to produce the same results. The bearings started failing prematurely, and a number of unfortunate people (mostly in the North Sea oil fields) discovered how poorly helicopters fly when the main rotor bearing disintegrates. Most of the contributors to RISKS seem much more frightened of software risks than mechanical risks (the steer-by-wire discussion is a case in point). Perhaps it's worth keeping in mind that mechanical systems have their problems, too: it's especially worth remembering if you are planning to use a mechanical system as the failsafe for some piece of software wizardry ("Oh, no, Mr. Bill: the emergency handwheel just came off in your hand! Watch out for the train... "). --Martin Harriman martin%ucscb.ucsc.edu@ucbvax.berkeley.edu [Deburred in the hand is worth 3 Bills in debrush. PGN] ------------------------------ To: risks%csl.sri.com%ncar.csnet@RELAY.CS.NET Subject: Spreadsheet budget helping legislators Date: 4 Mar 87 11:00:29 CST (Wed) From: sewilco%meccts.mecc.com%ncar.csnet@RELAY.CS.NET The Minnesota Legislature is now using a spreadsheet as an educational tool. Legislators can put their favorite proposals in the budget, but then have to find a way to pay for them. The budget proposals made by Governor Rudy Perpich were used as a starting point. Dick Pfutzenreuter, staff director of the House Ways and Means Committee, took those proposals and added relationships and comments for many issues. When using the program a legislator may change budget amounts for any item, but then has to balance the budget or raise taxes. Items are labeled to remind users of the meaning of each number. Pfutzenreuter says that about half of the House DFLers (non-USA readers: the DFL is a political organization) have used the program. The legislators have tended to spend more for their pet projects while avoiding cuts in education programs. He also says that each has tried many budget alterations, since it is so easy to do them on the spreadsheet. The Governor's staff has requested a copy of the program. Technical notes: Pfutzenreuter got the Governor's proposals in Lotus format. He is using "The Smart Spreadsheet" by Innovative Software, which is able to read Lotus disks. Not all legislators have their own computers yet, but many legislators simply used the program in Pfutzenreuter's office. Scot E. Wilcoxon (guest account) {ihnp4,amdahl,dayton}!meccts!sewilco (612)825-2607 sewilco@MECC.COM ihnp4!meccts!sewilco [It will be interesting when someone breaks in and modifies the costing or even the wording of a bill, unbeknownst to the legislator... PGN] ------------------------------ End of RISKS-FORUM Digest ************************ -------