Text File

Subject: RISKS DIGEST 10.55 REPLY-TO: risks@csl.sri.com

RISKS-LIST: RISKS-FORUM Digest Tuesday 23 October 1990 Volume 10 : Issue 55

FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Contents: Malfunction on Gambling Machine delivers $300,000 Jackpot (John Colville) Risks of Modernization (Chuck Weinstock) Airliner story (Ellen Cherniavsky) Summary of A320 report on W5 (Wayne Hayes) Boeing 777 to use fly by wire (Robert R. Henry) Re: Technology Meets Dog; Dog Wins (Dan Sandin) Stick-up At Banks (Paul Johnson) Re: Kasparov's sealed move (Peter Rice) Computerized cars and ham radio interference (Rich Wales) Programmer error, not language flaw (Stuart Friedberg)

The RISKS Forum is moderated. Contributions should be relevant, sound, in good taste, objective, coherent, concise, and nonrepetitious. Diversity is welcome. CONTRIBUTIONS to RISKS@CSL.SRI.COM, with relevant, substantive "Subject:" line. Otheres ignored. REQUESTS to RISKS-Request@CSL.SRI.COM. FTP VOL i ISSUE j: ftp CRVAX.sri.com<CR>login anonymous<CR>AnyNonNullPW<CR> CD RISKS:<CR>GET RISKS-i.j<CR>; j is TWO digits. Vol summaries in risks-i.00 (j=0); "dir risks-*.*<CR>" gives directory; bye logs out. ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY. Relevant contributions may appear in the RISKS section of regular issues of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.

----------------------------------------------------------------------

Date: Fri, 19 Oct 90 14:33:47 +1000 From: colville@otc.otca.oz.au Subject: Malfunction on Gambling Machine delivers $300,000 Jackpot

Abstracted, without permission, by J. Colville from Sydney Morning Herald: Friday, 19 October 1990, p1:

"Sorry, Tom, your $300,00 jackpot win is void" by Greg Roberts

BRISBANE: Every day for the past 11 weeks, Tom McCullough has been a familiar face at Jupiter's Casino on the Gold Coast. [.... He] inserts a $1 coin into a keno machine every 10 seconds.

Mr. McCullough thought his lucky break had come on Wednesday. He won $10,000 when the right numbers came up. He played again and won another $10,000. On the third consecutive play, he won a $320,000 jackpot.

The reaction from security officials was swift. They shut down all 42 keno machines, hung out-of-order signs from them, and blocked the area off with bar stools.

Mr. McCullough was told he was not entitled to keep the winnings because the machine had malfunctioned.

"The management checked it over the first time, agreed with it, and invited me to keep playing," Mr. McCullough said. "When I won the second $10,000 they urged me to keep going for the jackpot. They din't say anything about a malfunction at the time - they told me four hours later.

"I was highly elated when I won the jackpot because that's what you're always aiming at. They said the odds of what I'd done were four billion to one."

Mr. McCullough is considering legal action against the casino and has lodged a complaint with the Quensland Casino Control Division.

"I was very frustrated and disgusted," he said. "They should have some arrangement where the machines automatically shut down during malfunction. Everything's skewed in the casinos' favour."

The casino's vice-president, Mr. Bud Celey, said that although he sympathised with Mr. McCullough, he was not entitled to the winnings. A plate on the machines advises players that malfunction voids play.

"There is no doubt it was caused by a computer malfunction," Mr. Celey said. "I feel for Mr. McCullough. You can't blame him for being upset, but I had to be adamant. There is nothing in it for us in doing what we did - it was a no-win situation." [....]

John Colville

Currently at colville@otc.otca.oz.au UUCP: {uunet,mcvax}!otc.otca.oz.au!colville On leave from: University of Technology, Sydney colville@ultima.cs.uts.oz.au UUCP: {uunet,mcvax}!ultima.cs.uts.oz.au!colville

------------------------------

