9758 FFHH en ATM PDF

Human Factors guidelines
for air traffic

management (ATM) systems
(Doc 9758-AN/966)
FIRST EDITION - 2000
AMENDMENTS
The issue of amendments is announced regularly in the ICAO Journal and in the
monthly Supplernenf ro the Catalogue of ICAO Publications and Audio-visual
Training Aids, which holders of this publication should consult. The space below
is provided to keep a record of such amendments.
RECORD OF AMENDMENTS AND CORRIGENDA
Chapter 5, 5.1.1.3, and in Amex 11, Chapter 2, 2.22.1.1,

include both voice and data link communications.
The safety of civil aviation is the major objective of the

International Civil Aviation Organization (TCAO). Considerhle progress has been made in increasing safety, but
additional improvements are needed and can be achieved. It
has long been known that the majority of accidents.result
from less than optimum human performance, indicating
that any advance in this field can be expected to have a
significant impact on the improvement of flight safety.
Furthermore, at the ICAO World-wide CNSfATM Systems

Implementation Conference, held from 11 to 15 May 1998
in Rio de Janeiro, Brazil, inter alia, the following
Conclusions pertaining to Human Factors issues were
generated:
This was recognized by the ICAO Assembly, which in 1986

adopted Resolution A26-9 on Flight Safety and Human
Factors. As a follow-up to the Assembly Resolution, the
Air Navigation Commission formulated the following
objective for the task:
In order to maximize safety and cost-effectiveness of

CNS/ATM systems, the pro-active management of Human Factors issues must be a normal component of the
processes followed by designers, providers and users of
the systems. (Conclusion 6/2)
'TO improve safety in aviation by making States more

aware and responsive to the importance of Human Factors
in civil aviation operations through the provision of
practical Human Factors material and measures developed
on the basis of experience in States, and by developing and
recommending appropriate amendments to existing
materials in Annexes and other documents with regard to
the role of Human Factors in the present and future
operational environments. Special emphasis will be
directed to the Human Factors issues that may influence the
design, transition and in-service use of the [future] ICAO
CNSIATM systems."
One of the results of this initiative has been the
incorporation of Human Factors-related Standards and
Recommended Practices (SARPs) in several Annexes to the
Chicago Convention and in other ICAO documents,
including the Procedures for Air Navigation Services
Aircraft Operations (PANS-OPS, Doc 8400) and the
Procedures for Air Navigation Services - Rules of the Air
and Air Trafic Services (PANS'RAC, Doc 4444). Table F-1
presents the existing ICAO Human Factors SARPs in the
various Annexes that have a relationship with the provision
of air traffic services (ATS):
The Recommendation in Annex 10, Volume IV, Chapter 2,

2.2.1, includes the design and certification of automatic
dependent surveillance (ADS) systems. Similarly, the
references to "communications" in Annex 10. Volume 11,
The time to address Human Factors issues is during

technology design and before the technology is deployed into operational contexts. (Conclusion 6/3)
Training plays a fundamental role in CNSfATM systems but should not be used as a mediator of flawed or
less-than-optimum human-technology interface design.
(Conclusion 6f4)
On the subject of timely consideration of Human Factors
and associated safety regulation, the Conference recommended that:
Human Factors issues be considered before CNSJATM
technologies are deployed, during the process of design
and certification of the technology and associated
standard operating procsdures. (Recommendation 6/11)
States and organizations which design and provide
CNSIAXM systems take into account ICAO guidelines
when developing national regulations and incorporate
Human Factors Standards in the processes of design
and certification of equipment and procedures.
(Recommendation 6/12)
The Human Factors-related SARPs in Annexes 10 and 11,
as well as the Conclusions and Recommendations of the
Rio de Janeiro Conference, underlie the development of
this manual of Human Factors guidelines for air traffic
management (ATM) systems.
Hurna~zFactors guidelinesfor air trajjic management (ATM) system
{ii)
--
Table F-1. ATS-related ICAO Human Factors SAWS
Annex
Part and chapter
1 - Personnel Licensing
4.3
Paragraph and text of the Standard or

Recommended Practice
Air traffic controller licence
4.3.1.2
Knowledge
Human Performance and limitations
d) human performance and limitations

relevant to air traffic control;
10 - Aeronautical
Telecommunications
Volume I1 - (Communications
Procedures including those with
PANS status)
Chapter 5. Aeronautic31 Mobile

Service
5.1 General
5.1.1.3 Recornmendation.- In all

communications, the consequences of
human performance which could affect the
accurate reception and comprehension of
messages should be taken into
consideration.
10 - Aeronautical
Telecommunications
Volume IV - Surveillance Radar
and Ccllision Avoidance
Sy sterlls
Chapter 2. General
2.2. Human Factors considerations
2.2.1 Recommendation.- Human

Factors principles should be observed in
the design and certification of surveillance
radar and collision avoidance systems.
Chapter 2. General
2.22 Service to aircraft in the event of
an emergency
2.22.1.1 Recommendation-- In
communications between ATS units and
aircraft in the event of an emergency,
Human Factocs principles should be
observed.
11
- Air Traffic Services
The target audience for the manual consists of two main

groups: 1 ) ICAO panels and groups from other organizations that are involved in the development of ATM
equipment andfor procedures for ATM purposes; and 2)
States and organizations that will acquire and implement
ATM systems. Both groups are assumed to be familiar with
the CNSIATM concept.
The development, acquisition and implementation of an

advanced ATM system generally is not a linear but rather
an iterative process, involving a high degree of interaction
between the manufacturer and the buyer/user. Therefore,
this manual consists of a single vokme containing guidelines for both target audiences throughout the text.
This manual is designed as folIows:
Note I.- In several Stares the provision of air trafic

services (ATS) is the responsibility of organizations that in
varying degrees operate independently from the government. The governments, however; are still responsible for
safety regulation for the ATS-providing organizations.
G~citiciinesin fllis rnarllcal are applicable ro regttlarors and
providers alike.
Note 2.- In this manual, the phrase "ATS provider" is
rued generically, i.e. withoidt distirigltishing wiletfter a State
or an organizatiort is responsible for tile provision of ATS.
Chapter 1 contains background information from

various sources about the importance of incorporating
Human Factors knowledge into the development, acquisition and implementation processes for ATM systems.
Chapter 2 introduces three essential concepts to guide
these processes. This chapter is primarily aimed at the
panels and groups involved in high-level development
and implementation issues, but it is relevant to ATS
providers.
.
Foreword
Chapter 3 provides a description of external data link

infrastructure and applications, where "external"
indicates that the topics discussed are considered to be
outside the influence of those involved in the development, acquisition and implementation of ATM systems.
Panels and other groups may take note of the descriptions of the human-machine interfaces (HMIs) for
controller-pilot data link communications (CPDLC) on
the flight deck in this chapter.
Chapter 4 discusses design issues for the HMI of
advanced, ground-based ATM systems and therefore is
mainly aimed at States and organizations that will
acquire and implement ATM equipment. Manufacturers
of ATM equipment will. benefit from this chapter.
Members of pmels and other groups may find ihe
Appendices to this chapter, in which examples of
existing HMI designs are presented, of particular
interest.
Chapter 5 includes findings from the research
community related to the early implementation of
CPDLC. These findings arc in line with operational
results from user groups (mainly in the Pacific area) and
are presented as background information to support the
recommendations in this manual.
Chapter 6 is mainly aimed at the States and
organizations that will acquire and implement ATM
systems and presents guidelines on topics related to
preparation for the change from present to new systems.
Selected topics from this chapter are of interest to
panels and other groups as well.
Chapter 7, Standard operating procedures, is relevant to
panels and other groups as well a s to States and
organizations responsible for the provision of ATS.
Chapter 8 introduces examples of new flight deck
technology that will eventually have an impact on the
provision of ATS. This impact on the development and

acquisition of ATM systems should be anticipated,
hence the inclusion of this chapter.
Chapter 9 lists sources for further information on the
subjects discussed in this manual.
In summary:
Guidance material for panels and other development
and implementation groups is included in Chapters 1,
2, 3, 4 and 7. Background information material for this
audience is contained in the appendices to Chapter 4
and in Chapters 5, 6 and 8. Chapter 4 is especially
relevant for manufacturers of ATM equipment.
organizations that will acquire and

implement ATM equipment will find relevant guidance
material in Chapters 1, 3, 4, 6, 7 and 8, with background information material in Chapters 2 and 5.
States and
Sources for further information are presented in

Chapter 9.
This manual is a living document and will be kept up to
date. It will be amended periodically as more experience
with the new systems and associated procedures is gained,
and as new research and increased knowledge on Human
Factors issues as they may affect the development.
acquisition and implementation of ATM systems become
available.
The cooperation of the following organizations in the
production of this manual is acknowledged: Airbus, Air
Services Australia, the Airways Corporation of New
Zealand, Boeing, The European Organisation for the Safety
of Air Navigation (Eurocontrol), the Federal Aviation
Administration, the Japanese Civil Aviation Bureau and the
Radio Technical CommissiOn for Aeronautics.
TABLE OF CONTENTS
Page
Page
Appendix 1 to Chapter 4 -- The New Zealand
Oceanic Control System (OCS)
bAl-1
Foreword
..................................
(i)
Acronyms
...................................
(vii)
Chapter 1 Incorporating Human Factors

knowledge
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
..................................
1-1
1-3
1-3
Chapter 2. Three essential concepts .......... 2-1

2.1 Introduction .........................
2-1
2.2 Human-centred Automation . . . . . . . . . . . . 2- 1
2.3 Situational Awareness . . . . . . . . . . . . . . . . .
2-5
2.4 Managing error . . . . . . . . . . . . . . . . . . . . . . 2- 10
Conclu.sion .......................... 2- 14
References .......................... 2-14
Chapter 3 Data link infrastructure and

applications ................................ 3- 1
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.2 Data link . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
3.3 Data link applications ................. 3-2
Conclusion .......................... 3-23
References .......................... 3-23
Chapter 4
The Human-Machine interface
.....................................
(HMI)
4.1 Introduction
.........................
Input devices ........................

4.3 Visual displays .......................
4.4 Menus ..............................
4.5 Menu design ........................
4.6 Use of colour ........................
4.7 Data entry ..........................
4.8 Electronic flight progress strips .........
4.9 User guidance .......................
4.10 Visual alerting .......................
4.1 1 Auditory alerts .......................
4.12 Specific recommendations for
the CPDLC HMI . . . . . . . . . . . . . . . . . . . . .
Conclusion ..........................
Refertnces ..........................
4.2
4-1
4-1
4-1
4-2
4-3
4-3
4-6
4-7
4-8
4-10
4- 12
4-13
4-14
4- 16
4- 16
............
Appendix 2 to Chapter 4 -- Operational

Development of Integrated Surveillance
and Aidground Data Communications
(ODPAC)................................
4-A2-i
Appendix 3 to Chapter 4 .
The Australian
Advanced Air Trafic System (TAAATS).....
4-A3-1
Appendix 4 to Chapter 4 .
The Japan
Oceanic Control Data Processing
System (ODP) ...........................
4-A4-1
Attachment to Chapter 4 .
An example of a
checklist with Human Factors considerations
for the ATC Human-Machine interface
4-Att-1
......
.......................
.............
Chapter 5 Research
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Communication speed .................
5.3 Party line effect . . . . . . . . . . . . . . . . . . . . . .
5.4 Vulnerability . . . . . . . . . . . . . . . . . . . . . . . .
Conctttsion ..........................
References ..........................
Chapter 6 Preparing for change

6.1 Introduction .........................
6.2 Writing system specifications ...........
6.3 Human Factors plan ..................
6.4 Operating philosophy .................
6.5 Changing team roles ..................
6.6 Early prototyping .....................
6.7 Planning and timing of training .........
6.8 Training content ......................
6.9 Regulatory aspects. ...................
6.10 Recommendations ....................
Summary ...........................
References ..........................
....
Chapter 7. Standard operating procedures

7.1 Introduction .........................
7.2 Requirements for procedure
development .........................
6-1
6-1
6-1
6-2
6-2
6-2
6-4
6-5
6-6
6-7
6-8
6-9
6-9
7-1
7-1
7-1
(vi)
Human Facfors guidelines for air trafficmana~ernenr( A T M )xysre~ns
Page
7.3 Harmonization of standard operating

procedures ..........................
7.4 Standard operating procedures for
CPDLC .............................
7.5 Standard operating procedures
forADS ............................
7.6 Siandard operating procedures for
pre-departure clearance (PDC) ..........
7.7 Standard operating procedures for
GNSS-based instrument approaches ......
Conclusion ..........................
References ..........................
Page
7-1
7-2
7-2
7-4
7-5
7-6
7-7
Chapter 8 New flight deck technology ........ 8-1

8.1 Introduction .........................
8-1
8.2 Airborne situational awareness
(AIRSAW) .......................... 8-1
8.3 Airborne separation assurance
systems (ASAS) .....................
8-1
8.4 Unresolved issues . . . . . . . . . . . . . . . . . . . .
8-3
8.5 Consequences for P;Trvl ................ 8-6
Conclusion .......................... 8-6
Chapter 9. Sources for additional
information
................................
9-1
ACRONYMS
ACARS
Aircraft communications
addressing and reporting system
ACC
Area control centre
ACID
Aircraft identification
ADS
Communication, Navigation,
SurveillancdAir Traffic
Management
CPDLC
Controller-pilot data link

communications
Automatic dependent surveillance
DCDU
Data link control -and display unit
ADS-B
Automatic dependent surveillance

- broadcast
EICAS
Engine indication and crew alerting

system
AFN
ATS facilities notification
EUROCONTROL
Organisation for the Safety of Air

Navigation
AIDC
ATS interfacility data

comn~unications
FAA
Federal Aviation Administration
AIRSAW
Airborne situational awareness
FANS
Future Air Navigation System
m c
Aeronautical Radio, Incorporated
FDPS
Flight data processing system
ASAS
Airborne separation assurance

system
FDR
Flight data recorder
FIR
Flight information region
ASRS
Aviation safety reporting system
FL
Flight level
ATC
Air traffic control

FMC
Flight management computer
ATIS
Automatic terminal information

service
FMS
Flight management system
Am
Air traffic management
FO
First officer
ATN
Aeronautical telecommunication
network
GNSS
Global navigation satellite system
HCA
Human-centred automation
ATS
Air traffic services
HF
High frequency
ATSU
Air traffic services unit

HMI
Human-machine interface
CDTI
Cockpit display of traffic

information
IAS
Indicated airspeed
CDU
Control and display unit
ICAO
International Civil Aviation

Organization
CFL
Cleared flight level

Identification
Human Factors guidelinesfor air rrafic mriagcmenf (ATM) systems
(viii)
Instrument flight rules
RNP
Required navigation performance
ISPACG
Informal South Pacific Air Traffic

Services Co-ordinating Group
RTCA
Radio Technical Commission for

Aeronautics
JCAB
Japan Civil Aviation Bureau
RVSM
Reduced vertical separation

minimum
MCDU
Multipurpose control and display

unit (Airbus)
SA
Situational awareness
SARP
Standards and Recommended

Practices
SID
Standard instrument departure
S lTA
Sociktk Internationale de
T616communications Akronautiques
SOP
Standard operating procedure
SSR
Secondary surveillance radar
STAR
Standard instrument amval
STCA
Short term conflict alert
TAAATS
The Australian Advanced Air
MCDU
Multifunction control-display unit

iBoeing)
MFD
Multifunctional display
MSG
Message
MSAW
Minimum safe altitude warning

system
NM
Nautical mile
NOTAM
Notice to airmen
OCS
Oceanic Control System
ODIAC
Operational Development of
Integrated Surveillance and
Airlground Data Communications
Traffic System
ODP
Oceanic Control Data Processing

System
TCAS
Traffic alert and coilision avoidance

system
on
On-the-job training
TRM
Team resource management
PANS
Procedures for Air Navigation

Services
UHF
Ultra-high frequency
PDC
Predeparture clearance
VDL
VHF Digital Link
Prn
Primary flight display
vm
Visual flight rules
PNF
Pilot not flying
VHF
Very high frequency
Rfr
Radiotelephony
VOR
VHF omnidirectional radio range
Chapter 1
INCORPORATING HUMAN FACTORS KNOWLEDGE

"Automation, of course, is not infallible either: The
literarure abounds with failures of automation to perform
as expected; [. ..] . These failures are among the reasons
why humans must be an integral part of the system - they
are there to compensate for the imperfections of the
autotnarion. They are also there I...]
to accept
responsibility for system safety. If they are to remain in
command, they must be involved in system operation -not
only when the automation fails, but during normal
operatiorls as well, in order to be in the loop when the
inevitable failures occur: The human operator is the final
line of defence in arttomared systems, and the new systems
proposed for air trafJic management are no exception."
Charles E. Billings: Aviation Automation - The Search for

a Human-Centered Approach.
1.1 In recent years a significant body of knowledge
has made a compelling case in support of the incorporation
of Human Factors knowledge into air traffic management
(ATM) system design from the early stages. This body of
knowledge is captured in a number of highly regarded
publications. Three such publications are discussed in the
following paragraphs.
1.2 The document Human Factors in the Design and

Evaluation of Air Trafic Control System, was developed in
1995 for the Federal Aviation Administration (FAA) by the
United States Department of Transportation. This document
states:
"Human error remains the most common contributing
factor in aviation accidents and incidents, yet strategies
for mitigating their impact are well known and widely
documented. Acquisition handbooks and system
engineering guides identify equipment design, training
and personnel selection, procedures, and organisational
structures and management as causal of human-system
interface discrepancies. Because each application of
new technology poses unforeseen difficulties in these
interface areas, technology must be centred on the
needs, capabilities and limitations of the user rather
than the capabilities of the technology. [. . .] Failing to
consider the performance of the human component of
the system increases program cost and schedule, and

jeopardises system technical performance. However,
ensuring that system designs are human-centred, will
lead to enhanced system performance, reduced safety
risks, lower implementation and life cycle costs, and a
higher probability of program success. It is never
efficient to play 'catch-up' with Human Factors in any
acquisition.
"Qualified Human Factors support during system

design and acquisition provides an engineering
perspective to the incorporation of information about
human capabilities and limitations related to how
people receive and process information, solve problems.
and interact with the system and its components. Where
sufficient information is not already available to address
a concern, the Human Factors discipline also offers an
arsenal of methods for obtaining time-tested and
objective performance measures. Tools and methods
used to analyse system performance with the human
component as an integral part can help to provide
reliable information on which to base developmental
and operational decisions, efficiently.
"One of the main goals of Human Factors engineers is
to ensure that the users' interests are considered in all
stages of system acquisition and development. In this
sense, the goal of the user and the Human Factors
specialists are the same - to ensure that the system is
usable and operationally suitable to the user, the task,
and the environment. However, the role of selecting the
optimal human-system interface should not be the sole
proprietorship of the user for three reasons. First,
system design decisions [. .]always involve complex
trade-offs among optimal performance, cost, and
competing technological alternatives. These decisions
require program management and engineering expertise
from a multitude of disciplines, including that of the
human engineering community. Second, decisions and
alternatives related to human performance may be
counter-intuitive unless scrutinised and analysed by
those skilled in quantifying the relationships. For
example, the decision to assign some system diagnostic
tasks to an operator or a maintainer may require
Human Factors guidelines for
1-2
detailed analyses of life cycle cost, alternative training

strategies, and personnel selection criteria. Third, users
a r e not always the best judges of what will provide
the best operational performance. For example, users
may want many more system features than they will
frequently use (such as excess display information)
which can lead to distracting clutter, confusion during
emergencies, and non-standard interfaces that complicate training and supervision. Having Human Factors
engineers involved in the acquisition process helps to
ensure that the system is easy to use, unlikely to induce
errors, and tolerant of common and uncommon human
performance anomalies.
"Human Factors need to be considered early in the
process, such as when the requirements are identified.
Reqcirements that are written with systematic and explicit consideration of Human Factors issues lay the
foundation for ensuring that these issues are addressed at
the earliest possible stage of development (or
procurement). Identifying potential Human Factors
problems early has the advantage of remedying
situations when they are easier and Iess costly to fix. Too
often, Human Factors engineers aren't involved in the
process until the developmental or operational testing
stage. Addressing Human Factors problems at this stage
can lead to costly changes in design, delays in
implementation, or degraded performance. While
managers in charge of programs are often, and understandably, reluctant to incur additional costs (such as
those associated with baselining human-system
performance or establishing human-in-the-loop performance criteria), ignoring Human Factors concerns
air trajjk managemenr (ATM) systems
can prove even costlier when errors are induced by

inadequate design."
1.3 This point is made also in a Eurocontml document

entitled Human Factors Module - A Business Case for
Human Factors Investment. The document identifies three
different strategies for dealing with Human Factors issues
in the life-cycle of an ATM system:
"As a way of dealing with Human Factors in the iifecycle, three different strategies can be found:
'Do nothing' approach: no initiatives are taken to
counter Human Factors prob!ems and only when problems
arise will they be addressed.
'Reactive' approach:
concern for Human Factors is

left to the last stages of the
development process.
'Proactive' approach:
fix the problems before they

occur.
"The cost scenarios of the three different strategies are

illustrated in Figure (1-11. The first ('do nothing')
approach illustrates how cost related with human
performance issues will increase rapidly over the lifecycle of the system. If some concern for human
performance issues is dealt with in the final stages of
the development process, the cost scenario will develop
in a less aggressive yet increasing manner.
a) No Human Factors integration
ctive Human Factors integration
tive Human Factors integration
f
Design
lmplementafion
Operation
Figure 1-1. Cost scenarios of three different life-cycle strategies
Life-cycie
Chapter I. incorporating Human Factors knowledge

"However, if an early awareness to the Human Factors
and human performance issues is introduced in a proactive manner, the cost will develop in a rather different
manner. The figure illustrates how cost is higher
compared to the other approaches due to the
investments made early in the process, but also how the
early anticipation of problems takes the air out of later
and more expensive problems.
'The reluctance to provide the necessary resources to
embark on a proactive approach is probably based on
the notion that it is better to wait and see where the
problems occur and then intervene. While this strategy
may, apparently, save some money, especially when the
system is being developed, experience shows that the
bili will have to be paid iater ... with interest.
"Unless Human Factors are emphasised as an important
part of the requirements for a new or adapted system,
contractors bidding for the contract are likely to leave
them out to save cost (and therefore increase the
likelihood of winning the contract). Therefore, the
requirements from any system development or from
making changes to an existing system need to address
Human Factors specifically.
"In summary, we can make the following observations:

70% of cost are determined in the first 10% of the
project;
The change of design when the system has been
built and is operating will cost 60 to 100 times
more than the same change if it takes place during
the initial phases of the design.
'To put it briefly, it is a matter of either paying up front

for detecting and resolving the problems - or paying
moE later, which by a11 accounts, will be significantly
more costly."
1.4 The third and final selection in this chapter is
taken from the ICAO Human Factors Training Manual
@oc % 8 3 - M 5 0 ) . where a quotation from Professor Earl
Wiener (University of Miami) underscores that, compared
to the everyday operating costs induced by inadequate
design, the front-end cost associated with human-centred
technology in the conceptual stages is negligible:
'There is an 'iron law' that should never be ignored. To

consider Human Factors properly at the design and
certification stage is costly, but the cost is paid only
once. If W operator must compensate for incorrect
design in his training program, the price must be paid
every day. And what is worse, we can never be sure that

when the chips are down, the correct response will
be made."
'
Conclusion
1.5 The overall safety and efficiency of the aviation

system depends on human operators as the ultimate
integrators of the numerous system-elements. This dependence is un!ikely to decrease, and may even increase in
unanticipated ways, as additional advanced technology is
implemented. To a greater extent than ever before, understanding and accounting for the role of humans, including
their positive and negative contributions, will be important
to maintaining and improving safety while improving
efficiency.
1.6 This manual provides Human Factors guidance
material that will enable global and regional planners and
developers to ensure that Human Factors issues are
properly considered at the appropriate stages of planning
and development. At the same time, this manual provides
guidance on Human Factors aspects to States and organizations that are about to acquire^and implement CNSIATM
technology for the provision of air traffic services. The
objective is to facilitate a successful transition to ihe
CNSlATM environment.
References
Billings, Charles E., Aviation Automation - The Search for
a Hum-Centered Approach, Lawrence Erlbaum
Associates, Mahwah, NJ, 1997. (ISBN 0-8058-2127-9.)
Cardosi, Kim M. and Elizabeth D. Murphy (eds.), Human
Factors in the Design and Evaluation ofAir Traflc Control
Systems, United States Department of Transportation,
Research and Special Programs Administration, John A.
Volpe National Transportation Systems Administration,
Cambridge, MA, 1995. (DOT/FAA/RD-9513 DOTWSC-FAA-95-3.)
Human Factors Module - A Business Case for Human

Factors Investment, Eurocontrol. Brussels, 1999.
(HUM.ET1.ST13.4000-REP-02,
EATCHIP/EATMl?
Edition 1.0.)
Human Factors Training Manual, ICAO, Montreal, 1998.
(DOC9683-ANl950.)
1. Wiener, E.L., "Management of Human Error by Design",
Human Error Avoidance Techniques Conference Proceedings.

Society of Automotive Engineers, Inc., 1988.
Chapter 2
THREE ESSENTIAL CONCEPTS

2.1 INTRODUCTION
2.1.1 In order to provide a common platfoim for
discussions on the development, acquisition and implementation of ATM systems, this chapter introduces three
concepts essential to such discussions. These are the
concepts of Human-centred Automation, Situational
Awareness and Error Management.
2.1.2 Each concept is discussed in detail with special

emphasis on its relevance for air traffic management. The
discussion on Situational Awareness includes a listing of
specific consequences for the design, implementation and
operation of ATM systems. The discussions on Humancentred Automation and Error Management include highlevel conclusions which should be borne in mind
throughout the processes of development, acquisition and
implementation of ATM systems.
responsible for the "care and feeding" of the computer. In

contrast, a human-centred approach provides the operator
with automated assistance that saves time and effort; the
operator's task performance is supported, not managed, by
computing machinety.
2.2.3 The ICAO Human Factors Training Manual
(Doc 9683-AN/950), Part 1, Chapter 3, introduces the
principles of human-centred automation as developed by
Dr. Charles E. Billings. This section applies these general
principles to the aviation domain and, in particular, to the
M C domain.
Principles of Human-centred
Aviation Automation
Basic Assumptions
The pilot bears the responsibility for safety of flight.
2.2 HUMAN-CENTRED AUTOMATION
Introduction
Controllers bear the responsibility for traffic separation

and safe traffic flow,
Fundamental Principles
Pilots must remain in command of their flights.
2.2.1 Hardly anyone working in a radar environment

would want to return to the days prior to the introduction of
radar into air traftic control (ATC). There is no question
that the display of radar targets eases the burden on the
controller of remembering aircraft positions and projecting
those positions in relationship to each other. Similarly,
despite the uncertainties associated with increased automation, it is beyond argument that additional automation is
needed to enhance controllers' abilities to handle increased
WIG demands. What is at issue is the specific design of
new automated tools and their capabilities.
2.2.2 Automated aids can be designed from a
technology-centred perspective or from a human-centred
perspective. A technology-centred approach automates
whatever functions it is possible to automate and leaves the
human to do the rest. This places the operator in the role of
custodian to the automation; the human becomes
Controllers must remain in command of air M i c .

Consequences
The pilot and controller must be actively involved.
Both human operators must be adequately informed.
The operators must be able to monitor the automation
assisting them.
The automated systems must therefore be predictable.
The automated systems must also monitor the human
operators.
Every intelligent system element must know the intent
of other intelligent system elements.
Factors guidelines for air traffic managenlent (ATM) systems
Applied Human-centred Automation in ATC

2.2.4 In a technology-centred approach, whatever
automated functions that can be provided to the controller
to assist in managing aircraft and increasing capacity are
provided. This is different from a human-centred approach
which aims to provide only those functions that the
controller needs, based on information and task requirements. While the goals of the automation remain the same,
i.e. to assist the controller in managing aircraft and to
improve system performance, the approach taken to
automation will determine which functions are automated
and how the controller will use these automated functions.
2.2.5 A human-centred approach is applied by
systema~ically mapping user requirements to technical
solutions (e.g. hardware and software that will satisfy
requirements). A human-centred approach also requires
careful evaluation of the usability, suitability and acceptability of the design products. Such ?n evaluation benefits
controllers by ensuring that the tools and capabilities
provided by the computer system are in fact the ones
needed by controllers to do their jobs.
2.2.6 Possible ways in which human-centred
automation can support controllers have been suggested by
Charles E. Billings in an analysis of aircraft automation and
its effects on flight crews (Human-centered Aircrafi
Automation: A Concept and Guidelines). The following
recommendations are based on the conclusions of that
report:
*
Humans must remain in command of flight and air

traffic operations.
Automation can assist by providing a range of planning
and control options.
Human operators must remain involved in the task.
Automation can assist by providing better integrated
and more timely information.
Human operators must t>e fully informed about the
purposes and functioning of automated processes. At no
time should the controller be wondering, "What is the
automation doing" or "why is it doing that?"
Automation can be designed on the basis of a coherent
model of its use, which can be explicitly communicated
to users; automation should assist users by providing
explanations of its intentions, recommendations and
actions.
Human operators must have the information needed to

anticipate and resolve problems. Automation can assist
by monitoring trends, providing decision support and
making required information accessible when it is
needed.
2.2.7 The specification of requirements and review of
design products based upon considerations such as those
outlined above contribute to ensuring that ATC automation
remains human-centred.
High-level objectives
2.2.8 There are three higher-level objectives for ATC

automation: usability, operational suitability and workforce
acceptance.
2.2.9 Usability is a function of measurable easc-ofuse outcomes, such as the ease of navigating through a
menu structure, ease of remembering data-entry requirements (e.g. command formats and sequences), and ease of
locating specific items on a visual display. Overall ~~sability
depends on several interdependent factors, such as reliability of system performance, organization of the user
interface, and maintainability in the field. Establishing
usability goals and evaluating design products against these
goals are key system development activities in which
controllers, as end-users, should participate.
2.2.10 In order for a design to be operationally
suitable, it must support the controller's effective and
efficient planning, maintenance of situational awareness,
separation of aircraft, and performance of other ATC tasks.
Support is provided to the controller by the design
primarily in the form of information about the ATC
situation and the status of ATC equipment and facilities. A
design can be usable but operationally unsuitable if it does
not meet the controller's requirements for appropriate and
timely information. Early indications of operational suitability can surface in systematic field evaluations. The
ultimate tests of operational suitability occur later during
rigorous site-implementation evaluations.
2.2.11 Workforce acceptance derives, in part, from a

design's reliability, usability m d operations! suitability.
Acceptance also depends on the impact that new ATC
technology has on controller job satisfaction, and in
particular, on the intrinsic motivation the job holds for the
controller. It may be the case that sources of job satisfaction
in the current system, such as opportunities for individual
recognition by one's peers and managers, are disrupted or
removed by the new technology.
Chapter 2.
Ttlree essential concepts
Human Factors objectives for ATC automation

2.2.12 As a basis for ensuring that the design is
usable, operationally suitable and acceptable to the workforce, it is useful to specify Human Factors objectives for
the new ATC automation and its operation. A set of
objectives for automation that should be considered during
the specification of requirements and development follows:
transparency of underlying software operations so that
the controller does not need to be aware of the inner
workings of the computer but perceives a smooth,
responsive operation;
2.2.16 Error tolerance and recoverability. The

