Subject: Re: TV programme on 777

From: Robert Dorsett <[email-masked]>
Date: Fri, 20 Nov 92 15:46:39 CST

In article <[email-masked]> [email-masked] (Randolph Bentson) writes:
>Boeing is _very_ reluctant to use fly-by-wire.  Management
>trusts computer solutions no more than members of this forum.  I
>got the impression that this system has a pilot override as part
>of it's basic design.  (A sort of "do what I say, not what you
>think I want" mode.)

As I understand it, the FBW system is the only way the pilots can signal
the actuators.  Boeing is simply providing a "conventional" control law and 
interface, with "protections" that can be over-ridden by the pilot, if
necessary.  Redundancy/backup is at the hardware level, not in alternate
select modes.

So, rather than a simple joystick, Boeing's "simulating" a conventional 
interface, with feedback, in the cockpit cab: each control column inter-
connected with the other, each providing tactile feedback.  The FBW is there, 
one way or the other.

On the other hand, I do think it's a positive step that Boeing's not "re-
writing" the book by offering *artificial* control laws, as Airbus is doing.
Thus, to override the protections, the pilots just need to push or pull
*harder,* or click an overrride button: they don't have to deal with or 
anticipate the effects of *four* distinct control law modes, and the many 
permutations within each mode, depending upon system status, as is the case
with the A3[2-4]0.

---
Robert Dorsett
[email-masked]
...cs.utexas.edu!cactus.org!rdd

---

From: [email-masked] (Michael T. Palmer)
Date: 01 Dec 92 13:54:51 PST

>necessary.  Redundancy/backup is at the hardware level, not in alternate

[etc]

>permutations within each mode, depending upon system status, as is the case

This is correct, and highlights a very important distinction between the
approaches to flight envelope protection being taken by Boeing & Airbus.
The B-777 will have protections, but as you noted the crew can override
them by using excess force on the control column.  So, the airplane will
make it more difficult to do something it thinks shouldn't be done, but
will always leave the final decision to the crew.  In contrast, the
protection on the A320 *cannot* be overridden - you either get switched
into an alternate control mode, or your inputs are ignored.

This has some serious consequences.  For example, in the China Airlines
B-747 incident 300 nm northwest of San Francisco in 1985 (NTSB/AAR-86-03),
the crew was forced to overstress (and structurally damage) the horizontal
tail surfaces to recover from a roll and near-vertical dive following an
automatic disconnect of the autopilot when it could no longer compensate
for an asymmetric thrust condition.  At the time of disconnect, full
rudder was engaged to one side and the crew was unaware of this.  The
crew recovered control with about 10,000 ft of altitude left (from an
original high-altitude cruise).  It is very likely that if the aircraft
had prevented the crew from initiating control commands that would lead
to aircraft damage, the aircraft (and passengers) would have been lost.

Unfortunately, it appears that engine manufacturers may be heading down
the same path as Airbus with respect to their electronic engine controllers.
I can't remember which engine it was, but I remember reading that when
the controller detects a condition for which the proper action is to shut
the engine down, it will do it itself AND THE CREW CANNOT OVERRIDE THIS
ACTION.  Now, this may seem like a good idea on paper, but remember the
Eastern L-1011 out of Miami in 1983 (NTSB/AAR-84-04) with the triple
engine failure because the oil seals were missing?  Can you imagine the
tragic result if the engines had ALL detected this condition (in flight)
and shut themselves down?  It seems to me that letting the crew decide
to sacrifice an engine to save the airframe is probably a good idea.

If nothing else, I hope I have brought up some topics that deserve
discussion among readers of this newsgroup.  After all, aren't we the
ones in positions to influence our industry (all in our own way, of
course)?

-- 
Michael T. Palmer, M/S 152, NASA Langley Research Center, Hampton, VA 23681
Voice: 804-864-2044,   FAX: 804-864-7793,   Email: [email-masked]
PGP 2.0 Public Key now available -- Consider it an envelope for your e-mail

