Nof S.Y. Springer Handbook of Automation

Подождите немного. Документ загружается.

Flight Deck Automation 68.2 Application Examples 1225

vertical and horizontal τ) of a proximate aircraft is less

than the thresholds, the alert sounds. Otherwise, if the

closure rate is low, the alert will sound if both the hor-

izontal and vertical separation is less than the DMOD

(which is short for distance modiﬁcation) and altitude

thresholds, respectively. These thresholds for SL 3–7

are shown in Table 68.2.

68.2.3 Information Automation

Information automation is distinguished from other

types of automation as it is intended to provide in-

formation to support reasoning by the operator (as

opposed to supporting rule-based or skill behavior). In-

formation automation includes the most recent forms of

automation.

Automated Checklists

Electronic versions of checklists have been introduced

quite recently, including in the Boeing 777 [68.22,23].

These checklists reproduce, on a display,the stepsof the

checklist. As items are completed, they are presented

as completed after the item is actually completed (as

checked by automation, if possible).

Cockpit Display of Trafﬁc Information (CDTI)

A display of nearby aircraft is part of the ACAS system.

Such systems show aircraft within a certain range that

may pose a collision or separation risk. Along with rel-

ative bearing, their relative altitude, identiﬁcation, and

sometimes speed are shown.

A number of researchers have examined how such

displays may be utilized to improve the situation

awareness and conﬂict avoidance capabilities of pi-

lots [68.24–27]. Some have gone as far as suggesting

that such displays can be utilized (in part) to enable

ﬂight-deck-based separation, as opposed to separation

assured by centralized ground authorities such as air-

trafﬁc controllers [68.28,29].

In such displays, all aircraft within the range se-

lected for the display are shown, including all pertinent

information such as altitude and speed. An example is

showninFig.68.7.

There are some issues with CDTI,however.These

issues include displaying three dimensions on a two-

dimensional display, perspective issues, and clutter.

Because aircraft ﬂy in three dimensions, air trafﬁc

is nominally a three-dimensional task. However, air-

craft in cruise are stratiﬁed; they ﬂy at altitudes in the

whole thousands (35000ft, 36000ft, etc.). Because of

this, except when climbing and descending between

Fig. 68.7 NASA ﬂight deck display of trafﬁc information

(after [68.21])

these altitudes, an aircraft’s altitude is essentially a cat-

egory rather than a state. Moreover, it is treated as such

by ﬂight crews and controllers, who refer to aircraft

above 18000 ft (below which climbing and descend-

ing is more frequent) as being at a particular ﬂight

level (FL), which are measured in hundreds of feet.

So an aircraft at 35000 ft is referred to as being at

FL350.

In addition, the scales of horizontal and vertical sep-

aration are different by almost an order of magnitude.

Vertical separation is given in thousands of feet; hor-

izontal separation is given in nautical miles (just over

6000ft). It is not even possible to display these scales

simultaneously on a display and have the information

be adequately discernable. In order to create a three-

dimensional display of trafﬁc, one scale or the other

must bedistorted. For these reasons, air-trafﬁc control is

not typically addressed as a three-dimensional problem.

Designers of CDTI must also consider issues of per-

spective in displaying trafﬁc. Each perspective distorts

or obscures some aspect of the situation. A top-down

view (typically used in navigation displays) completely

eliminates relative vertical position, which is then of-

ten replaced by a text display of altitude. In general,

there is ambiguity in position information along the line

of sight of the display [68.30]. A display oriented to

the pilot’s perspective (referred to as immersed) elim-

inates information to the side, from behind, and from

above the aircraft. This results in a keyhole view of the

world [68.31].

Part G 68.2

1226 Part G Infrastructure and Service Automation

Researchers have shown that having the viewpoint

outside the ﬂight deck provides the best performance

for mapping between the world and display [68.32]. In

doing so, the principles of pictorial realism (the display

should be pictorially analogous to the real world) and

integration (related information should be integrated on

the same display) can be followed [68.33].

Heads-Up Displays

Heads-up displays (HUDs) and helmet-mounted dis-

plays (HMDs) were ﬁrst introduced in military aircraft

to reduce the amount of time a pilot spent looking in-

side the ﬂight deck. By positioning frequently accessed

information on a display that one could see through to

the world behind, pilots need only change the depth

of focus to extract information from the world or the

instrument, rather than moving the head, eyes or both.

Such displays are now ﬁnding their way into com-

mercial aircraft(and even automobiles). The advantages

of such a display are clear. For example, one can

easily integrate real-world information with displayed

information. Also, the HUD enhances the operator’s

ability to alternate between information at different

depths [68.34].

However, several disadvantages should also be

considered by designers. First, by superimposing infor-

mationontheworld background, the danger of clutter

increases. However, researchers have shown that pilots

are able to ignore the background information so that

no additional workload is imposed on the pilot [68.35].

Also, should unexpected eventsoccur, it appears that the

