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 3 Issue 47

Monday, 1 September 1986

Contents

o Flight Simulators Have Faults
Dave Benson
o Re: QA on nuclear power plants, the shuttle, and beer
Henry Spencer
o Acts of God vs. Acts of Man
Nancy Leveson -- two messages
o Computer Literacy
Mike McLaughlin
o Another supermarket crash
Ted Lee
o A supermarket does not grind to a halt
Brint Cooper
o Info on RISKS (comp.risks)

Flight Simulators Have Faults

Dave Benson <benson%wsu.csnet@CSNET-RELAY.ARPA>
Sat, 30 Aug 86 23:08:47 pdt
I mentioned the F-16 RISKS contributions to my Software Engineering class
yesterday.  After class, one of the students told me the following story about
the B-1 Flight Simulator. The student had been employed over the summer to
work on that project, thus having first-hand knowledge of the incident.

Seems when a pilot attempts to loop the B-1 Flight Simulator that
the (simulated) sky disappears.  Why?  Well, the simulated aircraft
pitch angle was translated by the software into a visual image by
taking the trigonometric tangent somewhere in the code.  With the
simulated aircraft on its nose, the angle is 90 degrees and the
tangent routine just couldn't manage the infinities involved.  As I
understand the story, the monitors projecting the window view went blank.

Ah, me.  The B-1 is the first aircraft with the capability to loop?  Nope,
its been done for about 70 years now...  The B-1 Flight Simulator is the
first flight simulator with the capability to allow loops?  Nope, seems to
me I've played with a commercially available Apple IIe program in which a
capable player could loop the simulated Cessna 180.  $$ to donuts that
military flight simulators with all functionality in software have been
allowing simulated loops for many years now.

Dick Hamming said something to the effect that while physicists stand on one
another's shoulders, computer scientists stand on one another's toes.  At
least on the toes is better than this failure to do as well as a game
program...  Maybe software engineers dig one another's graves?

And this company wants to research Starwars software...  Jus' beam me up,
Scotty, there's no intelligent life here.


Re: QA on nuclear power plants, the shuttle, and beer

<decwrl!decvax!LOCAL!utzoo!henry@ucbvax.Berkeley.EDU>
Sun, 31 Aug 86 01:35:29 edt
Equipment failures and human errors are common enough in any human endeavor;
the question is not whether they happen, but whether they present actual or
potential risks of serious consequences.  In this context the lack of
publicity is not at all surprising: one form of serious consequence is public 
hysteria over insignificant trivia.  When an attempt to reach a vacationing
brewery programmer gets blown up into stories of a total production shutdown
and impending beer shortage -- this, mind you, in an industry which is *not*
the focus of hostile propaganda campaigns and widespread irrational fears --
the people involved with nuclear plants have every reason to be very quiet
about even routine, unexciting, non-hazardous problems.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry


Acts of God vs. Acts of Man

Nancy Leveson <nancy@ICSD.UCI.EDU>
30 Aug 86 17:26:20 PDT (Sat)
   <> From: Nancy Leveson 

Acts of God vs. Acts of Man, Round n+1 (eastbound)

Nancy Leveson <nancy@ICSD.UCI.EDU>
30 Aug 86 23:30:36 PDT (Sat)
   >From Herb Lin:
   >But the number of assumptions that
   >designers must make is enormously large, and it is essentially
   >impossible to even articulate ALL of one's assumptions.  

Agreed.  But there are ways to determine which are the critical
assumptions with regard to particular hazards.  This is exactly what
some of my techniques, e.g. software fault tree analysis, attempt to
do.  In the Firewheel example that I published, we determined a critical
assumption which could have resulted in the satellite being destroyed.
That is, if there were two sun pulses detected within 64 milliseconds of
each other, the microprocessor interrupt system became hung which could
possibly result in destruction of the sensor booms (and thus the usefulness
of the satellite).  We found this assumption by working backward through
the software from the hazardous condition.  The solution, once the
critical assumption had been determined, was a simple blocking of the
second sun pulse interrupt.