---

From: [email-masked] (Robert Dorsett)
Date: 02 Dec 92 13:18:55 PST

[email-masked] (Michael T. Palmer) wrote:

> the crew was forced to overstress (and structurally damage)
               ^^^^^^

That might be overstating the case a bit. :-) The NTSB report suggests
they didn't have a clue how to recover from the spiral, once they entered
it, lacking military aerobatic training and being completely disoriented.  I
don't believe the report distinguishes the tailplane's damage as being
incidental or intentional.

> the horizontal

Your point's well taken, and the risks are certainly worth considering.  But
allow me to play devil's advocate, for a minute, without diluting your argu-
ment, and suggest that the EFCS would have prevented an A3[2-4]0 from getting
into the unusual attitude to begin with.  The protections are both aerodynamic
and input-filtering (and configuration-evaluating, and...).  In the China
Air incident, the flip-over was caused by a "dumb" autopilot/autothrottle
design configuration oversight, following an engine abnormality.  If a similar
event had occurred on an A3[2-4]0, the EFCS would probably have limited both
the authority of the FMS to put the airplane into the steep bank, *and* would
have provided maximum corrective action, using opposing controls, to keep the
airplane in the prescribed operating envelope.

But let's suppose some other kind of fault flips the airplane over: rotor,
wake turbulence, transient EFCS bug (REALLY unlikely).  I would have less
confidence in the system than in a 747, but there are saving graces in the
system design.

During the flip-over itself, the system would have reverted to Alternate Law
when one of these conditions were met:
    Pitch > 50 degrees nosePup or < 30 degrees nosePdown.
    Bank > 125 degrees.
    AOA > 30 degrees or < P10 degrees.
    Speed > 460 knots or < 60 knots.
    Mach > 0.91 or < 0.1.
There would not have been protections or auto-trim; there would have been
full-authority direct law in roll, without yaw-damper services.  It is not
clear whether "device-saving" protections would have been in place (likely,
no doubt, considering the extensive use of composites in the tail surfaces).
(don't forget: you have to remember all this when the shiny side's the wrong
way up :-))

I also wonder how well the four accelerometers the EFCS uses would have
held up to all this.  No matter: they're durable.

A320 simulators use pretty much the same EFCS code as the actual airplane.
Since programming errors often show up in 90-degree increments (tan 90!),
I suspect it would be interesting to turn off the motion system and take
the thing up for a spin, so to speak... :-)

More grist for the mill:

In an unnamed regulatory agency's commentary on a paper that Pete Mellor and I
are cooking up, there was a note that in the case of even a
"run-away" surface (actuator OR software malfunction), the remaining devices/
governing software would function to provide a "virtual" effect, providing
handling qualities that would mask the abnormality.  I was aware that a
"make-up" feature existed, but the precise wording raises the question of how
much loading, exactly, the run-away surface might introduce, or how violent
an oscillation the system could be trying to cover up.

I find this *quite* disquieting, especially since, in the FAA's Special
Conditions for the A320's certification in the United States, the point was
clearly made that the FAA does *not* believe the pilots have a right to be
warned of failures of this sort:

This is from the Federal Register 54:17, January 27, 1989, pages 3989 and
3996:

P. 3996: paragraph 2(a)2(i), the item under discussion: active controls, basic
criteria, with the system in failure conditions:

    "(i) Warnings must be provided to annunciate the existence of failure
    conditions which affect the structural capability of the airplane and
    for which the associated reduction in airworthiness can be minimized by
    suitable flight limitations.  Failure conditions which affect the
    structural capability of the airplane and for which there is no
    suitable compensating flight  limitation need not be annunciated to the
    flightcrew, but must be detected before the next flight."

