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 10 Issue 55

Tuesday 23 October 1990

Contents

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

Malfunction on Gambling Machine delivers $300,000 Jackpot

<colville@otc.otca.oz.au>
Fri, 19 Oct 90 14:33:47 +1000
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


Risks of Modernization

Chuck Weinstock <weinstoc@SEI.CMU.EDU>
Fri, 19 Oct 90 13:21:25 EDT
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


Airliner story

Ellen Cherniavsky <ellen@swift.mitre.org>
Fri, 19 Oct 90 15:17:14 EDT
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.


Summary of A320 report on W5

Wayne Hayes <wayne@csri.toronto.edu>
Sun, 21 Oct 90 21:17:44 EDT
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


Boeing 777 to use fly by wire

Robert R. Henry <rrh@tera.com>
Mon, 22 Oct 90 12:54:49 PDT
>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.


Re: Technology Meets Dog; Dog Wins

Dan Sandin <sandin@uicbert.eecs.uic.edu>
Mon, 22 Oct 90 05:05:39 GMT
>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


Stick-up At Banks

paj <paj@gec-mrc.co.uk>
22 Oct 1990 15:32:51-BST
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.


Re: Kasparov's sealed move (RISKS-10.51)

Peter Rice &eter.Rice@EMBL.BITNET>
Mon, 22 Oct 90 18:35 +0100
>   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]


Computerized cars and ham radio interference

Rich Wales <wales@CS.UCLA.EDU>
Tue, 23 Oct 90 14:14:37 PDT
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


Programmer error, not language flaw (RISKS-10.50)

Stuart Friedberg <stuart@cs.wisc.edu>
Tue, 23 Oct 90 19:51:10 -0500
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)

Please report problems with the web pages to the maintainer

Top