HUD may reduce the capacity of the operator to detect

these events, although it is not entirely clear why this is

the case [68.36].

Data Communications

Currently, most communication between air-trafﬁc con-

trol and ﬂight deck utilizes voice channels over

radiofrequencies. On commercial aircraft, communica-

tion between a company’s dispatch (called the airline

operation center – AOC) and an aircraft mostly happens

over data channels utilizing satellite communications.

There have been proposals to replace some or all of the

air-trafﬁc voice radiocommunications with data com-

munications (datacomm). Datacomm is similar to email

in that the messages are transmitted digitally and dis-

played as text, rather than transmitted across voice

channels.

One of the main reasons for this change is fre-

quency congestion. All aircraft under the control of

a particular air-trafﬁc controller monitor and commu-

nicate on the same frequency. In dense airspace, such

as close to the airport, the number of aircraft and the

amount of maneuvering results in a high volume and

rate of communications. Since by regulation each air-

trafﬁc communication must be read back by the pilot

of the aircraft for which the instruction was intended,

this volume can exceed the channel capacity. In such

cases controllers may even continue to the next instruc-

tion without waiting for (or getting) the read back of the

previous instruction.

In addition, many errors are associated with com-

munications read back. Pilots may read back the

clearance correctly but fail to recall it correctly, or they

may read back an incorrect clearance that is subse-

quently not noticed by the controller. Cases in which

the wrong aircraft has read back the clearance have also

occurred. It is expected that datacomm would alleviate

many of these communications errors.

In addition to equipment and certiﬁcation cost, one

of the main issues arguing against datacomm, how-

ever, is party-line information loss. Since all aircraft

under the control of a particular air-trafﬁc controller

are monitoring the same frequency, they would hear

communications with other proximate aircraft, includ-

ing aircraft preceding them on the same route. This

allows pilots to glean information about the relative

positions of other aircraft, their intentions, and the in-

tentions of the air-trafﬁc controller. For example, pilots

hear other aircraft preceding them asking for altitude

changes due to turbulence; this allows them to request

the same change before the turbulence is encountered.

With datacomm, such information would be unavailable

to pilots.

68.3 Guidelines for Automation Development

Flight decks are highly automatedand have many differ-

ent types of automation. In this section, the important

principles for the development of automation are dis-

cussed. First, principles related to each of the types

of automation (control, warning, and information) are

discussed. This is followed by several overarching con-

Part G 68.3

Flight Deck Automation 68.3 Guidelines for Automation Development 1227

cerns for the development of automation – human

factors issues, system integration issues, safety, and cer-

tiﬁcation.

The guidelines listed here are not necessarily fol-

lowed in the development of current automation. One

reason for this is that it is often impossible to follow

all guidelines regarding automation and still meet all

other constraints (such as space, cost, and certiﬁcation).

As such, these guidelines should be treated as goals for

automation developmentrather than hard-and-fastrules.

68.3.1 Control Automation

Control automation must be demonstrably control-

lable and observable. Controllable means that, for any

bounded input, the output will be bounded. If an air-

craft is not controllable, the autopilot may (forexample)

not have sufﬁcient control authority to dampen out er-

rors, resulting in continuously escalating error between

desired and commanded state. Observability means that

the values of the states are known to the controller. If

these states are not known, the controller will not know

to apply control, again resulting in a potential loss of

control of the aircraft. Controllability and stability are

demonstrated mathematically using control theory ap-

proaches (which can be found in any feedback control

textbook).

Control automation should make apparent the axes

under control and the expected behavior of the au-

tomation. Due to the desire to be able to control axes

separately undercertain circumstances, there are anum-

ber of modes in which the autopilot can be operated.

Typically these modes are not clearly identiﬁed to the

pilot, or, if they are, the expected operation of the

aircraft while in these modes is not well understood.

A number of aircraft accidents have occurred due to this

mode confusion. A number of researchers have investi-

gated this problem and proposed solutions [68.10,37–

40], but to date no particular method for mitigating the

problem has been widely adopted. Designers of future

control automation, however, must stronglyconsider the

likelihood of mode confusion, and use good human fac-

tors design methodology to ensure the transparency of

the automation.

Control automation should fail gracefully. It is pos-

sible for the aircraft to be exposed to conditions that

exceed the expectations of the designers. Such condi-

tions are often cases where the pilots could use the

assistance of automation, but where automation typi-

cally turns itself off. Autopilots are designed to be used

under speciﬁc sets of ﬂight conditions; if exceeded,

autopilots will simply disconnect, leaving the pilot to

handle the unusual circumstance by themselves. To the

extent possible, control automation should be designed

to assist pilotseven in unusualcircumstances ratherthan

just shutting off.

68.3.2 Warning and Alerting Systems

Warning and alerting systems are designed to identify

hazards. If this identiﬁcation (and the corrective action)

