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 8 Issue 63

Tuesday 25 April 1989

Contents

o More 737 Computer Problems
Brian Randell
o Cockpit Computers Defy Pilots
Robert Dorsett
o Common thread in recent postings: People
Ian
o Smoke vs. disc drives
John Shipman
o Use of "Standard" on sensitive applications
Terry S. Arnold
o Computer Threat Research Association (UK)
David J. Ferbrache
o ATMs used to track accused killer
Steve Bellovin
o Re: Most Accurate Clock
Don Watrous
o Info on RISKS (comp.risks)

More 737 Computer Problems

Brian Randell <Brian.Randell@newcastle.ac.uk>
Tue, 25 Apr 89 10:33:26 BST
[This is a remailing of a hitherto undelivered 10 April posting from Brian
Randell, Computing Laboratory, University of Newcastle upon Tyne.]

                BOEING 737 PROBLEMS REACH FRESH HEIGHTS
            by John Kavanagh, Computer Weekly, 6 April 1989

Autopilot computer systems on Boeing 737s have been hit by a problem which has
caused aircraft to change height without warning.  It is believed that full
details of the problem have been requested by the investigators into the crash
of the British Midland 737 on the M1 motorway in January. One theory is that
the crew were misled by cockpit instruments.

Six incidents have been recorded by British Airways on its aircraft but the
company says there has never been any danger because the crews have always
checked the autopilot actions against other cockpit instruments.

Boeing and Honeywell Avionics, manufacturer of the autopilot system, have
alerted airlines using the 540-plus aircraft affected.  "We have been working
with the airlines and the regulatory autthorities to fix the problem." Boeing
says.

The problem occurs after a pilot enters a new height to the autopilot.  The
system displays the instruction, but under certain circumstances the aircraft
moves to a different height and the autopilot then displays the new reading.

One senior British Airways captain says the autopilot seems to use instructions
entered earlier, even as long ago as the previous flight.

British Airways has called the problem "random memory initiation" and says it
is caused by unexpected electromagnetic conditions such as lightning, strong
radar signals, or an electrical power surge.  Boeing says it has no evidence of
any accidents occurring because of the problems.


Cockpit Computers Defy Pilots

Robert Dorsett <mentat@dewey.cc.utexas.edu>
Tue, 25 Apr 89 12:17:21 CDT
                   Cockpit Computers Defy Pilots
              By David Learmount, Air Transport Editor
                (From Flight International, 4/8/89)

Airliners have levelled out at incorrect flight levels as a result of flight
management computers overriding pilot instructions.  This results from a
phenomenon which British Airways has named random memory initialisation (RMI).
BA says that modifications it has carried out have eliminated the problem.

A line pilot has described RMI as "an increasingly common defect," although
replacement of the microchips thought to be responsible is being carried out.
The faults are most common, according to aircrew, in the early part ofa flight
after the aircraft has been on the ground for some time.  BA has experienced
problems on all of its aircraft types fitted with electronic flight management
systems.

The theory is that chips are retaining instructions which should have been
overridden by the pilots' latest entry into the flight management system.  The
earlier instructions sometimes override the current ones, changing not only
aircraft performance, but the digital display showing the effective instruction.

If the pilots are monitoring their flight management control display, they
should see the change take place, or the incorrect entry come up.  In busy
phases of flight, however, such events have been missed.

A change in selected parameter has been known to tkae place in the 737-300.  In
the glass-cockpit 757 and 767, the more likely error is that the aircraft may
fly through the set "height-acquire" flight level, or depart from the one it is
at, although the value in the "height-acquire" window remains as selected.  The
latter two events are likely to be discovered quickly beacuse the crew will be
monitoring flight level.

An airline pilot tells FLIGHT that some aircrew believe this sort of event may
be contributing to pilots' scepticism about information displayed in modern
cockpits--a human factor under investigation in the British Midlands 737
accident.  Pilots may enter one set of of information, then act on different
data which is displayed.

