From: rdd@cactus.org (Robert Dorsett)
Subject: Re: A320/automation...
Keywords: A320, 747-400, FMS
Organization: Capital Area Central Texas UNIX Society, Austin, Tx
Date: Sun, 26 Jul 1992 23:43:26 GMT

Yet MORE comments...

In article <1992Jul26.180312.14995@en.ecn.purdue.edu> dominop@en.ecn.purdue.edu
(Philippos A. Peleties) writes:

>>This is debatable.  The alpha-floor protection kicked in around 9 degrees
>>AOA, countermanding his pitch command.  The "static" alpha-floor AOA is
>>around 15 degrees.  Rather than interpret the pilot's *instantaneous* 
>>pitch-command, it was integrating it over time, anticipating the result.
>>As described by Airbus, this feature is intended to accomodate any 
>>control problems an excess rotational momentum may cause.
>>
>
>It sounds like an anti anti-lock brake argument :-)

Not really.  Anti-lock breaks are demonstrably effective in enhancing
control and reducing stopping distances, and have been shown so in vir-
tually every application, from airplanes to cars.  The A320's FBW, however,
has not been demonstrably effective in enhancing control of the aircraft or 
improving safety, neither theoretically nor in reality.  There is reason
to suspect it may actually retard each factor, *despite* possibly being
a more logical approach to aircraft control, an outgrowth of recent theories
on "managed" flight.


>>Airbus' Bernard Ziegler said the airplane was in a "black hole" from which it
>>couldn't recover.  I question whether a system which had provided instan-
>>taneous access to max-AOA (without slowing down the pitch-command) *and*
>>with even the marginal engine-power at spool-up, couldn't have "zoomed"
>>the 20 feet required to avoid the trees.   Now, at this point, one would
>>ask, even if this were *possible*, whether it could be done with conventional
>>flight instrumentation (i.e., no AOA indicator); perhaps not.
>>
>
>So what are you saying? That the aircraft had sufficient energy to avoid the
>tree tops and go on from there with eventual recovery? If this were possible 
>but could not be done with conventional flight instrumentation, then ... what
>is your point?

"Perhaps not" should not be construed as meaning I believe this to be the
case; it only indicates that I'm aware of the opposing view--or would you
rather that my comments be even more one-sided? :-)  By indicating I under-
stand the opposing viewpoint, I hope that I'm saving concerned proponents
the time to point out something I already know. :-)

Incidentally, by "conventional" in the cited paragraph, I was referring
to speed-altitude-horizon-based displays, whether electromechanical or 
EFIS.

At any rate, *I* would ask, besides the lack of AOA training (and WHY aren't 
such devices used on all airliners?!) is whether a "stick and rudder" pilot 
could have more effectively flown a *conventional* control interface, in the 
same situation, and saved the airplane.  'Course, flying the A320 for six 
months would kill *any* pilot's basic flying skills. :-) (yes, that WAS a 
dig)


>Which more points to the irresponsibility of the whole exercise of flying low,
>dirty with 130 passengers. It is not unreasonable to think that the pilots did
>indeed put the plane in a situation where it was not physically possible to
>recover, A320 or otherwise. I think from the three crushes *this* one is the
>least suspicious one from the aircraft's perspective (IMHO).

I agree!  I disagree with the assertion, however, which is what I was 
originally replying to, that the airplane "saved" the airplane or minimized 
the crash damage.  This was the Airbus line from day *one*, and is rather 
specious, IMHO.  Quote facts, not scared company propaganda.


>Not an excuse but a reality. Training is almost *always* used to mask out
>*perceived* system inefficiencies. It is a matter of degree at this point not
>whether it is/should happen.

A good design can pre-empt the need for intense conditioning.  In the 1940's,
three heavy aircraft--the B-25, C-47, and C-82-- had three different throttle/
mixture/prop-pitch controls, which exchanged the location of the various 
levers.  The solution was to standardize the control layout and feel, not 
re-train the pilots--many of which had experience in prior models--to adapt 
to a non-standard dumb-ass design.  The lack of any interest in doing so is 
highly indicative of the strength of the "fix it in training" mentality of 
manufacturers and operators.  And the lack of *any* interest in retrofitting 
airplanes with better interfaces (a relatively costly process, probably 
*more* costly than a "just get it to work" training-based approach).  This 
mentality extends from cockpit issues right on down to cargo doors.

To a limited extend, the cockpit environment can be "handled" by measures
like this.  And, due to the awesome lack of standardization of modern
airplanes, it's often necessary.  I draw the line at flight control systems,
however.  That *interface*, at least, should be elementary and simple, with 
one control law, as instinctive to a 50-hour private pilot as it is to a 
30,000 hour 747 captain.  


>What is in your opinion a *justifiable* reason from introducing a new design
>(more, next level of technology) whether in aircraft design, automobile design,
>etc (aside from fixing a previous problem)? Do you support the ex-Soviet
>approach (the approach might still not be ex- mind you :-) ) of pushing a
>given (current) technology to its limit before we jump to the next generation
>one?

Let's look at this from a software engineering perspective.  If a program
need only search for simple character strings in a block of data, one 
simply does not *need* to code for the pattern-recognition capabilities
of, say, awk.  A ten-line function can do the job just as well.  Having 
awk's capabilities in the program, though, may help *sell* it.  

However, from the user's perspective, the awk approach is more complex and 
difficult to learn; it's different from how the user has always viewed the
use of such features.  From *management's* perspective, the increased 
frequency of mistakes by the users using the awk-based program might be cause 
for concern.  But if the program is *purchased* by *administration* types, 
who are required to fairly evaluate competing products, and who tend to choose 
the more feature-ridden, or more "fancy,", the awk program is the one that 
gets purchased.  Thus, many programs tend to suffer from "feature-ism",
to compete against other programs.

The fact that simple pattern-matching is more appropriate for this 
application doesn't mean the "awk" approach has no merits.  Nor does it mean 
that we're "stretching" the old-fashioned "string-matching" method to its 
limits, as you imply.  How can you stretch something if the application
*purpose* is identical to those that preceeded it?  We can only say that, 
for this application, string-matching is best.  In an academic environment, 
flexible pattern-matching might well be desired.


Conventional flight control generally works.  Do it by FBW or do it with
cables and hydraulics: the result is the same.  Change the way the basic
control model works, and you're throwing away decades of experience.  Just
like that.  

(for the uninitiated, awk is a text pattern-recognition "langauge").





---
Robert Dorsett
rdd@cactus.org
...cs.utexas.edu!cactus.org!rdd