I don't know for what size systems these backward analysis approaches are
practical.  It took Peter Harvey (my student) two days to analyze the
Firewheel software (which is about 1600 lines long) by hand.  Obviously, it
would be possible to analyze larger software, but we do not yet know how
much this will scale up practically.  We are working on a software tool to
automate as much as possible.  These techniques are, of course, no more
perfect than other more traditional software engineering techniques.  And
better ones may be found.  I am just not ready to say it is impossible
without first trying.

Backwards analysis, verification of safety, software interlocks,
software fault tolerance, fail-safe design, ... -- there are possible
solutions which we should be examining.
                                               Nancy Leveson


Computer Literacy

Mike McLaughlin <mikemcl@nrl-csr>
Mon, 1 Sep 86 11:49:10 edt
From THE WASHINGTON POST, Monday, 1 Sept 86, page A14, Letters to the
Editor [ "..." indicates omissions].  While I do not entirely agree with
Mr. Jordan, much of what he says is directly applicable to Risks.

        [Before responding to this, please recall that this topic has
         already been discussed at some length in RISKS-2.36 and 37, 
         and in RISKS-3.17, 19, 20, and 21.  PGN]

        +++++++++++++++++++++++++++++++++++++++++++++++++++++++

                         COMPUTER LITERACY

     Although I earn my living as a consultant in computerized data bases,
I strongly oppose the view... that computer literacy should be mandatory in
the secondary school curriculum.

     Computers are a device for performing some task that either is already
performed by other means or first must be understood in other terms,
usually a mathematical equation.  Learning how to operate a computer, or
program one, is not going to improve a student's knowledge of languages,
mathematics, history or political science.

     Alfred North Whitehead observed that civilization increases the number
of things that we can do without thinking, i.e., that we can take for
granted.  This is evident in the development of computers, which
increasingly are becoming like automobiles; anyone can drive them.
Learning the technology of computers has as much relevance to everyday life
as learning the technology of auto engines.

     Unquestionably there are tasks for which computers are indespensable,
but individuals will learn those functions as they become involved in the
task itself, whether it be medical diagnosis, controlling the flow of
electric power over a grid or determining the authorship of a 16th-century
poem.

     What students need to know is how to think, especially about the human
condition.  As more and more college students flock to "practical" majors,
the secondary schools should be concentrating on the liberal arts.  In this
perspective, "computer literacy" may be just another form of a larger
illiteracy.

          - John S. Jordan,  Washington, D.C.


Another supermarket crash

<TMPLee@DOCKMASTER.ARPA>
Sat, 30 Aug 86 23:26 EDT
Same thing happened here (Minneapolis-St.Paul) a couple of years ago -- I
was in a major discount store (Target), during a normal busy time --
Saturday morning, I think -- only to find that all the cash registers wre
down because the central computer was down.  Don't know how long it lasted,
but at least long enough that by the time I got there the cashiers were
using paper and pencil.  Really, stupid -- (so he says as a so-called
computer expert) -- given that those registers probably had Z80's or 6502 or
such in them, a printed record, etc., so they could just as well have worked
off-line (except for not knowing the price on instant sale items, which
would I assume have been in the central machine.)


A supermarket does not grind to a halt

Brint Cooper <abc@BRL.ARPA>
Mon, 1 Sep 86 13:29:45 EDT
Last month, as I awaited checkout in a "Giant" supermarket in Bel Air,
MD, an area-wide power outage lasting several minutes occured.  The
following was the sequence of events:

    1.  All lights, outside and inside, instantly out.
    1A. Display on cash register_cum_terminal RETAINED display!
    2.  Some of the same lights came back almost immediately (seemed
            to be back-up power).
    3.  Several minutes passed; additional lights began to come on.
    4.  One-by-one, the terminals "beeped" and became functional.

No market employee with whom I spoke seemed to understand what actually
happened.  But the computer system obviously was protected from such
random power outages (which occur FREQUENTLY here).
                                                          Brint Cooper
                    UUCP:  ...{seismo,unc,decvax,cbosgd}!brl-smoke!abc

Please report problems with the web pages to the maintainer

Top