were deterministic, there would be no need to alert (the

system should operate automatically to perform the cor-

rective action). Typically, the system acts as a signal

detector, alerting based on some threshold of evidence

regarding the hazardous condition.

Signal detection theory provides a convenient and

effective way ofanalyzing alerting systems.If the detec-

tor is correct in identifying the signal, then the detection

is considered correct. Otherwise, the detection is con-

sidered a false alarm. If, on the other hand, the system

does not alert and is wrong (i.e., it should have alerted),

that is considered a missed detection. A correct rejec-

tion is the ﬁnal case, where the system correctly does

not alert.

Given an equal cost of a missed detection and false

alarm, thresholds should be set to minimize missed de-

tections and false alarms. Such a tradeoff can be viewed

on a system operating characteristic (SOC) chart, such

as that shown in Fig.68.8. The chance or guess line is

0 0.2 0.4

SOC line

Guess line

0.6 0.8 1.0

P(CD)

P(FA)

1.0

0.8

0.6

0.4

0.2

Fig. 68.8 System operating characteristic chart

Part G 68.3

1228 Part G Infrastructure and Service Automation

the 45

◦

diagonal on the chart. The curve is constructed

by manipulating the alert threshold and determining the

resulting probability of false alarm and correct detec-

tion. Different system designs will result in different

curves. In the SOC chart, the perfect system operates

in the upper left corner of the chart, where the probabil-

ity of false alarms is zero and the probability of correct

detections is 1.

Since perfect performance is not possible, the sys-

tem should be operated using the alert threshold that

is as close as possible to the upper left corner of the

SOC chart. Moreover, since correct detections and false

alarms are typically not valued equally, the best pointon

the SOC curve is determined by the relative value of the

correct detections and false alarms. In particular, for the

given curve, one should attempt to maximize the value

U = P(CD)V(CD)−P(FA)V(FA) .

(68.3)

For collision detection systems, there is another consid-

eration. If a false alarm occurs, it is possible that the

resulting actions of the pilot will induce a collision that

would not occur if no action had been taken. Therefore,

such systems must also consider induced collisions as

a metric. Other types of alerting systems should also

consider the full effect of false alarms on resulting sys-

tem performance.

Alert thresholdsshould includeconsideration for pi-

lot response time, which will vary considerably based

on the frequency of the alert. Often alert thresholds are

set based on assumptions about the resulting response.

For example, ACAS systems often expect a pilot to ini-

tiate the resolution maneuver within just a few seconds.

However, many alerts are uncommon, sometimes only

heard a few times in the career of a pilot. Expecta-

tion seems to affect pilot response to alerts, and pilots

have been known to take 30s or longer to respond to

alerts [68.41–43]. If the alert thresholds are set assum-

ing a 5s response time, but that threshold is not met, the

alert may come too late to be effective.

Expected responses (often included in the alert

threshold) should also reﬂect heuristics, as pilots will

often apply common shortcuts (or techniques) when

executing a response, even if that response is not con-

sistent with that expected by the alert. For example,

prototype alerting systems for collision avoidance on

approach assume that the pilots will turn away from

the approach path of the other aircraft, and the alert

thresholds are set assuming this response [68.44, 45].

However, military pilots are trained to always keep

proximate aircraft in sight so that separation can be as-

sured visually. A turn away from an aircraft violates this

heuristic and may not be followed.

Wherever possible, preparatory warnings should be

given. It has been shown that adherence to desired ac-

tions subsequent to an alert improves if the alert is

preceded by a preparatory warning [68.46,47]. For ex-

ample, the trafﬁc collision avoidance system (TCAS),

a type of ACAS, utilizes a two-level warning system.

A trafﬁc advisory (TA) is ﬁrst given to warn of a prox-

imate aircraft that may pose a threat. No action is

required due to the TA (although some action presum-

ably should be taken, even if it is to conﬁrm the threat).

If the conditionpersists, a resolutionadvisory is givento

indicate the high potential for collision. Resolution ad-

visories provide speciﬁc guidance to the pilots to avoid

the potential collision; pilots must comply with the res-

olution advisory instructions.

68.3.3 Information Automation

During periods of high workload, pilots will have lit-

tle time to scan a display looking for information. For

that reason, information automation must avoid clutter

– the presentation of useless information alongside use-

ful information. This coincidence of information forces

the pilot to search a display, utilizing time and cog-

nitive resources in short supply during times of high

workload.

However, the designer often cannot identify useful

information a priori. In this case, there are a num-

ber of methods to declutter a display, although no

deﬁnitive methods have been identiﬁed. Decluttering

eliminates low-priority information, or information that

is unlikely to be needed, from the display. One method

is to utilize multifunction displays (MFDs) instead of

single-sensor, single-instrument (SSSI) displays. MFDs

allow for depth, where information can be put on sep-

arate pages of the display that can be brought up when

needed or when called for by the operator. The infor-

mation is then present in the system but not visible until

