Re: over-automation with glass cockpits

From:         Don.Stokes@vuw.ac.nz (Don Stokes)
Organization: Victoria University of Wellington
Date:         08 Aug 96 12:11:50 
References:   1 2 3 4
Next article
View raw article
  or MIME structure

In article <airliners.1996.1597@ohare.chicago.com>,
Francis JAMBON <Francis.Jambon@imag.fr> wrote:
>In article (Dans l'article) <airliners.1996.1567@ohare.Chicago.COM>,
>don@firstsol.com (don shifris) wrote (crivait):
>
>>My other concern is over 'bugs' in this stuff. I have worked in the
>>computer industry for a long time. People are taught to solve specific
>>problems in specific ways. The Airbus approach is to use seperate teams,
>>and seperate hardware to insure this doesn't happen. The problem is that
>>since these people tend to be educated the same way, they tend to solve
>>the problem the same way, so it is very likely that the same, possibly
>>bad, underlying assumption were used in all solutions.

>Airbus use a very clever way (IMO) to solve this. Each (of three) FBW
>computer are made of two computers of differents architectures : one with
>a Motorola (68000 maybe), the other one with an Intel (8086 or 8088 ?).
>The two parts of the computers are made by differents teams and, to avoid
>communication between the teams, different manufacturers : Thomson and
>Sextant.

The point remains.  Heck, I use the _same_ code on different computers
with different architectures and even different operating systems, with
only minor if any changes -- the differences in the systems doesn't
change the picture much at all.  Even using different languages, one can
use the same algorithms.  What using different architectures means is
that you're unlikely to get the same erroneous sequence of instructions
from some common compiler bug cropping up, but little better than that.

Somewhere in my cookie file is the quote:

	For every complex problem, there is a solution that is simple,
	elegant, and wrong.

As long as you are trying to achieve the same thing, you're going to have
to use, out of necessity, use the same or at least similar algorithms,
and two people can jump to the same erroneous conclusion.

I'm not saying that the multiple systems approach is invalid.  I am
saying that one should _not_ rely on it alone to produce correct code.
Formal methods should _also_ be used.

>the same time. These method are not used by all manufacturers, for example
>the fighter Rafale build bay Dassault have two identical computer with
>identical software for performance. They use formal specification and some
>proofs to made them. Never forget that in a fighter you may use the
>ejectable seat :-)

You _don't_ want to use the ejection seat.  An ejection seat is something
that you use when faced with the prospect of certain death if you remain
with the aircraft, as opposed to probable death if you bail out.  They're
fitted into combat aircraft simply because flying a combat aircraft is
_dangerous_ -- in combat you have human beings actively out to destroy
your craft, something commercial pilots generally don't have to deal
with.  The nature of making an aircraft maneuverable enough for combat
also makes it more susceptible to failure.  For example, fighters and
small bombers glide like bricks whereas any commercial transport can be
safely deadsticked to a landing (given a suitable site and a certain
amount of luck).


--
Don Stokes, Network Manager, Victoria University of Wellington, New Zealand.
don@vuw.ac.nz(work) don@zl2tnm.gen.nz(home) +64 4 495-5052 Fax+64 4 471-5386