In one incident, a BA 737-300 on airtest out of Heathrow was cleared to descend
to flight level 80 [8,000 feet].  The crew believe they entered FL80 in
height-acquire, and saw it on the mode control display.  The aircraft levelled
at FL70, and air traffic control queried the action.  The crew saw that FL70
was entered on the "height acquire" window of the flight management mode
control panel and queried the ATC instruction.  The pilot then set FL80 on
"height-acquire" and climbed to it.  The crew then flew level for a short time
at FL80 and, while watching, saw the height-acquire display change to FL70.

Another 737-300 pilot has remarked to FLIGHT that, while dialling the
height-acquire instruction, care is necessary because the display can settle
one flight level above or below the figure entered.

BA admits to changes of these types occurring a recorded six times for a reason
classified as "transient electromagnetic condition" (TMC), which they say has
now been cleared by modification.  TMC can be induced by current surges, and it
is a well-known electronic phenomenon.  Power surges or other forms of TMC can
occur under well-recognised conditions, such as changeover from ground power
supply to aircraft generators, lightning strikes, and radar proximity.  Effects
have also occurred when the cause was not obvious.  It is not clear whether BA
references to events resulting from TMC are the same--or related to--pilot
reports of RMI detailed in BA's monthly Air Safety Review.

TMC problems have been dealt with by changes to software, hardware, and the
mode select panel.  BA says that there have been no further reports of problems
since the modifications were made.

   --------

An observation:

Modern glass cockpits (i.e., not the 757, 767, or A310) all use tape
altimeters.  Reading errors are common on such displays.  In addition, these
displays are not standardised; some scroll down to indicate increasing
altitude; some scroll up.  Some have a "highlight" window, showing current
digital altitude; some don't.  Setting errors, combined with read errors, could
be fatal.

Media observation: pilots are being increasingly portrayed as "reactionary old
fogies whose fears might actually be justified"--as if the manufacturers and
the industry, in general, are the bearers of Light and Goodness. :-)

Robert Dorsett
Internet: mentat@walt.cc.utexas.edu
UUCP: ...cs.utexas.edu!walt.cc.utexas.edu!mentat


Common thread in recent postings: People

<ian@lassen.sgi.com>
Thu, 06 Apr 89 10:04:47 PDT
 Many of the recent postings seem to have a lot in common.  They all deal with
some form of technological defect.  Airbus accidents blamed on faulty
computers, Audi 5000's effected by radio interferance, Elevators in which Micro
processors fail to detect open or blocked doors, fire control systems which
mis-identify civilian planes, the list goes on.

 Each of the incidents above have, of course,  another thing in common, they
were designed by humans.

 What are the risks associated with technology we don't properly understand?
As we have modernized elevators, planes, cars and fire control systems, they
seem to have become not only more complicated but more trouble prone.

 I am reminded that K(eep) I(t) S(imple) S(tupid) is perhaps something we
should reevalute by the NOVA episode "Beyond Top Gun" in which Korean war
pilots said, while flying in Vietnam, the first thing they did in a dogfight
was start turning things off starting with the back seaters' intercomm followed
by some of the warning buzzers and other techno whiz bangs.
                                    Ian


Smoke vs. disc drives

John Shipman <john@jupiter.nmt.edu>
Sat, 22 Apr 89 13:40:09 MDT
One advantage of Winchester-type disc drives is that they are sealed against
smoke and other particulates.  Hard drives with removable media, however,
must have ``absolute'' filters, since smoke particles are larger than the
flying height of a typical disc head.  It's a fine theory to warn your
customers not to smoke, but who's going to check up on third-shift operators?

At a famous West Coast computer company where I worked in the early seventies,
the newly founded disc division had just shipped their first production drive
to the computer division for testing.  A friend of mine in Systems Integration
believed it was not his duty to coddle the equipment, but to subject it to more
typical real-world conditions.  He installed the drive, got the diagnostics
running on it, and then lit a cigar and proceeded to exhale all the smoke
directly into the disc's air intake.  SPANG---head crash.

The disc division tried to ``blame the messenger'' and wanted my
friend fired, but the computer division backed him up.  Result: by
the time this model went to real customers, it had an absolute
filtration system, and eventually proved to be quite reliable.


Use of "Standard" on sensitive applications