P. 3989, the oh-so-enlightening, explanatory commentary:

    "The second commenter believes that the flightcrew must be aware of any
    failure conditions which affect the structural capability of the
    airplane, whether or not a compensating procedure exists.  The FAA does
    not concur with this comment.  It is not necessary for the flight crew
    to be aware of a failure in the active control system during the flight
    on  which the failure occurs if there is no available corrective
    action; however, the airplane should not be exposed to the failure
    condition for an extended period of time.  The flightcrew must
    therefore be alerted to the failure condition prior to the next flight."

This is from the FAA, the agency in charge of establishing airworthiness and
certification practices in the United States!  In reality, the A320 likely
*does* provide enough feedback: but the FAA, apparently unnecessarily, has
certainly opened the door for the practice to be introduced in subsequent
types.

> the same path as Airbus with respect to their electronic engine controllers.

Beyond "dumb" smartness, Pete Mellor has uncovered reason to believe
the engine controllers do not use dissimilar software.  On the A320, there
are two FADECS per engine: a common-cause-of-failure logic fault could con-
ceivably take out both controllers.  It's not clear whether this could happen
in tandem, based on environmental conditions, or serially, which could intro-
duce a short timing delay in which the input parameters could be "corrected."

> ones in positions to influence our industry (all in our own way, of

Especially in software, of particular relevance to the net.  A lot (if not
most) of the people writing this code--4M on the A320, 10M+ on the
A330 and A340--are *not* aero engineers: just programmers, ostensibly with
CS backgrounds (a more frightening thought I can't imagine! :-)), performing
under strictly governed, structured, controlled environments: to specif-
ication.

Airbus even mentioned the "CS" types it brought in from "outside" to
buttress a comment on its quality-control practices, in an article, as if
to make the point that mere engineers weren't writing this stuff: the
"pros" are doing it. :-)  Yeah, we know what we're doing, SURE... :-)

Computers on the brain...

Alphabet soup:

AOA     Angle of Attack
CS      Computer Science
EFCS    Electronic Flight Control System
FADEC   Full-Authority Digital Engine Control
FMS     Flight Management System
M       Megabyte
NTSB    National Transportation Safety Board

---
Robert Dorsett
[email-masked]

---

From: [email-masked] (Michael T. Palmer)
Date: 04 Dec 92 22:30:33 PST

>incidental or intentional.

Agreed.  I didn't mean to imply necessarily that they KNEW they needed to
overstress the airframe, and it is *possible* that this occurred during
control inputs that did not actually contribute to the recovery.  It's been
awhile since I read that report, and I didn't have it handy to refer to.

>airplane in the prescribed operating envelope.

Well... given the recent post here about the A310 in Moscow going 88 degrees
nose-up, I'm not sure that I agree that the Airbus EFCS would necessarily
prevent the aircraft from attaining "unusual" attitudes.  In fact, it was the
"smarts" of the A310 autopilot that actually contributed to that incident.
As that poster also mentioned, though, I would like VERY MUCH to see more
documentation and a fuller description of exactly what happened.

>    therefore be alerted to the failure condition prior to the next flight."

Oh, I get it!  Just because a condition exists that may affect OTHER choices
I make about how to respond to OTHER occurrences during that flight, that
doesn't mean that I have the right to know what is going on with my aircraft.
Hmm, seems reasonable... NOT!

>certainly opened the door for the practice to be introduced in subsequent

I agree completely.  I work in the Human/Automation Integration Branch in
the Flight Management Division at NASA Langley.  We have worked for some
time examining the complicated interrelationships between events that lead
to accidents, and have even constructed software prototypes that try to
determine these relationships and make them more explicit.

What really scares us is the prevalent attitude of many in the industry
that they can anticipate ALL the "important" ways that things will interact,
and provide procedures for dealing with them.  And whenever you point to
an example of how they failed and how that lead to an accident, they respond
"Oh, but we've already fixed that."  Sure.  But what about the NEXT one
that you haven't "fixed" yet!?!

By the way, the charter of our organization (as if you couldn't tell from
what I've said so far) is NOT to solve problems in the cockpit by increasing
the amount of automation.  Rather, we seek to propose better ways of using
the capabilities of both the automation and the flight crew, which may even
mean rethinking many of the traditional tasks that automation is used for
now.  And we do NOT see the "pilot as manager" scenario as being necessarily
ideal.  Humans tend to make lousy system monitors.  Ask the Nuclear people.
Human-machine systems work best when the humans are actively *involved*.

>"pros" are doing it. :-)  Yeah, we know what we're doing, SURE... :-)

Ummm... this point came up in a Newsweek article (now THERE'S an accurate
and unbiased source of information!) about digital flight control systems.
They were shocked that programmers, not pilots, were writing the software.
I feel at least somewhat qualified to address this issue, since my undergrad
is Aerospace Engineering, my master's is Computer Science, and I'm working
on the Ph.D. in Human-Machine Systems.

Pilots and engineers tend to be experts in specifying how things should
happen.  My experience with their programming ability is that they tend to
not be aware of most of the advances in Computer Science that have occurred
over the past 25 years.  The result is poorly designed and implemented code
that takes Herculean efforts to get working properly and maintain.  On the
other hand, programmers do not necessarily make good system designers... they
tend to think in terms of how things will be implemented (and the limitations
of that implementation) rather than in terms of what the system MUST be able
to do.  I have met only a few people who can combine both talents, to become
very good system designers AND software designers.

These people have the ability to hear what the pilots and engineers say, and
translate that into a total system design, including software design, that
meets the requirements and can be implemented.  At THIS point, the actual
programmers become involved.  If changes need to be made due to, say, hardware
limitations, then these can be incorporated by either a requirements OR an
implementation change.

So, I don't think you should be afraid that CS people are writing the code.
In fact, you should be glad that they are.  You just need to make sure that
they are filling in the pieces of a software design that was put together
by a competent person like I described above.

>...cs.utexas.edu!cactus.org!rdd

I hope I get to meet you at a conference sometime soon!  It's great to see
that other people are grappling with the same issues.

---

From: ditka!sgiblab!acd4.acd.com!HDFS1.acd.com!jbii ( John O. Bell II )
Date: 04 Dec 92 22:30:34 PST

>A330 and A340--are *not* aero engineers: just programmers, ostensibly with
                                          ^^^^^^^^^^^^^^^^

I used to think that way as an AE grad, until I got my CS degree. Let's face
it, guys, most AEs don't even know where to _begin_ coding this stuff. They
don't have the experience or the background to make clean, fast, fault-
tolerant code for these kind of applications. However, it is true that the CS
types better have a good math/engineering background if they are going to
understand exactly what is required for the code. You can't be a specialist
in everything (much to the company's chagrin >:-)... "Darn, we gotta pay money
to those CS people too? I thought our AEs could handle this!").

Side Note: Every time I see some aerospace article talk about how engineers
           are becoming accomplished computer scientists, I laugh my head off.
           I've been on both sides of the tracks, and I know better. Doing
           scientific programming in FORTRAN does not make you a CS god.

>under strictly governed, structured, controlled environments: to specif-

Unlike the AEs, who are allowed to be creative, free-wheeling, loose cannons.
Shyeah, and I'm the Easter Bunny... unless you are a conceptual designer, you
are a glorified paper shuffler just like anyone else. Why do you think they
call Boeing "The Lazy B", anyway (just an example).

>"pros" are doing it. :-)  Yeah, we know what we're doing, SURE... :-)

Yeah, they do. Evidently the AEs on the project couldn't handle the task
or they wouldn't have hired CS types. Either that, or the code they were
putting together was such a spaghetti-mess of calls and gotos that they
had to get CS people just so they could trace and fix the bugs.

>...cs.utexas.edu!cactus.org!rdd

John Bell
[email-masked]
Applied Computing Devices, Inc.