Re: Boeing 777 - Totally Irresponsible?

Date:         27 Dec 96 19:09:40 
From: (Robert Dorsett)
Organization: Netcom Online Communications Services (408-241-9760 login: guest)
References:   1 2
Followups:    1
Next article
View raw article
  or MIME structure

In article <airliners.1996.3056@ohare.Chicago.COM> (MegaZone) writes:
>The military has been using FBW for many years now.

The military flies airplanes with ejection seats.  As I'm sure the pilots
of the JAS-39 Gripen are very glad.

>He better not fly on any modern Airbus either then - they are FBW.


>Both the 757 and 767 have electronic flight management systems.

Not considered part of the flight control system.

>See, it's called redundancy.  Most of the time there are at least 3, usually
>4 or more, systems for each task.  And on critical cases different software
>is run on the different systems.  So that you can *never* have a single
>point of failure in the code cause a crititcal failure.

Specification errors can and do cause code failures in dissimilar
redundantly designed systems.

>You would have to
>have *all* systems fail in the same way at the same time, despite the
>different code.  The odds of that are incomprehensible.

Higher than you might think.  I'm sure Ladkin or Mellor will jump in
with references.

>Take the Space Shuttle.  It has 5 main computers.  To my knowledge there
>has never been a simultaneous failure that threatened a mission due to

I recall at least a few failures during the early years in which missions
were delayed because of "voting" failures.  If the mission involves the
deployment of a time-critical satellite, then, yes, I suppose
that such a failure, even if not involving vehicle loss, could be
construed as "threatening the mission."

>No one is stupid enough to fly an airfraft with FBW without redundant systems
>and with the possibility of universal code failure.

The best we can do is the state of the art.  The question is whether the
state of the art--the vast complexities of digital control systems, process
issues, etc--is as good as what it is replacing.

The 777 vs. Airbus is a good example of this.  The Airbus approach
seeks to guarantee safe flight by the combination of two types of computers,
elevator and aileron control computers (ELACs) and spoiler and elevator
control computers.  Each computer is split into two channels an operational
mode and a "supervisory" mode.  Each channel uses different microprocessors
and code written in different languages.  Moreover, the ELACs and SECs use
different microprocessors (thus safeguarding against MPU bugs, which also
occur).  The design teams implementing each type of computer were segregated,
only operating from common specifications.

Thus, two high-level languages (C and Pascal), two low-level languages
(68000 and 80x86 assembler) and two processors were used to establish

This was the state of the art in the 1980s, and it seems thorough to me.
Since then, understanding of failure modes has progressed.  The 777 does
not use dissimilar software (at least, not to this extent).  The idea there
is to do it right, rigidly test it, and keep it as simple as possible.

So by your own argument, it would appear that the 777 is "less safe"
than its predecessors.

Perhaps, rather than cite examples from the military world, where risks--
many of which would be completely unacceptable in the peacetime world--
occur on a regular basis, both in wartime AND in peacetime, it would be
better to focus on the fact that software engineering is in its infancy.
Whereas physical flight control systems have been around for nearly a
hundred years, and the engineering standards contributing to them have been
around for millennia, software is new.  Safety cannot be trivially guaranteed
by processes, good management, or even design.  Each new iteration carries
risks, which the implementors no doubt inflict in good faith.  And the
complexity and responsibility of software continues to increase.

We are nowhere near the ideal of a "gold standard", which we can point to
and say "THIS is the way it's done."  We're still on the learning curve.
A brand new learning curve.  It's a learning curve that will be hard-
fought, and that will by necessity be very proprietary, very institutional.
The lessons and processes will stay with their originators, and will not
be shared.

>Livingston Enterprises - Chair, Department of Interstitial Affairs
>Phone: 800-458-9966 510-426-0770 FAX: 510-426-8951
>For support requests:  <>
>Snail mail: 4464 Willow Road, Pleasanton, CA 94588

Robert Dorsett                         Moderator, sci.aeronautics.simulation