objectives of error tolerance and recoverability fall
primarily under operational suitability, but they are related
to the other goals as well. Error-tolerant designs allow for
the conceptual equivalence of different commands (e.g.
Exit and Quit) and will accept any of the pre-defined
equivalents. Further, error-tolerant designs anticipate
possible user errors in data entry and inciude capabilities to
trap errors before they spread through the system. Errortolerant designs routinely query the user at critical choice
points (e.g. "Are you sure you want to delete this flight
plan?'). Under such design, recovery from error is simple
and usability is enhanced.
error-tolerance and recoverability;

consistency with controllers' expectations;
compatibility with human capabilities and limitations;
ease of reversion to lower levels of automation and of
returning to higher levels of automation;
ease of handling abnormal situations and emergencies:
and
ease of use and learning.
2.2.13 For any specific design, these objectives will
need to be further specified in terms of individual system
functions and operational objectives.
2.2.14 Transparency of underlying operations.
Internal software operations will not be apparent to the
controller if design meets the high-level objective of
usability. For example, if it is dificult for the controller to
maintain a sense of orientation within a user-interface menu
structure, it is likely that programming convenience has
taken priority over usability goats.
2.2.15 Software operations will be transparent to the
controller if ATC tasks can be performed naturally or
intuitively without needing to pay conscious attention to
underlying computational structures. Thus, transparency
also relates to operational suitability. On the other hand, a
non-(ransparent (or opaque) user interface is likely to have
adverse consequences for job satisfaction because it wiil be
difficult to understand and use. It will add complexity to
operating the system and distract from the real task at hand,
i.e. controlling aircraft. It will foster negative attitudes, such
as frustration and resentment. These questions should be
dealt with early in design development so that systems
deployed in the field for early field evaluation and later site
testing will be more usable, operationally suitable and
acceptable.
2.2.17 Corsistency with controUers' expecta?ions.

Automation that does not assess a situation in the same way
a controller would, or does not take the same actions as a
controller would, is likely to elicit scepticism or
inappropriate actions from the controller. Controllers will
be more likely to accept, tmst and use automated functions
that handle situations in the same ways as a controller
would. To be most useful to the controller, the design of
automated functions should take into account air traffic
procedures and operations (e.g. airspace and traffic
management restrictions, rules for assignment of flight
levels), so that the automation dces not violate common
practices.
2.2.18 Compatibility with human capabilities and
limitations. People are, by nature, poor monitors of
automated processes. Controllers cannot be pui in the
position of passively monitoring the automation and then be
expected to be able to detect a failure, determine the
problem, and take appropriate action. On the other hand,
people are good at analysing novel or unforeseen situations
and selecting strategies to cope with these. Automated
functions must be compatible with human capabilities and
limitations.
2.2.19 Ease of reversion to lower levels of

automation. After operating with a highly automated
system for some time, returning to lower levels of
automation (e.g. as in the case of system degradation or
failure) may be problematic for several reasons. First,
controllers may experience a loss of proficiency.. For
example, if an automatic conflict-resolution function is
used extensively, controllers may rarely have to resolve
potential conflicts between aircraft. Their problem-solving
skills and strategies are not likely to be as finely tuned as
when they had to prevent and solve the problems with only
basic support from au!omation. Complex skills suffer from
disuse. Provisions for maintaining these skills (such as
Factors guidelinesfor air traflc management (ATM)systems
recurrent training) must be considered in these circumstances. Second, a controller's ability to respond may be
affected by a toss of Situational Awareness. Controllers
who are left "'out of the loop" will lose their Situational
Awareness and possibly become bored and inattentive. This
will increase the time required for the controller to take
over from the automation and will be detrimental to the
quality of the controller's response. Automated systems
have to include an active, involved role for the controller, so
that the controller always retains enough Situational
Awareness to handle whatever problems arise. Finally, the
controller will not be able to recover from an automation
failure if the number and complexity of operations being
managed by the automation exceeds basic human
capabilities.
2.2.23 The philosophy of human-centred ATC

automation emphasizes the need for allocating functions in
such a way that the controller's Situational Awareness is
continually maintained and updated, and that the
controller's expertise and creativity are exercised regularly.
It suggests that dynamic or adaptive function allocation be
considered as a technical solution. Under adaptive function
allocation, the controller can prepare for periods of heavy
traffic by allocating nomally manual functions to the
computer, and the controller can prepare for tighter traffic
periods by taking on some functions (or portions of
functions) normally accomplished by thc computer. Under
a static allocation policy, flexibility of assigning functions
is not possible.
2.2.20 Ease of handling of abnormal situations and

emergencies. Controllers need to have the information and
the means that are required to intervene in emergencies or
abnormal situations. Controllers should not be denied
access to conrrols or critical information that they may need
to respond to these situations. For example, a system
dcsigned to automatically handle all communications with
aircraft would be unacceptable unless alternative provisions
were available for thc controller to communicate with
aircraft as necessary. Such design should also provide direct
controller access to critical flight information regarding all
aircraft in the sector.
Human-centred Automation - Summary
2.2.21 Ease of use and learning. Automated

functions should be easy to learn and use. The implications
of the use of automated functions on training requirements
should be examined. Complex systems may require extensive training on the various operational modes and
limitations. Recurrent training may need to address
problems that are possible but rare.
2.2.24 The following excerpt from the bnok Aviarion

Auiomarion - The Search for a Human-Centered Approach
by Charles E. Billings provides an appropriatz concluding
summary to the concept of Human-centred Automation as
discussed in this section.
"Although humans are far from perfect sensors,
decision-makers, and controllers, they possess three
invaluable attributes. They are excellent detectors of
signals in the midst of noise, they can reason effectively
in the face of uncertainty, and they are capable of
abstraction and conceptual organisation. Humans thus
provide to the aviation system a degree of flexibility
that cannot be attained by computers. Human experts
can cope with failures not envisioned by aircraft and
aviation system designers. They are intelligent: they
possess the ability to learn from experience and thus the
ability to respond adaptively to new situations.
Computers cannot do this except in narrowly defined,
completely understood domains and situations.
ATC automation philosophy

2.2.22 Before evaluating automated systems, it is
useful to think in terms of a human-centred philosophy of
PifC automation. Such philosophy considers automation as
assisting, not replacing, the controller. It recognizes that
there is more overlap than ever in the capabilities of the
human and the computer. It does not divide tasks between
controller and computer according to simplistic approaches
depicting computers as "better-than-the-human" at some
tasks and humans as "better-than-the-computef' at other
tasks. This philosophy advocates a synergistic taskallocation strategy that benefits from the best of controller
and computer capabilities, rather than leaving to the
controller only those tasks (or bits of tasks) that the
designer finds difficult to automate.
'The ability of humans to recognise and bound the

expected, to cope with the unexpected, to innovate, and
to reason by analogy when previous experience does
not cover a new problem are what has made the
aviation system robust, for there are still many
circumstances, especially in the weather domain, that
are neither controllable nor fully predictable. Each of
these uniquely human attributes is a compelling reason
to retain human operators in a central position in
aircraft and in the aviation system. Those humans can
function effectively, however, only if the system is
designed and stnrctured to assist them to accomplish
the required tasks. As technology continues to advance,
it will become increasingly urgent that its applications
on the flight deck be designed specifically around the
Chapter 2.
Three essential concepts
human who must command them; in short, future

aviation automation must be human-centered if it is to
be a maximally effective tool.
"At the same time, many machines today are capable of
tasks that unaided humans simply cannot accomplish.
This is true in both the perceptual and cognitive realms.
An example today is the calculation of optimal orbital
trajectories for systems such as the Space Shuttle;
another is the determination of a great circle navigation
route. For these tasks, computers and automated
systems are an absolute requirement. Competitive
pressures in aviation being what they are, it is'likely
that still more complex automation will be offered in
the marketplace, and there will be a tendency to accept
it. If this tendency toward greater complexity is to be
countered, it must be by the customers: airlines and
other operators must decide whether the potential gains
are worth the certain costs."
perception of the elements in the environment within a

volume of time and space, the comprehension of their
meaning, and the projection of their status in the near
future"'. ?'he following section discusses in detail the
elements that are relevant to SA in the ATC environment.
For each element, the relationship to the design,
implementation and operation of an ATM system is
provided.
Elernenis of Situational Awareness in ATC

2.3.4 The elements listed below are highly dynamic
and present subtle to large changes that may occur at short
notice, and that can or will influence the way a controller
works at any particular moment. How these changes
interact with a controller's SA may only be recognized after
having gained considerable experience in ATC in general,
and at a specific location in particular:
personal factors
2.3 SITUATIONAL AWARENESS
Introduction
2.3.1 The ICAO World-wide CNSIATM Systems
implementation Conference, held in Rio de Janeiro, Brazil,
in 1998, concluded, inter alia, that "the most important
Human Factors issue in regards to human-technology
interface is the ability of the human operator to maintain
situationaYsystem awareness. It is an established fact that
human-technology interfaces have not always been
intuitive. Non-intuitive, 'opaque' interfaces lead to operational complexity which often forces the operator to
allocate increased attention to maintain an adequate mental
model of the situationfsystem status. This becomes the
breeding grounds for loss of situational awareness,
decreased system performance and eventually human error
and safety breakdowns." (The Role of Human Factors in
CNSIATM Systems Guidelines, ICAO, 1999.)
weather
airport infrastructure
individual differences
traffic
operators and pilots
environment
navigational aids
aircraft performance
equipment
adjacent units.
Personal Factors
2.3.2 Tme as this statement is; it may not always be
clear what exactly is meant by the term "Situational
Awareness" (SA). In particular there appears to be
confusion between thinking of SA as simply knowing the
relative position of other traffic in the vicinity of one's own
aircraft (pilots), or "having the picture" or awareness of the
traffic situation (controllers), as opposed to knowing what
is happening in a far wider sense.
2.3.3 The accepted definition of SA from the

scientific community would seem to support the wider
interpretation of the phrase: "Situational Awareness is the
2.3.5 A person's physical and mental state will very

much determine the interaction with other persons and will
also influence the performance of certain tasks by that
person. Simply put, someone who does not feel well will
probably be performing in a less-than-optimal fashion.
1. Endsley, M.. quoted in Siruarion Awareness Information

Requiremenrs for En Roure ATC, (DOT/FAA/AM-94/27).
Office of Aviation Medicine, Washington D.C.,December
1994.
2-6
Human Factors guidelines for air traffic management ( A T M ) system
2.3.6 In ATC, typical physical comfort factors

affecting individual performance include the ambient
temperature (too cold/too hot), lighting (too brightltoo
dark), humidity, as well as the noise level at the working
place. Knowing that any of these factors is present, or could
occur, when at work helps to shape the SA of a controller.
2.3.7 For example: when realizing that the noise level

is higher than usual, a controller may wish to give extra
care to ensuring that radiotelephony (FUT) readbacks are
correct. Similarly, the controller may take more care to
ensure that the microphone is close to the mouth.
2.3.8 Another important personal factor is being
aware of personal stress level. A controller with a high SA
wilt realize when stress (usually caused by external factors)
influences performance and may arrange to be relieved
from the working position earlier or more often than usual.
1.3.9 The last personal iacror discussed in this section
i s fatigue. Recognizing fatigue is not easy, but recognizing
the cvndirions that can cause fatigue increases the SA. The
onset of fatigue should be expected after working a high
number of consccutivc shifts, after a period with intensive
physical activity during off-duty hours, or towards the end
of a single nightshift. If such conditions apply, it may not
be prudent to work the busiest position in the operations
room if less busy positions are available. A controller with
a high SA will know that when fatigue could be a factor all
actions should be double-checked, and high attentiondemanding traffic situations should be avoided, if possible.
2.3.10 Consequences for the design, implementation
and operation of ATM systems
In the design of ATC workstations, and of the entire

ATC operations room with multiple workstations,
ergonomic principles should be taken into consideration. These ergonomic principles are discussed in the
ICAO H u m n Factors Trainiizg Manual, in the FAA's
Human Factors Design Guide, and in the book H u m n
Factors in Air Traflc Control by V. David Hopkin.
When analysing and developing safety-related working
conditions for air traffic controllers, consideration must
be given to the reduction of stress- and fatigue-inducing
factors. Stress and fatigue in ATC are discussed in the
ICAO Human Factors Training Manual.
2.3.1 1 SA is heightened by knowing the current

weather and the forecast trend for at least the duration of a
controIler's shift. For example: changes in wind direction

may involve runway changes. The busier the traffic, the
more crucial becomes the timing for a runway change. A
controller will plan strategies to make the change with a
minimal disruption to the traffic flow. For en-route
controllers, knowing areas of significant weather will help
to anticipate requests for re-routings or circumnavigation.
2.3.12 Appropriate knowledge of local weather

phenomena (e.g. turbulence over mountainous terrain; fog
patterns, intensity of thunderstorms, etc.) and/or sudden
weather occurrences like windshear or microbursts
contributes towards greater SA. A controller with a high SA
will apply more effective solutions in special circumstances.
2.3.13 Consequences for the design, implemeritation
and operation of A?U systems
Provisions should be included in systems design so that
updated and accurate weather information is availahle
to air traffic controllers at all times.
When designing traffic situation displays, available
weather data should be integrated in real time and in
graphical format on the display.
Airport infrastructure
2.3.14 Constant awareness of runway availability at

the airport(s) under the jurisdiction of a controller allows
adequate response in case of emergencies requiring an
immediate diversion. Such awareness should include not
only the runway physical characteristics but also
information on work in progress that might preclude
runway use at any particular time.
23.15 For aerodrome controllers, awareness of work

in progress is not limited to runways but must also include
taxiways and aprons, as well as special considerations such
as temporary obstructions to visibility from the tower by
construction work.
2.3.16 Knowing how the airport looks from a pilot's

point of view -not just during the approach but also when
taxiing - increases the SA of aerodrome controllers.
Which visual aicis (e.g. lighting, signs) can be referred to
when explaining a reqaired routing to a pilot? A controller
who possesses such awareness will be more successful in
transfemng routing information.
Chaprer 2.
Three essential conceprs
2-7

and operation of A l l 4 systems

and operation of P31U systems
Provisions should be included in the design of control

facilities so that information on the status of airports
under their jurisdiction is available to controllers at all
limes.
AT(: training programmes in general should include

teamwork training. Training programmes associated
with the implementation of advanced systems should in
particular include teamwork training. Teamwork training in ATC is described in Guidelines for Developing
and Implementing Team Resource Management
(Eurocontrol).
Training practices should provide the possibility to

aerodrome controllers to regularly familiarize
themselves with the visual aids at their airport.
Individual Differences
2.3.18 Controller performance is expected to meet

minimum standards. Controllers must perform according to
these minima, but there are differences in the degree to
which each individual controller performs in excess of the
minimum standards. At any given facility, controllers are
aware of these differences and will subconsciously or even
consciously take each other's strengths and weaknesses
into account when working together.
2.3.19 Humans, unlike machines, do not perform
exactly the same way over and over again. One of the ways
in which this human attribute manifests itself in ATC is the
feeling of "being a little rusty" after not having worked in
a certain position for a certain time (even though that time
is within the regulatory requirement). Recognition of this
variation in performance level among people is an
important component of SA.
2.3-20 The smial gradient influences each specific

work situation within ATC facilities. This social gradient is
also found in flight decks, where a situation in which a
young captain working with an older first officer is
different from a situation in which an older captain is
working with a younger first oficer. Substituting "captain"
by "supervisor" and "first officer" by "controller" allows to
see how social gradients could affect an ATC work situation
and influence SA.
2.3.21 The last discussion item in this section involves
on-the-job training (Om.Knowing that there is training
in progress at an adjacent position, or at a position .or
facility with which frequent coordination is necessary, will
influence the way a controller works. The degree of
influence can be subtle, such as in adopting a slightly more
formal phraseology during coordination, o r overt, such as in
accepting, for the benefit of the training. proposed solutions
for MIC
conflicts o r handovers that normally would be
regarded as less favourable.
2.3.23 Awareness of the exact traffic situation is a

very important element of a controller's SA. In addition to
"having the picture" of where all aircraft under the
controller's jurisdiction are and will be next, it is equally
important to be aware of the development of the traffic
situation. Is it the beginning of a peak period, or is it the
end of it? W111 there be additional traffic, such as photoflights, training flights, calibration flights and so forth? Any
of these aspects can influence the way in which a controller
will handle traffic.
2.3.24 A controller's awareness of the normal traffic
patterns will help 'determine options for solving conflicts.
These patterns are not necessarily the same as the airways,
standard instrument arrivals (STARS) andor standard
instrument departures (SIDs) depicted on maps, which
implies that a controller may only learn them over time, or
by experience.
2.3.25 A further aspect that may influence a
controller's SA is awareness of the flow of the traffic under
management. If a considerable amount of traffic is expected
to move in the same general direction (e.g. to or from one
particular aerodrome; north/east/south/westbound; and so
forth), solutions different from those when traffic is moving
randomly will be applied.
Design and organizational practices should ensure that
all relevant information on the traffic situation and its
development is available to the controller at all times.
Operators and Pilots
2.327 Viewing surface operations at unfamiliar

aerodromes is not unlike being in a strange city for the first
time. There are signs providing names and directions, as
well as maps with routes, but it takes time to properly
Factors guidelinesfor air traffic rnotragernenr IATM) system
interpret all that information. It is always useful if a person

familiar with the place can provide further instructions.
Aerodrome controllers. especially ground movement
conlmllers. are often in the role of the "familiar person': If
their SA is high, they will recognize operators and pilots
with a low familiarity level with the local circumstances,
and they can provide adequate assistance. (Recognizing
potentially unfamiliar operators is relatively easy by
looking at the company or aircraft colours or may be
evident from the call sign. Recognizing potentially
unfamiliar pilots could be more difficult.) To a certain
extent this also applies to area and approach conuollers,
with respect to their familiarity with specific, national or
local procedures.
2.3.28
'%orprate culture", in terms of the
differences among airlines, has received considerable
attention in aviation safety circles over the last few years.
Subconscious awareness of these differences exists among
controllers, who have learned to take the subjective
performance level of the various operators into account.
Solutions or manoeuvres that are acceptable to (and
therefore applied to) one operator are not proposed to other
operators. This awareness is part or a controller's SA.
2.3.29 A third aspect. distinct from and yet closely
linked lo the other two mentioned here, is worth
mentioning: a pilot's RIT level. Conlmllers get important
cues from the degree of proficiency in RIT that a pilot
displays, both in procedure and in vocabulary. and -given
the right degree of SA - will adjust their RIT accordingly
with respect to the complexity of instructions andlor
procedures.
2.3.32 Awareness of the terrain characteristics

could lead a controller to choose different solutions in given
situations to those that might have been applied without
that awareness. This could relate also to the familiarity
level of the operator involved.
2.3.33 Awareness of the noise sensitivity of
populated areas in the environment of an airport may be a
factor when cettain runway combinations must be
considered. Even when not many options are available. the
environment may dictate certain changes in the runway use
to be effected at certain times of day fcu~fews;
landingldeparture runway change; and so on). Awareness of
the part of the environment affected by traffic patterns or
runway(s) in use at any time is therefore part of an
aerodrome controller's SA.
When designing traffic siluation displays, the inclusion

of maps depicting relevant terrain, obstacles and noise
sensitive areas should be considered.
When designing advanced ATM syslems, the inclusion

of a minimum safe altitude warning (MSAW) system
should be considered.
Organizational procedures should be in place to keep

air traffic controllers constantly updated of temporary
changes in the surrounding environment.
NavigalionaI aids
2.3.30 Consequences for the design. implementation

Training programmes for air uaffic controllers should

include awareness of the importance of specific aspects
of diKerences between operators and between
individual pilots.
Environment
2.3.31 Although the environment could be considered

of a semi-permanent nature, and therefore irrelevant as an
element of SA. there are certain aspects that are important
enough to warrant mention in this section. Aemdmme
controllers need, for example. to be aware of the significant
obstades at and around their airpoii. This includes keeping
track of new construction in the vicinity and the machinery
associated with const~ctiono r maintenance work at
airpons.
2.3.35 An obvious aspect of this element is

availability. i.e. whether the navigational aid (navaid) is
serviceable or not, but there are further considerations. A
navaid (or way-point) may be situated in the area for which
a conwoller is responsible. but pilots may not have
immediate access to its frequency or coordinates. If a flight
is following a standard instrument departure (SID) that is
based on specific navaids and is cleared to proceed to a
navaid or way-point that is not specified in the SID, the
pilots might be unable to locate the navaid. A conlmller
with a high SA either will use navaids and way-points that
are likely to be familiar to the pilots concerned or will use
radar vectors to overcome these problems.
2.3.36 Similarly. controllers need to consider the
performance level of navaids. Navaids should work
according to operational specifications. but this is not
always the case even though the aids meet the required
technical specifications. Experienced controllers will
Chapter 2.
develop awareness of specific conditions impairing navaid

performance. This awareness is part of their SA.
(3 050 m) above mean sea level, thus res~rictingthe options

for applying vertical separation with such aircraft.

and operation of AIM systems

and operation of P;IU systems
Equipment design and organizational procedures should

ensure that:
Organizational procedures should be established to

ensure that verified information on the type of aircraft
of a flight under a controller's jurisdiction is available
to the controller at all times.
Information on the status of navigational aids is

available to the controller at all times.
Procedures applicable in case of failure of navigational
aids are established.
Training for air traffic controi1ers should include
proficiency in the application of procedures related to
the failure of navigational aids.
Training programmes for air traffic controllers should

include awareness about aspects of differences and
variations in aircraft performance.
ensure that controllers have the possibility to make
regular familiarization flights to observe from the flight
deck the possibilities and limitations of relevant types
of aircraft.
Aircraft Performance
2.3.38 Controllers are taught general awareness of

differences in aircraft performance, e.g. between jets and
propellerdriven aircraft. However, there may be more
subtle differences. An aircraft serving a destination that is
only two hours' flying time from the departure airport has
different performance characteristics than a similar aircraft
taking off for a ten-hour flight. This difference affects
aerodrome and area controllers alike. A controller with a
high SA will take cues from the flight plan information
available, or even just the call sign (flight number), to
assess the expected performance of each flight and will
adjust control strategies accordingly.
2.3.39 A further factor may be the way in which an
aircraft is usually operated by the various companies.
Climb speeds, rates and/or angles may differ although the
aircraft type is the same. Familiarity with such differences
adds to a controller's SA.
2.3.40 Controilers also need to be aware of potential
degradations in aircraft performance, either as a result of
atmospheric conditions or as a result of technical problems.
2.3.41 Different types of aircraft have different
possibilities and limitations, and awareness about these
will increase a controller's SA. For example: modem
aircraft have the capability for off-set navigation, to
construct non-standard way-points, or can provide accurate
wind information. Older aircraft often lack these
capabilities and should therefore be handled in a different
way. As another example, non-pressurized aircraft will
normally not accept altitudes of more than 10 OOO ft
Equipment
2.3.43 In line with the previous discussion on navaids,

awareness about ATC equipment availability is essential.
This includes spare (or back-up) equipment and equipment
scheduled to be temporarily taken out of semce for
maintenance.
2.3.44 The reliability of the equipment is an
important factor. A high number of failures with a certain
radarscope will dictate prudent use when working the
position, including tactics such as accepting less traffic or
applying wider separations than under normal circumstances.
2.3#.45 Also similar to the discussion on navaids, the

performance of the equipment may not be optimal under
all co~nditions.Awareness of these conditions, and the
associated degradations in performance, increases a
controller's SA.
2.3.46 Degradations may also occur as a result of
technic~alproblems. The ability to recognize the problems,
and know what the consequences are, are all part of a
controller's SA.
ensure that information on the status of ATC equipment
is available to the controller at all times.
Factors fuidelines for air traffic mMn8ement (ATMJsystem
Procedures that are applicable in case of failure of ATC

equipment must exist.
Controller training must include proficiency in the
application of procedures related to the failure of ATC
equipment.
Adjacent UniLs
2.3.48
2.3.52 When designing new systems and supporting

procedures that include the goal of "enhancing the
Situational Awareness of the controller': care must be faken
to address all the elements from chis section. As a
minimum, the controller should be formally provided with
up-to-date information on the traffic, weather. airport
infrastructure. navigational aids, the status of the system
itself. and the adjacent units. Such information should be
available to the controller when required or presented to the
controller in case of significant changes.
Ceriain aspects discussed under the heading
Individual Diflerences are also applicable to the traffic
exchange among ATC units. Awareness of the actual

performance level of different units, and the ability to
compare this to a perceived average performance, are part
of a controller's SA and may influence the choice of
strategies. In some cases, a shift takeover in an adjacent
centre has a significant bearing on the way traffic is handled
by that unit and subsequenrly affects traffic exchange with
that unir.
2.3.49 A controller with a high SA will also be aware
of possible limitations that adjacent units may experience.
For example. significant weather may complicate adherence
to agreed handover procedures. Another example could be
staff shortages or equipment problems. In some cases this
may lead the adjacent unit@) to declare a lower capacity
than usual.


ensure that information on the status of adjacent centres
is available to the controller at all times.
ensure that controllers have the possibility to make
regular familiarization visits to adjacent centres in order
to observe the working practices in those centres.
Situational Awareness -Summary

2.3.51 Situational Awareness in ATC comprises more
than knowing where all the traffic is at a given moment and
what is the relative direction of movement of each aircraft.
For air uaff~ccontrollers SA includes all the elements
discussed in this section. Consideration of all elements may
be done consciously o r unconsciously, and some elements
can have a higher imponance in one situation than in
another.
2.4
MANAGING ERROR
Introduction
2.4.1 The last two decades have witnessed a notable
shift in the way #heaviation industry regards hvman error.
In the past, it was generally considered that human error
was an individual trait that could be prevented by the right
training and attitudes. Specific to CNSIATM systems it was
considered that emor-free systems could be designed by
automating as many human tasks as possible. RepoN from
aviation incidentlaccident investigations commonly coneluded that '+pilot error" or "controller error" was the cause
of the event under investigation.
2.4.2 Automation. however. did not eliminate error,

and serious accidents kept oecumng in aviation as well as
in o!her high-technology envimnments (e.g. the nuclear,
aerospace and oil industries). Studies on safety in "complex
socio-technological systems" further demonstrated that
automation had a tendency to change the place where
human e m r could occur in the system and sometimes even
potentially increased the magnitude of human error as a
result.
2.4.3 The model developed by Professor James
Reason. of the University of Manchester (UK), provides
insight into enor generation within organizations and what
organizations can do to prevent it. (See Figure 2-1.)
Note- A detailed discussion of the Reason model is
pmvided in the ICAO Human Factors Training Manual.
2.4.4 The Reason model proposes that accidents

seldom originate exclusively from the errors of operational
personnel (frontline operators) or as a result of major
equipment failures. Instead, they result Emm interactions of
a series of failures or flaws already present in the system.
Many of these failures are not immediately visible. and they
have delayed consequences.
Chapter 2.
Three essential concepls
2-11
Limited window of
accident opportun ity
Active a n d latent failures

Active failures
Latent failures
Latent failures
Latent failures
Figure 2-1. The Reason model
Factors guidelinesfor air rrafic management (ATM)sysrems
2.4.5 Failures can be of two types. depending on the

immediacy of their consequences. An active failure is an
error or a violation that has an immediate adverse effect.
Such errors are usually made by the frontline operator. A
latent failure is a result of a decision or an action made
well before an accident. the consequences of which may lie
dormant for a long time. Such failures usually originate at
the decision-maker, regulator o r line-manager level, that is.
with people far removed in time and space from the
resulting event. These failures can also be produced at any
level of the system by the human condition. for example.
through poor motivation or fatigue.
2.4.6 Latent failures, which originate from inevitable
downsides of strategic decisions, may interact to create "a
window of opponunity" for a pilot. air traffic controller or
mechanic to commit an active failure that breaches all the
defences of the system and results in an accident. The
frontline operators are thus the inheritors of a system's
defects. They arc the ones dealing with a situation in which
technical problems, adverse conditions or their own actions
will trigger the latent failures present in a system. In a wellguarded system, latent and active failures will interact, but
they will seldom breach the defences.
2.4.7 Based on the work by Reason and others.
aviation incidentlaccident investigators are coming to
realize that "human error" is not the end of the investigation
process but rather its starting point. The objective of
investigations thus becomes to find out why these errors
were made, how they could have led to disaster in a
particular case and. subsequently. to make recommendations for improving the safety of the overall system.
2.4.8
correct the problem. In fact, by separating the composition

stage and the printing stage, an opportunity to correct a
multitude of errors is created.
24.10 The concept of error resistance can also be
illustrated using the example of a personal computer. Many
potentially deswctive commands will first rrigger a
"'question" from the computer to confirm that the user
really wants the programme to execute that command and
often q u i r e a second input from the user before the
programme performs the action. Examples are: deleting
files, formatting disks and terminating applications
(programmes) before saving work done with those
applications. Personal computers therefore by design can be
seen to resist potential user errors that would negate the
purpose of using the computers in the first place.
Error management
24.1 1 Error management has two components: ermr
reduction and ermr containment. Error redaction comprises
measures designed to limit the occurrence of errors. Since
this will never be wholly successful, there is also a need for
error containment - measures designed to limit the
adverse consequences of the errors that still occur.
2.4.12
measures to minimize the error liability of the

individual or team:
measures to reduce the error vulnerability of particular
tasks or task elements:

measures to discover. assess and then eliminate errorproducing (and v i ~ l a t i o n ~ - ~ r o d u cfaclors
i n ~ ) within the
workplace;
The aviation industry thus shifted its focus from
e l i m i ~ t i n gerror to pmeming and m a ~ g i n gerror. Human
error is recognized as an inevitable component of human

performance. Complex socio-technological systems
therefore should take this into account by design. The
concepts of ermr tolerance and e m r msisrance in
technology design best exemplify this new focus.
2.4.9 The concept of error tolerance can be illustrated
by the comparison between a typewriter and a word
processor. A typewriter is hardly error tolerant: if a wrong
key is s u c k during the typing of a texf. the entire text has
to be retyped in order to produce a faultless page. Later
models of typewrites include correction facilities to help
overcome this problem to a degree. but the corrections
made are still noticeable to the (rained eye of readers. A
computer-based word processor on UK other hand is highly
error tolerant in this respst: if a wrong key is struck. the
backspace key provides a simple but effective means to
Error management includes:
measures to diagnose organizational factors that create

error-producing factors within the individual, the team,
the task or the workplace;
measures to enhance error detection;

measures to increase the error tolerance of the
workplace or system;
measures to make latent conditions more visible to
those who operate and manage the system;
2. In Professor Reason's terms a violation is a deviation from safe

.
deviations can
o p t i n g procedures. standards or ~ l e s Such
be either delihate or erroneous.
Chapter 2.
measures to improve the organization's

resistance to human fallibility.
2-13
intrinsic
People cannot easily avoid actions that they did not

intend to perform in the first place.
2.4.13 Most attempts at error management are

piecemeal rather than planned, reactive rather than
proactive, event-driven rather than principle-driven. They
also largely ignore the substantial developments that have
occurred in the behavioural sciences over the last 20 to 30
years in understanding the nature, varieties and causes of
human error.
E m r s have multiple causes: personal, task-related,

situational and organizational.
2.4.14
Some of the problems associated with existing

forms of error rnanagement include the following: ,
They address the last error rather than anticipate and
prevent the next one.
They focus on active failures rather than on latent
conditions.
They focus on personal rather than on situational
contributions to error.
They rely heavily on warnings and disciplinary
sanctions.
They employ blame-laden and essentially meaningless
terms such as "carelessness", "bad attitude" and
"irresponsibility".
They do not distinguish adequately between random
and systematic error-causing factors.
They are generally not informed by current Human
Factors knowledge regarding error and accident
causation.
2.4.15 In aviation and elsewhere, human error is one
of a long-established list of "causes" used by the press and
accident investigators. But human error is a consequence
rather than a cause. Errors are shaped and provoked by
upstream workplace and organizational factors. As
mentioned before, identifying an error is merely the
beginning of the search for causes, not the end. The error,
just as much as the disaster that may follow it, is something
that requires an explanation. Only by understanding the
context that provoked the error can the= be hope to limit its
recurrence.
Within a skilled, experienced and largely wellintentioned workforce, situations are more amenable to
improvement than are people.
2.4.117 Human behaviour is governed by the interplay
between psychological and situational factors. This applies
to errors as to all other human actions. Such claims raise a
crucial question for all those in the business of minimizing
potentially dangerous errors: which is the easiest to remedy,
the person or rhe situation?
2.4.18 General practice seems to aim at the person.
After all, people can be retrained, disciplined, advised or
warned in ways that will make them behave more
appropriately in the future - or so it is widely believed.
This view is especially prevalent in professions that take
pride in their willing acceptance of personal responsibility;
among these are pilots and air traffic controllers. Situations,
in contrast, appear as given: people seem to be stuck with
them. A.s a consequence, errors in aviation often are
suppressed. They go unreported and therefore do not exist.
If errors do not exist, they need not and cannot be managed.
2.4.19 A developing trend, however, is to clearly
favour the siiuational rather than the personal approach to
error management. There are many reasons for this:
Human fallibility can be moderated up to a point, but it
can never be eliminated entirely. It is a fixed part of the
human condition, partly because errors, in many
contexts, serve a useful function (for example, trial-anderror learning).
Different e m r types, which have diffeient
psychological mechanisms, occur in different parts of
the organization and require different methods of
management.
Safety-critical errors happen at all levels of the system,
not just at the operational end.
2.4.16 It is essential to recognize the following basic

facts about human nature and error as the foundations of an
error management programme:
Measures that involve sanctions, threats, fear and

appeals have only a very limited effectiveness; in many
cases, they can do more harm -to morale, self-respect
and a sense of justice - than good.
Human actions are almost always constrained by factors

beyond an individual's immediate control.
Errors are a product of a chain of causes in which the

precipitating psychological factors - momentary
2-14
H u m Focror~~uidelincs
for air trafic mann,qernenr (ATM) sysrems
inatlention. misjudgement, forgetfulness, preoccupation

- are often the last and least manageable links in the
chain.
The evidence from a large number of accident inquiries
indicates that bad evelits are more often the result of
error-prone situations and error-prone activities than
they are of error-prone people.
2.4.20 Error management therefore must be aimed at
systemic performance rather than individual performance.
Developments in e r m r management
2.4.21 To conclude this section, a brief mention is
made of an emerging development in error management in
aviation. Since it is realized that not every human error
immediately has a disastrous ot~tcome, the industry has
begun to monitor "normal operations". Several airlines are
routinely analysing flight data recorders (FDRs) from
flights during which no abnormal occurrences happened.
The idea behind this is to learn from "successes" (i.e.
operations that went az intended) rather than from
"failures" (i.e. operations that resulted in incidents or
accidents). Of course such "failures". should they occur, are
still thoroughly investigated as well, but it is hoped that
data from the monitoring of normal operations will provide
new insights into human error and, therefore. error
management. The overall aim remains to reduce the
number of safety occurrences in the aviation industry.
2.4.22 It could be argued that, in order to k t t c r
understand the nature of normal operations, in addition to
the quantitative data from the FDRs there should also be a
qualitative analysis of the performance of the human
operators. This would. for example. provide an insight into
the operational suitability of a system design (see 2.2 Humansentred Automation). For practical reasons.
however, this part of the equation is not routinely included
in the monitoring programmes s o far, although certain
encouraging initiatives are being undertaken.
Managing E n u r
-Summary
2.4.23 Contrary to what was believed in the w e n t

past. human error cannot be avoided by "designing it out of
the system" or by disciplining operators. Error is a normal
component of human performance. This fact therefore must
be incorporated into all stages of the design.
implementation and operation of complex systems where
safety is the expected outcome. ATM systems are a prime
example. During the development, acquisition and

implementation stages of an ATM system. one should
always be on the lookout for opponunities for error by the
eventual operators and users, in order to reduce those
opponunities and/or mitigate the consequences of the
resulting errors. The following chapters in this manual
provide alternatives to this end.
Conclusion
2.4.24 There is a relationship between the Uuee

conceptual topics presented in this chapter. Application of
the Human-centred Automation concept will increase the
Situational Awareness of the air traflic conuoller, which in
rum becomes a component of the Error Management
programme of the air traffic services provider. Controllers
with a high Situational Awareness are more likely to detect
errors and contain their consequences. Furthermore, a
human-centred system design reduces the vulnerabiliiy to
error of tasks or task elements from operators.
2.4.25 This interrelationship plays an imponant role
throughout thc proccsscs of development, acquisition and
implementation of ATM systems. In Chapter 4 'The
human-machine interface" and in Chapter 7 "Standard
operating procedures" more detailed guidelines are
provided for the practical application of these concepts.
References
Human-centred Auromarion
Billings. Charles E.. Aviarion Automation - The Search for

Human-Cenrered Appmach, Lawrence Erlbaum
Associates. Mahwah, NJ. 1997. (ISBN 0-8058-2127-9).
Billings. Charles E.. Human-centered Aircraft Automation:

A Concept and Guidelines, NASA Technical memorandum
103885, NASA-Ames Research Center, Moffeit Field, C k ,
1991.
Cardosi. Kim M. and Elizabeth D. Murphy. (eds) Human
Factors in the Design and Evaluation of Air Trafic Contml
Sysrems. United States Department of Transportation,

Volpe National Transportation Systems Administration.
Cambridge. MA. 1995. (DOTIFAAAUI-95B DOT-VNTSCFAA-95-3.)
Human Factors Tmining Manual. ICAO. Monueal. 1998.
(Doc 9683-AN1950.)
Chapter 2.
Situatbnal Awareness
Managing Error
Guidelines for Developing and Implementing Team

Resource
Management,
Eurocontrol
1996.
(HUM.~I.ST10.1000-GUI-01.).
Human k t o r s Digest No.7 - Investigation of H u m

Factors in Accidents and Incidents. ICAO, Montreal. 1993.
(Circ: 2#AN/144.)
Hopkin, V. David, Human Factors in Air Trafic Control.

Taylor & Francis Ltd, London, UK, 1995. (ISBN 0 7484
03574.)
The Human Factors Design Guide. CD-ROM, version 1.1.
J. Hughes
Federal Aviation Administration,
Technical Center, New Jersey 08405, USA.
H m n Factors Training Manual, ICAO 1998. (DOC9683AN/950.)
Isaac, A. and B. Ruitenberg, (1999) Air Traffc Control:

Human Performance Factors. Ashgate Publishing Ltd.,
Aldershot, Hants, UK, 1999. (ISBN 0-291-39854-5.)
Human Factors Digest No.10 - Human Factors.

Management and Organization. ICAO, Montreal, 1994.
(Circ 247-AN/148.)
Human Factors Training Manual. ICAO, Montreal, 1998.

(DOC9683-ANI950.)
Reason, J.T. (1997) Managing the risk of organizational

accidents. Ashgate Publishing Ltd. Aldershot, Hants. UK,
1997. (ISBN 1-84014-104-2 or 1-84014-105-0.)
Chapter 3
DATA LINK INFRASTRUCTURE AND APPLICATIONS
aircraft with global navigation satellite system (GNSS)
capability, ADS capability and C P D K capability.
This chapter discusses aspects of the data link infraskcture
that are relevant to the design and implementation of ATM
systems but that are outside the influence of the designers,
buyers or operators of the systems. Furthermore the chapter
includes an overview of data link applications most relevant
for ATS, as weil as a description of human-machine
interface designs for controller-pilot data link communications (CPDLC) on the flight deck. Designers, buyers and
operators of ATM systems should understand and take into
account the characteristics of the topics in this chapter.
3.2 DATA LINK

3.2.1 Although CNSlATM systems are being
designed to operate with the aeronautical telecommunication network (ATN), it is quite likely that the ATN will
not be fully available before 2005. Until that time, most of
the emerging system components will use a provisional
network based on the use of the existing aircraft communications addressing and reporting system (ACARS) infrastructure. ACARS was originally designed as a system for
airline operators to enable them to communicate via data
link with aircraft during flight without having to use scarce
VHF voice communication channels. When the first
operational trials with automatic dependent surveillance
(ADS) and CPDLC were designed ACARS was chosen as
the data link medium to transfer data between the aircraft
and ground stations.
3.2.2 To that end, Boeing, Airbus and Honeywell

designed avionics packages for selected aircraft types that
would transfer the required data from the on-board
navigation system (or to be more exact, the flight
management system [FMS]) to the ground stations. The
Boeing package is called FANS-1 and is available for the
B747-400 series, the B767 and the B777. In addition there
are also FANS-I packages for the MDll and MD90.The
Airbus package is called FANS-A and is available for the
A330 and A340 series. Both packages provide equipped
3.2.3 From a technical viewpoint the most important

difference between the ACARS network and the ATN is
that ACARS is a character-based system (analogue)
whereas the ATN is bit-oriented (digital). A bit-oriented
system has fewer constraints for data exchange than does a
character-based system. One of the key components of the
ATN will be the VHF Digital Link Mode 2 (VDLMode 2)
network, which is expected to render the ACARS network
obsolete over time. W~thACARS, messages from air traffic
control "compete" with messages from airlines for
transmission space on the network. Although there is a
prioritization system to govern this competition, there is a
realistic risk that not all messages get through in the
required order of priority. With VDL Mode 2 this risk is
expected to be significantly reduced, thereby increasing the
integrity of the data exchange between all parties involved.
3.2.4 One aspect that will probably not change when

ACARS is replaced by VDL Mode 2 is the fact that L!e
communications service is mainly being offered by
independent service providers. For ACARS, there are two
companies that offer this service globally, i.e. ARINC
(Aeronautical Radio, Incorporated) and SITA (SocittC
Internationale de T61Ccommunications A6ronautiques). and
although the market is, in principle, open to other
companies, it appears that ARINC and SITA will also be
the main providers for VDL Mode 2
3.2.5 Customers, i.e. the airlines and the air service

providers, must subscribe to the services of one of these
communications service providers in order to get access to
ACARS and/or VDL Mode 2. Subscribing to one does not
preclude access to clients using the other. An airline that
uses ARINC as its communications provider can
successfully establish ADSlCPDLC contacts with an air
service provider that uses SITA or vice versa. The only
drawback that so far has been identified with ACARS in
this respect is that there may be a t e c h r i d delay of up to
six minutes before this cross-provider contact is
established. It is expected that this situation will improve
with VDL Mode 2.
: Factors gu&-lines for
3.2.6 Other networks that are under development are

VDL Mode 3 and VDL Mode 4. Originally. there were also
provisions for VDL Mode 1, but since the characteristics of
it were at best similar to those of the ACARS network, the
lack of market demand for it seems to have forestalled its
further development
3.2.7 A further technological development comprises
the use of Secondary Surveillance Radar (SSR) Mode S
data link. There are two options available for Mode S data
link: Mode S and Mode S Extended Squitter, that in functionality are quivalent to VDL Mode 3 and VDL Mode 4,
respectively. The following table gives an overview of the
attributes of the VDL Modes and SSR Mode S:
Table 3-1. Overview of VHF Digital Link

and SSR Mode S
Technic01
TYPE
choracterisrics
Specifics
VDL Mode 1
Similar to
ACARS
No funher
development
expected
VDL Mode 2
Transfer of
data only
Improved speed
and distribution
compared to
ACARS
VDL Mode 3
Transfer of
digitized voice
and data
Point-to-point
transmission
(i.e. no broadcast)
VDL Mode 4
Broadcast
transfer of
data only
Enabling
technology for
ADS-B
Mode S
Transfer of
digitized voice
and data
Point-to-point
transmission
(i.e. no broadcast)
Mode S
Broadcast
Extended Squitter uansfer of
data only
Enabling
technology for
ADS-B
3.28 In the ultimate ATN network environment the

technical aspects will be transparent to the end-users. The
pilots and contmllers will not be required to choose which
of the available technical means of communication is best
suited under a given circumstance; the PLFN technology will
do that for them. It is expected, however, that pilots and
contmllers will be informed (by the system) of what
functionalities are available to them at any given time.
oir rrofic mnnogemenr (ATM)system
3.29 Human Factors implications for the design,

implementation and operation of KTM systems
systems must be able to accommodate both

ACARS- and ATN-based data link transmissions.
Controllers should have information on which
technology is employed by the aircraft under their
jurisdiction.
P;IU systems that are already implemented should be
upwardly compatible in order to accommodate pmgressive developments of the KIN.

Operators and users should be made aware of the
inherent limitations of any deployed technology.
Separation minima must be designed or adjusted in
accordance with the capabilities and limitations of the
enabling technology.
3.2.10 More detailed guidelines on how this can be
accomplished will be provided throughout this manual, and
in panicular in Chapter 4 'The human-machine interface".
Chapter 6 "Preparing for change" and Chapter 7 "Standard
operating procedures".
33 DATA LINK APPLICATIONS
Automatic Dependent Surveillance (ADS)

3.3.1 ADS offers a potential for the vansfer of a vast
amount of information from each aircraft to a e gmund
starion. Every ADS report contains the following
information: the 3-D position of the aircraft (latitude.
longitude and level), the time, and an indication of the
accuracy of the position data information figure of merit In
addition to this basic information, an ADS repon max
contain any or all of the information presented in Table 3.2
3.3.2 It is obvious that to manage this amount of
information clear choices will have to be made in the
design stage of the system. It is also obvious that depending
on the choices made, further choices will follow as a logical
consequence. To illustrate this. a choice to make the
(extended) projected profile information visible in a
graphical format (i.e. as a line on the traffic situation
display) will generate requirements different from those
generated by a choice to have that same information
displayed in a tabular format (i.e. as written text). In the
latter case, a choice also has to be made as to whether to
display the tabular information on the main screen or on an
Chapter 3. Data link infrastructure and applications
3-3
Table 3.2 Overview of ADS information categories and content

r
fnfonnation category
Information content
Aircraft identification
As in field 7 of the ICAO model flight plan
Ground vector
Track
Ground s l d
Rate of climb or descent
Air vector
Heading
Mach or IAS
Rate of climb or descent
Projected profile
Next way-pint
Estimated level at next way-point
Estimated time at next way-point
(Next + 1) way-point
Estimated level at (next + 1) way-point
Estimated time at (next + 1) way-point
Meteorological information
W~nddirection
W ~ n dspeed
Temperature
Turbulence
Short-term intent
Latitude ti1 projected position

Longitude at projected position
Level at projected position
Time of projection
Intermediate intent
Distance from current point to change point

Track from current point to change point
Level at change point
Predicted time to change point
Extended projected profile
Next way-point
Estimated level at next way-point
Estimated time at next way-point
Estimated time at (next + 1) way-point
Estimated itime at (next + 2) way-point
... [repeated for (next + 128) way-points]
Focrors auidelines for a i r traffic managemenr (ATM) sysfems
auxiliary screen. Other important choicer to be made

include whether such information is to be displayed
continually for all flights or only at the discretion of the
controller. This is why input from the future users of the
system is crucial during the design stage, as many of the
choices will depend on local (or national) preferences. As
a general rule it would appear that most users are more
comfortable working with information displayed in
graphical than in tabular format.
3.3.3 This is supported by a recommendation from the
RTCA in the document Human engineering guidance for
daralink systems (DO-238):
"Graphic displays of data should be considered in
addition to message text when the graphic format
presents the data in a manner that eases the operator's
task. When compatible with the operator's task.
graphical formats are preferred for redundant display of
spatially-oriented routc and weather dam If a clearance
is represented grapl~ically on a map display, route
discontinuities, restricted airspace violations, and olher
errors may be more apparent than if ihc clearance is
represented in text. Funhermore, icons may caplure
more information in a smaller space than text."
3.3.4 Figure 3.1 illusuates how information could be
displayed to the controller. These experimental labels have
been proposed by Eumontrol and are pan of ongoing
developmental studies on the human-machine interface
(HMI) for advanced ATC workstations.
3.3.5 The label on the left is for a non-data linkequipped aircraft, the one on the right for an aircraft that
does have data link capabilities. The box around the call
sign (BAW362) in the label on the right denotes this
capability. The letters AW indicate the next ATC sector
with which this aircraft will work. The figures 290 are the
actual flight level (Mode C andlor ADS), the cleared flight
level and the transfer flight level. The figures 470 (left) and
475 (right) are the indicated airspeed. C N is the next waypoint (in this case a VOR) in the mute of the aircrafl. The
bottom line of the label on the right gives the heading
(135), speed (Mach .81) and vertical change rate (00, to
indicate that the aircraft is in level flight). These parameters
are derived from the aircraft's flight management system
(FMS) through ADS.
3.3.6 Figure 3.2 presents three labels which show a

change in heading, speed and venical change rate.
respectively.
3.3.7 The first label (on the left) shows that the
aircraft is in a left-hand turn and passing heading 320. In
the second label (centre), the aircraft is accelerating lhrough
a speed of Mach .745. In the third label (on the right).
BAW362 is climbing out of FL 255 for FL 290. indicated
on the second line, with a decreasing climb speed of 1 200
feet per minute, which is indicated on the bottom line by a
"down arrow" symbol (V) in front of the figure 12. (Of
course, changes in those three parameters may occur
simultaneously, in which case the label would show mows
for all three items on the bottom line.)
Nore I.- With respect fa the method pmposed in the
Eurocantml experiments to denote a change in vertical
speed (the label on rhe righr side in Frgure 3-2). from a
Human Factors perspective ir is inreresring ro see rhar
" V I 2 " (where V is a "dawn arraw") actrrally means rhar
rhe aircrafr is climbing, bur nor as fast as if was befare.
Confirmation rlzor the aircrafr is climbing can befound on
rhe second line ofrhar same label, where the informarion on
rhe F L is presenred ("2.55 ? 290"). It worrld nor be unlikely
for a conrn~llerro misinrerprer "VIZ" ro mean rhar rlre
aircrafr is descending ar I 200feet per minure. This sarne
mismatch co~~ldpossibly
occur when rhe aircrafr is acrually
descending, bur wirh an increasing rate of venical change.
in which case rhere would be an "up armw" symbol (A)
displayed in fmnr of the figures corresporrding with the
vertical speed. This design therefore requiresfinher work
.-
Nore 2.- Human Factors guidelines for the design of

the human-machine inrerfoce are contained in Chaprer 4 of
this nmnual.
3.3.8 In order to present those parameters in a

meaningful way to the controller, it will be necessary to
establish a high update rate for the ADS reports. If, for
instance, an update rate of once every 15 minutes were
maintained, the changes in heading. speed and vertical
change rate would probably be useless to the controller, in
which case it could be questioned whether they should be
displayed at all. But if an update rate close to that of radarreturns (i.e. once every four to ten seconds) were to be
achieved, controllers could make good use of the available
information.
3.3.9 One factor that may possibly restrict the
freedom of controllers to select a high update rate for ADS
repons is the cost of the ADS contract with each individual
flight As mentioned earlier in this chapter, the transmission
of the actual data is so far done via the network of one of
two commercial service providers. ARINC and SlTA, and
those companies charge a fee for their services. The more
frequently data is exchanged, the higher the fee.
Chapter 3.
3-5
Duta link trlfrustrucr~treatld applications
290 290 470

290 C1v
hdg spd vrc
Non Datalink
Datalink
$'
Figure 3-1. Examples of ADS information display labeis
Figure 3-2. Example of ADS information display labels
ADS-Broadcast (ADS-B)
3.3.10 ADS-B is a s~r\~cillancc

application that allows
the transn~ission of parameters. such as position and
idcntitication. via a broadcast mode data link for use by any
air and/or ground users requiring it. Where ADS rcports
can bc rcccivcd by a lirnitcd nunihcr of selected ground
stations only. ADS-B reports can bc received indiscriminately. This application is cn\isagcd to enable nc\v tliglit
deck tccllnolry! such as 3 suckpit display of traffic
infornlation (CDTI) and other airborne separation
assurance systcnis (ASAS).
Nofc."Nctc.jliglrt
AS.45 ntid CIITI arc. di.sc.lrssi.d it2 Cl~clprcr8
tic<-ktcchrlolo~!".
3.3.1 1 Recent trials have bccn conducted to validate

the ADS-B concept. While the first results are encouraging,
it remains to be secn whether the aviation industry is

prepared to invest in this new technology on a large enough
scale for global iniplen~cntation.
Note.- 111 othc'r cllnptcrs of this n~rnlunlocc~isiotrcrl
refirrrlcc is t~rnticsto AIIS-R, hcrlc.e its itlclrcsion it1 tliis
scc.riorl.
.ADS an the flight deck

3.3.12 The ADS capability is fully transparent to the
tlight crcw in that position reports are generated and
transmitted automatically frorn the FMS after a successful
data lilik log on has bccn accomplished with a suitably
equipped grc>undstation. The only physical .4DS elcnient
available lo thc Iliplit crew is an -'ADS Emergency" pushbutton. which, when activated. will generate and transmit
an emergency ADS report with rnaxirnum priority.
Factors guidelinesfor air trof/ic rnanojiernenr (ATM) sjsremr

CPDLC
3.3.13 Controller-pilot data link communications
(CPDLC) is a means of communication between controller
and pilot using data link for ATC communication.
3.3.14 The CPDLC application provides air-ground
data cammunication for ATC service. This includes a set o i
clearance/informationlrequerr message elements which
correspond to voice phraseology employed by ATC
procedures. The controller is provided with the capahility to
issue level assignments. crossing constraints, lateral
deviations. route changes and clearances. speed assignments. radio frequency assignments and various requests
for inforn~ation.The pilot is provided with the capability to
respond to messages. to request clearances and information,
to repun inlbrmation, and to declare or rescind an
emergency. The pilot is, in addition, provided with the
capahility to request conditional clearances (downstream)
and inf~~rmation
from a downstream ATS unit (ATSU). A
"free rcxt" capability is also pro\.idsd 1 0 exchange information no1 conforming to defined fornmats. An auxiliary
capahility is provided to allow a ground systenl to use data
link 111 forward a CPDLC nlcssagc to another ground
system.
3.3.15 Controllers and pilots will use CPDLC in
conjunction with the existing voice communication. it is
expected lo he used for routine or frequent types of
transactions. Although tile initial i~~~plementation
is
intended to conform to existing procedures. it is anticipated
that future c\.olution of thc system and procedures will
result in the greatcr automation of functions for hoth
aircraft and ground syste~ns.
3.3.16
steps:
Sending a message hy CPDLC comprises three
1) selecting the recipient;
2 ) selciting the appropriate message from a displayed

menu or by other means that allow fast and efficient
message selection: and
3) esccuting the transmission