needed. For example, automation onboard ﬂight decks

will display information related to a malfunction when

that particular malfunction is detected.

Two tradeoffs when using MFDs are the possibil-

ity that information is presented when not needed (or

not presented when needed) by the automation, and the

need to navigate through the display. It can be difﬁ-

cult for the designer to envision all the circumstances

involved that lead to a pilot needing information dis-

played, or needing the display to remain the same.

Moreover, for such automation to be used, it should be

Part G 68.3

Flight Deck Automation 68.3 Guidelines for Automation Development 1229

highly accurate at predicting the information needs of

the pilot.

When depth is introduced into displays, the pilot

must navigate through that depth to arrive at a partic-

ular set of information, just as people navigate through

the depthof webpages.On ﬂight decks, information dis-

plays are typically very small (a few inches by a few

inches), so for the same amount of information more

depth is needed than on a conventional laptop-sized dis-

play. Moreover, fewer controls are provided to navigate

through the displays, making the task even more difﬁ-

cult.

Another method to declutter displays is to de-

emphasize some information by reducing its contrast,

brightness or both. Important information will then pop

out of the display, and unimportant information will be

easier to ignore.

Recent work on visualization may provide some as-

sistance [68.48, 49]. Visualization approaches attempt

to provide information in a format that eases inter-

pretation, allowing more information to be extracted

from a display for a given amount of information

presented. However, such approacheshave yet to be val-

idated for use in such safety-critical systems as a ﬂight

deck.

68.3.4 Human Factors Issues

Our ability to create automation capable of replacing

a function previously done by a human is becoming

largely dependent upon human factors issues rather than

technical ones. With computers becoming smaller and

faster, it is technically possible to produce automation

capable of remarkable feats. However, if that system

must interact with humans, it must be compatible. This

problem of compatibility is often a major obstacle to

the introduction of automation into complex socio-

technical systems.

Such automation must consider a number of as-

pects of human interaction with technology. The role

of human in a highly automated system is often rele-

gated to that of a supervisor. This role has particular

requirements and challenges that must be considered

by the designer of automation. One of these chal-

lenges relates to the out-of-the-loop problem [68.50],

which is being addressed in terms of understanding

the operator’s awareness of the situation. In addi-

tion, automation must incorporate human limitations

with regards to perception, workload, and physical

ergonomics.

Supervisory Control

As ﬂight deck automation increases in quantity and

sophistication, some have expressed concern that pi-

lots are becoming supervisory controllers of automation

rather than users of automation. On some aircraft, it is

possible to connect the autopilot once aligned on the

departing runway, and allow the aircraft to ﬂy to its

destination, land, and taxi off the runway without inter-

acting with the aircraft control surfaces (except drag/lift

devices such as ﬂaps and spoilers) except through the

autopilot.

One concern related to this phenomenon is

the loss of manual control skills, as discussed by

Billings [68.51] and others [68.52, 53]. Should the au-

tomation fail, the pilots would have to ﬂy the aircraft

manually. Since such failure is likely to result from

a more serious system failure, such control may have

to be assumed under less than ideal circumstances. For

example, the aircraft may have only partially operating

control surfaces, as was the case with a DC-10 mishap

in Sioux City, Iowa in 1989 [68.54]. In that accident,

an uncontained engine failure left the aircraft without

hydraulic power to operate any of the control surfaces.

The pilots controlled the aircraft using engine power

only, a procedure that had to be created by the pilots

on the spot. Without excellent manual ﬂying skills, it is

unlikely that the result would have been as successful

(175 of the 285 passengers and all but one of the crew

survived the crash landing). Designers of automation

should ensure that sufﬁcient opportunity exists for the

operators to exercise those aspects of control for which

an intervention need may arisein the case of automation

failure.

The overarching considerations that are part of su-

pervisory control [68.55] should be considered when

designing automation for ﬂight decks. These con-

siderations include the ability of pilots to monitor

information, an understanding of the impact of commu-

nications/control delay, and loss of situation awareness.

As supervisors of automation, pilots are responsible

for monitoring the automation to ensure it is operating

properly and to intervene should the automation fail.

Humans are notoriously bad at monitoring highly reli-

able systems [68.56]. Under such conditions, humans

will tend to become complacent and fail to monitor

adequately. One response to this has been to suggest

caution against overautomation [68.51], while others

have suggested that more automation (or at least feed-

back) is the answer [68.57]. Likely what is required is

smarter automation, including designs that make a sys-

Part G 68.3

1230 Part G Infrastructure and Service Automation

tem fail only in ways that can be handled by a human

supervisor.

Even relatively small delays in communication or

control can have signiﬁcant consequences for supervi-

sory control.This isanalogous tomanual control, where

delays between identiﬁcation of control requirement

and application ofthat control canlead to instability.For

faster control loops, less delay is required; for slower

control loops, longer delays can be tolerated. For ex-