Date: Fri, 19 Oct 90 13:21:25 EDT From: Chuck Weinstock <weinstoc@SEI.CMU.EDU> Subject: Risks of Modernization

There is a fascinating article in the 10/22/90 issue of the New Yorker about a train wreck and pipeline explosion that took place in San Bernadino, California a year ago May. The two events were separated by 13 days, and between them they managed to take out an entire neighborhood.

The train involved was heading from Mojave to Colton, Southern Pacific's main yard for the Los Angeles area. The route takes it through Cajon pass and down an extremely steep grade towards San Bernadino. Apparently the train was heavier than anyone expected, and of the 6 locomotives assigned to it, only two had fully functional dynamic brakes . (A dynamic brake slows a train by turning the traction motors into generators, slowing a train much like you would slow an automobile by keeping it in a low gear and letting the engine do some of the work of braking.)

The crew thought that four of the units had functional dynamic brakes, and that would have been able to do the job. The combination of fewer units with functioning dynamics, and a much heavier train than was expected is the ultimate cause of the accident. The reason why the train was so unexpectedly heavy is the point of this submission.

The train was carrying 69 cars of trona (used in detergents I believe), a very heavy mineral that is transported in hopper cars. The cars have a capacity of 100 tons and each car weighs in at 30 tons making a train weight of nearly 9000 tons for a fully loaded train. The company that loaded the trona, in fact, did fully load the cars, but never communicated the fact to the Southern Pacific. In the old days, this would not have been a problem as the railroad had scales everywhere. This is because the railroad gets paid for the weight it hauls for some shipments. Old style weighing involves stopping each car on the scale. Modern weighing is done on more sophisticated (and expensive) scales that allow the train to be weighed while moving. Since the equipment for this is more expensive, scales now are located at strategic locations such as Colton (but not Mojave).

Unfortunately, Colton was at the bottom of the hill, not at the top. So the railroad was forced to estimate the weight of the cars, and did so, finally coming up with a weight of 6100 tons, or just 67% of the actual weight. The result was a disaster. Once the train started down the Hill, there was no way to stop it. To quote the engineer: "We had figured with the dynamics we had and the tons per operative brake and everything, that we could do 30 down the hill, that's what we had calculated, 30 miles per hour was what we were allowed." As the train started down the hill the speed was about 25 which was just about right, but it soon started creeping up. The engineer went to full dynamics (but remember that only two of the units had fully functioning dynamic brakes), with little effect. The speed kept climbing until it was doing over 100 miles per hour. When it reached San Bernadino there was a curve that was rated at 45 miles per hour and the train simply left the tracks, scattering cars among houses like a kid playing derailment with a model railroad.

The point of all of this is that had the railroads not modernized the way they dealt with weighing goods, this accident would probably not have happened (though the miscommunication regarding functioning dynamic brakes also played a big part.) Sometimes the old ways are the best ways.

Chuck Weinstock

------------------------------

Date: Fri, 19 Oct 90 15:17:14 EDT From: ellen@swift.mitre.org (Ellen Cherniavsky) Subject: Airliner story

Reasons for being concerned about the lack of a working transponder are: an aircraft with invalid altitude data is not eligible for processing by the conflict alert function, and in order to enter a Terminal Control Area an aircraft must be equipped with a 4096 code transponder (so without a transponder the pilot could not fly into Newark, Kennedy, La Guardia, Atlanta, Dallas/Fort Worth, etc.). Agreed this is not an immediate major safety problem, but there are good reasons not to proceed without a transponder.

------------------------------

Date: Sun, 21 Oct 90 21:17:44 EDT From: Wayne Hayes <wayne@csri.toronto.edu> Subject: Summary of A320 report on W5

W5 had a 30 minute report highlighting Air Canada's recent purchase and delivery of the A320 Airbus. I took some quick notes, so here is a point form summary of the broadcast. (Some of these points have already been made here.)

