The RISKS Digest
Volume 12 Issue 10

Monday, 29th July 1991

Forum on Risks to the Public in Computers and Related Systems

ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator

Please try the URL privacy information feature enabled by clicking the flashlight icon above. This will reveal two icons after each link the body of the digest. The shield takes you to a breakdown of Terms of Service for the site - however only a small number of sites are covered at the moment. The flashlight take you to an analysis of the various trackers etc. that the linked site delivers. Please let the website maintainer know if you find this useful or not. As a RISKS reader, you will probably not be surprised by what is revealed…

Contents

Summer slowdown
PGN
Egad, sail-by-wire! (W. K.
Bill) Gorman
Third Chicago Airport: Rare Events & Computer Projections
William E. Mihalo
Risks of human error in Soviet nuclear "industry"
Tom Blinn
Re: Smart cockpit with no backup
Simson Garfinkel
Licensing of Software Engineers
Bill Murray
Re: New Jersey "software engineering" registration legislation
Bob Frankston
ACM SIGSOFT '91, SOFTWARE FOR CRITICAL SYSTEMS
Judith Burgess
Info on RISKS (comp.risks)

Summer slowdown

"Peter G. Neumann" <neumann@csl.sri.com>
Mon, 29 Jul 91 9:56:27 PDT
I'll be off the net more or less for the next three weeks.  I hope the world of
computer-related activities becomes very peaceful and uneventful, so that we
don't miss anything.  Please keep sending in your goodies, however, and we'll
get to them eventually.

Please check out the advance information on SIGSOFT '91, SOFTWARE FOR CRITICAL
SYSTEMS, 4-6 December 1991, in New Orleans, included as the last item in this
issue.  This conference will be of unusually high relevance to the RISKS
community.  PGN


Egad, sail-by-wire!

<34AEJ7D@cmuvm.bitnet>
Fri, 26 Jul 91 11:16:50 EDT
I recently noted that the Japanese are aggressively developing a generation of
huge, totally unmanned, computer-guided supertankers intended to embark/debark,
as well as transit the oceans, in fully automated mode. The risks, based on
fly/drive by wire research, of having these vessels transiting the oceans
unmanned seems significant. Any supertankers is a significant hazard to
navigation by smaller vessels, which are notorious for not being particularly
easy to spot on radar.  The risk of possible environmental disasters, e.g.
Exxon Valdez, exists for all supertankers. Running unmanned, IMHO, exacerbates
the situation. The risk of possible terrorism involving a large, relatively
slow-moving, completely exposed, unmanned ship, carrying a potentially
hazardous cargo through the strategic shipping lanes of the world probably
should not be ignored.
                                        W. K. (Bill) Gorman


Third Chicago Airport: Rare Events & Computer Projections

"William E. Mihalo" <calumet!wem@gargoyle.uchicago.edu>
Sat, 27 Jul 1991 13:59:07 cdt
Considerable controversy developed during the past year regarding the site
selection for a third airport within the Chicago metropolitan area. Once in
place the projected number of planes using the airport would exceed the current
traffic at O'Hare Field, one of the world's busiest airports. A number of sites
have been proposed: 1) an area on the southeast side of Chicago called the Lake
Calumet site; 2) an area on the western side of Gary, Indiana and 3) two other
"green grass" sites that are located approximately 35 miles south of Chicago.

Richard M. Daley, the mayor of Chicago, has been promoting the Lake Calumet
site for over a year. A number of politicians within Gary, Indiana and
downstate Indiana have been promoting the Gary site. Both the Lake Calumet and
Gary locations are in open land adjacent to some heavily populated areas. Both
the Lake Calumet and Gary sites would require massive condemnation of homes in
the southeast side of Chicago and in Gary, Indiana.

How does this relate to RISKS?  I see two possible links.

The first is the obvious "rare event." Planes tend to crash near airports. For
example in May, 1979 a DC-10 crashed shortly after takeoff killing 275 people.
The areas adjacent to the Lake Calumet and Gary sites are heavily populated.
Moreover, an oil refinery is within 3 miles of the Lake Calumet site and
several steel mills are adjacent to the Gary site.  The idea of a DC-10
colliding with an oil refinery is admittedly a rare event. The consultants and
politicians promoting the Lake Calumet and Gary sites have dismissed such
possibilities with little discussion.

