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 4 Issue 59

Sunday, 8 March 1987


o Safe software
Geraint Jones
o Computer Problem causes airline financial loss
Rob Horn
o Re: Altitude Encoders... expensive for some
Ronald J Wanttaja
o Influence of goal selection on safety
Henry Spencer
o Re: Puget Sound Ferry Boats
Dennis Anderson
Robert Frankston
Bjorn Freeman-Benson
o GOES satellites, Scotchbrite, Gnomic Maxims, and Mr. Bill
Martin Harriman
o Spreadsheet budget helping legislators
Scot E. Wilcoxon
o Info on RISKS (comp.risks)

Safe software

Geraint Jones <>
Sat, 7 Mar 87 00:41:38 GMT
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.

Computer Problem causes airline financial loss

Rob Horn <wanginst!infinet!>
Fri, 6 Mar 87 11:30:31 est
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

Re: Altitude Encoders... expensive for some

Ronald J Wanttaja <ames!uw-beaver!ssc-vax!wanttaja@cad.Berkeley.EDU>
Thu, 5 Mar 87 09:52:32 pst
> 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)

Influence of goal selection on safety

Fri, 6 Mar 87 20:51:46 pst
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

Re: Puget Sound Ferry Boats

Dennis Anderson <ames!uw-beaver!ssc-vax!dma@cad.Berkeley.EDU>
Wed, 4 Mar 87 15:18:19 pst
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

Re: Puget Sound Ferry Boats

Sat, 7 Mar 87 01:50 EST
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

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.

Re: Puget Sound Ferry Boats

Sat, 7 Mar 87 02:01 EST
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.

GOES satellites, Scotchbrite, Gnomic Maxims, and Mr. Bill

Martin Harriman <""@RELAY.CS.NET>
Fri, 6 Mar 87 14:53 PDT
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... <crunch>").

  --Martin Harriman

                      [Deburred in the hand is worth 3 Bills in debrush.  PGN]

Spreadsheet budget helping legislators <Scot E. Wilcoxon>
4 Mar 87 11:00:29 CST (Wed)
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]

Please report problems with the web pages to the maintainer