ample, under conditions of several seconds of delay,

intervention by a supervisor to accept manual control

would likely be impossible, whereas such delays would

not impact the supervisor’s ability to provide navigation

commands to a vehicle.

In addition, humans have better situation aware-

ness when actively involved in the operation rather than

when acting as a supervisor of automation [68.58,59].

Situation awareness is the set of information used by

the operator in order to make decisions and choose

courses of action, and will be discussed in more detail

in the next section. Good situation awareness, consid-

ered a key to good performance in complex systems, is

adversely affected by the operator’s cognitive distance

from the task. This may be a result of research ﬁnd-

ings suggesting that concrete, directexperiences involve

deeper cognitive processing, and are therefore better re-

called than those that are merely described or otherwise

undergo more shallow processing [68.60].

Situation Awareness, Clutter,

and Boundary Objects

Since situation awareness is correlated with good

performance, automation designers should attempt to

enhance situation awareness. However, this cannot be

addressed by simply making sufﬁcient information

available and salient to the operator, since situation

awareness involves the operator making use of that

information. Making information available is not suf-

ﬁcient for ensuring that the information gets used;

operators may simply fail to use available informa-

tion for guiding action for reasons that are as yet

unclear. For example, one aviation incident self-report

from theNational Aeronautic and Space Administration

(NASA)’s aviation safety reporting system database de-

scribes landing at the Los Angeles International Airport

without ﬁrst obtaining landing clearance as required

by FAA regulation. The crew, who would normally

switch their radiofrequency to that of the tower con-

troller (who would then grant landing clearance), was

told to remain on a previous frequency by air-trafﬁc

control (most likely due to some separation concern).

As a result, the crew never switched frequency and

never got landing clearance. They realized their mis-

take after turning off the runway, at which point they

were about to switch to the frequency of the ground

controller. Noticing the error, the crew called the tower

and reported their mistake. The crew in this incident

had sufﬁcient information to know they did not have

clearance; they simply did not make use of that in-

formation. While factors such as interruptions (and

other disturbances to a routine), workload, idiosyncratic

cognitive capabilities, and experience would seem to in-

ﬂuence the prevalence of this type of behavior, as yet no

deﬁnitive researchhas been accomplished to understand

it.

Automation designers should be aware that the ab-

sence or lack of salience of information, while not

technically a part of situation awareness, will have the

same effect as a loss of situation awareness. That is,

not having the information in the ﬁrst place will have

an identical effect on performance as not making use

of available information (although the causes of the er-

ror may be different). One method to ensure this is to

conduct a thorough task analysis [68.61], such as goal-

directed task analysis [68.62]. Such methods provide

insight into what information may be required by an

operator in the conduct of their task.

In addition to ensuring the availability of infor-

mation, designers should ensure that information is

accessible to the operator. Too much irrelevant informa-

tion can make accessing particular (important) pieces

of information more difﬁcult than necessary [68.35,63].

For this purpose, a number of decluttering schemes are

available [68.64–66].

Intelligent design of displays, so that multiple oper-

ators across a collaborative task can easilycontextualize

information while making use of the same body of in-

formation, is also recommended. Such displays, known

as boundary objects, have been found in examples of

good collaborative work [68.67,68]. Unfortunately, de-

sign criteria for these types of displays are still lacking.

Situation Assessment

Automation designers should consider the situation as-

sessment capabilities of the pilots. Situation assessment

is a term that refers to the process of populating sit-

uation awareness. Situation assessment involves most

aspects of cognition– perception,attention, comprehen-

sion, memory – and is therefore very complex. These

limitations are discussed in subsequent sections. How-

ever, several important overarching ﬁndings bear on this

capability.

Part G 68.3

Flight Deck Automation 68.3 Guidelines for Automation Development 1231

Operators monitoring dynamic displays do so at

a near-optimal rate under most circumstances. Accord-

ing to the Nyquist–Shannon sampling theorem [68.69],

one can fully reproduce a signal if that signal is sampled

at more than twice the signal’s frequency, if the signal

is bandlimited. Operators have been found to sample

at precisely this rate, with some deviation at higher

and lower frequency [68.70]. For highly dynamic in-

formation, operators will oversample, while they tend

to undersample low-frequency information. Numerous

reasons have been proposed for this tendency, with-

out a deﬁnitive answer. However, designers can feel

somewhat comfortable that human operators will sam-

ple dynamic displays appropriately.

However, as mentioned above, operators become

easily complacent with highly reliable or very low-

frequency information. In such cases, designers should,

where practical, ensure that operators are engaged in

the task. One method, utilized in airport security x-ray

machines as the threat image protection system, is to

occasionally probe the operator with false signals. Such

signals can be used to engage the operator but also to

test to see if the operator is becoming complacent. An-

other method is to increase the salience of potentially

offending signals, such as providing a warning light to

attract the attention of the operator to the instrument

containing the relevant information.

