<underline>A simple and practical view:
</underline>
Having lived (as a user) with the A330/A340 version of Automation for
some years, I can vouch for the "love" bit, but also suggest that any
pilot who "wants" to be in control, NEVER allows her/himself the luxury
(during critical flight phases) of thinking "what's it doing now?";
rather "if in doubt, take it out". The designer has allowed for this at
all levels of automation, and the pilot knows h/she always has control.
There are some design features of course which have now been accepted as
part of the furniture, such as engine acceleration control units (60s),
engine top temperature/overspeed limiters (60s), antiskid (60/70s), and
fly by wire envelope control (70+s), which all contribute to safety, but
"limit" human control in the traditional sense. Such features reduce the
unpredictability of human skill-dependence, but do not limit the ability
of the human to manage the flight through the full mission of an airline
flight.
On these aircraft there is still much to do in flight deck design, but in
my opinion, improvement can now come in panel/keyboard locations rather
than fundamental
conceptual change.
In designing automation as the "third pilot", "unconditional love for
automation" will naturally be tempered with "healthy respect for failure
potential", just like any succesful Capt/FO (and vv) relationship!
John Bent
Cathay Pacific
At 02:29 PM 12/2/97 U, you wrote:
>
> RE>>Unconditional Love of Automation!
12/2/97
>
>Actually one can define with engineering precision what *...being in
control
>means* according the theoretical framework provided by Perceptual
Control
>Theory (PCT). PCT claims that humans (and indeed any goal driven
organism)
>are controllers (in the full force of the engineering sense). They take
in
>sensory information, transform those data into a percept, compare the
percept
>to a goal and generate some action/decision in response to the error
state
>(requiring another transformation process) to change the state of the
world
>(or at least some world variable(s)) so that the perception is made to
match
>the goal. This completes the feedback loop. To be in control means
that you
>are actively controlling the variable(s) in question (error nulling) and
that
>requires the attentional mechanism to be focussed on that variable(s).
If you
>are not attending you are not controlling. PCT shows us how we are so
>succesful even though our mental models are imperfect as long as we do
not
>drop feedback.
>
>So if the FMS is controlling altitude, the human is not, at least at the
same
>low level that the FMS is. The human can be considered to be
controlling at a
>higher (monitoring) level and would intervene if the error state
exceeded a
>certain level (due to FMS failure or finger trouble in setting up the
AP).
>This is not the same loop the FMS is controlling, unless you are hands
on and
>fighting the FMS. It is easy to show the unstable control that results
form
>this type of multi-controller action. Whatever control loop you are
going to
>give the human must be designed for (give the appropriate sensory input
and
>allow the appropriate control actions). This whole process can be
formalised
>in the sense of a classic action information requirements analysis or
similar
>procedure. The bottom line is that you can go about this in a rational
(and
>even logical :-) way. Yes there is still room for design induced error
but
>you can capture a lot more of the variance than a *finger in the air*.
The
>problem with many systems has been that the interface has not been
designed
>explicitly to support human control at the level they are expected to
operate
>(also a claim of the Ecological Interface Design proponents).
>
>The PCT model also provides insight into how various goal driven
devices
>combine as a team (a classic multi-controller system). One can tease
out the
>requirements for communication and leadership, role/task allocation,
absolute
>necessity of feedback (attention), common mental models, common goals
(only to
>the extent that the same variables are being potentially controlled by
the
>team players), authority gradient (loop gain) etc. The players can be
all
>machines, all humans, or humans and machines combined. The model does
not
>change. Everything we know about the stability of multi-controller
systems
>maps onto this situation regradless of the composition of the players.
The
>only difference with machines is that they are still show no signs of
>intelligent behaviour (now that could start a never ending thread), are
not
>particularly cooperative, are blindly obedient, are not good at sharing
their
>mental models and lower level goals, and do not fail gracefully (or does
that
>sound like a new hire).
>
>We have used this framework (PCT together with a model of the human
>information processor) to design a new training course (titled *human
factors
>in decision making*) to replace current CRM training in the CF CC-130
>community. The theoretical framework also provides prototype
assessment
>instruments which is a bonus. At the moment it is only a proposal and
has not
>yet been implemented. We hope to get that chance next year and to
formally
>assess the revised training against the current baseline.
>
>Some sidenotes.
>
>* the Information Processing (IP) model claims that performance,
error
>production and perceptions of workload are driven by time pressure (can
be
>reduced to the ratio of the amount of information to be processed to the
time
>available).
>* the IP model claims that all factors that effect workload can be
reduced
>to either there effect on the amount of information to be processed or
the
>time available before the decision has to be actioned.
>* the PCT and IP models combined integrate the concepts of workload,
>performance, error production, situation assessment, and situation
awareness.
> They show how they are related and get over all the old probles of
explaining
>how SA can be either high or low under either high or low workload.
>* my best model for the human is that of an adaptive fuzzy,
bandwidth
>limited, controller (at least at the level we are generally dealing
with).
>
>While beauty may be in the eye of the beholder some of us find this
framework
>to be an extemely powerful HF tool. BTW there has been a brave attempt
to
>validate both the IP and PCT models. They are not just the product of a
late
>night over a bottle of Oban - might have been where the original idea
for the
>IP model came from now I come to think of it!
>
>
>Keith Hendy
>DCIEM, North York, CANADA
>--------------------------------------
>Date: 12/2/97 1:16 PM
>To: Keith Hendy
>From: Raymond A Hudson
>Received: by gatormail with SMTP;2 Dec 1997 13:16:18 U
>Received: from arcturus.uneec.eurocontrol.fr by hermes.dciem.dnd.ca
>(4.1/SMI-4.1) for Phil_Farrell_at_gatormail;
> id AA28650; Tue, 2 Dec 97 13:13:04 EST
>Received: (from majordom_at_localhost) by arcturus.uneec.eurocontrol.fr
>(8.7.1/8.7.1) id LAA04351 for bluecoat-list-raw; Tue, 2 Dec 1997
11:36:21
>-0500 (EST)
>Received: from advgwy.mdc.com (ADVGWY.STL.MO.BOEING.COM [130.38.139.67])
by
>arcturus.uneec.eurocontrol.fr with ESMTP (8.7.1/8.7.1) id RAA04347 for
><<bluecoat_at_bluecoat.eurocontrol.fr>; Tue, 2 Dec 1997 17:36:11 +0100
(MET)
>Received: (from x400_at_localhost) by advgwy.mdc.com (8.7.1/8.7.1) id
KAA23483
>for bluecoat_at_bluecoat.eurocontrol.fr; Tue, 2 Dec 1997 10:37:19 -0600
(CST)
>X-Authentication-Warning: advgwy.mdc.com: x400 set sender to
>raymond.a.hudson#064#boeing.com_at_mail.mdc.com using -f
>Received: by TELEMAIL; Tue, 2 Dec 1997 8:27:08 -0800
>Date: Tue, 2 Dec 1997 8:27:08 -0800
>From: Raymond A Hudson <<raymond.a.hudson#064#boeing.com_at_mail.mdc.com>
>Subject: Re: Unconditional Love of Automation!
>To: bluecoat_at_bluecoat.eurocontrol.fr (IPM Return Requested)
>Message-Id: <<"971202163616Z.WT22905.
>43*/PN=Raymond.A.Hudson/OU=C363550/OU=SLLN/O=McDonnell
>Douglas/PRMD=MDC/ADMD=TELEMAIL/C=US/"_at_MHS>
>X-Mailer: Worldtalk (NetJunction 4.5)/STREAM
>Sender: owner-bluecoat_at_bluecoat.eurocontrol.fr
>Precedence: bulk
>
>Once again, I "fat fingered" the response I wanted to quote!
>(You see, automation bites each and every one of us every day!)
>
>Ron Rogers wrote (paraphrased) :
>>...the pilot must remain in control and in the loop.....
>
>A great statement, and I am sure there is no one out there who would
>disagree with you. But to help us all understand the problem in
>satisfying such a requirement, let me ask for what should be an
>obvious clarification :
>
>Please define (with engineering precision, so I can design to it) what
>it means to be "in control". Herein lies the rub. "Control" is a
nebulous
>(dare I say FUZZY?) concept. Are you "in control" when the A/P is
>engaged in cruise? No, not technically. You have override authority
>but at the moment the A/P goes on you are not "in control", the
machine
>is. Are you "in the loop"?...well, yes, but not as much as if you were
>hand flying.
>
>No level of automation will ever be able to meet the requirement that
>the pilot is "always in control". It wouldn't be automation if it
did!
>Bert Ruiterkamp brought up the timely topic of how we "manage"
>systems. Once you engage the automation, you BECOME a
>manager...no two ways about it!
>
>Again I point out that it might behoove us to continually think of any
>automation as "another crew member" (from both a design and
>a CRM standpoint). How does a line CAPT "manage" his F/O,
>and more importantly, shouldn't s/he be able to "manage" the
>automation in the same manner? We should NEVER design any
>system (although we have in the past) that cannot fit the CAPT/FO
>CRM "model". This just sets-up the causal chain that leads to
>"what is it doing now?". In fact, it may behoove us as designers
>to assume the "what is it doing now?" question for every complex
>feature we design-in! The sooner we provide a means for the
>automation to answer such questions (don't laugh! it IS possible)
>the sooner we can achieve pilot/automation levels of CRM that
>come close to matching human/human CRM.
>
> The only "hitch" here is that (today) the automation is not
"conversant"
>.....you can't figure out "what's on its mind"....it was not designed to
>answer questions, only to perform its automation function......
>Some of us are working to solve that problem, but we need help
>from the system users AND the system maintainers! ;-)
>
>As always....not meant to enflame, only to "enthink"! :-)
>
>Raymond A. Hudson (Rainman)
>Principal Engineer
>MD-11/MD-10 Automatic Flight Systems
>Boeing - Douglas Products Division
>
>
>====== Bluecoat Mailing-list : bluecoat_at_bluecoat.eurocontrol.fr
========
> To change your address or be removed from the list, send mail to
> Jim Messina <<jmessina_at_bluecoat.eurocontrol.fr>
> else mail majordomo_at_bluecoat.eurocontrol.fr with words info
bluecoat
>see also http://bluecoat.eurocontrol.fr
http://www.neosoft.com/~sky/BLUECOAT
>
>
>
>