Second, the site location for this third airport is based on a series of
computer projections performed by outside consultants hired to provide
information on needed runway size, number of passengers and the overall
economic impact of the facility. Northwest Indiana and the southeast side of
Chicago underwent substantial deindustrialization starting in the 1960's and
accelerating in the 1980's. Computer models have projected a payroll of $2.7
billion, for the Gary airport and an overall economic benefit of $5.7 billion
by the year 2020. These data are being pushed as "fact" (it must be true, it
came from a computer). Also, heavily emphasized are estimates of 150,000 to
300,000 jobs that would be created in conjunction with the airport. Work on the
noise contours associated with the runway configuration for these two airport
sites have been delayed. Also delayed is the projected out-migration of
residents from the area.

The entire site selection process is an example of a consulting firm with a PC
running amok with projected statistics and estimates. In some cases the media
are directly fed the projections with little questioning. The fact that these
data were created by a computer simulation or projection is not taken into
account. Nor is there any questioning of the type of mathematical model that is
being used to generate this data.

Geographic and cartographic software used to map the proposed airport sites has
failed to take into account the topography of the land and the number of
businesses affected. Massive wetland drainage would be required for the Lake
Calumet site. Also, the consultants failed to take into account the substantial
migratory bird population (birds and airplanes don't mix) and weather
associated with the Lake Calumet and Gary sites (both sites would start near
the shore of Lake Michigan and head south). The chairman of the bistate
selection committee for the third airport Frank Luersen (CEO for Inland Steel)
was forced to resign after the consultants recommended the closure of Cline
Avenue (a major divided highway in northwest Indiana) and the closure of the
Inland Steel Research Lab.  Somewhat embarrassed, the consultants returned with
a new runway configuration that allowed Cline Avenue and Inland Steel to
remain, but on land immediately adjacent to the Gary airport site.

William E. Mihalo   wem@calumet.uucp


Risks of human error in Soviet nuclear "industry"

Tom Blinn <blinn@dr.enet.dec.com>
Fri, 26 Jul 91 12:28:19 PDT
In the RISKS DIGEST 12.08, PGN contributed the article "Human Error Blamed for
Soviet N-Plant Problems".  In the recently translated and published book on the
Chernobyl disaster, the Soviet nuclear engineer/scientist Medvedev reported on
the root causes, which were, basically, human error.  It should be no surprise
that, in spite of Glasnost, the fundamental flaws in the system have not been
addressed.  (I regret I do not have a better reference for Medvedev's book at
hand.  It is excellent.)

Thomas P. Blinn, Digital Equipment Corporation, Digital Drive — MKO2-2/F10,
Merrimack, New Hampshire 03054 ...!decwrl!dr.enet.dec.com!blinn (603) 884-4865


Re: Smart cockpit with no backup

<simsong@nextworld.com>
Fri, 26 Jul 91 12:19:26 PDT
Henry Spencer writes that the Air Force's new F-22 has no mechanical backup
instruments --- making the flight software extremely flight-critical.

However, on new "fly-by-wire" aircraft, a computer failure would also
deactivate all of the aircraft's control surfaces, since the pilot's stick is
really nothing more than a joystick on these planes.  In the event of a
computer failure, the only good that mechanical backup instruments would do
would be to let the pilot watch the altitude ticking off on the way down...


Licensing of Software Engineers

<WHMurray@DOCKMASTER.NCSC.MIL>
Fri, 26 Jul 91 09:36 EDT
I do not read the text of the NJ legislation posted here as requiring the
licensing of programmers.  Rather it recognizes the existence of a special
class of programmer.

It only requires licensing of those who offer themselves for hire as software
ENGINEERS.  Hire and engineer are both key words.  I am a "once and sometime
programmer."  I have not been employed in that capacity for years.  Since I do
not offer myself for hire in that capacity, I would not require a license.

Even if I were to take a job as an entry-level programmer [a job for which I am
at one and the same time both over and under qualified] I would not need to be
licensed under this legislation, since I do not offer myself for hire as an
engineer.  I would be a programmer, not an engineer.  [Nancy L. is a software
engineer.  Padgett P. is an engineer.  I am a mere software author.]  I would
be making no special claims about my qualifications.  It is the special claim
of engineer that would subject me to this legislation, not software alone.

Now, while I suspect that this law may be a little premature, past discussions
in this list suggest that mere programmers, such as myself, are making
decisions for which we are not qualified.  The result is as much to put the
public at hazard as if I were to undertake to build a bridge.  I did, once
program at the Louisiana Department of Highways.  Some of the work that I did
influenced the construction of roads and bridges, but it was done under the
supervision of licensed civil engineers, experienced in building roads and
bridges.

Soon we will have "smart" roads and bridges in which computer hardware and
software will be active components of the roads and bridges.  The ability to
write the software for those roads and bridges does not necessarily, include
the ability to write the specification.  It clearly does not include the
ability to decide upon the role of the computer or software in the road.  This
requires special competence which I am not even qualified to judge [but which I
would trust Nancy and Padgett to judge.]

Note that the NJ legislature does not attempt to define these qualifications or
to describe them.  Rather, it leaves that to those who would so hold
themselves.  This is similar to what it does with other professions.

It is not clear whether or not programming is a profession or not.  It is clear
that most of the people who engage in it, even some of those who do it for a
living, would not qualify under any reasonable definition of professional.  It
is equally clear that there is a requirement for a group of professionals,
trained in the lore and traditions of engineering, not "computer science" who
can make decisions about how software is to be designed, built, and used.  I
know some of the people who do it; they are professional in a sense that some
programmers cannot even understand.

I do not trust the NJ legislature to rcognize these people.  I concur in the NJ
legislatures recognition that they can and should have the discretion to
recognize their peers and exclude others.  It is in the public interest that
they do so.

That programmers, without the qualifications of these few, should feel
threatened by this is natural and to be expected.  However, I do not believe
their fears to be justified.

William Hugh Murray, Executive Consultant, Information System Security
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840       203 966 4769


Re: New Jersey "software engineering" registration legislation (J.M.Ritter)

<frankston!Bob_Frankston@world.std.com>
26 July 1991 19:37 -0400
One fundamental problem is that we are still learning what software engineering
entails.  Is a Hypercard programmer a software engineer? A spreadsheet macro
writer.  What about a VCR programmer?  Essentially any control of a system that
can remember instructions is programming and thus involves software
engineering.

I realize that the model the legislature has in mind is a Civil Engineer or a
Licensed Bridgebuilder (it is fun to revisit old examples), and that it looks
in horror at amateur mistakes being made in building critical systems. But
world is changing from engineering final systems to creating refineable systems
and thus propagating the empowerment of programming out to the end user and
making us all (Unlicensed) Software Engineers.

I greatly fear any attempt to codify what is not understood.

Note that there has been a certification process available (CDP) for a long
time.  Does anyone pay attention to it?

Actually, there may be a good side to this.  From the proposed act:

9.  (New section) No person shall practice, or  present  himself  as  able  to
     practice, software  1[engineering] _________1 unless he possesses a valid
     license as a software 1[engineer] ________1 in accordance with the
     provision of this act.

I guess we won't have to deal with nonprofessionals attempting to program their
VCRs.


ACM SIGSOFT '91, SOFTWARE FOR CRITICAL SYSTEMS, Advance E-mail program

Judith Burgess <burgess@csl.sri.com>
Fri, 26 Jul 91 16:46:29 -0700
            ACM SIGSOFT: '91 SOFTWARE FOR CRITICAL SYSTEMS
            4-6 December 1991, Fairmont Hotel, New Orleans

                        PRELIMINARY PROGRAM

Computer systems are increasingly affecting nearly every aspect of our lives.
They control aircraft, shut down nuclear power reactors in emergencies, keep
our telephone systems running, monitor hospital patients, and execute financial
transactions.  Although such systems offer considerable benefits, they also
pose serious risks in that we are increasingly vulnerable to flaws and other
deficiencies in the software, hardware failures, and effects of accidental and
intentional computer misuse.

WEDNESDAY, 4 DECEMBER 1991

Welcome and Introduction: 8:45am - 9:00
  Mark Moriconi, SIGSOFT '91 Chair (SRI International)
  Peter G. Neumann, Program Co-chair (SRI International)

Session 1: 9:00 - 10:15, Carl Landwehr, Chair

FORMAL VERIFICATION OF ALGORITHMS FOR CRITICAL SYSTEMS
  John Rushby (SRI International), Friedrich von Henke (University of Ulm)

STATE-BASED MODEL CHECKING OF EVENT-DRIVEN SYSTEM REQUIREMENTS,
  Joanne M. Atlee and John Gannon (University of Maryland)

Discussion

Session 2: 10:45 - 12:30, Dines Bj/orner, Chair

RIGOROUS DEVELOPMENT USING RAISE,
  Bent Dandanell (CRI, Birker/od, Denmark)

SPECIFYING AND VERIFYING REQUIREMENTS OF REAL-TIME SYSTEMS
  K.M. Jensen, A.P. Ravn, and Hans Rischel (Tech. University of Denmark)

A SYSTEMATIC KERNEL DEVELOPMENT
  J.F. S/ogaard-Andersen, C.O. Rump and H.H. Lovengreen (Tech. Univ. Denmark)

Discussion

Luncheon: 12:30 - 2:00

Session 3: 2:00 - 3:45, Elaine Weyuker, Chair

THE INFEASIBILITY OF EXPERIMENTAL QUANTIFICATION OF LIFE-CRITICAL
SOFTWARE RELIABILITY
  Ricky Butler and George Finelli (NASA Langley Research Center)

PANEL: ARE THERE ABSOLUTE LIMITS TO SOFTWARE VALIDATION?
  Elaine Weyuker (NYU Courant Institute)
  Bev Littlewood (City University, London)
  David Parnas (McMaster University)
  Ricky Butler (NASA Langley Research Center)
  John Musa (AT&T Bell Labs, Whippany, NJ) (unconfirmed)

  The Butler/Finelli paper argues that ultra-high reliability cannot
  be validated directly with testing alone, nor by the use of
  fault-tolerance. What are the implications?

Session 4: 4:15 - 5:30, Martyn Thomas, Chair

PANEL: THE CONFUSED WORLD OF STANDARDS FOR CRITICAL SYSTEM
   Martyn Thomas (Praxis, plc)
   Robin Bloomfield (ADELARD) (unconfirmed)
   Peter Neumann (SRI International)
   Mike DeWalt (FAA)

   Anticipated topics include British MoD DEFSTAN 00-55/56 and
   various security criteria (e.g., TCSEC, ITSEC, CTCPEC).
   What role should such standards play?  What should be
   mandated regarding requirements, specifications, criteria,
   methodologies, tools, and certification of developers?

THURSDAY, 5 DECEMBER 1991

Session 5: 9:00am - 10:30, Bill Howden, Chair

COMPARING FAULT DETECTING ABILITY OF TESTING METHODS
  P.G. Frankl (Polytechnic University), E.J. Weyuker (NYU Courant Institute)

AN EXCEPTION HANDLING MODEL FOR PARALLEL PROGRAMMING AND ITS VERIFICATION
  Valerie Issarny (IRISA/INRIA)

Discussion

Session 6: 11:00 - 12:30, Invitational Talk

HUMAN ERROR IN DESIGN
   Henry Petroski (Duke University), author of the books ``To Engineer
   is Human: The Role of Failure in Successful Design,'' and ``Pencil''

Luncheon: 12:30 - 2:00

Session 7: 2:00 - 3:30, Victoria Stavridou, Chair

A REAL-TIME TRANSITION MODEL FOR ANALYZING BEHAVIORAL COMPATIBILITY OF
TELECOMMUNICATIONS SERVICES
  E.J. Cameron and Y-J Lin (Bellcore)

PROGRAMMING AND VERIFYING CRITICAL SYSTEMS BY MEANS OF THE SYNCHRONOUS
DATA-FLOW LANGUAGE LUSTRE
  C. Ratel (Merlin-Gerin), N. Halbwachs and P. Raymond (IMAG/LGI)

Discussion

Session 8: 3:45 - 5:30, Mark Moriconi, Chair

Invited Talks on Practical Experiences:

Emphasis is on difficult real-world problems, approaches to critical systems
development, and lessons learned with respect to requirements, specification,
design evaluation, testing, and other forms of assurance.

VALIDATION OF CRITICAL FLIGHT CONTROLS
  Jim McWha (Chief Eng., 777 Flight Controls, Boeing)

TELEPHONE SWITCHING SYSTEMS
  Michael Meyers (AT&T Bell Labs)

A CASE STUDY OF THE THERAC 25 ACCIDENTS
  Nancy Leveson (U.C. Irvine)

Session 9: 8:00pm - 9:30pm, Evening Poster Session

FRIDAY, 6 DECEMBER 1991

Session 10: 8:30am - 10:30, Hermann Kopetz, Chair

STEPWISE DESIGN OF REAL-TIME SYSTEMS
  Reino Kurki-Suonio (University of Technology, Tampere)

ON SATISFYING TIMING CONSTRAINTS IN HARD-REAL-TIME SYSTEMS
  Jia Xu (York University), David Parnas (McMaster University)

AUTOMATED ANALYSIS OF BOUNDED RESPONSE TIME FOR TWO NASA EXPERT SYSTEMS
  C-K Wang, R-H Wang, D-C Tsou, J.C. Browne, and A.K. Mok (University of Texas,
  Austin)

Session 11: 11:00 - 12:30, Hermann Kopetz, Chair

Open discussion of Real-time Issues

PANEL: WHERE ARE WE AND WHERE SHOULD WE BE HEADED?
  Nancy Leveson, (U.C. Irvine) and others.

What is the state of the art in building critical systems?
What are the limitations of the various approaches?  What is needed?

Adjornment at 12:30

 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

             ADVANCE REGISTRATION FORM
     SIGSOFT '91 — Software for Critical Systems
    Fairmont Hotel, New Orleans, Dec. 4 — 6, 1991

Name _________________________________________________________
Affiliation __________________________________________________
Address ______________________________________________________
City, State and Zip __________________________________________
Phone (and FAX) ______________________________________________
email address ________________________________________________
ACM or SIGSOFT Membership No. ________________________________

Registration Fees (Circle one)

                            Before        After
   Category                    Nov. 1        Nov. 1
   ---------------------------------------------------
   ACM or SIGSOFT Member         $280        $330
   Non-Member                    $330        $380
   Full-time Student             $180        $230

To pay by credit card, circle one:    AMEX        VISA       MC
Name on card __________________________________________________
Card number __________________Exp. date _______________________
Signature _____________________________________________________

Make checks payable to SIGSOFT '91 in U.S. dollars.  Requests for refunds must
be received by Nov. 15.  Fees include 3 continental breakfasts, 2 lunches, and
the Proceedings.

Dietary requests:  vegetarian ______  Kosher ________  Other?  ________

SEND THIS FORM WITH FULL PAYMENT TO:
Judith Burgess / EL266, SRI International, 333 Ravenswood Ave.,
Menlo Park, CA 94025, USA

For further information, contact Judith Burgess,
burgess@csl.sri.com phone: (415) 859-5924, FAX (415) 859-2844

NOTE: REGISTRATION BY EMAIL OR FAX IS ALSO PERMITTED (ONLY WITH CREDIT CARD)a.
(RISKS FORUM READERS MAY PREFER TO TRANSMIT CREDIT CARD NUMBERS BY PHONE OR FAX
OR OTHER OUT-OF-BAND MEDIUM IF YOU PREFER NOT TO SEND IT ON-LINE!)

 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

          FAIRMONT HOTEL RESERVATION FORM
    SIGSOFT '91 — Software for Critical Systems
          New Orleans, Dec. 4 — 6, 1991

Name _________________________________________________________
Affiliation __________________________________________________
Address ______________________________________________________
City, State and Zip __________________________________________
Phone (and FAX) ______________________________________________
Date/Time of Arrival _________________________________________
Date/Time of Departure _______________________________________

Room Rates (subject to taxes):

Circle one:                Single $99         Double/Twin $119

RESERVATIONS: 1-800-527-4727 or 1-504-529-7111

To guarantee your reservation by credit card:

Circle one: AMEX     MC     Visa    Carte Blanche  Diners Club

Name on card _________________________________________________
Card number ___________________ Exp. date ____________________
Signature ____________________________________________________

These rates apply from Nov. 29 through Dec. 8, subject to availability.
Reservations must be received 30 days in advance.  A deposit for the first
night must accompany your reservation to guarantee it for arrival after 6:00pm.
Cancellations must be made 24 hours in advance.

SEND THIS FORM TO:
The Fairmont Hotel, University Place, New Orleans, LA 70140, USA

 = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

For further information on the conference, contact Judith Burgess.  The General
Chairman is Mark Moriconi, Computer Science Laboratory, SRI International, Room
EL-249, 333 Ravenswood Ave., Menlo Park CA 94025-3493 (phone 415-859-5364,
Internet moriconi@csl.sri.com).  Program CoChairs are Peter G. Neumann at SRI,
Room EL-243 (phone 415-859-2375, Internet neumann@csl.sri.com) and Nancy
Leveson of the University of California at Irvine (currently on sabbatical at
the University of Washington, phone 206-543-1695, Internet
leveson@cs.washington.edu).  The Program Committee consists of David Barstow
(Schlumberger), Dines Bj/orner (Technical University of Denmark), Marie-Claude
Gaudel (Universite de Paris - Sud), Jim Horning (DEC Systems Research Center,
Palo Alto CA), Bill Howden (University of California, San Diego), Hermann
Kopetz (Technical University of Vienna), Carl Landwehr (Naval Research
Laboratory), Bev Littlewood (City University, London), Leon Osterweil
(University of California, Irvine), David Parnas (McMaster University,
Hamilton, Ontario, Canada), Fred Schneider (Cornell University), Vicky
Stavridou (University of London), Martyn Thomas (Praxis, Inc.), Walter Tichy
(University of Karlsruhe), and Elaine Weyuker (NYU Courant Institute).

Johnette Hassell, Tulane University, is managing Local and Travel Arrangements.
[Judith Burgess is handling just about everything else, and all questions
should be directed to her.]

Please report problems with the web pages to the maintainer

x
Top