In addition,operators have signiﬁcant cognitive lim-

itations (but also have several methods of coping with

these limitations). A human’s channel capacity is lim-

ited to somewhere between four and nine individual

items [68.71, 72]. Above this, operators must be able

to chunk the information (such as recalling a phone

number as one seven-digit number rather than as seven

separate digits in a sequence). Expertise improves the

ability of operators to chunk information, but design-

ers are cautioned not to design automation that taxes

a human’s channel capacity.

Perception

In terms of visual perception, human operators sparsely

sample scenes, then integrate their knowledge of the

world with these sparse samples to obtain a representa-

tion. One factor known to affect sampling is the Gestalt

of the scene [68.73]. Factors such as the proximity of

items, their common fate, and their similarity all affect

the ability of the operator to associate information. An

example of this ability regards the monitoring of a num-

ber of check-reading gages. Gages oriented so that their

limits are aligned (Fig.68.9) are much easier to monitor

than those that are not. Designers are therefore encour-

Max

Fig. 68.9 Aligned gages for Gestalt effect

aged to consider the Gestalt of instruments to assist

operators, including grouping information used for the

same purpose close to one another [68.74].

The basic layout of ﬂight deck instrumentation was

established many decades ago, based on research into

the scan pattern of pilots [68.75]. This placed the most-

used instruments into a T-shaped pattern (now called

the basic T), with less-used instruments being placed

outside of this T, but close to related instruments. The

basic T has been replicated on multifunction displays

utilized in modern aircraft in place of single-sensor,

single-instrument gages. It seems certain that this ar-

rangement will continue, and should be adhered to by

automation designers.

Workload has been known to affect perception and

attention, as has been widely reported in studies on

driving [68.76, 77]. Increased workload impairs visual

detection, as well as the size and shape of the vi-

sual ﬁeld [68.78]. Increased workload also dissipates

attention, which in turn inﬂuences perception. Design-

ers should be aware that, under conditions of high

workload, pilotsmay have difﬁculty in perceiving infor-

mation that would otherwise be considered sufﬁciently

salient.

Much of the information imparted to the user by

ﬂight deck automation uses the visual channel. In order

to avoid further saturating the visual channel, design-

ers are reminded that other perceptual channels are

available. Several automation systems use the aural

channel, particularly alerting systems. The GPWS,the

stall warning system, the landing gear warning system,

and a number of others produce both visual and aural

warnings; each aural warning is distinct to aid in iden-

tiﬁcation. Very little work has been done in trying to

utilize the haptic medium in aviation, but some suc-

cess has been found in aiding operators in locational

attention directing [68.79], which could be useful for

pilots.

Part G 68.3

1232 Part G Infrastructure and Service Automation

Workload

Often the primary concern related to workload is to

ensure that the work required of an operator does

not exceed the operator’s capability. Pilots experience

swings in workload from very high (takeoff and land-

ing) to very low (cruise). The periods of high workload

are such that almost no cognitive work, required for

reasoning and other higher-level functions, can be ac-

complished. Instead, pilots are relegated to skill-based

control [68.80], and do not have time for things such

as mental calculation or troubleshooting. Imposing re-

quirements for such activities during high workload

periods should be avoided.

Performance in complex tasks has been showed to

be inverse-U shaped with respect to workload [68.81,

82]. At low levels of workload, human performance is

low due to complacency. At high levels of workload,

performance is also low, but due to task demands tax-

ing or exceeding human capabilities. Performance is

highest at moderate levels of workload. Automation de-

signers should therefore try to balance workload (not

too high and not too low), rather than strictly trying to

reduce it.

Physical Ergonomics

Automation designers should consider good physical

ergonomics as well as cognitive ergonomics. For au-

tomation, several factors are considerations, including

repetitive strain avoidance, placing frequently used

controls within reach, ensuring proper visibility and

audibility, and reducing the heads-down time of the op-

erator.

Automation should avoid requiring signiﬁcant ﬁne

input from the operator. The ﬂight management system

(FMS) includes a control display unit (CDU), which is

the primary manual interface for the pilot with the unit.

Pilots may needto input information into the FMS using

the CDU, which consists of a small keyboard and dis-

play. The keys on the CDU are small, mostly identically

shaped, and laid out in an idiosyncratic (to the particu-

lar CDU) manner. This layout is far from ideal from

a human factors standpoint, and results in a slow rate of

typing. Should signiﬁcant typing be required, repetitive

stress injuries (such as carpal tunnel syndrome) would

be a signiﬁcant risk. However, designers of the CDU

must contend with a very small device footprint, it must

have very high reliability, and it must be robust to ﬂight

conditions such as turbulence. Fortunately, most of the

information in the FMS is loaded only once (or by elec-

tronic download), so typing is infrequent and usually

limited to a few key presses.

There are numerous principles for controls to

avoid the chance of repetitive strain or overuse disor-

ders [68.82]. These types of injuries are associated with