The rccci\.ed messaze may be displayed and/or printed. A
message sent by a downstream ATSU will be distinguishable fnim a CPDLC message sent by the current ATS unit.
~
channel congestion, misunderstanding due to poor voice

quality andlor misinterpretation, and corruption of the
signal due to simultaneous transmissions.
3.3.18 The following quote from the document PilotConlrollcr Ca~nmunicarionErrors: At1 Arralysis of Aviation
Safer). Reporting System (ASRS) Reports. illustrates
however that CPDLC is not the solution for all communication errors:
"Data link is often touted as a technology that will
reduce or eliminate communication errors. Cenainly,
data link technology presents capabilities for reducing
some forms of errors and greatly reducing frequency
congestion. However, no technology can resolve all
communication errors. Clearly, the pattern of errors will
change. Sending clearances directly to the aircraft will
eliminate the possibility of the pilot accepting a
message intended for another aircraft, however, it is
possible Tor the conuuller to send the message to the
wrong aircraft or make another error in the message
sent. For the pilot, seeing clearances in writing has
several advantages over hearing them; it gives the
advantage of attending to it when the pilot is ready and
to double check it whenever necessary. However. it is
still possible to misinterpret written clearances (e.g. by
transposing numbers). While no communication technology can totally prevent communication errors,
careful use of data link is likely to reduce frequency
congestion and reduce the likelihood of communication
errors. The relative error ntes observed with data link
(compared to voice) will depend on the design of the
equipment and thc procedures used to implement it.
Careful attention to Human Factors issues in the design
and implementation of data link systems will help to
realise the benefits of data link without a potentially
deleterious increase in controller workload."
3.3.19 Implementation of CPDLC will significantly

change the way pilots and controllers communicate. The
effect of CPDLC on operations should be carefully studied
before deciding the extent to which voice will be replaced
by data link.
3.3.20 The following aspects of CPDLC should be
taken into account in considering its application and in
defining procedures:
3.7.17 CPDLC may he used to remedy a number of

shoncomings of voice communication. such as voice
,) (he total tinle required for selecting a message. msmilling the message, and reading and interpreting the
message;
.. .
h) the heads-down time for the pilot and controller: and
CJ
tile itlability of the pilot to monitor other dat:~ link

tr;~nsmissions to and from orhcr aircr;ll't in the same
; m a of' operation.
3.3.21 .More detailed guidclinc\ on lioir. this can hc