o about the first crash of the A320 at the airshow: - from the pilot of the A320 that crashed at the airshow: . the altimeter was wrong, it said 100 feet when actually it was only 30 . the pilot claims he was pulling back on the stick and increasing the throttle, but the computers kept the throttle and elevator constant, holding the plane in a perfect straight-and-level, low speed cruise. (this can clearly be seen in the incredible film of the plane flying gracefully into the forest on the shallow hillside) . the trace from the black box he shows confirms this: the stick is coming back, but the elevator in fact is going *down* (I really didn't understand the trace, since the plane flew straight and level into the trees; perhaps the elevator line was supposed to be a "delta" added to the stick position by the computer, to arrive at what elevator position it thought should be "correct") . "the computer has no eyes; it couldn't see the forest coming up, and so it assumed I wanted straight and level flight" . the black box was carried away in a police car without being sealed, which it is supposed to be by law . most critical last 4 seconds is missing from the trace. He says there has been obvious tampering with the results.

- from Airbus Industrie: . the altimeter problem was documented . pilot error - he was flying too low, to slow, and thus the crash is not surprising . out-of-hand dismissal of tampering accusations

o About the Indian A320 airbus crash: - A320 lands in golf course, well short of runway, 91 (93?) dead - Airbus Industrie says pilot error again . "The A320 will land wherever the pilot tells it to. If I give you a sharp knife and you cut yourself, is it my fault?" . says we should compare A320 to other new airplanes . W5 shows statistics on Boeing's new 767 (now I'm not sure about the following numbers): 600 planes, 6 years, no crashes; A320: 1 year, 100 planes, 2 major crashes, one minor, many danngerous incidents - Indian pilot union president says there are frequent failures in the navigation systems, giving pilots incorrect position readouts - incidents from other Indian pilots: . bird strike (which is common and usually not dangerous) causes screens to blank and cut one engine on final approach . steering completely locks after landing -- plane is luckily going straight at the time . total of 36 incidents reported in 5 months

o from Air Canada reports: - A320 is at 33,000 feet, pilots give command to decend by 4,000 feet, it suddenly decides it's on the ground (altimeter reads zero) and cuts both engines to idle . Airbus Industries waffles and says "it's normal to cut engines to idle when decending" (which of course doesn't explain why the altimeter was reading zero) - A320 upon landing experiences locking of left undercarriage brakes - Air Canada officials claim "we are simply unaware of any of the problems [mentioned by the interviewer and covered in the program]" (we can make our own decision of management competence and informedness if this is true), and claim the A320 is "working perfectly, no problems" - Air Canada pilot goes to A320 conference and has "very heated discussions" with A320 supporters - A/C will change flight path without warning - pilots are frequently confused by readouts

o reports from pilots of Air France (some unofficial because Air France's official position is like Air Canada's -- everything is peachy) - term used in report for incidents has become "unplanned excursions" - things like changing the cabin temperature causes an engine to be cut - 12 times the number of expected problems on the A320 - 7 April 1990, after landing, computer throws nose back into the air for take-off posture, but engines stay in landing mode - "brusque" right turn on runway after landing - all screens suddenly go blank for a few seconds on final approach - causes are hypothesized: . lack of training for pilots? . pilots too trusting of the computers?

o from FAA reports in the US: - main fight system failures annoyingly common - A320 goes into steep dive on final approach, but recovers - at the same time Airbus Industrie is telling the world the A320 is perfectly safe, Northwest airlines is sending urgent report to it's A320 pilots of possible main flight guidance system problems that may not be easily recognized, so you don't even know something's wrong.