high-frequency activity, and therefore can be avoided

by eliminating prolonged periods of repetitive mo-

tions. High repetitiveness has been deﬁned as a cycle

time of less than 30 s, or more than 50% of the total

task time [68.83]. Larger loads can induce the same

conditions with less repetition. Maintaining body posi-

tions (other than the neutral body position) or gripping

objects can also induce repetitive strain injuries. Ac-

cording to Kroemer et al. [68.83], there are seven sins

associated with overuse disorders:

1. Highly repetitive motions

2. Prolonged or repeated application of more than one-

third of an operator’s static muscle strength

3. Stressful body postures, such as elevated wrists

when typing or working while bent or twisted at the

waist

4. Prolonged nonneutral body postures, such as stand-

ing

5. Prolonged contact with a surface, such as leaning

against a surface or holding a tool

6. Prolonged exposure to vibration

7. Exposure to low temperatures (such as a draft or

exhaust from a pneumatic tool).

Certain types of reaching are ergonomically unde-

sirable. The need to extend oneself to reach a control

poses risks to the back and shoulders, as does the need

to reach above one’s shoulder height [68.84]. The need

to twist one’s body frequently also poses signiﬁcant risk

of injury to operators. For these reasons, it is a com-

mon ergonomic principle that frequently used controls

be placed within the normal reach of the operator.

To ﬁnd the normal reach of the operator, one should

ﬁrst identify the range of sizes of the people that con-

stitute the population for which the device will be

designed. A common choice is to use a 5th percentile

female as the lower limit and the 95th percentile male

as the upper limit. However, certain occupations may

further limit the population.

If single measurements are required (such as

shoulder–hand length), lookup tables, such as those that

can beobtained from NASA or commercial sources, can

be used. If multiple measurements are required, how-

ever, cases should be considered rather than trying to

combine measurements from the tables. Cases identify

a typical small or large person, rather than assuming

that a small person has the 5th percentile seated height

Part G 68.3

Flight Deck Automation 68.3 Guidelines for Automation Development 1233

and 5th percentile shoulder–hand length (for example),

which is usually not accurate.

Once the lower and upper measurements have been

obtained, the designer can then check to see whether

the commonly used controls are within the reach of that

range of persons without extending. Such methods have

been applied in a great number of different domains.

Proper visibility should be ensured throughout the

typical illuminance conditions. Studies that provide

guidance on illuminance were conducted decades ago,

including studies in which Blackwell [68.85] found

that the threshold contrast at which objects became

recognizable increased with decreasing object size,

decreasing orderliness of objects, movement of the

objects, and if less time was given to detect the

object. Increased age also increases the need for con-

trast [68.86].

In addition, the viewing of displays should be free

of glare and veiling reﬂections. Glare is the condition

where bright light sources are in the line of sight of the

operator, creating a nuisance. Veiling reﬂections are the

condition where bright light sources are reﬂected off the

display surface, obscuring information on the display.

These problems can be minimized by positioning the

display where bright light sources pose neither a glare

or reﬂection issue (to the maximum extent possible).

Automation designers should also ensure audibility,

particularly of aural feedback or alerts. An alert that

is at least 10–15 dB above the ambient noise level is

generally considered sufﬁciently salient, although alerts

are often found with signiﬁcantly less difference when

placed in the normal operating environment (a ﬂight

deck is a noisy place in ﬂight). Different types of tones

can also be used to indicate different levels of critical-

ity [68.87].

When multiple auditory warnings exist, as they do

on ﬂight decks, they should utilize distinct tones to

avoid confusing one alert with another. Some alerts may

even include computerized voices. On a typical ﬂight

deck, auditory warnings exist for the GPWS system,

TCAS system, overspeed warning, landing gear warn-

ing, and altitude alerts.

When the weather permits, pilots must direct a sig-

niﬁcant amount of attention to outside the ﬂight deck.

In addition to visually locating other aircraft that may

pose a collision risk, pilots must frequently locate, iden-

tify, and orient themselves with respect to a particular

airport runway. On the ground, scanning for obstacles

and other aircraft is a particularly important task. For

this reason, automation should not impose upon pilots

too much heads-down time (the term is contrasted with

heads-up displays located on the windshield of the air-

craft). Flight management system reprogramming, for

example, is a difﬁcult task, requiring many minutes of

heads-down time to accomplish relatively simple re-

programming tasks. It is therefore undesirable to have

changes close to the ground, where pilots’ attention

should be outside rather than inside the aircraft.

68.3.5 Software and System Safety

Calls have been made previously for automation that

gracefully degrades [68.51, 55], but there has been

a general lack of guidelines for such a purpose. One

signiﬁcant complication for the introduction of such

methods is that most advanced automation is soft-

ware rather than hardware based. Software systems lack

physical constraints available in hardware. Whereas

one can construct physical constraints on machines

