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…
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.
gj
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
> 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)
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
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
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
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 computerization. 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.
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.
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 martin%ucscb.ucsc.edu@ucbvax.berkeley.edu
[Deburred in the hand is worth 3 Bills in debrush. PGN]
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