o generally: - difficult to trace accidents in the software - "management problems", sometimes problems are kept quiet - the A320 is supposed to get better fuel economy due to lower weight of electronic wires over conventional controls, yet Air Canada often has problems making it from Montreal to Vancouver on a full load with a headwind without stopping in Calgary (other similarly sized planes make it no problem) . in fact A320 pilots routinely file for Calgary in anticipation of stopping there for fuel, even though Vancouver is final destination . sometimes leaves with empty seats or dumped cargo to lessen weight on this trip - "consensus" (I can't remember who said this) of pilots is that the A320 isn't living up to expectations - other pilots love the craft . "it's a great to fly, just don't make a mistake -- it's very unforgiving"

Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525

------------------------------

Date: Mon, 22 Oct 90 12:54:49 PDT From: rrh@tera.com (Robert R. Henry) Subject: Boeing 777 to use fly by wire

>From the October 22, 1990 Seattle Times, page B1 (without permission):

...by the time the first 777 takes to the air for a test flight in 1994, the company should be intimately familiar with the plane's breakthrough fly-by-wire control system. That's because the 777's controls -- in which computer signals replace pulleys and cables for the first time in a Boeing bird -- will be fully tested on a 757 test aircraft.

"We will validate to ourselves, and to our customers, that the system works really well. It'll be ready when the 777 goes into service," said John Roundhill, chief engineer of new airplane development.

------------------------------

Date: Mon, 22 Oct 90 05:05:39 GMT From: sandin@uicbert.eecs.uic.edu (Dan Sandin) Subject: Re: Technology Meets Dog; Dog Wins

>push-button telephone. The Robbs had attempted to teach the dog to dial 911 by >smearing peanut butter on the corresponding buttons of the keypad. >W-H-Y were the Robb's attempting to teach their dog that trick?

It would seem obvious to me that it would be a sort of useful thing if for example, a refrigerator fell on you.

Sounds like they saw too many old reruns of "Lassie"

stephan meyers c/o sandin@uicbert.eecs.uic.edu

------------------------------

Date: 22 Oct 1990 15:32:51-BST From: paj <paj@gec-mrc.co.uk> Subject: Stick-up At Banks

Summarised from the Manchester Evening Star:

A Manchester teenager named Paul James Cooper used Blue-Tak (sic) to block cash dispensers. When the genuine customers went to complain, he walked over to get the money. Exact details were not revealed to avoid copy-cat crimes, but I bet I can guess how to go about it. He got 490 pounds in 26 offences (3 specimen charges plus 23 taken into account). The report mentions another man being caught but does not describe his role in the crimes.

Banks in Stockport, Hyde, Ashton and Macclesfield were all hit. Cooper was caught after a police operation to keep town centre machines under observation. He was ordered to carry out 60 hours of community service.

Paul Johnson UUCP: <world>!mcvax!ukc!gec-mrc!paj +44 245 73331 GEC-Marconi Research is not responsible for my opinions.

------------------------------

Date: Mon, 22 Oct 90 18:35 +0100 From: Peter Rice <Peter.Rice@EMBL.BITNET> Subject: Re: Kasparov's sealed move (RISKS-10.51)

> Computer blunders, revealing Kasparov's sealed move

Sorry, but I don't believe this story. The sealed move is written down on the scoresheet, which is then put into an envelope and sealed. The board probably does record and transmit every move (that technology has been in use since Kasparov met Karpov in London 1986). The catch is that the sealed move is never made on the board until the next day.

However, there was a security breach on the sealed move in the previous match between these two (game 4 of the Seville match in 1987). Kasparov's sealed move was picked up on a video close-up and transmitted to monitors around the venue. Fortunately his position was completely won, and Karpov resigned without resuming.

Another possible computer-related risk is that all leading grandmasters now use databases of recent games and analysis to check up on their next opponent's habits. There has been at least one case of mistaken identity when one of the databases (copying the error from a chess magazine admittedly) got a player's name wrong. His next opponent was surprised when he did not play the expected variation, and found out later that the game he had been studying was played by his opponent's wife (also a *very* strong player). The Polgar sisters have also been confused this way.

[a lack of Pravda (truth) in Isvestia perhaps]

[It *was* a new opening, complete with Queen sacrifice, and an "Indian" opening at that. Maybe PGN's name Gary Indiana Jones Beach Defense will catch on. Stranger names have been used]

Peter Rice, EMBL, Postfach 10-2209, D-6900 Heidelberg, Germany Internet: rice@EMBL-Heidelberg.DE Phone: +49-6221-387247

[I had intended correct my spelling to "Garry Indian a Jones Beach Defense", but had a clock overflow, and could not make the last move. PGN]

------------------------------

Date: Tue, 23 Oct 90 14:14:37 PDT From: Rich Wales <wales@CS.UCLA.EDU> Subject: Computerized cars and ham radio interference

As most RISK readers are aware, more and more aspects of today's cars are being controlled by sophisticated electronics -- from electronic ignition, to computerized fuel injection, to digital LED dash displays.

What happens when you put a radio transmitter in a modern-day car? Are the new electronics properly designed to withstand stray electromagnetic radiation at close range and fairly high levels?

I'm thinking in particular of what might happen if one were to put an amateur ("ham") radio in a current-model car. Ham equipment can easily generate 30-50 watts of power at frequencies near 144, 220, and/or 440 MHz.

My 1984 Honda Accord (which has electronic ignition and an aftermarket alarm system, but no other ultra-fancy stuff that I can think of) has coexisted very nicely with my 144/440-MHz ham transceiver. But what about the =next= car I buy -- which will most likely have sophisticated fuel injection and maybe even a digital dash? It would be most disconcerting to have the car stall -- or speed up all by itself -- or even just have the dash go blank -- whenever I might hit the mike button.

I recently asked the USENET "rec.autos.tech" newsgroup about digital dashboard displays on new cars. One respondent indicated that his 1989 Ford Aerostar's digital display went completely berserk whenever he operated his ham radio at high power (50W) -- though, thankfully, it promptly returned to normal once he stopped transmitting. More disturbingly, when he transmitted at medium power (15W) with the cruise control engaged, the car would start to accelerate!

I wonder how aware auto makers are of this issue. Surely, they need to be thinking about it at least a little; even though there aren't that many hams, there are lots of people with cellular phones or CB radios. (To be sure, these generate much less power than ham radios do.) Also, what about the person who drives near the transmitter tower of a commercial radio or TV station? Again, less power than a ham rig, but still maybe enough to wreak havoc with poorly shielded electronics.

My purpose in submitting this message is twofold. First, I'd like to get some discussion going on the general issue. Second, if anyone knows of any specific auto makes/models being manufactured today which suffer from this kind of problem, I'd like to know so that I can avoid these cars when the time comes to buy a new set of wheels.

Rich Wales, WA6SGA <wales@CS.UCLA.EDU> // UCLA Computer Science Dept. 3531 Boelter Hall // Los Angeles, CA 90024-1596 // +1 (213) 825-5683

------------------------------

Date: Tue, 23 Oct 90 19:51:10 -0500 From: stuart@cs.wisc.edu (Stuart Friedberg) Subject: Programmer error, not language flaw (RISKS-10.50)

Chet Laughlin wrote (14 October): > It was interesting to note that programs that ran correctly on SUNS did > not run correctly on the PS/2s - even though they compiled without change.

I don't wish to offend, but I really feel this was simply a programming error and has nothing to do with Ada. The program in fact ran *correctly*. The apparent fault was not in the program behavior, but in the programmers' expectations.

Nor do I think this is a problem with Ada as a misleading language. When my introductory OS class studies race conditions and the need for synchronization, one of the boundary cases we stress is one process not making any progress at all until all others are blocked. This can happen equally well on uni- and multi-processors and in distributed systems. If they don't come to understand scheduling uncertainties from the book, or my lectures, the programming projects they do with interrupts give them the lesson the hard way.

Stu Friedberg (stuart@cs.wisc.edu)

------------------------------

End of RISKS-FORUM Digest 10.55 ************************