:~ccoillplishedwill hc provided througho~rtt l l i h 111anualand.
111 p;~rlicular.i i i Clraptcr 4 ".l'lic: Iiuii~ari-rnacliil~e
intcrlice"
;irl(l i l l Cliaptcr 7 -'Standard opcratirl; proccd~rrc\".
CPDLC interfaces of thrcc different families of aircral't will

he introduced. Although signilicant diffcrcnccs exist
bctwcen these intcrfaccs, the ground-based (:PL>I-C
systems (i.c. on thc ATC side) should handle data link
conlmunications with cach of the airborne systclns witflour
the users noticing any dif'fercnccs. Ideally, it should he
transparcnt to the controller with which type of airborne
equipment the CPDLC is taking place.
The CPDLC IlrlfI otl the jligh f deck

of the IJoeitig 717-100
Ct'I)I,C
011
(he flight ticck
.;.3.11 \Vlic~idcsigiiirig. i ~ ~ ~ p l c ~ ~ ~i~iicf

e i i toperating
i~ig
('i'lj1.t' woi.ks[:~rioil\: I I I ~ proccd~~rc,
lor co~itrollers.i t i \
L-.\L.IIII:II
10 coi~sidcrlio\v llic Cf'l1i.C iiirci-I':ice sill^ [lie
I l l ~ l i rclcck i \ cor~structcd.In rIic Ioilo\\.irlg [~ar:igrapf~s
[tic
3.3.73 In the Boeing 717-100 (Figure 3-31. tllc

CPIILC l'unctior~;tlity is iriregratcd in the ~ l ~ u l t i l u r ~ c ~ i o r ~
Coi~trol-Di~~)l;iy
L11it (biCDti), tile i i ~ t c r i ~ cwit11
c ~ I I C i:>tS.
'1'llcr.e arc: tllrcc identical hlCUUs on the t'ligllt dcck. hut
CI'ULC cannot hc accessed tlirougti lllc rear ,MCIlL.
Figure 3-3. The flight deck of the Boeing 737-300
Figure 3-4. Visual indication of a n incoming CPDLC message
3.3.24 The flight crew is alcned to an inconling

nicssagc by means of by an audio sound which consists of
:I chinr that sounds once when a message is rcccivcd. This
a111ei~l~ral
alert is used for I vi~rictyof otl~crcon~monic:~lionsfunctions. In additio~ithere is a line of tcxt 011 l11c
EICAS (Engine Indication and Crew Alcning System)
xreeti t l l l t reads "ATC MESSAGl? to direct the pilots to
tlic carrcct response to the sound. The visual nIelii(i (tile
Iext line) rcliuins on tllc ElCAS scrccn until the ere\\.
responds to the messas. FANS-I does not distingoisll
between routine and urgcnt ntessages.
3.3.25 Figure 3-4 sl~owsa close-up of tllc ElCAS

screen. The text "ATC MESSAGE is in white, while 111ost
of the other textu31 inionnation i n this picture is in hlue.
green or magenta.
3.3.76 The actual mcssa~e car1 he viewed al the

Multifunction Conlrol-Display LInit (MCDU. i.e. tllc screen
of the ioteriacc will1 ~ I I C FMS) located on tile I~orironti~l
panel hetween tlic pilots. This MCDU screen (Figure 3-51
is monochranie. so no use is 1113de~ icolour
i
cotling.
Figure 3-5. T h e hlultifunction Control-Display Unit
3.3.27 To access tllc CPDLC intcrfilcc. the crc\i. 1i;ts

to ptlsfl rllc ATC hultcln Cjitst below 1111: screen). They arc
tlicrl prcseritcd with the ATC log ontstalus nicnu page. its
illustrated iri Figure 3-5. If the system is already lofgcd on
and tlicrc is no opcn uplirik (i.c. n nicssagc requiring a
rcspon5r.l. tlic ':4TC IKDEX" page is disp1;iycd. It' rhcrc is
one open (new o r pending) rncs5qc. the riiessagc is
displayc~lon the "'ATC U1'LINK p;lpc. If tltcrc arc t\vo or
rilorc opcn rncssagcs. the "A?'C LOG" is displa.ed.
3.3.25 Funcrioris for ii4iicli the crew can make ;I
spccili~.input by tlic pusll-huttons (In the left and riglit side
of t l ~ csirccll arc i~ldicatcdhy a "<" o r a ">" s!.rnbol o n tile
scrccn. sdjaccnt to thc appropriate hutton(s). Pushing such
;I huttori results in a page ch;t~igc. 3. status chrlrigc or ;I
tr.;trisn~issic~ri.Xddiiiorl;tl data can bc ccritcred by tlic
"scr;ttcllpad" I'ilnction of the MCDU irito varioirs other

liclds (c.g. rllc "LOGON TO" linc at the top lcli in thc
picture.)
3.3.79 Two difircnt font sizes arc used on tile
display. In tlic menu shown irl 1:igurc 3-6 the s111;1lIerSolit
is used to itidicarc liscd rcxt. tile larger 1'0111 is U S L . ~ ~t i ~ r
variahlc test.
3.3.30 In c>tlicr 2;crc.cn pages. such as lllc o ~ i ciri

Figure -3-6. the tu.o forit sizes arc used to display text ~ I I ; I ~
continues o\.cr niorc ilia11o ~ i clinc. in the example. tlic test
";~t EI'lI clc;~rcdroucc clcarancc" uses rhrcc ilispl:~y lines
and altcnlcitcs bctivc.cn the s~iiallerand 111c I;~rgcr folits.
Fixed nicssngc rest is in small font uliilc varirthlcs tii;~t are
irisertcd inro tlic n~ess;~gc
arc in Iargc li>rit. Furttlcrriiorc.
3-10
H~tmonFacrnrs guidclit~er
for o i r rrof/ic monagenenr (ATM) sysre,n.s
Figure 3-6. Example o f message w i t h text in two font sizes
any tinic the message srvitchcs from lixcd to variahlc text

or vice vcrsit i t is displayed on n new line. Tlic goal o f this
fornlot is eitsicr intcrpretaticin hy pilcils 01what is iniporta~it
i n IIICtext.
into tlic FMS. provided the sender used tile correct

prcf~,niiaue~l
nrssagc elcmcnts. When lice text is used. this
functionality is not nvailahle.
3.3.32 Tlie 'ACCEPT' command will gciicrat~ 3

"Wilca".
"Kosci' or an "'Allinn" message. 3s appropriate.
Nur<,.- F ~ ~ ~ ~frou~
l h ~rt.ser.s
~ c k1ru.s i r r ~ l i c ~ r r r11i1r
c ~ l r1ri.s
d trans!iiiI a "Ne:mti\.e" or
,qoi~/,!fr/~c tIA.11 ~l~~si,q,~cr.s
is ,su,ttrri,~~e.s1
,1
,1 ~ t ~ l r i r1v11icIt
~ ~ ~ ~ l . 1'11~'..KUECT' c ~ n i ~ i i a n\\'ill
"Unahlc" nicsnlge. as appropriate. Buforc the mcsssgc is
can l<srd [to pororriull!. talw!k sirrruriorrs. (See C/!u/~lerF
.
transmitted to tlie ground system. tlic crew can rc\.ie\v i t 011
"Re.veun.11 ". J t h ~ r i r ~1,1qu.s raor ~ ~ ~ i ~ ~111~
/ >~l<~.~cril><~<l&>r~~~<tr
re<l
a suhseqocnt display page.
i n rlrc irrq,k.,rzc,muion
q i CP1)LC &,r thr, 757067 w r i r . ~ .
urrd a alodi/i.irrk~,r rs bci,~?~ l c v r l r ~ ~ ~ rlrc
r d f 747-4011.
i~r
NarcT11is i u r / ~ l i i ~Is
/!uI
1110 sy,sr~~rrri.s t ~ c r r i i ~ l l ~
rrunsrrrirring orlrrr irr~rdsrlturr rlrosc irririal!\. s c l c c r ~1~
1.v~r il ~ c
3.3.31 With the "LO.-\U" corntiland thc pilot can
pilors. Sre C l ~ n / ~ r5r r"Rcsr.a~/z"
transfer relevant items fro111the received clearance directly
3.3.33 The indication 111 i n thc top right-lland comer

of Figure 3-6 denotes that this message consists of only one
pagc. Messages consisting of more than one pagc will be
indicated as xly, where x is the number of the displayed
page and y is the total number of pages. Related pilotresponse prompts are only displayed on the last pagc of a
multipage uplink, so the pilot must go to the end of the
message to respond.
Nore.Feedback from CPDLC operutions in the

Pacific region sriggests that flight crews sornetitnes overlook
the fact that u message can cotlsist of more than one page
and begin to reuct to instrrictionsfron~the first puge before
reading the following pagds). This tnuy have implications
ji)r procedrcre design as cceell as for controller and pilot
training it1 the use of CPDLC. (See Chapter 7 "Stundard
operating proced~ires".)
3.3.34 A similar though improved CPDLC interface is
used i n the FANS-I packages that Bocing dcvclopcd for the
B767, the B757 and the MD9O. and it is expcctcd that the
FANS-I package that will be offcrcd for the MDl l will
also usc this improved method.
The CPDLC IiMI on Ihefliglzl deck

of the Boeing 777
3.3.35 In the Boeing 777 (Figure 3-7). the CPDLC

function can be displayed on one of three Multi-Functional
Displays (MFDs): the inboard display for each pilot and the
lower central display. Furthermore, the EICAS display has
a dedicated space for incoming messages. The EICAS
screen (Figure 3-8) also displays memo messages and alerts
associated with the communications function.
3.3.36 The flight crew is alerted to an incoming
message by means of a line of text on the EICAS screen
that reads "ATC", as well as by an audio sound. The audio
signal consists of a two-tone chime that sounds once when
a message is received. The visual memo (the text line)
remains on the EICAS screen until the message is
responded to by the crew. Suitable messages are displayed
directly in the ATC Uplink Message Block (also known as
Data Block, see Figure 3-9) on the EICAS scrccn. This
message area can handle up to five lines of text uith a
maximum of 30 characters per line. For each separate
message element a new line is used.
Figure 3-7. The fliglit deck of the Bocing 777
.{-
12
--. .-. .
-
ff~rtllnt~
Fuc tors ,yiiidelitles for uir fruffic ttratlcr~ctrletlt( A T M ) .s~.rfert~.r
.
-
Figure 3-8.
Visual indication of an incoming CI'I)I,C n1ess;ige
Figure 3-9. The Baeing 777 ATC Uplink message block
Chapter 3. Data link infrmtrrtcture and applications
3.3.37 If a message that is too large for the Message

Block (e.g. one consisting of multiple elements) or a route
clearance message is received, the crew is presented with
the text "LARGE ATC UPLINK" in this message block
They subsequently have to use the COMM function on a
MFD to read the message. FANS-1 does not distinguish
between routine and urgent messages.
3.3.43 Another difference between this display and

the Boeing 747-400's FMS-based display is that here the
font size is consistent for the whole message. The B747400's FMS-based display uses two different font sizes. For
the B777 interface, colour coding is used to distinguish
different categories of displayed text. For example, when
the crew correctly selects certain numerical values (e.g.
altitude clearances, radio frequencies, headings, etc.), these
characters turn green as a validation of the correct selection.
3.3.38 The block also displays the responses that are

available and the crew can access these by using the
ACCEPT or RETECT buttons mounted on each pilot's glare
shield. Alternatively, the crew can select the COMM
function on an MFD and use the cursor control to klect a
response prompt in the displayed menu. After selecting and
sending a response, for example "ACCEPT", the displayed
text changes to "ACCEPTED" and the text colour changes
from white to green.
ATC instruction, they have the option to send a message in
3.3.39 The Message Block furthermore displays what

Boeing terms "sidelinks", i.e. when the system
automatically downlinks a response to certain incoming
messages (e.g. REPORT LEVEL FL350). The downlink is
displayed in this area (LEVEL FL350) and the crew is
aurally alerted just as if the message were an uplink. This
allows validation by the pilots of the automatic response.
which they explain why they are unable to accept the

instruction. The B777 CPDLC interface provides the crews
with a dedicated template from the menu in which several
options a& preformatted. In addition to those options, the
crew may also elect to send a free text message to ATC.
Figure 3-14 shows an example of the crew using the latter
possibility. Also visible in the picture are three
preformatted options.
3.3.40 Figure 3-10 shows the ATC menu overview

from the MFD. Selections are made by means of cursor
control. (In the picture the cursor is on the "ATC" button,
top left.) When alphanumeric input is required, the input
is composed on the Multifunction Control-Display Unit
(MCDU, the interface with the FMS) and transferred
into the appropriate field on the MFD using the cursor
control.
3.3.41 Figure 3-1 1 shows the Route Request page. It

offers the pilots a wide variety of input options that are
grouped in a logical order. In the picture the pilot has
selected "Route 1" as the requested choice, which is a
reference to one of two possible alternative routes the crew
can programme in the FMS.
3.3.42 Rgure 3-12 shows an example of what a route
clearance looks like on the B777 CPDLC display. The fact
that the pilot has access to a second page (see the scroll bar
on the right of the picture) indicates that this is not the end
of the message but no more can be presented on this page.
At the bottom of the picture a button with the text "LOAD
FMC" is visible. By clicking this button the displayed route
clearance is automatically loaded into the flight management computer. thus greatly reducing the chance for input
error by the flight crew when compared to having to
manually type the way-points.
3.3.44 Figure 3-13 shows an example of an M C

instruction to "CLIMB TO AND MAINTAIN FL350.
REPORT LEAVING FL230." The digits 350 are displayed
in green, while the rest of the text is in white.
3.3.45 If flight crews are unable to accept a specific
The CPDLC HMZ on the jlight deck

of the Airbus 340
3.3.46 The flight deck of the Airbus 340 (Figure 3-15)
features two dedicated screens for CPDLC called Datalink
Control Or Display Units (DCDUs).
3.3.47 The DCDU was designed to provide a
minimum change in existing flight deck procedures and to
allow folr a simple reversion to backup voice-based
ptoceduws when needed.
3.3.48 On the DCDU colour coding andlor reverse
video are used to differentiate between titles, text, main
parameters in the text, uplink or downlink messages and
closed actions.
3.3.49 The DCDU provides for full time accessibility
and readability for both crew members and requires only
limited heads-down time.
3.3.50 The flight crew is alerted to an incoming
message by means of a flashing blue "ATC MSG" light in
two push-,buttonson the glare shield (i.e. visua1):as well as
by a dedicated audio sound. The alert is stopped by
3-14
Human Factors guidelinesfor
sending. Figure 3-19 shows an impression of the DCDU

display with a climb request that was just transferred from
the MCDU. The message text is displayed in reverse video
in blue colour.
pressing a push-button or by answering the message. For

normal messages, the buttons flash and the audio signal is
repeated about every 15 seconds (with the first signal
delayed by 15 seconds). The message will appear on the
DCDU if the screen is empty. If the screen is not empty, a
flashing cue (e.g. "MSG 112") reminds the crew of the
arrival of the message. For urgent messages, the buttons
flash, the audio signal is repeated about every five seconds,
and the message is displayed on the DCDU regardless of
the state of the screen.
3.3.51 Figure 3-16 shows an impression of how an

uplinked ATC instruction is displayed on the DCDU. The
message text is in white, with the speed instruction (the
variable part) in blue. The text "OPEN in the top right
comer indicates that a reply to the message is required.
air trefic managernenr (ATM) systems
3.3.56 After pressing the "SEND button, the colour

of the reverse video changes to green. The text "OPEN" in
the top right comer indicates that a reply to the message is
required (in this case a reply by iWC).
'
3.3.57 The same system will be available for the

Airbus 330 and, eventually. for the Airbus 320 family. It is
designed to be usable within the ATN-based CNS system,
for which it will require a software upgrade.
Data link ATIS
3.3.52 To reply to a message, the flight crew either

uses the standard replies displayed on the DCDU or
composes a reply on a menu page from the Multipurpose
Control and Display Unit (MCDU, i.e. the interface with
the flight management computer). After the message is
composed on the MCDU, it is transferred to the DCDU for
checking and sending.
3.3.53 Figure 3-17shows an impression of the DCDU
display after the crew has selected the "WILCO reply. The
text "WILCO appears in reverse video in blue colour in
the top right comer, allowing verification of the selected
reply before sending it.
3.3.54 After pressing the "SEND button, the
message text and the reverse video change to green colour,
and the text "SENDING" is displayed in white in the
bottom half of the DCDU. Once acknowledgement of
receipt by the ground system is received, this text changes
to "SENT'. (Figure 3-18)
3.3.55 If the crew wish to initiate a message to ATC,
they use the MCDU to compose the message and
subsequently transfer it to the DCDU for checking and
3.3.58 The data link automatic terminal information

service (ATIS) supplements the existing availability of
ATIS as a voice broadcast service provided at aerodromes
worldwide. A11 types of ATIS currently in use (i.e. arrival,
departure and combined) are encompassed.
3.3.59 The data link ATIS kessage will be used to
provide an alternative means of transmitting the service to
those equipped aircraft which request the message.
3.3.60 Data link ATIS (together with future
applications like data link Flight Information Service) has
the potential to significantly reduce congestion on voice
communication channels at aerodromes and in terminal
areas. Especially in environments where most
communications between fight crew and P;TC are
considered to be time-critical (e.g. aerodromes, terminal
areas), the implementation of data link ATIS could be more
effective than implementing CPDLC. In such environments
voice-communications (Rn? will be preferred over
CPDLC, so any reduction in frequency congestion achieved
by data link A?IS will be regarded as an improvement in
communications.
Chapter 3. Data link infrastructure and applications
Figure 3-10. The Boeing 777 CPDLC ATC menu
3-15
3- 16
Human Factors grridelincs for air traffic management ( A T M ) systems
Figure 3-11. The Boeing 777 Route Request page
Chapter 3.
Uata link infrastructure and applications
Figure 3-12. Example of a received CPIDLC route clearance
3-17
3- 18
Human Factors grcidelinesfor a i r rraffc management (ATM) systems
Figure 3-13. Example of a received CPDLC ATC instruction
Cllapter 3.
Data link infrastrccc~ureatid upplicarior~s
Figure 3-14. Example of a CPDLC message with free text
3-19
Hurnaf Factors guidelines for a i r tra,ffic
3-20
e 3-15
management (ATM) system3
The flixht deck of tile tlirt~us340 anti the Airbr~s340 1)ataliilk Coti!rol and 1)isplay I;nit
Figure 3-16. Example of a received CPDLC ATC instruction
Figure 3-17. Example of a CPDI,C repi? message (before sending)
Figure 3-18.
Example of a CPDLC reply message (after sending)
Figure 3-19.
Example of a CPDLC climb request message
Chapter 3. Data link infrastructure and appiicatiom

.-
Conclusion
3.4 Designers, buyers and operators of ATM systems

need to be familiar with the present and future data link
infrastructure. They also should be familiar with present
and future data link applications. Knowledge and
understanding of the HMI. design on flight decks of the
major airframe manufacturers and how these are used by
aircrews will enhance the design and operation of P;IU
systems. The material presented in this chapter should be
considered as basic study material for all those involved in
the development, acquisition, implementation and operation
of AThl systems.
References
Cardosi, K., P. Falzarano, S. Han, Pilot-Controller

Communication Errors: An Analysis of Aviation Safety
Reporting System (ASRS) Reports, United States
Department of Transpoxtation, Research and Special

Programs Administration, John A. Volpe National
Transportation Systems Administration, Cambridge, MA,
1998, reprint 1999. @oT/FAAfAR-98/17 IXYI-VNTSCFAA-98-4.)'
Galotti, Vincent P., The Future Air Navigation System
(FANS). Avebury, Ashgate Publishing Ltd., Aldershot,
Hants, UK, 1997. (ISBN 0-291-39833-2.)
H m m n Engineering Guidance for Data Link System.

n C A , Inc., Washington, D.C.,1997. (wrCA/DDO-238.)
Hwnan Machine Interface Catalogue for EATCHIP Phase

III. Version 1.0, Eumcontrol, Brussels, 1998.
Manual of Air Trafic Services Data Link Applications.
ICAO, Montreal, 1999. (Doc 9694-AN/955.)
Chapter 4
THE HUMAN-MACHINE INTERFACE (HMI)

4.1
INTRODUCTION
"The increased complexity and added workload thht has

resulted from the system is already surfacing as an
important issue, even in the low traffc volumes of the
current single sector: Future functionality and complexities
as well as busier sector trafic volumes will serve to
heighten this concern We recommend testing the current
configuration and future multisector version of the sofrware
in simulations of heavier traffic. When identihing solutions.
we commend that changes in the design of the HMI be
considered as a higher priority than training or other
interventions.
"
Computer-Human Interface Evaluation

of the Oceanic Data Link System (FAA, 1997)
The human-machine interface (HMI) consists of physical
components as well as software and tailored standard
operating procedures (SOPS). The physical components of
the HMI include the parts of the system. i.e. the computer
screens and output and input devices, that support the
transfer of information and instructions between the
computer and the human. This chapter will discuss issues
for the design and use of input devices. visual displays,
menus, colour, data entry, electronic flight progress strips,
user guidance, visual alerting and auditory alerts. Specific
recommendations for the design of the HhfI for CPDLC are
also included. The Appendices to this chapter contain
examples of existing HMI designs for CNSIATM
technology. An example of a checklist with Human Factors
considerations for the ATC HMI is also included as an
attachment to this chapter.
Note.- Standard operating procedures are discussed in
Chapter 7.
4.2
INPUT DEVICES
4.2.1 Several issues need to be considered in the

design and use of input devices. Some of these issues are
common across devices, while others are unique to each
device. Such devices include keyboards, touchscreens,

mice, lightpens and trackballs (rolling balls). Although the
selection of a specific type of input device will depend
upon the task at hand, in no case should an overall design
of input devices require frequent switching between
devices. Frequent switching between devices induces errors
and adds to the controllers' workload.
"The input devices used with the system are a keyboard and
a tr&kball with pushbuttons. Many controllers expressed
concern about the difficulty of using the rrackball. The
trackball has three pushburtons that are used for
performing many functions. The left and right trackball
buttons have multiple and sometimes inconsistentpurposes.
Some rfiuckball commands do not seem like they would be
very emy to remember: Some people were observed using
two h a d at times to operate the trackball and press its
pushbutirons. Also, some users said it is too slow. Another
complaint was that the trackball does not have a long
enough cord. This makes it difficult for the controllers to
arrange the workstation as they like. Finally, the trackball
pointer (doesnot disappear when text is entered into data
entryfields. The pointer blocks the text being entered in the
field. "

4.2.2 The main Human Factors issues related to the
design of input devices are usability and operational
suitability. At issue is not only whether a controller can use
a device to perform a task, but also whether the device
promotes optimal task performance. The following example
illustrates this point. In a tower, a controller could use a
keyboard to enter or manipulate data. However, the need to
maintain Situational Awareness outside the tower suggests
that input devices requiring less heads-down time would be
more appropriate or operationally suitable.
4.2.3 Controllers frequently update information in the

computer and exchange information with other controllers
through the computer system. Consequently, any change in
the input device needs to be carefully examined because it
affects critical aspects of ATC performance.
Human Factors guidelines for air trafic management (ATM) systems
4-2
4.2.4 Assessment of input devices for use in ATC

should focus on two key questions:
Does the device meet the needs of the controller?
Do new capabilities change the ways controllers
organize their tasks?
4.2.5 To ensure that the performance of the device
matches the needs of the controller, positioning accuracy
and time lag between input and output should be taken into
account when evaluating the device. Performance parameters must be assessed on tasks that closely resemble
those performed by air traffic controllers, and the
participants in the evaluation should be controllers who are
representative (e.g. in level of skill) of the user population.
4.3.2 Before a display is designed, a task analysis

should be conducted to answer the following
What is the objective of the task that must be performed
with this display? What other tasks will be performed
concurrently?
What information does the controller need at each stage
of performing the task?
What errors is the controller likely to make in
conducting this task? What are the consequences of
these errors?
'
4.2.6 A thorough evaluation of any input device

should include assessment of basic Human Factors issues
(i.e. usability and operational suitability) and testing of
,xrformance parameters that are valued in ATC operational
environments (e.g. system response times and feedback).
Because certain Human Factors issues and performance
parameters might not have the same relevance in different
contexts, findings from the research literature should be
generalized with caution. The nature of the task that is
analysed, the purpose, and the situation in which controls
are employed, are some of the considerations that must be
taken into account when evaluating the relevance of
research findings. Although research literature may suggest
what the results could be, there is no substitute for actual
usability testing with controllers who are representative of
the workforce.
4.3
VISUAL DISPLAYS
"Much of the complexiry and display clutter problem is

caused by the fact that the intetface is made up of several
windows that can be customised in size and placement.
Also, a lot of unnecessary information and commands are
provided in the display. Other issues that add to the
complexity of the system's HMI are the large number of
menu buttons and infomtion coding types."

4.3.1 In ATC environments, the best display is the one
that most consistently and accurately enables the controller
to achieve the goals associated with the task being
performed. This is why it is necessary to understand task
objectives and related information requirements &fore
designing the display format or symbology.
What other displays. will the controller be working

with? The symbology, layout, controls and other
characteristics of the new display must be compatible
with those of other displays in use.
How critical is it for this task to be completed
immediately?
4.3.3 The selection and presentation of information
for displays must be managed so that the displays provide
only the information that is needed, when it is needed, and
how it is needed (i.e. in a form that is useful and
operationally suitable). Ergonomic standards and guidelines
are available to aid in meeting this objective, and these
issues must be resolved within the context of the
controllers' individual and team tasks. Prototype visual
displays must be evaluated for usability, operational
suitability and acceptability within the A X context.
"When aircmji messages appear on the aircraji list they
appear in alphabetical order and not by utgency. This
requires the controller to scan the entire list of messages
awaiting acknowledgement and deternine which is the
nlost urgent. It was also noted that the level of urgencyfor
various urgency codes was not well understood by users."

of the Oceanic Data Link System (FAA. 1997)
4.3.4 Visual displays may be technically usable but
not operationally suitable or acceptable; that is, their
physical and perceptual aspects, such as formatting and use
of colour graphics, may comply with guidelines, but their
content and their sequential presentation of information to
the controller may be deficient. If visual displays do not
meet criteria for operational suitability, it is unlikely that
they will be acceptable to the workforce. Field evaluations,
developmental testing, operational testing and evaluation.
and site testing are required to identify suitability and
acceptability issues and to assess usability.
Chapter 4. The hurnan-machine interface (HMI)

4.3.5
In summary:
Displays must be designed for the tasks they need to

support and the environment in which they will be used
The entire set of displays that a controller will use must
be designed and evaluated as a whole and not as a
combination of parts.
"The use of separate subsystems and components adLZs
complexity, requires the same data to be entered several
times, and divides controller and supervisor attention
among the components. Lack of integration also results in
inconsistent HMI designs across subsystems. When users
require a variety of data to complete a task it is important
that those data be provided in an integrated display and not
partitioned in separate windows or on separate systems."

4.3.6 For an ATC environment where surveillance
data (radar andfor ADS) and communications (CPDLC)
both need to be displayed, the issue arises whether to apply
dedicated visual displays for each function or to integrate
both functionalities on a single display, When formulating
a decision, careful consideration must be given to the tasks
that are being performed by the users of the display(s) and
the environment in which the display(s) is/are to be used.
Experience from systems in operation suggests

that, in case a choice is made to apply dedicated displays
for each modality, it is appropriate to enable access to
certain functions from both (or all) displays. In particular,
the traffic situation display, used by controllers to monitor
and plan the M i c for which they have responsibility,
should allow access to often-used functions for
communication (CPDLC) and coordination (AIDC).
4.3.7
4.4
MENUS
4.4.1 A menu is a list of options from which a user

makes a selection or selections. An option is one of the
selectable items in a menu. Selection is the action a user
makes in choosing a menu option.
4.4.2 Three types of menus are permanent, pull-down
and pop-up. Permanent menus are always "opened", that is,
the menu options are continuously displayed on the screen.
Pull-down and pop-up menus conserve screen area by only
showing the available options at the user's request. Pulldown menus are activated by selecting a menu title that
describes the menu. Several menu titles are usually

available on the menu bar of a window or application.
Pop-up menus are typically accessed by pressing a special
mouse button while the cursor is on a graphical symbol or
hot spot.
Note.- For an e m p l e of pull-down menus, see
Appendix I to this chapter; for an example of pop-up
menus, see Appendix 2 to this chapte,:
4.4..3 The windows used for data entry or to specify
command parameters may contain graphical controls called
command buttons to initiate or cancel data processing and
command execution. Command buttons are also called
push-buttons because of their physical appearance. Pushbuttons may be shaded or coloured to appear threedimensional. This coding enables them to show a pushedin (i.e. activated) versus pushed-out state on the visual
display, depending on whether they have been selected or
deselected via an input device.
4.4.4 Frequently, a menu option or push-button
command can be executed using keyboard short cuts, such
as function keys or key combinations (e.g. "Enter" key to
activate the currently highlighted push-button or "Alt" and
"F4" to close an open window). Before the widespread use
of the mouse, function keys were used extensively as the
only or primary method to activate menu options.
4.4.5 Another method used to execute commands
within today's applications is by directly manipulating
graphical objects on the screen, an example of which is
included in the "Data entry" section later in this chapter
(see also Appendix 2 to this chapter).
4.5
MENU DESIGN
"Many menu buttons seemed to be mrely used and

unnecessary to the controllers. Some of the commands were
mrely used because the contmllers found little benefit in
using them Others, the controllers believed, were unnecessary features. It was understood that some of the
cornmar& would be useful to contmllers in other sectors
with dzj5erent types of air traffic."

4.5. f. Menu design requires careful consideration.

Issues facing the designer include:
the number of options to offefer;
4-4
Human Facrors guidelines for
how to phrase and format the options;

how to organize options within the menu;
the number of levels to use;
how to help the user maintain a sense of orientation
within the menu structure.
4.5.2 Research on menu design has shown that design
solutions to these issues are important in terms of human
performance. Both direct and indirect costs can be reduced,
and benefits can be increased through menu design that
complements human capabilities and protects against
errors.
4.5.3 Number of options. This issue has received a
great deal of research attention. There is, however, no
single answer to the question of how many options to
present baause the answer varies from one context to
another. For example, the number of options in a
"coordination" menu for an approach control unit will
probably be lower than that for a large area control centre.
Where possible, four to six options are considered optimal
because this limits the demand on working memory.
Having too many options in a menu increases the time it
takes to find any one option. Having fewer than four
probably means that levels of the underlying menu structure
could be combined so that more options could be offered in
one place. With few options in a given menu, the user may
be required to select options from several lower-level
menus in order to reach a specific location in the menu
structure.
4.5.4 In contrast to these general recommendations,
research on so-called '%st" menus suggests that a menu
can contain up to 200 options if they are organized into
logical groups. Wtth large numbers of options, however,
problems arise in developing a menu structure and graphic
layout that reflect the underlying structure of the domain
information. For example, if the underlying structure is a
hierarchy. the menu structure should be hierarchical, i.e.
organized as a multi-level, branching structure of smaller
menus in which an option in a higher level menu is the
name of another menu at the next lower level. The options
in the l o ~ e s level
t
menus are such things as commands or
values; they are not the names of other menus.
4.5.5 Large hierarchies are difficult to traverse
efficiently. therefore hierarchical menus should be
organized and labelled to guide the user within the
hierarchical structure (e-g. when a user selects an option
from a menu, the menu and the selected option remain on
air traffic management (ATM) systems
display with the selected option highlighted, and the lowerlevel menu that results from the selection is displayed
adjacent to the selected option). Users should always be
able to return to the next higher menu level with one simple
action, as well as always be able to retum to the top-level
menu from anywhere in the hierarchy with one simple
action.
4.5.6 Phrasing menu options. Research has shown
that vague, ambiguous wording of menu options confuses
the user and detracts from performance. T3e purpose of
careful phrasing is clarity; this allows users to understand
the meanings of the options in terms of how the system will
respond. For options that are to be executed immediately
upon selection, a general recommendation is to use wording
that reflects the actions to be executed. Notice that the
emphasis is on action. Actions are denoted by verbs or verb
phrases, not by nouns or noun phrases. Common actions
that might be offered in an ATC hand-over menu include
Accept, Deny, Initiate and Retract.
4.5.7 W o other types of options are: 1) routings that
display a window or a cascading submenu; and 2) settings
that are used to define parameters or to specify an
application state. Routing options, such as Search,
Customize, Sort or Save As, should be followed by three
dots (an ellipsis) to indicate that another small window,
called a dialog box, will open when this option is selected.
The purpose of the dialog box is to present further choices
that are related to the higher-level action, for user selection
before the system can proceed. For example, before
carrying out a command to sort metering advisories, the
system may need to know the criteria on which the sort is
to be based. The alternatives should be presented in a
dialog box.
4.5.8 The wording used in menus should be consistent
with ATC vocabulary as it is used in the ATC environment.
New terminology or ATC terms that mean something
different from what controllers understand them to mean
should be avoided. This requires that designers and
developers survey ATC facilities and become familiar with
operational concepts to identify terms that are commonly
used for system actions.
4.5.9 Option labels should be concise and used
consistently from one menu to another. They should be
distinctive and mutually exclusive (non-overlapping).
Controllers can provide expert assistance in the
development and review of menu phrasing.
4.5.10 Formatting menu options. Menu options can
be formatted in a linear (vertical or horizontal) list or
presented in a spatial format. Although most menus tend to
Chapter 4. The human-machine intelface (HMI)

be presented as lists, some sets of menu options might best
be represented in a rectangular or circular format. Spatial
menus for ATC might take advantage of existing spatial
formats, such as the geometry of sectors within an area.
with than an arbitrary order. If frequency of usage is the

basis for organizing menu options, the less frequently used
options and destructive commands (such as Delete or Exit)
should k placed at the bottom of the menu.
4.5.11 Whether a menu is linear or spatial, each word

in a menu should be presented in upper and lower case with
the first letter capitalized. When a vertical menu is displayed, the location cursor should be on the first available
option closest to the top of the list When a horizontal menu
is displayed, the location cursor should be on the first
available option to the left.
4.5.17 To protect against accidental activation, menu

options that initiate opposing actions (such as Save and
Delete) should not be placed next to each other.
4.5.12 Menu options presented in a vertical list should

be left-justified, never centred in relation to each other. Left
justification allows the user's eye to follow a direct line,
rather than a jagged line, in searching for a particular menu
option. Other forms of justification increase search time
and conlribute to visual fatigue.
4.5.13 A window that contains a hidden popup menu
or menus should indicate the availability of these menus to
the user, One way to do this is to highlight the portion of
the display that can be selected to access the hidden menu.
Another way is to provide a textual message indicating that
a hidden menu is available. A third approach is to change
the shape of the cursor when it is located in a "clickable"
or selectable area. When a pop-up menu is selected, it
should be displayed in context, that is, close to associated
information. For example, if there is a popup menu for
each radar target, the menu should be displayed near the
associated target, not halfway a m s s the screen.
4.5.14 An option or set of options that is never
available to the user should not appear in the menu. If an
option is temporarily unavailable, it should be displayed in
its normal place in the menu but subdued in intensity
(dimmed down or greyed out).
4.5.15 Organizing menu options. There are three
acceptable ways to organize menu options:
in logical or functional groupings witb clear titles;

by frequency of usage, with the most frequently used
options at the top or beginning of the list;
in alphabetical, numerical or chronological order.
4.5.16 Logical or functional grouping of menu
options is recommended because it is more meaningful than
the other methods. A meaningful order is easier to work
4.5.18 For the sake of positive transfer, similar

options that appear in different menus should be ordered
consistently from one menu to the next. Any cascading
menus should appear to the right of the parent menu or
below t!he parent menu if there is insufficient space to the
right
4.5.19 The process of organizing menu options should
always occur in the context of the tasks to be performed by
the controller. A menu organization that properly supports
one set of tasks may not be as good for a different set of
tasks.
4.5.20 Number of levels. Research has shown that
when more than three to four levels are included in a menu
structure, users tend to feel lost or disoriented. To reduce
the likelihood that this will happen, menu users should not
be required to move more than three to four levels down
into a menu structure to locate a desired option.
4.5.21 Sometimes it may be necessary to make a
trade-off between the recommendations on number of
options (menu breadth) and number of levels (menu depth).
Ln such a case, evidence indicates that it is better to increase
the numbr of options per level than to add to the number
of levels.
4.5.2'2 If the menu structure includes more than a few
levels, designers should consider providing a way for the
experienced user to by-pass intermediate levels. Using fastaction keys, controllers can then go directly to specific
locations in the overall strucfme without having to step
through intermediate menus.
4.5.23 Supporting user navigation. When working
within a large, multi level menu structure, us& often lose
their bearings, forgetting where they are and which levels
they have traversed. To some extent, this disorientation
relates to the limits of working memory because it is
difficult to keep in mind one's position four or more levels
down in a menu structure while also concentrating on the
task at hand. To assist users in navigating easily within a
menu structure, graphical or textual aids should be
provided.
H u mm Factors guidelines for air trafic munagement (ATM) systems
4-6
4.5.24 A graphical aid may take the form of a small

schematic representation of the menu structure with the
path already taken highlighted. This miniature menu map
may be displayed continuously in a corner of the screen or
made available from a pull-down menu. An alternative to
the menu-map is a sequential list of the options that have
been selected. If they are not displayed continuously, menu
navigation aids should be available in the help function.
4.5.25 Resolving detailed design issues. This
discussion has surveyed major issues in menu design, but
many other detailed issues will need to be resolved.
Tentative menu designs should be subjected to systematic
testing with representative groups of controllers. The key
objectives of menu design, testing and redesign are to
minimize search-and-selection time and to minimize
navigational errors.
4.6 USE OF COLOUR

4.6.1 The effective use of colour on a display requires
careful attention to the definitions of the colours used and
the ways in which the colours are used. The development of
a coding scheme begins with an understanding of the tasks
to be performed and the identification of subtasks for which
colour coding may be particularly helpful (such as immediate identification of certain streams of W I C ) . From this
identification of tasks and the information required to
complete the tasks, we can construct a hierarchy of display
information. Such a hierarchy would include all of the
information to be displayed ranging from the background
information (e.g. a map), which should be present but
unobtrusive, to critical components of a display (e.g.
warnings that require immediate action, the cursor) that
require some form of highlighting.
4.6.2 While this hierarchy of display information will

help to determine how the information is colour-coded, the
first decision must be the choice of a background colour.
Black (or other very low luminance) backgrounds are very
good for colour identification and help to minimize display
flicker, but they can suffer from noticeable glare. Light grey
backgrounds minimize glare, but colour identification can
suffer and hicker is more apparent (and potentially
distracting) at higher lighting intensity. The selection of a
background colour should consider the task and operational
environment. In a dark environment, a dark background is
usually preferred. In high ambient light (such as in an ATC
tower), with a display that uses minimal colour coding, a
light grey background may be preferred. In office level
lighting, either light or dark backgrounds are usable when
properly designed.
4.6.3 Once a background colour is selected and a

hierarchy of information has been constmcted, colour
names can be assigned to specific groups of information.
While user input is important at all stages of display
development, an efficient strategy is to have structured user
input at the first stages of design (e.g. the construction of
the information hierarchy) and then again at the final stages
(evaluating the prototype displays). Human Factors
specialists are in a better position than users to design the
prototype colour schemes, since their designs will be based
on Human Factors "best practices" rather than user preferences. There is a tremendous amount of variation in
personal preferences for selection of display colours.
However, the colours that users prefer are not necessarily
the ones that will optimize their performance. Thus, having
a prototype colour scheme based on Human Factors
guidance not only minimizes variability, but also precludes
designs that may have a detrimental effect on performance.
4.6.4 Once a colour scheme that matches colour
names to groups of information has been developed, these
colour names will need to be defined to be optimally
distinct for a specific monitor. Once the colour set has been
defined, it should be validated by testing to ensure that no
two colours in the set can be confused and none of the
colours in the set adversely affect legibility. Again, these
are tasks for Human Factors engineers. The next and final
steps are a critical review of the colour scheme by users
and, finally, operational testing and evaluation.
4.6.5 In developing a prototype colour scheme, it is
very useful to examine the colour schemes used by other air
traffic organizations. It could be argued that since specific
colour schemes have been in use at other P;TC facilities
with no disastrous outcomes, the same colour scheme
should be applied elsewhere. However, since no two air
traffic control facilities have exactly the same amount, mix
and complexity of -c,
it could be a mistake to adopt
similar colour schemes without adequate operational
testing.
4.6.6 The use of color must be considered cautiously.
However, colour remains an effective, compelling and
attractive method for coding visual information on a
display. The use of colour in PirC displays presents
opportunities as well as challenges. Colour, when used
properly, is an extremely useful tool for organizing complex
information. Well-designed colour displays for AT!are
likely to have profound advantages over monochromatic
displays. The careful design and testing of specific colourcoding schemes with attention to the guidelines presented
here will help to realize the potential benefits of the use of
colour while minimizing the potential drawbacks:
Chapter 4.
The human-machine interface (HMI)
Whenever colour is used to code critical information it

must be used along with another method of coding,
such as reverse video or the use of different sizes of text
or symbols (see 4.10 "Visual alerting", later in this
chapter).
When colour is used to assign a unique meaning to
specific colours (such as red for emergencies or green
for aircraft under one's control), it is imperative that no
more than six colours be used.
Care must be taken to ensure all colour-coded text and
symbols are presented in sufficient contrast. '
Cultural colour conventions (such as red for danger and
yeiiow for warnings) should not be violated.
Pure blue should not be used for text, small symbols,
fine detail or a s a background colour.
Bright, highly saturated colours should be used
sparingly.
Colour use needs to be consistent across all of the
displays that a single controller will use.
The specific colours that are selected for a display must
take into account the ambient environment and the
capabilities of the specific monitor.
Any implementation of colour needs to be tested in the
context of the tasks that it is designed to support and the
environment in which it is intended to be used.
4.6.7 As a final point concerning the use of colour it

should be noted that results of ATC simulations indicate
that where colour coding of data blocks is used to divide
aircraft into groups (e.g. departure and arrival, or own
traffic versus other WIG) controllers may not notice
potential conflicts between two aircraft colour-coded
differently. In other words, the controllers tend to look for
conflicts only between aircraft pairs with labels in the same
colour. They tend to miss conflicts between aircraft whose
labels are coloured differently. This suggests that colour
coding of data blocks should only be applied in
combination with a short term conflict alert (STCA)or
similar device.
4.7
DATA ENTRY
4.7.1 The simplest data entry method is free text entry

into a large field (e.g. for a data link message to be
transmitted to a pilot). Generally, little or no data entry

restrictions are placed on such a field, and the computer
firforms tittle data validation.
4.7.2 A fill-in-the-blank form allows the user to enter

data into predefined, labelled fields. Labels should be used
consistently within and throughout all forms and should use
specific, user-oriented wording (e.g. accepted ATC tenninology). Data entry items should be logically ordered and
arranged according to user expectation. This method
facilitates computer validation of the entered data.
4.7.3 When the same set of data must be entered for
everall entities (e.g. aircraft flight information for all
currenlt traffic), a iable is often the best data entry form.
Labels are required for both columns and rows. The first
column should contain the most salient discriminating
feature that identifies and distinguishes the row (e.g. flight
number or aircraft identifier). There should be row and
column scanning aids (e.g. on every third rowlcolumn a
blank lor shaded rowfcolumn). If the user needs to run a
finger down the table or hold a ruler up to it, this is
indicative of poor table design. The table (and other forms)
used for data entry should be compatible with, or identical
to, display data on tabular and other displays.
4.7.4 In general, another sign of poor design is the
"sticky" note posted in or around the workstation area. If
controllers need to post notes, the design has failed to
capture and provide all necessary information.
4.7.5 Data entry may also be achievsd via direct

manipulation of graphic objects on the screen. For example,
to enter a revised flight route for the pilot to fly, the
controller could select points on a map (e.g. by pointing
with the cursor/mouse and selecting by pressing and
releasing the mouse button) or could "bend" the pilot's
currently planned fight path (e.g. by selecting a point on
the route and pressing and holding h e mouse button while
moving the mouse). Direct manipulation interfaces support
a highly natural flow of communication between the user
and the computer and therefore could be a useful means to
help realize a human-centred design.
4.7.6 Figure 4 1 shows an example of a direct
manipuliation interface for a route revision from The
Australian Advanced Air Traffic System ( T M S ) . A
graphic re-route is in progress, indicating a change to the
north of the original route. The internal flight plan in the
system is automatically updated with the new way-points,
and the new clearance (preformatted by the system) may be
uplinked by CPDLC to the aircraft.
Human fictors guidelinesfor air trufic mmcinagemerzt ( A T M ) sysrcms
4-8
Figure 4-1.
Example of a direct manipulation interface
4.7.7 For cluttered screens, where many selectable

graphic objects are in close proximity, it helps to provide
users the ability to zoom (or enlarge) a portion of the
display for precise pointing. Usualiy, the selectable objects
remain the same size while other information (e.g. a
background map) is magnified so that selectable objects
appear farther apart.
progress strips have significant potential in terms of

automated assistance to the controller in maintaining
Situational Awareness - but so do paper flight progress
strips. The challenge for system designers therefore is to
identify what elements of the controller's Situational
Awareness provided by paper strips can be transposed to an
electronic format and how best to achieve that.
4.7.8 Once selected, a graphical object should be

highlighted, so that the user knows the next acti,on will be
applied to it. For certain transactions, the user should be
able to select a set of objects (e.g. by holding the Shift key
and clicking on several objects o r drawing a box around a
grouping or specifying a characteristic shared by all objects
in a group). Once the grouping is specified, the user can
initiate a transaction on all group members. For example,
the controller may want to transmit the same message to
several aircraft.
4.8.2 Electronic flight progress strips can be an

integral part of an ATM system featuring flight data
processing, i.e. dynamically keeping track of flight
parameters derived from flight plan data and surveillance
information. W~th paper strips, controllers write down
changes in these parameters on each strip (which, as an
action, serves to help them maintain Situational Awareness)
and often must coordinate such changes with other
controllers. Electronic strips can be updated automatically
by the system, and changes can be displayed at all affected
working-positions of the system. Furthermore, automated
exchange of data with other ATM systems for coordination
becomes a possibility, thus potentially reducing controller
workload.
4.8
4.8.1
ELECTRONIC F1,IGHT
PROGRESS STRiPS
Although the introduction of electronic flight

progrrss strips to replace the traditional paper versions is
regarded by many controllers as a controversial issue, it
would be a mistake not to consider their use when
desi~ninp an advanced ATM system. Electmnic flight
4.8.3 It is important for system designers to preserve

as much as possible the Situational Awareness-enhancing
attributes from paper strips when ir-.:roducing electronic
flight progress strips. Yet this does not necessarily imply
that every checkmark or annotation currently utilized by
controllers should be mimicked for the electronic version.
Designers rather should attempt to capturc the essence of

the checkmark or annotation, and provide an alternative for
it in the new system. Is the mark on the paper strips there
to denote the completion of an action, or is it there to
indicate that an action still has to be taken? Is the position
of the mark on the strip of relevance to the controller, and
if so, why? Oncc these and other questions have been
answcrcd, it will be possible to look for means and mcthods
to providc the controller with sinlilar functionalitics in the
ncw system.
4.8.6.1 The first box on the Icft of the strip contains

an orientation indicator (a green triangle indicating a
nonhbou~ldflight), the controlling sector and the llight plan
state.
4.8.6.2 The second box from the left shows the call
sign (QFA12 - Qantas 12). CPDLC status (colour coded
call sign). wake turbulence category (H - Heavy). SSR
code (121 I), aircraft type (B744 - Bocing 747-3W).
departure point (YBBN - Brishanc). destination (SZAA
Auckland) and departure timc (0000).
Thc third box shows the true airspeed (KO475

reported lcvel (304) and the FIR
exit time (01 16).
4.8.6.3
4.8.4 One specific issue for dcsigncrs to consider is

the importance of crossed-out items on paper strips and
how to retain that same import:rncc in an autornatcd systcnl
with electronic flight progress strips. For example. aiicr
clearing an aircrafi to a higlicr tlight Icvcl. a controller
norlnully writes do\v11 rtlc IICLV Ic\cl ;tnd crosses orlt tlic
prccic~usly;rssigr~cdIcscl. Yct iil' (11' icvel cils~lgewas ;I
t;ic~ic;iIdecision tiom thc citr1lro1lc.r i n ortlcr lo rc'solvc ;I
cotiflicl. the ;lircr:tff 111;1yI;~lcrhc cIc;~rc~i
hack to ils origir1;ll
Iligli~Icvcl h;iscd OII tllc cro\\cd-oul saluc o n tl~cstrip. 'l'llis
\vot!Id ir~lply tI1;1t i l l a11 a~rto111;1tccIcnvironnlcnt the
controllcr 111ust Ilavc access to tlic origitl;~l valirc o f the
Ilight level cvcn after thc new Icvcl is displayed hy the
system. One possible way o f doing this is hy displaying the
aclual tlight Icvcl, the assigclcd lligt~tIcvcl and the lilcd or
rccjucstcd tlight Ie\8cl,all a! 1111. sanlc t i ~ l ~ c .
4.8.5 If rile rlcw s>stem features a traffic siltration
display and this was not availnhlc in the old systcm. i t
n ~ hc.
y possible to "transfer" some 01' the Sitt~ation;~l
Awareness-cnhnncing attributes from paper strips to the
lahcls on the tral'lic situatior~displ;ry. (See as an cxnn~plc
Appendix 2 IODIAC] 10 this chapter.)
- 475 knots). the pilot
4.8.6.4 The fi)urth hox contains the requested flight

lcvcl (330). the cleared Ilipflt Icvcl (330) and the
coor.clination Iligllc lcvcl (3.30).
4 . . 13ox five shows the prc\,iot~slix (DUDID). rhc
next lix (I'ONIIL). rllc I I C X I lis plus onc (1JII). the acti~cllor
csti~naccd tirnc ovcr the fix (007X/0034/0051) and thc
prolilc Icvcl (330).
4.8.6.6 The sixth box. a1 the hortonl lcli of ccntrc.
contains other inform;~tionor remarks (/AlISEP. to indicate
1Ii;lt thc ;~ir.craliis qualilicd for spccilic nation;tl scpnnltion
crilcrin).
3.8.6.7 The scvcnrll hos. to tlic rig111ol'tllc previous
31 the hottonl. shows the FIR entry tinlc (in this c:isc
o ( ) ~ M ) as tile Ilight depar-ts from an acmdntmc ~\rithir~
the
FIR).
one
1.8.6 Figurc 4-2 silotvs an csamplc of an c l c c t r ~ ~ i i ~

4.8.6.8 'Tile final hox. on the botto111 right. is a
Slight progress strip from The Australian Advanced Air
scc~tcltpadl area where a controller can add notcs. if
Tralfic Systerll (TAAATS1.
required.
Figure 4-2.
Example of a n clcctronic flight progrcss strip
Human Factors guidelines for air traffic management (ATM) systems
4-10
4.9
USER GUIDANCE
"For the keyboard there is a problem with the meaning of

theficnction keys. A few conrrollers said that it is difficult to
remember the meaning of each of the fiinction keys. This is
made more complicated because the meaning of the
function keys changes under different system modes. "
of Ihe Oceanic Data Link System (FAA* 1997)
4.9.1 User guidance includes alarms, prompts, labels,
error messages and instructions provided to guide the user's
interaction with the computer. Effective u.ser guidance
contributes to meeting several of the HMI design's general
objectives:
consistency of operational procedures
elficient use of full system capabilities
limited memory load on thc uscr
reduced lcarning time
flexibility in supporting diffcrcnt users.
4.9.2 Because it is oftcn difficuit for a software
developer to crcate messages that are clear to the user
community. it is recommended that a ream including a
software developcr, a Human Factors specialist and a controller rcprescntative collaborate on guidance jnessage
devclopment.
4.9.3 Guidance mcssagcs should provide any required
context infonnation (e.g. a history of prcvious entries).
Both on-1inc and hard
of a
of
abbreviations and lcgends for all symbols and codcs should
be provided. In addition to on-line help, the controller
should have access to a complete list of error messages with
detailed explanation in hard copy form (e.g. within the user
manual).
"Thc fecdback for some errors \r9asfound to be too vague

to be tr~eat~it~Rfiil
or irelpjicl to the users. An example of a
cryptic error feedback message is "Bad Format", wltich is
received crfter the user olters data tl~atis not i r ~a proper
fortttar. A more dctrriled feedback message about the format
error and tlre t ~ c c e s s nsolrrtintr
~
~coorrldbe iisejrl to r11e
user: It rtfcrs icr~derstondthat sot?ze crmr nres.rages co~ildbe
c/icked on to gcr more irlfon~latiorlaho~ltthe fonnat errors,
but niost corrtmllers did not seem to he a$c9areof this
fcatlrrc. The pmblem wit11 tllis npe offiaralre is tfiar thcre
is no indication that the user needs to click the message to

get the information. In addition, the messages provided with
this feature were ofren not very helpfirl. "
4.9.4 Typically, users commit two types of errors:
expert errors and novice errors. An expert error o r "slip"
occurs when the user h e w what should have been done but
inadvertently performed the wrong action. This can occur
without direct awareness and is not likely to be remembered. In such a case, the user needs the computer to report
the user's action. A novice error or "mistake" occurs when
the user knew the action, but thought that the action
sequence was correct when in fact it was not. In such an
instance, the intention is flawed and the user needs to know
what action should have been taken. Any user is likely to
commit both types of errors, although with experience
novice errors will be less prevalent. To address both typcs
of errors, messagcs should summarize the problem and
proposc a solution. Expert users may choose to downsize
an error nvxsage window so (hat only the problem statcmen[ is in view. When an error is detected, the computer
should display an error message stating both what is wrong
and what can be done. When the set of acceptable
responses is small, these should be provided.
4.9.5 To address the needs of both the novice and the
as well as an individual's specific needs, [he
puter should support multiple levels of etror messages.
are many ways to accomplish this:
A controller-defined capability may be provided to set

the message level as abbreviated or detailed;
An error message window may be provided that can be

sized so that only the beginning of a message (which
should be the most informative part) is shown;
A capability may be provided with each message to

expand the text with explanations, examples and perhaps illustrations; or
0
Messages may be tied closely to a help application (e.g.

an on-line user manual where the controller can click
on "hotspots" to jump to various topics andlor tutorials)
so that the controller can quickly transfer into the
appropriate area of help. For example, each message
window can include a "Help" push-button through
which the controller can access specific information
associated with the current problem.
Chapter 4.
The human-machine intelface ( H M I )
Specifically:
Error messages should always be written in the active
voice and be as specific as possible while, at the same
time, minimizing wordiness.
Error messages that are too generic (e.g. "Invalid Entry"
or "Invalid Drive Path Specification") or too obscure
(e.g. "Error #E211A07") should be avoided.
Error messages should describe the problem and the
recommended solution(s) in very specific terms, that is,
they should tie the problem to a process, object,'action,
file, data entry field or other data element.
Terms used in error messages should be task oriented
and familiar to controllers.
Error messages should be unique (i.e. only one possible
message for each error) and should not be redundant
(i.e. each error generates only one message).
Guidance messages should promote the idea of the
computer as a tool, not a person, and should affirm the
controller's sense of being in charge.
Wording of feedback messages should reflect fact rather
than make value judgements (e.g. instead of "Flight
Conditions = Excellent," state "Visibility = 50 miles").
Prompts should indicate a ready mode (e.g. an ''I"shaped beam for data entry) rather than telling the
controller what to do (e.g. ENTER DATA>).
The computer can prompt the controller for a logical
action (e.g. "Save training session Alpha before Exit?")
but should never automatically perfonn a task or switch
the controller into or out of a mode without being
explicitly instructed by the controller to do so.
4.9.6 Since part of the user population may be
unfamiliar with computers or may be accustomed to modem day "friendly" applications, computer messages should
be constructive phrases written in a positive tone. Messages
should be worded in the affirmative, not the negative. They
should instruct the controller on what can be done, rather
than on what is wrong or not possible. Any blame should
be placed on the computer, not the user; e.g. a value should
be described as "Unrecognized" or "Not within range"
rather than "Illegal" or ''Ifivalid."
-
4.9.7 Message wording and tone are key components

in error message development. Historically, computerized
messages were written in condemning and extreme

language. It was not uncommon to get a "FAXAL" or even
"CATASTROPHIC" error or have a "RUN ABORTED or
'mRUINmD."(Messages were often in all capitals to
further emphasize the severity of the error.) User actions
and entries were deemed "Bad," "Illegal," in "Error" or
"Invalidl" This approach can be unsettling to a person not
familiar with the programming world in which operating
systems and compilers, even today, commonly display
harsh messages. Wording should reflect the controller's
understanding of the system and avoid any codes, references to computer user manuals, or other information that
may not be readily available.
4.9.8 In general, users prefer mixed upper and lower
case. People can read mixed case messages more quickly
than messages in all capitals, and mixed case makes error
messages appear less harsh. Messages should preserve
consistency in grammatical form, terminology, phrasing,
abbreviations, punctuation and other grammatical elements.
Visual format and placement should also be consistent.
Error messages may be presented in a pop-up message
window, which the controller should be able to quickly
dismiss, for example. by pressing a confirmation pushbutton, or perhaps by clicking anywhere on the screen.
Error messages can also be presented as a closable
message-log window, which should be displayed upon log
on unless otherwise specified by the controller, or via an
audible beep.
4.9.9 Audible "beeps" provide one alternative to
textual error messages. These are most appropriate for
minor errors committed by expert users, who need to be
informed of the problem's occurrence but not given the
solution. The sound of the audible tone should be subtle
and pleasant. Since users often find an audible cue to be
embarrassing or annoying, they should be able to turn off
the tone or replace it with a visual cue, for example, very
brief dimming of the screen. If the controller repeats the
error two or more times successively, a textual message
should be provided.
4.9.10 Error messages should be presented
immediately after the error's occurrence. In order not to
disrupt the user's task, the computer should allow the
controller to finish entering data in a field before the
computer validates the entry, e.g. the user indicates completion by moving to another field. A special key (e.g. a
function key or the *'Returny'key) can be used to allow the
controller to move quickly to the next erroneous field using
the keyboard. Guidance messages should present a series of
actions in the sequence that the controller would normally
foiIow.
4-12
Human Factors guidelinesfor air traffic m g e r n e n f (ATM) systems
4.9.1 1 The following are some areas where computer

messages or feedback should be provided:
Processing delay: acknowledge receipt of request,
specify process and length of delay, indicate per cent of
processing complete and provide feedback when
processing is complete.
Limits not met or exceeded: specify appropriate range.
Unrecognized command action (e.g. mouse click) or
data entry value.
performance data collection routine can be implemented to run in the background. This routine could
record the frequency of each error message. Any
message that occurs frequently in a session or across
controllers points to user-interface issues that need to be
redesigned.
4.9.14 Guidance messages should provide any
required context information, e.g. a history of previous
entries. Users should have access to an on-line and hard
copy dictionary of abbreviations and legends for all
symbols and codes.
Status information (e.g. current mode).

Prompting for logical action (e.g. save before exit).
Confirmation of destructive entq, especially if the
action is irreversible (e.g. delete).
Cautionary messages or highlighting for questionable
entries.
4.9.12 To maintain consistency and promote ease of
error message evaluation, a single file of computer
messages should be created. This allows software developers to access a common set of computer messages or to
create new ones using templates provided in this file, e.g.
"[task type] processing will be complete in [time value]
[minutes or seconds unit of measure]".
4.9.13 The complete set of computer messages should
be reviewed by controllers who are only minimally familiar
with the new system (e.g. not those who have been involved
in system development). Evaluation and d e s i g n of
messages should occur where appropriate to eliminate
uncommon or unclear words, phrases, abbreviations and
acronyms. The following evaluation methods are suggested:
Show an error message and ask a controller to describe
the problem that caused it and the solution to remedy it.
This will determine whether the message is intuitive
with explicit remedies or needs to be changed to make
it more readily understood.
Describe a problem with several potential error

messages and have the controller select the best one.
Present a problem and an error message and have the
controller note any aspect of the message that is
confusing, superfYuous or incomplete. Once error
messazes are implemented on the ATC coimputer, a
4.10 VISUAL ALERTING

"The large number and variety of coding dimensions
results in added complexity to the HMI and possible
confusion to the users. The requirement to remember all the
coding dimensions can interfere with the controllers' main
task. "

4.10.1 There are many factors that affect the
effectiveness of visual alerts and coding techniques. Some
of these factors are related to the physical parameters (e-g.
brightness, location) of an alert and others are related to its
functional parameters (i.e. does it perform as it was
intended to perform). The goals of visual alerts and coding
techniques are to effectively direct the controller's attention
to important information that might otherwise be missed or
to critical situations that might othenvise take longer to
recognize. Both the physical and functional parameters of
ale- should be evaluated in order to ensure that the alert
is effective and useful.
4.10.2 It is important that the alert be useful to
controllers and not be an annoyance. The alert must provide
the controller with useful information in a timely manner. If
the controllers consider an alert to be annoying, then the
alert needs improvement. The problems with the alert may
be related to its physical parameters (e.g. the location, blink
rate or contrast of the alert) or to its functional parameters
(e.g. it does not activate when it should, or it goes off when
it should not). In either case, the problem will have
implications for human performance. For example, any
alert that generates a high percentage of false alarms will be
considered annoying and, eventually, controllers may begin
to ignore it. Similariy, an alert that continues to be activated
after it is no longer needed is unnecessarily distracting.
Chapter 4.
-
4.10.3 The following coding and emphasis techniques

can be used to attract attention to specific information or to
categorize information on a display:
4.11 AUDITORY ALERTS

4.1 1.1 With respect to auditory alerts it is important to
serve the following "dos and don'ts":
blinking or flashing
use of different sizes (of text or symbols)

colour
location.
4.10.4 All coding techniques have advantages and
disadvantages. For example, flash coding is good for
attracting attention, but flashing text is difficult to read The
critical importance of specific information can be indicated
by a separate blinking symbol placed near the information
that must be read. The controller should always be able to
turn off blinking or flashing. The blink rate should be
between 0.1 to 5 Hertz (Hz),with 2 to 3 Hz preferred. No
more than two levels of blinking should be used because
more will be difficult for controllers to discriminate. Flash
coding or blinking should be used sparingly and should
never be used for text or numbers that are critical or that the
controller needs to read quickly.
4.10.5 Critical, abnormal or updated data should be
emphasized or highlighted using such techniques as reverse
vidw, shadows, brightness or colour coding. In each case,
the levels of shadows or brightness used (as well as
different colours) need to be distinctive and easily identified
in order to be effective highlighting tools.
4.10.6 Overuse of a coding technique or the combined
use of too many techniques can result in unacceptably
"busy" visual designs. If size coding is used, it is
recommended using only two widely different sizes
Emphasis should be placed on simplicity and clarity.
4.10.7 Colour coding is especially useful for
highlighting or categorizing information on a display.
Highlighting must be used sparingly so that emphasized
items will actually "pop out" fmrn the others. If too many
items are emphasized, none will pop out. Use of colour is
discussed in detail in the next three sections of this chapter.
...
4.10.8 The location of information on a display is a

function of both the physical area of the display surface and
the position of the eyes relative to the display screen. vsual
alerts will be recognized more quickly when placed in the
area of the visual field that has the best visual acuity than
they would if placed in the periphery.
Do not overload the auditory channel: In any situation,

it should be impossible for more than a few auditory
alerts to be presented simultaneously. If there is one
underlying problem, rather than activating multiple
dams, the problem should produce one high-level
alarm message indicating the root cause. As an example
of overloading, the Three Mile Island nuclear crisis
activated over 60 auditory warnings in the power plant's
control room. adding to the confusion.
Avoid conflict with previously used signals: Where

practical, newly installed signals should agree in
meaning with previous ATC system signals.
Promote intuitiveness: Auditory alerts should make use
of natural or learned relationships familiar to
controllers, e.g. wailing signals mean emergency.
Promote discemability: Auditory alerts should be easily
recognized among the other signals and noise. Use of
synthetic speech or tones of varying frequencies will
usuiilly create a highly distinct warning.
Do not overload short-term, working memory: The

auditory alert should not pmvide more information than
is necessary.
Promote consistency: The same signal should always be
used to indicate the same information and should not be
used for any secondary purpose. The meanings of
specific auditory alerts should be documented in a
design standard or style guide to ensure consistency in
thek implementation.
Avoid extremes of auditory dimensions: For example, a
high intensity alarm could startle the controller and
disrupt performance. Ali a l m s should be of moderate
intersity (or volume). Alarm signals should be spaced
relatively far apart and kept within a moderate range.
Establish intensity relative to ambient noise level:
Signal volume should be loud enough to be heard over
background noise.
Use interrupted or variable signals: To minimize
perceptual adaptation, use interrupted or variable
signals rather than steady signals.
Human Factors guidelinesfor air rraffic management (ATM) system
4-14
Test the signals to be used: Use a representative

controller sample to make sure users can (detect the
signals in their working environment. Signals should be
tested in realistic ATC work conditions to ensure
distinctiveness. They should also be evaluated for
suitability and acceptability.
Facilitate changeover from previous display: When
auditory alerts are replacing visual warnings, use both
simultaneously during the transition period. In .some
cases, it is preferable to maintain both permanently, for
example, a visual display to illustrate spatial relations
and a voice message to provide a verbal reference.
The controller should be able to cancel auditory signals:
A capabiiity to cancei signais will help to minimize
annoyance caused by auditory alerts anld prevent
possible disruption to the controller's processing of
other information.
4.1 1.2 In summary, auditory signals need to be
distinctive, concise, clear, audible and invariant. Testing is
necessary to ensure that they meet these usability criteria.
4.12.2 These objectives can be achieved by adhering

to the following recommendations:
The air WIG controller should have information to
determine which aircraft have a data link capability and
the level of that capability. It is recommended that data
Iink system availability should be indicated only when
the aircraft has the capability to receive and process all
controller.
data link services provided by the air -c
The use of unique indications for multiple levels of data
link capability is not precluded. However, empirical
research should be undertaken to ensure that the larger
number of indications does not degrade air traffic controller performance. For air traffic controller positions
operating with a traffic situation display, indications of
an aircraft's data link system status should be associated
with the aircraft's label or position symbol.
The data link system should provide capabilities for
message generation such as the following:
- form-filling -either controller entry or retrieval of

stored parameters to fill in predefined message
templates;
4.12 SPECIFIC RECOMMENDATIONS

FOR THE CPDLC KMI
"One concem is that the large number of message

composition steps causes contmllers to pay attention to
system-generated tasks and be distracted from the true task
at hand, which is to keep aircraji separated. Another
concem is that the number of steps is cumbersome and time
consuming."

4.12.1 This section includes functional smd design
requirements for the CPDLC HML When developing data
Iink systems, the need for error protection should be
balanced against the need for ease of use. This is a
fundamental trade-off, to the extent that automated e m r
detection cannot trap every possible critical e m t It is
critical that the content of CPDLC clearances and clearance
requests be checked for reasonableness and implications to
flight safety. However, because the system will be used
frequently, the process of entering data into the system and
transferring data to and from the system needs to be as easy
as possible in order to reduce the total number of
keystrokes that should be made and the amount of attention
that should be paid to CPDLC operations. The HMI design
should reflect trade-offs made between ease of use and
error protection.
- free-form message text entry;

- selection of predefined messages and phrases from
a menu;
- entry
of commands or use of fundion keys to

quickly format messages;
- selection of computer-generated message data.

The data link system should provide feedback for every
user input in time to prevent doubt about the status of
the input
Any unrecognized or unreasonable entry should promp
an e m r message from the system and should not result
in any data changes. The system should provide the
information needed to assist the controller in determining the nature of the e m r and how the error could
be corrected
The HhfI should clearly distinguish between the various
functions and modes of the system and indicate the type
and format of data expected. To the extent possible.
data link systems should ensure that data intended for
one purpose cannot be used erroneously for a different
purpose.
Chapter 4.
The human-machine interface ( H M I )
The HMI should clearly differentiate functions that are

available for use from those that are not available, based
on the current context of the system or message status.
For example, applicable response options should be
indicated when a specific message is selected by the
controller.
If speech generation technology is used to present
CPDLC messages, it should be used redundantly with a
visual display, unless research demonstrates that such
redundancy is not required. Speech generation applications should meet or exceed current levels of
intelligibility and comprehensibility achieved with
voice radio without increasing controller workload. If
speech generation is provided, the controllers should be
able to select it on and off, have the message replay,
mute the message, and adjust the speech rate and
volume through headsets and speakers. It is further
recommended that speech presentations of messages be
preceded by an aural pre-alert such as a tone or aircraft
call sign to orient the controller to attend to the
message.
The controller should not be required to enter the same
information multiple times. In addition, it is desirable
that data link systems be designed to facilitate sharing
of information needed for multiple functions.
Control logic for CPDLC operations should permit
completion of frequent or urgent data link-related
operations with a minimum number of actions and
keystrokes and minimum controller memory load. Only
one action should be required to see the next or
previous display page of a CPDLC message.
Lines of text should be broken only at spaces or other
natural delimiters. Parameters associated with text
should be adjacent to and grouped with their descriptive
or explanatory text or labels and should be on the same
page. If the complete message cannot be presented on
the same page, there should be a clear indicator to the
controller that the message continues.
A minimal number of inputs should be required to
compose or respond to a message.
The CPDLC system should provide a preview of all
messages as they are composed and before the
controller sends them; the system should support
editing of controller-composed messages.
To reduce workload and data entry errors, common
messages and message response options should be
predefined or composed by entering data into
predetermined formats.
For messages that require a controller response, the

CPDLC system should indicate the set of appropriate
response options as established in current procedures.
For clearance requests from the flight deck, the CPDLC
system should generate and present an appropriate
clearance as a response option for controller review and
uplink.
For controllers, the CPDLC HMI should facilitate
message composition by providing a predefined set of
frequently used messages tailored to the position's
operation.
To the extent possible, the system should automatically
manage designation of the message addressee. This
should not preclude controller designation of the
message addressee.
When multiple CPDLC messages are waiting, the
system should facilitate responses by order of urgency
first and age second. More urgent messages should be
answered before less urgent messages. W~thinlevels of
urgency, messages should be displayed and answered in
order of oldest to newest, based on sending time. The
controller should be able to manually select messages
for display.
When a previously issued clearance or clearance
request can be identified as having been superseded by
a new message, the previous message should be visually tagged as being superseded. If the message that is
being superseded has not been displayed to the
controller it may be automatically cleared from the
queue; however, the crew should be notified that the
message has been cleared and should acknowledge this
notification.
A new message should not automatically cover and
displace a message currently being displayed. Disruption due to automatic overwriting of a message
being processed by the controller should not be
possible, and errors due to the association with a new
message of a response intended for an old message
should not be possible.
It should not be possible to inadvertently respond to a
message so soon after it appears that it could not have
been read; a minimum two-second delay between the
appearance of the message and its response should be
implemented. All of the message should have been
displayed before a positive or negative response is
allowed.
4- 16
Hrtrnan Factors guidelinesfor air trafjric mnugenzen: ( A TM) systems
CPDLC implementations should minimize any increase

in controller visual attention to display locations that
will interfere with attention to high priority tasks.
In order to minimize controller re-entry of data, it is
recommended that the CPDLC system be integrated
with appropriate N S system functions.
CPDLC installations should not prevent the controller
from performing other high priority tasks by either
requiring excessive devotion of the controller's attention
or by tying up the equipment needed for the olther tasks
with data link functions.
Conclusion
4.13 The HhfI is the most important part of the
system for the user. Throughout the lifespan of the system,
which typically is in the range of 10 to 15 years, the user
will use the HMI to make the system work and to get
support from the system in the user's task execution. As
was argued earlier (see Chapter 1 "Incorporating Human
Factors knowledge"), it will pay off in the end, both in time
and money, to invest adequate resources during the design
phase of the HMI. The guidance provided in this chapter
will help to achieve an optimal HMI design for advanced
ATM systems.
The alerting function for incoming CPDLC messages

should be easily distinguishable from any other alerts
presented at the controller's workstation.
R~~~~~~~~~
Maximum use
data link
undue
competition for display or control resources. Data link
systems should not preclude access to other functions or
unduly conflict with higher priority operations.
Cardosi, Kim M. and Elizabeth D. Murphy. (eds.), Human

Factors in the Design a& Eva[uarionof Air TrafiC Conrml
Systems, United States Department of ~
~
Research and Special Programs Administration, ~~h~ A.
Cambridge, MA, 1995. (DOTIFAARD-9513 DOT-VNTSC-
Use of colour for CPDLC message display should be

consistent with established standards for air traffic
controller workstation colour coding.
The controller should be able to suspend ongoing data
link functions to access other functions at any time and
resume the suspended data link function at the point at
which it was suspended. Clear indication s,hould be
provided of where the controller is in the suspended
operation.
If data link operations share display and control
equipment with other functions, one controller's use of
data link functions should not impede another
controller's use of other equipment hnctions,
particularly if there is only one of the equipm,ent at the
workstation.
All information required in a data link operation should
be available for display during the data link operation.
The controller should not be required to rely solely on
memory at any point during the transaction.
FAA-95-3.)
Cardosi, K. and D. Hannon, Hannon Consulting,
Guidelinesfor the Use of Color in ATC Displays, United
States Department of Transportation, Research and Special
Programs Administration, John A. Volpe National
Transportation Systems Administration, Cambridge, MA,
1999. (DOT/FAA/AR-971 DOT-VNTSC-FAA-98-5.)
Computer-Human Inteface Evaluation of the Oceanic
Data Link System, Federal Aviation Administration, Human
Factors Branch, ACT-350, WlHiarn J. Hughes Technical
Center, Atlantic City International Airport, NJ, 1997.
The Human Factors Design Guide. The United States
1)epartment of Transportation Federal Aviation Administration Technical Center, Atlantic City, NJ, 1996.
(DOTffAA~CT-9&rl.)
Human Engineering Guidance for Data Link Systems.
RTCA. Inc., Washington, DC, 1997. (RTCA/DO-238.)
Appendix 1 to Chapter 4
THE NEW ZEALAND

OCEANIC CONTROL SYSTEM (OCS)
1. Phase 2 of the Oceanic Control System (OCS) that

was commissioned in 1999 by the Airways Corporation of
New W a n d consists of an integrated flight data processing system (FDPS), a datalink communications system
(for both CPDLC and ATC Inter-facility Data Communications [AIDC]), a traffic situation display, electronic flight
progress strips, a meteorological and NOTAhf database and
a conflict probe.
2. The workstation (Figure 4-A1-1) has two displays
(2 000 x 2 000 pixels). One is the Traffric Situation Display
and on the other are the communication message queues,
electronic fight progress strips, coordination and clearance
windows,
the
window and a connict summary
window. The Situation Display can be zoomed in (i.e. the
range can be decreased), and a window can be superimposed on either display.
3. The Traffic Situation Display shows aircraft

symbols much like a contemporary radar display does, but
the symbols represent either a radar-derived aircraft
position, an ADS-derived aircraft position or a "projected
position*' (i.e. a position computed by the OCS, based on
position reports, estimates and flight plan data). For each of
these categories of position information a different symbol
is used to represent the aircraft concerned.
4. Each symbol is connected with a label in which the
controllers can see the most relevant control parameters for
the flight The labels include mandatory and optional fields:
call sign, CPDLC log-on indicator, destination special code
(e.g. RNP [Required Navigation Performance] certified,
RVSM [Reduced Vertical Separation Minima] certified,
etc.), reported flight level, climb/descent indicator, cleared
flight level. lower block flight level upper block flight
level, Mach number or True Airspeed, ground speed SSR
[Secondary Surveillance Radar] code/mode. distance-based
separation flag, Mach number separation flag. Additionally,
the label will show alerts such as "position report due",
"coordination due" or "coordination in progrss".
T h e ADS interface
5. In the permanently displayed AT'S Facilities

Notification (AFN) Wtndow (see Figure 4-A1 -2) the
controller can see the status of the data link connections
between the OCS- and FANS-1/A-equipped aircraft The
log-on sequence for an aircraft starts with establishing an
AFN connection, normally followed by establishing ADS
contracts. Subsequently, the CPDLC connection may be
established.
6. The OCS automatically establishes two default
contracts for a flight: a Periodic Report contract and a Waypoint Event contract. The controller can modify a contract
whenever necessary. To do so, the controller clicks on the
"Edit ADS..." button at the bottom of the AFN window,
after which the controller gets access to a template for the
desired contract type (i.e. Periodic, Event or On Demand).
7. As an example, the Periodic Contract template is
shown in Figure 4-A1-3. The call sign of the flight to which
the contract pertains (QFA36 - Qantas 36) is displayed at
the top of the template. Below that are eight items that may
be included in the periodic reports. In the example the
frequency for the ADS reports is set at 15 minutes and 00
seconds, which in reality means it will be at 14 minutes and
56 seconds (the OCS corrects the frequency entered by the
controller to the nearest possible periodic reporting rate).
Of the seven remaining items, one (the Airframe ID) is not
available which is indicated by "greying out" the option in
the list. All other six items are selected for inclusion in the
reports. ' R e "modulus" column gives the controller the
option to set how often each item should be included in
consecutive reports. in the example all values are set to "1".
which means that in every report each item will be
included. If a value were set at "3". this would imply that
the related item would only be included in every third ADS
report fmm the aircraft.
8. The item "Earth Reference" comprises the

aircraft's true track. ground speed and vertical rate. The
Human Facrors guidelinesfor air traffic managemenr {ATM)systems
4-A 1-2
item "Air Reference" comprises the true heading, Mach

number and vertical rate. Both items are normally not
displayed to the controller, unless the parameters are out of
conformance (i.e. exceeding a pre-set tolerance value).
9. By clicking the "Send" button at the bottom, the

controller activates the contract with the (avionics of the)
aircraft.
10. Similar templates are available for Event contracts
and On Demand contracts.
Note.- For an exphmrjon of the different categories of
ADS contracts, see the Manual of Air Traffic Services Data
Link Applications, (ICAO Doc 9694) Pal? I I I , Chapter 3.
The CPDLC interface

Ihe OCS features
menus in a Message
Processing window to generate CPDLC messages for
'plinking to the aircraft. An
of the Message
Processing window is depicted in Figure 4-A14.
12. The top line in the window shows the call sign of
the aircraft with which the message is exchanged (DLol).
Immediately below that is an area where downlinked (i.e.
incoming) messages are displayed.
13. In the example this area is empty. Next is a
horizontal bar with twelve menu headers where the item
"Vertical Clr" has been activated to display five related
categories. Each of those options will open a subsequent
menu, from which the desired CPDLC message element
eventually can be selected.
14. Here the "Expect" category was activated,

opening a menu with thirteen available message elements.
Each element is preceded by a number which corresponds
to the accepted FANS-l/A message set and also to the
CPDLC message set in ICAO Doc 4444 (Appendix 5).
Those numbers are used by the flight deck automation to
generate logical default responses for the pilots to downlink, if acceptable.
15. In the example the controller selected message
number 6 "EXPECT (alt)". as can be seen on the left side
below the horizontal menu bar. In fhe field following the
selected message* the controller inputs the desired flight
keyboard. The
level
using an
of the "message under consuuction" is. displayed in the
Message Editing Area, below the input field. The phrase
"DUE TO lXAFFE"2'in the example was also added by
using the input field.
w5O)
16. Once the message is completed, it will be

displayed in its final form in the Message Review Area at
the bottom of the window. By finally clicking the "Send"
button, the control[er activates the CPDLC transmission
and the message is sent to the aircraft. If the message is a
clearance or instruction, the OCS will conduct a conflict
probe prior to sending the message. If a conflict is detected,
the message is not sen[, which gives the conmller the
opportunity to change the clearance or instruction.
Other features
17. The OCS has an audio signal to alert controllers to
incoming CPDLC emergency messages. There is also a
visual alert, i.e. a different colour for the emergency
messages in the queue.
facilities notification window
Figum 4-A 1-2.
F i r-
l'criociic contract tcruplatc
Figure 4-A1-4.
CI'DI,C message processing \vintlow
OPERATIONAL DEmLOPMENT OF INTEGRAa7ED
SURVEILLANCE AND AIIWGROUND DATA
COMMUNICATIONS (ODIAC)
1. INTRODUCTION
1.1 The HMI features described in this section were
designed by Eurocontrol's ODIAC (the Operational Development of Integrated Surveillance and Airlground Data
Communications) Subgroup to support the airlground data
link functionality as described by ODIAC. In the ODIAC
philosophy. data link communications will not substitute
for voice communications but rather supplement and
support them.
1.2 The ODIAC HMI is incorporated in this manual
as an example of what is technically possible and to
demonstrate the need for careful integration of Human
Factors knowledge. This example should be considered
neither to be exhaustive, nor to present the ideal solution for
the problems associated with HMI design.
2. INDICATION OF CDPLC CAPABILITY

2.1 The indication on the radar display or ADS
display of an airlground data link aircraft is very simple.
Only aircraft which have logged on to perform CPDLC are
indicated. The indication is a framing around the call sign
in the display label. The colour of the framing indicates the
status of the CPDLC.
2.2 In Figure 4-A2-1 the label on the left represents

an aircraft without CPDLC capability. The label colour is
black (the standard label colour). The central label is for an
aircraft with CPDLC capability that has not logged on to
the Air Trafic
Services Unit. This label is coloured blue,
including the framing around the calt sign. The label on the
right represents an aircraft with CPDLC capability that has
successfully logged on to the ATS Unit, which is
distinguished from the central label by the black colour of
the framing.
Note.- ODIAC elected to not use the aircraft position
qmbol to distinguish between aircraft capabilities. In all
presented examples the position symbol is a dot. Other

systems, however; could consider indicating CPDLC
capability by using dzrerent symbols for apprapriate
aircrajt, e.g. V , A, 0, 8,etc.
3. THE SELECTED LABEL

3.1 When a controller wants to access the label of a
particuiar flight (e.g. in order to transmit a clearance via
CPDLC to that flight), a mouse or trackball is used to
position a pointer (arrow) over the symbol or label of that
flight. This will trigger the label to change from the
standard content to a more comprehensive version (see
Figure 4-A2-2).
3.2 The standard label shows the call sign (BAW362),

the actual flight level (290, derived from Mode C in a radar
environment, or from the FMS in an ADS environment) and
the next control sector where this flight will go (AW). The
black framing of the call sign indicates that this aircraft is
in CPDLC contact with the ATS Unit. The selected label
shows the call sign in a differing colour (green) and has
additiornal fields to denote the cleared and requested flight
levels (290), the airspeed (420). the routing (RP2) and the
type of aircraft (B737). The information in the bottom line
of the selected label is discussed in Chapter 3 "Data link
infrastructure and applications".
4. COMMUNICATING A CLEARANCE
VIA CPDLC
4.1 The following example describes the sequence of
events involved in issuing a flight level clearance via data
link. Similar sequences will apply when issuing
directheading, speed and vertical rate of change clearances.
In Figure 4-A2-3, flight BAW362 is being cleared to climb
from flight level 260 to flight level 290.
4-AZ-2
4.2 The sequence initiated by the controller is the

following:
4.7 The absence of a reply from the pilot will uigger

the display of a warning in the standard label (see Figure
4A2-7).
The controller inputs the new flight level 291) via the
cleared flight level (CFL)field in the selected label.
Note.- A button click with the pointer activates a
local menu that showsflight levels that are "l~ogically"
related to the actual flight level of the aircraft. By
scrolling, other flight levels are accessible as well,
when required.
The input value is framed in'black, a message is

displayed in the "Message OUT' window (see Figure
4-A2-4) and the clemnce is transmitted to the aircraft.
The pilot transmits a "Wilco" message.
4.8 A yellow "warning colour" frame highlights the

field to which the message refers. Take, for example, a
situation where a climb clearance is sent to the aircraft and
a pilot reply is expected but not received. After a time out
(which is a system parameter), the absence of the pilot
reply results in a yellow frame around the CFL field, and a
warning message "NO REPLY' is displayed in yellow
above the call sign.
Note.- When no reply is received by CPDLC from a
pilot, the contruller would normally try to establish contact
by voice communication in order to resolve the issue at
stake.
When the "Wilco" message is received:

The frame around the CFL. field disappears.
The message in the "Message O W ' window disappea*.
4.3 Figure 4-A2-4 shows a detail of the "'Message
OUT' window that can be positioned at another part of the
controller's traffic situation display (i.e. radar screen or
ADS screen) or on a separate display.
4.4 In case the pilot does not transmit a "W~lco"
message, but sends a "Standby" or an "Unable'message
instead, this will be presented to the controller as depicted
in Figures 4-A2-5 and 4-A2-6, respectively.
4.5 When a "Standby" message is received, the
framing around the field to which the messa,ge refers
changes colour to white. The white frame remains until
another message from the pilot is received, i.e. "Wilco" or
"Unable".
4.6 When an "Unable*' message is received, the

framing around the field to which the message refers
changes colour to yellow and the message "UNABLE" is
displayed in yellow above the call sign.
Note.- It would seem logical to expect that this
response will be followed by a funher exchange, probably
involving the "free text" option provided by CPDLC.
Alternatively, the controller could elect to switch to voice
communication in order to discuss other options with the
pilot.
5. NEGOTIATING A PILOT REQUEST

VIA CPDLC
5.1 The next example describes the sequence of
events involved in requesting a flight level change via data
link. Similar sequences will apply when requesting direct,
heading and speed clearances.
5.2 When the pilot request is received by the ground

system, the background of the call sign field changes to
white in the standard label and in the corresponding line of
the "Message IN window. The request is displayed in the
"Message I N window (Figure 4A2-8).
5.3 The possible answers (cleared FL 330, Standby or

Unable) are available in the "Message IN"window.
A click on the downlinked (i.e. from aircraft to ground)
requested flight level "330" displays the CFL menu,
with the cursor defaulted on that particular level; a
second click uplinks (i-e. from ground to aircraft) the
clearance to climb from flight level 290 to flight level
330.
A click on "Standby" uplinks that message to the pilot

and the display is changed to a white framing of the call
sign.
A click on "Unable" uplinks that message to the pilot
and the request is then cancelled. The message in the
''Message IN" window is removed and the white
background of the call sign is removed as well.
Chapter 4. The human-machine interjfuce ( H M I )
5.4 The controller can also respond to the request

through the CFL menu (as described in Section 4
"Communicating a clearance via CPDLC") in the selected
label. If a new CFL is entered, the white background of the
call sign is removed.
6. LOGICAL ACKNOWLEDGEMENT
6.1 The Logical Acknowledgement is a technical

message, normally not displayed to the controller, confirming that the message sent has been received by the
airborne systems and will be displayed to the pilot.
6.2 Only when a Logical Acknowledgement is not
received within a certain lime is a warning displayed to the
controller in the standard label (Figure 4-A2-9).
6.3 A yellow "warning colour" framc highlights the
field to which the message is referring. If, for example. a
clearance to climb from FL260 to FL290 is sent to the
aircraft. a Logical Acknowlcdgcrncnt is expectcd as with all
messages. After a lime out (which is a system parameter).
the absence of the Logical Acknowledgement triggers a
yellow frame around the CFL field, and a warning message

"DL ERROR" is displayed in yellow above the call sign.
Note.- After a data link error; the controller would

either have to re-send the message (assuming that the data
link connection still exists) or; possiblx alert the pilot by
voice communication that the data link connection has been
lost. In the latter case, the pilot could subsequently attempt
to log on again.
7. CONDITIONAL CLEARANCES
The ODIAC HMI has no provisions (yet) for the
transmission of conditional clearances. The main reason for
this is that the design was aimed specifically at the use of
CPDLC in areas with high-density traffic and radar
coverage. It was felt that in that environment there would
be very little use of conditional clearances (as compared to
a procedural environment, e.g. oceanic airspace, where
cond~tionalclearances are more commonly used).
Hrtnlor~Machitte Interface Catalogue for EATCHIP Pl~ase
Ill. Version 1 .O, Eurocontrol, Brussels, 1998.
H I U ~ I UFacrors
~I
grtidclines for air troffic n1utlci.cettletit / A T.MI .c.>..steti~.s
4-A2-4
CPDLC not active
Non CPDLC
Figure 4-A2-1.
Indication of CPDLC capability
Figure 4-A2-2. ODIAC label options
CPDLC active
Figure 4-A2-3,
Comnlunicating a flight level clearance via CPDLC
Figure 442-4.
Figure 1-:\2-5.
The "hlcssage OUT' window
f'rcscntatii)n of use of the "Standby" nlessage
Figure 4 4 2 - 6 . Presentation of use of the "Unable" message
Figure 4-A2-7. Presentation of the "Absence of reply" warning
Clruprcr 4.
Thc htcmun-machine ii~rctfuce( H M I )
Figure 4-A3-8.
Figure 3-A2-9.
4-A2-7
The "Message IN" window
Presentation of the "Absence of logical acknowtedgernent" warning
THE AUSTRALIAN ADVANCED AIR TRAFFIC SYSTEM

(TAAATS)
4. Figure 4 4 3 - 2 shows, from left to right, a label for

a radar track, an ADS track and a flight plan track Each
label can be displayed as a normal label or as an extended
label (which contains more information) at the discretion of
the controller. In Figure 4-A3-2 the radar track label is a
normal label, while the other two are extended labels.
1. The Australian Advanced Air Traffic System

(TAAATS) is a fully integrated airspace management and air
WIG control system that has been incrementally becoming
operational since 1998. It combines computer, radar and
communications technologies in a system that makes all
flight information available to controllers in two Flight Information Regions and two Flight Data Regions, comprising
two en-route control centres, four terminal control units and
29 aerodrorne control towers. The area covered by TAAATS
represcnts 1 1 per cent of the earth's surface.
2. A TAAATS workstation (Figure 4-A3-1) consists
of an air situation display (2 000 x 2 000 pixels, central in
the picture), an auxiliary flight data display (on the right in
the picture), a weather radar display (top left in the picture)
and a voice communications control panel (bottom left in
the picture). The weather radar display also is connected to
a networked PC, which provides access to static graphics
(e.g. airport diagrams, approach and departure procedure
diagrams) and to hypertext linked documents such as
controller manuals and checklists. Input devices are a
keyboard, one mouse for both the air situation display and
the auxiliary flight data display, and a second mouse for the
weather radar display. The communications control panel
inputs are made by a touch-screen. In Figure 4-A3-1, the
object to the left of the keyboard is a unique hand-operated
push-to-talk switch that was designed specifically for
TAAATS. It is colloquially called a "ferret". Like the mice,
the ferret can be moved around the working surface to suit
left- and right-handed controllers. In addition to the ferret,
there is an R/Tfootswitch located on a footrest under the
console.
3. The air situation display shows aircraft symbols

much like a contemporary radar display does, but the
symbols represent either a radar-derived aircraft position,
an ADS-derived aircraft position or a "flight plan track"
(i.e. a position computed by T M T S , based on position
reports, estimates and flight plan &?a). For each of these
categories of position information a different symbol is
used to represent the aircraft concerned.
5. The contents of the normal radar track label are: the

call sign (AVNI I), the wake turbulence category (M medium), an indication (*) that there is relevant information to be found in the "other information" field, the
mode C-derived flight level (350), an attitude indicator (>),
the cleared level (350), the ground speed in tens of knots
(41, i.e. 410 knots) and a free text line: (RWY 16L, i.e.
assigned runway 16 left).
'
6. The contents of the extended ADS track label are:

an indication that coordination has been completed (C). the
call sign (QFA46), the CPDLC connection status (-1, the
wake turbulence category (H - heavy), an indication (*)
that there is relevant information to be found in the "other
information" field, the ADS-derived flight level (350), the
cleared level (350). the ground speed in tens of knots (45,
i.e. 450 knots), the destination (YSSY - Sydney) and the
aircraft type (3744 -Boeing 747-400). There also is a free
text line, which in Figure 4-A3-2 is empty.
7. ,The contents of the extended flight plan track label

are: the call sign (QFA104), the wake turbulence category
(H - heavy), an indication (*) that there is relevant
information to be found in the ''other information" field, the
pilot-reported flight level (390), the cleared level (390), the
ground speed in tens of knots (38, i.e. 380 Iknots), the
destination (YSSY - Sydney) and the aircraft type (B762
- Boeing 767-200). There also is a free text line, which in
Figure 4-A3-2 is empty.
8. All labels on the TAAATS air situation display are
interactive, which means they provide the controller with
access to pop-up menus for the most relevant air traffic
control actions. Figure 4-A3-3 shows an example of a popup menu for a cleared flight level entry in the system.
Human
4-A3-2
-
Fucrors guidelines for air traffic mamgemcnl (ATM) systems
The CPDLC interface
9. By clicking on the cleared flight level in the label

(350), the controller is presented with a menu in which the
current cleared flight level is indicated by inverted video.
The next four levels above and below the current level are
displayed in the menu, while other levels can be accessed
by clicking a "-"or a "+" symbol. The number of symbols
on the buttons indicates the desired range from the current
level.
10. The controller selects the desired level and clicks

on it. thus entering the new value in the label on the air
situation display. TAAATS automatically and simultaneously updates all other fields on other displays
(including electronic flight progress strips) that contain the
cleared flight level for this particular flight.
11. In case the change in flight level is transmitted by
CPDLC to an aircraft, TAAATS automatically updates the
related values on all displays as soon as the expected
acknowledgement "Wilco" is received from the aircraft.
This means the controller does not have to make the same
input twice for the system.
The ADS interface
12. The types of ADS contracts and default periodic

reporting rates are initialized automatically by the ground
system. The controller can manually modify the periodic
reporting rate for a period of time through the ADS contract
window depicted in Figure 4-A3-4. This window is one of
the display options of the air situation display or the
auxiliary flight data display. L i e all other windows it can
be moved to any position on either of the two screens at the
controller's discretion. The controller can elect to have the
window displayed permanently or just to bring it up when
needed.
13. The window shows the aircraft identification

(ACID) for the flight to which the A D S contract pertains
(VAL815 - United Airlines 815). Also presented are the
parameters that the conmller can select as required. The
"Escape" button allows the controller to not activate the
changes that were about to be made to the contract and to
return to the screen that was used before. The "One shot"
button is the TAAATS equivaient of an On Demand
contract.
14. As can be seen in Figure 4-A3-5, the ADS
contnct windows in TAAATS aIso feature pop-up menus
with context-specific values.
IS. To manage CPDLC messages, the controller has a

CPDLC Message Editor window, a Current Messages
window and an Error Messages window. (The Enor
Messages window is also used for system error messages
that are not related to CPDLC.) These windows can be
positioned on the air situation display or the auxiliary flight
data display at the controller's discretion.
16. When a downlink message is received, the

controller is alerted by a single audible "beep" and the
message is displayed in the Current Messages window.
Colour coding is applied in 'I%AAXS to distinguish
messages that have been responded to from messages that
still require action from the controlkr. The controller
generates a response through the Message Editor window.
Once sent, the message is displayed in the Current
Messages window. When a reply is received from fhe flight
deck, the message changes colour again to indicate the
change in status to the controller.
17. The CPDLC Message Editor window is organized
in a hierarchical menu structure (see Chapter 4 'The
human-machine interface"). The cont-dler is presented
with several message categories (e.g. Climb, Descend,
Speed, SSR,Route, Free Text, etc.) that each give access to
a specific menu with related message elements. The
controller selects the desired message elements, which are
subsequently displayed in a dedicated section of the
window. After each element, the window provides a "clear"
button that aIiows the controller to remove and edit a
specific element without having to compose the whole
message again. The Message Editor features a "suspend"
button to allow the controller to attend to other tasks while
retaining the selected elements from the message under
construction. When the controller returns to the Message
Editor window, the composition of the message can be
resumed at the point where it was suspended.
18. After completing the message, the controller

clicks the "Send Message to: (call sign)" button, or
alternatively, clicks the "Escape" button to cancel the
message without sending it. By repeating the call sign of
the aircraft to which &he message will be sent on the "Send
Message" button, enhanced assurance is provided against
inadvertently sending a message to the wrong aircraft.
19. Emergency messages in T M S are colour

coded red in the Current Messages window and are
accompanied by a continuous audible "beep". Also, an
emergency indication is gensrated on the corresponding
uack label (see Figurc 4-A3-6) by adding a box around the
label. Tile box contains the mnemonic EMG for emergency.
Chapter 4.
(The octagonal shape around the aircraft position symbol

indicates that the controller has designated the track with
the mouse to apply a subsequent function - in this case
probably to cancel the aural alarm.)
21. Figure 4-A3-7 shows an example of a way-point

estimate entry by means of a pop-up menu. After the
controller enters the revised estimate, all estimates for
subsequent way-points are automatically updated by the
system.
Electronic flight progress strips
22. Colour coding of the border and call sign of a

strip indicates that, for the system, the flight is in a warning
status. The type of warning (e.g. "no response") is indicated
by a mnemonic in the corresponding track label, similar to
the emergency indication (see Figure 4-A3-6). except that
the colour is yellow rather than red.
Note.-
The electronic flight progress strips from
TAAATS were used as an example in the main text of d~is

chapter and are described there in detail.
20. In TAAATS the electronic flight progress'strips

are displayed in a window either on the air situation display
or on the auxiliary flight data display, at the controller's
discretion. Paper strips are not used in the system. Like the
labels on the air situation display, the electronic strips are
interactive. Selected areas on the strips provide the
controller with access to pop-up menus for the most
relevant air traffic control actions.
Other features
23. TAAATS features a highly user-friendly direct
manipulation interface for route revisions. This particular
interface is described in Section 4.7, Data Entry, in the
main text of this chapter.
Fiztjrc 4-:\3-l.
Figurc 3-A3-2.
TAAKTS workstation
Position symbol categories
1:igurt. 4-A3-3.
E s a ~ n p l cof' a pop-up n ~ e n u
ADS CONTRACT WINDOW
MOVE
Period :
CLOSE
15
368 372
ALT DEV
5
i?
SEL Period
SEL Period End 07:IO
One
Shot
LOWER
Enter
Escape
Pop-up menu in an ADS contract wintlo~r.
Figure 4-A3-5.
i r eA
Track label with enlergcncy int1ic;iliori
THE JAPAN OCEANIC CONTROL DATA PROCESSING

SYSTEM (ODP)
1. Tokyo Area Control Centre has been operating

version 2.5 of the Oceanic Control Data Processing System
(ODP) since 1997. The current version includes a data link
function, and it is expected that version 3 of the ODE
which will become operational in 2000, will feature
electronic Flight Progress Strips.
2. The Traffic Situation Display shows aircraft
symbols for two categories of data, i.e. ADS-derived tracks
and way-point projected time from Flight Data Processing
(procedural tracks). Position symbols in different colours
are used for each of these categories, and colour coding is
used also to distinguish RVSM-certified aircraft. In case no
more ADS data is received from an aircraft, the symbol on
the Traffic Situation Display changes to that for a FDPderived track. Position data for FDP-derived tracks are
obtained by High Frequency voice communications or by
CPDLC position reports.
3. Labels may be displayed in two ways, i.e. with

limited or full data presentation. Full data consist of the call
sign, FWP certification (e.g. "R10 indicates compliance
with RNP 10 requirements), RVSM certification ("R"
indicates the aircraft is RVSM certified), aircraft status',
assigned altitude, reported altitude, climbldescent indicator,
cruising speed, altitude block, altitude limitation and
destination. In a limited label, a selection of these items is
presented, including mandatory items such as call sign and
altitude.
4. The parallel diagonal lines on the Traffic Situation
Display (Figure 4-A4-1) are air routes. The colourcoded
rectangular shapes in front of the position symbols are
called separation boxes.
1.
Aircraft status comprises alerts for delayed position reports.

AIDC transfer information and receipt of CPDLC messages.
The ADS interface
5. In the Air Communication Status window (Figure

4-A4-2), the controller can see the status of data link
connections between the ODP and FANS-1lA-equipped
aircraft.
6. After an aircraft establishes an AFN log on, the
ODP automatically transmits a Periodic Report contract
and an Event Report contract to the aircraft. The controller
can modify a contract when necessary by changing items in
a dedicated window on the display. There are windows for
modifying Periodic contracts, Event contracts and Demand
contracts. Figure 4A4-3 shows the Event contract window,
with several items that can be modified.
7. Deviation and Vertical Rate can be set by using the
keyboard or by using the increasefdecrme buttons adjacent
to the boxes for the numerical values. By clicking the
SEND button at the bottom of the window the controller
activates the contract with the (avionics of the) aircraft. The
CANCEL CNT button is used to cancel an existing
contract.
8. Figure 4A4-4 shows a Periodic Report window in

which received ADS reports are presented as analytical
data. At the top of the window. the call sign (AhIA901) and
the internal FDP registration number (0012) of the flight to
which the contract relates are displayed.
The CPDLC interface

9. On the Traffic Situation Display is s message
monitoring field. In Figure 4A4-5 a request for altitude
change is shown in the downlink message display area (top
left side of the window). Since this is a request message,
the ODP recognizes that the avionics remain in an "open"
status (i.e. a reply is required to close the communication
loop). This is indicated to the controller by displaying a
"r'at the beginning of the line with the messasc (not
visible in Figure 4-A4-5).
4-A4-2
12. Colour coding is used to indicate the technical

status of transmitted messages (e.g. message assurance
received yedno).
10. By clicking with the right mouse button on the

message, a menu appears with related reply categories. The
controller selects the required elements and thus composes a
reply message. Sending this message will close the "open"
status of the avionics. At the same time, the "Y' at the
beginning of the message line changes into an "A" in case of
an altitude request message and into a 'T' for other request
messages. When the controller initially replies by sending a
STANDBY message, the "Y" changes into an "S".
11. During the composition of a reply message to a

climb request, the ODP rejects values that represent a lower
altitude than the present altitude of the aircraft. By default
it will display possible values up to +5 000 ft of the present
altitude of the aircraft, since it is not expected that the
controller will receive a request for an altitude change of
more than 5 000 ft.
Other features
13. The ODP has both a visual and an audio alert to

indicate incoming CPDLC emergency messages to the
controller. Furthermore, the ODP features a conflict alert
that will warn the controller whenever the separation
between two aircraft is foreseen to become less than the
required minimum.
14. Figure 4-A4-6 shows workstations from version 3

of the ODP, which wiii become operational in 2000. One
sector consists of three working positions.
Figure 444-1.
F u r4 - 4 2
Traffic Situation Display
Air <:ommunications stalus wirldo\r
Figure 4-A4-3. Event contract window
Figure 4-A4-4. Periodic Report \vindow
i r e4 - 4 5
Recluest f i ~ r:~ltitr~de
ch:t11gc
Attachment to Chapter 4
AN EXAMPLE OF A CHECKLIST WITH HUMAN FACTORS
CONSIDERATIONS FOR THE ATC HUMAN-MACHINE:
INTERFACE
The following checklist is excerpted from the final report

on Human Factors in the Design and Evaluation of Air
Traffic Control Systems, by Kim M . Cardosi and Elizabeth
D. Murphy (1995). of the U.S. Department of
Transponation Research and
Special Programs
Administration, John A. Volpe National Transportation
Systems Center, for the Federal Aviation Administration
(FAA).
"Note.- Checklist items marked by shading indicate

items that must be assessed with equipment and/or by
referring to the specifcarions docwnentation.
"I.
VISUAL DISPLAYS
A. General
1.
Information does not disappear from the screen

without being intentionally deleted or suppressed by
the controller.
2.
The computer responds quickly so that the controller is

not kept waiting for information (i.e., in less than one
second for simple, frequently performed tasks,within
four seconds for more complex processing; and within
12 seconds for infrequent, highly complex processing).
3.
Essential A X information is never blocked or

obstructed by other information.
4.
All information that a controller needs to accomplish a

task that is essential and timecritical is located on a
single page or in a single window.
5.
Wsual displays provide necessary information in a

usable form when it is needed.
6.
Display clutter is not a problem.
7.
The meaning of each icon is immediately apparent to

the controller or it is labelled.
8.
Symbols chosen for the display are intuitive so that the

controller can interpret them quickly and accurately.
9.
Controllers can change the amount of task-related

detail that is presented.
10. When the meaning of the colour is critical, colour is

used redundantly with another type of visual cue. such
as shape, text, or size. For example, all yellow objects
have a triangular shape.
I
11. The controller is able to recognise and differentiate
between colour codes under all anticipated lighting

conditions.
12. The controller will not need to identify more than five
colours (to interpret the meaning of the colour when it

stands alone).
13. Colour displays are readable and adequately bright
under all anticipated lighting conditions.
14. When the controller must distinguish between the
colour of characters and symbols, small blue

characters and symbols are not used.
15. Saturated (i.e., vivid) colours are used only for critical
or temporary information.
16. Saturated (i.e., vivid) colours are not used for small
objects or areas.
17. Saturated (i.e., vivid) red and blue are never presented
next to each other.
18. Colours are far enough apart in perceptual terms that
they are not confusable even when "washed out*' by

sunlight, if applicable.
19. Characters and symbols can be read easily under all
anticipated lighting conditions (e.g., from dim light to
direct sunlight, if applicable).
4-Aft-2
H u m n Factors guidelirtesfor air traffic management (ATM) systems
20. Computer displays and controls are clearly visible and

easy to use under all anticipated lighting conditions
(e.g., from dim light to direct sunlight, if applicable).
21. To acquire needed information, the controller only
needs-to look at a single, localised display22. The position and form of displayed objects appear the
same to the controller seated directly in front of the
object and to team members, when they view the
display from other anticipated viewing angles.
23. If windows are used, the controller can scroll the
underlying data set.
38. If size coding is used, it is limited to two widely

different sizes.
39. Graphic displays are used only to present information
that is naturally pictorial and to present dynamic data.
40. Placement of standard data fields is consistent from
one display to another.
41. Formats used within data fields are consistent from one
display to another.
42. Labels, terms, and abbreviations are used consistently
across the display set.
24. If windows are used, the controller can move windows.

25. If windows are used, the controller can resize 'windows.
26. If windows are used, the controller can iconify display
pages.
27. If windows are used, the controller can open and close
windows.
28. The active window is highlighted to distinguish it from

inactive windows.
29. The relationship between different windows is clear to
the user.
30. All information that a controller needs to accomplish a
given task is located in a single window o r within a
small number of related windows.
31. Abnormal data are emphasised effectively so that it
attracts the controller's attention.
32. Updated data are emphasised effectively so that it
attracts the controller's attention.
33. Acronyms in the new display system have the same
meanings as in the previous system.
34. Terms in the new display system have the same

35. Symbols in the new display system have the same
36. Symbol size can be adjusted by the controller.
37. Visual displays and their labels are sufficiently visible
under ail anticipated lighting conditions.
43. Only one abbreviation is used for each word or item

and abbreviations are used consistently on all visual
displays.
44. Punctuation is used conservatively and consistently.
45. Continuous text is presented in mixed upper-and-lower

case.
46. Computer printouts (in upper and lower case) are
available for lengthy text.
47. Visual displays maintain good image quality even at

the dimmest possible setting.
48. According to the display monitor manufacturer's

report, the display refreshes at a rate of 65 cycles (or
more) per second so that the display does not appear
to flicker.
49. According to the display monitor manufacturer's

report, a displayed object moves no more than .0002
times the viewing distance (in inches) in one second
so that no display jitter can be detected.
50. The heights and widths of characters appearing at the

centre and the four comers of the displays do not
vary by more than 10 percent .
51. '?&en the centre of the display is compared to an

edge, brightness uniformity does not vary by more
than 50 percent.
Chapter 4.

.$.'i.%;I&~,L.+
..
-.
+.z'&&
*?$-:;&
*,
14. Information that is blinking, has2an,on period that

52. The luminance of dynamic @tiWJ,phbh..eight
. times that of
u
c ~ k .g . r.....-,
~ ~ ~ ~ $ ., ~ ~ ~ ~ ~is ~at least
: + as
+ long
~ : & theffiof?
* ,
d. ....
., &od,.
,.
.;::
-...
. . . . . .
.......:.,.-.. ,.?<. : ... . :...:
-4.-, .. .
15. If blinking i ~
. . .'. .~. . .~. . & .<. b ~. . ., . ~
& k3 & r i : ~
53. All colours -are 8 . times .brighk'f?$han7-'the
static
. . .~. . i $ aod
. .. .:-,,.- . "",:C-.
. . .
.:A.
' - :.. - .;-. --!:.<,.;:*<~:..~-U.+~:,~, -;. . . .
:Hz.
background symbology. . ; .':+:{,?.>>%
$..
. .
.,.
.c
..
.. -' ~,!&2:L~:.;&.>;~G:
2 ;g.,;.--L;\.j:,.
:.
- ,,- .
:
: . . . ." . .,;y-.$%
"...,.'&....,........-V L . : ~ . .
%q . . . A . . s . ,
::.
I'
I..
A,
-L
.+.
-+I-.,:d
;-
0 _ _ .
"IL AUDITORY ALERTS

A.
General
B.
Visual alerts
1.
Auditory alerts are used only when necessary.
1.
Information that the controller must read and

understand quickly, such as alarms or critical e m r
messages, never blinks or flashes rapidly (greater than
3 Hz).
2.
The number of auditory alerts is sufficient, that is,

auditory alerts are included wherever they are needed.
3.
The meanings of auditory alerts are readily apparent.
4.
All proposed auditory alerts have been tested and
2.
High-priority alerts and other critical information are

located within the central display area (i.e., the central
15 degrees of the area where the controller normally
looks, given the normal viewing position).
3.
Highlighting and blinking are used sparingly.
4.
The colour red is used only for warningldanger.
5.
Yellow is used to indicate caution.
evaluated in a realistic environment by a representative

set of conuolIers.
5.
The auditory alert does not nag, or otherwise annoy,

the controiler.
6.
Auditory signals (and speech messages) are not

masked by other auditory alerts or background noise.
7. For any situation, it is impossible for more than a few

auditory alerts 'to be presented simultaneously.
6. Green is used to indicate for normaVready status.

7.
The same colour coding strategy is applied to every

display used by the same controler.
8.
No more than two levels of blinking are used.
9.
If blinking is used, it is cancellable by the controller.
10. For a timecritical warning system (such as a conflict

detection or resolution advisory), the controller
response time has been measured and is within
acceptable limits.
11. This design effectively directs the controller's attention
by means of alerting. coding. and emphasis techniques
12. If size coding is used it is limited to two widely
different sizes.
13. Alerts have a low incidence of false alarms.
8.
The number of auditory signals (e.g., warnings, alerts)

that the controller may need to identify is fewer than
five.
9.
Auditory alerts are easily discernible fmnn other

signals or noise.
10. Auditory alerts do not provide more information than

is necessary.
11. The same auditory signal always indicates th~esame
information.
12. Auditory alerts are

throughout the system.
consistently
implemented
13. The information contained in an auditory alert is also

displayed visually.
14. Auditory alerts are only used when immediate action is
required.
Human Factors guidelinesfor air traffic rmnagement (ATM) systems
4-A tt-4
,;rr.'i:7'.
15. Auditory alerts are cancellable by the controller.

..
16. A. &M&ed
.
..IS.
:.
..'second.
2r.;:.:.., : > " .....
.
: .-*
. ;l.-.;,. . .
.: *..
.
"
.- .
..
,,
,,,
,$gnalAe&ts from one to eight b e e b i g
.Ui..l
'-
........ .-.,.-. .
;
.
A
..-,
--.
.. -
a;,d...
. ;.;::-..
. .->,>A,--.,
,-;.s;*
4
.,:
>
.%rf?t..r+.-*sr -r;,. .,,:'.'
- m i * ,J.:.:
r+;:;2@Z*&,it
. -- . . --..' .- .-. .
:. . .
.
.
. ..-,<..:>:&,;<
:., . . .
*.- ..,ru6is.
,;-...
2-
17. A war&bgsound varies from one to three times

per
'
second. .
'
. '.
: .;-,
i 7 ; & $ f ~ ~ t ~ ~ a g ' eproduced

S .....
....;;;..I*;; -. ...' .i.,.;.-*.
:-A.+
"ID[
:l
Db
i..>.
.
:*.. .: ........ :
-
'. :-1.
...
;' 5 ,
,
;
;
.;
. ..,. . .. .... g..

,.
,, :;
-.
.........
:7.,
<; '
DATA ENTRY PROCEDURES
A. General
18. .The frequency of all auditory signals is between 500

and 3 000 so that they are
withinthe band of
'. frequencies that hum& are most sensitive to:- ,
.L. : ,
19.- fn general, auditory alerts sound for at, least -a

0.5 second duration.
20- The Pause between reptitions of an auditory signal

is less than or equal to three seconds.
21. Auditory alerts are at least 10 dB above ambient

noise or have been demonstrated to be sui5ciently
intense for a specific working environment.
1. The number of keystrokes (or other control actions)

necessary to input data is kept to a minimum and the
amount and complexity of data entry is about the same
as was required in the previous system.
2. With this system, data-entry errors can be caught and
corrected before they propagate through the system.
3.
The design assists the controller in detecting and

correcting errors in data entry.
4.
This system makes it easy to m v e r from dataentry

errors.
5.
Keystrokes or other dataentry actions are echoed

immediately on the screen, that is, there is no delay in
providing a legible representation of what has been
entered.
B. Speech messages
6. The data entry method helps to minimise errors and
1.
2.
3.
4.
5.
6.
A detection signal display (for example the sound of

static on the line) precedes a voice warning, unless a
distinctive synthesised voice is used.
Speech messages are short enough to be easily

remembered.
Brief speech messages are available to the controller
when there is the need to explain the specific nature of
a l m and warning signals.
Speech displays are distinct from and not easily
confused with other voices in the control room.
provides for quick, simple data editing and correction.
7. This user interface system queries the controller at

critical choice points, e-g.. "Are you sure you want to
delete this flight plan?".
8. A particular data item, such as assigned altitude, must
be entered only once; the computer can ~ t a i nthis
value and enter it in other fields, as appropriate.
9. The controller receives appropriate feedback on data
acceptance or rejection.
10. The computer does not erase all or part of any
erroneous data entry.
The controller does not need to remember more than

one or two speech messages at a time in
accomplish anj cf his or her ATC tasks.
11. The controller controls the pace of data entry, that is,
the computer d m not impose time limits or time outs.
Speech messages are not masked by other auditory

alerts or background noise.
12. The computer does not restrict the order in which data
items are entered.
--
Chapter 4.
The h u m - m a c h i n e interface (.HMI)
13. The computer prompts the controller for data that have
4-Aft-5
9.
been deferred for entry.
Commands are consistent in their placement across

multiple screens, ]panels,or windows; in their wording;
and in their method of activation.
14. Data processing is initiated only after an explicit

command from the controller.
10. The computer indicates the current operational mode.
15. Boundaries indicate where to enter the data and show

maximum field length.
11. Entry of long sequences of command parameters is not

required
16. A cursor appears to indicate data-entry mode and

location.
12. Uppr- and lower-case letters are accepted as

equivalent when the controller is entering a command
or command parameter.
17. The controller can edit all or part of a data field.

18. The controller is not required to enter leading zeroes
for numeric entries.
19. When delimiters, such as punctuation, are required to
partition long entries, the computer provides the
required format and prompts for the order of data
entry.
20. Field labels use accepted ATC terminology and are
used consistently.
B. Commands and Command Execution

1.
2.
3.
4.
Command execution requires minimal controller

action.
The consequences of destructive commands (e.g.,
"Delete") are explained.
Destructive commands (e.g., "Delete") require
controller confirmation of intention before they are
executed.
Command execution always occurs by explicit
controller action, never as a by-product of another
action.
13. Feedback is always given to indicate that the computer

has initiated a command.
14. Commands should[ be stated in the affirmative; that is,
they should tell the controller what to do, rather than
what not to do.
C. Menus
1.
Menu options are phrased to reflect the action

executed and worcled in user vocabulary.
2.
Options that perform opposing actions are not placed

adjacent to each other.
3.
The number of menu options is between three and ten

(five to six options is optimal).
4.
If an option, or set of options, is never available to the

user, the option@)is not in the menu.
5.
If an option is tem,porarily unavailable, it is displayed

in the menu, but dimmed.
6. Menu options are organised in logical or functional

groupings with clear titles.
5.
The controller can suspend/intermpt or canceVundo a

transaction in progress.
7.
If not in logical groups, order is by frequency of usage,

with most frequently used options at the top.
6.
Command ordering is consistent from screen to

screenlwindow to window.
8.
If not in logical groups or by frequency, options are in
7. Command labels use accepted ATC terminology and
9.
are used consistently.

8.
The relevant command set is displayed to show the

controller which commands are currently available.
alphabetid or numerical order.

Less frequently executed options and destructive
commands are at tt~ebottom of the menu.
10. If similar options are in different menus, the options

are ordered in a consistent manner.
Human Factors guidelinesfor air trafic manugement (ATM) system
4-Att-6
11. Each word in the menu is presented in upper and lower

case with the fist letter capitalised.
Feedback regarding processing delays specifies the

process, the length of the delay?and completion of the
process.
9.
12. Cascading submenus appear to the right of the parent

menu (below, if space to the right is limited).
"1%
13. When a menu is displayed, the location cursor is in the

first available option.
DATA ENTRY AND CONTROL DEVICES
A. General
14. When a popup menu appears, it appears near the
element with which it is associated.
1.
Input devices work in ways that are compatible and

consistent with the controller's tasks.
15. A window containing a pop-up menu provides an

indication that the menu is available.
2.
The overall design of input devices does not require

frequent switching between devices.
16. If they are presented in a vertical list, menu options are

left justified.
3.
The input device(s) idare appropriate for performing

the necessary functions (e.g., alphanumeric data entry;
selection of displayed objects; cursor positioning).
4.
Input devices have been compared not only for speed

and accuracy, but also for factors such as induced
fatigue, resolution capability, and space requirements.
5.
Controls and their labels are sufficiently visible under

dim lighting conditions.
17. Menu organisation supports specific controller tasks.
18. Graphical or textual aids are provided to assist

controllers in navigating through menu structures.
The
is required traverse
levels in a menu structure.
than four
20. When a trade-off is required between menu breadth

(i.e., number of options at a level) and menu depth
(i-e., number of levels), the design increases breadth
rather than depth.
. . -.-..
...
Input devica meet operational 'requirements for
accuracy, , force, feedback, precision,. : and
T
6.
,
9-;.
manipulation.
Error Messages and User Guidance
B. Keyboards
Error messages are provided whenever needed.
1.
Alphanumeric keys are arranged consistently on all

keyboards that the controller will use. (The preferred
mangement is the QWERTY layout)
2.
Keyboards are readable under all operating conditions

and backlit, if necessary.
3.
If a numeric keypad is provided, it is visually separated

from the main keyboard and arranged in a 3 X 3 + 1
matrix.
4.
Function keys are provided for frequently used

commands.
Each enor message briefly summarises the specific

problem and proposes a specific solution.
Error messages are direct and precise.
Error messages are presented immediately after an
error's occurrence.
Error messages are not redundant
Guidance messages are presented in mixed upper and
lower case.
5. Function keys are clearly labelled to indicate their

Messages about limits not met or exceeded specify the
appropriate range for data entry.
Questionable data entries elicit cautionary messages.
function.
6. The functions iiivoked by the function keys are

consistent throughout the system.
Chaprer 4.
7. Keys on keyboards and keypads have no more than

two functions.
8.
Non-active keys are left blank (i-e.. not labelled).
9.
The key used to initiate a command is clearly labelled

"Enter".
5.
D. Trackballs
1.
The trackball can move the cursor in any direction

without causing cursor movement in the opposite
direction.
2.
The trackball allows the controller to move the cursor

quickly across relatively large distances and also to
precisely position the cursor within a small area.
3.
The trackball meets standards for physical dimensions,

resistance, and clearance.
10. Keyed data are displayed quickly (echoed) on the

screen.
1 1. Tactile and auditory feedback are provided in response
to keystrokes.
12. The main keyboard is located directly in front of and
below the associated visual display, at a comfortable
distance from the seated controller's position.
13. Forearm and wrist supports are provided.
14. Alphanumeric keys meet standards for dimensions,

displacement, and separation.
Touchscreen displays meet standards for required

finger pkessure (displacement), separation of touch
areas, and resistance.
E. Control Grip Devices

1.
Any input device meant to be held and operated by a

standing controller can be held comfortably for a
period of three to four hours.
F.
Mice
1.
If a mouse is part of the design, it can be used

compatibly with all of the tasks the controller is
supposed to perform.
2.
Controllers can easily and smoothly position the cursor

with the mouse.
3.
Movement of the cnouse produces cursor movement in

the same direction on the display. For example, if the
mouse is moved to the left, the cursor moves to the left
on the display.
4.
The mouse is equally usable with the left or right hand.
15. Keyboard design includes guards to reduce inadvertent

key activation.
16. If alternative keyboards are featured, they have been
tested for usability and operational suitability.
17. The slope of the keyboard is adjustable between 15
and 25 degrees fmm the horizontal.
18. Keyboard height is adjustable between 23 and 32

inches.
C. Touchscreens
I.
If a touchscreen is used, it is suitable for the task@) to

be performed by the controller.
2.
Controllers can achieve sufficient touch accuracy with

the touchscreen.
3.
Touchscreen displays can be read easily under all

anticipated lighting conditions.
5.
The mouse has nu sharp edges and meets standards

for width (1.5 to 3 in.), length (3 to 5 in.), and
thickness (1 to 2 in.).
G. Graphics Tablets
4.
The touch input strategy (e.g., land-on; first contact;

lift-off) is compatible with the controller's task
objectives.
1.
Movement of the stylus in any direction on the tablet

surface produces smooth movement of the cursor in
the same direction.
4-Att-8
2.
3.
Human Facforsguidelines for air traf/ic mamanagement (ATM) systems
When the stylus is placed at any point on the tablet, the

cursor appears at the associated co-ordinates on the
display screen and maintains that position until the
stylus is moved.
If the stylus and tablet are to be used for free-hand
drawing, the device generates a continuous line as the
stylus is moved.
4.
The active and inactive states of virtual pushbuttons

are visually distinct.
5.
The on-off status of software-generated togglebuttons

is made clear through the use of labels and graphic
indicators.
6. h-Mechanicalpushbutton resistance is in the range

-
. , recommended
4. If a graphics tablet is used, frequent switching to the

keyboard is not necessary.
5.
The graphics tablet can be located on the workstation

within a comfortable distance from the controller.
H. Pushbuttons (Actual and Virtual)

1.
2.
3.
Mechanical pushbuttons are sized and spaced to

support activation but to prevent accidental activation.
single-finger
operations
I.
Foot Switches and Pedals
1.
Positive feedback is provided to ifidicate activatior? of

the foot switch.
2.
The controller is not required to operate more than one

switch or pedal with the same foot.
3.
Foot switches are positioned for operation by the toe or

ball of the foot.
4.
Foot switches/pedals meet requirements

dimensions, resistance, and displacement"
The surfaces of "hard" pushbuttons are rough or

concave.
Labelling of virtual pushbuttons is consistent.
for
( 1 0 4 oz.).
for
.-
Chapter 5
RESEARCH
5.1
INTRODUCTION
The empirical lessons from the early implementation of

CNSfATM systems (mainly in the Pacific region) have been
supplemented by several scientific studies on the effects of
using CPDLC. These studies are either research-oriented or
conducted in response to analysis of reports received
through confidential safety reporting systems in the
aviation industry. This chapter focuses on research on the
communication speed, the par9 line effect and the potential
vulnerabiliry to human error of CPDLC. The recommendations from these studies complement the guidelines
contained in Chapter 4 'The human-machine interface"
and Chapter 7 "Standard operating procedures" of this
Manual.
5.2 COMMUNICATION SPEED
5.2.1 High Frequency voice communication has

served the aviation community for over five decades. As a
consequence of its inherent propagation characteristics,
however, it often takes considerable effort from flight crews
or ground-based radio operators to successfully exchange
messages. More to the point, establishing and sustaining
two-way contact often proves difficult and requires a significant amount of time. The actual exchange of words
normally takes place in a relatively short time.
5.2.2 CPDLC is expected to bring improvements in
this area, especially when the ATN is available. VHF
digital link (VDL modes 2, 3 and 4, see Chapter 3 "Data
link infrastructure and applications") will enable more
reliable technical means to exchange messages between
ATC and flight crews. Yet it should be realized that with
CPDLC a written message is sent from controller to pilot or
vice versa, and this message requires composing by the
sender and reading by the receiver. So although the
transmission of CPDLC messages may be faster than
establishing contact by HF voice, the time needed to
compose, read and interpret the messages may actually be
longer.
5.2.3 If no contact is established using HF voice, it

will be apparent to the party trying to make contact that no
message (e.g. a report, a request, a clearance, etc.) can be
exchanged. Time spent on making contact is spent "offline", as no actual ctommunication is taking place. With
CPDLC, however, the party initiating the transmission
expects a reply from the other party almost immediately
after sending the message. If the other party requires some
time to reply, or elects not to attend to the incoming
message immediately, the sender will experience the delay
as time lost "on-line". The time required to complete the
communication may therefore appear longer than when
using HF voice.
5.2.4 A number of scientific studies have looked at
the amount of time or the number of transmissions required
to complete a communication when using data link versus
voice communication. It was shown that total transaction
time (i.e. the entire time span when a controller would be
concerned with a given communication) was twice as long
for data link as for voice. This can be explained by various
factors such as the possibility of delayed responses to data
link messages or by more time being required to compose
data link messages. Also, the ability to delay attending and
responding to an incoming message, until competing task
demands allow for it, can create problems with respect to
the timeliness and relevance of information.
5.2.5 Such delays may be a consequence of normal

distractions, either on the flight deck or in the ATC facility.
Other studies have shown that distractions occuring on the
flight deck after the crew has accessed the message (i.e.
brought it up on the screen, but not yet completely read or
interpreted it), have a potentially large impact on message
acknowledgement times. Handling of other tasks after
accessing the data link message also seemed to be
procedurally problematic. Half of the messages with
distractions were not acknowledged by the flight crews, and
the remaining messages had acknowledgement times
almost three times longer than considered desirable.
5.2.6 Several airlines have meanwhile introduced the
flight deck procedure to first print the content of an
5-2
incoming FANS-I/A CPDLC message. The pilot not flying

(PNF) then reads it out aloud, and both pilots discuss and
interpret the message before composing and sending a reply
to ATC. This obviously affects the total transaction time for
the communication.
5.2.7 The shift to processing messages to Ithe visual
modality from the auditory channel may lead to increased
modality competition between accessing ATC information
content and the already visually laden flight deck
environment. This modality shift in the presentation of ATC
information appears to fundamentally change the role of the
PNF in the communication cycle. The PNF becomes the
primary distributor of the ATC message content in data link
compared to acknowledging and verifying infoma:ion
transfer in the present voice system. Results from one study
suggest that the amount of message content the PNF makes
available within the flight deck can affect both the
understanding and timing of the overall message.
5.2.8 In summary, the existing potential for delays in
the flow of communication suggests that current data link
implementations may not be well suited to handling the
majority of transmissions in the future ATM environment,
where most communication can be expected to be timecritical so as to support the planned tactical approach to
traffic management. Many researchers and practitioners
agree that even in the current ATC system, data link should
not be used to transmit time-critical, immediate action
messages.
5.2.9
Recommendations:
Air haftic controller training for the use of CPDLC

should include awareness of related flight deck procedures used by operators in their area of jurisdiction:
and
Standad operating procedure design and training for
controllers must incorporate the fact that voice communications are the preferred option for transmitting
time-aitical immediate action messages.
5 3 PARTY LINE EFFECT

5.3.1 The phrase "party line information" has its
origins in a commercial telephone service that has been
offered in several countries by high-tech entrepreneurs
since the late 1980s. This service, called the "party line".
makes it possible for a high number of individual callers to
engage in a group conversation on the same telephone line.
Every participant can hear what the others say, even if they
themselves are not actually taking part in the discussion.
5.3.2 The conventional radiotelephony
system
used in aviation possesses this same attribute. Pilots who
are not actively involved in an R/T conversation can overhear what is being said by other pilots and by ATC.
Consciously but also subconsciously this provides them
with information that they will use in subsequent stages of
their flight(s).
5.3.3 An example of consciousiy received party line
information via FVT could be a report by a preceding
aircraft of turbulence at a certain position or level. Overhearing this report r?llows a crew to anticipate the
turbulence and possibly even plan an alternative strategy to
avoid the area.
5.3.4 Subconsciously received R/T party line
information can simply be the notion that it is very busy on
the frequency. Yet this notion will likely cause pilots to be
more alert to what is said on the R/T in general, and for
calls to their flight in particular. At the same time it will
keep them from making extra requests to ATC, and when
they do communicate, they will keep their messages as
short as possible without having to be asked to do so.
5.3.5 When the research community began to study
the differences that could possibly occur as a result of the
introduction of CPDLC, they adopted the phrase "party line
information" to describe the effects mentioned above. The
studies that so far are available seem to indicate that the
loss of party line information, in an environment where W
communications are replaced by CPDLC, is something that
cannot be ignored. This leads to the following conclusions:
'The presentation of information currently available
from party line information must be a consideration during
implementation of data link communications. The importance of party line information was found to be significantly
higher in the busier and higher density phases of flight near
the airport, suggesting any initial implementation of data
link communications in Terminal Area control sectors will
need to be well compensated for party line information
loss.
"Specific Traffic and Weather party line information
elements were identified as critical. These results,
combined with the common citing of these two types of
information as necessary for 'The Big Picture' suggest
Traffic and Weather information is required for pilot global
Situational Awareness." (Variations in "Party Line"
infonnation importance between pilots of di~eerenr
cl~aracteristics.
)
Chapter 5. Research
-
5.3.6
5.4
Recommendation:
Design of CPDLC systems and associated procedures

must include provisions to compensate for the loss of
party line information as compared to conventional RIT
communications.
5.3.7 It could be argued that the traffic information
element eventually will be compensated for by the cockpit
display of traffic information (CDTI. see Chapter 8 "New
flight deck technology"), a tool that will be enabled by
ADS-Broadcast (ADS-B, see Chapter 3 "Data link infrastructure and applications"). Yet it should be realized that
the implementation of CPDLC will precede the possible
implementation of CDTI and ADS-B by a significant time
span. States that are about to introduce CPDLC into their
airspace may have to find other ways to compensate for the
loss of party line information.
5.3.8 Recommendation:
When introducing CPDLC. alternative procedures must
be developed for those cases where no technological
means of compensation are available for the loss of
party line information as compared to conventional R/T
communications.
5.3.9 These alternative procedures could take different
forms, depending on the situation to which they apply. A
State might decide to authorize CPDLC for use in the enroute phase of flights only; it might decide to authorize
CPDLC only as a back up for conventional WT communications (which would probably lead to increased workload
for controllers and pilots); or it might decide to authorize
CPDLC only for the transfer of information while the
transfer of instructions would still be via FUT communications. It is emphasized that these examples should not be
seen as limiting or restricting the options available to
States.
Note.- See also Chapter 7 "Standard opemting
procedures".
5.3.10 It should be realized that similar provisions

will need to be in place even once the use of VDL Mode 3
(transfer of digitized voice and data, see Chapter 3 "Data
link infrastructure and applications") has become an
integral part of the ATN. VDL Mode 3 communications are
point-to-point transmissions, which means that no stations
other than the sender and the receiver can hear any voice
communication in progress.
VULNERABILITY
5.4.1 This section uses two case studies to

demonstrate CPDLC:'s potential vulnerability to human
error. Both case studies are based on reports from the
Aviation Safety Reporting System (ASRS, USA). In both
cases the type of aircraft involved was a Boeing 747-400.
For the sake of readability, the abbreviated format of the
original narratives is replaced by the full words.
5.4.2 Case Study I: Flight crew misunderstanding of
a c o n d i t i o ~altitude
f
clearance.
5.4.2.1 The fol1,owing narrative is from the ASR:S
incident report filed by the flight crew:
"We were 3200 Ibls. behind our flight plan fuel forecast,
and because of aircraft reluctance to climb, I requested an
off course climb to FL350, a more efficient altitude for us.
The following clearance was received from ATC, 'cleared
direct 1510N ISOW, clirect 12N 156W, direct 05N 164W, at
150W dimb and mai~ntainFL350, report reaching FL350'.
We both somehow missed the 'at 150W' restriction arld
began a climb to 1x350 on the new heading. After
reporting level at FL350 we received a message from PiTC,
'your clearance was to climb at 150W, not before, verify
alt.' We were both su~rprisedby this message.".
5.4.2.2 The reporter goes on to describe what the crew
did, then speculates about what might have led them to
overlook a crucial part of the clearance:
"I feel several factors contributed to the error. [I:] Both
the FO and I had little actual experience using FANS since
our original training in late 1995, and this was our first time
seeing the ATC uplink clearance format. [2:] The new
clearance was quickljr accepted using the accept prompt,
this action changed the screen to the verify response page,
and diverted us from the print prompt which should have
been selected before sending the accept message. [3:] If just
the CDU screen is used to read the clearance, the critical
word "at" is in small font, and very easy to overlook with
dim screens and tired eyes. [4:] The correct operational
procedure is to "print imd read aloud" and had we followed
the procedure, the incident would not have occurrecl.
However, neady 1 year has elapsed since initial FANS
training. This long pelid of time without actual hands on
experience presents an opportunity for procedural errors."
5.4.2.3
factors:
The reporter identifies four contributing
1) crew unfamiliarity with the data link interface;
5-4
2) disappearance from view of the "print" prompt (and the

"at 150W' phrase) when the CDU page changes;
3) mixed font formats that make the short word "at" even
harder to notice; and
4) a long interval (roughly ten months) between training
and initial use that made trained procedures difficult to
remember.
5.4.2.4 One additional factor was not apparent to the

captain nor to anyone else until a few additional incidents
were reported. The flight crew had asked for (and were
eager to receive) a climb clearance. They were not expecting the conditional restriction "at 150W' that delayed
the clearance to FL350 and overlooked it when reading the
ATC uplink message on the CDU.
5.4.2.5 Although conditional clearances may also be
misunderstood or forgotten in voice communicaeions, the
readback requirement and opportunity for the controller or
radio operator to emphasize the conditional restriction
make it less likely that an error will occur.
5.4.2.6
P;TS CPDLC operator training should include

information on the opportunities for human error when
issuing conditional clearances by CPDLC.
5.4.2.7 Perhaps the most interesting conciusion from
this example is that the significance of the conditional
element in this data link clearance was not recognized until
a number of similar incidents had occurred. System
designers, message set developers, Human Factors analysts,
fleet training personnel and trained flight crews did not
detect or immediately recognize the vulnerability of conditional elements in data link clearance messages. This was
a lesson waiting to be learned from operational experience.
5L4.3 Case Study 2: Significance of "accept" and
"reject" as data link response Iabels.
5.4.3.1 The flight in this case study was cleared to
operate in a block altitude from FL290 to FL330. After
three hours the crew was asked to "say time able FL350".
Shortly after responding to this message, the aircraft
received a subsequent clearance by data link as described in
the narrative part of the ASRS report filed by the crew:
"At xxxxZ we received the following CPDLC message:
Recommendation:
'xxx ATC clears aircraft x descend to and maintain FL3 10
CPDLC procedures
clearances; and
0
0
should
DIRECT 12H 156W, DIRECT

05H164W
12342
avoid
conditional
0
0
report reaching. Descent necessary due to opposite

direction company traffic'. The ACARS provided 2
prompts ('accept" or "reject") for response to this message.
The way it is presented to the pilot makes it seem that you
do have an option. The lower altihtde was unfavorable and
because we were down on our fuel score I felt that I needed
to reject the clearance. A few minutes later we were
selcalled. They wanted to know why we didn't want to
descend. I told them because of fuel burn concerns. In the
meantime, we started to reevaluate the higher altitude."
ATC UPLINK
NlS*lO.O w 1 m . o
Figure 5-1. Recreation of the ATC Uplink

CDU pages described in Case Study 1
Figure 5-2. Re-creation of the ACARS display

described in Case Study 2
5.4.3.2 In an ASRS callback interview, the reporter

again told the analyst that: .."he believed the ACARS
machine (CPDLC) gave a clearance which could be
accepted or rejected because that is what the options were
on the selection menu of the aircraft's receiver".
5.4.3.3 The captain certainly has the authority to
reject any clearance that is felt to be unsafe, and concern
about fuel bum is a good reason to reject the descent
clearance. So it is interesting to note that the reporter
suggests - not once, but twice - that the labels on the
prompts for responses influenced the decision.
5.4.3.4 The example shows how standard message
formats. interface labels and transmission delays might
distort communication between the pilot and controller in
the data link message exchange. In this case, the crew
apparently felt that the controller had offered them a choice
of accepting or rejecting the descent clearance, and the
controller may have felt the crew was being uncooperative
- refusing to either climb or descend from their current
altitude.
5.4.3.5 Finally, the example illustrates some of the

unintended side effects of changing from voice to data link
for pilot-controller communication. One of these consequences is increased difficulty in conducting any dialogue
or negotiation that requires more than a simple questionreply exchange.
interface in data link communication was also

demonstrated: message presentation format and function
labels played a significant role in both ASRS incidents.
5.6 Standard pliraseology and voice communication
protocols are replaced in data link by standardized message
sets (often based on voice phraseolou) and new interface
conventions. As both examples show. data link messages
are not directly equivalent to voice clearances, and attempts
at direct translation cannot guarantee that safeguards
evolved over years of radio voice communication will
successfuIly transfer to data link Both examples
demonstrate h a t new problems are encountered with data
link communication and different safeguards must be
developed.
5.7 Finally, to quote research: "Although the focus of
the studies has been on exploring problems encountered
with use of FANS-I CPDLC, early survey results indicate
that pilots find it a great improvement over HF voice for
most oceanic communications with air traffic control. The
discussion has offered some preliminary lessons that can be
learned from operator experiences with the system.
However, i t is not t11e intent to suggest that CPDLC is
inferior to voice for pilot-controller communication." (An
assessment of flight crew experiences with FANS-I ATC
data link)
5.8 Recommendation:
Note.- Boeing has not adopted the describedformat in
the implementation of CPDLC for the 757~767series, and
a modification is being developed for the 747-400.
5.4.3.6
Recommendations:
Training for ATS CPDLC operators should include

awareness of the capabilities and limitations of the
CPDLC interfaces on the flight deck of relevant aircraft
types; and
Procedures including the use of voice communications
should be established as alternative to the use of
CPDLC for complex dialogues or negotiations.
Use of the available confidential reporting mechanisms

to describe operator experiences must be encouraged so
that the operatiolnal problems encountered can be
thoroughly analysed and the system improved.
Submission of such reports should not divert crews
from submitting reports to their organizations in support
of FANS Interoperability Team efforts to improve the
system as a whole.
References
Conclusion
Kerns, K., Human Factors in ATUFlighr Deck integration:

implications of data l i d simulation studies. MITRE Report
MP 94W0000098. MlTRE McLean, VA, 1994.
5.5 The two case studies demonstrate some of the

negative side effects of changing from voice to data link for
pilot-controller communication: conducting a dialogue
becomes more difficult; the absence of readback opportunities removes an important error-trapping mechanism;
the intent of the communication can be affected by the
mechanics of data link. The importance of the system
Mackintosh, Marganet-Anne, Sandra Lozito, Alison

McGann. Elizabeth Logsdon, Melisa Dunbar, Vicki
Dulchinos, "Information m s f e r in data link communications for ATC clearances", in Proceedings of the Tenth
lnrernational Symposium on Aviation Psychology, R.S.
Jensen. A. Weir (Eds.). Ohio State University, Columbus,
OH, 1999.
5-6
Human Factors guidelines for air trafic management (ATM) sysrem
Pritchett, Amy R., and R. John Hansman, "Variations in

'Party Line' information importance between pilots of
different characteristics," in Proceedings of the Eighth
International Symposium on Aviation Psychology, R.S.
Jensen, L.A. Rakovan (eds.). Ohio State University,
Columbus; OH, 1995.
Sarter, Nadine B., "Communication technologies and
procedures in support of future ATh4 operations," in
Proceedings of the Ninth International Symposium on
Aviation Psychology, RS. Jensen, L.A. Rakovan (eds.).

Ohio State University, Columbus, OH, 1997.
Smith, Nancy, John Moses. Stephan Romahn, Peter Polson,

John Brown, Melisa Dunbar, Everett Palmer, Sandra
Lozito, 'An assessment of flight crew experiences with
FANS-I ATC data fink", in Proceedings of the Tenth
International Symposium on Aviation Psychology, R.S.
Jensen, A. Weir (eds.). Ohio State University, Columbus,
OH, 1999.
Chapter 6
PREPARING FOR CHANGE

6.1
INTRODUCTION
The development, acquisition and implementation of

CNSIATM systems for ATS are complex processes with
many facets. States and organizations that make the
transition to new technology and new prmedures need to
prepare for this change several years ahead of the envisaged
transition day. In this preparation all aspects related to the
transition must be considered. This chapter addresses:
- writing of systcm specifications;

- development of a Human Factors plan;
- the operating philosophy;
- changing team roles;
- early prototyping;
- planning and timing of training;
- training content; and
- regulatory aspects.
6.2
WRITING SYSTEM SPECIFICATIONS
6.2.1 One common feature of recent successfully

completed programmes to introduce new ATC equipment is
that early in the process a multidisciplinary team was
formed to guide the procurement of the new equipment.
Such a project team comprises a mix of technical and
operational expertise from the groups that ultimately will
k using the new system. Engineers, air traffic controllers,
flight data personnel, flow controllers, software experts and
trainers are all represented on the team. The individual team
mmbers are selected because of their personal interest and
motivation to make the new system happen. For certain
stages of the process, the team may be expanded to include
dtty-occurrence investigators, simulator operators and/or
data analysts. The project team should include a human
prformance sptcialist.
6.2.2 The following excerpt from Human Factors in

the Design and Eval~lazionof ATC S y s t e m provides an
adequate insight into the need for a team approach:
"When a Human Factors evaluation of a system or

subsystem is warranted, it should be designed by team
that includes Human Factors specialists and operations
specialists. Since there is no licensing prnedure for Human
Factors specialists, they can only be judged by their
credentials and previous experience. A successful (i-e..
helpful) Human Factors specialist is likely to have an
advanced degree (in an area of experimental or engineering
psychology. Human Factors, or a related field) and
experience in a specific area (e.g., ATC). Operations
spccialists are intimarely familiar with the operational
environment (e.g., a specific cockpit or ATC facility). They
represent the potential users and are usually operators (e.g.,
pilots or controllers). As long as they are operationally
current (i.e., knowledgeable of current issues. procedures,
and practices), they are the most appropriate source for
information on user preferences and suggestions for
symbology, terminology, display layout, and other factors.
"Even the most experienced users should not be solely
responsible for the user.-machineinterface, however. In fact,
many years of experience can occasionally be a liability in
making such decisions, since the skills and knowledge that
develop with extensive experience can often compensate for
design flaws that may then remain unnoticed.
"For these and other reasons, it is important for
operations specialists to work with Human Factors
specialists in the planniing and conduct of a Human Factors
test. Human Factors specialists are intimately familiar with
the capabilities and limitations of the human system, testing
methods, and appropriate data analysis techniques. They
can point out potential problems that operational specialists
might overlook. Working together, the two types of
specialists can predict problems and head them off before
they occur in actual operations. Together, Human Factors
specialists and operations specialists are equipped to decide
exactly what needs to be tested and how it should be
tested."
Factors guidelines for
6.3 HUMAN FACTORS PLAN
6.3.1 The development of a formal Human Factors

plan ensures that Human Factors considerations are fully
incorporated into system design. This plan addresses the
human performance and staffing parameters for programme
and design alternatives. The plan is first developed at the
very start of the project and updated during each
subsequent acquisition phase. The initial Human Factors
plan outlines the issues, tasks and strategies associated with
human performance considerations in the operation, maintenance and support of system options. Subsequent update5
to the plan further define and refine the human parameters
of the programme and ensure the identification and
resolution of Human Factors problems and issues in the
programme. The Human Factors plan should be designed to
be a living document; it should be tailored to the specific
programme requirements, procurement strategy, key
decision points and acquisition phase as well as to customer considerations qf the programme. It imposes only the
necessary and reasonable requirements to achieve the objective effectiveness of human performance during system
operation. maintenance and support, and the efficient use of
personnel resources, skills, training and funds.
6.3.2 Table 6-1 contains the content and format for a
Human Factors plan.
air trafic management (ATM) systems
multiple screens, a third would be for the available and

applicable level or levels of automation, a fourth would be
for the (de)centralized control of the system configuration,
and so forth. It may be necessary to assign a certain level
of importance to each of the philosophies in order to be
able to determine which has priority over another and thus
avoid conflicts. For example, a philosophy that "users will
have all the available information displayed to them at all
times" would probably conflict with a philosophy "to only
have one display screen at the working positions".
6.4.4 It will be one of the most important tasks of the
procurement team to coherently formulate the operating
philosophies for the system. Admittedly this will take some
time at the very beginning of the process, but it will be time
well invested. During the subsequent lifetime of the process
it will be possible to refer to the agreed philosophies and
verify that every step about to be made, or that has just been
completed, is compatible with those philosophies - which
in fact is the main reason for having them.
6.4.5 By applying the principles of Human-centred
Automation (see Chapter 2 'Three essential concepts") to
the operating philosophies, the end-result should be a
system that supports the users in their operational tasks,
removes non-essential tasks, reduces workload, improves
performance and increases efficiency. Such a system
enhances the safety element of the users' tasks, in addition
to the job satisfaction of the users.
6.4 OPERATING PHILOSOPHY

6.4.1 Being part of the procurement process of new
equipment presents participants with the opportunity to
introduce basic requirements or aspects into the system.
But before going into detail about what certain system
elements should or should not look like, it is recommended
for the procurement team to formulate an operaring
philosophy that should govern the design of the entire
system.
6.4.2 An example of such a philosophy could be that
in the new system "users will have all the available
information displayed to them at all times". This
philosophy will no doubt result in a system design that is
different from one that is built on the philosophy that "users
will have access to all available information without having
to g o through more than three levels of menus at all times".
6.4.3 These are but simple examples. In reality there
may be a requirement to formulate several of such
philosophies to govern the design of the system. One
philosophy would bc for the access to information. a
second would be for the use of one display screen versus
6.5 CHANGING TEAM ROLES

6.5.1 Most forms of computer assistance in ATC are
to support the tasks of individual controllers although
traditionally many functions have been performed by teams
or by individuals working within teams. The purpose of
introducing computer assistance is to help each single
controller and to improve the efficiency and safety of N C .
Any associated changes in team roles are considered
incidental consequences instead of stated objectives.
6.5.2 Most of the changes in team functions are a
consequence either of the reduced observability of
controller actions and effectiveness or of the failure to
devise forms of computer assistance that can be applied
collaboratively by teams to ATC. Many of the traditional
roles of teams become more difficult for controllers to fulfil
as team members if the available forms of computer
assistance only help their individual tasks. Examples
include discerning the controlling style of colleagues, the
allocation of responsibilities among team members, and the
identification of training needs.
Chuprer 6.
Preparing for change
6-3
Table 6-1. Human Factors plan content and fonrnat

Content
Headings
Programme Summary
Brief description of the programme

Concept of operation and maintenance
Programme Schedule
Overview of system acquisition schedule
Target Audience
Identify the user and maintainer

Demographics
Biographical data
Previous training
Aptitudes
Task-related experience
Anthropometric data
Physical qualifications
Organizational relationships
Workspace requirements
(Appendix if data are lengthy)
Guidance
Summarize any guidance received
Constraints
State if additional staffing is required by the new system

State whether an existing job series will be used or a new one
created
Post limits on the amount of time that can be afforded for
training
Establish standards on the working conditions that will be
acceptable when the new system is fielded
Issue Description
Describe the issue or problem background, importance and

consequences or task to be done to support the acquisition
Objectives
Identify Human Factors Programme objectives

Provide performance measures and criteria in terms of time and
accuracy to perform tasks to evaluate resolution of issue
When human performance thresholds are known, identify tasks
for the developer to be done early enough in the acquisition
process to influence require~nentsand system engineering
Identify the actions to be taken to resolve each issue
Show the current status of each issue
Actions
Identify actions to be taken to resolve issues

Show current status of each action
Activity Description
Identify any tasks, studies or analyses that must be performed to

resolve the issues
Activity Schedule
By acquisition phase, describe the Human Factors tasks in terms

of who, what, when and hovv (resources)
Identify feeds to and depende:ncies on logistics support, training
and test and evaluation programs
Background
Issues and
Enhancements
Activities
Human Factors guidelitlesfor air traffic management (ATM) syslems
6-4
Headings
Strategy
I Goals and Requirements
I
I
I
I
I
I
I
I
1
Strategy should be derived from the major concerns. issues,

schedule. tasks, guidance, constraints, objectives and approach
for the Human Factors Programme
Answer the question, "What objectives does the organization
wish to achieve?"
Answer the question, "How will the organization accomplish
these objectives?"
I1
Identify relevant references needed for a full understanding of

the Human Factors plan (Use appendix if appropriate.)
Identify administrative handling procedures
Identify update schedule and procedure
Identify review and approval authority and procedures
References
Review, Approval
and Distribution
I
ReviewlApproval
/ Distribution
Define who will be responsible for the Human Factors

Programme
Set out the extent of contractor support required
Define how the Human Factors coordinator will support the
acquisition team
1 content
I
I
1
I
At a minimum, the Human Factors plan and each update should go

to system engineering representatives and personnel with oversight
responsibilities
6.5.3 Controllers may have less evidence available to

detect when a colleague is tired, incapacitated or inexperienced. and fewer possibilities to intervene even when such
judgements are still possible with some validity. Each
controller's picture of the traffic tends to be confirled more
within the individual region of responsibility. This is
because the reduced contact with other team members tends
to remove opportunities to supplement the pictuce with a
framework of broader information about the traffic in other
regions. As a result, the controller's Situational Awareness
(see Chapter 2 "Three essential concepts") is reduced,
although the aim of advanced systems usually is to enhance
Situational Awareness.
6.5.4 To avoid this situation the effects of the new

system on team functions should be taken into account
early in the design process. This is particularly relevant
when it is foreseen that, in the new system, two persons
will operate ATC functions that were the responsibility of
a single controller in the old system. An examplc of this
situation could be the introduction of ADS into an
environment where previously only procedural control was
available. If the ATS provider elects to have the ADS
workstations nlannrd by two controllers, it should be clear
from the outset what the individual responsibilities of cnch
controller are. as those responsibilities will have a direct
impact on the design of each working position.
6.5.5 One initiative that has been developed to help

the transition to new technology is that of team resource
management (TRM) training for ATC. W~thinEurope, this
initiative has fostered the development of various approaches from a teamwork perspective. Topics include
safety practices, teamwork, the roles within the team and
issues such as collective Situational Awareness, decision
making and stress management.
Note.- More information on TRM can be found in the
Eurocontrol Guidelines for Developing and Implementing
Team Resource Management.
6.6 EARLY PROTOTYPING

Experience from ATS providers who recently accomplished
a successful transition to an advanced ATM system
indicates that there can be significant benefits from
employing early prototypes of (components of) the new
system. An "early prototype" of a system or system
component is normally a first developmental version of the
manufacturer's interpretation of the design specifications.
By showing this first version to the end-users, i.e. the
controllers (or other operators) who will ultimately work
with the ncw system, and inviting them to interact with and
Chapter 6.
Preparing for change
comment on the prototype, valuable feedback can be

obtained. This feedback can be used to improve or modify
the design where necessary. At the same time the early
exposure to the new system will promote user acceptance,
in particular when comments from the user population are
seen to be taken seriously. To that end it should be.ensured
that feedback on the use of the received comments is
provided to the end-users throughout the process.
6.7
PLANNING AND TIMING OF TRAINING
6.7.1 One of the lessons learned from the introduction

of new and complex ATM technology is that generally not
enough time appears to have been reserved for a proper
training programme for the operators to learn how to use
the new equipment. For a variety of reasons most of the
systems were delivered only after a considerable delay in
time which meant the original planning for the
implementation could not be met. Since usually those
systems were overdue to replace the previously used
systems, there was considerable pressure on the ATC
providers to stan using the new systems almost
immediately after the manufacturers had finished the
technical installation.
6.7.2 As a result, training programmes for the
conversion from the old system to the new sometimes are
started before the final development of the system has been
completed. Testing of the system, and adding modifications
to the system, is taking place in parallel with the training of
the staff who will use the system eventually. This is
illustrated in Figure 6-1.
6.7.3 A major drawback of this situation of course is
that at the time of implementation (i.e. actual use) of the
new system, few (if any) operators will have received any
training on the operation of the system in its final form.
Sometimes subsystems may not have been available during
training at all, so that the first time the operators see the
Development
Testing
Implementation
Modifying
Training
Figure 6-1.
Actual or observed situation
complete system is the day they are expected to start using

it. There may be significant differences in the quality and
fidelity of training rcxeived by individual operators. Not
surprisingly, it will take the operators several days or even
weeks to sufficiently acquaint themselves with the new
system(s). Until the lime they feel comfortable operating
the system(s), they are likely to handle traffic more
conservatively than envisaged by the designers of the
system and probably even more conservatively than they
did using the old system, which in turn will detract from
optimum system performance. By more careful planning of
the process, this undesirable situation could have been
avoided for all.
6.7.4 The follovving quote from Comp~ter-~'i'u;nan

Interface Evaluation of the Oceanic Data Link System
demonstrates that the situation described above is not a
hypothetical one: "The primary training issues appear to be
that training is conducred on a simulator that is not identical
to the system to be used in operations, there is minimal
controller exposure to the new system, and there is limited
refresher training. Due to the frequent changes in the new
system (particularly command labels), controllers find that
much of what they have learned is no longer accurate and
they must use trial and error to identify new or modified
commands."
6.7.5 Experience shows that it is unrealistic to expect
a new system to be ready for use the day the manufacturer
releases it to the customer (the ATC service provider).
Despite the fact that at that moment the system formally
meets the specifications to the satisfaction of the customer.
preparations by the customer for several minor or major
modifications to the system (usually in the software) will
already have been made. ?he reason for adding those
modifications only afteir having formally become the owner
of the system, rather limn during the installation phase, is
purely financial. Were they to be done during the
installation, the man~ufacturer would have probably
considered them to tre a deviation from the original
specifications, for which there normally would follow a
charge. By doing the modifications after accepting the
system from the manufacturer, the new owners may not
have to pay such additil~nalcosts.
6.7.6 Ideally. training of the operators would only

commence after those modifications have been incorporated
into the system. At that jmint in time all developmental work
and testing should have been completed and the system will
be in its operational stale. All operatois receive training on
the most recent version of the system and will soon feel
comfortable using it. Thtre will probably still be a
requirement to allow for a minimal transition time, during
Human Factors guidelinesfor air traflic management (ATM) systems
6-6
which the organization will start using the new system and
stop operating the old one, which may cause some
disruption to normal operations in the airspace concerned.
Through a careful information campaign, the airspace users
can be informed of this in advance though, and they in turn
can plan for the inconvenience, too.
6.7.7 It should be realized that the linear timeschedule from Figure 6-2 does not imply that preparations
for the training cannot start before completion of the
system. In fact, as argued before (see 6.3.1). those
preparations should start as early as the writing of the
system specifications. If the system features a training
simulator, which with advanced and complex systems is
normally the case, the specifications for this simulator and
its connection with the operational system should be
included in the system specifications. Also, by involving
trainers from the early stages onward in the design and
development of the project, they will obtain a good
understanding of the various aspects of the system, which
will enable them to transfer relevant knowledge to the
training programme.
6.8 TRAINING COSTENT
6.8.1 When implementing new equipment andlor new

procedures, the main focus of associated training
programmes obviously will be on the HMI features of the
new equipment and application of the new procedures.
What is less obvious, however, is that for optimal operator
performance it is necessary as well to address other aspects
in such training programmes. These aspects include
understanding of the applied philosophies in the system
design, understanding of the (changing) team roles within
the ATS unit, understanding of the interaction of the new
equipment with other equipment, and understanding of
concepts such as Situational Awareness and Ermr
Management (see Chapter 2 'Three essential concepts").
Testing
6.8.2 Previous chapters in this manual suggest various

items for incorporation into training programmes related to
the implementation of ATM systems. For convenience,
these items are summarized below:
Chapter 2 -Three essential concepts/Situational Awareness
ATC training programmes in general should include
teamwork training. Training programmes associated
with the implementation of advanced systems should in
particular include teamwork training.

include awareness of the importance of specific aspects
of differences between operators and between
individual pilots.
Training for air traffic controllers should include
proficiency in the application of procedures related to
the failure of navigarional aids.
include awareness about aspects of differences and
variations in aircraft performance.
Controller training must include proficiency in the
application of procedures related to the failure of ATC
equipment.
Chapter 3 - Data link infrastructure and applications
Operators and users should be made aware of the
inherent limitations of any deployed technology.
Chapter 5 - Research
Air WIC
controller &raining for the use of CPDLC
should include awareness of related flight deck
p d u r e s used by operators in their area of jurisdiction.
Training
Figure 16-2. Ideal or desired situation
Implementation
--
Chapter 6. Preparing for change
Standard operating procedure design and training for

controllers must incorporate the fact that voice communications are the preferred option for transmitting
time-critical immediate action messages.
ATS CPDLC operator training should include
information on the opportunities for human error when
issuing conditional clearances by CPDLC.
Training for ATS CPDLC operators should include
awareness of the capabilities and limitations of the
CPDLC interfaces on the flight deck of relevant aircraft
types; and
Procedures including the use of voice communications
should be established as alternatives to the use of
CPDLC for complex dialogues or negotiations.
6.9 REGULATORY ASPECTS

6.9.1 The implcmcntation of a new and advanced
ATM support system may require certain actions from the
State's air safety regulatory authority. In particular the
regulator may wish to become involved in the certification
of the new equipment, as well as in defining specific
licensing criteria for the operators of the new system(s).
Certification
6.9.2 The certification of ATM equipment is a
relatively new area in air safety regulation. Historically,
ATM systems have by design been rather autonomous
pieces of technology. Requirements that needed to be
fulfilled for interactions with other systems (both airborne
and on the ground) were fairly basic and mainly consisted
1(
of precise technical specifications. In essence, ATM

systems were designed to operate independently of airborne
equipment (with the notable exception of transponders),
and the airborne equipment was designed to operate
independently of the ,4TM equipment. The introduction of
CPDLC and ADS brings a major change to this practice.
ATM equipment and airborne equipment become
interdependent (CPDLC), or ATM equipment even
becomes largely dependent on airborne equipment (ADS hence the name Automatic Dependent Surveillance).
6.9.3 This implies that air safety regulators in
principle become responsible for the correct functioning of
ATM equipment in conjunction with airborne equipment. In
fact this is not a new responsibility, since the regulators
have always k e n ultimately responsible for the correct
functioning of ATM equipment. Yet that responsibility has
not always resulted in a formal certification process for
ATM equipment. With the implementation of, for example,
CPDLC and ADS-based services in a State, it becomes
necessary to establish such.a formal certification process in
order to ensure compatibility of the new equipment with
that in adjacent States as well as with airborne equipment
(avionics).
6.9.4 It goes beyond the scope of this Manual to offer
detailed information on the certification process for PirM
equipment. For the purpose of this chapter it suffices to
identify the requirement for certification of the equipment.
The graph in Figure 6-3 illustrates where certification fits in
the time-schedule presented earlier.
Licensing
6.9.5 The graph in Figure 6-3 also illustrates where
licensing fits in the time-schedule for the implementation of
new ATM equipment. The introduction of CPDLC and/or
p
c
iens
n
ig]
Certification
Training
Modifying
b1
Figure 6-3. Time-schedule including certification and licensing
Human Fucrors guidelines for air
5-8
ADS-based air traffic services will require licensing

authorities to review their existing licensing schemes. Just
as not every person who can speak is thereby qualified to
use radiotelephony (RIT) communica~ions,it should not
automaticatly follow that any person who is qualified to use
R/T is also qualified to use CPDLC. For the provision
ADS-based air traffic services, which fundamentally differ
from both procedural control and radar control, it is evident
that operators will first need to have obtained an adequate
level of knowledge and skills relevant to these services.
6.10
6.9.8 This concept offers States and regulatory

authorities flexibility to adapt their licensing schemes to the
operating practices of the air traffic service promviders. It
also allows for the future introduction of other means of
surveillance by simply adding an endorsement to the
scheme where appropriate.
Note-- See also the ICAO Manual of Procedures for

Establishment and Management of a State's Personnel
Licensing System (Doc 9379).
Approach ControlIArea Control

Procedural Rating
CPDLC
RECOMMENDATIONS
A multidisciplinary project team should be formed to

guide the procurement of new equipment.
~h~ project team should consider the development of a

formal Human Factors plan.
The project team should formulate an operating
philosophy to govern the design of the new system.
This operating philosophy should be based on the
concept of Human-centred Automation.
6.9.6 By s.dding appropriate requirements for

knowledge and skills related to CPDLC and ADS-based air
traffic services, the licensing authorities will ensure that the
new services are only provided by qualified operators.
6.9.7 In a proposal for a European Manual of
Personnel Licensing for Air Traffic Controllers, the concept
of distinguishing ratings for tower, approach and area
control is introduced based on whether or not the service is
provided with the aid of surveillance equipment. In case
sunzeillance equipment is used, the type of equipment for
which the licence-holder is qualified is specified in what
has been provisionally labelled an "endorsement" to the
rating. Such an endorsement could also be used to indicate
on the licence that the holder is qualified to use CPDLC,
both for the Procedural and the Surveillance ratings.
(See Figure 6-4.)
traffic management (ATM) systems
The effects of the new system on team functions should

be taken into account early in the design process.
fie project team should consider [he use of

prototyping".
All operators must receive training on a version of the

system that is similar to the operational version.
Training for operators should not be restricted to the
HMI features of the new equipment and application of
the new procedures. It should include such aspects as
understanding of the applied philosophies in the system
design, understanding of the changing team roles within
the ATS unit, understanding of the interaction of the
new equipment with other equipment, and understanding of concepts such as Situational Awareness and
Error Management.
'
States and regulatory authorities must consider the

implications for certification of ATM equipment and for
ATC licensing schemes in a timely manner when
implementing CNSIATM systems andlor related
services.
Approach ControlIArea Control

Surveillance Rating
I
Figure 6-4. Sample endorsements to ratings
Ct~apier6. Preparing for change

Summary
6.1 1 The flow chart in Figure 6-5 provides a schematic

summary of the items discussed in this chapter and
incorporates the recommendations listed above. The chart
contains a reference to standard operating procedures, which
are discussed in Chapter 7.
References
Cardosi, Kim M. and Elizabeth D. Murphy. (eds.), Humon

Factors in the Design and Evaluation of Air Traflc Control
Systems, United States Department of Transportation,
Cambridge, MA. 1995. (DOTIFAAIRD-9513 DOT-VNTSCFAA-95-3.)
6-9
Computer-Httman Interface Evaluation of the Oceanic
Data Link System, Federal Aviation Administration, Human
Factors Branch, ACT-350, W~lliamJ. Hughes Technical
Center, Atlantic City International Airport, NJ, 1997.
for
and implementing
Resource Management, Eurocontrol, Brussels,
(HUM.ET1 .ST10.100-GUI-01.)
Team
1996.
European Manual of Personnel Licensing - Air Trafic

Controllers. Draft edition version 5.1, Eurocontrol,
Brussels, 1999.
Hopkin, V. David, Human Factors in Air Traffc Control,

Taylor & Francis, L~ndon,UK, 1995. (ISBN 0 7484
03574.) (ISBN 0 85066 823 9.)
Manual of procedure.^ for Establishmenr and Management
of a State's Fersonner! Licensing System, ICAO, Montreal,
1983, reprinted 1996. (Doc 9379.)
6-10
Human Factors guidelinesfor air trafic management (ATM)systems
Determine operating
philosophies
Human Factors Plan
Human-Centred Automation
System specifications
f
Team functions
v
Early prototyping
Develop Standard Operating

Procedures (Chapter 7)
Train operators
Implement system
Standard Operating Procedures
I,
HMI, S O P S , design philosophies,

team roles, interaction with other
equipment, SA, error management
1
Legend
Tangible output
Methodology or
input
Action of Regulatory
Authority
Figure 6-5. A schematic summ,ary of items and recommendations from Chapter 6
Chapter 7
STANDARD OPERATING PROCEDURES
7.1
INTRODUCTION
7.1.1 The introduction of CNSlATM technology

generates the requirement to develop and implement new
standard operating procedures which reflect the needs and
constraints of the operational context in which the technology will be deployed.
Note.-- 111 this chapter the term ''procedures" is used to
itzdicute srandard operatir~gprocedures.
7.1.2 ICAO has developed Standards and Recommended Practices (SARPs) related to CNS/ATM, but
due to the asynchronous and incremental introduction of
the various (suh)systerns in different regions and States it is
unavoidable that initial procedures for thc application of
new technology will sometimes have to be developed
regionally, nationally or even locally.
7.1.3 This chapter presents general guidelines on
procedure development and specific guidance concerning
standard operating procedures for CPDLC, ADS, predeparture clearance (PDC) and GNSS-based instrument
approaches.
7.2 REQUIREMEKTS FOR PROCEDURE

DEVELOPMENT
by whom it should be conducted;

how the task should be done (action);
the sequence of actions; and
the feedback necessary.
Furthermore, procedures should:
be written carefully;
be error-resistant and error-tolerant:

be unambiguous;
be comprehensive;
not contradict each other;
be easy to understand and apply.
7.2.3 Procedures should clearly state who is
responsible for their application, and when procedures
contain listings of conditions, it should be clear what is to
be done and by whom in cases where not all of the
conditions are met.
7.2.1 It is of paramount importance to incorporate

Human Factors knowledge in the procedure development as
well as in the procedure implementation.
7.2.2 Procedures must be based on ihe concept of the
users' operation. These operating concepts should evolve
into work policies and practices that specify how to operate
the system efficiently. In general, procedures should
specify:
what the task is:
when the task should be conducted (time and
sequence):
7.3 HARMONIZATION OF STANDARD

OPERATING PROCEDURES
For case of interoperability, on a nationa! level there should
be as little discrepancy between local procedures as
possible, just as on a regional level there should be as little
discrepancy from national procedures as possible. To that
end, States and organizations involved in the in-iplemcntation of CNSIATM-related standard operating procedures
should coordinate their activities on a regional level as early
as is feasible.
Factors guidelines for air fraffic management ( A T M ) system

7.4
STANDARD OPERATING PROCEDURES

FOR CPDLC
Nofe.- General procedures for the use of CPDLC are

contained in the Manual of Air Traffic Services Data Link
Applications (ICAO Doc 9694).
7.4.1 From a Human Factors perspective, and based
on feedback from early implementation as well as from the
research community, it is possible to offer the following
observations concerning the use of CPDLC:
The differences in characteristics and capabilities of the
available FANS-l/A avionics should be known to the
ATS providers and in particular to the controllers.
When implementing CPDLC it may be advisable to
initially use a limited subset of the available message
elements only.
It may hc advisable, due to differences in interpretation
hetwccn ATS units, to exclude the use of certain message clcmcnts.
Not all available message elcmcnts can he accommodated by the different FANS-IIA avionics.
It may be useful to add locally frequently-used phrases
to the message set of the ground system, even though
the airborne systems will consider these phrases to be
free text.
Unresolved issues
7.4.2 The ICAO CPDLC message set is initially
published in English only. There is, however, nothing to
prevent States, organizations andfor operators from
translating this message set into any other language. The
potential for incompatibility between end-users, and the
resulting errors and degraded safety, is obvious. Therefore
there may be a growing requirement for the formal certification of the software containing such translated message
sets before they are put into operational use.
7.4.3 For the development of the current ICAO

CPDLC message set, a conscious choice was made to
adhere as much as possible to the existing ICAO R/T
phraseology. It should be realized, however, that the RfT
phraseology was designed for use with voice communications via HF, VHF or UI-IF radio. The RfT phraseology
contains words and sounds that are optimally suited for
transmission and interpretation via these media. With
CPDLC there no longer are any sounds transmitted
between controllers and pilots, and some of the words used
in R/T may therefore not be strictly required anymore in
CPDLC. An example are the simple words "yes" and "no",
that in R/T were substituted by "affirm" and "negative",
respectively. It may be possible to design a future CPDLC
message set in which words and phrases are used that are
optimally suited for transmission and interpretation via data
link. The effect of the differences in the two sets of
phraseologies (R/T and data link) should be carefully
analysed and understood before such a change in
philosophy is effected.
The use of free text should be iimited to those cases for

which no preformatted message elements exist.
Note.-- The use of prefonmrred message elements
allows on-board data processing such as the automatic
insertion of the clearance information into the flight
managemcnr conzpurer: If also ollows the controller to
respond more quicklj when tile ATS system has the capability ro automatically Iink a preforrnatted request to a
prefonnarted response. Additio?lall> rhis process minimizes
the risk of input errors.
The use of long messages should be avoided.
The use of messages with multiple clearance elements
should be avoided.
The use of conditional clearances should be avoided.
Procedures for data link failure (i.e. CPDLC
contniunicarions failure) must hz established.
7.5 STANDARD OPERATING PROCEDURES

FOR ADS
Note.- General pmcedures for the use of ADS are
contained in the Manual of Air Traffic Services Data Link
Applications (ICAO Doc 9694).
7.5.1 From a Human Factors perspective, and based
on feedback from early implementation, it is possible to
offer the following observations concerning the use of
ADS:
Most ground systems, whether manually or automatically, will establish ADS contracts on completion
of a successful AFN log on. However, the estabfishment of an ADS contract by a ground system does not
q u i r e the current controlling authority to forward the
address of that particular facility to the aircraft. As
such, it is imperative that a priority system for ADS
connections be strictly adhered to;
Chapter 7. Star~dardoperating procedures

connection request will be refused by the aircraft as Ihe
FIR will not have been notified as being the Next Data
Authority;
FANS-]/A-equipped aircraft can have up to four ADS

connections established, each with a different ground
facility. As no priority is assigned to these connections,
the highest priority for an ADS connection must be
given to the current controlling authority, followed by
the next authority with direct control responsibilities for
the aircraft (see Figure 7-1 );
To guard against the situation where an aircraft is

required to generate reports at a rate faster than can be
sent by the ACARS system, only the ATS facility
currently controlling the flight should initiate a high
periodic reporting rate with the aircraft. Any adjacent or
subsequent ATS facility requiring a high reporting rate
(five minutes or less) with that aircraft should
coordinate with the current controlling authority prior
lo increasing the periodic reporting rate.
Figure 7-1: An ADS contract was required by ATSU 2 to

allow the aircruji's progress near the FIR boundary to be
monitored. To ensure that the next unit with direct control
responsibility for the aircraji had priority over the ADS
connections, an AFN log on to ATSU 3 was initiated by
ATSU I prior to the aircraji being instructed to log on to
ATSU 2.
Unresolved issues
Ground automation and system design features differ
between FIRS. Some systems cannot process flights
which do not enter their FIR, whether or not they are in
possession of a flight plan. Additionally, some systems
will connect both CPDLC and ADS automatically on
receipt of an aircraft's AFN log on. For these systems,
when connecting as the adjacent FIR for the moniroring
of an aircrali close to a boundary, thc CPDLC
7.5.2 There are no ICAO provisions pertaining to

ADS vectoring (ac opposed to radar vectoring). Still it will
be very tempting for a controller with an ADS-derived
traffic situation display to resolve certain conflicts by
issuing heading inst~uctionsto aircraft. Since the source of
the posirion information and the update rate of the position
reports differ significantly between ADS and radar. it is yet
,------1
I
ATSU 1 (ADS)
Figure 7-1. Esanlple of a n ADS connection sequence
7-4
to be demonstrated that ADS vectoring is a safe option. The

appropriate authorities and/or the ATS providers should
ensure that ADS vectoring is not applied unless procedures
are developed and conditions exist under which it is
considered safe to do so by all parties involved.
7.6 STANDARD OPERATING PROCEDURES

FOR PRE-DEPARTURE CLEARANCE (F'DC)
7.6.1 Pre-departure clearance (PDC) is a system that
allows pilots to obtain IFR clearances via data link prior to
engine start, thus reducing or even eliminating the need for
verbal communication on clearance delivery frequencies.
PDC has been implemented operationally or in trial
versions at various airports around the world. The data link
medium used so far is the ACARS network, though in the
future the ATN will be used.
7.6.2 Issues that have arisen from the application of
PDC include: confusion on the flight deck concerning the
content of PDC messages; flights departing without having
received their PDC; and inconsistencies in the formats of
PDC messages used by different facilities. On the ATC
side, it has been noted that the addition of a PDC terminal
that was not integrated in the existing (automated) system
significantly increased the workload of the controllers.
Content and format

7.6.3 According to ICAO Annex 11 - Air Traffc
Services, an air traffic control clearance is an "authorization
for an aircraft to proceed under conditions specified by an
air traffic control unit". An air traffic control clearance shall
indicate:
the aircraft identification as shown in the flight plan;
the clearance limit;

the route of flight;
the level(s) for the entire route or part thereof and
changes of levels if required; and
any necessary instructions o r information on other
matters such as approach or departure manoeuvres,
communications and the time of expiry of the
clearance.
7.6.4 At many airports where frequent IFR departures

are handled, standard instrument departures (SIDs) are used
to indicate the initial route to be followed after departure

and often contain the initial level to climb to. This reduces
the requirement for controllers to read lengthy and
complicated routing instructions and also reduces the
requirement for pilots to copy and read back such
instructions.
7.6.5 An example of the text of a PDC transmitted via
voice communication is: "Flight 123 is cleared to Los
Angeles via MOGULlA departure, squawk 4530". In this
example MOGULlA is the designator of a SID that
includes an initial altitude restriction. The pilot is required
to read back the complete text and the controller will
confirm to the pilot that the readback was correct. It is
obvious that when routing instructions consisting of several
way-points andlor airway designators are used instead of
SIDs. the potential for error increases.
7.6.6 In the previous example. the pilots from
Flight 123 additionally will have to obtain information on
the weather conditions and the assigned departure runway,
which is normally received from the automatic terminal
information service (ATIS). Confirmation of receipt and
validation of this information is also passed b> voice
communication between pilot and controller.
7.6.7 A format for PDC via data link that is becoming
widely accepted in the industry was developed by ARINC
as part of their Specification 623. The contents of this
format consist of (in this specific order): a message type
identifier, iime and date, ATC identifier, clearance indicator
and number, flight identificr, cleared destination, cleared
runway, departure and route, squawk notification, departure
time notification, next frequency notification, current ATIS
notification and optional free text.
7.6.8 An example of the text of a PDC transmitted via
data link in accordance with this format is:
"m1035 990802 EGKK

146
BAW123 CLRD TO KJFK
26R
DTYSV
SOUAWK 5023
1022 NEXT FREO 134.550
m I
EXPEDITE IF POSSIBLE".
Items that are underlinzd are "fixed text", i.e. non-variable
standard items in the PDC. The avionics of the aircraft
receiving a data link PDC subsequently generate a "readback downlink message". This message is almost identical
to the PDC received, except that the message type identifier
is diffcrent. By transmitting this message, the pilot enables
the ATC system to process the acknowledgement of the
PDC.
Cl~uprer7. Sru~ldurdoperating procedures
7-5
comnlunication between pilots and ATC. The form of
such verification shall be established by the appropriate
authorities and may consist of readback of the
transponder code, o r readback of the clearance indicator
and number, or other acceptable means.
7.6.9 In case it is necessary to amend a PDC already

received by a flight, the new clearance is transmitted in
accordance with the same format and the text
"RECLEARANCE #" (where # represents a numeric
indication of the appropriate reclearance sequence) included as thc first part of the frce text area of the message.
Note.-- At certaiti locutiotis nliere PDC triu1.c hur*e

beet1 corlrlrccted based on the use ($ACARS, it Hns decided
ro ot11> utnend PI)Cs by R/T since rc.if11ACARS there is tro
grturutiree I / I U I tnessuges are delivered in t l ~ esutrie order it1
wl~ich rliey ure senr. Tlrc possihilit! e.tists that a rc.cleuru~zce
coitld reach u fligizt creitl before tlic origitiul cieurutlce is
recei\aed. bt-hich is a poretiriul sortrre ofcotlfiisioti. Once the
ATN is u~rriluhle,rllis sititution it~illhe rerr~edied.
Integrity
7.6.10 Due to existing diSiercr~ccs in the way these
clearances are generated within A?'C units, as well as to
cnisting dil'fcrsnccs in the processes by \shich clearances
arc pro\.idcd to fliglit crews. it is not possihlc to prcicnt
liere a detailed procedure for data link PDC delivery thi~tis
applic:thle in all situations. Sornc acrodro~nccontrol ur~its
havc to first contact an area control centre (ACC) before
they physically havc all elcmcnts of the PDC available.
Other units immcdiatcly havc the full PDC available and
can issue i t to pilots ~ ~ p odcmand.
n
aster wliich they only
require (silentj cndorscrncnt of the cIc;~rancccontents f'ronl
the ACC. 111 ~ n i facilities.
c
the PDC is communicated by
ATC to tlic airline opsrations centres. who in turn
communicate ir to their pilots bcfore departure. Yet the

following general guidelines apply:
I'roccdurcs need to bc in place to ensure th;lt the ATC

clearance rcccivcd and uscd by 111c fligl~t crew is
identical to that issucd and uscd by ATC.
The automated systcni niust indicate that a flight is
requesting a PDC, arid it must present the controller
with a proposed PDC for that llight.
At the same time. it must provide an opportunity Sor the
controller to rllodil'y the p r o p o d I'DC where arid wlicri
necessary before tile nicssagc is trarlsniitted to tlic
aircraft.
Nore 1.- I f readhack of the trarisponder code is considered us a n~cansof PDC verification, this inlplies tlrut in
utiy sltbseq~tetitreclearar~cesthe code nricst be dzatlged.
Norr 2.- Fligtlt crews nluy apply un itlteniul procctltcre
that itivolves prititittg of the PDC via lire ACAKS pritlter otr
tlle j7ight deck. If silould be rloted rfiut tile iriregrir~.of this
prititer is - 11y specijicutiotl - of u loiser stut~dard111utl
tlru; ofrlle vistcal disltlujs on nJlicii tiie PDC is presetlted.
111 sott~ecuses this tmuj lead to discrel,utrcies bcr~t.cetltile
prirltcd rext urld tliat or1 tile displu>s, tt,hic/l niay go
rrr~tloticedby the flight creiv cofzcertzed. T1ri.s is purticrtlrrrl~
tire (.use >tJleti tirtn~ericulsrritigs (e.,y. la~itrtdc/Iotrgir~tc/c~
> t . u ~ - p ( ~ i rrre
t ~ t srcsed
)
iti the POC. Cotirrollers shorcld be
rt.ccit1c.d ro l)c ulcrt f i r u11purctlt dc,viutiotis frotri PDC
m!trinxs or l e c ~ l siriitl.sit~itredhy rkrtu litlk.
An example of a data link PDC HMI

7.6.1 1 Figure 7-2 shows an example of the screen of
an ATC data ,ink PDC
is an
cxpznmental
from
Exreraivc
use is made o f colour coding to distinguish the various
illlormation
on tllc
ATIS illfurmarion
on
riglit side of
It may
c.tc
is
techrlically possible to transmit this
with thc PDC, thus reducing the number of separate actions

that pilots havc to perform hcfore departure.
Note.- One u.sl)ect that ertrerged as a lessoti from

.s~~t~i~riil
data 1ir1k PDC i ~ t ~ / ) I e ~ t z ~ ~ ttrials
~ t ~ ~ ti i. o~t11(1t
t i the
cotltrollcr-I'fX irrtetjir~cesiiorcl(1 he crt~itrtgrured purr of'
tllc tirttonlured ATC s.v.rteni. If cotitroilt~r.~
are rcqreirc.ci to
oposirc drcnl .syfctri.s. their \t*orkiocrd (fittl i t i i ~ r e c i .to~ ~ ~ ~
rtr~crc~c~c~l)tahle
1c1.cl.s ~t-iri(.llre.st11t.s it1 O I I C Of t i ~ eS.YSICIIIS
(rt.srtnl1~~
tlrc cicrrti litrk P I X ) tlot h~itlgtr~~c~~rtic.d
to atl\ttlnw.
(See crlso C/ltrl~tc,r4 "Tlie /ttenruri-t~~cic~I~it~c~
itltcrfric.~~".)
Tlie systcm must inclica[c tIl:tt the PDC was received

arid ackrio\~lcdgcdhy the Ilight crcw.
7.7 STANIIARD Oit'ERATING PROCE1)IJRES

FOR GNSS-BASED INSTRUMENT
AI'PKOACIIES
At a givcn tirric hclorc titkc-off. verification of receipt

of the corrixt !'I)(' shitll he accon~plisliod hy voice
As with otllcr ir~stn~rllclii

approaches, it is cxpccrcd that
with ; I I ) ~ ~ o ; ~ c I I L ' s t~;tscclor1 the GNSS [lie role of A'TC will
7-6
Hiinfan Facrors ,qltidcli~~esfor

oir rrafjc ttznnugenioz!( A T M ) sysfenls
.--
--
.cF
,.
-:M . ~ 'I ' 2 j5S
~ i ~i U
>!.1.:17!71
~
O
0, K2 i:l :GS
start& $&hl;
st& ]
-- ]
-. C
-'
-rms[=d - tm@fl~-kJ
---rl)iil?9? j --S1.1 - ..-- --.- ii-N
Sf ~ n d b g l ~~ loiu t i - 1
odlry
FM
R W ~
rtEscR7~le@4&~330
.-..-180 HUL- BULUX LEBTQ
j
~ n rI : : --- - .. ...-.. .- . .- . - . .
.. . - MONDO
. .
I-.
- -1; .~ - -.
,.
1I
i /
__
_. __
- -_--I
I
11
,--
@1.i .s- -a- o a l q *1vk1@735

.
.- -.
._
~'L-ml
ke~J
I_-.
i ~ ~
-1;
1
Figure 7-2.
Example of a data link predeparture clearance HMI
he to clear [lie aircrali to the st;irtirlg poitit {'orthe ;ippro;~cli

as well as to clear it t'or the suhscqucnt prtxedurc. .4TC will
he tile authority to determine whctiicr the requested
appn)ach proccdunt cart he used. To iliat ciid KIT will have
to hc pn)vidcd with tcclinical irihrriiation conccniing the
availability and integrity of the GNSS signals. Furtlicrmorc.
proccdtrrcs need to he in pincc in casc tlic GNSS-bused
:ipproacli cannot be uscd Sctr technical rcasoris.
When GNSS-based inslrumcnt approaclics are used.
ATC niust he provided with tcchnical infomiation
concerning tlic availability and integrity of GNSS
signals: and
Procedures niust he in place in casc the GNSS-hascd
instrunicnt approach cannot he uscd for technical
~~3SOIlS.
Cot~c.lir.vioti
7.S Standard operating proccdurcs enable the
conversion from a thcorciical opcrutional concept to its
practical application: tcchnology should assist and support
tlic operators to achicvc this conversion. Ho\vevcr with the
intrcrfuction of data link technology. originally designed to
ovcrconic sho~comi~igs
in voice Iirr co~nriiunications.ncw
pc'ssihilitics arise that warrant n change in existing
prck-cdurcs when applied. CPDLC, ADS and orhcr data link
applications hring fundamental changes in the way air
traitis coritrollcrs work - arid are trained to work. By
applying Human Factors knowledge i n CNSIAThl
prwcdurc design. these cliangcs will rcrnain rnanagcahlc,
prcn.idcd adequate training is given to the operators k i o r e
tl!c sFstcms arc put illto opcrntionnl use.
Sore.-- Traitiiri~aspects arc cfiscrtssc~ciitr Cl~n/~rc*r

6
"Pn*juirir~~
.for cl~cztfgc
".
Chapter 7. Standard operaring procediires

References
ARINC, Characrer-Oriented Air Traffic Services (ATS)

Applicutions. Specification 623, 1999.
Isaac, A. and B. Ruitenberg, Air Trajic Controi: Human
Performance Factors. Ashgate Publishing Ltd., Aldershot,
Hants, UK, 1999. (ISBN 0-291-39854-5.)
ISPACG, South Pacific Operations Manual. Version 2.6,
1999.
Manual of Air Traffic Services Data Link Applications.
ICAO, Montreal, 1999. (Doc 9694-ANl955.)
7-7
Chapter 8
NEW FLIGHT DECK TECHNOLOGY

8.1
INTRODUCTION
8.1.1 The ideal way to change operations begins with

defining a concept, followed by developing procedures to
support the concept, and subsequently designing technology to support the procedures. However, this is not how
change is always introduced in aviation. Quite often
changes in aviation procedures and indeed in operational
concepts havc bccn brought about by emerging new
technologies.
This chapter introduces the concept of Airhome

Situational Awareness and presents new designs for flight
dcck technology that may cvcntually havc an impact on air
traffic services and ATC procedures. Implementation of this
technology may still bc years away. and some of it may not
bc implemented at all, yet designers of ATM systems should
consider allowing for future incorporation of relevant aspects
of new flight dcck technology in thcir systems.
under the term of airborne separation assurance capability.

Such capability can be defined as the set of communication,
navigation and airborne surveillance functions on board an
aircraft which enable the aircrew to ensure that their flight
remains separated from others (in accordance with rninimum separation standards) and from other hazards (c.g.
terrain, obstaclcs, vchiclcs, ctc.), in all types of weather.
8.3 AIRBORNE SEPARATION

ASSURANCE SYSTEMS (ASAS)
8.1.2
8.2 AIRUORNE SITUATIONAI,

AWARENESS (AIRSAW)
8.2.1 Airborne Situational Awareness (AIRSAW) is

defined as the aircrcw mental picture of thc aircraft state
and outside operational environmcnt, including information
on the terrain. aircraft position, weather, traffic situation
and air traffic management. The AIRSAW concept ainls at
enhancing the aircrcw mental picturc of its outside
environment in ordcr to improve its ahility to manage the
flight safely and cflicicntly within the current and foreseen
operational environment.
8.3.2 To provide cnhanccd AIRSAW. in~pro\r.ddata
on aircraft position. weather, terrain, surroundin2 tralfic :und
ATM information need to be fed on board the aircnit. This
can bc done through the implemcotation of data link
scrvices and other airborne t(u>Is in ordcr to glohally
enhance aircraft func~ions.
8.2.3 Thow cnhanccd aircraft functions \\ill also

constitute a set of firnctionalities that can he r:groupcd
8.3.1 By increasing the Situational Awarcncss of

fligh~crcws it is c~lvisagcdthat new concepts (e.g. Free
Flight) and new proccdurcs (e.g. In-trail Climb, and
Station-keeping) will become feasible. An important
feature of these concepts is that the responsibility for
separation hctwccn aircraft will be delegated in part or fully
from the ground ( i t . ATC) to the llight dcck (i.e. pilots).
The generic name for systems that support this delegation
of responsibility is Airhornc Separation Assurance Systems
(.ASAS).
8.3.2 I'hc Research and Development community has

made significant cfforts to develop tools I'or improving and
supporting the Situational Awareness of flight crews. The
cockpit display of traffic inforn~ation(CDTI) is a tool that
has resulted from thcsc efforts. Another innovation consists
oi integrating a CPDLC incssage display wit11 a navi~ation
di.;play on the fligllt dcck. Esanlplcs of new tools arc
discussed i n the Sollowing para~raphs.
Cockpit display of
t r a f i c information
8.3.3 A cockpit display of traffic intbrrnation (CDTI)
is a pcncric avionics device on thc llight deck that is
c~pahlcof displaying the position information of nearby
aircr;~li.It 111;iy also i n c l ~ d egrot~ndrckrcncc points and
nasiption informarion to incruse the AIRSAW. The
r.\:lrnplc dcscrihcti here (Figure S- 11 was developed hy the
Clrapter 8.
New jlighr deck 1ecltt1ology
Predictive ASAS
Dutch Aerospace Laboratory (NLR). It represents a stateof-the-art experimental design of a CDTI.

8.3.4 The traffic information. obtained via ADS-B, is
displayed on the navigation display. Because of the relative
importance of vertical manoeuvres, a vertical navigation
display is integrated below the normal horizontal navigation
display. In contrast to a conventional TCAS display,
different symbology is used because of the extra
information available. The extra information consists of:
traffic call sign
heading
altitude
ground speed
climbing or descending arrow
horizontal and vertical track lines
prcdictcd intrusion of protcctcd zone of target, and
lime to intrusion.
8.3.5 The first six items can be toggled on or off by
using a display control panel. The horizontal, vertical and
clipping range of the navigation display can also be
controlled by means of the display control panel.
8.3.6 Whcn a conflict occurs with a time to maximum

intrusion of lcss than five minutes, an aural alert sounds and
the following sequence of display changes are shown:
1. The position of traffic is shown (in amber);
2. Whcn a conflict is predicted. the incursion of the
protected zone of the traftic is shown;
3. Thc traffic resolution is shown on the NAV display;
and
4. For ten seconds after the conflict is resol\rd. the
position of the traffic is shown in ihe colour of the
conflict.
S.3.7 If. during the above sequence. the rime to
nlu\~rnurn intrusion becomes lcss than three minutes. the
traflic symbols will be shown in red together with an
incrcase in the aural alcrtinp level.
8.3.8 An important issue associated with ASAS

concepts is whether or not to provide traffic intent
information. In a situation in which no intent knowledge is
communicated, surprises and short-term conflicts can occur
when aircraft unexpectedly turn or initiate a vertical
manoeuvre. Many people see the communication of intent
as the solution. Concepts are being proposed which would
communicate mode control panel data such as altitude,
heading and speed settings or flight management system
data, such as next way-point andlor optimal cruise level.
However. it is not always clear which of the data should be
used. The flight crew has no direct connection with the
ADS-B set-up and can suddenly change the parameters by
which the aircraft is flying. Therefore NLR has tried to
tackle the problem from a different perspective. The goal of
using intent is to avoid sudden manoeuvres that would
trigger short-term conflicts. If the crew/aircraft knows what
manoeuvre would trigger a short-term conflict, they could
avoid such conflicts by not initiating any such manoeuvres.
Adding a "nilc of the road" stating that no such
manoeuvres arc allowed would theoretically eliminate the
problcm of short-term conflicts. At ICLR a so-called
"Predictive ASAS" has been developed which shows the
crew on the primary flight display (PFD) and the NAV
display which manoeuvre (if any) will trigger a conflict
within five minutes. Figure 8-2 shows the PFD with
"Predictive ASAS".
8.3.9 As long as the aircraft is flying in a straight line
(and other aircraft obey the above-mentioned rule) no
conflict will bc triggered at less than five minutes (the lookahead time uscd by the NLR). If a manoeuvre is called for
(c.g. at the top of descent), the crew is expected to avoid
manoeuvres which would trigger a conflict at short notice.
This is achieved by selecting parameters that are outside the
amber and/or red regions on the heading. speed and vertical
speed scale of the PFD.
8.3.10 Figure 8-3 shows a display that combines a
CDTI with a navigation display and a weather-radar
picture. Aircraft arc presented as symbols with vecrors.
indicating the direction in which they move. Relevant
additional paranietcrs of aircraft from which ADS-B
information is available arc also displayed. This display is
onc of the designs used in the Cargo Airline Association's
ADS-B evaluation programme.
8.4
UNRFSOLVED ISSUES
8.4.1 For most ASAS concepts and CDTI applications

it is expected that the Sonnal responsibility for aircraft
Figure 8-2.
Ksarnple of a prima-
separation \vill still he w,irli the grtwnd. i.c. witti air tral'lic
control. Thcrcf'orc ASAS concepts rriust k' dcvclopcd in
\vllicll corirrc>licrs are kept ^'in the loop" even though their
role Iilay he more passit'c than in today's systcril.
Dc\.ciopcrs of ASAS concepts face the cliallcngc 01'
cnsuririg that controllers ;it all titiles and under a11
circurnstanccs can s;~i>l>.rcsunic full responsibility li)r
aircr:~fi separation. This inciudcs sysrcni dcgradaions.
malfunctions and aircraft crncrsc.niies.
S.4.2 Otllcr isst~csth;it will r:quisc c:~rcfttl tliousht arc
the trairiirig ;md iiccnsing a>Fi.its invol\*cd \vith the
iniplcruc~~t;~tiorl
ot' AS,\S and CIITI. 01ic olwious trairli~ig
aspcit. for csamplc. is nirirc\v rrniliarity with the tlirccIcuc'r idcrlt~tic;~tion~
t'or fl~ghrc>pi.r.lrors ( ~ i r l i ~ i cprcscntcd
s)
on ilicir displ;\ys. Tticsc tiiscc-1i.itc.r c r ~ d c suaialil; diit'cr
fro111 tlic call sign li)r rhnt o p r a t n r as used in R/T
cornrnu~lic.atio~is.
(1:clr c\aniplc. BXW, thc identitier fix
British ;\ir\v;iys. is as\ociatcj \vitli the call sign
"SpcCJliird.'.) If prlots c1per;ltc In a foreign ctlvirorlrllcrit
there 1 1 1 ; ~ tw sever31 unf:l~riili;~r
thrcc-letter codes 011 tticir
displays. \rliicli tvill rii;ikc i t dil'ti~ultfor then1 to ccrrcl;~tc
visual t;lrgets witti ;ltlr;~linfor~ii;trion.Ttiis could lead to an
i~l~.rcasc
in tvorklo;id both ciri t l ~ cflight deck and for :\TC.
flight display with predictive ASAS
5in;c the flight crew nny rcquirc more clarilication from

X C 11c'li)rccomprcltcndir~gthe trattic >ituatiori.
S.J.3 On thc liscnsiog side it needs to he clariticd
\vhctlicr pilots require a fhrnlal quali1ic;trion to s\\umc
pafli31 rcsponsibility (dclegatcd hy A I T ) for scpar~tion
fronl other tlights. In the currcrit sysrcni. pilots h.i\c a
similar-looking responsibilily uridcr visual tligtit rules
(\'FR). hul thc dill;.rcn<c is tliat no prcscrihcd star~darjifor
\'FR scpar;~ticrricsist otlicr than "see-and-;~vi,iJ". 11. .-\S:\S
zon<cp~sa1.c adopted in wliicli 17igl1t crews arc to ipply
zc'II-~ep;~r;itior~n'itli {tic s311ic st;ttid;1rds ;IS c\i\iing
zi.i;;d.ird~ I'or r~dur->:par;ltior1. this nil1 reqc~ircskill. rtisr
ar: Jiffc'rcr~tI'rom r h w ot' pilots today.
S.1.1 ?'liis 1attc.r point also has iniplicatioiis fi>i icy1

li.ii.~lity.c.g. in case of loss of scparatio~i.If scparaticv tri a
gi\:n siti~ationbecomes less tli:ui rlic prcscrihcd (i.c. !:+I)
st.inJ;irll. ;11id oric or nwrc of the tligltt ~.rcivsi~ivol\:d .ire
uylng ASAS/CD?'I uitli the coriscrit o f .-YI'C. \vlio \\!it he
hc1J legally rcspctns~blc'! For optrutor acccpt;llicc ~bolli
aifit>riic arid on thc ground) of i11c ASXS concepts. 11 \\.ill
k iriiporlunt to rcsol\c this legal issue before any s! >tc'riis
or proccdurcs 3rc ir~iplc~lie~itcd.
Figrtrr X-3.
E:s;~mpleof ;I r~avigatior~
display \\itti an integrated CDTI ;jut1 weatllcr radar
hum at^ Factors guidelines for air traffic manugernent (ATM) systenis
8-6
8.5
CONSEQUENCES FOR ATM
8.5.1 In view of the fact that equipping aircraft with

ASAS and CDTI will require a considerable investment by
airline operators, it is expected that there will be pressure
from those operators on ATS providers to offer a service
that will accommodate the use of this technology. Since
equipping of aircraft with ASAS and CDTI will most
probably be an evolutionary rather than a revolutionary
process, ATS providers will at some point have to cater to
traffic that either is or is not ASASICDTI-equipped. In
other words. ATS providers will hzle to sustain operations
in a mixed environment (as far as ASAS/CDTI equipage is
concerned) for what could be a considerable length of
time.
8.5.2 One related Human Factors concern is that
flight crews in ASASICDTI-equipped aircraft may be under
the impression that they can "see" all traffic in their
vicinity, whereas in reality they only have information on
ADS-B-equipped aircraft and lack information on other
aircraft. This may lead to an increase in communications
between flight crews and ATC, thus adding to the workload
of both sides. In some cases flight crews, based on the
information available on their CDTI, could even initiate
actions that are jeopardizing the separation with aircraft
that are not visible on their display. Procedures need to be
developed and implemented to minimize or preferably
eliminate such events.
8.5.3 The introduction of ASASICDTI will also have

consequences for ATC training. Controllers will need to be
proficient in procedures for delegating responsibility for
separation to flight crews and for resuming this responsibility when required. This applies to both routine and
emergency situations. .
8.5.4 A further and less obvious area that could be
affected is the user charges. Where ATS providers charge a
fee for services provided to flights in their area, flight
operators with ASASICDTI-equipped aircraft may claim
that they should be charged a reduced fee because their
flight crews can provide their own separation. The
cumulative effect of this potential loss of revenue could
significantly affect corporatized ATS providers and shauld
therefore be considered at the early stages of an ASAS
concept implementation.
8.6 Developments in flight deck technology will

continue to drive changes in ATM operational concepts.
When developing and implementing ATM systems and
procedures, consideration should be given to the fu~ure
incorporation of such changes. More importantly, those
involved in the development of ATM operational concepts
should weigh whether a concept should fit the technology
or the technology should support the concept.
Chapter 9
SOURCES FOR ADDITIONAL INFORMATION

Postal addresses
For more information on topics discussed in this manual,
the following addresses are suggested:
Eurocontrol
96 Rue de la Fus&
B-1130 Bmsseis
Belgium
Federal Aviation Administration
800 Independence Avenue SW
Washington, DC 20591
United States of America
generic addresses for accessing the sites are reproduced

here. Most websites contain menu structures for subsequent
navigation through the available information. Furthermore,
several of the listed agencies offer the option of ordering
documentation (in electronic or conventional format) via
the Internet
Air Services Australia
www.airservices.gov.au
Airways Corporation
New Zealand
www.airways.co.nz
Cargo Airlines Association www.ads-b.com

RTCk Inc.
1140 Connecticut Ave., NW,Suite 1020
Washington, DC 20036
United States of America
CD-ROM
The FAA document Human Factors in the Design and
Evaluation of Air Trafjc Control Systems (Cardosi and
Murphy. 1995) is available on CD-ROMfrom the National
Technical Information Service, Springfield, Virginia 22161,
United States of America.
Internet addresses
An increasing amount of information on topics related to

CNS1P;IU systems implementation is available on the
Internet. Since providers of such information sometimes
modify the internal structure of their websites, only the
Eumcontrol (main menu)
www.eurocontrol.be
Eurocontrol
(Research and
Development)
www.eurocontrol.fr
FAA Human Factors
www.hf.faa.gov
FAA Human Factors

Design Guide
www.tc.faa.gov
IATA
www.iata.org
ICAO
www.icao.int
North European
ADS-B Network
www.ifv.se
RTCA
www.rtcaorg
SAE
www.sae.org

9758 FFHH en ATM PDF

Uploaded by

Copyright:

Available Formats

9758 FFHH en ATM PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

9758 FFHH en ATM PDF

Uploaded by

Copyright:

Available Formats

Human Factors guidelines

for air traffic

FIRST EDITION - 2000

RECORD OF AMENDMENTS AND CORRIGENDA

Chapter 5, 5.1.1.3, and in Amex 11, Chapter 2, 2.22.1.1,

The safety of civil aviation is the major objective of the

Furthermore, at the ICAO World-wide CNSfATM Systems

This was recognized by the ICAO Assembly, which in 1986

In order to maximize safety and cost-effectiveness of

'TO improve safety in aviation by making States more

The Recommendation in Annex 10, Volume IV, Chapter 2,

The time to address Human Factors issues is during

Hurna~zFactors guidelinesfor air trajjic management (ATM) system

Table F-1. ATS-related ICAO Human Factors SAWS

Part and chapter

Paragraph and text of the Standard or

Air traffic controller licence

Human Performance and limitations

d) human performance and limitations

Chapter 5. Aeronautic31 Mobile

5.1.1.3 Recornmendation.- In all

2.2.1 Recommendation.- Human

- Air Traffic Services

The target audience for the manual consists of two main

The development, acquisition and implementation of an

Note I.- In several Stares the provision of air trafic

Chapter 1 contains background information from

Chapter 3 provides a description of external data link

provision of ATS. This impact on the development and

organizations that will acquire and

Sources for further information are presented in

Chapter 1 Incorporating Human Factors

Chapter 2. Three essential concepts .......... 2-1

Chapter 3 Data link infrastructure and

The Human-Machine interface

Input devices ........................

Appendix 2 to Chapter 4 -- Operational

Chapter 6 Preparing for change

Chapter 7. Standard operating procedures

Human Facfors guidelines for air trafficmana~ernenr( A T M )xysre~ns

7.3 Harmonization of standard operating

Chapter 8 New flight deck technology ........ 8-1

Area control centre

Controller-pilot data link

Automatic dependent surveillance

Data link control -and display unit

Automatic dependent surveillance

Engine indication and crew alerting

ATS facilities notification

Organisation for the Safety of Air

ATS interfacility data

Federal Aviation Administration

Airborne situational awareness

Future Air Navigation System

Aeronautical Radio, Incorporated

Flight data processing system

Airborne separation assurance

Flight data recorder

Flight information region