that prevent them from failing in certain ways (e.g.,

short-circuit protection devices on electrical outlets

in bathrooms), no such assurances can (so far) be

provided for software systems. Formal methods for

mathematically verifying software [68.88], particularly

in concert with model-based software development

methods [68.89], are methods that go far toward im-

proving software systems in this regard.

Formal methods, however, are insufﬁcient for en-

suring software safety [68.90]. Safety is often more

than ensuring that the output of the software remains

within some constrained set of appropriate responses.

Safety also involves the processes for deﬁning those

constraints and the interaction of human and other auto-

mated agents with the system. Therefore, system safety

must also account for these (and other) factors.

Because of this, safety has been viewed as an emer-

gent feature of a system, ensured by providing sufﬁcient

control for agents in the system to prevent it from enter-

ing unsafe states [68.91]. Under this concept, a system

can be modeled as a set of states, where safety (as

a goal) is preventing the system from entering an unsafe

state.

68.3.6 System Integration

As ﬂight decks get more complex, and as the in-

teractions between systems (other vehicles, air-trafﬁc

controllers, passengers, company) become tighter, sys-

tem integration issues will grow in importance. Aircraft

have been typically designed to optimize some aspect

of the vehicle (for example, speed, fuel economy, range

or capacity), but now must consider the integration of

Part G 68.3

1234 Part G Infrastructure and Service Automation

that vehicle within a larger system. There are tight

interactions between customer demand, airline route

decisions, air-trafﬁc control infrastructure, and aircraft

design.

Such design optimizations involve multiple sys-

tems, each of which have very different dynamics.

The behavior of the system is not deﬁned by the

sum of the behaviors of the components, but typ-

ically also has emergent behavior at higher levels

of aggregation of the components. Methods for ac-

complishing such optimizations have not yet been

developed, but are being studied as systems-of-systems

problems.

Nonetheless, automation designers must address

systems integration issues. Flightdeck automationis ex-

pensive to develop and implement, and therefore must

last many years (typically the lifetime of different air-

craft models). For example, ﬂight management systems

have hardware and software that is highly antiquated by

modern computer standards, but because it works and is

certiﬁed (Sect.68.3.7), it has not substantially changed

over the last few decades. Moreover, the ﬂight deck au-

tomation needed to take advantage of next-generation

air-trafﬁc systems will need to be developed and in-

stalled over the next decade.

Flight deck systems often interface with multiple

systems of various types. State information on air-

craft comes from pito-static, temperature, and other

instruments. Position and navigation information come

from radio navigation aids, inertial navigation systems,

GPS, and the ﬂight management systems. There are

also mechanical, electrical, hydraulic, and pressuriza-

tion systems onboard. Potentially, automation must be

integrated with several of these different types of sys-

tems.

68.3.7 Certiﬁcation and Equipage

The various civil ﬂight authorities have strict cer-

tiﬁcation requirements for new automation. These

requirements impose rigorous safety requirements on

that automation. This results in long lead times and high

costs, which in turn imposes a heavy burden on any new

automation system being proposed.

In the USA, the Federal Aviation Administration

certiﬁes new equipment. Under the Code of Federal

Regulations, each installed system must:

1. Be of a kind and design appropriate to its intended

function

2. Be labeled as to its identiﬁcation, function or oper-

ating limitations, or any applicable combination of

these functions

3. Be installed according to limitations speciﬁed for

that equipment

4. Function properly when installed [68.92, p.125].

In addition, for ﬂight and navigation instruments:

1. The equipment, systems, and installations ... must

be designed to ensure that they perform their in-

tended functions under any foreseeable operation

condition.

2. The airplane systems and associated components,

considered separately and in relation to other sys-

tems, must be designed so that:

a) The occurrence of any failure condition which

wouldprevent the continuedsafe ﬂight andland-

ing of the airplane is extremely improbable.

b) The occurrence of any other failure conditions

which would reduce the capability of the airplane or

the ability of the crew to cope with adverse operat-

ing conditions is improbable.

3. Warning information must be provided to alert the

crew to unsafe system operating conditions, and to

enable them to take appropriate corrective action.

Systems, controls, and associated monitoring and

warning means must be designed to minimize crew

errors which could create additional hazards [68.92,

p.126].

The certiﬁcation process is detailed and slow, de-

signed to prevent systems with deleterioussafety effects

from being installed in aircraft (particularly commer-

cial aircraft). This process, which is well known to

the industry but is not well documented, should be

considered by automation designers. The use of off-the-

shelf and previously certiﬁed hardware and software is

recommended to simplify and shorten the certiﬁcation

process.

68.4 Flight Deck Automation in the Next-Generation Air-Trafﬁc System

As of this writing, the next-generation air-trafﬁc system

is still taking shape [68.1,2], but the following appear

to be emerging as key features of that system:

•

Network-centric operations

•

Integration of novel vehicle types

•

Operations under conditions of very high density

Part G 68.4