"Terry S. Arnold" <Arnold@DOCKMASTER.ARPA>
Mon, 24 Apr 89 22:49 EDT
What do the readers of this forum think are the risks involved in using
"Standard" tools such as lex or yacc etc. in developing sensitive applications?
Is it reasonable to set some criteriaa for saying that a given tool has
withstood the test of time therefore it can be safely used?  If so what should
this criteria be?
                                        Terry Arnold


Computer Threat Research Association (UK)

"David.J.Ferbrache" <davidf@cs.heriot-watt.ac.uk>
31 Mar 89 09:03:40 GMT
For those of you interested an umbrella organisation has been established
in the UK to co-ordinate information on, and research into, all aspects of
computer security. In the first instance one of the organisation's primary
concerns will be combatting the threat posed by computer viruses by
acting as a clearing house for virus information and control software.

Below is a copy of an initial letter mailed to prospective members:

            The Computer Threat Research Association

The computer threat research association, CoTra is a non-profit making
organisation that exists to research, analyse, publicise and find solutions
for threats to the integrity and reliability of computer systems.

The issue that caused the formation of CoTra was the rise of the computer
virus. This problem has since become surrounded by fear, uncertainty and
doubt. To the average user the computer virus and its implications are a
worry of an unknown scale. To a few unfortunates whose systems have become 
a critical issue.

The key advantage of CoTra membership will be access to advice and information.
Advice will be provided through publications, an electronic conference (a
closed conference for CoTra's members has been created on the Compulink
CIX system) as well as other channels such as general postings direct to
members when a new virus is discovered.

CoTra membership will be available on a student, full or corporate member
basis. All software that is held by CoTra that enhances system reliability,
such as virus detection and removal software, will be available to all
members. It is intended to establish discounts with suppliers of reliability
tools and services. A library of virus sources and executables and other
dangerous research material will be made available to members who have a
demonstrable need.

A register of consultants who have specific skills in the systems reliability
field will be published by CoTra and reviews of reliability enhancing
software will be produced.

Your support of CoTra will ensure that you have the earliest and most
accurate information about potential threats to your computer systems.

CoTra, The computer threat research association,
c/o 144 Sheerstock, Haddenham, Bucks. HP17 8EX

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

Part of the organisations aims is to establish reciprocal links with other
similar organisations worldwide, to facilitate the sharing of experience
and rapid flow of information on new threats.

To this end if you are involved in (or have contacts with) a similar
organisation in your country, please write to CoTra (or by email to me, 
and I will forward your correspondence) outlining your organisation 
and its aims.

Yours sincerely

Dave Ferbrache                            Personal mail to:
Dept of computer science                  Internet <davidf@cs.hw.ac.uk>
Heriot-Watt University                    Janet    <davidf@uk.ac.hw.cs>
79 Grassmarket                            UUCP     ..!mcvax!hwcs!davidf 
Edinburgh,UK. EH1 2HJ                     Tel      (UK) 031-225-6465 ext 553


ATMs used to track accused killer

<smb@arpa.att.com>
Tue, 25 Apr 89 08:02:19 EDT
  In times of emergency such as this, we suspect that such requests can be
  [used] legally by appropriate agencies without too much fuss.

Part of the problem here is not that the technique was used, but that it was
done without judicial approval.  The bank *chose* to co-operate, on the word of
the police authorities.  In this case, the situation was fairly clear.  What if
it's a foreign student who is accused of being a ``terrorist''?  Such
accusations by the government have already been thrown out of court on several
occasions.  (The student may or may not be one; that's irrelevant.)

        --Steve Bellovin


Re: Most Accurate Clock (RISKS 8.62)

<watrous@aramis.rutgers.edu>
Tue, 25 Apr 89 10:04:33 EDT
 > Date: Sat, 22 Apr 89 11:35:21 PST
 > From: David Schachter <david%daisy@sri-unix.UUCP>

 > Unfortunately, I couldn't get anyone interested in modifying the
 > WWV/WWVH code to include a public-key encipherment approach, so that
 > if the clock can decode the signal, the signal must have come from WWV/WWVH.
 >                               -- David Schachter

The signal must have come from WWV/WWVH _at some time_! This would verify the
source of the signal, but not the timeliness.  Your clocks could be set back by
broadcasting a tape of WWV/WWVH.  The encipherment only solves half the problem.

Don

Please report problems with the web pages to the maintainer

Top