european organisation for the safety of air - free home page

EUROPEAN ORGANISATIONFOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL EXPERIMENTAL CENTRE

A Human-Machine Interface ReferenceSystem for EnRoute Air Traffic Control

EEC Report No. 292 : EEC Task AT66EATCHIP Task DPS.ET1.ST07

Approved for publicationby Head of Division B2

Issued : December 1995

The information contained in this document is the property of the EUROCONTROL Agency and nopart should be reproduced in any form without the Agency’s permission. It does not necessarily

represent the official policy of the Agency.

INTENTIONALLY LEFT BLANK

DOCUMENTATION PAGE

ReferenceEEC Report No. 292

Security ClassificationUnclassified

Originator

EEC Division B2

Originator (Corporate author) Name/LocationEUROCONTROL Experimental CentreBP15 91222 Brétigny-sur-Orge CEDEXFRANCETelephone: (33 -1) 69 88 75 00

Sponsor

EUROCONTROLDirectorate of EATCHIP Development

Sponsor Contract Authority) Name/LocationEUROCONTROL96 Rue de la FuséeB-1130 BRUXELLESBELGIUMTelephone: (32 - 2) 729 90 11

Title :A Human-Machine Interface Reference System for EnRoute Air Traffic ControlAuthorsAlistair JacksonDr IsabellePichancourt

Date

12/95

Pages

164

Figs Ref.

36

Appendices

4

EATCHIP Task

DPS.ET1.ST07

EEC Task No.

AT66

Task No. Sponsor

AT66

Period

March/Nov 95Distribution Statement :

(a) Controlled by : Head B2(b) Special Limitations (if any) : None(c) Copy to NTIS : Yes

Descriptors (keywords) :r Traffic Control (ATC), Graphical Interaction, Colour displays, Input Definition, Windows, ATC Tools,

Human Factors Design Principles, PHARE, ODID, HMI (MMI, HCI, CHI).

Abstract :is Report provides a specification of a Graphical Human-Machine Interface for a Planner Tactical

Controller Working Position.

e specification has evolved from the working position defined for the Reference Organisation ofPHARE (Programme for the Harmonisation of Air Traffic Management Research inEUROCONTROL) Demonstrator One, which was in turn based on ODID IV.

rovides definition of input primitives for interaction, window management, integration of first generationcontroller support tools and an integrated rationâle for the use of colour.

This document has been collated by mechanical means. Should there be missing pages, pleasereport to:

Publications Office

EUROCONTROL EXPERIMENTAL CENTRE

B.P. 15

91222 - BRETIGNY-SUR-ORGE CEDEX

France

ACKNOWLEDGEMENTS

Many people have contributed to the contents and the production of this report. Theauthors would like to thank the ODID Group and the project Teams of ODID III and IV, aswell as those who conducted and participated in the ODID IVbis, for a vast amount ofinformation and much helpful advice. The PHARE GHMI Group provided support andessential critical input and the PHARE PD1 Management and Implementation team basedat DRA(Malvern) contributed at all levels from concept to realisation. Finally, we wouldlike to thank our many colleagues at the Experimental Centre who have tolerated,supported and even shared-in our less than orthodox working methods. Daniel Tassetdeserves a special mention for his contributions to the revision of Chapter 4 as do ourproof readers whose endurance cannot fail to impress.

AJ & IP

“I can’t understand how all these people can spend so much time standing around onhill. Hills are for running on anyway”

- Old HMI Designer’s Proverb

EEC Report 292 An HMI Reference System for EnRoute ControlAuthors: Alistair Jackson and Isabelle Pichancourt Issued: December 1995

ContentsVersion: 1.0 i

Contents

Contents .................................................................................................................. i

Glossary of Terms and Acronyms ..................................................................................... vii

Chapter 1 Introduction and Executive Summary

1.1 Purpose .....................................................................................................................1

1.2 Derivation of the Current Specification ...................................................................2

1.3 Contents of this Document and How to Read Them. ..............................................2

1.4 How to Use this Document.......................................................................................4

Notes on Chapter 1 ...................................................................................................................5

Chapter 2 Input Events and Interaction Model

2.1 Introduction...............................................................................................................1

2.2 Terminology..............................................................................................................1

2.3 Input Events ..............................................................................................................2

2.4 Input Actions ............................................................................................................2

2.5 Selection Model ........................................................................................................3

2.6 Priorities in Direct Manipulation Interfaces ............................................................4

2.7 Alternative Input Devices.........................................................................................6

2.8 Use of Multiple Mouse Buttons ...............................................................................6

Notes on Chapter 2 ...................................................................................................................9

Chapter 3 General Display Characteristics and Window Management

3.1 Introduction...............................................................................................................1

3.2 Terminology and Principal Concepts.......................................................................1

3.3 Physical Characteristics of Displays.....................................................................2

Visual Characteristics...............................................................................................2

Interaction Characteristics ........................................................................................2

3.4 Principal Elements of the Visual Environment ...................................................3

The Background Environment .................................................................................4

The Window Elements .............................................................................................5

Cursors ......................................................................................................................7

System Message Windows/System Dialogue Boxes ...............................................9


ContentsVersion: 1.0 ii

3.5 Implementation of Window Management ...........................................................10

Repositioning............................................................................................................10

Re-Sizing ..................................................................................................................11

Scrolling and Panning ..............................................................................................12

Zoom.........................................................................................................................13

Iconification ..............................................................................................................13

3.6 General Toolbox......................................................................................................14

General......................................................................................................................14

Parking Rank ............................................................................................................15

Clock.........................................................................................................................16

User Preferences .......................................................................................................17

‘Flexibility’ Support .................................................................................................20

Notes on Chapter 3 ...................................................................................................................22

Chapter 4 Specification of the Radar Plan View Display of the Reference GHMI

4.1 Introduction...............................................................................................................1

4.2 Main Elements of the Radar Plan View Display .....................................................2

4.3 Window Initialisation and Attributes...................................................................3

Initialisation ..............................................................................................................3

Attributes ..................................................................................................................3

4.4 Toolset ......................................................................................................................4

Tools .........................................................................................................................4

Zoom Function..........................................................................................................5

Height Filter ..............................................................................................................6

Radar Pre-set Selector ..............................................................................................7

Mapset Tool (Map Menu Window) .........................................................................7

Label Overlap ...........................................................................................................10

Speed Vector-Track History.....................................................................................11

The Modes Menu (Access to the Bearing and Distance tool + Tracker LinkTool)..........................................................................................................................12

Operation of the Range and Bearing Tool ...............................................................12

Operation of the Tracker Link Tool .........................................................................13

The Label Menu........................................................................................................14

4.5 Window Contents ...................................................................................................15

General......................................................................................................................15

The Background ATC Airspace Map.......................................................................15

4.6 Class of Aircraft: The ODID Task Related Presentation .................................16


ContentsVersion: 1.0 iii

General.....................................................................................................................17

Description of Encoded Task States ........................................................................17

Coordination .............................................................................................................19

Urgency/Warning Conditions...................................................................................19

Short Term Conflict Alert (STCA) ................................................................19

Warning Conditions .......................................................................................20

4.7 Aircraft Track and General Characteristics of Labels ......................................21

Main Elements of Aircraft Track .............................................................................21

The Different Forms of the Radar Label ..................................................................22

The Selected Radar Label Form.....................................................................22

Standard Form................................................................................................23

Extended Radar Label Form ..........................................................................24

Minimum Form(s) ..........................................................................................24

Key to Abbreviations for Radar Label Field Descriptions.......................................26

Label Structures For the different Label States........................................................26

The Extended Flight Label Window (ELW) ............................................................27

Minimum Information Display.................................................................................29

4.8 Interaction with the Radar Label and Track Symbology ..................................30

General Comments ...................................................................................................30

The Callsign (CALLSIGN) ......................................................................................30

Actual Flight Level (AFL) ........................................................................................31

Cleared Flight Level (CFL/PEL). (Planned Entry level before Assumptionof Control).................................................................................................................31

Exit Flight Level (XFL) ............................................................................................32

Exit Point of the Sector (XPT) .................................................................................32

Assigned Heading (ahdg) .........................................................................................32

Assigned Rate of Change of Climb or Descent (arc) (if implemented) ..................33

Assigned Speed (asp) (input of a speed restriction) ................................................33

Interaction with the Radar Position Symbol - The Elastic Vector Functionand Mode (EVM)......................................................................................................33

Dynamic Flight Leg Mode/Function (DFL) .............................................................36

4.9 Callsign Menu .........................................................................................................36

General Characteristics.............................................................................................36

The ASSUME Option...............................................................................................38

The TRANSFER Option ..........................................................................................38

The HANDOVER Option ........................................................................................38

The RELEASE Option .............................................................................................39


ContentsVersion: 1.0 iv

The FORCED ACT ..................................................................................................39

The SKIP Option ......................................................................................................39

SUMMARY: Availability of Callsign Menu Items .................................................40

Cursor Defaults.........................................................................................................41

4.10 Flight Level Menu Window (FLMW) ..................................................................42

Range of Applications ..............................................................................................42

General Description of the FLMW...........................................................................42

4.11 Waypoint Menu Window (WMW) .......................................................................44


Description of the WMW. ........................................................................................44

4.12 Speed Input Menu Window (SMW) .....................................................................46


Description of the SMW...........................................................................................46

4.13 Sector Inbound List ................................................................................................47


Description of the SIL ..............................................................................................48

4.14 Message Windows...................................................................................................49


Description of the MESSAGE WINDOWS.............................................................50

Notes on Chapter 4 ...................................................................................................................52

Chapter 5 Specification of the Auxillary Flight Information Display Elements ofthe REFGHMI

5.1 Introduction...............................................................................................................1

5.2 Medium Term Conflict Information: It’s availability and display. ........................2

5.3 The Conflict Risk Display ......................................................................................4


Attributes of the CRD...............................................................................................4

Contents of the CRD Window .................................................................................5

Interaction with the CRD Window...........................................................................6

Possible Enhancements to the CRD Window..........................................................7

5.4 The Vertical Aid Window (VAW) ........................................................................7


Status of VAW Development...................................................................................8

Attributes of the VAW..............................................................................................9

Contents of the VAW Window ................................................................................9

Interaction with the VAW Window .........................................................................12


ContentsVersion: 1.0 v

5.5 The Conflict Zoom Window (CZW) .....................................................................13


Attributes of the CZW..............................................................................................13

Contents of the CZW Window.................................................................................14

Interaction with the CZW Window..........................................................................15

Notes on Chapter 5 ...................................................................................................................16

Chapter 6 Human Factors Assumptions, Principles and Models Underlying theREFGHMI

6.1 Introduction.............................................................................................................1

Purpose .....................................................................................................................1

Target Readership and Contents ..............................................................................1

6.2 Design Objectives in the Re-Modelling of the ODID IV Interface....................2

Design ‘Tactics’........................................................................................................2

Design ‘Strategies’ ...................................................................................................3

Separation Of Procedures And Interface Mechanisms .................................3

Initiative For Action Stays With The Controller. ..........................................3

Data Access and Flight Database Model .......................................................4

6.3 Automation Philosophy: the ‘Role of Man’ and its implications.....................4

Background...............................................................................................................4

Transitions in the Role of the Interface....................................................................4

Interface Style and Function.....................................................................................6

6.4 The Rationâle for the Use of Colour in the REFGHMI.....................................7

The Problem (Historically) .......................................................................................7

Two Different Approaches .......................................................................................8

Interim NATS Standard .................................................................................8

ODID Approach .............................................................................................8

Integration of the Approaches (PHARE PD1) ..............................................8

Critique and Issues in Exploiting the Two Schemes ...............................................9

Conflict Resolution: Integrating the approaches.....................................................10

6.5 A Simple Model of Action at the Interface..........................................................11

Controller Activity as Multi-Threaded Tasking.......................................................11

Supervisory Scanning and Task Management .........................................................13

How the Model is Reflected in the REFGHMI........................................................15

Explicit Design to Support Monitoring .........................................................15

Designing for Interruptability ........................................................................15

Status and Value of the Model.......................................................................16


ContentsVersion: 1.0 vi

6.6 ... and a ‘Last Word’ about what has been left out.............................................16

What has been left out ..............................................................................................16

Notes on Section 6 ....................................................................................................................18

References

Traduction en français de l’ Introduction et de l’ “Executive Summary”

1.1 Objectif .....................................................................................................................1

1.2 Origines de la Spécification actuelle........................................................................2

1.3 Contenu du Document et Comment le lire. .............................................................3

1.4 Comment lire ce document.......................................................................................4

Notes sur l' Introduction et de l' "Executive Summary" (Chapitre 1)......................................4

Appendices

Appendix 1: Prioritisation of Display Layers ..........................................................................1

Appendix 2: Graphical Appearance of Supportive Window Structures.................................1

A2.1 General Principles .................................................................................................1

A2.2 Dimensions ............................................................................................................1

A2.3 Specifications of Palette for Window Elements ...................................................1

Appendix 3: Suggested Color Palettes ....................................................................................1

Appendix 4: Master Colour Table for EFGHMI .....................................................................1


ContentsVersion: 1.0 vii

Glossary of Terms and AcronymsAB The Action Button used to make operational inputs in ODID IV

and operational and window management inputs in PD1 and theREFGHMI

ABI or ADV Advanced Boundary Information (Formerly called ABI in ODID forAdvanced Boundary Information, it is now the state when thePlanning authority has been transferred out by the previous sectormaking it availble in the current sector)

A/C or a/c Aircraft

ADVHMI ADVanced Human Machine Interface the HMI for the AdvancedOrganisations of PHARE Demonstration 1

AFL Actual Flight Level, the Mode C level of an aircraft on the RPVD

ahdg Aircraft heading, abbreviation and field in aircraft radar label

Aircraft menu The menu made available by clicking mouse button B1 on thecallsign of an aircraft anywhere on the ODID IV, PD1 orREFGHMI interfaces.

API Applications Programme Interface, a pre-defined interface whichcan be used to connect a software module to a larger system.

asp Assigned speed, abbreviation and field in aircraft radar label

ATC Air Traffic Control

ATM Air Traffic Manangement

BEAC Beacon

CFL Cleared Flight Level, abbreviation and field in aircraft radar label

COPS Common Operational Performance Specifications

CP Conflict Probe, one of the PHARE Advanced Tools

CRD Conflict Risk Display

CZW Conflict Zoom Window

CWP Controller Working Position

D Distance of displacement/movement of a pointing device

DEPA Departure Airfield, abbreviation and field in aircraft radar label

DEST Destination Airfield, abbreviation and field in aircraft radar label

EATCHIP European Air Traffic Control Harmonisation and ImplementationProgramme

EVM Elastic Vector Mode, used to refer to both the tool and the mode

ELW Extended Radar Label Window

ETD Estimated Time of Departure

FLEX The ‘Flexibility Option’ in the General Toolbox


ContentsVersion: 1.0 viii

FLMW Flight Level Menu Window

FPM Flight Path Monitor, one of the PHARE Advanced Tools

Freq Frequency, as used in Radio Telephony systems of Air TrafficControl

GHMI Ground Human Machine Interface: a term coined within thePHARE programme. Distinct from the AHMI, the AirborneHuman Machine Interface.

HAW Horizontal Aid Window

HCI Human Computer Interface/Interaction

HMI Human Machine Interface/Interaction

IB The Information Button of ODID IV, PD1 and this REFGHMI

IPRT Internal Processing Response Time

ISA Instantaneous Self-Assesment, a Subjective Workload Assessmenttechnique developed by the UK, Civil Aviation Authority

MT Movement Time: the time to displace a pointing device, mouse,finger, etc.

NATS National Air Traffic Services, responsible for the provision of AirTraffic Control services in the United Kingdom

NERC New En-Route Centre, UK

NS Next Sector, abbreviation and field in aircraft radar label.

ODID Operational Display and Input Developments, an internationalgroup, organised by EUROCONTROL, which was responsable forthe ODID series of simulations at the EUROCONTROLExperimental Centre, Brètigny.

ORG Organisation, an ‘experimental condition’ in a real-time simulation

PATs PHARE Advanced Tools(et)

PC Planning Controller (Sometimes called PLC in ODID, Organique)

PD/1 PHARE Demonstrator 1. There are two other PHAREDemonstrators, PD2 and PD3.

PHARE Programme for Harmonised Air traffic Management Research inEUROCONTROL

PREF The Preference Set Window option in the General Toolbox

PSW Preference Set Window

REFGHMI Reference Ground Human Machine Interface, the subject of thisdocument

RFL Requested Flight Level, abbreviation and field in the extendedradar label window

RGB Red, Green, Blue. A common means of describing colour inCathode Ray Tube based display systems in terms of the three‘primary’ phosphor colours.

RPVD Radar Plan View Display, the principal radar image


ContentsVersion: 1.0 ix

SDBs System Dialogue Boxes

SIMs System Information Messages

SIL Sector Inbound List

Speed Vector A line drawn in front of the aircraft symbol on the radar displayindicating the aircraft’s velocity vector over a parametrised timeperiod, eg. 1 minutes flight.

SURT Screen Update Response Time

SMW Speed Input Menu Window

sp Ground speed, abbreviation and field in aircraft radar label

T1...n Times at waypoints (1 to n) listed in extended radar label window

TAS/tas True Air Speed

TC Tactical Controller, (Radar Controller, Executive Controller,Radariste)

TP Trajectory Probe, one of the PHARE Tools

Track History A means of indicating the evolution of a aircraft’s flight on theradar display by marking the aircraft’s position on previous radarupdates. Derives from the persistence of phosphors on earlyprimary radar displays.

TYPE Aircraft type, used in extended radar label window

VAW Vertical Aid Window

W Width of the target along the direction of approach of a pointingdevice.

w Wake vortex category, abbreviation and field in aircraft radar label

WMB Window Management Button of ODID IV

WMW Waypoint Menu Window

WP1...n Waypoints (1 to n) listed in extended radar label window

XFL eXit Flight Level, abbreviation and field in aircraft radar label

XPT eXit PoinT, abbreviation and field in aircraft radar label


Introduction and Executive SummaryVersion: 1.0 Chapter 1 - 1

Chapter 1

Introduction and Executive Summary

1.1 Purpose1.1.1 The report provides a description of a ‘state-of-the-art’ graphical

interface for en route air traffic control, based on a Planning Controller(PC), Tactical Controller (TC) partition. It describes the graphicalinterfaces necessary to support both the PC and the TC functions butmakes minimal assumptions concerning the nature of the hardwareemployed to realise the Controller Working Position (CWP), i.e. itassumes the availability of high resolution interactive graphics withoutspecifying the nature of the physical screens or software employed torealise the implementation. It is, however, suitable for implementationwithin the UNIX, X-window, 2000 x 2000 colour screen configurationwhich is currently accepted as the norm in Air Traffic Control Systemdevelopment. Some mechanisms are also provided to support instanceswhere the interface must be distributed over more than one displayscreen.

1.1.2 The specification is intended to provide a Reference Ground HumanMachine Interface (REFGHMI) which can be used as both ameasurement baseline and as a starting point for the development ofinterfaces exploring and exploiting the more advanced functionality madepossible by technical developments such as ground-air datalinks,improved trajectory prediction, multi-sector planning, etc. For thisreason, its functionality is based on ‘the best en route system that couldbe built now’. Consequently, it could also be used as a starting point forthe specification of an upgrade/harmonisation in HMI by individualnational authorities. (One way of approaching this document, is toconsider it as a first step in the production of an ATC Interface StyleGuide which could be used as the basis for other ATC interfaces.)

1.1.3 The emphasis of the system which is described is pragmatic. It seeks toprovide a sound basis of display principles and mechanisms, inputoperations, colour usage and interaction consistency which can beexpanded and modified in a transparent way to support the needs ofdifferent potential customers.

1.1.4 The specification represents a synthesis and reworking of design activitywhich has been conducted by the authors and many others over a numberof years (See §2 for a more detailed description of the origins of thespecification). As a result, most of the principles, mechanisms andimplementations described have been tried and tested in previous studies,evaluations.

1.2 Derivation of the REFGHMI Specification



1.2.1 Many activities and individuals have contributed to the evolution of thisspecification. The most immediate predecessor of the interface describedin this document is the Reference System Interface for the first PHARE1

Demonstrator. The specification for that interface was produced by theEUROCONTROL Experimental Centre, on behalf of, and under themonitoring of, the PHARE Ground Human Machine Interface (GHMI)Group2. The present document IS NOT the specification of the PD1Reference System GHMI. Rather it represents both a simplification andextension of the interface actually implemented in PD1, but one thatshares most of the essential functionalities, features and mechanisms.The interfaces implemented in PD1 are described in the relevant sectionsof [1].

1.2.2 The PHARE PD1 Reference Interface3 was in turn derived directly fromthe output of the ODID4 Group, in particular, that of the ODID III(Organisation 2) and ODID IV simulations in which severalEUROCONTROL Member States, but especially France, Switzerlandand Denmark were higly involved [2],[3]. These simulations, and thecontroller exposure that followed them, provided both the underlyingfunctionality and the experimental feedback and controller reactionwhich guided the human factors re-engineering used to turn theoperationally derived ODID concepts into a more consistent and errortolerant interface. The extensive documentation of ODID IV5 served asfoundation of the PD1 Reference Specification and of the presentdocument. The simulations themselves provided one of the mostthorough ‘prototyping’ assessments imaginable. Further, the ODID ‘Bis’demonstrations permitted exposure to a very wide variety of controllersfrom different national administrations allowing the re-engineering toreflect a wider variety of ATC cultures than usual.

1.2.3 In terms of Human Computer Interaction (HCI) principals, the majorsources of input have been the EATCHIP Guidelines Document [4],which summarises the lessons of ODID I, II, and III with a specificallyAir Traffic Control orientation, and the style guides associated withmainstream graphical interfaces [5], [6]. Finally, perhaps the clearest andmost fundamental guidance has come from the Hollan, Hutchinson andNorman’s classic paper on direct manipulation [7] and BruceTognazzini’s insightful and amusing book on interface design [8].Personal experience on the prototyping of Electronic Flight Strip Systemsand Graphical Interfaces for other experimental Controller WorkingPositions has also been very influential6. Chapter 6 provides a detailedoverview of the Human Factors philosophies, principles and practiceswhich underpinned the re-engineering process and our understanding ofthe present interface.

1.3 Contents of the Document1.3.1 The interface specification is divided into five main sections (Chapters 2-

6, respectively) and a number of Technical Appendices. The Chaptersare entitled as follows:

Chapter 2 Input Events and Interaction Model



Chapter 3 General Display Characteristics and Window Management

Chapter 4. Specification of the Radar Plan View Display Element of the Reference System Interface

Chapter 5 Specification of the Auxiliary Information Display Elements of the Reference System Interface

Chapter 6 Human Factors: Important Ideas, Principles and Models

1.3.2 The first two chapters deal with the form of the interface, its architectureand the primitive elements that can be pieced together to provide therequired functionality. This information is a prerequisite for thereference system interface but is also the foundation on which anyextension or modification of the interface must be constructed.

1.3.3 Chapters 4 and 5 provide detailed descriptions of the content,functionality, interactivity and appearance of the interface. The referencesystem interface contains four of the five major elements included inODID IV. These are:

• the Radar Plan View Display (PVD)

• the Conflict Risk Display (CRD)

• the Vertical Aid Window (VAW)

• the Conflict Zoom Window (CZW).

1.3.4 The missing element is the Horizontal Aid Window (HAW) which foundonly limited application in the context of ODID IV. Chapter 4 deals withthe Radar Display and all its supportive elements. Chapter 5 describesthe remaining displays.

1.3.5 Chapter 6 deals with Human Factors philosophies, principles andpractices that underpinned both the re-engineering process from theODID starting point and the subsequent attempts to create an interfacearchitecture suited to the current task and the future extensibility of theinterface.

1.3.6 The technical appendices and footnote are used in a complementary way.Number notes, located at the end of each Chapter, provide briefexpansions or explanations. Technical Appendices are used to providemore detailed explanations on particular topics and examples, data ortables too large for convenient insertion in the text. The TechnicalAppendices are:

Appendix 1: General Prioritisation of Display Layers in the Interface

Appendix 2: Graphical Appearance of Supportive Window Structures

Appendix 3: Suggested Colour Palettes

Appendix 4: Master Colour Table

1.4 How the Document should be Used



1.4.1 The document can be used in a number of ways. For those interested inthe interface specification itself, its operational functionality, or possibleimplementation as it stands, the text can be followed normally, withreference to the Notes and Appendices.

1.4.2 For those with an interest in the design of the interface (as opposed to itscontents) or those with a need to add or change the functionality of theinterface, Chapter 6 should be read FIRST. This should provide aframework for understanding the design decisions already made andsubsequently for provision of additional functionality.

1.4.3 It is anticipated that there may be revisions of this document as theREFGHMI evolves with time.



Notes on Chapter 1

1 Programme for Harmonisation of Air traffic management Research inEUROCONTROL.

2 The comments, critiques and suggestions of the PHARE GHMI group havecontributed considerably to clarifying the ideas expressed in the current document.

3 The interfaces for the advanced organisations of PHARE PD1, on the other hand,represent a significant augmentation of the the functionality of ODID IV.

4 Operational Display and Input Development Group. An international collaboration ofoperational authorities responsible for the conduct of four major simulations (ODID Ito IV) between 1986 and 1993. The first author served on the ODID Group 1989-93and the second author was responsible for the human factors measurement in ODIDIV.

5 The authors should like to express our sincere appreciation to the ODID Group formaking all their extensive documentation available and to the ODID IV Project team,especially (at CEE Brétigny) Bob Graham, Dave Young, Chris Brain and (atBrussels) Vic Day, Poul Jørgensen and Geoff Gasté for giving us so much access tothe system and answering our endless questions. Their patience, as they havewatched our modifications, has been highly commendable.

6 With Messrs Ball and Dean between 1988 and 1990 at DRA (M) under CAAsponsorship.


Input events and Interaction ModelVersion: 1.0 Chapter 2 - 1

Chapter 2

Input Events and Interaction Model

2.1 Introduction2.1.1 This chapter describes the general input requirements and characteristics of

the Reference GHMI (REFGHMI). These differ slightly from ODID but are asemployed in PHARE PD1. The input events described are amongst the mostfundamental building blocks of the interactive system. Together with theinteractive display objects defined in subsequent chapters, they constitute theprimitives from which all interactions are constructed.

2.1.2 Following definitions, the chapter provides coverage of three topics.

• a description of the basic input events to be recognised by thesystem, and the basic input actions to be employed bycontrollers.

• a description of the selection model to be employed in theinterfaces.

• a discussion of alternative input devices and theirimplementation.

2.1.3 In remainder of the description, unless otherwise noted, the input device isassumed to be a three button mouse.

2.2 Terminology2.2.1 In the discussion, the following terminology is employed.

2.2.2 Direct Manipulation. In a true direct manipulation interface, inputs arecreated by manipulating outputs already made by the system. In the case ofGraphical Direct Manipulation, this means that the user composes inputs byperforming simple operations on objects already present on the displaysurfaces of the system.

2.2.3 Input Events are those inputs which the system software is capable ofdistinguishing.

2.2.4 Input Actions are the input events or sequences of input events which theuser of the interface distinguishes.

2.2.5 The set of input actions and input events need not be identical although theremust always be a consistent mapping between them.

2.2.6 Pointing Device. The following definition is based on the one contained inthe OSF/Motif Style Guide [5]. A pointing device;

• lets the user move a pointer around on the screen

• allows the user a means of activating the object under thepointer



• allows the user to directly manipulate screen objects

2.2.7 Selection Model. A selection model describes the mechanisms by whichinterface objects or actions are selected, in terms of input events and theconsequences which result from them.

2.3 Input Events2.3.1 The interface will have to recognise the input events described below. Note

that the description of events includes parameters that should be available tothe system. Time parameters are necessarily associated with some of theseevents for the purposes of their function. This requirement is separate fromany time parameters that may be required for the purposes of logginginteraction events for experimental analysis. In fact, it is likely that, inexperimental and simulation contexts, all input events will require a timeparameter for logging purposes.

2.3.2 The system should behave as if 'continuously aware' of the X.Y co-ordinates ofthe pointing device.

2.3.3 The system should be aware of the logical state of any button associated withthe pointing device. Buttons are assumed to have two states for inputpurposes i.e. 'UP' and 'DOWN'. Parameters are button identity and state.

2.3.4 The system should be aware of any transition between button states.Parameters are button identity (ButtonID), Pointer Position and time oftransition. The system has to identify the following,

BUTTON DOWN (ButtonID, Pointer Position, Time)

BUTTON UP (ButtonID, Pointer Position, Time)

2.3.5 It will be necessary to know which 'screen object' the cursor lies within at thetime of the button transitions. The means of implementation is immaterial butit may imply the addition of an ‘object’ parameter to the above inputs. NOTEthat under some circumstances, this might also imply information on theordering of objects within the layers of the screen priority stack correspondingto that point on the display.

2.3.6 It will also be necessary to detect that the pointing cursor has entered withinthe area of target objects such as screen buttons or menu items. This may berealised by a mechanism for detection of BOUNDARY CROSSING or byother techniques as appropriate.

2.4 Input Actions2.4.1 Users should normally be aware of a number of input possibilities at the

interface. These correspond to the system image that the designer is trying tocreate and they should also be the terms used in any set of instructionalmaterials prepared for guidance in the use of the interface.

2.4.2 The principal input actions employed in mouse driven graphical interfaces are:

a) POINT in which the cursor is moved until it is located withinthe boundaries of a target screen object. POINT makes animplicit selection. This mechanism is employed in the



REFGHMI (e.g. the change in the form of aircraft labelsdescribed in §4.7.1.4)

b) CLICK in which a mouse button is pressed and released inrapid sequence (i.e. the BUTTON DOWN and BUTTON UPevents occur within some time parameter, the CLICK Interval.This parameter should be readily accessible for adjustment,perhaps as part of the user preferences set-up). CLICK makesan explicit selection. CLICK is the normal selectionmechanism in the REFGHMI.

c) PRESS-HOLD-RELEASE in which a mouse button isdepressed and the system produces some form of response,(e.g. the extended label function described in §4.7.5) which is‘undone’ when the button is released. This function isemployed frequently for the ‘quick-look’ information functionin the REFGHMI. It is usually referred to in the shortenedform, ‘PRESS AND HOLD’.

d) PRESS-MOVE-RELEASE or PRESS-SELECT-RELEASE inwhich a mouse button is depressed, a pop-up menu appears,the cursor is moved within the menu to a selection field andthe button is released resulting in selection of the item. Thismechanism is NOT employed in the REFGHMI.

e) PRESS-DRAG-RELEASE in which a mouse button isdepressed while the pointing cursor is positioned on amovable screen object. The pointing device is then moved toa new position DRAGGING THE OBJECT, OR AWIREFRAME REPRESENTATION OF THE OBJECT,WITH IT. When the button is released, the screen object is re-drawn at the new location. This function is employed widelyin the REFGHMI. It is usually referred to as DRAGGING orPRESS and DRAG.

f) DOUBLE, and TRIPLE CLICKS, consist of CLICKsequences that occur within a time parameter. It is not thecurrent intention to make use of this capability within theREFGHMI.

2.5 Selection Model2.5.1 A number of selection mechanisms could be employed in the REFGHMI.

Initially, it is suggested that a comparatively 'safe'1 strategy be adopted. This isexplained as follows.

2.5.2 WINDOW SELECTION is implicit, based on mouse position, i.e. there is noneed to make a specific input to designate any particular window as the locusfor further input as is required on the Macintosh interface, for example. Thisis made possible since a baseline derived from ODID has no need for any formof keyboard input. The need to define a predictable focus for keyboard inputis normally the source of the requirement for explicit selection. In theREFGHMI environment, the focus of all input is the current mouse position.

2.5.3 Inputs can be made through two types of screen objects.



a) Draggable Objects are objects on which the PRESS-DRAG-RELEASE mechanism can operate. In the case of theReference System Interface these are almost all associatedwith window management2. The principal exception is relatedto manual resolution of label overlap on the radar display.

b) Selectable Objects are a more general class of objects whichpermit input to the system (i.e. a draggable object is a type ofselectable object). When a mouse button is operated with thecursor located on the visual image of a selectable object,modifications in display and system state can occur. Therewill be a wide variety of classes of selectable objects withinthe baseline system ranging from toggle switches, that changeparameter settings, active fields within aircraft labels on theradar display that produce pop-up menus or trigger additionalinformation display, symbols that produce tools, draggableobjects, etc.

2.5.4 Selectable objects will normally be explicitly selected with a single CLICKalthough it should be noted that implicit selection may be used to providehighlighting feedback to clearly indicate the particular screen object that willbe addressed by a subsequent explicit CLICK input.

2.6 Priorities in Direct Manipulation Interfaces2.6.1 From an engineering perspective, the priorities in a graphical interface may

seem counter-intuitive. They can be expressed quite simply.

RULE #1: INPUT PRIORITY

An initial response to user input should take priority over anyother activity at the interface.

2.6.2 This includes even such apparently insuperable priorities as updating of theradar display. The logic is simple. If the user’s focus of interaction is locatedat the input cursor, then that is where the priority of processing should be.They will notice a lag in response to their input. They will NOT notice a lagin the update of the radar display because they will not be looking at it. Whenthey are monitoring the radar display, they will not be making inputs andhence there will be no conflict in updating priority. It is for this reason thatany Macintosh or Windows programme begins with a mouse monitoring eventloop. The REFGHMI system must do effectively the same thing.

2.6.3 Although these priorities may seem somewhat strange to an external observerwatching controller activity at the interface, it is the responsiveness to the userperforming the task, which matters.

2.6.4 This requirement does not mean that all system activity has to stop while anyuser input sequence is followed to completion. It does mean that initialfeedback of the fact that an input has been made and parsed, must appear tooccur immediately, e.g. in less than 0.125sec. This may be little more than achange in state of the cursor to show that input is being processed. SomeIMPLICIT INPUTS such as highlighting of objects to provide feedback oncursor location may have to be processed even more quickly (within a fewscreen refresh cycles) to be useful. Figure 2.1 illustrates the sequence of times



involved for a very simple input such as the appearance of a ‘pop-up’ menuwhen a mouse button is depressed.

Cursorenters object

Object Highlights

if necessary

User Presses button

System gives local feedback

System completes requested

action

time

A B C D

Figure 2.1: The various time intervals associated with a simpleinput (such as ‘popping-up’ a menu).

RULE #2: FEEDBACK TO IMPLICIT INPUTS

Feedback to such inputs should be consistently less than 125milliseconds.

2.6.4 The figure illustrates the following sequence:

a) Interval A: The cursor enters a selectable target. In some, butnot all cases (e.g. a window slider), this requires immediate(Explicit)3 visual feedback. This type of feedback (interval A)must occur within a few refresh cycles of the screen or elsethe cursor will have moved on into another screen object.This corresponds to the Screen Update Response Time(SURT) described in [9, p2.29].

b) Interval B: This is the user response time required torecognise successful acquisition. In (implicit) cases wheresome form of explicit feed back to acquisition is not providedA+B becomes a single interval but, since the user has to makea more complex judgement A+B will be longer. Collectivelythe sum of A and B, for both explicit and implicit conditions,is often referred to as the target acquisition time.

c) Interval C: This is the critical interval discussed in §2.6.3.When the user makes some form of active input by changingthe state of a mouse button, some form of ‘immediate’acknowledgement of the input must be provided withinaround 125msecs. In cases where the input can be fullyprocessed within 125msec (i.e. interval C+D < 125msec), thesuccessful outcome of the resulting process will suffice -provided that there is a consequential change in the visualenvironment. In cases where the system requires longer,visual feedback, acknowledging the input and informing theuser of the delay, should be provided by a change in cursorformat to a ‘busy’ cursor within the 125msec time frame.

d) Interval D: When intermediate input feedback has beenprovided, interval D represents the balance of the time untilthe system completes processing initiated by the input. The



sum of C and D may be considered as the system responsetime to the user’s input. It corresponds to the InternalProcessing Response Time (IPRT) described in [9, p2.29].

2.6.5 The sequence in Figure 2.1 is extended for other types of input such asPRESS-DRAG-RELEASE but, in reality, this involves little more than acycling around the ‘C’ component while the cursor is repositioned and thenthe mouse button is released.

2.6.6 RULE #3: CONSISTENCY

Consistency of input response time is even more important thanthe absolute speed of response.

This is particularly true for the immediate feedback to inputs. If there isvariability in this response, it generally leads to high levels of frustration anddissatisfaction, as well as incorrect input sequences when users repeat inputsthat have not been acknowledged. The resulting queued events make theinterface perform in apparently unpredictable ways destroying the illusion ofdirect manipulation.

2.7 Alternative Input Devices2.7.1 The decision to base the reference interface on ODID implies an interface

based on a single pointing device with the possibility of three related inputbuttons (a three button mouse). There is no need, within the reference system,as based on an ODID interface, for any additional input capability, other thanthe telecommunications requirements.

2.7.2 As a general comment, it is possible to achieve a systematic mapping in inputlogic between a touch screen and a single button mouse but mice withadditional buttons can only be emulated with a track ball and associatedbuttons. Use of the touch screen would require a secondary button pad.Consequently, while the facility may support these additional devices, there isno proposal to exploit them for the REFGHMI.

2.7.3 As noted earlier, there is no need to exclude the possibility of employing otherinput devices in association with extension of the functionality of theREFGHMI. Such devices could also be used to provide alternative inputmethods provided consistency and input logic are respected.

2.8 Use of Multiple Mouse Buttons2.8.1 The ODID III simulation employed a two button mouse [10] and ODID IV

[11] used a three button mouse. It is assumed that a three button mouse isavailable for PD1. Please note the comments in §2.7.2, above.

2.8.2 In ODID III the buttons were employed as follows [10 Annex 1, §1.1]:

Left Button (ODID B1)4 to select the display of data. The display of datacould be either permanent or temporary. Permanent display was achieved byCLICKING B1 to display data, and then repeating the action to remove it fromthe display. Temporary display was achieved by PRESSING B1 and holdingit down. Data was displayed only while the button was held down. It wasremoved when the button was released.



Right Button (ODID B2) was used to enter data into the system.

2.8.3 In ODID IV the buttons were described and employed as follows:

Left Button. The left button was known as the INFORMATION BUTTON(IB). The IB displayed or deleted information, or closed windows.

Middle Button This button was called the ACTION BUTTON (AB). TheAB initiated dialogues and input new information.

Right Button This button was described as the WINDOW MANAGEMENTBUTTON (WMB). The WMB was used to move, size, swap and iconisewindows. However, panning and zooming were viewed as task activities andeffected by using the AB.

2.8.4 In conjunction with the button allocation a logic was applied to the form ofinput action such that a CLICK implied a complete action. A PRESS andHOLD (Button Down, and keep down) provided a ’quick-look’ capability withthe additional information disappearing when the button was released.

2.8.5 The button logic employed in both these simulations was based on a logicalpartitioning of the task activity into different work activities, gettinginformation, inputting data and manipulating windows. This distinctionrequires comparatively ’high- level’ cognitive decisions based on the nature ofintentions. In direct manipulation it is normal the objective to try to ’relegate’the use of the mouse to a much ’lower’ level, usually based on a distinction atthe input action level. Thus, for example, the Motif Style Guide [5] goes sofar as to specify that certain input events be bound to specific buttons. TheMotif BSelect function is bound to B1. The Motif BDrag function is bound toB2, etc. Such directness is an objective of the button allocations for theREFGHMI.

RULE #4 USER DEMAND

The user should not have to decide whether the next input isATC task or window management related before making it.

2.8.6 Other streamlining is possible and appropriate. Observation and experiencewith using the ODID IV interface suggested that there was an unnecessarilyhigh risk of re-sizing windows when re-positioning the window was theintention5. Further, suggestions that a ’Lock’ function should be madeavailable once the user has established a satisfactory layout emphasise that theexisting mechanisms may not have been adequate. In this context, it isproposed that the window management functions will be removed from adedicated button and simpler, on-screen mechanisms such as name bars andre-sizing handles will provide the same functions via the use of an actionbutton.

2.8.7 Similarly, the attribution of action and information functions to B2 and B1 willbe modified. The action button function will be assigned to B1 on the basisthat the most time critical and the most repetitive functions should be assignedto the more dextrous index finger6. This is a similar rationale to that whichunderlies the Motif recommendation. As far as can be established, the originalbutton assignment in ODID III was arbitrary. It was later followed in ODIDIV since, at that time, there was no perceived need for change.

2.8.8 Thus the button convention in the REFGHMI will be:



B1 (Left) All normal inputs. Essentially this includes all the functions of theAction Button in ODID IV, plus the operations necessary for windowmanagement.

B2 (Middle) This button is reserved for a single specialist function: the‘flipping’ of the main radar display to the top of the viewing stack to provide aclearer view of the traffic situation

B3 (Right) The functions of the Information Button in ODID IV, i.e. displayor removal of additional information.

2.8.9 For left handed users the B1 functions should be interchangeable with B3.



Notes on Chapter 2

1 In this context ’safe’ means that the trade-off favours resistance to error rather thanseeking to optimise speed of selection.

2 The 'rubber band’ heading vector may also be considered as an exception. However,it is only available after a 'selection' operation.

3 A little care is necessary here. As a seeming contradiction, explicit feedback isgenerally the consequence of implicit input, i.e. the user does not have to make abutton press, the placement of the cursor is sufficient. It is in just these cases thatimmediate feedback has to be provided so that the user is informed that the system isaware of the user’s activity.

4 In the REFGHMI specification activity a similar naming convention will be applied tothe mouse buttons which will be numbered from left to right; thus the LEFT button isB1, the MIDDLE Button is B2 and the RIGHT button is B3. Paragraphs 2.8.2 and2.8.3 employ the terminology of the original simulations. Elsewhere the B1, B2, B3convention is employed.

5 The ODID IV window management mechanism distinguishes between the user'sintention to re-size a window and the intention to move a window on the basis of thecursor's position within the target window at the time of B3 operation. Themechanism is similar to the 9 square 'noughts and crosses’ wire frame used in early XWindow managers.

6 This same notion has been advanced to support the original ODID button allocationon the basis that PCs would be asking for information more frequently than theywould be making inputs and hence should use their index finger for the function.One response to this would be to suggest that such frequent requests for additionalinformation imply that the basic information available on the PC’s displays might notbe adequate. Subsequent analysis of ODID IV data indicated that the action buttonwas used almost twice as frequently as the info button justifying the changesdescribed in §2.8.7.


Display and WindowsVersion: 1.0 Chapter 3 - 1

Chapter 3

General Display Characteristics andWindow Management

3.1 Introduction3.1.1 This chapter describes the general display requirements for the Reference

GHMI (REFGHMI)

3.1.2 It will describe:

• the physical characteristics of the displays required both forviewing and interaction via a pointing device

• the principal elements of the visual environment

• the mechanisms of user control of the visual environment and'window management'

• the rationale for the use of colour and symbology.

3.1.3 In the description, unless otherwise noted, the input device is assumed to be athree button mouse.

3.2 Terminology and Principal Concepts3.2.1 Terminology relevant to input processes and direct manipulation is provided in

Ch2.2. In the discussion which follows additional terminology is employed.

3.2.2 Screen Priority: The graphical display component of a direct manipulationinterface often creates a partial illusion of depth into the screen by presentingobjects as if partially obscured by others. Some objects appear to lie on-top ofothers, masking some of the surface area that these objects would otherwisepresent. Those objects that appear nearest the user are said to have the highestscreen priority. Those seemingly furthest away have the lowest priority.

3.2.3 Viewing Distance (d): Viewing distance is defined as the physical distancebetween the a visual stimulus (e.g. the surface of the computer screen) and thelens of the observer's eye.

3.2.4 Visual Angle (a): Since the size of the image that a visual stimulus presentsto the retina of the human is eye is not simply a function of its size but is also afunction of the viewing distance, stimuli are conventionally described in termsof the visual angle. This method of description is stable over both stimuli andobservers. It is described in detail in [12, §1.240] but in summary:

tan α = S/d

where α is the visual angle subtended by the target stimulus at the eye, S is thephysical size of the stimulus and d is the viewing distance. This convention isused to calculate all screen sizes in this document.



3.3 Physical Characteristics of Displays

3.3.1 Visual Characteristics

3.3.1.1 The current requirements of an ODID HMI are approximately 4 megapixels ofdisplay per controller working position. A similar display capacity is assumedfor the REFGHMI. It is more difficult to quantify colour requirements.Although the ODID IV system only employs about 24 colours at any one time,these have to be chosen from a rather large palette to establish shadings withappropriate characteristics. The present level of colour selection employs atleast 10 shades of grey, and 10 shades of green. A potentially importantobservation from ODID IV is that, while the colour schemes employed seemvery subdued in brightness and contrast to observers and visitors (includingHuman Factors observers), the controllers find the displays both practical andrestful to use over periods of time of around 90 minutes. This suggests thatthere may be very different criteria for brief and prolonged exposure. Fullerdiscussion of the principles underlying the use of colour in the REFGHMI isprovided in Chapter 6.

3.3.1.2 Assuming the viewing distance at the Controller console lies between 0.6 and0.66 metres, the MINIMUM size of any font employed should be 4mm (visualangle of 21.8" at 0.63m). This corresponds to character 13 pixels high1.Larger fonts are almost invariably appropriate, especially under conditionswhere a text string may be the target of a pointing device as part of a directmanipulation input sequence (see §3.3.2 below)2.

3.3.1.3 A range of highly legible fonts will have to be available in a variety of screensizes. These will have to include a fixed space and a proportional sans-seriffont and at least one good serif font should be provided. All fonts should beavailable in italic, bold and italic/bold forms. ODID IV employs only sans-serif fonts in the present version.

3.3.1.4 The fixed space font is of particular importance for use in selectablealphanumeric fields in aircraft labels where the area of the selectable field is afunction of the string size. It is also important in the structuring of any listmaterial.3

3.3.1.5 Confusability between Characters: It is recommended that, when assessingthe fonts for use in the interface, particular attention should be paid to theconfusability of uppercase ‘B’, ‘8’ and ‘P’and to the confusability of ‘S’ and‘5’. Further, in choosing the san serif fonts care should be taken with thereadability of ‘1’, ‘l’ and ‘L’ especially when they are placed close to othercharacters such as ‘m’, ‘n’, ‘u’ and ‘h’ with multiple parallel verticalsegments. In examining the proportional fonts care should be taken with howboth upper and lower case ‘C’ interact with a following vertical character togive the impression of ‘O’ or ‘d’.

3.3.2 Interaction Characteristics

3.3.2.1 The general system of interaction for the REFGHMI is based on that employedin ODID. Consequently, it is an attempt to realise a graphical directmanipulation interface. In a direct manipulation all inputs are generated by



using some process of manipulation of elements already output by the systemand composing them into a suitable input. In the case of graphical directmanipulation this usually means employing some form of pointing device toselect and manipulate visual objects presented on the output display. Thedisplay becomes the locus of the interaction and the actions of manipulatingand creating graphical objects and processes constitute the human machinedialogue. The set of objects, and processes represented by objects becomesthe lexicon of nouns, the set of manipulations corresponds to verbs and thecompositional rules become the grammar of the interaction language.

3.3.2.2 This form of interaction, based on the location of a single pointing device, hasa number of characteristics.

a) The number of alternative inputs is largely governed by theavailable screen objects4. In order to be available, a screenobject must be visible to the user, (i.e. not be completelycovered by other screen objects) and must be enabled forinputs. If a screen object is visible and not available for input,this status must be clearly indicated to the user.

b) Input to the system is completely serial. The device can onlypoint to one object at a time5. That object is the focus of thecurrent activity.

c) The ability to point to an object is governed by Fitts’ Lawwhich relates the movement time (MT) taken to acquire atarget to the width of the target along the direction of approach(W) and the distance (D) which the hand must be moved.

MT = a + b log2(2D/W) where a and b are

empirically derived constants.[12, §9.201]

For the mouse this can be roughly6 expressed as:

MT = 100 log2 (D/W + 0.5)

A worst case value for D on the Intergraph or Sony displays is68.58 cm (27” diagonal) although a more typical value wouldbe around 30.0cm for the RPVD and tools. Under theseconditions a minimum target width of 4mm7 along thedirection of movement would result in reasonable MT valuesof between 620 and 750msec. Note that this size alsocorresponds to the minimum character height recommended.

3.4 Principal Elements of the Visual Environment3.4.1 This section lists and describes the main elements of the visual environment.

These can be divided into three main categories: the background environment,the window elements and the contents of the window elements (ATC taskelements). This document will deal with the first two of these categories. TheATC task elements will be dealt with in detail in Chapters 4 and 5.

3.4.2 The Background Environment



3.4.2.1 The principal elements are the Worktop8, the Tool9/menu regions, theCursor(s) that are associated with the pointing device and System MessageWindows.

3.4.2.2 The Worktop is the background surface on which all other display elementsare presented. It is analogous to the Desktop in the metaphor employed onMacintosh and Microsoft Windows systems. It is not anticipated that largeareas of the worktop area will be visible within the REFGHMI as most of thedisplay surface will be required for the task displays. However, it isrecommended that the visual presentation of the worktop itself should besubdued (of a brightness comparable to the background of the radar image)and of a very fine visual texture to avoid perception of any flickering effects asobjects are moved. Any texture that produces Moiré patterning, or undulyemphasises drift in colour convergence of the displays should be avoided.

3.4.2.3 In ODID III, the tool region was a movable window containing selectableitems. In ODID IV it was fixed and placed along the top of the displaysurface. This later arrangement of a fixed region at a display boundary has theadvantage that it can be selected with very great rapidity since it is effectivelyan infinitely wide target in terms of Fitts' Law (see above). Precision isrequired only in one dimension (along the toolbar) instead of two.

3.4.2.4 Within ODID III, there were already distinctions between the tools requiredfor the general management of the interface and tools specifically required forsupport of the Radar Plan View Display (RPVD) functions. It isrecommended that in the REFGHMI there should be a distinction betweentools which are general (applying to the interface as a whole) and those whichare specific to particular ATC Task Displays, and that this distinction shouldbe reflected within the display structure. To achieve this there will be ageneral menu/tool bar on the Worktop that will deal with workpositionfunctions and management. This will be complemented by a tool windowsystem which will be employed in a consistent manner for each window butwill be matched to the specific requirements of that window. The suggestedtechnique is for there to be an icon/button within each window, which willgive access to a toolbox with contents matched to the window. This toolboxwill be movable only within its parent window. If usage is very low, thiswindow can be closed, down to its icon/button form. This has the advantageproviding an individual toolbox for each task window, but not forcing acommitment of the screen area, if the tools are seldom employed.

3.4.2.5 Individual tools within the toolbox, will be openable, closeable and movable,independently of the local toolbox. Thus a tool which will be frequentlyemployed over a period of time, can be accessed via the toolbox, moved to aconvenient location and then the toolbox can be closed leaving only therequired tool available for use.

3.4.2.6 Where similar tools are required in different windows, they are identical inform and operation.

3.4.3 The Window Elements

3.4.3.1 Windows will appear in a number of different forms within the system withdifferent properties associated with these forms. Windows can becharacterised along a number of dimensions. A list of relevant dimensions,drawn from ODID IV usage [17, §10] includes:

• iconifiable or non-iconifiable



• closeable or uncloseable

• movable or non-movable

• re-sizeable or non-re-sizeable

To this can be added,

• presence or absence of an associated toolbox

• status: ‘parent’ window or ‘child’ window

• pannable and/or scrollable

• status on invocation, i.e. priority, position, size

• whether it has a minimum or a maximum size

• whether it is modal or not, (i.e. whether input operationsbehave differently as a result of actions possible within thewindow, e.g. §4.4.8 or §4.8.8).

• square or round corners (round corners are used to indicatesystem messages, see §3.4.5)

• relationship with general toolbox

Close/Iconify

Click for incremental pan

Button

WINDOW NAME

Move Handle/Namebar

Re-sizing Handle

Panning Sliders

Toolbox Button

Figure 3.1: The Generic Window structure that supports the main propertiesdescribed in §3.4.3.1.

Note that many windows will employ only a subset of these elements

3.4.3.2 Only certain combinations of these will be required for the REFGHMI. Sincemost of these characteristics require supporting visual objects to permitappropriate interaction, the visual appearance and behaviour of a window willcue the user as to its available properties. Figure 3.1 provides a referenceillustration of a window that has all the possible features. These will beexplained in more detail in §3.5. In general:



a) All windows will be movable. The mechanism chosen toimplement this will be the PRESS AND DRAG of button B1on a suitably defined handle/name bar.

b) Some windows will be re-sizeable. These fall into two furthercategories. User re-sizeable windows, where re-sizing is bymeans of a PRESS AND DRAG action using button B1 on asuitable handle (e.g. the Radar Plan View Display, §4). Thispossibility will be cued by the presence of the handle. Thesecond class of re-sizeable windows are dynamically sizedwindows where the system re-sizes the window to allowadequate display of varying amounts of information (e.g. theSector Inbound List, §4.13). These would not require userintervention and this property may be made explicit onlythrough observation of its behaviour. Under mostcircumstances, the re-sizing process would follow from somecontroller action so the predictability of the system wouldremain high.

c) Windows may overlap, i.e. the general principal of windoworganisation will be stacking. However, the principle of thefocused window moving to the top will not always hold10.The focus of interaction, or input, will always be the locationof the pointing device cursor.

d) Windows will have to have a screen stacking priority todetermine the overlapping of their display representations. InODID IV, and in this system, it is possible (and useful)11 tohide windows completely. In order to do this safely it isnecessary to provide a mechanism for changing the priority ofitems in a sub-section of the priority stack (bracketed inAppendix 10). The proposed method is similar to thatemployed in ODID IV. CLICKING mouse button B2on anyexposed part of a window, causes that window to move to thetop of the sub-section of the priority stack unless it is alreadyat the top of the stack in which case, it is moved to the bottomof the stack. This function can be useful for having a quicklook at an item or uncovering concealed items. The situationis slightly more complex in the REFGHMI. Individual ‘parent’windows may have ‘child’ windows which are moved withthem. Effectively there is a primary stack with secondarystacks attached to parents. Appendix 1 illustrates the overallstacking structure of the interface. The mechanism describedhere operates only within the layers shown as Windows 1 to n,in the diagram.

3.4.3.3 The final tuning of the graphical appearance and the colours for the windowstructures, frames, buttons, handles, etc. will have to take place using thedisplays, and ambient lighting conditions, under which a system isimplemented. However, some initial suggestions as to basic graphicalappearance of these support structures are made in Appendix 2.

3.4.3.4 For the REFGHMI, it is suggested that there should be six principal (orprimary) window elements. These are:

• the General Toolbox



• the Radar Plan View Display (RPVD)

• the two Message Windows

• the Vertical Assistance Window (VAW)

• the Conflict Risk Window (CRD)

• the Conflict Zoom Window (CZW)

3.4.3.5 Optionally, a seventh element, a Horizontal Aid Window (HAW) could beincluded. This window played an important role in ODID III but ODID IVrevealed that it was less useful than had originally been anticipated, partlybecause of overlap in function with the Conflict Zoom Window (CZW), and itwas dropped altogether from the Reference System Implementation of PHAREPD1.

3.4.3.6 The General Toolbox is described in §3.6 of the current chapter. The RPVDis described in Chapter 4 together with the Message Windows, §4.14 and theother three elements, all of which are derived from ODID, are specified inChapter 5. Collectively, these are the set of Parent objects in the interface.

3.4.3.7 A large number of secondary or ‘child’ windows and other objects are requiredwithin the interface. All of these will be employed within the context ofinteraction with one of the parent elements above. They are defined, inassociation with their parent objects, at appropriate points in subsequentchapters.

3.4.4 Cursors

3.4.4.1 Cursors are a very important element in a direct manipulation environment.They carry out a number of roles and functions and operate:

a) as the Focus of Attention

b) as the Locus of Input Actions

3.4.4.2 Verplank [18] has suggested that the cursor can be considered as therepresentation of the user's presence within the system or at least within thesystem produced parts of the interface. It supports this role by providingfeedback:

a) on the user’s pointing activity

b) on the consequences of the user’s actions, i.e. the system'sresponse to the user

3.4.4.3 The feedback (referred to in § 3.4.4.2a) is essential in order to control theuser’s activity and is analogous to the sensory feedback required for humanmotor control. This comparison emphasises the need for absolute consistencyin the relationship between the user’s action and the cursor's behaviour. Lackof such consistency is directly comparable to a failure of your own body toobey your intention to move in a particular way. Consequently, the cursorneeds to be re-drawn very swiftly, and smoothly and to track mousemovements without lags. NO system activity should take priority over themouse cursor tracking relationship. (RULE #1, §2.6.1). This is particularlytrue in a system that uses implicit window selection, as this system does, sinceno other form of window highlighting or colour change is implied. Onlycursor position is important.



3.4.4.4 The feedback in §3.4.4.2b) reflects a number of aspects of system activity. Ifthe feedback is not provided with sufficient rapidity, queuing of inputs fromthe operator will occur. This will then result in unpredictable, andconsequently unacceptable, behaviour of the interface. This feedback canfunction as follows.

a) It can indicate that the system has recognised that an inputhas, or is being made, e.g. change from pointing to draggingcursor.

b) It can indicate that the system has not only recognised theinput but that it will require significant time to process theinput and produce a response, e.g. the change for a pointingcursor to a busy cursor.

c) It can provide an additional indication that the system hasfinished processing some input. For example, when the systemhas modified a data field in response to an input, besides thechange in the data field itself, the cursor may change from abusy cursor back to a pointing cursor.

d) It can indicate that a particular input or activity is illegal in aparticular region of the display surface, or at a particular timein a processing sequence, by turning into a warning cursor.

e) It can indicate the existence of a mode by changing into aspecial form when the interaction has entered the mode, e.g.the 'drawing tools' in a paint package or a special cursor, whilethe system is 'rubber banding' for modification of aircraftheadings on the RPVD as in ODID IV.

3.4.4.4 The following cursors are specified as the minimum for the REFGHMI.Illustrations are provided in Figure 3.2.

3.4.4.5 POINTING CURSOR: The standard default cursor. An arrowhead pointingup and to the left. Used for all pointing and window management functions.Defined within the X windows system as Xname=XC_top_left_Arrow ([5]pp7.83-7.85). The hot spot12 of this cursor is the point of the arrowhead.

3.4.4.6 BUSY CURSOR: Used to indicate that the system is processing as a result ofinput. No other inputs possible in the area while this is active13. It reverts tothe appropriate cursor when processing is complete. Two alternatives areshown in Figure 3.2. For the Clock and the Mandala the hot spot is at thecentre of the visible disk. Neither should be used for inputting of information.

Sighting Cursors

Busy Cursors

Caution Cursor

Pointing Cursor

Figure 3.2: Suggested cursors (approximate illustrations only)

3.4.4.7 If possible, the busy cursor should be dynamic. For example, spinning clockhands in the case of the Clock or a spinning disk for the Mandala. The speed



of spin effectively acts as a secondary cue to the current loading on the system(on the assumption that it will slow as the system loading increases).

3.4.4.8 Alternatively, if Motif is employed, either the hourglass pointer or the watchpointer could be employed effectively in the busy cursor role ([5], p2-10).

3.4.4.9 NOTE: In cases where the input action requires a particularly lengthycomputation, it may be appropriate to provide a specific system message, bymeans of a suitable mechanism, to indicate the progress of this activity (See§3.4.5). It may even be necessary to release the cursor to permit the controllerto undertake other activities while awaiting the outcome of this process.Possible examples could include the running of an induced conflict probe, orother calls to tools, or the use of a datalink communications mechanism inmore advanced experimental conditions. However, this type of mechanismshould be undertaken only with extreme caution.

3.4.4.10 WARNING CURSOR: This cursor is used to show that input is not currentlypossible in this region of the display, usually because some prior inputrequirement must be completed first. The cursor reverts to previous cursorform when the pointer is moved from the illegal region or an attempt at anillegal input is terminated. Hot spot is the centre of the disk. Note that theoperation of this cursor can be complex with a three button mouse where someinputs could be legal while others are not. Under these circumstances, thewarning cursor only appears when the illegal button input is attempted or allbutton inputs would be illegal.

3.4.4.11 SIGHTING CURSOR (Crosshairs): Used when the interaction has entered amode. In the case of the REFGHMI, this should only occur during use of the'rubber band' heading vector or in the modes menu of the Radar Toolbox. Thehot spot of this cursor is the centre of the cross. Two exemplars, to distinguishdifferent modes, are shown.

3.4.4.12 It should be noted that the bit mapped images of the cursors will normallyappear as dark against the general background materials of the displays.However, it is general practice for the bit maps employed to have a very fine,single pixel, white outline which ensures the contrast of the cursor when it ismoving against varying backgrounds and crossing darker lines. StandardMotif-type cursors should provide this.

3.4.5 System Message Windows/System Dialogue Boxes

3.4.5.1 System Message Windows are used to provide special information, orwarnings, concerning the status of the system.

3.4.5.2 They are system generated, appearing at the current location of the cursor.Since they will generally follow in response to a user input, it is assumed thatthe user’s attention is focused close to the cursor.

3.4.5.3 Their precise physical description will be a function of context, however theywill have a number of features in common.

• They will have the highest screen priority except for cursors.

• They will always have rounded corners to distinguish themfrom all other forms of window.

• They will have a white general background and a blackboundary.



• They will be movable by means of a name/handle in case theirappearance obscures critical operational information.

• They will have a Message region which identifies their nature(see §3.4.5.4) and is used to explain their appearance to theuser.

3.4.5.4 System Message Windows will fall into two broad categories. SystemInformation Messages (SIMs) and System Dialogue Boxes (SDBs).

3.4.5.5 SIMs will be used to communicate temporary system conditions to users. Forexample, if system action in response to a user input will take a significanttime, a SIM could appear to explain that fact and to provide dynamic feedbackas to the status of the activity. SIMs are removed with no specific user inputwhen they are no longer relevant.

3.4.5.6 SDBs are used when a specific input, e.g. user acknowledgement of awarning, or additional user information is required. SDBs are removed whenthe user completes the necessary actions. SDBs will be used very sparingly.

3.5 Implementation of Window Management3.5.1 This sub-section explains the mechanisms implemented to provide the

window management functions referred to in §3.4.3. A general illustration ofscreen prioritisation is provided in a diagrammatic form in Appendix 1.

3.5.2 Repositioning

3.5.2.1 Windows are moved by means of a window handle/name-bar located along thetop edge of each movable window frame. The absence of such a bar indicatesthat the window is not movable. The name bar should be at least 6mm deepincluding the thickness of its delimiting lines. In detail, movement isimplemented by moving the pointing arrow cursor onto any part of thenamebar and depressing button B1. The area of the name bar includes thethickness of the delimiting boundaries. On depression of B1, the cursor doesnot change but immediate feedback of input is acknowledged by the presenceof a wire frame showing the outline of the window. This moves in a fixedrelation to the cursor as the latter is moved on the display surface. When B1 isreleased, the window is re-drawn in the position corresponding to thewireframe outline and the wireframe disappears.

3.5.2.2 The wireframe will need to differ sufficiently in texture from the originalwindow frame, that its presence is immediately apparent. It will also need tobe visible when moved across backgrounds of various colour colours andtextures. The wireframe will need to be re-drawn with a speed that allows it totrack the cursor position moving at the same speeds as are required in normalcursor movement.

3.5.2.3 NOTE that the process of moving a window by means of the handle/name barautomatically moves it to the top of its stack, (either the main stack if it aparent window, or the appropriate secondary stack if it is a child window).CLICKING B1 on the handle/name bar has the same effect.

3.5.2.4 NOTE also that the style of text in a window name bar can be used tocommunicate significant information. The current suggestion is that NormalText be used to indicate the name of windows which are fixed, e.g. RPVD



(Radar Plan View Display) or CRD (Conflict Risk Display). Italic Text isused to indicate elements of a window name which are dynamic, e.g. thecallsigns of the aircraft shown in the CZW (Conflict Zoom Window) or thesubject aircraft of the ELW (Extended Radar Label Window).

3.5.3 Re-Sizing

3.5.3.1 This is accomplished by means of a re-sizing handle displayed at the bottom,right hand side of the window frame. When a window is re-sizeable, thishandle is permanently displayed. The absence of a handle indicates that awindow is not user re-sizeable. The handle is operated by placing the pointingcursor within the handle region and depressing mouse button B1. The handleregion includes the lines that make up its frame. A wireframe immediatelyappears as in the case of repositioning. In this case the wireframe is fixed atthe top left hand corner, and expands or contracts in the X and/or Y directionsas the handle is dragged by moving the mouse. On the release of B1, thecurrent location of the handle becomes the new handle position of a windowre-drawn with the co-ordinates of the wireframe.

(a) (b)Figure 3.3: The two forms of Re-sizing handle employed for PD1.

The Varying aperture handle (a) is employed on all windows exceptthe RPVD, the HAW, and the CLOCK, which have the re-scaling

handle 9b). See §3.5.3.3 and §3.5.3.4 below.

3.5.3.2 There are two possible variations on the behaviour of the window contentsfollowing re-sizing. Normally, it is anticipated that the user is not aware of thedistinction between these behaviours but, in case the distinction is recognised,it is important that there should be a clear means of distinguishing whichbehaviour is to be expected. This is achieved by employing two differentvisual forms of re-sizing handle. The variations are defined as VaryingAperture and Re-scaled Aperture14. In both cases the re-sizing handlesshould be at least 6.0mm x 6.0mm including the delimiting lines and thewireframe should meet the same responsiveness and visibility criteria as forrepositioning. A suggestion for the distinguishing visual forms is shown inFigure 3.3.15

3.5.3.3 The Varying Aperture handle is provided for all re-sizeable windows exceptthe RPVD, the VAW, and the CLOCK (also the HAW if it were to beimplemented). In the Varying Aperture case the scale of the window contentsis not changed but the aperture of the window is changed to show an increasedor decreased field of view.16 This is the case for the CZW for example.

3.5.3.4 In the Re-scaled Aperture case, the aperture of the image window remainsconstant and the image is re-scaled to fill the re-sized window, i.e. the imagegets bigger or smaller as the window is re-sized. This mechanism applies onlyto the RPVD, and the CLOCK (§3.6.3).



3.5.3.5 OPTION: An alternative would be that re-sizing handle type could beassociated with position The varying aperture on the right hand bottom cornerof the window, the re-scaled aperture on the bottom left. Thus some windowscould be provided with both.

3.5.3.6 IMPORTANT NOTE: A potential difficulty arises when re-scaled aperturewindows are re-sized to a different extent in the X and Y directions changingthe aspect ratio of the window. The aspect ratio of the contents MUST NOTchange. In the case of ODID IV a simple rule was adopted whereby thedisplayed image retained the same centring and was re-scaled to maintain theX axis extent as constant. A similar rule was employed for PD1 and is alsorecommended here.

3.5.4 Scrolling and Panning17

3.5.4.1 This is implemented by means of slider bars and incremental buttonspositioned along the right hand and bottom edges of window frames. Theabsence of slider bars indicates that the window cannot be panned or scrolled.When a window, with no scroll bars is re-sized to be smaller, scroll bars mayneed to appear, inside the re-sized frame, if it is intended that window shouldbe scrolled and panned.

3.5.4.2 Sliders are moved by pressing B1, dragging and releasing (PRESS andDRAG). On release of B1 the screen image is redrawn on the same scale butwith the centre of the display displaced in the same sense as the slider hasbeen dragged. In cases where the potential field of view is limited, the slidershould reach the end of the slider bars to correspond with the limit of possiblemovement of the display.

3.5.4.3 If the cursor is moved off the slider with B1 still held down, the slider willcontinue to track the appropriate axis of cursor movement until the button isreleased, as if the cursor were still positioned on the slider.

3.5.4.4 The incremental buttons are activated by clicking B118 with the pointer locatedwithin their area. Each click results in a displacement of the displayed imagein the opposite direction to the incremental pointer, i.e. the pointer indicatesthe direction in which the window frame moves relative to the image. Thesize of the appropriate increment has to be determined empirically dependingon the nature of the material that is displayed in the windows, i.e. when thedisplayed material is text, it is typical that the incremental button will movethe text by one line at a time. The choice of increment may be moreproblematical for graphical windows such as the RPVD.

3.5.5 Zoom

3.5.5.1 For the REFGHMI, as for PD1 and ODID IV, zoom is generally not a functionat the window management level. It is an operation that takes place on thedata in a window. As such, any zoom function will be provided by anappropriate tool within the toolbox for that window.

3.5.5.2 The exceptions to this are described in §3.5.3.4.

3.5.6 Iconification

3.5.6.1 It will be possible to reduce primary windows to icons but not to remove themcompletely. It will not be possible to iconify the RPVD or the CRD. All otherwindows will be iconifiable. When a window is iconified, its icon will be



placed at a specific location (the ‘parking rank’ described in §3.6.2) associatedwith the general toolbox. The exception is the general toolbox itself, whichcan be reduced to an icon on either or both of the two screens on a doublescreen system. In this case the icon maintains the same screen priority as thegeneral toolbox, ie. it is always available.

3.5.6.2 Iconification serves two main functions for the REFGHMI. Firstly to savedisplay space when particular display elements are not required. Secondly,there is a technical difficulty on some multiple screen systems which does notallow dragging of windows from one display surface to another and theiconification mechanism as defined in §3.5.6.3 provides a means oftransferring windows in a simple way. For single screen systems thismechanism will not be necessary.

3.5.6.3 In two screen systems there will be a 'parking rank' area incorporated in thegeneral toolbox. In this there will be an icon/button corresponding to each oneof the main display elements that can be made available, i.e. RPVD, VAW andCRD. When a display window is open on a particular screen, that icon will beshown as ‘depressed’ in the 'parking rank' only on the screen on which it isdisplayed; not on the other screen. (The icon will not lose its place in therank.) Clicking button B1, on the icon on the second screen will cause thedisplay to redrawn on the second screen in exactly the same position (withhigh priority) as on the first screen and will then cause it to be closed on thefirst screen. The icon/button will be ‘depressed’ in the parking rank in thesecond screen and will be restored to the normal state in the parking rank onthe first screen. Thus with a single mouse click the display will have beentransferred from one screen to the other. Once on a particular screen, thewindow can be moved re-sized, etc. by the mechanisms already outlined.

3.5.6.4 To iconise an individual window on both displays it is necessary to CLICKbutton B1 on the close box positioned near the left hand end of thename/handle of the relevant window. Alternatively, CLICKING B1 on thedepressed icon/button, corresponding to the open window, will cause thewindow to be closed and the icon/button restored to its normal state. Thiswill be possible for all primary windows except the RPVD and CRD whichwill always be open somewhere on the interface. This special status of thedepressed RPVD and CRD buttons will be shown by a diagonal ‘red’ stripeindicating the prohibition.

3.6 General Toolbox

3.6.1 General

3.6.1.1 The General Toolbox19 is a window that contains tools that relate to the wholeinterface. Tools specific to individual windows will be provided as suitabletoolsets within their own, dedicated toolboxes. The main elements of thetoolbox relate to user preferences, the list of icons in the parking rankdescribed above, a CLOCK, and access to required mechanisms for flexiblemodification of the interface. Other tools may be added to this toolbox asneeds and capabilities emerge.

3.6.1.2 All these functions, except the CLOCK are represented by icons/buttonswhich are identical in size. The toolbox window is sized such that it iscompletely filled by the row of buttons (See Figure 3.4).



3.6.1.3 In both iconised and opened forms, the general toolbox has a higher screenpriority than any elements of the interface except cursors and system dialogueboxes (see Appendix 1) and the CLOCK window if opened. The iconisedform of the general toolbox is actually the CLOCK, the same size as theCLOCK button in the toolbox but in a different colour. (See Figure 3.4)

FLEX

GENERAL TOOLBOX

VAW PREFCRDPVD 12:26:10

Figure 3.4. The General Toolbox CLOCK/ICON and the General Toolbox

(Actual Size)

3.6.1.4 IMPORTANT NOTE: It is intended that colour is used throughout theinterface in a consistent way. (The specific recommendations are included asAppendix 3 and the Master Colour Table as Appendix 4.) Buttons come inthree sizes; large icon/buttons, medium menu buttons and small buttons.

LARGE FAWN ICON/BUTTONS: Open and close windows

LARGE BLUE ICON/BUTTONS always give access to windows or menus inwhich additional choices scan be made.

Similarly BLUE MEDIUM MENU BUTTONS always give access to childwindows or menus in which additional choices scan be made.

SMALL FAWN BUTTON are always RADIO BUTTONS, i.e. for any set onlyone choice can be active at a time.

SMALL BLUE BUTTONS are TOGGLE or SWITCH BUTTONS used forindicating and setting a parameter state.

3.6.1.5 Attributes: An instance of the general toolbox can be made available on allscreens which make up the REFGHMI. It has the following properties:

• parent window

• iconifiable/closeable (close box: back to button form [CLOCK])

• moveable (name bar/handle)

• fixed size according to content (not user re-sizeable)

• no internal toolbox

• no panning or scrolling

• always highest screen priority below cursors and systemwarnings (it cannot be obscured by overlapping)

• penetrable20 (special characteristic, objects pass under)



• square corners (rounded corners is reserved for system messages)

• the position, size status of the general toolbox are saved withthe preferences set.

3.6.1.6 Contents: The General Toolbox contains a horizontal row of icon/buttonsthat are used to launch a variety of windows or functions. These are:

• Icon/buttons for each of the windows available on the interfaceas described for the 'Parking Rank' above. (PVD, VAW, CRD)

• Icon/button for the clock display (CLOCK)

• Icon/button for accessing Preferences Menu (SET-UP))

• Icon Button for accessing Flexibility Support (FLEX)

3.6.1.7 Activation: The Toolbox can be opened from its icon/button form (CLOCK:WINDOW BLUE RGB% 44,55,66 WHITE Text) by CLICKING mousebutton B1 with the pointing cursor located on the button. The Toolboxwindow opens at the location of the icon.

3.6.1.8 All the icon/buttons within the toolbox are activated in the same way byCLICKING B1 with the pointing cursor located within their boundaries.

3.6.2 Parking Rank

3.6.2.1 The Parking Rank (initially described in §3.5.6.3) contains an icon/buttoncorresponding to each of the primary windows potentially available within theinterface. Those currently opened on the particular main display surface onwhich the a toolbox is located are shown in a ‘depressed’ form in that toolbox.Depression is indicated by x,y inversion of the button highlights and shadowsand changing the button infill to the appropriate ‘depressed colour’, i.e.FAWN/DEP (RGB% 48,37,21) or BLUE/DEP (RGB% 24,35,54). Theparking rank region will be indicated by a suitably bounded backgroundwithin the toolbox, i.e. either an outline grouping the parked windows togetheror a different shading of background. (See Figure 3.4).

3.6.2.2 If the re-ordering mechanism described in §3.6.1.9 is implemented it will notapply internally to the icons in the 'parking rank' region of the toolbox. Theparking rank will be treated as a whole. The correct ordering for its internalcontents will be established and modified as usage requires.21

3.6.2.3 Activation: CLICKING button B1 with the pointing cursor positioned on anyof the icons on either screen will result in the window, related to that icon22,being opened on that screen in a location defined by the currently storedpreferences list. (Option: The window is opened in the position in which thelast instance of that window was opened.)

3.6.2.4 When the appropriate window has been opened, the icon/button correspondingto that window is shown as depressed only in the parking rank in which it hasbeen selected. Clicking B1 on the depressed icon/button closes the recentlyopened window, as does the close box on its own handle. If the Parking Rankhas been used to open a window on a particular screen as a means oftransferring it from the other, then the icon/button on the screen from whichthe window has been transferred must be re-elevated from the depressedposition when the window is deleted from its display.



3.6.2.5 Note that the RPVD and CRD form a partial exception to the closureprocedures described in §3.6.2.4. This is because they must always bepresented on one screen or the other. Consequently;

a) the RPVD and CRD windows will not have a close box, and

b) the depressed icons in the general toolbox contain a warningband to show that they cannot be de-selected by CLICKINGB1.

3.6.2.6 The attributes of the various windows that can be controlled from the parkingrank are defined in Chapters 4 and 5 which define the RPVD (Ch4) and theVAW and CRD (Ch5) respectively.

3.6.3 Clock

3.6.3.1 The clock is present as an icon/button within the general toolbox. In this iconform it presents the time in a digital form showing hours, minutes andseconds, i.e. as six digits grouped in pairs separated by decimal points “.” orcolons “:”. (Option. If the clock updating has a performance impact on theinterface, then updates could be limited to 10 second intervals.) This is thesame form employed for the icon representing the general toolbox and differsin the colours of presentation. In this instance the CLOCK Button is in FAWN(RGB% 68,57,41) with BLACK text.

3.6.3.2 Activation: Unlike the other icon/buttons, the clock is always active in that,even in the icon form, it continues to perform its function by displaying acorrectly updated time. When B1 is CLICKED on the icon/button a clockwindow is opened and the CLOCK icon/button is shown as depressed.CLICKING B1 on the depressed CLOCK button closes the CLOCK Window

3.6.3.3 Attributes: The attributes of the CLOCK window are:

• independent window

• iconifiable (close box: back to button form)

• moveable (by means of name handle)

• re-sizeable (re-scaled) (by means of a re-sizing handle on bottom right corner of frame)


• cannot be panned or scrolled

• highest priority (above general toolbox)

• minimum size (internal window area cannot be smaller than the invoking button area)

• square corners (rounded corners for system messages)

• the status, position, and size a of the CLOCK are saved withthe preferences set.

3.6.3.4 The CLOCK window has no internal functionality in the currentspecification23. It continues to display the time in the same manner as wheniconised - only the sizes differ. The only inputs or manipulations are thoseassociated with window management.



3.6.3.5 The re-sizing function on the CLOCK window is re-scalable like the RPVD.When the window size is modified, the font size of the time information ischanged to optimally fill the available space. The re-scaling is carried out onthe basis of the change in the X axis.

3.6.4 User Preferences

3.6.4.1 The user preferences element allows the controller to save a preferred screenset-up so that it can be restored at some future time, such as the beginning of anew work session. The information stored is:

a) the location and size of all open windows, including hiddenwindows.

b) the panning and zoom values of all windows equipped withthis capability.

c) the presence and position of any toolboxes and tools and of allsettings selectable within tools

3.6.4.2 In the ODID IV Facilities Specification [17], User Preferences were operatedthrough a Preference Set Window (PSW). A slightly simplified version ofthis system proved effective in the simulation and an almost identicalprocedure is defined here for the REFGHMI.

3.6.4.3 Activation: The Preference Set Window (PSW) is activated by CLICKINGB1 on a PREF Button/Icon in the General Toolbox. It appears near to, but notoverlapping, (or underlapping) the general toolbox.

3.6.4.4 Attributes: The attributes of the PSW are:

• independent window

• iconifiable (back to general toolbox)

• closable back to icon

• moveable (by means of name handle)

• fixed size


• cannot be panned or scrolled

• high priority on invocation

• square corners

3.6.4.5 Functions: A preference selection may be saved as required by a controller.Participating controllers will be allocated a number. This will permit them tosave their own preference and to load the preferences of another controller (orthe default). On start-up, the configuration is the default24 for the sector andposition (TC/PC). Any desired preference set may be loaded by a controller.

3.6.4.6 The PSW is shown in Figure 3.5. It is drawn in standard window colours.The general background of the window is presented coloured as WINDOWBLUE (RGB% 44,55,66). It is divided into four regions by means ofSHADOW GREY lines (RGB% 20,20,20). These regions are:

a) Region 1. The window dragging handle, name bar andclosing button, positioned at the top of the window.



b) Region 2. Two Push buttons, labelled LOAD and SAVE,drawn in WINDOW BLUE with conventional highlights.

PREFERENCES

Mouse Hand

1 2

3 4

5 6

7 8

9 10

L R

SAVELOAD

Figure 3.5: The Preferences Menu

c) Region 3. A region of 10 contoured radio buttons drawn inBUTTON FAWN (RGB% 68, 57,41). Buttons are labelled 1to 10 in sans serif font, black. When a button is pressed, thecontour shading reverses and the button becomes WINDOWFAWN DEPRESSED (RGB% 48,37,21). The text of thedepressed button becomes white. Depressing another buttonreleases the previous selection (definition of radio buttons).

d) Region 4. This region is intended for setting the mouse forleft or right handed users. (The initial default setting is forright-handed users.) The region consists of an identifyinglabel and two radio buttons labelled LEFT and RIGHT. Thecolouration and graphical behaviour of the buttons are as forRegion 3. This region could be extended to include slidersettings for screen brightness and contrast, mouse gain, andthe timing parameters of a CLICK if the system could supportit.

3.6.4.7 Operation:

• The menu is invoked, with the pointing cursor, by CLICKINGB1 on the preferences icon/button in the general toolbox.

• Any button may be activated by CLICKING B1 with the cursoron the button surface. For all buttons (except the SAVEbutton), activation will result in the button being redrawn asdepressed and any other button that has been shown asdepressed (selected) in that region being released. (This is theimmediate feedback action.) In the case of the SAVE button,the button reflects the action of B1, i.e. as B1 is depressed the



SAVE button shows as depressed and the name label invertsfrom Black to White. On release of B1, the screen buttonreverts to its rest state.

• On initial start up, the screens will have been set to the defaultsetting, and no buttons in regions two or three will be shown asselected. The right mouse button will be shown as selected(depressed).

• The controller selects their assigned number by CLICKINGB1. The buttons provide immediate feedback

• If the controller now Clicks B1 on the LOAD Button, thescreens will be redrawn to reflect the stored preference setassociated with that button. If there is a perceptible delay inthis re-drawing process the cursor should change to the busycursor, reverting to the pointer when the process is complete.

• To modify a preference selection, the controller sets the displayenvironment to the required preferences by the normal displaymanipulation mechanisms, returns the pointer to thepreferences window, and CLICKS B1 on SAVE. This willsave the current configuration under the number selected inRegion 3.

• The window can be returned to the toolbox by CLICKING B1on the close box.

• The window can be moved by employing B1 in PRESS andDRAG mode with the pointer on the handle.

• That fact that a value is stored in a button is shown bychanging the text of the button number to WARNINGYELLOW (RGB% 100,90,12).

• Saving a new configuration on a previous configuration,overwrites that configuration.

3.6.4.8 It is recognised that this preferences option is very limited and could not bereadily employed in operational practice. Currently there is no way to preventan existing set being over written. Further, 10 settings is a rather smallnumber and a more ‘open’ repertoire is desirable. Extending the system wouldbe simple, but is not a design priority at the moment.

3.6.5 ‘Flexibility’ Support

3.6.5.1 Generally, in simulation, a certain measure of flexibility is required forinterface parameters. For example, in PHARE PD1 this was required for anumber of attributes of the interface. In the REFGHMI such requirements aremet at several levels.

a) Moment to moment variations in requirements are dealt withwithin the tools and parameters of the interfaces itself, e.g. theability to re-size or pan and zoom windows, the selection ofheight filters within the RPVD etc.

b) Individual differences in requirements are supported by thePreference Set Window that allows individual users tocustomise many elements of the interface. This mechanismalso allows this customisation to be modified as the controllers



more clearly define their personal requirements with extendedexperience of the system.

c) Some parameters, such as the colour of individual displayelements, symbology, font and font size may need to modifiedas consequence of experience with the system over time. It isnot anticipated that such variables should be modified withinthe course of experimental runs. Rather they would bemodified, either between runs, or in special sessions where ananalyst sits alongside a user. In effect, these should beavailable at the interface but not directly to the user duringruns.

d) Some parameters such as the period of ATC anticipation andthe retained number of radar plots form part of simulationconfiguration data.

3.6.5.2 Parameters of the type referred to in c) will require that the relevantparameters are embodied within the (object/attribute) structure of the interfacesoftware, and that appropriate editors are provided to permit interaction andmodification of the parameters as is necessary, i.e. colour, font and symbologyeditors.

3.6.5.3 In the short term, specifying and designing these editors is not incorporated aspart of the REFGHMI Specification activity. It is a requirement that should bemet as part of the basic facility on which the system.

3.6.5.4 However the REFGHMI25 must provide mechanisms for accessing these toolsas appropriate. The following general mechanism is suggested.

• Within the general toolbox there will be a FLEX button/iconproviding access, via a CLICK of B1, to editing menus relatingto colour, font, (symbology?) and other editors relating to theobjects of the general environment, worktop and windowingsystems. The objects described in this document such as thePSW, the CLOCK and the General Toolbox would be modifiedthrough this mechanism.

• If required, within each individual window, which supports atoolbox, there could be a identical button/icon providingaccess, by an identical B1 operation, to the editing capabilitiesappropriate for that window.

• It is strongly suggested that both the software structure and theoperation of the interfaces of the editors could be identical inall cases. The applications need differ only in the objects andattributes that they can access according to their context.

• Some form of password protection on the general FLEX buttoncould be employed to if there is any danger of controller’sinterfering with the FLEX settings. In this case the text of theFLEX button should be shown in SHADOW GREY rather thanBLACK.

3.6.5.5 The FLEX Button is included in the general toolbox for the purposes ofillustration. For simplicity, it has not been included in lower level toolboxes.

3.6.5.6 The parameters referred to in §3.6.5.1.d) are not of direct relevance to theREFGHMI.



Notes on Chapter 3

1 For example consider the characteristics of an Intergraph Display. The effectivedisplay surface of the individual Intergraph screen is 514 x 384 mm with anaddressable range of 1664 x 1248 pixels. This provides a horizontal and verticalpitch of approximately 3.24 pixels per millimetre. Overall, the active display surfaceof a single Intergraph presents visual angles of approximately 44° x 34°.

2 Classical wisdom on font design for emissive displays [13] suggests that readability isbest when character heights of presenting visual angles of between 20 and 22 arcminutes are employed. This also assumes a height to width ratio of between 1:0.7and 1:0.9. However, much of the material on this topic is somewhat dated and dealswith positive image (light on dark), 'glass teletype' text displays employing muchlower pixel resolutions than are currently available. The admonitions against usingtext greater in size than 24 arc minutes are based on the need for more eyemovements per unit of text when READING larger characters [14]. If, however, themessages are short enough to be read in single fixations, the legibility advantage oflarger text, and more especially the more rapid acquisition of a larger target duringvisual search, will more than offset any such effects.

3 For the purposes of illustration this font will be represented by GENEVA on theMacDraw Pro illustrations that are provided as part of the REFGHMI specification.

4 It is also dependant on the range of compositional rules available.5 At the time of writing, there is no intention to implement a 'multiple selection'

function of the type that can be found on the Macintosh or the Atari GEM system.This function permits several objects to be selected simultaneously, either by the useof a rubber band mechanism or holding down the shift key while clicking to makeselections without de-selecting previous choices.

6 This alternative form of Fitts' Law was derived by Welford [15]. The value of 100for the slope constant is extrapolated from Card, Moran and Newell [16] asrepresenting a very conservative value.

7 Since D/W is a ratio, it does not matter whether the values are expressed as visualangles or screen sizes. For reference, the 27" diagonal of a Sony or Intergraphdisplay presents a visual angle of 57° 7" at the estimated mean viewing distance of0.63metres.

It is also important to note that this is the size of the acquisition area associated witha target. Provided suitable feedback as to target acquisition is provided, this can bebigger or smaller than the extent of the visible target.

8 The term ‘Worktop’ has been chosen to distinguish the present environment andmetaphor from the ‘Desktop’ and the associated metaphor made popular on theMacintosh and subsequently in Microsoft Windows on PCs. A number of featuresdiffer. The Worktop has no ‘Dustbin’ or any other mechanism for representing andhandling file data by direct manipulation. All the objects represented relate either tothe ATC task or to window and work management. Similarly, some of the screenpriority behaviour found in PD1 would violate the physical model of overlaiddocuments that characterises the desktop metaphor.

9 There is a potential for confusion between the notion of ATC Tools as developedwithin PHARE Advanced Tools Set (PATS) and tools as required for themanagement and manipulation of data at the interface. For the purposes of thisdocument, and related documents in this series, the word 'tools' with a lower case 't'



always refers to interface tools. PATS are always referred to by using the term PATSspecifically.

10 For example, the Sector Inbound Lists (SILs) will appear to be drawn in front of theradar display. Interacting with the radar display will NOT cause it to be redrawn infront of the SILs.

11 It is possible, if not desirable, that a number of other windows might partially overlapthe main radar display. In is often useful to be able to take a quick look at theuncluttered radar picture. This can be done by the mechanism explained above(clicking B2) and then the status quo can be restored by repeating the B2 action asnecessary.

12 The HOT SPOT of a cursor is the pixel point within the cursor which is returned asthe value of the cursor location, i.e. the location which would be that selected wereany mouse button to be pressed.

13 It is not clear if this actually means that input events are not queued or simply thatthey will not be processed while this cursor is active. Perhaps the best solution is thatonly a single input event should be queued. It would also be preferable to be able todefine a maximum acceptable limit for the busy cursor. Unfortunately, the necessarydata is not available, and in any case will depend on system performance. See§3.4.4.9

14 A more general and elegant solution than the one proposed would be to make thenature of the re-sizing operation user specifiable for each window that is re-sizeable.This could be achieved in two ways:

a) by providing re-sizing handles on each of the two bottom cornerswith one corresponding to each of the two types of re-sizingfunction.

b) within the tools element of each individual window, providing apreferences switch which would be stored with the globalpreferences described in §3.6.4.

15 Thanks to Jeroen Hooijer at NLR for his suggestions on a considerably improvedvariable aperture handle.

16 The appropriate model is of a window looking through onto an image plane, not of aflat surface containing a fixed image that is re-sized. This model also applies toscrolling and panning where the viewpoint follows the movement of the slider.

17 Scrolling is defined here as referring to movement of an image in the Y axis. Panningdescribes movement in the X axis.

18 This marks a slight departure from current Motif Window manager practices althoughnot from the Style Guide requirements, as far as can be established. In PD1,CLICKING of B2 is reserved unambiguously for window priority manipulation.

19 The term ‘toolbox’ is used to describe the area carrying tools. The term ‘toolset’ isused to refer to a particular set of tools defined for use in a particular context.

20 An ‘impenetrable’ object implies that the boundary of the object cannot be traversedby a cursor while the pointing device is in a ‘drag’ mode. Further it implies that anywire-frame being dragged by the cursor will be unable to penetrate the object, eitheroverlapping or behind the impenetrable object. Penetrable implies the contrary stateof affairs. All objects are penetrable unless otherwise specified. In the case of thegeneral toolbox which ‘floats’ at a high level other objects will be able to passunderneath.

21 This may be one of the parameters covered by the Flexibility requirements of §3.6.5.



22 This is true of the PVD and the CRD. In the case of the HAW and VAW, depressingthe icon buttons ENABLES these windows. That is, it permits that they be displayedif appropriate data is available and other conditions are met which causes theirinvocation (actual appearance on the display).

23 It is included because individual controllers have expressed a wide range ofpreferences for how big the CLOCK should be.

24 The default settings will be defined with experience, but must include an open radarwindow.

25 Remember that this is a capability to be provided only for an experimentaldevelopment system. It would not normally be available during a large scalesimulation. Indeed a facility could be provided to implement or remove the FLEXbutton system at the exercise initialisation stage depending on the nature of theintended experimental run.


RPVDVersion: 1.0 Chapter 4 - 1

Chapter 4

Specification of the Radar Plan ViewDisplay Element of the Reference GHMI

4.1 Introduction4.1.1 This chapter provides a detailed description of the Radar Plan View Display

(RPVD) element of the REFGHMI.

4.1.2 It provides details of:

• the basic attributes of the RPVD

• the toolset available within the RPVD Toolbox

• the contents of the window, a detailed description of allpossible HMI interactions with the contents and of theconsequences of these interactions.

4.1.3 The input and windowing operations employed are as described in Chapters 2and 3. The specification which follows is largely based on the RPVDemployed in the ODID IV simulation and draws heavily on the specifications[17], supportive documentation [11, 19] and the results of that simulation.The colour palettes employed for the present specification are based on thosedefined in the Interim NATS Colour Standard [20] with minimal extensions toallow texturing of the windowing environment itself. Revised details of theNATS palettes, clearly showing the extensions are shown in Appendices 3 &4. All colour descriptions relate to theses revised palettes.

Table 4.1: Standard Window Colours for REFGHMI

4.1.4 The colours proposed for the window amd tool structures are shown in Table4.1

4.1.5 However, it is recognised that all colours, line widths, font choices and sizesmay require revision in the response to the actual displayed quality on thescreens used to implement the system.

Main body and slider background Window Blue RGB% 44, 55, 66

Body, and Track Highlights WBlue Highlight RGB% 64, 75, 86

Window Icon/Button Depressed WBlue Depressed RGB% 24, 35, 54

Radio Button /Slider Body Window Fawn RGB% 68, 57, 41

Radio Button /Slider Highlight WFawn Highlight RGB% 88, 77, 61

Radio Button Depressed WFawn Depressed RGB% 48, 37, 21

Window Restriction WFawn Restriction RGB% 65, 21, 20

All shadows Shadow Grey RGB% 20, 20, 20.



4.2 Main Elements of the Radar Plan View Display4.2.1 The RPVD may be considered as consisting of 6 main elements. These are as

Follows and will be described in more detail in the Sections of this documentindicated in brackets. These main elements are:

• the supportive structure of the window, handle, etc. (§4.3)

• the toolset provided within the RPVD Toolbox (§4.4)

• the background ATC map containing airspace, sectorboundaries, beacons, reporting points, airfields, etc. (§4.5)

• the symbology representing aircraft positions, etc. (§4.7)

• aircraft labels providing flight data information for individualaircraft (§4.7 & §4.8)

• secondary windows and information displays which appearwithin the RPVD, e.g. Callsign Menus, Sector Inbound Lists(SILs), etc. (§4.9- §4.14).

4.2.2 All interaction with the elements of the RPVD will be defined as part of theirgeneral description, in the relevant sections. All input will be via the threebutton mouse as prescribed in Ch.2. In summary;

B1 All normal inputs. Essentially the functions of the ActionButton in ODID IV, plus the operations necessary for windowmanagement.

B2 This button is reserved for a single specialist function: the‘flipping’ of the main RPVD to the top of the viewing stack toprovide an uncluttered view of the traffic situation

B3 The functions of the Information Button in ODID IV, displayor removal of additional information.

4.2.3 The baseline interface for REFGHMI does not make use of any of the toolsmade available through the PHARE Advanced Tools Set (PATS). However,the HMI and assumes that a number of basic ATC tools are available. Brieflythese are:

• a short term conflict alert function

• an automatic label overlap removal algorithm

• procedural trajectory prediction up to 10 minutes ahead,similar to that available in ODID III to support the CRD(Conflict Risk Display).

4.2.4 VERY IMPORTANT NOTE: If infilled track labels are employed withinREFGHMI, as suggested, it is important that any label overlap algorithmshould not only take account of the additional task of preventing labels fromoverlapping aircraft symbols, but give it priority over label/label conflicts.

4.3 Window Initialisation and Attributes

4.3.1 Initialisation



4.3.1.1 On system initialisation the RPVD will be open on the display. The locationand set-up will be as defined in the appropriate preference file or in the default

4.3.1.2 The default set-up will be that the RPVD will appear on the left hand screen ofa two-screen system, full height and square. On a single screen system, it willappear in the top left hand corner, in a square form, occupying about 50% ofthe available display surface.

4.3.2 Attributes

4.3.2.1 The RPVD will have the following attributes:

• parent window

• not iconifiable/not closable(no close box)

• moveable (by means of name handle PRESS and DRAG B1)

• re-sizeable (re-scaled) (by means of a re-sizing handle on bottom right corner of frame. PRESS and DRAG B1)

• full internal toolbox

• can be panned or scrolled (standard window management scroll bars, slider PRESS and DRAG B1, incremental buttons, CLICK B1)

• high priority on invocation (below General Toolbox)

• square corners

• The position, size and parameters, including Toolbox, saved inpreferences set

• colours as defined in the master colour chart for windowmanagement functions (See Appendix 3 &4).

FLEX

GENERAL TOOLBOX

VAW PREFCRDPVD 12:26:10

Figure 4.1: General Toolbox showing Restrictions on the RPVD Icon

(Actual Size)

4.3.2.2 The RPVD cannot be iconified in the conventional sense. It must always bepresent on a display surface at the work position. There will be no close boxon the namebar. The optional mechanism for moving the RPVD from onescreen to another in two screen systems is by CLICKING B1 on the RPVDicon/button within the General Toolbox on the destination screen. However,since clicking on a depressed button on the tool will not result in iconisation,there should be some mechanism which clearly indicates this fact to the user.It is suggested that a diagonal red/brown slash (RGB% 62, 21, 20) be placedbehind the text on the depressed button to show that a click on this location



will have no effect. This is illustrated in Figure 4.1. Similarly, any attempt toCLICK B1 on the depressed button might briefly show the caution cursor.

4.3.2.3 Movement of the window operates in the following way. The window will beremoved from the sending screen and redrawn in the same location on thereceiving screen. The depressed RPVD icon/button in the General Toolbox ofthe sending Screen will be raised and the raised icon/button in the GeneralToolbox of the receiving screen will be re-drawn in the depressed form.

4.3.2.4 All other window management mechanisms operate as described in Chapter 3.

4.4 Toolset

4.4.1 Tools

4.4.1.1 The RPVD has a full dedicated toolset within a toolbox which can be invokedfrom an icon normally positioned within the display area of the window in thetop left-hand corner. The Radar Toolbox follows exactly the same principlesand forms as the General Toolbox and has the same attributes except that it isa child window of the RPVD and that its priority remains within the RPVDsub-stack. It can be moved anywhere within the confines of the RPVD.

4.4.1.2 The toolset within the Radar Toolbox consists of the following functions,which were provided in ODID IV:

• Zoom in/out

• Predetermined radar set up

• Map set tool (what to show)

• Label overlap removal

• Speed Vector/Track History

• Height Filter

and two functions which were augmented for PD1 and the REFGHMI:

• Bearing & Distance

• Modes (Access to the Range and Bearing tool + Tracker LinkTool).

4.4.1.3 In the REFGHMI, the tool functions are structured differently. This in partreflects the actual pattern of use observed in the ODID IV simulation but alsoreflects the limitations on the maximum size of the radar which may resultwhen multiple screen systems are employed. The general organisation of thetoolbar is shown in Figure 4.2

4.4.1.4 In the REFGHMI, each of these tools can be used independently. This meansthat each tool can be left open whilst the Radar Toolbox itself is closed. Tomake an individual tool independent , it has to be isolated. The procedure isas follows: the Zoom function, the Height Filter function and the Speed andTrack function can be moved out of the Radar Toolbox area directly by a B1Press and Drag on their header. The other functions (Map, Label,...) have to beopened first and then can be moved out of the Radar Toolbox area. After anindividual function has been isolated, the Radar Toolbox can be closed by aB1 on its own close box leaving an exemplar of the isolated tools within the



RPVD. When the isolated function is closed by a B1 CLICK on its own closebox, it is automatically replaced back within the Radar Toolbox.

RADAR TOOLBOX

MAP MENU LABEL MENU OVERLAP MODES

T rack His tory

Speed Vect orS PE E D and T RACK

3 350 7

2 3 4 510Lower UpperHE IGHT F IL T E R

2 4 0 4 9 0

ZOOM

2 2 6 4 0 0

SAVE

Figure 4.2: The Radar Toolbox as planned for initial implementation in the REFGHMI

(Not to Scale. Reduction can be judged by comparison with Fig. 4.3 below)

4.4.1.5 When a tool has been displaced from the toolbox, its point of origin shows ablank space in the Window Blue Depressed colour, with the name of the toolin Black. A click of B1 on that blank location will make the tool re-appear atthat location, removing the displaced exemplar. In the case of a menu tool, themenu will be open.

4.4.2 Zoom Function

4.4.2.1 The Zoom function is essentially similar to that provided in ODID IV (seeFigure 4.3). It consists of a conventional slider bar which is operated by aPRESS and DRAG operation of B1. As the slider moves the range in nauticalmiles corresponding to the x aperture of the RPVD is shown in a black‘Geneva’ 12 point bold font (or similar) above the slider. The value changesas the slider is moved and increases from the left to the right. As far aspossible, the radar picture is redrawn to keep track of the slider. The optionalrange markers on the bottom and left-hand edges of the frame (§4.5.2.7) willalso need to be redrawn.

ZOOM

226 400

SAVE

Figure 4.3: The Zoom Tool (actual size), showing one pre-set valuestored for future use.

4.4.2.2 In addition to the ODID IV functionality, the REFGHMI slider incorporates anumber of additional features. ODID IV used three buttons that could be usedto provide access to pre-defined zoom settings. The functionality thusprovided, is incorporated into the Zoom for REFGHMI by the addition of theSAVE button illustrated in Figure 4.3 This operates as follows:

• CLICKING B1 on the save button stores the current Zoomsetting for future access. This has secondary consequences:



a) The SAVE legend on the button changes to DEL(short for delete) and from black text to white text

b) If the slider is moved away from the location a thingrey line (RGB% 20,20,20) is drawn to correspondto the centre of the stored cursor position. Further, asthe text associated with the slider moves away withthe slider, the value of the saved position appears inWHITE at its original location. It may be necessaryto vertically stagger these values if pre-sets aredefined very close together although it is difficult toimagine any reason why a controller should chose todo this.

• CLICKING B1 on the White text, corresponding to a savedsetting, results in the Zoom slider jumping to that value and theradar picture being redrawn accordingly.

• The button legend reads DEL whenever the slider is at a savedsetting and reads SAVE otherwise. (Unless the save set is full,see below.)

• If B1 is CLICKED on the DEL button, that selection isremoved from the stored save set and the button legendbecomes SAVE. The fact that the value is currently selecteddoes not change.

• It may be advisable to set a maximum number of pre-sets atany one time. In this case, the legend of the save button will beblank when three selections have be made except that, whenthe Zoom is set to a pre-set, it reads DEL.

4.4.2.3 PLEASE NOTE, that this form of pre-set is of limited application. It does notcope with circumstances where an offset of the display centre is required as analternative view. OPTION: If such a function is required, it could beprovided via a pop-up menu invoked by a CLICK of B3 on the slider to permitselection of a suitable display centre to be associated with that saved value.

4.4.2.4 The Zoom slider is shown actual size in Figure 4.3. It is drawn with standardREFGHMI highlighting and shading conventions. The colour specificationsare:

4.4.3 Height Filter

4.4.3.1 The Height Filter Tool has exactly the same functionality as in ODID IV. Thetool is illustrated in Figure 4.4. A single slider track supports two sliders eachwith an associated selected value shown in flight levels. The left hand sliderrepresents the lowest flight level to be displayed on the RPVD, the right handslider, the highest Flight Level. Sliders are operated via PRESS and DRAG ofB1. The range of the tool (max/min) values would be defined by operationalrequirements. The RPVD should be updated as quickly as possible to reflectchanges. The cursor should change to the wait cursor until the display hasbeen updated.

4.4.3.2 The colours employed are identical to those for the Zoom Tool §4.4.2.4.

4.4.3.3 In ODID IV the height filter only applied to the aircraft in the unconcernedcategory and it applied over the entire airspace viewed in the RPVD. If theuser of the REFGHMI wishes to apply height filters to all aircraft, as is



possible with current equipment, it is suggested that two radio buttons, bearingthe legends U/C and ALL could be added to the height filter tool. These couldbe used to switch the same input device between one function and the other.The sliders would jump to appropriate positions when switched, and marks,like those for stored values in the zoom tool, could be used to indicate thecurrent values of the unselected option.

Lower UpperHEIGHT FILTER

240 490

Figure 4.4: The Height Filter Tool (actual size).

4.4.4 Radar Pre-set Selector

4.4.4.1 This function is provided by the Zoom Tool, §4.4.2.2

4.4.5 Mapset Tool (Map Menu Window)

4.4.5.1 This tool is represented by a Button/icon bearing the legend MAP MENU. It isoperated by a single CLICK of B1, within the Toolbox1. In keeping withconvention established for the General Toolbox, Icon/Buttons for taskwindows are in Fawn and those for menu/control windows, like the MapMenu, are in the general WINDOW BLUE colour. The CLICK of B1 resultsin the Map Menu button being shown as depressed and the Map MenuWindow (Figure 4.5) being displayed with the handle/name bar immediatelyabove the button.

4.4.5.2 The attributes for the Map Menu Window are:

• child window (restricted to the RPVD sub stack)

• non iconifiable (on close reverts to Toolbox item)

• closeable (close box top left)

• moveable (B1 move handle/title bar. Within radar window only. This also moves it to the ‘top’ of the radar window sub-stack)

• fixed size (by number of menu items)

• non-modal



• high priority on opening (within RPVD sub-stack below message windows)

• square corners

• status saved with preferences set



• Special: appears with handle/namebar superimposed on theinvoking key, i.e. directly under the cursor.

• colours as defined in the master colour chart for windowmanagement functions (See Appendices 3 &4)

4.4.5.3 The Map Menu Window consists of a Move handle name bar (operated by thestandard PRESS and DRAG of B1) and a list area with names and switchboxes for SECTOR, WAYPOINTS, WAYPOINT NAME, AIRWAYS,MILITARY (or RESTRICTED as operationally preferred), COASTLINE andRANGE RINGS. Any other system functions relating to the display of mapinformation would be added to this location.

4.4.5.4 Switch Boxes are distinguished from Radio Buttons (§4.4.6.4) in that they canall be set independently. Only one radio button can be selected at a time.Colour is used to distinguish the two categories. Switch boxes are always inWBlue Highlight (RGB% 64,75,86) with a BLACK ‘N’ character inside toindicate the NO or OFF state and in WBlue Depressed (RGB% 24,35,24) witha WHITE ‘Y’ inside to indicate the YES or ON state. CLICKING B1 on anySWITCH BOX toggles its state.

Sector

Waypoints

Airways

Military

Coastline

Y

Y

N

N

N

NR-Rings

MAP

NScale Line

Figure 4.5: The Map Menu Window of the Radar Toolset (actual size).

(The misalignment of the text in the boxes of the illustration is an artefact ofthe graphical importation process)

4.4.5.5 OPTION: CLICKING B1 on the text field associated with the box has thesame effect. Effectively the receptive field for input is a bar the entire widthof the menu.

4.4.5.6 OPTION: (If §4.4.5.5 is implemented) As the cursor is moved over thereceptive field, the text, corresponding to the field, highlights by switchingfrom Black to White while the cursor is in that region. Alternatively, ahighlighting could be applied to the background of the text field.

4.4.5.7 When a selection is CLICKED ON or OFF, it comes into effect immediately.If this is not possible it should be implemented by the next radar update at thelatest.



4.4.5.8 The SECTOR Switch causes presentation or removal of the layer showing thearea of a sector. Sector area is presented as a transparency of approximately70% transmission over the background land/sea map. This is achieved byusing the colour values described in §4.5.2.

4.4.5.9 The WAYPOINTS switch causes waypoint beacons to be displayed orremoved from the display. The ability to display waypoint names and symbolsseparately is provided by the WAYPOINT NAME switch. Colours are asdefined in §4.5.2.

4.4.5.10 The AIRWAYS switch causes display or removal of lines indicating routes,contours as defined in §4.5.2.

4.4.5.11 The MILITARY switch causes the display or removal of restricted areas.

4.4.5.12 The COASTLINE switch causes the presentation or removal of the coastlineinformation. Since the coastline is shown by different coloured infills for thesea and land regions, removal of the coastline is implemented by changing allof the map background to the land infill (RGB% 36,34,34).

4.4.5.13 The R-RINGS switch causes display or removal of concentric range rings fromthe RPVD. The rings are drawn at 10 nautical mile intervals (or five ifoperationally preferred).

Figure 4.6: One version of a Scale Marker. Each axis is 15nm in lengthmarked at 5nm intervals (see §4.4.5.14).

4.4.5.14 The SCALE LINE switch causes display or removal of a scale line. One, quiteelaborate, option is illustrated in Figure 4.6. Each of the diagonal axes of thescale line represents 15 nautical miles and is marked off at 5 nautical mileintervals. (This may need revision. It may be better at 10 miles per axis). Thehandle box in the middle is at least 6.0mm square. The scale line and thehandle are drawn in BEACON GREY (RGB% 65,65,65). The scale line canbe moved by PRESS and DRAG of B1 on the central handle box within theRPVD. In terms of priority is should be treated as ALWAYS lying at thebottom of the RPVD sub-stack except while being moved.

4.4.5.15 The order of the menu items is derived from that employed, without difficulty,in ODID IV. It may be changed if significant justification arises duringpreliminary testing of an interface.

4.4.5.16 The Map Menu Window remains open until it is specifically closed byCLICKING B1 on close box, (or by CLICKING B1 on the depressed MAPMENU button in the Toolbox).

4.4.6 Label Overlap



4.4.6.1 Label overlap resolution is supported by a variety of mechanisms. Some ofthese are provided by the general HMI principles employed, e.g. the ability topick and move an individual label directly (§4.8.1.4) and the fact that a labelconverts to an opaque form when the cursor is positioned within its text area(§4.7.2.6). Both these mechanisms support the extraction of information fromoverlapping aircraft information. However, there are two additionalmechanisms supported through the Toolbox. These are:

• access to an Automatic Label Overlap Resolution algorithm

• the ability to set the global orientation and leader line length ofall labels.

4.4.6.2 These options are accessed by CLICKING B1 on the OVERLAP Icon/Buttonin the Radar Toolbox. This causes the appearance of the Overlap MenuWindow shown in Figure 4.7 as well as ‘depression’ of the Overlap button inthe Toolbox. This menu has two forms depending on the status of theAutomatic Label Overlap Resolution algorithm. These are both shown in theillustration. The attributes of this window are identical to those for the MapMenu Window (§4.4.5.2).

4.4.6.3 When the auto resolution is switched on, the menu takes the form shown in theleft-hand illustration2. There are two regions, the standard handle/namebarand a single Switch Box for controlling the Automatic resolution algorithm.This box is operated by a CLICK of B1 and toggles between ON and OFF withthe standard switch box colour changes as defined in §4.4.5.4.

4.4.6.4 When the value is set to OFF, the menu is redrawn to the form shown on theright-hand illustration incorporating two additional regions. The first regionconsists of three radio buttons3 for selecting the length of the leader linebetween an aircraft symbol and its label. These are drawn in slider/icon Fawn(RGB% 68,57,41) with highlights (RGB% 88,77,61) and shadows (RGB%20,20,20). Single BLACK letters in a suitable font (S, M and L), indicateshort, medium and long leader lines respectively4. These are organised fromleft to right. Selecting a radio button by CLICKING B1 causes it to beredrawn in the appropriate depressed button colour (RGB% 48,37,21) with theshadows and highlights reversed. The text label changes to white. Any otherprevious selection is redrawn in the normal, de-selected form.

4.4.6.5 Beneath the leader length selection function, there is another set of eight radiobuttons arranged in ‘snowflake’ pattern to permit selection of the labeldirection relative to the aircraft symbol. The operating principles are identicalto those for the leader line. Selection is by a single CLICK of B1. Selection ofany value, deselects any other. All labels are redrawn in the appropriatepositions as soon as possible.



LPOSIT

ON

S M L

OFF

LPOSIT

AUTO is AUTO is

Figure 4.7: The Menu for Label Overlap Tool.

Note the two forms. The second form appears only when Auto is switchedto OFF.

4.4.6.6 When the Auto resolution algorithm is switched on, the most recent settingson the collective leader tools are stored against return to manual settings. Are-invocation of the manual settings also resets any labels that have beenindividually manipulated by the controller. However, any subsequentmanipulations by the controller hold good.

4.4.6.7 The menu is closed by CLICKING B1 on the close box of the window (or byCLICKING B1 on the depressed OVERLAP MENU button in the Toolbox).

4.4.7 Speed Vector-Track History

4.4.7.1 Like the Zoom Function and Height Filter, the Speed Vector - Track Historytool is permanently available while the Radar Toolbox is open. The tool isillustrated in Figure 4.8.

Track History

Speed VectorSPEED and TRACK

3 350 7

3 4 50 21

Figure 4.8: The Speed Vector/Track History Tool, actual size.

4.4.7.2 It consists of two identical rows of buttons one for the Speed Vector functionthe other for the Track History Function. For the Speed vector there is a row ofsix standard radio buttons labelled 0 a 5, for the Track History there are 4 radiobuttons labelled 0,3,5 and 7. In the case of the Speed Vector, the buttonsselect a heading vector of from 1-5 minutes flight time in extent. Selecting the‘0’ means that no heading vector is displayed. Similarly, for track history, thebuttons represent between 1 and 5 radar updates with the ‘0’ value meaningthat no history is displayed.



4.4.7.3 Colour and operational conventions are as defined for radio buttons above.

4.4.7.4 Following a change in setting, the radar picture should be updated as soon aspossible.

4.4.8 The Modes Menu (Access to the Bearing and Distance tool +Tracker Link Tool).

4.4.8.1 These two tools are grouped together, since they both require that the systemswitch into a ‘mode’ for their operation. While in the relevant modes, no othertype of input is possible until the mode is exited.

4.4.8.2 Both tools are accessed by means of the same modes menu which is invokedby CLICKING B1 on the icon/button labelled MODES in the Toolbox. Theattributes are identical to those of the MAP and OVERLAP menus except forthe fact that modes are involved. The resulting menu is shown in Figure 4.9.

4.4.9 Operation of the Range and Bearing Tool

4.4.9.1 The function of the Range and Bearing Tool is to provide a read out of bearingand distance as measured from one point to another.

R & B

MODES

OFF

TRACKERSELECTING

(c) (d)

R & B

MODES

OFF

TRACKEROFF

(a)

R & B

MODES

ON

TRACKEROFF

(b)

R & B

MODES

OFF

TRACKERON

Figure 4.9: The Modes Menu:

(a) on invocation, (b) during operation of the Range and Bearing Tool, (c) during setting ofthe Tracker, and (d) while the Tracker is in operation.

4.4.9.2 The R&B tool is activated by CLICKING B1 on the READY Switch box inthe R&B Tool area of the MODES Menu.

NOTE: That an important difference between Switch Boxes and buttons isthat switch boxes provide a more flexible means of monitoring the state of thefunctions associated with them. Buttons indicate only two states but switchboxes can be treated as small displays. This is the case in the presentutilisation of the switch boxes for the Range and Bearing and the Trackertools.

4.4.9.3 The OFF Box immediately toggles to the activated background and WHITEText reading ON appears in the BOX. (Figure 4.9(b)).

4.4.9.4 The cursor changes to the sighting cursor form but in a (Warning) YELLOW(RGB% 100,90,12) Figure 4.10(a) to emphasise the modality of the followinginteraction. To perform the function the cursor is initiallyy positioned on the



screen object, or point from which the bearing has to be taken and B1 isCLICKED. This causes a small cross (X character?) in the same yellow colourto be draw at the location and an elastic vector to be created between this crossand any subsequent position of the cursor. As the sighting cursor is movedthere is a continuous readout of its bearing and distance from the fixed point.This readout will be presented in a Geneva font (RGB% 100,90,12) in twolines in the form:

xx Distance in nautical miles

yyy Absolute heading in degrees

4.4.9.5 This is displayed at a position to be determined next to the sighting cursor(perhaps immediately below).

4.4.9.6 CLICKING B1 again causes a new point of origin to be established and erasesthe previous one5.

4.4.9..7 CLICKING B3 anywhere cancels the function and the mode. Similarly,CLICKING B1 or B3 on the R& B area, cancels the function and the mode.Cancellation of the mode causes the Switch box to revert to the OFF state (Fig.4.9(a)) and the cursor to revert to the normal pointing form.

4.4.9.8 This function requires essentially the same mechanisms as the elastic vectorfunction for aircraft heading manipulation described in §4.8.10.

4.4.10 Operation of the Tracker Link Tool

4.4.10.1 The function of this tool is to allow the linking of two aircraft, or an aircraftand a fixed point, in order to permit monitoring of the change in relativeheading and distance over time. This tool was not available in ODID IV. Theomission was noted by controllers. Only a single instance of the Tracker Linkis available at any one time on the RPVD of the REFGHMI.

4.4.10.2 The required mode is slightly more complex than that for the R&B toolbecause two points must be selected successively. This requirement meansthat it is not possible to use an overwriting correction mechanism forerroneous target selections and a more elaborate technique is provided. Thedifference in behaviour of the two modes is significant and must be clearlyindicated to the controller (in this case by a difference in the form of thecursor, see Figure 4.10). The suggested mechanism has not been tested andthe possibility that revision will be required is recognised.

4.4.10.3 Initiation of the function/mode is similar to that for the R&B tool. B1 isCLICKED on the OFF Switch Box in the Tracker Area. The Switch boxchanges to SELECTING and the cursor changes to the form Figure 4.10(b) inWarning Yellow (RGB% 100,90,12). CLICKING either B1 or B3 on theSwitch Box at this point aborts the mode and restores the status quo.

(a) (b)

Figure 4.10: Possible Cursors for the R&B Function Mode (a), and the Tracker Link (b).



4.4.10.4 The first point is selected by pointing the cursor at a suitable screen object(aircraft symbol, beacon symbol or route intersection) and CLICKING B1.The selected object is redrawn in YELLOW (RGB% 100,90,12), i.e. theaircraft symbol, the beacon symbol or the point of intersection. An elasticvector (single pixel dashed line) in Warning Yellow is created from theselected object to the cursor.

4.4.10.5 To undo the selection, it is necessary to move the cursor back onto the objectand CLICK B3. In order to do this it may be necessary to highlight the objectto provide feedback as to its selection. (Perhaps by changing the target objectto white when selected.)

4.4.10.6 The second point is selected in the same manner as the first, and is alsoredrawn in yellow (the modal colour). The elastic vector now connects thetwo points and continues to do so as the radar updates. The range and bearingof the second object from the first is displayed at the second object in the sameway as for the elastic vector. At this point both selections can still bemodified6 by CLICKING B3 on either one which deselects it and CLICKINGB1 on another object

4.4.10.7 The mode is exited at any time by CLICKING B3 with no object selected. Ifthe input sequence has not been completed by selecting two objects there is noTracker link on the screen and the Switch box returns to OFF.

4.4.10.8 If the input has been completed, the Tracker link remains active on the RPVDand the Switch Box turns to ON. The link is displayed even if the Mode menuwindow is closed, until the last of the aircraft concerned have left the sector, orB1 is CLICKED on the ON Switch Box within the menu. At this time, theselected objects revert to their normal colour coding and the elastic vector,range data and heading information are removed.

Freq

Type

Company

Depart

Destinat

Y

Y

N

N

N

LABEL

Figure 4.11: The Label Menu Window.

4.4.11 The Label Menu

4.4.11.1 This facility was not requested as part of the requirement of the PHARE PD1Reference System but was available in ODID as a series of separate toolbuttons that could switch on additional information, within the radar label.With the facility to produce the extended label provided by B3, these buttonswere seldom used by controllers familiar with the airspace, however, visitingcontrollers from the FAA participating in ODID IV, found them very helpful.



If the REFGHMI is to employ controllers not familiar with the airspace theremay be similar advantages.

4.4.11.2 The Label menu window is invoked in exactly the same way as the Map menuwindow §4.4.5, and it has exactly the same attributes and behaviour. Its formand the available menu items are shown in Figure 4.11.

4.4.11.3 Selection of items in this menu causes them to be displayed (if available)within the labels of all aircraft on the display. The locations of informationcorrespond to the general ODID type plan for label layout summarised in§4.7.4.4, i.e. mainly in line 5.

4.5 Window Contents

4.5.1 General

4.5.1.1 The overall colour table for the RPVD is provided as part of the Master ColourTable in Appendix 4. The actual names quoted are those employed inREFGHMI Master Palette of the MacDraw Pro™ Mock-up from which all theillustrations in this document are drawn. This palette can be made availableon request. Where appropriate, references to the NATS palettes described in[20] are provided.

4.5.2 The Background ATC Airspace Map

4.5.2.1 The background ATC Map will depend on the airspace of interest to theimplementor. The broad details of representation are as follows.

• general non-sector land mass is shown as shaded inLANDMASS (RGB% 36,34,34, NATS Opaque BackgroundPalette L1, Red 35).

• large bodies of open water are shown as WATERMASS(RGB% 39,39,41, NATS Opaque Background Palette L1, Blue40%).

4.5.2.2 Sector boundary information is selectable from the interface (Mapset tool§4.4.5). If sector boundary is selected, then:

• sector land mass is shown as (RGB% 39,37,37) SECTOR ONLAND

• open water within sector is shown as (RGB% 42,42,42)SECTOR ON WATER.

4.5.2.3 Display of beacons and fixed waypoints is selectable from the Mapset Tool(§4.4.5)

• All beacons and waypoints are shown by the same symbol, anunfilled equilateral (or isosceles) triangle of minimum altitude6mm and drawn in BEACON (RGB% 65,65,65: NATS L2,Grey 65).

• Descriptive text is shown by the appropriate waypointdesignator drawn in Geneva 12 Point, BEACON (RGB%65,65,65: NATS L2, Grey 65).



• IMPLEMENTATION OPTION: Some requirements identifythe need to highlight beacons. If there is truly a requirementfor individual beacons to be highlighted, this can be achievedby CLICKING B1 which will toggle the infill of the beaconsymbol also in the BEACON colour.

• IMPLEMENTATION OPTION: The individual beacon name(and other beacon information if required) can be toggled on oroff by clicking button B3 with the pointing cursor on thebeacon.

4.5.2.4 Route and Airway Information. It will be possible to display general routestructure information by selecting an option in the MAP MENU Tool.

• When routes are selected, they will be displayed a single lines(1-2 pixels) linking, but not touching, waypoints.

• They will be drawn in BEACON, (RGB% 65,65,65: NATS L2,Grey 65).

• If multiple categories of route are required, a second class mayprovided by drawing ‘major’ routes with a thicker (2-3 pixels)in (RGB% 44,46,48).

4.5.2.5 Airfields

• Airfields are shown as waypoint/beacon triangles with a thinline in the beacon colour showing the extended centreline andorientation of the runway.

• Colours and fonts are as for beacons and fixed waypoints

• IMPLEMENTATION OPTION: The individual airfield namecan be toggled on or off by clicking button B3 with thepointing cursor on the beacon associated with the airfield.

4.5.2.6 Control of the display of all these functions may be made through the MAPMENU window invoked from the Radar Toolbox.

4.5.2.7 Optionally, there will be a series of scale (or distance range) markers along thebottom and left hand sides of the window at intervals of 10 Nm. The intervalmay require modification to reflect the size of the sectors under simulation.This element was specified for ODID IV but not implemented. Controllerssubsequently indicated a need for some form of scale reference. Thesemarkers will need to be redrawn to correspond to the Zoom Function in theRadar Toolbox §4.4.2. It is suggested that they take the form of small, inwardpointing triangle in the window frame colour (Window Blue, RGB%36,34,34).

4.5.2.8 Additionally, there will be a number of child windows which, while movable,must remain within the confines of the main RPVD. These include:

• Sector Inbound Lists (SILs)

• The RPVD Toolbox and any of its element windows which thecontroller chooses to leave open.

4.6. Class of Aircraft: The ODID Task RelatedPresentation



4.6.1 General

4.6.1.1 In ODID IV colour was employed to distinguish between aircraft in terms oftheir status within the controller’s task activity. There were five task statesshown by the colour of the label text on the RPVD7.

• Other or Non Concerned8

• Advanced Information State

• Assumed State

• Concerned State

• Co-ordination

In addition colour was employed to indicate a number of other ‘Urgency orWarning’ conditions. These are:

• Short Term Conflict Alert

• Manual Warning Input9

• Alert

4.6.2 Description of Encoded Task States

4.6.2.1 The same Categorisation of states will be employed for the REFGHMIbaseline Reference System The following paragraphs, which describes thesestates in more detail, is based closely on [8] §7.4.1 onwards. Two values aregiven for each of the aircraft states reflecting the form of display when thecursor lies outside the label area and when it lies within it (See §4.7.1.2/4,Selected Aircraft Form).

4.6.2.2 NOT CONCERNED: This applies to aircraft that are not being worked bythe sector, e.g. they lie outside the sector. These aircraft can be selectivelyfiltered out from the controllers display (§4.4.3.3). It may be that there is anadvantage in introducing two levels of Not Concerned, those which are neverconcerned and those which, according to the flight plan will eventuallybecome concerned (i.e. not yet concerned). Aircraft that have beentransferred but still are physically within the sector airspace are describedunder Concerned State in §4.6.2.6 below.

• In ODID IV the radar labels for these aircraft were shown inGREY

• In the REFGHMI they are shown as:

a) ‘ BEACON GREY’ text RGB% 65,65,65

b) Black text on ‘CRD BACKGROUND’ RGB% 48,45,45

4.6.2.3 ADVANCED INFORMATION STATE10: These are aircraft for which theplanning information has been received and on which it is legal to begin entrycondition negotiations. For the REFGHMI (as in ODID IV) advanceinformation is received automatically 10 minutes (parameter) prior toSECTOR ENTRY. At the same time as an aircraft is converted to theadvanced information state, the label on the previous sector displays the nextsector symbol.

• In ODID IV the radar labels for these aircraft were shown inPINK




a) ‘ADVANCED PINK’ RGB% 92,68,68

b) Black text on ADVANCED PINK RGB% 92,68,68

Note: It is possible that this advanced information can be made availableearlier by the use of the Forced Act option on the callsign menu by theprevious sector (§4.9.6).

4.6.2.4 ASSUMED STATE: These aircraft are on frequency and have beenassumed, i.e. they are under the sector’s current control or are in the process ofbeing taken under control.

• In ODID IV the radar labels for these aircraft were shown inBLACK


a) WHITE RGB% 100,100,100

b) Black text on WHITE

This change has been made to provide better contrast against the backgroundbut also to reserve BLACK text for the infilled label state which does not existin ODID (See §4.7.1.2/4, selected aircraft state).

4.6.2.5 CONCERNED STATE: This is traffic that concerns the controller but is notcurrently under the sector’s active control. Examples would be skipped trafficthat has not cleared the sector, traffic in a shared airspace that is controlled bya team, or traffic that has been transferred out (see §4.6.2.2) but which has notyet physically cleared the sector.

• In ODID IV the radar labels for these aircraft were shown inMUSTARD

• In the REFGHMI they are shown as

a) CONCERNED MUSTARD RGB% 72,61,28

b) Black text on CONCERNED MUSTARD RGB%72,61,28

4.6.2.6 In addition to the planning states of the aircraft, there are a number of otheroperational states which can apply to aircraft or to information relating toaircraft. These are described in §4.6.3 (Coordination) and §4.6.4 (Urgencyand Warning Conditions)

4.6.3 Coordination

4.6.3.1 Information which is the subject of coordination proposal or response ispresented in the Co-ordination Colour. This colour applies to any itemwhich is the subject of co-ordination and is used wherever the item isdisplayed (message window, radar label, sector inbound list, etc.).

• In ODID IV these items were shown as WHITE

• In the REFGHMI they are shown as COORDINATION PINKRGB% 100,41,60

4.6.3.2 This change complements the use of WHITE as the ASSUME Colour.

4.6.4 Urgency/Warning Conditions



4.6.4.1 Additional colours are used to indicate abnormal situations to which thecontroller should pay attention. These are as follows.

• RED (RGB% 100,10,10, NATS L6 palette) is used universallyto indicate very high priority and potential danger conditions ofan operational nature.

• YELLOW (RGB%, 100, 90, 12, NATS L6 palette) is useduniversally to indicate any form of warning condition.

4.6.4.2 There following paragraphs describe the main urgency and warningconditions in the REFGHMI

4.6.4.3 Short Term Conflict Alert (STCA)

4.6.4.3.1 When the STCA detects an imminent loss of radar separation in en routesectors (called Area Control in ODID IV) a 2-3 minute warning can beprovided.

• In ODID IV this was done by changing the text of the callsign,within the label, to red.

• In the REFGHMI this will be achieved by an alternative meansas the red text was not particularly legible just at a time whenmaximum rate of information extraction was required. Further,it was not favoured by all controllers. The primary candidatemechanism at the moment is that the labels of the relevantaircraft will switch to the NATS Interim Standard form forSTCA. At present that means that the label switch to aninfilled RED background11 (RGB% 100,10,10, NATS L6palette) with WHITE text. The use of a white frame for thelabel, as described in the NATS standard, is noted as apossibility but will be reserved until more detailed mock-upsare available.

• If this option proves too strong, an alternative would be to turnthe aircraft symbols and speed vectors from BLACK to REDand perhaps additionally, surrounding the aircraft labels withRED frames. This would have the advantage of preserving allthe other information on aircraft planning state present in thelabel.

• If the infilled solution is chosen, the SELECTED state of thelabel (§4.7.2.3) will be the same as if it was not in conflict, i.e.the label will reflect all the normal planning and coordinationinformation.

4.6.4.3.2 Red is also used to indicate segments of aircraft trajectories which are inconflict when these trajectories are displayed in the Conflict ZoomWindow or the Dynamic Flight Leg.

4.6.4.4 Warning Conditions

4.6.4.4.1 There are several types of warning condition available through theREFGHMI.

• manually input warning on a conflict pair

• Inter console marker/manual warning on a single aircraft



• Alert: the indication that an aircraft is ready to exit the sectorwithout having been cleared to its intended Exit Flight Level(XFL).

4.6.4.4.2 The aide memoire function (§4.6.4.4.6), which can be thought of asrelated to these functions , does not incorporate a warning element andconsequently does not use the warning yellow colour in its codingmechanism.

4.6.4.4.3 The manual input warning on a conflict pair is input by a CLICK of B1on the Conflict Letter relating to a conflict. This causes the callsign ofboth aircraft in the pair to change to Warning Yellow in the normal labelstate and to Black Text on a yellow background in the selected labelstate. This change operates anywhere within the sector where the radarlabels of these aircraft are displayed. The warning is removed by afurther CLICK of B1 on any instance of the Conflict Letter. The usualapplication of this function would be for the PC to draw the attention ofthe TC to a potential conflict which has not been removed at the planninglevel.

4.6.4.4.4 The inter console marker serves a similar function but is used to drawattention to single aircraft rather than conflict pairs. It is invoked lessdirectly via CLICK of B1 on the WARNING FIELD of the ExtendedLabel Window (ELW). This causes the symbol and heading vector of theaircraft in question to change to the warning yellow colour. Normallythis could be removed by a further CLICK of B1 on the warning field ofthe ELW, but if the usage of the function demands a more direct method,CLICK of B3 on the aircraft symbol could be used to remove thewarning. (Note: the interaction of this with aide memoire interactiondescribed in §4.6.4.4.6).

4.6.4.4.5 Alert: When an aircraft has been transferred to the next sector/controllerwithout receiving clearance to its Exit Flight Level, the CFLautomatically shows in YELLOW (RGB%, 100, 90, 12, NATS L6palette).

4.6.4.4.6 In the PD1 development, an additional aide memoire function was addedat the request of controllers which allowed the local (within one displayonly) marking of an aircraft as a mnemonic that something should bedone or monitored concerning this aircraft. This can be considered asanalogous to the ‘cocking’ of a paper flight strip holder. The mechanismfor this is simply CLICK B3 on the aircraft symbol which produces ablack ring drawn around the circular symbol. The ring is removed by asubsequent CLICK of B3. Note that if additional mechanism suggestedfor removal of the inter console marker (§4.6.4.3.4) is implemented, thereis a potential conflict of inputs. The resolution initially suggested is that,if an inter console marker has been allocated, a CLICK of B3 on thesymbol removes it. Subsequent CLICKS of B3 would add and removethe aide memoire. If the aide memoire was already in place when theinter console marker was invoked from the ELW both symbol and ringwould change to Warning Yellow and a subsequent CLICK of B3 on thesymbol would remove both warnings (on the basis that the aide memoirecan be re-invoked very easily).



4.7 Aircraft Track and General Characteristics ofLabels

4.7.1 Main Elements of Aircraft Track

4.7.1.1 The radar track will consist of:

a) Plan Position Symbol (filled circle). Note that this symbolmust be big enough to be acquired as a selectable object bythe mouse12.

b) Lead Line connecting radar label data block and plan positionsymbol.

c) Speed (or Heading) vector of 0 to 5 minutes length selectablefrom within Radar Toolbox.

d) Trails (history dots/afterglow) 0/3/5 dots. Selectable fromwithin Radar Toolbox

e) Data block (radar label - possible five lines of data, 1 to 5).

4.7.1.2 In ODID IV the position symbols, lead lines, speed vectors and trail dots wereshown in WHITE for all states except ‘not concerned’ where they are show inthe same GREY as the text of the ‘not concerned’ label. In the REFGHMIsymbols, speed vectors and trail dots will be black. The leader line is inWHITE and of a lighter weight (thinner) than the heading speed vector.(OPTION: It can be decided at a later date if the speed vector and symbol forunconcerned traffic should be shown in the same ‘BEACON GREY’ as thetext. This was done in ODID.)

4.7.1.3 The acquisition area of a radar label is a rectangular area large enough toembrace all the text associated with that label with a margin such that if aborder were drawn showing the limit of the acquisition area, the legibility ofthe text would not be impaired by proximity to the border.

4.7.1.4 When the pointing cursor enters the acquisition area of an aircraft data block,that data block changes to the NATS type infilled label with the appropriatebackground colour and text colour for that aircraft task state (§4.6.2.2 -§4.6.2.5). The limits of the infilled region and the boundary of the acquisitionarea described in §4.7.1.3 will correspond where appropriate. This is referredto as the SELECTED Label State (See §4.7.2.3 below). When the cursor exitsthe acquisition area, the label reverts to its original form.

4.7.1.5 Where two aircraft data blocks overlap, the block that is highlighted will bethe block whose acquisition area, the mouse pointer first entered. To selectanother label the cursor must exit the initially selected label.

4.7.2 The Different Forms of the Radar Label

4.7.2.1 The radar label text will appear in a number of different forms bearingdifferent colour codings. The different forms are related to both the processesof interaction with the fields of the aircraft label and the state of the aircraft.The Forms available are:

• SELECTED, and

- STANDARD



- EXTENDED

- MINIMUM

4.7.2.2 The last three options all relate to the amount of information that can bedisplayed on an aircraft at different times or in different conditions. The notion of SELECTION can be potentially applied to aircraft in each of the otherstates and relates to the intention to interact not only with the aircraft label but,where appropriate, with the aircraft itself. The interface supports the notion ofTHE CURRENTLY SELECTED AIRCRAFT, i.e. the aircraft whose data thecontroller is currently examining or modifying. The concept is introducedhere both for convenience and because the RPVD and the Radar Label inparticular are the primary locations for the SELECTION of aircraft. The maincharacteristics of SELECTION are:

a) SELECTION is a condition which applies across the wholeinterface, i.e. there can only be one currently selected aircraftat any instant within the interface of a single controller.

b) An aircraft can be SELECTED by placing the cursor on thelabel of that aircraft, on the aircraft symbol, by interactingwith the aircraft in the Sector Inbound List or the MessageWindows, or anywhere that that aircraft is uniquely identified.

c) SELECTION causes information on that aircraft to behighlighted by being shown in the appropriate SELECTEDform wherever information on that aircraft appears.

d) SELECTION is a necessary condition before interaction withan aircraft or its data.

4.7.2.3 The Selected Radar Label Form

4.7.2.3.1 The radar label may be ‘selected’ by placing the cursor over the radarlabel, or the aircraft symbol, or the entry corresponding to the aircraft inthe SILs or Message Windows, at which point the aircraft symbol, theentries in the SILS and Message Windows will highlight, and the labelwill switch to the infilled, selected form and all information fields (of thestandard form) not currently displayed will be shown. This includesCleared Fight Level (CFL) and Exit Flight Level (XFL) fields which havebeen hidden in keeping with the minimum information rules described in§4.7.6.2. Fields like ahdg will show as field name if no values arecurrently assigned. The displayed fields are available for input actions (ifdesignated for this purpose) through the mouse buttons.

B1 CLICK will allow manipulation of data where legal as definedin §4.8 below.

PRESS and DRAG allows the controller to drag the radarlabel to a new position relative to the aircraft symbol. Thelead line automatically extends and repositions to maintain thelink between the repositioned label and the aircraft symbol. Itis preferable that the entire label be draggable as was done inPD1. If this is too demanding of resource, a wireframe,indicating the boundary of the label, could be substitutedduring the dragging process.

B2 CLICK13 causes window priority changes as for any otherlocation within the RPVD.



B3 will allow presentation of supplementary data as defined in§4.8 below.

4.7.2.3.2 The selected form is such that the text is always BLACK and thebackground is in the appropriate colour as described in §4.6.2. In caseswhere an individual field has been highlighted, e.g. as for co-ordinationof a level, the text of that field still becomes BLACK but the backgroundfor the field becomes the background appropriate for the state, i.e.COORDPINK, RGB% 100,41,60 in the example.

4.7.2.3.3 It should be noted that the PRESS and DRAG capability for B1potentially raises a number of difficulties. Firstly, a rule must be definedfor the point of connection between the leader line and the dynamic radarlabels employed for REFGHMI. It is suggested that some notion of acentroid for the label is developed and that the leader tries to connect tothe centroid from any direction but is not allowed to overlap text in itslabel. The second issue relates to the interaction of this label adjustmentmethod with the others described in §4.4.6. The suggested rules are asfollows:

• With Auto resolution ON a controller adjusted label stays inthe controller defined position until auto resolution is switchedOFF. At this point all labels are reset to the rules definedwithin the global tool.

• Any labels subsequently adjusted by the controller will retaintheir controller defined position until the Auto resolution isswitched back ON. At this point the labels are again reset.

4.7.2.4 Standard Form

4.7.2.4.1 The STANDARD radar label form is the normal form of label in thedisplay. It is used primarily in three of the planning states described in§4.6. These three states are indicated by the appropriate colour and are,‘Entering’, i.e. advance information to the sector (§4.6.2.3), ‘Assumed’and on my frequency (§4.6.2.4), and finally ‘Concerned’, i.e.‘transferred to the next controller but still relevant to my area ofresponsibility’ (§4.6.2.5).

4.7.2.4.2 The information displayed when an aircraft label is in Standard form isdescribed in more detail in §4.7.4.6.

4.7.2.5 Extended Radar Label Form

4.7.2.5.1 The Extended Radar Label format provides supplementary flight plandata. The extended label provides all the functions that are available in aselected label of the RPVD, as well as input capability for the RequestedFlight Level (RFL). Where an extended label is called from a callsign inthe ‘not concerned’ or ‘concerned’ state then input actions with B1 willnot be possible. Input actions with B1 are only available in the ‘entering’or ‘assumed’ states. It can be strongly argued that B3 (informationbutton) actions should be available in all aircraft planning states(§4.7.2.6).

4.7.2.5.2 There are two mechanisms for display of the Extended Radar Labelinformation.



a) PRESS and HOLD of B3 on a callsign anywhere on theinterface14 produces a temporary display of the extended labelat the location of the input.

b) CLICK of B3 on a callsign will load a new, movable ExtendedLabel Window with the extended Label15. Only one extendedlabel window is available and only one aircraft can bedisplayed at a time. The information remains in that windowuntil over-written by subsequent B3 CLICK on the callsign ofanother aircraft. This window is described in more detail in§4.7.5.

c) It will be possible to put in a manual warning for any aircraftthrough the extended label window.

4.7.2.5.3 The information displayed when an aircraft label is in extended form isdescribed in more detail in §4.7.5.

4.7.2.6 Minimum Form(s)

4.7.2.6.1 The MINIMUM FORM is used for the Not Concerned Radar Label seenby the sector controller in the ‘not concerned’ colour. There are anumber of options associated with this label.

4.7.2.6.2 OPTION 1: One option is that this label cannot be selected for input.

4.7.2.6.3 OPTION 2: This label can be selected for information inputs only, i.e.inputs based on the B3 button to show the dynamic flight leg or theextended radar label window.

4.7.2.6.4 OPTION 3: It may be that there is advantage in resolving label overlapproblems, if such labels can be selected by the presence of the mousepointer, in which case the infill state will be as described in §4.6.2.2.

4.7.2.6.5 OPTION 4: There should be two types of ‘not concerned state’:

• OTHER (Never Concerned)

• NOT CURRENTLY CONCERNED

4.7.2.6.6 The OTHER category will consist of only two lines (Callsign and AFL)No interaction will be possible with this label and it will have no priority,in that all other aircraft information will be drawn on top of it.

4.7.2.6.7 The NOT CURRENTLY CONCERNED category will consist ofeffectively the same information as other aircraft labels, i.e. up to amaximum of five lines. The label will infill when the cursor enters. B1PRESS and DRAG can be used to reposition the aircraft label(§4.7.2.3.1). All B3 (Information Button) functions will be available, e.g.Dynamic Flight Leg, etc.

4.7.2.6.8 OPTION 4 is the preferred solution for the NOT CONCERNED state.

4.7.3 Key to Abbreviations for Radar Label Field Descriptions

4.7.3.1 The abbreviations shown in Table 4.2 are used to refer to the fields of theaircraft radar label data blocks in standard and extended forms. PLEASENOTE that these definitions derive from the operational procedures andpractices employed in ODID IV. The contents of the label may need to bemodified to meet the requirements of individual applications of theREFGHMI.



4.7.3.2 NOTE for ODID IV the XPT for the current sector will be the next pointfound on the flight plan following the sector out (from the current sector)event. For REFGHMI the XPT and the XFL should be determined tocorrespond to the appropriate letters of agreement.

4.7.4 Label Structures For the different Label States

4.7.4.1 Label text is always presented in a non-proportional (i.e. a fixed spacing) font.The font size should correspond to the minimum requirements as defined inChapter 3.

4.7.4.2 OTHER or NEVER CONCERNED (not relevant to the sector). In thiscase, there are no input actions possible except to call an extended label. Thelabel cannot be selected. ‘Not concerned’ colour as specified in §4.6.2.2

line 1 CALLSGN NS

line 2 AFL

4.7.4.3 NOT YET CONCERNED Potentially the same layout as the Standard RadarLabel. In this case all the B3 Information input actions are possible. Notconcerned’ colour as specified in §4.6.2.2

line 1 CALLSGN NS

line 2 AFL XPT sp

line 3 CFL XFL

line 4 ahdg.asp.arc

line 5 (option) NSSR (freq/REL/DEPA/DEST/TYPE/Company )

4.7.4.4 Prior to entering the sector (after reception of the Activation of InformationMessage, (ACT)). In this case, the label will have the same format as theStandard Label. Colour coding will be as defined for advance information in§4.6.2.3.



ABBREVIATION DEFINITION

NSSR New SSR Code (when provided)

SSRC Current SSR Code

Freq Next Sector Frequency (and sector name for line 5)

REL Aircraft is Released (remains until crossing sector boundary)

NS Current or Next Sector designator - will show only whenadvanced information has been passed (except it will alwaysshow in ‘not concerned label’ who owns the label)

CALLSGN Callsign in 7 (max.) characters

AFL Actual Flight Level (mode C)

XPT Exit Point of the sector (airfield designator for lowerairspace and approach).

sp Ground Speed (system monitored)

OPTIONAL16

CFL Cleared Flight Level (Planned Entry Level before AOC)

XFL Exit Flight Level

ahdg Assigned Heading T/H 3 digits (T = Track, H = inputheading)

arc Assigned rate of climb/descent R 2 digits

asp Assigned Speed, K/M 2 digits (K = indicated, M = mach)

TYPE Type of Aircraft (ICAO)

w Turbulence/Wake Vortex Category (for approach)

tas True Airspeed

RFL Requested Flight Level

Ti:me ETA for entry time in aircraft is in the advanced state andETA for exit when the aircraft is in the assumed state.

DEPA Departure Airfield (used in conjunction with TMA)

DEST Destination Airfield (used in conjunction with TMA)

WPx Next Waypoint on the flight plan

WPn First Waypoint in the Next Sector

Tx Next waypoint ETA

Tn First waypoint in NS ETA

Table 4.2: The abbreviations used in the following description of the aircraft labelstates.

4.7.4.5 On TRANSFER out (or RELEASE) from previous sector the CALLSIGN17

will turn into the assume colour (§4.6.2.4, WHITE RGB% 100,100,100). On



the previous sector the CALLSIGN will change to ‘not concerned’ (§6.2.2,GREY RGB% 65,65,65)). While the cursor is in the label the appropriateselected label colour variants will apply.

4.7.4.6 STANDARD RADAR LABEL (Standard label after Assumption of ControlInput, (AOC) §4.8). Following AOC the entire label text will change toassume colour (§4.6.2.4, WHITE RGB% 100,100,100). The NS will show thenext sector designator as it is passed into ADVANCED information state inthat sector. If the aircraft is subject to SKIP then following SKIP (transfer) itwill change to concerned label colour (§4.6.2.5, MUSTARD, RGB%72,61,28).

line 1 CALLSGN NS

line 2 AFL XPT sp

line 3 CFL XFL

line 4 ahdg.asp.arc

line 5 NSSR (freq/REL/DEPA/DEST/TYPE/Company )

NOTE: When a label goes into the SELECTED State (§4.7.2.3) it is alwaysturns into standard label form.

4.7.4.7 CONCERNED LABEL has the same format as the Standard Label. Colourcoding will be ‘Concerned’ (§4.6.2.5, MUSTARD RGB% 72,61,28). Thereare no input actions possible except the information functions e.g. the DFL orthe extended label (no input actions on the extended label)18. This labelapplies to SKIP aircraft. When leaving the SKIP sector it changes to ‘notconcerned’ (§4.6.2.2, GREY RGB% 65,65,65).

4.7.4.8 Supplementary Information: The NS symbols (2 characters) to be used inthe area label will have to be determined in conjunction with the airspacebeing used for the exercise. Note that care must be taken with the form ofthese next sector symbols. If digits are used, they could be confused withother information. The Next Sector symbol only appears when the ACTmessage is sent to the next sector.

4.7.4.9 NSSR will be shown automatically when a new SSR code is required ontransfer from another sector. The information will be removed (by the system)when the pilot is given and sets, the new code.

4.7.4.10 Non Correlated Radar Label ‘Concerned’ (§4.6.2.5, MUSTARD RGB%72,61,28). As an ODID example:

line 1 7000 (or 4321 if military)

line 2 AFL

The appropriate codes for an implementation of the REFGHMI will have to bedetermined as a function of the airspace and procedures.

4.7.5 The Extended Flight Label Window (ELW)

4.7.5.1 Description: PRESS and HOLD of B3 on any callsign, anywhere withinthe interface of the individual workposition provides a temporary display ofthe extended flight label. RELEASE of B3 causes removal of this temporarydisplay. Interaction with this temporary display is not possible.

4.7.5.2 CLICK of B3 on any callsign, anywhere within the interface of the individualworkposition places the extended label information for that aircraft within the



Extended Flight Label Window. This information overwrites any previousinformation within the Extended Flight Label Window.

4.7.5.3 The Extended Flight Label Window is opened by CLICKING B1 on theicon/button in the General Toolbox. A further B1 CLICK on the icon/buttonwill close the Extended Flight Label Window. The window can also be closedby CLICKING B1 on the conventional close box at the top left corner of theframe. In dual screen systems the Extended Flight Label Window can bemoved from one display screen to the other by activating the icon/button in theGeneral Toolbox on the second screen. The Extended Flight Label Button cannever be shown as depressed in the toolbox on both screens at once.

4.7.5.4 NOTE: Feedback from controllers involved in ODID IV, suggested that theyfound the mechanism provided for the input of Manual Warnings throughConflict Letters, useful, but limiting. There was a frequently expressed desirefor the capability to input a similar manual warning on any aircraft. The newlydefined ELW seems a logical place to initiate this function since it wouldnormally be open when considering a ‘problem aircraft’. (See §4.6.3.6).

4.7.5.5 The attributes of the Extended Flight Label Window are:

• parent window

• iconifiable, (either by Close Box or icon Button in General toolbox)

• moveable (by means of name handle PRESS and DRAG of B1)

• fixed size

• non-modal




• minimum size

• square corners

• position and presentation status saved in preferences set


• colours as defined in the master colour chart and table

4.7.5.6 Contents of the Extended Flight Label Window (ELW): The informationpresented in the Extended Flight Label Window is as follows

line 1 CALLSGN NS TYPE w tas RFL

line 2 AFL XPT sp Ti:me DEPA DEST

line 3 CFL XFL WPx WPn WPn+119

line 4 ahdg.asp.arc Tx Tn

line 5 NSSR, SSRC, REL, Freq [warning button]

4.7.5.7 The Extended Flight Label in situ on the radar follows the colour conventionsfor the non-selected radar labels in the radar window, i.e. planning state,coordination, etc.



4.7.5.8 Interaction: will be possible on all fields where interaction is normallypossible on the radar label and by means of the same mechanisms. B1interaction with the Extended Flight Label data cannot take place when theaircraft is in the ‘not concerned’ and ‘concerned’ states, however B3(Information Button) is always possible.

4.7.5.9 An additional interaction, CLICK of B1 on the newly established warningfield will causes the input or removal of a manual warning from the callsign ofan aircraft. The Warning Field is simply the word warning in Black text. at thebottom right of the ELW window. Following the B1 CLICK the text of theword changes to WARNING YELLOW.

4.7.6 Minimum Information Display

4.7.6.1 ODID IV operated employing minimum information principles. These areexpressed in the ODID report and Guidelines document [4, p.7] as:

‘display permanently only the minimum information needed by the controller’

‘access additional information simply and quickly as requested by thecontroller’

‘automatic removal of information as soon as it is no longer of interest to thecontroller’

4.7.6.2 These principles are reflected in the amount of information displayed in theradar label.

• Lines (1) and (2) will be the minimum display.

• Line (3) information will only be shown as follows (minimuminformation rule)

• If AFL < > CFL or CFL < > XFL or XFL < > AFL. To expressthis more simply, if any one of the three values AFL, CFL andXFL differs from the others then the line will be displayed.When two of these values are the same, then only one of thevalues will be displayed, e.g. when CFL = XFL, only the CFLis displayed. Thus the controller has a cue, from the shape ofthe label as to how much activity has still to be carried out onan aircraft.

• Line (4) information will only be shown if data has been inputby the controller. If there is no information in line (3), line (4)information will occupy line (3) (minimum information rule).

• Line (5) information will normally appear following call downfrom the main menu, i.e. type, NS frequency, etc. However,where a NSSR is required, or a REL or Radar Hand-over actiontaken, this will also be indicated on line (5).

4.7.6.3 NOTE that the minimum information principles apply only to unselectedlabels. When an aircraft is selected all three of the AFL, CFL and XFL fieldsare displayed (See §4.7.2.6).

4.7.6.4 These same principles are accepted and implemented in the REFGHMIwithout reservation, but note that when a label is SELECTED, all the fieldsare shown including line 4.



4.8 Interaction with the Radar Label and TrackSymbology

4.8.1 General Comments

4.8.1.1 This section describes the processes of interaction that can take place with thevarious elements of the radar label and the track symbology. It also indicatesthe consequences of these interactions.

4.8.1.2 It is a basic principal of both ODID and the REFGHMI, and indeed of anysuccessful graphical interaction system, that wherever the same object appearswithin the interface, it can be operated on in exactly the same manner.Consequently, the forms of interaction described in this section for the fieldsof the various forms of radar labels, should be valid wherever those fields arefound, e.g. in the radar label, in the VAW, etc., unless there is someoverwhelming reason which demands an exception. Such exceptions will bespecifically noted in the text. They should also be clearly indicated to the userby the interface itself in accordance with principles concerning thetransparency of modalities.20

4.8.1.3 Where an action opens an input menu window, the dialogue for completingthe input is described in this chapter together with the description of therelevant window. The colour coding and co-ordination described is alsoapplicable wherever the same input fields are found.

4.8.1.4 The following input operations have the same effect anywhere within anaircraft label and apply equally to all the fields described in §4.8.2 - §4.8.8,below.

B1 PRESS and DRAG This is used to reposition theaircraft label.

B2 CLICK This causes the RPVD, and all its child windows tomove to the top of the modifiable window stack, if it is notthere already. If it is at the top, it moves to the bottom.

4.8.2 The Callsign (CALLSIGN)

4.8.2.1 Interaction with the callsign field varies as a function of its operational status,as indicated by its colour. These differences apply only to the CLICK B1operation. The operations described in §4.8.1.8 hold true on the callsign forall states as do:

B3 CLICK which produces permanent display of the extendedlabel information in the ELW.

B3 PRESS and HOLD which produces temporary displayof the extended label information.

4.8.2.3 When the aircraft is in the advanced information state (both CALLSIGN andother label information in the ADVANCED colour RGB% 92,68,68,CLICKING B1 produces a single option to SKIP in the form of a button on theaircraft callsign region (See Figure 4.14 and §4.9.7). This is operated by afurther CLICK of B1 and rejected by CLICKING B1 anywhere else on theinterface. (CLICK B3 will also reject the option). Effectively this means thatwhen in the advanced information state, a double click of B1 causes SKIP.



4.8.2.4 Whenever the CALLSIGN is in the ASSUME colour (WHITE RGB%100,100,100) the full CALLSIGN MENU is available as a result of CLICK B1input. The callsign is in the ASSUME colour under two sets of conditions:

a) when the aircraft is in the advanced information state and thecontroller on the previous section has made a TRANSFER orRELEASE inputs. In this case the label is in theADVANCED information state, except for the callsign whichis shown in the ASSUMED colour.

b) following a), when the controller has made an ASSUMEinput, then the entire label, including the callsign is in theASSUMED colour.

4.8.2.5 Under both these conditions the invoked CALLSIGN menu contains fiveselectable items.

• ASSUME (Assume control)

• TRANSFER (Transfer of Frequency)

• HAND-OVER (Radar Hand-over)

• RELEASE (Release of Control)

• FORCED ACT (force advanced information to nextsector)

4.8.2.6 B1 is CLICKED again to make a, or clicked off the menu to close it withoutmaking a selection. The detailed functioning of the CALLSIGN MENU isdescribed in §4.9.

4.8.3 Actual Flight Level (AFL)

4.8.3.1 CLICK B1 has no effect on AFL as it cannot be modified.

4.8.3.2 CLICK B3 has no function on the AFL.

4.8.3.4 PRESS and HOLD of B3 has no function on the AFL

4.8.4 Cleared Flight Level (CFL/PEL). (Planned Entry level beforeAssumption of Control).

4.8.4.1 This field represents the Planned Entry Level (PEL) when the label is in theadvanced information state and the Cleared Flight Level (CFL) after theassumption of control.

4.8.4.2 CLICK B1 opens the CFL Flight Level Menu Window (FLMW) formodification of CFL/PEL. B1 is clicked on selected level and FLMW closes.See §4.10 for a description of the FLMW.

4.8.4.3 CLICK B3 Updates or opens the VAW21 (if not iconified) at its last displayedlocation, providing that it has been enabled22 from the General Toolbox. Thedata displayed in the VAW will show Conflicts and Risks according toConflict and Risk Display rules in force.

4.8.4.4 PRESS and HOLD of B3 has no function on the CFL

4.8.5 Exit Flight Level (XFL)



4.8.5.1 CLICK B1 opens the XFL FLMW for modification of XFL. B1 is CLICKEDon the selected level and FLMW closes. See §4.10 for a description of theFLMW.

4.8.5.2 CLICK B3 causes display or update of the VAW (as for CFL/PEL) except thatthe contents will show both conflicts and conflict risks according to theConflict and Risk Display rules in force.

4.8.5.3 PRESS and HOLD of B3 has no function on the XFL.

4.8.6 Exit Point of the Sector (XPT)

4.8.6.1 CLICK B1 opens a Way point Menu Window (WMW) for route, (holding oronward clearance input)23. (See §4.11) CLICKING B1 again makes theselection and closes the menu window. The selection is shown in the ahdgfield. The system should automatically remove a beacon name once thatbeacon has been overflown (or passed abeam).

4.8.6.2 The modification of XPT described in the preceding paragraph only allows theselection of other waypoints already lying along the proposed track of theaircraft. It may well be more useful to allow selection of alternative waypointscurrently lying OFF-TRACK, especially for entry and exit modification. Theproblem here is to find a rule suitable for identifying the optional OFF-TRACK waypoints. This can probably only be done as a function of airspace.The issue will be further discussed in §4.11

4.8.6.3 CLICK B3 displays the aircraft's current flight leg through the sector on thecurrent radar picture, plus the flight legs of all conflicting traffic. CLICKINGB3 again on the field removes the display. This is described as the DynamicFlight Leg Function and is defined in §4.8.12. In ODID IV this function wasonly available for assumed aircraft. For the REFGHMI it should be availablefor all aircraft except, perhaps, the never concerned category.

4.8.6.3 PRESS and HOLD of B3 displays the flight leg until the button is released (inthis case route modifications cannot be made).

4.8.7 Current or Next Sector Designator (NS)

4.8.7.1 CLICK B1 has no function

4.8.7.2 CLICK B3 causes permanent display of the Next Sector name and frequencyin Line 5.

4.8.7.3 PRESS and HOLD of B3 provides a quick-look display of the Next Sectorname and frequency in Line 5.

4.8.8 Assigned Heading (ahdg)

4.8.8.1 CLICK B1: According to the ODID IV specification the cursor shape changesand the 'Elastic Vector' function is initiated. The cursor will return to itsnormal shape on completion of the input (see elastic vector function in §4.8.11) In fact the elastic vector function was invoked by CLICKING B1 onthe aircraft symbol, the method that is also specified for PD1 and theREFGHMI. Invocation from the heading field should also be implementedalthough it appears to offer little advantage during en-route control. (It willhave application however in TMA control where aircraft symbols may be tooclose together to permit easy selection. Because the aircraft label can always



be re-positioned with B1 PRESS and DRAG, access through a label field willalways be possible.)

4.8.8.2 CLICK B3 in ODID IV cancelled the display of any existing heading inputvalue. The same mechanism is used for REFGHMI.

4.8.8.3 PRESS and HOLD of B3: Quick-look display of the current radar track(system monitored value).

4.8.9 Assigned Rate of Change of Climb or Descent (arc) (ifimplemented)

4.8.9.1 CLICK B1 opens a rate of Climb/Descent input menu window (CDMW)

4.8.9.2 CLICK B3 cancels the display of any existing climb or descent data.

4.8.9.3 PRESS and HOLD of B3 provides a quick-look display of the current systemrate of climb or descent (requested).

4.8.10 Assigned Speed (asp) (input of a speed restriction)

4.8.10.1 Interaction takes place on the asp field.

4.8.10.2 CLICKING B1 or asp opens a rate of Speed Input Menu Window (SMW) (see§4.12)

4.8.10.3 CLICKING B3 on asp cancels the display of any existing speed input value.

4.8.10.4 PRESS and HOLD of B3 provides a quick-look display of the current speedrestriction.

4.8.11 Interaction with the Radar Position Symbol - The Elastic VectorFunction and Mode (EVM).

4.8.11.1 The aircraft position symbol must be big enough, or have a big enoughacquisition area to make selection easy and reliable.

4.8.11.2 CLICK B1: Activates the Elastic Vector Function24 (EVM). This

a) Automatically changes the cursor from the pointing symbol tothe sighting symbol form (§3.4.4.11) indicating that thesystem is now in EVM Mode. Further a single pixel circle inWARNING YELLOW (RGB% 100,90,12) is drawn with aradius of 1.5 cm, centred on the aircraft symbol. No otherinputs can be made until closure of the mode (e, f, below).The Radar label changes to the SELECTED form and theaircraft information highlights in the SIL and Messagewindows if present in these locations.

b) If the function has been invoked from the heading field of thelabel (ahdg), and no input has been made in this field, thecursor is automatically repositioned on the radar positionsymbol. If a heading input already existed at the time of EVMinvocation, a three minute speed vector is displayed with thisprior heading as the starting point for the elastic vectormanipulation.

c) Movement of the cursor now draws out an elastic vectorbetween the aircraft position symbol and the cursor position.If possible, the elastic vector is marked with a bead every fivenautical miles measured from the initiating aircraft symbol.



d) A continuous readout is provided alongside the cursorshowing the value of the elastic vector heading. If the elasticvector is inside the circle, the readout shows relative heading(5 degrees, L or R indicating Left or Right) and the length ofthe vector in nautical miles in modal green. If the cursor isoutside the circle the readout shows absolute heading (3digits, to nearest 5 degrees) and length of vector in nauticalmiles.

e) While in the EVM, the automatic highlighting of aircraftlabels on cursor entry, is suspended. Radar labels are ignored.The only objects that can be acquired are beacons. The labelof the aircraft which is the source of the EVM remainshighlighted (as does any entry in the SIL or MESSAGEWINDOWS for that aircraft).

f) CLICKING B1 inputs the current value of heading andterminates the elastic vector mode. The cursor will return toits normal shape and original position. The heading value isthen continually displayed in the label until deleted or a newinput is made.

g) CLICKING B3 exits the mode without having made an input.The cursor will return to its normal shape and originalposition.

h) The elastic vector and position readout are in (Warning)YELLOW (RGB% 100,90,12)and sans serif 12pt.

i) An important finding of the Pilot Testing Phase for the PD1Reference System was that it was necessary to include aminimum length of displacement for the input of an ElasticVector. This was necessary to avoid accidental inputs throughunintended double clicks on the aircraft symbol on invokingthe EVM, or accidental selection of the aircraft symbol whentrying to make another input. A minimum displacement ofabout 5.0mm is suggested. Any displacement less than thisexits the mode without having made an input. (This problemdid not arise in ODID because acquiring the EVM requiredconsiderable attention.)

4.8.11.3 The EVM can be used to give a direct routing to a reporting point as analternative to using XPT field (§4.8.6). This is performed by dragging thesighting cursor to the appropriate waypoint and CLICKING B1. This isfacilitated by providing feedback as follows. If the elastic vector cursor ispositioned to within 2 nm (circular zone) of a fix by CLICKING B1, the fixname is 'captured' (it will change colour to MODAL GREEN to providefeedback prior to capture, reverting to normal once the CLICK has occurred).The heading input will be interpreted as a direct track to the 'captured'position. The fix name is then continually displayed in the label until either:

a) a new heading or direct route input is made, or

b) the flight passes the fix when it will be automatically deletedfrom the label.

c) SPECIAL COORDINATION: Where this input is made bythe accepting PC, during the advance information stage, a co-



ordination will be effected. The co-ordinated value (beaconname) will be in the co-ordination colour (in the suplementaryfouth or fifth line) until accepted when it will change toWarning Yellow until communicated to the Aircraft. When ithas been communicated to the aircraft (normally by a TC) itwill change to the current label colour. The TCcommunicating this clearance can make the input byCLICKING B1 directly on the direct point indicated in thefourth line of the label. During the coordination phase, theappropriate messages will be generated in MESSAGE IN andMESSAGE OUT windows.

4.8.11.4 PRESS and DRAG of B1 has no function on the radar position symbol.

4.8.11.5 CLICKING B2 causes re-prioritisation of windows as for any other locationwithin the RPVD.

BAW2345 230 ↓ BEE 47 190 150

SAS809 WW 190 BEA 45

FIGURE 4.12: Dynamic Flight Leg within the Radar Plan View Display

4.8.11.6 CLICK B3 on the aircraft symbol adds or removes the aide memoire functionas described in 4.6.3.8.

4.8.11.7 PRESS and HOLD of B3 has no function on radar position symbol but noteeffect of PRESS and HOLD on ahdg field in §4.8.8.3.

4.8.12 Dynamic Flight Leg Mode/Function (DFL)



4.8.12.1 This function can be invoked anywhere that an XPT is displayed, byCLICKING B3 on the XPT.

4.8.12.2 The dynamic flight leg is displayed on the current radar image. It provides aninformation display of the selected flight’s currently planned path through thesector, as well as an indication of conflicting flights along the route. Figure4.12 provides a general indication of its appearance, based on ODID IV. Thesubject aircraft is shown as a solid line and conflicting aircraft are shown asdashed lines. Conflict segments are shown in red for all aircraft involved.

4.8.12.3 The colour principles will follow the standard rules for the REFGHMI asdefined in Appendices 3 and 4.

4.8.12.4 The dynamic flight leg updates with the RPVD.

4.8.12.5 CLICKING B3 on the XPT cancels.

4.8.12.6 It is possible to have the DFL displayed for more than one aircraftsimultaneously.

4.8.12.7 PRESS and HOLD of B3 on the XPT causes temporary display of the DFL.

4.9 Callsign Menu

4.9.1 General Characteristics

4.9.1.1 This menu, Figure 4.13(a), is invoked by CLICKING B1 on any callsignwhich is in the ASSUME colour (see §4.8.2.5). CLICKING B1 on an aircraftin the ADVANCED INFORMATION colour causes presentation of the SKIPoption (Figure 4.13(b)). CLICKING B1 on a callsign in the, CONCERNED orthe NOT CONCERNED colours has no effect. The callsign menu containsfive items ordered (From top to bottom) as follows:

• ASSUME (Assume control)

• TRANSFER (Transfer of Frequency)

• HAND-OVER (Radar Hand-over)

• RELEASE(Release of Control)

• FORCED ACT (force advanced information to next sector, normally PC function)

and appears as illustrated in Figure 4.14(a).

4.9.1.2 The CALLSIGN menu will ‘pop-up’25 so that the ASSUME option is underthe cursor or, if the aircraft planning state requires th SKIP OPTION, with theSKIP option under the cursor. The basic rules of REFGHMI aircraft relatedmenus , which differ significantly from those of ODID IV, are that:

a) the system will not move the cursor anywhere except underthe user’s control

b) all menus will always appear in the same position relative tothe invoking field

c) all menus related to a particular aircraft will always displaythe identity (callsign) of that aircraft.

4.9.1.3 The menu will have the following attributes.



• child (of the RPVD)

• modal26 (IMPORTANT FOOTNOTE)

• not iconifiable

• not moveable

• not re-sizeable



• high priority on invocation (within RPVD stack)

• square corners

• no data saved in the preferences set

• colours as defined in the master colour chart for windowmanagement functions (See Appendices 3 &4).

4.9.1.4 Selections are made by CLICKING B1 on the appropriate option item. Onselection the menu disappears.

4.9.1.5 To delete either menu without selection CLICK B3 with the cursor within themenu. The menu is effectively a tight mode. No other input is recogniseduntil the menu is closed (by the next input)27. In effect, CLICKING B1 or B3anywhere else on the display removes the menu without a selection.

4.9.1.6 The frame of the menus will be in standard WINDOW BLUE (RGB%44,55,66) and the individual items in the same. Visual appearance of themenus will be as in Figure 4.13. Selectable fields will be a minimum of 8mmacross their shortest dimension. Available Options will have their text inBLACK, unavailable options on the callsign menu will be in SHADOWGREY (RGB% 20,20,20).

SKIP

BAW1234

(a) (b)

TRANSFER

HANDOVER

RELEASE

FORCE ACT

BAW1234

ASSUME

Figure 4.13: The Callsign Menu and the SKIP Option, invoked from callsignsmenu invoked from the callsigns

(The illustration is approximately actual size)

4.9.1.7 As the cursor moves over the options within the menu, highlighting feedbackwill be provided by the option changing to WBLUE HIGHLIGHT (RGB%64,75,86) for the field. The text remains in its original colour (§4.9.1.6).

4.9.2 The ASSUME Option

4.9.2.1 CLICKING B1 on the ASSUME option will cause the aircraft to change itssystem status from the ADVANCED INFORMATION STATE to the



ASSUMED state. It will be accepted onto the frequency. The label displayedin the RPVD will change from the ADVANCED colour (RGB% 92,68,68) tothe ASSUMED (on frequency) colour (RGB% 100,100,100). In the previoussector’s display the aircraft label will change to the NOT CONCERNEDcolour (RGB% 65,65,65) or the CONCERNED colour (RGB% 72,61,28) if itstill lies within that sector’s airspace.

4.9.3 The TRANSFER Option

4.9.3.1 CLICKING B1 on the TRANSFER option will inform the system that theaircraft has been transferred to the next sector frequency. The CALLSIGNwithin the label will change to the NOT CONCERNED colour (RGB%65,65,65). The next sector’ CALLSIGN will change to the ASSUMED colourindicating transfer. ASSUME by the following sector produces the changesdescribed in §4.9.2. The operational aspects of the TRANSFER function assuggested for ODID IV are described in [17] §8.5.11.

4.9.3.2 If co-ordination conditions are not achieved (i.e. if CFL is not equal to XFL)when transfer is effected, the CFL text in the RADAR LABELS of the twosectors involved will show in the ALERT/WARNING colour (RGB%, 100,90, 12, NATS L6 palette). This alert is cancelled on ASSUME from thesecond sector.

4.9.4 The HANDOVER Option

4.9.4.1 Although planned, this option was not fully implemented in ODID IV. Itsimplementation is somewhat complex in that it involves the provision of anadditional mode. Consequently, it is defined as OPTIONAL for REFGHMI,but its inclusion is VERY STRONGLY RECOMMENDED.

4.9.4.2 CLICKING B1 on the HANDOVER option invokes the HANDOVERFUNCTION for the selected aircraft. A HANDOVER differs from aTRANSFER in that it is employed in cases where normal separation rules arenot in force - for example to aircraft on parallel headings (and less than 5 milesapart) - and typically it involves more than one aircraft.

4.9.4.3 In this implementation a HANDOVER can only operate on pairs of aircraftand can only be invoked when both the aircraft are in the ADVANCEDinformation state on the receiving sector (i.e. the ACT has been passed). Thisis reflected in the presence of the next sector symbol in the labels on thehanding out sector. HANDOVER can only be used for aircraft with the samenext sector.

4.9.4.4 After CLICKING B1 the cursor changes in to a suitably unique sighting cursorin WARNING YELLOW. The CALLSIGN of the first (invoking) aircraft alsochanges to WARNING YELLOW.

4.9.4.5 To DESELECT the mode without completing the input, CLICK B1 anywherebut on the callsign of another aircraft, or CLICK B3 anywhere on the display.This causes reversion to the normal pointing cursor with nothing selected andexits the handover mode.

4.9.4.6 To make a complete HANDOVER input, a second aircraft is selected byplacing the modal cursor on the aircraft’s CALLSIGN and which causes it toturn to WARNING YELLOW as do both callsigns on the receiving sector(where the labels should be in the advanced warning state). CLICKING B1 onthis highlighted callsign completes the input.



4.9.4.7 Completion of the input causes a special symbol (a hand was recommendedfor ODID) to appear next to the Callsign on both the sending and receivingsectors and causes radar HANDOVER MESSAGES (IN and OUT) to begenerated in the appropriate MESSAGE WINDOWS. At the same time, thecursor returns to normal indicating the end of the mode. The callsigns and thespecial symbol remains in place presented in WARNING YELLOW.

4.9.4.8 CLICKING B1 on the hand, on either of the aircraft or in the MESSAGE INwindow, on the receiving sector, accepts the handover. Acceptance of thehandover ASSUMES both Aircraft as if a full TRANSFER and ASSUMEoperation had taken place. Messages are removed from the message windows,and the CALLSIGNS and the labels on the handing out sector go toCONCERNED state until the aircraft have left the sector. If the handover isnot accepted the receiving controller WILL (mandatory) initiate a verbaldialogue.

4.9.4.9 The handing out sector can cancel by CLICKING B1 on the special symbol ineither of the aircraft labels or in the MESSAGE OUT window, but ONLY ONRECEIPT OF A VERBAL REFUSAL FROM THE RECEIVING SECTOR(§.4.9.4.10).

4.9.4.10 The receiving sector may reject the handover BUT ONLY BY VERBALLYINDICATING A REFUSAL TO THE OFFERING SECTOR who must cancelby means of the mechanism described in §4.9.4.9.

4.9.5 The RELEASE Option

4.9.5.1 CLICKING B1 on the RELEASE option will cause EARLY release of controlof an aircraft to another sector. This differs from TRANSFER only in that thefollowing controller is free to manoeuvre the RELEASED aircraft - not thecase with a transfer. This option places a REL in line 5 of the RADARLABEL in both sectors and then performs a TRANSFER, as described in§4.9.3. The REL is removed automatically when the aircraft crosses the sectorboundary. The operational aspects of the RELEASE function as suggested forODID IV are described [17] §8.5.9.

4.9.6 The FORCED ACT

4.9.6.1 CLICKING B1 on the FORCED ACT option, forces the transmission of anEstimated boundary time to the next sector before the 10 minute system triggeris sent28. This causes the aircraft to be placed in the ADVANCED informationstate in the following sector.

4.9.7 The SKIP Option

4.9.7.1 CLICKING B1 on a CALLSIGN in the ADVANCED INFORMATION colourgives access to a single option button, SKIP (Fig 4.14(b)). Selecting SKIP byCLICKING B1, will cause a flight to be transferred to the next sector(N+1) ifthe controller decides that it should not be worked in the current sector (SectorN). The SKIP button has exactly the same attributes as the CALLSIGNMENU WINDOW.

4.9.7.2 To reject the SKIP button without selection, CLICK B3 on the button or B1 orB3 anywhere else on the display.

4.9.7.3 The SKIP function cannot be cancelled or refused. It will operate as follows:

In Sector N-1 (the sector before the SKIP selecting Sector)



a) a modification of the displayed XFL to that required by SectorN if this is necessary.

b) change of the sector designator (NS) to that of Sector N+1 inline 1 of the RADAR LABEL. The NS field will change tothe ALERT/WARNING colour (RGB%, 100, 90, 12, NATSL6 palette). The frequency of N+1 sector should also bedisplayed in line 5 of the label

In Sector N (the sector selecting the SKIP option)

a) change of RADAR LABEL colour to CONCERNED (RGB%72,61,28) until the aircraft crosses sector N’s boundaryoutbound into Sector N+1.

In Sector N+1 (the sector following the SKIP selecting sector)

a) change of sector designator (NS) to that of Sector N-1 in line 1of RADAR LABEL. The NS changes to theALERT/WARNING colour (RGB%, 0,90,12).

The operational aspects of the SKIP function as suggested for ODID IV aredescribed in [17] §8.5.10.

4.9.8 SUMMARY: Availability of Callsign Menu Items

4.9.8.1 ODID IV and PD1 had a set of rules which determined which options wereavailable on the callsign menu at different times. When an item was notavailable, it retained its place in the menu but the text was presented in a lesssalient font colour. A similar logic will be the basis for the REFGHMI.

4.9.8.2 This paragraph describes the available menu options as they are defined forthe REFGHMI. However, it is suggested that this be reviewed carefully, inconjunction with the operational experts familiar with the proceduresproposed for any implementation of the REFGHMI. There are a number ofdifferences between these proposals and the specifications for ODID IV andODID IV bis. These changes have been made in order to improve consistencyof behaviour and the clarity with which availability of the menu is indicated29.

4.9.8.3 IMPORTANT NOTE: The operational procedures defined and accessed byASSUME, SKIP, TRANSFER, RELEASE and HANDOVER makedistinctions which may not be appropriate to the airspace in all exercises. Ifthis is the case, this menu should be modified to reflect the procedures actuallyrequired in preference to adding further interaction mechanisms. For example,in PD1 TRANSFER and RELEASE were collapsed into a single option calledRELEASE.

4.9.8.4 Label is in NOT CONCERNED colour

• CALLSIGN MENU cannot be invoked

4.9.8.5 Label is in all in the ADVANCED INFORMATION state but has not beenoffered for TRANSFER, HANDOVER, or RELEASE (i.e. Callsign is also inthe ADVANCED INFORMATION colour).

• SKIP option

• Option as to whether the FORCED ACT should be available,establish in conjunction with appropriate operational experts

• no other options presented



4.9.8.6 Label is in ADVANCED INFORMATION state and either

a) CALLSIGN is in ASSUMED colour indicating TRANSFERout from previous sector, or

b) handover symbol is present HANDOVER (and Callsign is inWARNING YELLOW colour), or

c) CALLSIGN is in ASSUMED colour indicating TRANSFERand REL is displayed in Line 5 of the label

• ASSUME option is available

• FORCED ACT is available

• all other options are subdued

4.9.8.7 Complete Label is in ASSUMED colour but estimate is not available

• only FORCE ACT available

• all other options subdued

4.9.8.8 Label is in ASSUMED and estimate is available (implies ADVANCED INFOin next sector)

• TRANSFER and RELEASE available

• all other options subdued

4.9.8.9 Label is in the ASSUMED colour, CALLSIGN is in the NOT ConcernedColour (or WARNING YELLOW for HANDOVER out), and the aircraft hasbeen TRANSFERRED, HANDOVER out or RELEASED

• menu not available

4.9.8.10 Label in CONCERNED colour

• menu not available

4.9.8.11 GENERAL RULE: The callsign menu is only available when thecallsign is in the ASSUME colour.

4.9.9 Cursor Defaults

4.9.9.1 ODID IV had a series of rules that defined what would be the default selection(cursor position) when the CALLSIGN MENU appeared. (The menu alwaysappeared in the same relative position. The cursor was warped to theappropriate location.)

4.9.9.2 These rules will not be observed in PD1 or the REFGHMI. The requirementhas been partially removed by separating out the SKIP option (which was partof the CALLSIGN MENU in ODID IV. For REFGHMI and PD1 the cursorwill be moved by the controller to the appropriate selection. Consequently, theASSUME option or the SKIP option is always drawn beneath the cursor.

4.10 Flight Level Menu Window (FLMW)

4.10.1 Range of Applications

4.10.1.1 The Flight Level Menu Window is employed anywhere that a Flight Levelmust be modified. The principal locations for this on the RPVD are within the



RADAR LABEL on the CFL/PEL field, the XFL field and the RFL field.However, the same menu and rules will apply anywhere else that these fieldsare displayed (e.g. in VAWs, etc.)

4.10.1.2 The physical form and mechanisms of manipulation are identical in all threecases. Only the initialisation and default behaviours differ. Consequently thegeneral structure and interaction will be described, followed by a briefspecification of the individual applications.

250260

BAW1234

210

240

220

230

200

Figure 4.14: Flight Level Menu Window (redraw without pink)


4.10.2 General Description of the FLMW

4.10.2.1 The Flight Level Menu Window is illustrated in Figure 4.14. It is invoked byCLICKING B1 on any of the fields described in §4.10.1.1. The menu contains7 flight level options arranged as shown.

4.10.2.2 The attributes of the menu are:

• child window (of invoking window)

• not iconifiable

• not moveable

• fixed size

• modal


• scrollable


• square corners


4.10.2.3 Selections are made by CLICKING B1 on the appropriate menu item. Onselection the menu disappears.



4.10.2.4 To delete the menu without selection, CLICK B3 with the cursor within themenu. The menu is effectively a tight mode. No other input is recogniseduntil the menu is closed (by the next input). In effect, CLICKING B1 or B3anywhere else on the display removes the menu without a selection.

4.10.2.5 The menu frame of the menu will be in the standard window element coloursWINDOW BLUE (RGB% 44,55,66) and the individual items in the same.Visual appearance of the menu will be as in Figure 4.14. Selectable field willbe a minimum of 8mm across their shortest dimension.

4.10.2.6 As the cursor moves over the options within the menu, highlighting feedbackwill be provided by the option changing to WINDOW HIGHLIGHT (RGB%64,75, 86) for the field. The text will remain BLACK30. Note that the PINKcolour used for the scrolling control elements is ADVANCED PINK (RGB%92,68,68).

4.10.2.7 The FLMW is scrollable. Scrolling is implemented by PRESS and HOLD ofB1 on the area s containing the scrolling triangles. The triangular indicatorwithin this region is drawn with a black outline if scrolling is possible in thedirection indicated. If there are no further items available the black outline tothe triangle is removed effectively reducing the contrast of the triangular area.

4.10.2.8 The range and increment of values shown in the FLMW will reflect theoperational requirements of the sectors.

4.10.2.9 In the longer term it may be worth ensuring that when the menu appears it ispositioned such that the cursor (which is not moved by menu appearance) is atthe top of the selection list for descending aircraft and at the bottom of the listfor climbing aircraft, in order to minimise the need for scrolling. A complexset of contextual rules was employed in ODID IV and these could be used fora model ([17], §10.15). However, for a first implementation, it is probablyadequate that the menu always appears centred on the cursor so that themiddle value would be the default selection.

4.10.2.10 The exact range of values shown in the FLMW shall depend on the context inwhich it is selected.

a) When the menu is invoked from the CFL/PEL field, it is PELbefore Assume and CFL after. If in both these cases, the menuwill appear centred on the current XFL value.

Input on the PEL in the ADVANCED INFORMATIONSTATE will effect a co-ordination. Standard colour rulesapply, i.e. co-ordinated value will change to co-ordinationcolour COORD PINK (RGB% 100,41,60) and will revert tocurrent label colour on acceptance of the co-ordination.

b) When invoked from the XFL field, the menu will be centredon the current XFL or incoming coordination proposal. Thismeans that a shortcut acceptance of coordination can beeffected by a double CLICK on a proposed XFL.

Input on the XFL during the advance information state (to theNS) will effect a co-ordination. Standard colour rules apply,i.e. co-ordinated value will change to COORD colour PINK(RGB% 100,41,60) and will revert to current label colour onacceptance of the co-ordination.



c) When invoked from the RFL field of the extended label themenu will be centred on the current RFL.

4.10.2.11 IMPORTANT NOTE: The choice of PINK for Coordination reflects a needin PD1 to preserve a strong clear green colour for some of the AdvancedGHMI functionality connected with planned and cleared trajectories. Thiscolour RGB% 46,83,31 could be used if this advanced functionality is notlikely to be required.

4.11 Waypoint Menu Window (WMW)


4.11.1.1 The Waypoint Menu is used to input a direct heading. It is invoked byCLICKING B1 on the XPT field of the RADAR LABEL, or anywhere elsethat it is displayed.

4.11.2 Description of the WMW.

4.11.2.1 The Waypoint Menu is illustrated in Figure 4.15. It may contains the next plusfive reporting points on the aircraft’s flight plan. Alternatively, before theaircraft enters the sector, i.e. while it is in the ADVANCED INFORMATIONstate, the menu should also show a number of alternative waypoints withinthe approaching sector which will allow the coordination of alternative entrypoints. It is accepted that definition of a suitable general rule to define suchalternatives is difficult and that the contents of this menu should probably bedefined on a case by case basis for sectors and routes. Note also that thenumber of beacons displayed should be revised to reflect the requiredoperational procedures. If necessary the same scrolling mechanisms providedfor the FLMW can be made available.

4.11.2.2 Except for the absence of scrolling, the attributes of the WMW are similar tothose of the FLMW, namely:


• not iconifiable

• not moveable

• fixed size

• modal



• square corners




BAW1234

WP2

WP1

WP3

WP4

WP5

WP6

Figure 4.15: Waypoint Menu Window



4.11.2.4 To delete the menu without selection, CLICK B3 with the cursor within themenu. The menu is effectively a tight mode. No other input is recogniseduntil the menu is closed (by the next input). In effect, CLICKING B1 or B3anywhere else on the display removes the menu without a selection.

4.11.2.5 The menu frame of the menu will be in the standard window element coloursWINDOW BLUE (RGB% 44,55,66) and the individual items in the same.Visual appearance of the menu will be as in Figure 4.15. Selectable fields willbe a minimum of 8mm across their shortest dimension.

4.11.2.6 As the cursor moves over the options within the menu, highlighting feedbackwill be provided by the option changing to WINDOW HIGHLIGHT (RGB%64,75,86) for the field. The text will remain BLACK.

4.11.2.7 Using the elastic vector directly to a waypoint will have the same effect31.

4.11.2.8 If the activities described in §4.11.2.7-8 are undertaken when the aircraft is inthe advanced information state, or are employed to modify the XPT,coordination proposals will be produced with appropriate colour changes inthe aircraft labels and the generation of appropriate messages in theMESSAGE IN and MESSAGE OUT windows.

4.11.2.9 Once a Waypoint has been overflown, the system will automatically removethat waypoint from the list.

4.11.2.10 The range of the list may be limited by the operation requirements of thesectors.

4.11.2.11 Note, no co-ordination will be effected for direct route input after theadvanced information has been sent to the NS. However, under thesecircumstances, coordination requests may be received from that sector.

4.11.2.12 The menu will appear so that the cursor (which does not move) is centred onthe next waypoint. The waypoints are ordered in a descending column ofprogression along the planned route32.

4.12 Speed Input Menu Window (SMW)




4.12.1.1 The Speed Input Menu window is used to input a speed restriction. It isinvoked by CLICKING B1 on the sp or the asp field (if available) on theRADAR LABEL, or anywhere else that these are displayed.

84

85

BAW1234

80

83

82

81

MK

79

Figure 4.16: Speed Input Menu Window


4.12.2 Description of the SMW

4.12.2.1 The Speed Restriction Menu is illustrated in Figure 4.16. It offers thepossibility of operating in either KNOTS (IAS)33 or MACH number. Sevenoptions are displayed in descending order from the top of the menu. ForODID IV a general default was set for actual MACH above FL250, and 250KNOTS below that level. (A similar rule should be specified for REFGHMIbased on the operational requirements.) However, if a speed has already beeninput then the display will default to this speed type and value.4.12.2.2

The attributes of the SMW are identical to those of the FLMW, namely:


• not iconifiable

• not moveable

• fixed size

• modal


• scrollable


• square corners





4.12.2.4 To delete the menu without selection CLICK B3 with the cursor within themenu. The menu is effectively a tight mode. No other input is recogniseduntil the menu is closed (by the next input). In effect, CLICKING B1 or B3anywhere else on the display removes the menu without a selection.

4.12.2.5 The selection between MACH and KNOTS is effected by CLICKING B1 onthe appropriate radio button. This does not cause closure of the menu. It issimply re-drawn with the appropriate menu values.

4.12.2.6 Speed values in knots will begin at 12 (120) and will increase in 10 knotintervals to 40. Speed values in Mach will begin at .68 and will continue inincrements of .01 to Mach .90.

4.12.2.7 The menu frame of the menu will be in the standard window element coloursWINDOW BLUE (RGB% 44,55,66) and the individual items in the same.Visual appearance of the menu will be as in Figure 4.16. Selectable fields willbe a minimum of 8mm across their shortest dimension.

4.12.2.8 As the cursor moves over the options within the menu, highlighting feedbackwill be provided by the option changing to WBLUE HIGHLIGHT (RGB%64,75,86) for the field. The text will remain BLACK.

4.12.2.9 Where an input is made during the advance information stage by the acceptingcontroller a co-ordination will be effected. The co-ordinated value will be inthe COORD PINK colour (RGB% 100,41,60) until accepted when it willchange to current label colour.

4.13 Sector Inbound List


4.13.1.1 The SIL is displayed from start-up on all sectors. It presents the aircraft’sEntry Time, Callsign, PEL and Exit Point. Following selection of a B3 input,ie.on PEL to examine the VAW, on XPT to examine the DFL or on thecallsign to eamine the Extended Radar Label, a á is added to indicate that themental process of planning has been effected (theoretically). This can beconsidered as comparable to the integration of a flight strip into the active bay.

4.13.1.2 Information is removed following Assume by the accepting controller (orSKIP). Dialogue is the same as for the dialogue functions available on thesame fields in the radar label.

4.13.1.3 SILs are geographically dispersed according to pre-defined sector entry points.Data is presented in a SIL in accordance with the aircraft’s geographicboundary crossing point into the sector and is not specifically related to itsflight planned route.

4.13.1.4 When an aircraft label is highlighted into the selected state within the RPVDby entry of the cursor into its label, any entry relating to that aircraft in a SILwill also be highlighted. The reciprocal condition is also true, entry into a SILfield causes infill of the aircraft label in the appropriate colour for its state.

4.13.2 Description of the SIL



4.13.2.1 A typical Sector Inbound List is illustrated in Figure 4.17.

4.13.2.2 The attributes of the SIL are:

• child window (of RPVD)

• not iconifiable

• moveable (namebar/handle)

• dynamically re-sized by the system but minimum space for oneline of text

• non-modal



• square corners


4.13.2.3 A SIL consists of a window header/move bar that identifies the relevant SectorEntry Point. Beneath this information is presented as a tabular list with eachline corresponding to an aircraft and the columns corresponding to, EntryTime, Callsign, PEL, Exit Point (or a special symbol if the entry and exitconditions have not been checked), and a column for a planning check mark(á). NOTE in ODID IV, individual controllers disagreed as to the amount ofinformation which should be presented in the SILs. A number wanted XFLand type included in addition to the information shown in the illustration. Ithas been suggested that this should be accommodated in the Preferences Set.

4.13.2.4 Moving the cursor onto the line corresponding to any aircraft causeshighlighting of that line within the SIL, it also causes the label of thecorresponding aircraft to highlight in the selected label form within the RPVD.It will also highlight any messages relating to that aircraft in the MESSAGEWINDOWS.

24011:32 BAW976 260 KOR 11:20 SAS992 290 KOR * 11:13 SHAMU 31 310 ALS

VES - TAL - ALS

Figure 4.17: Sector Inbound List

(The example uses ODID beacons. The data is arranged in columns. The misalignment derives from the graphic importation process into this text.

The * in the image should be replaced by á)

4.13.2.5 The CALLSIGN, PEL, and Exit points can all be used to invoke the samemanipulation menus as the corresponding fields in the RADAR LABEL.These can be invoked by CLICKING B1 on the appropriate fields.



4.13.2.6 Aircraft information is presented in the SILs according to the following rules:

Information displayed 10 minutes prior to sector entry (or for a departure 10 minutes prior to ETD)

Information removed on AOC by receiving sector controller

Information up-dated if holding, by EAT calculated by the sequencing tool

4.13.2.7 Aircraft inbound to a measured sector will be allocated to a SIL according toits sector boundary crossing point. Designated tracts of sector boundary willbe linked to SIL’s. This allocation procedure will ensure that aircraft on directroutes will be displayed in a SIL that is relevant to the geographical area of thesector that they cross.

4.13.2.8 A SIL cannot be removed from the display. When there are no aircraft listedwithin a SIL, the minimum display consists of the header/move bar. A SILcan be moved by using PRESS and DRAG of Button B1 on the header/movebar.

4.14 Message Windows


4.14.1.1 The MESSAGE WINDOW facility consists of a pair windows, the MESSAGEIN WINDOW and the MESSAGE OUT WINDOW with essentially the sameproperties but some differences in function. Collectively, they are used toprovide co-ordination related communication Centre to Centre and Sector toSector by means of pre-defined messages. An example of a pair of MESSAGEWINDOWS is shown in Figure 4.18

4.14.1.2 These co-ordination messages are generated as a result of inputs made to theRADAR LABEL, SILs or supportive tools such as the VAW. The co-ordinations may be accepted by CLICKING B1 on the appropriate fields in theMESSAGE IN WINDOW.

4.14.1.3 An operationally appropriate set of Co-ordination messages for any particularimplementation of the REFGHMI must be defined.

4.14.1.4 Both Message windows are displayed from start up.

24003.10 F m C: SAS809 C hange XFL from 330 to 290

Message IN

24003.10 T o DY: SAS809 change PEL from 330 to 290

Message OUT

Figure 4.18: Message Windows



(The example use ODID sectors. The Message Out window is taken from Sector C.The Message In window is from Sector DY).

4.14.2 Description of the MESSAGE WINDOWS

4.14.2.1 Both message windows have the following attributes:

• parent windows

• not iconifiable

• non-closeable

• moveable (anywhere on interface namebar/handle)

• dynamically re-sized by the system but minimum space for oneline of text

• non-modal


• high priority on invocation and stays above tools and RPVDbut not General Toolbox

• square corners


4.14.2.2 The Message Windows cannot be removed from the display. When there areno messages within a message window, the minimum display consists of theheader/move bar. Both Message Windows can be moved by using PRESS andDRAG of Button B1 on the header/move bar.

4.14.2.3 For co-ordination, the message is removed once the co-ordination has beenaccepted or counter proposed (if allowed).

4.14.2.4 All messages are time stamped in minutes and tens of seconds as illustrated inFigure 4.18.

4.14.2.5 The MESSAGE WINDOWS support co-ordination for:

• XFL/PEL co-ordination initiated by either the offering oraccepting controller (counter proposal possible).

• Heading, speed and rate of change initiated by the acceptingcontroller (no counter proposal).

• Change of entry or exit point.

• Radar Hand-over initiated by the offering controller.

ODID IV also supported

• departure clearance requests initiated by the system (it waspossible for these to be amended by the accepting controller) atETD minus 10 minutes.

4.14.2.6 Standard input functions as defined for the same fields of the RADAR LABEL(§4.8) operate in the MESSAGE WINDOWS but only on the original (not theproposed) values of parameters.

4.14.2.7 The following additional interaction is available:



CLICKING B1 on proposed new value accepts co-ordination proposal. Thisremoves the message from both the receiving and sending sectors and restoresto normal colour the values that were highlighted in the co-ordination colour34.Messages within the message windows are in BLACK with proposed values inBLACK on a background of the COORDINATION Colour. The originalvalues are shown in WHITE.

CLICKING B1 on the original value in the message allows production of acounter proposal by invoking the appropriate menu window to input a value.

4.14.2.8 As a result of a counter proposal input:

• the current messages in the sending and receiving controllerswindows are removed

• sector as the sending sector are generated causing the messagesto switch from incoming to outgoing windows and vice versa.These messages show the original values of the parameter andthe counter proposal in the ‘change to’ field.

• the refused levels (in XFL/PEL co-ordination) will be recordedfor ‘dimming’ in the VAW of both sectors for the concernedflight .



Notes on Chapter 4

1 For the present this icon button carries a simple text legend. It may be that a suitableicon could be devised for this function should time permit.

2 The status of the Auto resolution should be stored within the preferences file.3 The definition of a set of radio buttons is that only one button in the set can be

selected at any time. Making a new selection de-selects any previous selection.4 Suitable lengths for the leader lines on the radar display will have to be determined in

practice. A suggested starting set is 75mm, 150mm and 220mm respectively. NOTEthat there is also a difficulty in deciding which point on the label should be connectedwith the leader line. This is especially acute with dynamically changing labels andwith the label drag facility described in §7.2.6.

5 There is no need for a ‘deselect’ function on this tool. If an error is made in theselection of a point, it is sufficient to simply select a new point. Effectively there is anoverwriting editor. Compare this with the Tracker Tool.

6 For the moment there is no suggestion that the radar display be frozen while thisactivity takes place.

7 The same colour system was employed on the other windows and supportive displaysto associate information relating to the same states

8 In the Advanced Organisations of the PHARE PD1 studies it has been suggested thatthe not concerned state should be further sub-divided into two categories, OTHER(Ncver Concerned) and NOT CURRENTLY CONCERNED for aircraft which willeventually enter the sector or have been transferred out. These two classes wouldshare the same colour coding conventions but differ only in terms of the amount ofinformation displayed in the aircraft label with the OTHER class having only callsignAFL and CFL. It would be possible to have all information button interactivity with aNOT YET CONCERNED aircraft

9 In the ADVANCED GHMI of PD1 there are several types of manual warning. Thereis a amnual warning for a conflict pair, inserted through the Conflict letter numberand used by a PC to draw the attention of the TCas in ODID, there is the interconsolemarker, activated through the Extended Radar Label Window, which can be used tohighlight an aircraft for another sector’s work position; and finally, there is the withinconsole reminder which can be added to individual aircraft symbols by a CLICK ofB3 on the aircraft symbol.

10 This terminology is a hold over from ODID and is perhaps slightly misleading inthinkink about modern ATC interfaces based on shared databases of information. Itis necessary to make the distinction between

a) the availability of information

b) the relevance of information.

In the the REFGHMI the information is assumed to be always available, but alsoalways improving in quality as the aircraft approaches the observer/controller. Thechange to advanced information in ODID IV originally meant that information wasavailable. In the REFGHMI, it is actually a prompt to invite the PC to begin thePlanning Process.

11 Another important advantage of the use of both infilled and transparent labels is thata system (or other controller) driven transition from one state to another can be usedas a signalling mechanism.



12 This implies that it is close to 6mm across. It could be the case that the acquisitionarea of the symbol is larger than the visual image presented by the symbol, but, if thisstrategy were to be adopted, some for of visual feedback (probably a highlighting)would have to be provided to indicate which symbol would be selected.

13 NOTE that the distinction between CLICK and PRESS AND HOLD is a critical one.Response times to input must be prompt and absolutely reliable or PD1 will sufferaccidental window re-prioritisation when label repositioning is required.

14 There was an error in the Reference System Specification [1] §5.3.4.10 where a B3CLICK on callsigns within the Conflict Risk Display (CRD) caused display of theHAW, VAW (and CZW) for that aircraft. This action should have caused display ofthe Extended Flight Label. If required the HAW and VAW can be invoked from thisextended label by a further CLICK of B3 on the CFL, AFL or XFL.

15 It will also load the aircraft into the HIPS. This is the main reason for the change.16 It is not clear if this is required for PD1.17 This is a significant change from ODID where only the Next Sector symbol (NS)

changed colour. The justification for the change is that there was no simple visualcue on ODID to inform the controller as to when a menu would be available from thecallsign. This change permits a simple rule. IF CALLSIGN IS IN THE ASSUMECOLOUR THEN A CALLSIGN MENU IS AVAILABLE. If the ‘not concerned’colour is not sufficiently legible for the callsign on the transferring out sector, thenthe callsign could be shown in the Black text on ‘not concerned’ colour format.

18 It may be important to ensure that there is a clear mechanism for indicating to thecontroller when inputs are possible and when they are not. It may be that the colourof the text is sufficient to achieve this.

19 A number of the controllers involved in ODID IV expressed the desire to see moreextended route information in this field. This should be considered in the light of theoperation requirements of PD1.

20 A mode or modality is a situation where the rules of inputs change locally (ortemporarily). Some interface design guidelines state that modes should be avoided atall costs, others that modes are quite acceptable, and very powerful, provided they areclearly indicated and that there is no ambiguity to the user concerning the staterelative to the mode, i.e. that modes are completely visible. This later viewpoint isthe one adopted for the REFGHMI. It is generally a property of a mode, that otherinputs cannot take place until the mode is exited (sometimes automatically whenother inpts are attempted).

21 If VAW has been enabled from the General Tool Box, this action will update it withthe information for this aircraft.

22 Care should be taken to understand the difference between ENABLING andINVOKING. Enabling means that the conditions which would prevent somethingoccurring have been removed. Invoking means specifically taking the action whichmakes something happen.

23 Only if holding has been implemented for PD1.24 This function is a true mode. This fact is communicated to the user by means of the

change in the cursor.25 The pop-up menus in PD1 (and ODID IV) are not ‘Pop-up’ Menus in the Motif

sense. The Motif definition of a pop-up requires that it appears on the depression ofa button (normally B3), that selection is made by moving the mouse and releasing thebutton, at which point the menu disappears and the selection is made. In ODID, PD1and the REFGHMI, the menu is invoked by a CLICK of B1 and remains until aselection is made by a second CLICK of B1.



26 This is an attribute that is introduced for certain classes of dialogue windows andmechanisms. It essentially means that interaction cannot take place anywhere elseuntil this dialogue sequence is completed, (or discarded). As a general rule for PD1,this particular type of modal dialogue may be DISCARDED by:

a) clicking B1 on a close or discard option if one is provided within thedialogue mechanism.

b) clicking B3 anywhere within the dialogue.

c) Clicking B1 or B3 anywhere OUTSIDE the dialogue mechanism.

It is a point of considerable difficulty whether such inputs should also beprocessed in their normal manner. This really requires some simpleuser testing. Consequently, it would helpful if the option could be keptopen for change at a later date. Best guess is that users will expect theB3 (inf. requests) to be processed but not necessarily the B1s. The B1swill depend on whether they have been deliberately moved to anotherB1 target because the focus of interest has shifted or clicked on vacantspace with the INTENTION of discarding the menu.

In the mean time it is suggested that the inputs should be IGNOREDother than to exit the mode.

Clicking B2 will have no effect until the Dialogue has been discarded or completed.

NOTE: One set of dialogue mechanisms, the System Message Windows is evenmore tightly modal than those described above. This consists of the SystemInformation Message (SIM) and the System Dialogue Box (SDB) described in§3.4.5. These cannot be discarded by the mechanisms described above. The SIMwill disappear when it is no longer relevant and the SDB will be removed only whenthe user makes the prescribed inputs.

27 In effect the next subsequent button press, wherever it occurs, should close the menuwithout making a selection, unless it is B1 on a menu item in which case thatselection will be made.

28 This facility was considered of questionable value in ODID IV. A forced ACT mightbe more useful. The author’s opinion is that both ABI and ACT are system eventsreflecting a particular kind of data model and are not really appropriate, ormeaningful, ‘objects of discourse’ for the controller. The FORCED ACT is really apassing of Planning Authority and a means of directing the following planner’sattention to the aircraft.

29 For example, in ODID IV, once the aircraft had been transferred or released, thecallsign and label remained in the assumed colour and only a single character in thenot concerned colour indicated that operation had taken place. An attempt to invokethe callsign menu at this stage evokes no response. There is at least one othercondition where the menu can be invoked with no options available. There shouldbe:

a) a clearer indication of when the menu is available, e.g. perhaps the entirecallsign should change colour following handover or release.

b) greater consistency of behaviour when the menu is not available, perhapseven an information dialogue box indicating that the menu is notavailable

30 This represents a change from the mechanism in ODID IV which showed the buttonas depressed. A button should only really move into the depressed state inconjunction with the depression of B1. If it were possible to provide this animationfeature, it would add quality to the interface.



31 Note that this mechanism is only appropriate for Reference Systems which do notincorporate advanced ATC tools and do not rely on precise trajectory predictions.Such systems will need to take account of the delay between making a proposal andits acceptance or negotiation, probably by making the edited ‘go direct’ begin from apoint in advance of the aircraft’s current position rather than directly from the currentposition as was included in ODID IV. Such a mechanism has been specified for theAugmented Dynamic Flight Leg of the Advanced GHMI of PD1.

32 This ordering was used in ODID IV, seemingly without complaint. It may requirechanging if the UK stereotype differs.

33 While Ground Speed is the reference speed between aircraft on the RPVD, IAS isalways used in communication with the aircraft. For this reason it is necessary thatthis menu, which will be used largely for updates of tactical instructions, shouldoperate on the IAS.

34 There is some reservation as to whether the present co-ordination colour (MODALGREEN) provides sufficient contrast on the WINDOW BLUE background of themessage windows.


Auxiliary DisplaysVersion: 1.0 Chapter 5 - 1

Chapter 5

Specification of the Auxiliary FlightInformation Display Elements of theREFGHMI

5.1 Introduction5.1.1 This chapter provides a detailed description of the Supportive Windows used

in conjunction with the Interactive Radar Plan View Display [Chapter 4] toprovide the HMI of the Ground Reference System

5.1.2 The chapter provides specifications for:

• the Conflict Risk Display (CRD)

• the Vertical Aid Window (VAW)

• the Conflict Zoom Window (CZW)1

5.1.3 The specifications describe:

• the basic attributes and properties of these windows

• the contents of the windows

• the interactions available to the controller within thesewindows.

5.1.4 The chapter is based largely on experience gained in the preparation ofspecifications for the PD1 GHMI. The input and windowing operationsemployed have already been detailed in Chapters 2 and 3 of this document.The specifications that follow are heavily influenced by those of the ODID IVsimulation and they draw heavily on the specifications [17], supportivedocumentation [11], [19] and the results of that simulation [3]. The colourpalettes employed for the present specification are based on those defined inthe Interim NATS Colour Standard [20] with minimal extensions to allowtexturing of the windowing environment itself. However, the logic of colouruse reflects a harmonisation with the developments of the ODID exercises.Revised palettes, clearly showing the extensions are shown in Appendices 3 &4. All colour descriptions relate to theses revised palettes.

5.1.5 However, it is acknowledged that all colours, line widths, font choices andsizes may require revision in the response to the individual display quality ofthe screens and the nature of the lighting environment employed for anyimplementation of the REFGHMI.



5.2 Medium Term Conflict Information: It’savailability and display.

5.2.1 In the Ground Reference System that is being specified in the presentdocument prediction capability is essentially assumed to rely on theinformation available in current, advanced operational systems. This isgenerally assumed to extend to around 10 minutes in the future. In moreadvanced systems the prediction capability will be based on informationderived from the initial version of advanced tools such as those of the PHAREAdvanced Toolset (PATS). It is generally considered that these tools willcomputationally extend the limit of ‘useful’ prediction to around 20 minutes inthe future.

5.2.2 As well as the temporal extent of a predictive capability there is a second issueas to how the available information is displayed to the controller. Thus inODID III the controller was presented with STCA on the RADAR Display andadditional tools in the form of the Conflict Risk Display, the Entry AidWindow, and the Exit Aid Window. In ODID IV, partly as a result of thefindings of ODID III, Entry and Exit Aids were merged into a single VerticalAid Window (VAW). Further, a limited trajectory prediction facility wasincluded and the CRD became the CARD (Conflict AND Risk Display) basedon a double definition of:

CONFLICT as the prediction that two flights will be within the sameairspace at a future time based on the known positions, flightplan information and current input clearance of the flight.

Sector

PEL /CFL

A B

xCFL

XFL

Sector

PEL /CFL

A B

xCFL

XFLRisk while on A - B

Conflict while on A - B

Risk while on A - B

Conflict while on A - B

(a) (b)ODID IV Conflict and Risk REFGHMI Conflict and Risk

acft acft

(on A -B)(on A -B)

Figure 5.1: The notions of CONFLICT and RISK showing the differences between the concept initially2 employed in ODID IV and that proposed as a

starting point for the REFGHMI

ODID IV CONFLICT RISK as the prediction that two flights will bewithin the same airspace at a future point in time based uponthe known positions, flight plan information and expectedclearances which have either been input as a CFL, or areimplied by the sector Entry/Exit (PEL/XFL) planning. ([11],§13.6, page 36).



5.2.3 It seem to the current designers, that the notion of Conflict Risk as describedabove was difficult to understand and explain in practise. For this reason, aslightly different notion of Conflict Risk was defined for both PD1 and theREFGHMI.

REFGHMI CONFLICT RISK as the prediction that two flights willbe within the same airspace at a future point in time basedupon the known positions and flight plan information, if aplanned clearance or modification does not come into effectas anticipated.

5.2.4 This notion of RISK is now based clearly and simply on the notion of a dangerwhich could occur if a PLANNED action does not come into effect asassumed, i.e. plans are not carried out. The difference between the ODID andPHARE/REFGHMI RISKS is illustrated in Figure 5.1

5.2.5 The REFGHMI will not initially be equipped with advanced conflictprediction and deviation monitoring in the sense that they are included inadvanced toolsets such as PATS, however, it would be advantageous if therecould be considerable continuity between the HMI in the Reference Systemand those which could be required for more advanced systems. Indeed it is theobjective of the REFGHMI to be a baseline or starting point for those wishingto develop such advanced systems. It is our intention that the HMI for suchexplorations should be seen as an evolved extension of the reference system.

5.2.6 For the PHARE exercises it was decided that there should be a referenceGHMI for the Reference organisation of that simulation and a singleAdvanced GHMI (ADVHMI) which would be capable of supporting both theAdvanced Organisations of the simulation. The ADVHMI was to be asuperset of the Reference GHMI. Consequently, the GHMI Strategy was asfollows:

Reference System (CONFLICT ANTICIPATION)

Simple exemplars of the CRD, VAW, HAW and CZW,based upon conflicts and conflict risks identified by rules ofknow and anticipated level occupancy over time.

Advanced Organisations (CONFLICT PREDICTION.)

CARD, VAW, HAW and CZW with enhanced functionalitybased on full trajectory prediction through PATS. Theaddition of the LOOKAHEAD display as an alternative formof visualisation for the controller.

5.2.7 This REFGHMI stays within the same limitations as the PHARE ReferenceSystem. It describes simplified versions of CRD, VAW, and CZW close tothose available for the PD1 Reference System. These in turn were very closeto their ODID IV predecessors but incorporated improvements derived fromthe results of the ODID IV exercise itself and from other activities within theEUROCONTROL Experimental Centre (e.g. [21]). The HAW has beeneliminated based on the conclusions of ODID IV.

5.3 The Conflict Risk Display




5.3.1.1 The CRD is invoked by CLICKING B1 on the CRD Button/Icon in theGeneral Toolbox as described in §3.6.2.4.

5.3.1.2 The CRD does not have a close button (§5.3.2.1). Like the RPVD the CRDmust always be present on the displayed surface. Thus the CRD button isshown depressed with a red diagonal like the RPVD button on the screenwhere it is displayed. In the case of multiple screen systems the button will beshown in the normal mode on other display screens. Depressing the buttonwith a B1 CLICK will transfer the CRD to the new Display surface andremove it from the original screen.

5.3.1.3 The status, position and internal filtering (height & time limits and conflict orconflict + risk settings) of the CRD are stored in the user’s screen set-uppreferences file managed through the Preferences Set Window (PSW) §3.6.4.

5.3.1.4 Once invoked, the CRD displays all conflicts/conflicts + risks detected by thesystem. In ODID IV the CARD was updated every 30 seconds, or when a newaircraft entered the system. In the absence of any negative reaction to thisvalue, it is recommended for the REFGHMI.

5.3.2 Attributes of the CRD

5.3.2.1 The CRD has the following attributes.

• parent window

• not iconifiable/not closable(no close box)

• moveable (by means of name handle PRESS and DRAG B1)

• re-sizeable (Fixed Aperture, re-scaled) Handle

• high priority on invocation (below General Toolbox)




• square corners (rounded corners for system messages)

• The position, size and parameters saved in preferences set

• minimum size (the display will have a minimum size related to the scale of l lookahead and legibility. Figure 5.2 is close to that size)

• colours as defined in the master colour chart for windowmanagement functions (See Appendices 3 and 4).

5.3.2.2 As with other windows, the re-sizing mechanisms differ from those used inODID IV. In particular, the zoom capability, described in §5.3.4, has beenmodified to make its behaviour more predictable.

5.3.3 Contents of the CRD Window



5.3.3.1 An exemplar of the CRD is illustrated in Figure 5.2. It consists of two mainregions. On the left there is a list of conflict pairs3 (callsigns) with anassociated, system assigned, CONFLICT LETTER. This list is ordered fromthe bottom up in terms of shortest distance of closest approach. Theindividual aircraft are shown in the colour reflecting their planning state. TheODID specification describes a scrolling capability associated with this list.No scrolling was implemented and there appeared to be little need for it undercurrent loads. If required, a scrolling mechanism, similar to that for the menusdescribed in Chapter 4, can be added.

5.3.3.2 The layout of the callsigns of aircraft involved in conflicts (Figure 5.2) differsfrom ODID, partly because vertical spacing in this case is more economicalthan horizontal, but also to permit associations of triple and quadrupleconflicts. (See footnote 3.)

5.3.3.3 At the top of the List area is a toggle RISK switch box for choosing betweendisplay of Conflict only, and Conflicts and Risks. This button is operated byCLICKING B1 which causes it to toggle between the two conditions in thestandard way. The conditions are shown by the legend on the button thatstates RISK IS ‘OFF’, with OFF in BLACK against WBlue Highlight when therisk is off and RISK IS ‘ON’ with the ON in WHITE against window WBlueDepressed when on. (It may be appropriate that the CRD and VAW should belinked so that changing the risk display status in one changes both).

10

5

5 10 15 20 25

A

B

C

D

A BAW1234

AF4167

B SWR416 DHL397

C SAS576 DLH319

D

CONFLICT RISK DISPLAY

IBE576 DLH524

RISK is ONON

Figure 5.2: Conflict Risk Display

In the simplified form suggested for the REFGHMI (See §5.3.3.5b). The illustration is closeto actual size



5.3.3.4 In the right of the window there is a graph type display with the X-axisshowing time in minute intervals from 0 up to a maximum of 25 minutes (forREFGHMI). Every 5 minute interval is labelled with the appropriate numericvalue. The Y-axis shows the distance of closest approach of the trajectories oftwo aircraft in nautical miles, from 0 to a maximum of 15 nm, with every 5 nmlabelled.

5.3.3.5 A conflict (or risk) could be shown by one of two alternatives:

a) As in ODID IV, a horizontal line is drawn along the line ofexpected minimum distance. The left and right end points ofthe line represent the times of initial loss of separation and theend of separation loss respectively. Consequently, theduration of the conflict is shown by the extent of the line. Theappropriate Conflict Letter is drawn on each of these lines atthe time of closest approach of the two aircraft. Conflict Linesare in the CONFLICT Colour (red) and Risk lines are in theRISK Colour (yellow).

b) The preferred alternative for the REFGHMI (and PD1) isderived from [21] and is shown in Figure 5.2. Conflicts areshown as white text on a Conflict Colour background (RGB%100,10,10) and Risks are shown as Black text on the RiskColour background (RGB% 100,90,12). The Conflicts (andRisks) are displayed as CONFLICT LETTERS identical tothose in the list, at a Y co-ordinate corresponding to thedistance of closest approach and an X co-ordinatecorresponding to the time of LOSS OF SEPARATION4. Theduration of the conflict is not indicated. This variation followsdiscussion with controllers and avoids the unnecessary pre-eminence given to slow converging conflicts because of thevery extended horizontal lines they present on the currentODID IV display.

5.3.4 Interaction with the CRD Window

5.3.4.1 The window can be moved and re-sized by means of the general windowmanagement mechanisms described in Chapter 3.

5.3.4.2 Risk as well as conflict data is displayed optionally by means of the RISKbutton described in §5.3.3.3.

5.3.4.3 The scale of the two axes can be varied independently by means of a PRESSand DRAG using B1 on the square black rectangles that act as handles oneither scale. This causes the handle to shift to the new location chosen by thecontroller, increasing or decreasing the scale. Once the scale has been re-drawn, the handle is repositioned at the mid-point of the scale. The scales canonly be moved to a minimum of 5 nm or 5 minutes and a maximum of 15 nmor 25 minutes. In order to provide feedback the selected handle will change toa wire frame on depression of the mouse button. This will then follow thecursor, along the relevant axis only, until the mouse button is released, atwhich point the scale re-draws.

5.3.4.4 This mechanism is considered to be more transparent and reliable than thezoom button employed in ODID IV.

5.3.4.5 CLICKING B1 on the Conflict Letter associated with a conflict, either in thelist or on the graph, causes the input of a warning, or the removal of a warning



if it has been already input, for the conflict pair. A warning causes the callsignfield of all the aircraft involved in the conflict, (or risk) to change to theWarning Colour (RGB% 100,90,12) on all displays5. Further, following aninnovation by the PD1 Implementation Team, moving the cursor onto aConflict Letter causes the callsigns of the aircraft involved in the conflict tohighlight temporarily in Warning Colour as if the warning had been input.

5.3.4.6 CLICKING B1 on any of the callsigns gives access to the CALLSIGN MENU,(§4.9) in the cases where it is available for that aircraft, and the SKIP optionwhen the aircraft is in the ADVANCED INFORMATION state and has notbeen offered for acceptance.

5.3.4.7 B2 causes the CRD and all its child windows to move to the top of themodifiable window stack, if it is not already there. If it is already at the top, itmoves to the bottom.

5.3.4.8 CLICKING B3 on the Conflict Letter causes the CZW to appear, displayingthe relevant conflict. (Also, optionally the VAW)

5.3.4.9 PRESS and HOLD of B3 on the Conflict Letter produces a temporary displayof the CZW (and optionally the VAW).

5.3.4.10 CLICKING B3 on any of the callsigns in the list causes the Extended RadarLabel Window for that aircraft to be presented. PRESS and HOLD causestemporary display of the ELW at the callsign location.

5.3.5 Possible Enhancements to the CRD Window.

5.3.5.1 A very useful extension to this device would be a simple means of classifyingconflicts into, converging, climbing, descending, crossing or oppositedirection, if this could be done on the basis of simple rules rather thantrajectory prediction6. The different types of conflict could then berepresented with appropriate symbology on the graphical element. Thisenhancement should be acceptable within the terms of the reference systembut would effectively represent an advance on current systems.

5.3.5.2 It is considered that the availability of trajectory prediction in the moreadvanced systems would allow the CRD to work in essentially the same waybut with much greater precision. The role of the CRD is seen to be that of ahigh level tool which plays a role in the controllers high level monitoring andmanagement of resources. In effect, it is used to identify the nature andquantity of work to be undertaken, the priorities (importance and urgency) ofthat work and to provide a point of departure for undertaking a new planningor conflict resolution task.

5.4 The Vertical Aid Window (VAW)


5.4.1.1 The Vertical Aid Window is initially enabled by CLICKING Button B1 on theVAW icon/button in the General Toolbox as described in §3.6.2.4. The statusof enabling means that it will be displayed if a number of other conditions aremet. The fact that the VAW is enabled is shown by the depressed state of theVAW Button. The VAW is disabled by another B1 CLICK on the button/icon.CLICKING B1 on the VAW button on a toolbox in another display will cause



it to be transferred, if open, or to make its appearance on the other screen wheninvoked, if not currently open.

5.4.1.2 The VAW can be opened in a number of ways. The VAW is opened if B3 isCLICKED on either the CFL, AFL or XFL of any RADAR LABEL. In ODIDIV the VAW displayed Conflicts only if invoked from the CFL or AFL andboth Conflict and Risk if invoked from the XFL. It is suggested that this maybe too subtle a distinction and that for the REFGHMI all invocations causepresentation of both conflict and risk. A mechanism is provided for theremoval of risk. If this found to be operationally unacceptable the ODIDmechanism could be implemented.

5.4.1.3 The VAW can also be optionally opened if B3 is CLICKED on the ConflictLetter in the conflict list of the CRD. (The CZW is also opened in this case.)

5.4.1.4 The VAW is closed by CLICKING B1 on the close button located on left ofthe menu bar. Closing the VAW does not change its enabled status. It willreappear when next invoked. Disabling can only be effected through theGeneral Toolbox buttons as described in §5.4.1.1

5.4.2 Status of VAW Development

5.4.2.1 The VAW as used in ODID IV was an enhancement and integration of theseparate Entry Aid and Exit Aid windows employed in ODID III. The impetusfor this integration derived from controller feedback from the ODID IIIsimulation. The availability of experimental conditions, particularlydifficulties with the re-computation of trajectories, limited the effectivenesswith which ODID IV can be considered as a test of this new form of thedisplay. However, it is clear that controllers considered it to be a much moreuseful tool than the HAW.

5.4.2.2 In spite of the ODID controllers’ positive attitude to the VAW, it is evidentthat it could be improved in a number of ways. The need for scrolling in thevertical direction could possibly be eliminated by developing better rules forthe display of information on initial presentation. Similarly, the range of thehorizontal axis appears to compress the most relevant information into asmaller area that necessary while conveying little information in other areas.However, simply generating a new set of untried rules at this stage is equallylikely to cause problems. What is actually necessary is a period of prototypingon this display. In practice, we should expect to revise this display, in anumber of areas, after its initial implementation. The main areas are:

• the horizontal and vertical ranges shown on initial presentation

• the addition of dynamic sizing on initial presentation (note thatthis is a change to attributes)

• the nature of the information shown on individual aircraft, e.g.inclusion of type data

5.4.2.3 It is not anticipated that any major revision of the interaction mechanisms withoperational data will be required.

5.4.2.4 The only changes of any significance proposed in the present descriptionrelates to the display of conflict and restricted regions within the display.These are in keeping with feedback from ODID IV that the existingmechanism led to unnecessarily large regions of highly saturated CONFLICTRED.



5.4.3 Attributes of the VAW

5.4.3.1 The attributes of the VAW are:

• parent window

• has to be enabled from the General Toolbox

• closeable

• moveable

• re-sizeable varying aperture (but some internal re-scaling as in the CRD)

• minimum size

• no internal Toolbox presently envisaged

• no scrolling or panning at the moment, but may be re-scaled


• square corners

• position size and parameters saved in the preference set

• colours defined in the master colour chart for windowmanagement functions

5.4.4 Contents of the VAW Window

5.4.4.1 An exemplar of the VAW is shown in Figure 5.3. The VAW displays avertical view, a slice of airspace displaying a minimum of seven (parameter)FLs of the designated aircraft's flight profile through the sector from threeminutes before entry or actual position, whichever is later, to three minutesafter exit. On change of subject aircraft the selected levels are centred on theCFL. Conflict information (including Conflict Letter) is presented as filled(colour) rectangles. The edges of the regions correspond to loss and regain ofseparation. The background of the display is CRD BACKGROUND GREY(RGB% 48,45,45) and the sector is displayed in SECTOR ON LAND (RGB%39,37,37). The axes and value texts are drawn in BLACK.

5.4.4.2 The callsign of the subject aircraft is presented on the handle of the window inItalic text, and is repeated in the appropriate planning colour (infilled labelform) together with some aircraft information, specifically including typepositioned to the top centre of the window (see Figure 5.3)

5.4.4.3 CFL (PEL) and XFL values may be input through the level value radio buttonsdisplayed at either side of the vertical view (CFL left side and XFL right side)with horizontal lines (SHADOW GREY, RGB% 20,20,20) in the viewshowing FLs. CLICKING B1 on either a PEL/CFL or XFL value will changethe current PEL or XFL of the subject aircraft to that value. The currentlyselected, and any subsequently selected, value is shown by depression of therelevant button and an inversion of the text colour from BLACK to WHITE.The height scales are increments of 20 (e.g. 350, 370) above FL290 and 10(270, 280) below. The subject aircraft’s Requested Flight Level (RFL) isshown by an asterisk after the corresponding XFL value.



A

PEL XFL

1 0 . 2 1 . 2 0

BAW2 314

C RRR1 201

F IN1 2 1 1 DC9 2 9 0 XPT 4 7

XPT

3 5 0

3 3 0

3 1 0

2 8 0

2 7 0

2 6 0

2 5 0

2 4 0

2 9 0

3 5 0

3 3 0

3 1 0

2 8 0

2 7 0

2 6 0

2 5 0

2 4 0

2 9 0

RISK is ONON

25 30 35 40 45 50 55

EPT

VAW : FIN1211

4 9 0

1 1 0

2 3 0 2 3 0

350

230

Figure 5.3: The Vertical Aid Window.

This illustration (not actual size) shows the consequences of overlapping conflict and riskregions. It also illustrates the presence of a zone of restricted airspace

5.4.4.4 Time is displayed along the bottom, marked in minutes with every 5 minutevalue shown as in CRD. Time of information display request is shown(predicted, i.e. 3 min prior to entry or actual request time). This is positionedon the vertical axis at the bottom left hand side of the figure to illustrate thetime to which this axis corresponds. In the illustration this is 10.21.20.

5.4.4.5 Sector boundaries are indicated by shading the sector area as SECTOR onLAND (RGB% 39,37,37). The exit point, if known, is indicated bypositioning a beacon symbol and name at the appropriate time near the X-axis.The Beacon EEL is shown in Figure 5.3.



5.4.4.6 The subject aircraft’s level profile is represented by a line GREEN (RGB%46,88,31) with the aircraft’s position symbol and heading vector representingthe start of the line (BLACK). Other aircraft are denoted by a filled colouredrectangle. The cross section of the conflict rectangles will indicate theduration of the conflict in time and distance and the upper and lower levelswill indicate the affected level band. Conflicts are shown as a 60%transparency of the conflict and risk colours Conflicts always appear ‘above’risks. A potentially large number of transparency combinations could arisefrom the presence or absence of conflict and risk and whether they lay withinthe sector or not. This has been rationalised so that only the following fourstates are employed. Events lying outside the sector are treated as if they werewithin the sector for colour purposes and risk/risk overlaps are not presentlydistinguished although this could be added quite simply as a 30% RISKtransparency. The combinations defined are as follows:

Within Sector:

COMBINATION COLOUR CODING

Conflict RGB% 63, 26, 26

Risk RGB% 63, 58, 27

Conflict on Risk RGB% 78, 39, 20

Conflict on Conflict RGB% 82, 18, 187

5.4.4.7 Restrictions on airspace are shown by an appropriate rectangle in theRESTRICTED ON SECTOR COLOUR. To preserve the contrast of thisregion against the other regions, and to avoid the production of moretransparencies, it is outlined in WINDOW FRAME SHADOW GREY. Thesezones are always drawn as if in front of the sector but behind any risks andconflicts except for the outline.

5.4.4.8 Each rectangular region is also labelled with the relevant conflict or risk letterand the callsign of the aircraft involved, presented in the standard conflict orrisk colour conventions.

5.4.4.9 This window provides the controller with an additional opportunity to verifypre-entry, through sector and sector exit conditions. Dialogue may be effectedthrough the designated target, CFL and XFL values or Conflict Letter for thesubject aircraft but is limited to calling the extended label on other targets.

5.4.4.10 On invocation, the VAW shows both Conflict and Risk information. The Riskinformation can be removed or restored by CLICKING B1 on a RISK buttonidentical in appearance and operation to the one specified for the CRD.

5.4.5 Interaction with the VAW Window

5.4.5.1 Window management functions are according to the general rules, i.e. B1PRESS and DRAG on the move/name bar can be used to move the window.Similarly, B1 PRESS and DRAG on the handle can be used to re- size thewindow. NOTE that the re-sizing handle is of the Re-scaled Aperture type



§3.5.3.4, which redraws the same window contents at a greater scale as thewindow size is increased. It may be appropriate to identify a maximum size forthis window

5.4.5.2 The VAW can be closed by CLICKING B1 on the close button on the left ofthe move bar.

5.4.5.3 All standard label interactions are possible within the subject aircraft’s label.(Extended aircraft labels can be invoked by CLICKING B3 any aircraftcallsign. However, for aircraft other than the subject aircraft, interaction is notpossible with the extended label.8)

5.4.5.4 CLICKING B1 on the values of XFL or CFL/PEL scales will change therelevant values for the subject aircraft only.

5.4.5.5 Re-scaling of the X and Y axes can be achieved independently by differentmechanisms.

a) The X axis, (time) is modified by the same mechanism as isemployed in the CRD. That is, by means of a PRESS andDRAG using B1 on the square black rectangles that act ashandles on either scale. This causes the handle to shift to thenew location chosen by the controller, increasing ordecreasing the scale. Once the scale has been re-drawn, thehandle is repositioned at the mid-point of the scale. The scalecan only be moved to a minimum of 5 minutes and amaximum of 25 minutes. In order to provide feedback theselected handle will change to a wire frame on depression ofthe mouse button. This will then follow the cursor, along therelevant axis only, until the mouse button is released, at whichpoint the scale re-draws.

b) The Y axis, Flight Level, requires more complex manipulationanalogous to the height filter in the RPVD Toolbox withmodification of both upper and lower limits being necessary.This is achieved be a mechanism adapted from [32], andshown in Figure 5.3 to the left of the Y axis. In essence, thisis a reduced slider bar (in SHADOW GREY) with two sliderhandles corresponding to the upper flight level displayed andthe lower flight level displayed. These currently selectedlimits are shown to the left of the appropriate slider inBLACK. The region between the sliders, corresponding to thecurrently displayed levels, is shown as a thickening of theSlider Bar itself. The upper and lower limits of the airspaceare shown as BLACK text at either end of the slider bar.Manipulation of the values is by PRESS and DRAG with B1on the sliders. While in motion the current valuecorresponding to the slider position is shown in WHITE to theleft of the slider. The old value continues to be displayed inBLACK until the B1 is released when the new value isdisplayed on the left and becomes BLACK. Ideally, thedisplay of the VAW should change directly as the slider isdisplaced, however, it is recognised that this may be tooprocessor hungry. In this case the display should be updatedimmediately on release of the slider.



5.4.5.6 CLICKING B1 on the Conflict Letter causes input of the manual warning onConflict Group as in the CRD. Moving the cursor onto a Conflict Lettercauses the callsigns of the aircraft involved in the conflict to highlighttemporarily in Warning Colour as if the warning had been input.

5.4.5.7 CLICKING B3 on the Conflict Letter causes display of the CZW. PRESS andHOLD B3 causes temporary display of the CZW.

5.4.5.8 CLICKING B2 performs its normal window priority operations.

5.5 The Conflict Zoom Window (CZW)


5.5.1.1 The Conflict Zoom Window (CZW) (Figure 5.4) is invoked by CLICKING B3or by PRESSING and HOLDING B3 on the Conflict Letter in the CRD, orVAW. It is only available if the CRD, or VAW has been enabled from theGeneral Toolbox. (Departure from ODID IV.) The CZW will appear on thesame Screen as the cursor at the time of its invocation in multiple screensystems.

5.5.1.2 The CZW is removed either by releasing B3, if PRESS and HOLD has beenemployed, or by CLICKING B1 on the Close button at the left hand end of itsmove/name bar.

5.5.1.3 The name bar of the CZW displays the callsigns of all aircraft involved in theinvoking conflict as well as the Conflict Letter. The aircraft names will be inBlack Italic Text.

5.5.2 Attributes of the CZW

5.5.2.1 The attributes of the CZW are:

• parent window

• only available if VAW or CRD available

• closeable

• moveable

• fixed size

• only speed vector track history tool available at present

• no scrolling or panning


• appears only on screen from which it is invoked

• square corners

• colours as defined in master colour chart

5.5.3 Contents of the CZW Window

5.5.3.1 The CZW will present the controller with a system predicted image of whatthe detected conflict situation will look like at its minimum distance. Thewindow will display approximately 20 nm by 20 nm of airspace around thisposition showing the conflict pair radar label information.



5.5.3.2 Background map profile lines and heading vectors are shown. Labelinformation for other conflicting aircraft is also presented.

BEAC1

FIN1121 290 EEL 47

BAW2314 290 ↓ XPT 250

CZW : FIN1211 - BAW2341

SP/ TH10.39.20

A

Figure 5.4: The Conflict Zoom Window

(Approximate Actual Size)

5.5.3.3 The time of minimum predicted distance is displayed at top centre . Time isshown as WHITE Text on SHADOW GREY (RGB% 20,20,20). The ConflictLetter, is shown in its usual form and can be used for the input of a manualwarning. It is placed close to the loss of separation. The aircraft labels, andthe conflict time can be moved by PRESS and DRAG of B1.

5.5.3.4 The trajectory of both subject aircraft is shown in Green RGB% 46,88,31.Sections of all conflict trajectories, from loss of separation until return ofseparation, are shown in CONFLICT RED (RGB% 100,10,10).



5.5.3.5 Since only aircraft that are predicted to be in conflict are shown in the CZWthere is no need to display them in the conflict colour.9 Text and labels are inthe colours appropriate to their CURRENT STATE so that the controller cansee instantly which aircraft can be the subject of interaction. Conflict labelcoding is redundant. The information in the aircraft labels is also theinformation relating to the aircraft’s CURRENT STATE.

5.5.3.6 It is questionable whether interaction should be allowed with the aircraft labelinformation in the CZW. However, if it is decided that this is acceptable thennormal interaction rules for all aircraft apply. This is a departure from ODIDwhich only permitted such interaction for the subject aircraft. If interaction isnot allowed, there will be no infilled aircraft label states.

5.5.3.7 It is not clear whether any tools are actually required in the CZW. The onlycandidate is the same Speed Vector Track History Tool as is available throughthe RPVD Toolbox. The Icon/Button, for this is shown in Figure 5.4, Thelabel of this tool is difficult to identify; SP/TH may suffice.

5.5.4 Interaction with the CZW Window

5.5.4.1 Window management functions are according to the general rules, i.e. B1PRESS and DRAG on the move/name bar, can be used to move the window.CLICK of B1 on close box to remove CZW.

5.5.4.2 IMPORTANT: Label SELECTION operates in the CZW as in the RPVDand other tools. When the cursor enters the aircraft label it goes into theinfilled form. However, an additional feature is required in that when thecursor is in a label the background to the callsign of both conflict aircraft,within the RPVD is displayed temporarily in WARNING YELLOW as if themanual warning (§4.6.4.3.3) had been input. This function helps thecontroller find the current position of the conflict aircraft in the RPVD and isremoved when the cursor exits the aircraft label.

5.5.4.3 Standard inputs as specified for the same fields of the RADAR LABEL for allaircraft shown (only if interaction permitted).

5.5.4.4 CLICKING B1 on the Conflict Letter causes input of the manual warning onConflict Group as in CRD (the callsign changes to warning yellow for theconflict aircraft on the RPVD). This is also described in (§4.6.4.3.3). Movingthe cursor onto a Conflict Letter causes the callsigns of the aircraft involved inthe conflict to highlight temporarily in Warning Colour as if the warning hadbeen input.



Notes on Chapter 5

1 As discussed in Chapter 1, the Horizontal Aid Window (HAW) of ODID IV wasconsidered to be somewhat redundant and was omitted from the subsequent PD1 andthe current REFGHMI Specifications.

2 The definition described here was employed at the beginning of ODID IV but wasmodified in the course of simulation to reduce the number of very low probabilitypotential conflicts which could be indicated under this type of system. Note,however, that both definitions remain unsatisfactory. The idea of ‘Risk’ is a poorsubstitute for that of ‘Traffic’ but this latter is very difficult to define.

3 The identification of conflict aircraft in pairs is an artefact of the analysis techniquesemployed. Controllers do not seem to decompose (or resolve) conflicts in this way.For example, rather than present two pairs with one aircraft in common, it might bebetter to present a single conflict that associates all three aircraft.

4 Please note that one important consequence of this change is that the two scales ofthe CRD should be interpreted separately. The distance available is ‘distance atclosest approach’ The time value is the time at which separation is lost andconsequently, the latest time by which remedial action should have taken place. Thetime does not relate directly to the point of closest approach. Thus if a controller’sown estimate of the time of a conflict is based on closest approach, it may seemdifferent from the time indicated in the CRD. The controller’s understanding of thisdistinction should be monitored carefully to ensure that no confusion is arising.

5 It remains to be see whether this will cause any difficulty by interacting with thechange of callsign colour for HANDOVER, TRANSFER and RELEASE described inChapter 4.

6 Discussion with appropriate technical experts, suggests that this should becomparatively straightforward.

7 This corresponds to a transparency of 30%. In fact, it should be around 36% (60%transparency on 60% transparency), but the resulting perceived contour was judgednot quite strong enough for the desired effect.

8 Perhaps there is a need for a mechanism to indicate when extended labels are forinformation only and when they support interaction. It should also be noted that notall fields in an extended label are interactive in any case.

9 Perhaps the namebar/handle should be coloured differently to indicate the specialstatus of this window. If this found to be necessary, WINDOW RESTRICTIONRED (RGB% 65,21,20) is recommended.


HMI PrinciplesVersion: 1.0 Chapter 6 - 1

Chapter 6

Human Factors Assumptions,Principles and Models Underlying theREFGHMI

6.1 Introduction

6.1.1 Purpose

6.1.1.1 A number of ideas, principles and Human Factors Guidelines have played animportant part in the development of this interface and the related interfaces ofboth the Reference System and the Advanced Organisations of PHARE PD1.This chapter attempts to identify and explain some of these influences andexplain the way in which the designers believe they are implemented in thedesign itself. It also discusses the automation philosophy which was used inthe preparation of the PHARE PD1 interface and discusses how it is reflectedin the REFGHMI described here.

6.1.1.2 A number of the principles, models and theories employed in this design anddescribed in the following text result from the authors collective experience inthe design of interfaces, graphical and otherwise, over a number of years andin different control cultures. These principles have not been examined indetailed human factors experimentation and hence should be treated as nomore than (informed) personal opinion. However, the authors are willing tosubscribe a pragmatic definition1 of an adequate test for such principles, i.e.that an interface designed using them, clearly and unambiguously outperformsand is preferred over one that does not. Finally, it is for time and the users tojudge!

6.1.2 Target Readership and Contents

6.1.2.1 This chapter is aimed at those who will have to undertake similar designprocesses, perhaps even extending the present specification to embrace newfunctionalities and ATC requirements. It is not necessary to read this chapterin order to build the interface. It is necessary in order to understand Why andHow it works.

6.1.2.2 The text does not assume that readers have a psychological or ergonomicsbackground but it does assume that they have already encountered and arefamiliar, with the many of difficulties that arise in trying to understand, designand (perhaps) specify similar complex graphical interfaces. It is targeted atreaders who have met with problems and want ways in which to address them.What follows is a series of ideas that the authors found helpful in the task ofstarting with ODID III and ODID IV descriptions and moving through PD1before producing the present document. Ideas are introduced and explained assimply as possible with a few key references to psychological and interface



design literature and guidelines which may prove helpful to those wishing tofind more powerful and general principles.

6.1.2.3 Some of the ideas and guidelines had already played a significant part in thedevelopment of the starting point for this interface, i.e. the early versions ofPHIDIAS and ODID III itself. Indeed [4] represents an articulation of manygeneral HMI and Graphical Interface Design principles in the language, andfrom the perspective of, those who rediscovered them from within theOperational ATC Community. These will not be discussed further, in thistext. They are already well documented both from the ATC perspective in [4],and for more general HMI application in [5], [6] and [8].

6.1.2.4 Discussion begins in §6.2 with a listing of some of the specific designobjectives which were derived from PHARE PD1 requirements for theconversion of ODID IV to PHARE purposes. These should help explain thedifferences between the current REFGHMI and ODID IV. This is followed in§6.3 by an explanation of the way in which colour has been employed in theREFGHMI. In §6.5 we present a summary of the conceptual model of actionwhich was used to think about the way in which the controller prioritises taskand navigates around the interface. The text finishes with a short list ofimportant principles.

6.2 Design Objectives in the Re-Modelling of theODID IV Interface

6.2.1 Design ‘Tactics’

6.2.1.1 The immediate ancestor of the PHARE PD1 Reference GHMI and the presentREFGHMI was ODID IV as represented by the Simulation Specificationdocument and by the finally implemented system. This system was thensubjected to a human factors re-engineering process for the PHARE GHMIactivity. The following objectives were identified for this process:

a) resolution of any interface difficulties or inadequaciesrevealed in the course of ODID IV or ODID IVbis.

b) make the interface much more robust against interface errorsparticularly against those that result from unintentionalincorrect inputs (action slips) or arising from queued inputsattributable to the interaction of poor response times andfeedback.

c) make the interface more consistent.

d) make the interface more transparent (i.e. the consequence ofactions should be clearly predictable and modes should beshort and clearly indicated).

e) to try to ensure that the user need only think at the (ATC) tasklevel and need not make decisions at the level of inputtechnique. User intentions should be naturally expressed interms of ATC objectives as opposed to HMI action sequences.

f) ensure that the interface is open and flexible. That is, theinterface does not commit the user to long sequences of input,



nor does it prevent the user from switching tasks and retainingresults of partially completed activity.

g) within the constraints of a) to f) to keep required input actionsto a minimum both in terms of the cognitive effort associatedwith them (cost) and their number.

6.2.2 Design ‘Strategies’

6.2.2.1 In addition to these specific ‘tactics’, for re-engineering, a number of higherlevel design ‘strategies’ were made explicit.

6.2.2.2 Separation Of Procedures And Interface Mechanisms

6.2.2.1.1 As far as possible the operational procedures would not be ‘hard-wired’into the interface. This was intended to provide a separation of operationprocedure, which cannot often be well defined at the initial systemspecification stage, from the mechanisms of the interface. If theoperational procedure has to be changed the interface will not necessarilyneed to be changed.

6.2.2.1.2 This has special implications for the error management style adopted bythe interface. Highly specific error monitoring and prevention based onprocedures cannot be built in2. The designer has to assume that the useris intelligent, responsible and well intentioned and will not deliberatelyseek to push the system beyond its limits (during measured exercises).The system does not try to forbid potentially destructive actions3.Specific inputs are not made impossible since, with a change inoperational procedure or task partitioning, they may become useful. Thedesign therefore has to become error tolerant rather than error free. Thisis not incompatible with the tactic expressed in §6.2.1.1.b concerningrobustness against certain classes of error.

6.2.2.3 Initiative For Action Stays With The Controller.

6.2.2.3.1 Based on experiences with previous interfaces [22] and the continuingconcern with how the admonition to ‘keep the controller in the loop’,[23, 24] is to be realised there is a policy that:

‘As far as possible the controller should not be forced to bereactive to the interface, but should be presented withinformation which permits the decision how to allocateresources and priorities to tasks generated by the traffic.’

6.2.2.3.2 An important consequence of this is that, to allow flexibility of resourceswitching by the controller, the interface should not require long relatedinput sequences that have to be followed through without interruption(see §6.2.1.1.(f)). It should also provide the controller with theinformation necessary to decide when to change priorities.

6.2.2.3.3 A further consequence is that the interface should not prevent thecontroller from seeking innovative but viable solutions to unusualproblems. This reinforces the previous assumption’s need for a tolerantapproach to error management. The system must assume that thecontroller is an intelligent and responsible agent and, allow exploratorybehaviour.

6.2.2.4 Data Access and Flight Database Model



6.2.2.4.1 Both of the previous principles emphasise that there should be fewrestrictions on the user. An important extension of this is in the model ofinformation access in the REFGHMI, and in PD1, which is that thecontroller can always access available data. This model differs from thatused in ODID and implicit at least in the early SYSCO documents [30].That model is based on task authority defined by control of access toinformation. For example, information is only available to the plannerwhen the aircraft enters into the ADVANCED INFORMATION state.

6.2.2.4.2 For the REFGHMI we assume the existence of a universally availableflight plan database with the best available System Trajectories(descriptions of aircraft intentions) and a separation of read access andwrite access. Anyone can have read access to information on any aircraftthat is suitably represented on their displays. Ability to change thisinformation is however strictly limited to those with the appropriateplanning and tactical control authority for the aircraft at that stage in itsprogress. As a result in the REFGHMI the controller always has B3(INFO button) access to aircraft information through the aircraft label.Changes in plan, coordination or tactical control (B1 activities) are onlypossible when the aircraft lies within the controller’s responsibility.

6.3 Automation Philosophy: the ‘Role of Man’ andits implications

6.3.1 Background

6.3.1.1 The general approach to the role of the controller in the PHARE programmewas developed by the dedicated sub-group at a comparatively early stage in theprogramme. The consensus of this group was presented in a document [29]which describes the role in general terms. In particular [29, §2.3.1.2] lists anumber of design constraints that have been accepted for the PD1 system andthe current REFGHMI. In summary, the PHARE system is seen as a user(controller)-centred evolution from present day systems with emphasis onretaining the ‘controller in the loop’ (see §6.2.2.2). A few assumptions aboutthe general nature of the interface implied by this need are discussed below.

6.3.2 Transitions in the Role of the Interface

6.3.2.1 The PHARE document suggested that one important element of keeping theoperator in the loop is that liability, responsibility, understanding and powerto act (or authority) must be co-located with the operator at the necessarycritical system states [29, §2.3.1.2.e]. Understanding and the power to act areoften addressed in the construction of interfaces, albeit in an indirect waythrough the prioritisation and presentation of information and the definition ofthe interaction possibilities. Liability, the legal significance of controlleractions, can be considered as reflected in a variety of measures (which mayalso have other motivations). For example, the recognised importance ofincluding controller’s in the design process, the cultural requisite forvalidation through large scale simulation and the fact that the final word inusing an element of a system or not, practically lies with the controllers. Allof these recognise the controller’s legal status. On the less positive side datarecording and incident reporting procedures also relate to this aspect. It could



reasonably be argued that these elements also reflect the notion ofresponsibility, however, it may also be appropriate to ask if there is:

a) a requirement to reflect responsibility in the interface designprocess itself, and

b) any means by which this could be achieved.

6.3.2.2 The first of these two questions has not been previously explored (within ourlimited knowledge), but it does seem to the authors that a significant transitionin the role of interfaces, with implications for controller responsibility, istaking place. This transition can be thought of as taking place in two stages,moving between the states of:

• Todays paper strip systems

• ‘Stripless’ systems like ODID III and IV and the PD1Reference System which mediate information transmissionbetween sectors and controllers

• Advanced systems which mediate the transmission ofinformation to the aircraft as well as between sectors

6.3.2.3 We would argue that until recently the role of the controller interface has beento present the operator, in a clear and unambiguous way, with informationreflecting events ‘in the real world’ and the intentions and requirements ofaircraft. This information allowed the controller to make decisions andperform appropriate actions. These actions were not made via the interface, orat least the computational element of the interface. The transmission ofdecisions to the aircraft was made via R/T, to other controllers via thetelephone systems and to colleagues through direct speech. In paper stripsystems, even the records of actions were independent of the computationalelements for the greater part. The data within the computational part of thesystem was derived from sensors and the flight plan processing systems.Interactions with the system were primarily concerned with manipulating theinformation presentation to the controller himself.

6.3.2.4 In ‘stripless’ systems like ODID and the current REFGHMI new elements areintroduced.

a) In order to have the advanced displays provided by the system,the controller has to make inputs following actions so that thesystem is kept up to date. These inputs are still made aftertrue ATC actions have taken place and REFLECT the realworld.

b) A certain number of controller actions now pass via thesystem, i.e. proposals for coordination and the distribution, toother controllers, of data reflecting controller actions. The firstclass of information is now anticipating actions in the systemand for the first time there is the possibility that incorrectinterface input values can have DIRECT effects on controlprocedures. However, this effect is not yet strong and theconsequences of such input actions can be limited by thenature of other procedures. For example, frequency is notautomatically transferred with the input of a TRANSFER.

6.3.2.5 At the next level of the Advanced Systems, where planning inputs are made tothe system which then transmits them directly to the aircraft via datalink, the



transition is complete. Here the controller manipulates the interface in order tomanipulate events in the real world. An incorrect interface interaction cannow result, almost directly in incorrect behaviour in the real world. A wholenew significance is now attributed to interface inputs. There may beproblems associated with the fact that a significant and possiblyirrecoverable action can be undertaken with very great facility.

6.3.2.6 It seems to the authors that these transitions have direct implications for theway in which the interface approaches the topic of input errors. In §6.2.2.2.3we suggested that the interface should not take an authoritarian line in theeffort to avoid ‘operational errors’ but we are now faced with the possibilitythat simple interface ‘action slips’ [32] can have direct operationalconsequences. How can these two elements be reconciled?

6.3.3 Interface Style and Function

6.3.3.1 The approach adopted for the REFGHMI and for (PD1) has been to try tocreate an interface with a Responsible Style. By this we mean:

An interface that encourages the user to give consideration to inputswhich might have an operational significance before they are made.

At the same time the interface must be made as easy to use and as ‘direct’ aspossible.

6.3.3.2 Initially, it might seem strange to suggest that anyone should create aninterface with an irresponsible style, however, after reflection it is reasonablethat in circumstances where:

a) the consequences of input errors are severely limited, and

b) the cost of correction is very low, and

c) least cognitive effort from the user is given a high weighting,

there might be cases where such an interface is suitable. A good example is tobe found with many word processors where it is accepted that typing errorsand other action slips will occur with a comparatively high frequency.Nothing other than the document being prepared is normally directly effectedby the input slip. In such cases there are many lines of defence, there can beon-line and post input spelling and grammar checkers; there can be simple lastaction and multiple action ‘undo’ functions. Additionally, there are thenormal outflow monitoring skills of the proficient user. The few actions thathave a danger element such as saving, deleting and overwriting files, can besubject to confirmation and system backups of actions.

6.3.3.3 However in ATC, where the proportion of significant actions is much higher,where the skills of the user militate against a restricting interface and thechecking/confirmation loops would be too onerous, another approach must befound. Further it is our suggestion that it is very difficult to build an interfacethat uses a few simple input rules and is highly consistent but which allowsseparation of some areas of responsible interaction and others with more laxprocedures. We would argue that where lax procedures, demanding littlecognitive effort, are established, they would tend to spread to other areas.Controller’s style and attitude to errors must also be consistent.

6.3.3.4 The problem for the ATC interface (REFGHMI) then becomes how to ensurethat the input mechanisms demand little cognitive effort but at the same time



ensuring that sufficient thought is given to the operational consequences ofhard to recover input actions4. The following strategies were employed:

a) Following ODID the principal operational decisions wereplaced in a single location (the Callsign Menu)

b) Steps were taken to limit the ease with which action slipscould be made. These included the steps, described inChapter 2, to improve the ODID interface for the REFGHMIand PD1 and the design tactics of this document. Further thecursor warping (system displacement of the cursor) todifferent callsign menu items, available in ODID wasremoved.

c) No ‘UNDO’ function is provided. Some items can beREDONE inflicting a workload penalty for error. (Although acase can be made for a single UNDO ASSUME where anaction slip has consequences only for the controller who madethe error.)

d) No double or triple clicking (although an implicit double clickfor ASSUME and SKIP can be found in the operationallyrelevant contexts).

6.3.3.5 However, the most important single way in which this responsible style can beestablished is through the form of presentation and discussion with controllers,where they have to be introduced to the idea that certain input errors involvehigh risk and cost. This should not be a difficult idea for a population withsuch a highly developed safety culture.

6.3.3.6 Other measures, such as finding a direct means of indicating/codingoperationally critical decisions can be considered, in the future, if necessary.

6.4. The Rationâle for the Use of Colour in theREFGHMI

6.4.1 The Problem (Historically)

6.4.1.1 While it is the opinion of the authors that it is highly artificial to treat the useof colour as a separate from other techniques used to prioritise the display andsaliency of information in a graphical interface, it is also accepted that the useof colour has been identified for many years as an issue by the Air TrafficManagement Research Community [25, 26, 27]. For this reason, the followingsection deals specifically with the application of colour in the REFGHMI. It ishowever, respectfully suggested that it is time for the debate to move on andthat for the future we should speak simply of the issue of appropriate displaypriorities and mechanisms rather than identifying colour uniquely as the issue.

6.4.1.2 It is also considered that the colour system integration achieved for the PD1Reference System and the current REFGHMI, was one of the most importantdevelopments of the PD1 GHMI Design Activity.

6.4.2 Two Different Approaches

6.4.2.1 At the time of preparation of the Specifications for the PD1 Reference System,the use of colour in the design of ATC displays had been based mainly on



designer judgement, trial and error and consideration of suitable stereotypicinterpretations of the use of colour. In Europe, there were two mainexceptions to this, the work of the ODID group itself, and the work sponsoredby the UK Civil Aviation Authority on the use of colour in, firstly, radardisplays and subsequently other ATC displays [20, 28]. The UK activity ishereafter referred to as the Interim NATS Standard. These two activities tookvery different approaches to the use of colour but both arrived at a much moresystematic and principled application of colour than had previously beenavailable to the ATC community.

6.4.2.2 Interim NATS Standard

6.4.2.1.1 The Interim NATS Standard [20] provides a structured rationale for theuse of colour based on the principles and literature of human visualperception. It then provides a system of layered palettes5, symbology andpresentation principles for the display of the information required forgeneric secondary radar displays, with high levels of legibility anddiscriminability.

6.4.2.1.2 To the observer the most striking aspects of the displays which resultfrom following the NATS Guidelines are the harmonious pastel colours;the effective use of transparency and the infilled labels for all aircraft onthe display.

6.4.2.3 ODID Approach

6.4.2.3.1 The ODID approach has a different emphasis. It derives from theattempt to establish an operational task oriented system for the use ofcolour. The initial approach was empirical, but over the series of ODIDsimulations, transcended the issues of identification of specific coloursto produce a series of related display principles described in [4].

6.4.2.3.2 The central theme of the ODID approach is the way in which colour canbe used to support the logic of the controller’s task. Colour is employedto clearly reflect distinctions central to the controller’s ‘cognitive’ modelof which aircraft states are critical for task identification, planning anddecision making. The logic was mainly developed in ODID III andfurther refined in ODID IV where it met with considerable controllerapproval6.

6.4.2.4 Integration of the Approaches (PHARE PD1)

6.4.2.4.1 The approach taken in preparation of the PHARE PD1 GHMI, andexpanded here, was to review the two application systems and then toattempt an integration based on the best features of both. The critique issummarised in the following sub-section (§6.4.3) together with theprinciples used to drive the integration. Since both systems werefounded on sound principles, the integration task proved both simple anddirect with little compromise required from either approach. The limitedexperience with the PD1 system at the time of writing, seems to indicate,that while ‘tuning’ may be required with individual colours, theintegration is proving to be better than either of its parents. The details ofthe compromise as followed in PD1 and the present REFGHMI aredescribed in §6.4.4.

6.4.3 Critique and Issues in Exploiting the Two Schemes



6.4.3.1 It appears that the mechanism recommended for labels (or plaques) in theInterim NATS Standard Document [20] is based primarily on a desire tooptimise the legibility of the text of the aircraft label (while still allowing awell-designed hierarchy of information saliency for the supportive map andairspace information). Extraction of the aircraft information by the controller,can be considered as consisting of two components. The first componentinvolves location of a specific aircraft through the mechanisms of locating,reading and identifying its callsign. This will be referred to as VISUALSEARCH. The second involves the extraction of the flight information oncethe correct aircraft has been identified. This can be considered (generally) asREADING7. In this later area of label text processing, it seems highlyprobable that the NATS Standard will be superior to the results so far achievedin ODID.

6.4.3.2 The information on which NATS label design criteria are based derives from athorough review of the colour literature covering both the psychophysics ofvision and the application of colour in information displays. Most of theavailable literature in psychophysics deals with repeated single instance,stimulus presentations. The information display literature deals primarily withstructured text displays of a comparatively homogeneous nature. Indeed, theapplication of colour is often used to provide additional structure to allowmore rapid access to such displays. Consequently, the criteria optimise:

a) The unambiguous perception of colour information.

b) The legibility of text. (Effectively ease of READING)

6.4.3.3 It is argued that other factors play a critical part in the controller’s use of theRPVD, particularly those relating to VISUAL SEARCH, and that an adequatedesign solution requires consideration of a number of elements. The solutioneventually proposed for PD1 and the REFGHMI takes account of other factors(§6.4.3.4) and offsets some loss in legibility during search activity againstimprovements in other areas, especially the control processes of the visualsearch behaviour itself. After the search activity has located a candidatetarget, the legibility advantages are regained for confirmation and subsequentinformation extraction.

6.4.3.4 The following two factors suggest the importance of other considerations incontrolling search activity.

a) Although the PVD contains text, it is a heterogeneous mixtureof both graphical information and text. Further, it isconstantly changing, but in comparatively systematic ways,e.g. aircraft do not make large jumps to different locations onthe display.

b) The controller interacts with the display over an extendedperiod of time. There is knowledge of the structure, and thehistory of development, which can play an important part inthe user’s navigation within the display.

6.4.3.5 It is this area of navigation within the display and the initial LOCATION ofrelevant targets that is better supported by the ODID mechanisms. There isevidence from the literature on eye movement control during reading8, frompsychophysics and from letter recognition literature, to suggest that outlineshape information can be used to direct search behaviour. Consequently theODID solution allows size, shape and colour to assist in the search process.Because of the minimum information principle, it is probable that the shape of



an ODID label provides the controller with information that a particularaircraft requires more or less control action even before the identity of theaircraft can be extracted. This shape information is lost by the homogeneousrectangular contour of the infilled label.

6.4.3.6 Another consideration is the visual masking effect that will be produced by theedge contours of the infilled label, and is likely to impair recognition of thecharacters within the label. This effect will be stronger if the edges of thelabel are closer to the text and if the contour is stronger (i.e. if the plaques areedged with black). Further, the existence of all the infilled radar labelsintroduces a lot of vertical and horizontal contour information (the edges ofthe labels). This is an artefact of the mechanism employed to produceimproved label contrast. It seems probable that this contour informationserves no useful purpose during visual search and scanning processes and, onthe contrary, will act as noise impairing the processes.

6.4.3.7 Finally, there is the problem of the greater effect of label overlap produced bythe infilled label. It is true that infilling makes the top label much easier toread, but it impairs the ability to identify the lower label as well as to extractits more detailed contents. What is more important, is that any inputmechanism so far suggested to flip the labels, requires that the mouse cursorbe moved to the area of overlap, even if it does not require an additionalbutton press. Not only does this create an additional, and comparatively task-irrelevant, activity for the user, but it implies that the attention of the user musthave already focused on the screen location. However, as it has already beenargued in §6.4.3.6 that location of the correct aircraft becomes more difficultwith infilled labels, the cost in impairment of controller efficiency ispotentially high.

6.4.4 Conflict Resolution: Integrating the approaches

6.4.4.1 In summary, four implementation issues were identified in integrating the twosystems to avoid the identified weaknesses and take advantage of the strongpoints of the approaches.

a) It was not clear that current hardware could readily support thedirect hardware implementation of the layering structure of theNATS Interim Standard

b) The NATS palette structure [20] was likely to require a small,but significant, amount of extension in order to deal with theadditional requirements generated by:

i) The general infrastructure of the windowingenvironment.

ii) The provision of visual texture and highlightingrequired to support a Motif-type look.9

c) There was a potential conflict between the mechanismsemployed by ODID to communicate clearance status of anaircraft (by general label profile and size) and task status (bythe colour of text of the label), and the mechanism of fixedsized infilled labels employed in the NATS Interim Standard.This uses infilled labels to provide both task status and astable contrast level for the black text, label informationagainst the changing colours of the map background.



d) The infilled label causes an novel form of label overlapproblem which requires additional input mechanisms10 anduser focus, in order to be able to read overlaid labelinformation.

6.4.4.2 In order to achieve a practical reconciliation of these few differences thefollowing approach was recommended for both PD1 and the currentREFGHMI.

6.4.4.3 The palette sets recommended in [20] should be adopted irrespective of theability of the PD1 hardware to implement the full, layering philosophy.

6.4.4.4 The palette sets should be extended in a minimal and systematic way toprovide support for the textural characteristics of the window systeminfrastructure.

6.4.4.5 The principal (non-textural) colour elements of the windowing infrastructurewould be drawn, where possible, from the existing palettes, especially fromthe background layer palettes. Should this fail, minimal extension of thepalettes would be undertaken by the design team.

6.4.4.6 The ODID solution of coloured text and unbounded labels should beemployed to retain the label profile information presently in ODID. The logicof the text colouring would follow the state distinctions employed in ODID forEnroute Sectors. The actual colours employed for the text should (as far aspossible)11 be drawn from the existing NATS palette set.

6.4.4.7 However, when the controller locates the cursor within an aircraft label, thatlabel will be highlighted by converting into the appropriate form derived fromthe Interim NATS Standard [20]. This would avoid the requirement foradditional input mechanisms to avoid the compounded label overlap problemassociated with infilled labels.

6.4.4.8 The resulting palettes are illustrated in Appendix 3.

6.5 A Simple Model of Action at the Interface

6.5.1 Controller Activity as Multi-Threaded Tasking

6.5.1.1 Previous discussion by the PHARE Role of Man Group [29], has alreadyidentified that the Norman Seven Stage Model of User Activities 9[31], Ch3 &5) was a useful framework to employ when thinking about the controllerperforming a task at the interface. Space limitations prevent a detaileddescription of this model here. The reader is referred to the original referencesand the brief summary in the PHARE document.

6.5.1.2 However, certain characteristics of the typical controller activity suggested thatsome elaboration of this type of framework was necessary in order tocharacterise the pattern of activity as opposed to the performance of individualtasks. While it is not inherent in the Norman Model, the psychologicalliterature has a tendency to discuss human task performance in terms ofsequence of activity in single psychological tasks in comparative isolation.Firstly, in Air Traffic Control any single task occurs in the context of manyothers, before after and concurrently. There is surely facilitation, competitiondependencies and other complex interactions between psychological tasks.Secondly, it is difficult to characterise the controller’s activity in terms of



single goals except in the highest and most general of terms, e.g. ‘controllingair traffic’. In reality at any one time the controller is trying to satisfy a largenumber of goals simultaneously. Indeed very often, a single piece of controlactivity may be directed at multiple objectives. Alternatively, an action mayalso be directed at general situation maintenance objectives rather thanspecific ATC objectives, e.g. simplify the general situation.

GOAL SET e.g. Task Goals,

Task Management Goals

Supervisory Intention

Supervisory Evaluation

Supervisory Interpretation

Specific Intention

Evaluation

Action Specification Interpretation

Execution Perception

PHYSICAL ACTIVITY

PHYSICAL ACTIVITY

TASK LOOP

Action Specification (info gathering)

Execution (Monitoring) Perception

Figure 6.2: The Norman Model extended to include the Supervisory Loop

6.5.1.3 Finally, a very important part of all controller roles is using the informationavailable to prioritise and react to the many ATC tasks in an appropriate andtimely manner. We have tried to specifically support this element of controlleractivity in the interface described here and this is linked very firmly to many ofthe tactics and strategies described in §6.2 and §6.3. In doing so we haveimagined a simplistic extension to the Normal Model which involves theoverlay of ‘cyclic’ requirements scanning pattern. This is illustrated in Figure6.2 and described in the following section.

6.5.2 Supervisory Scanning and Task Management

6.5.2.1 One of the findings of the ODID IV simulation [2, Annex VII] was that boththe Planning and Tactical Controllers had a basic pattern of activity which



consisted of a general background scanning pattern around certain criticalelements of the control position. This scanning pattern would be interruptedto perform a sequence of actions relating to a single or several aircraft afterwhich the controller would return to the background activity. Theinterruptions could be of an information gathering nature, of an executivenature or one followed by the other. This general pattern of behaviour coulddiffer in detail for individuals but was followed in outline by all controllers.We would argue that this general pattern of activity is probably typical of mostcontinuous complex human task performance.

6.5.2.2 The extension to the Norman model involves the addition of this general background supervisory scanning activity that provides the binding between themore classical elements of the existing model. (The hierarchical nesting of theNorman Model can be considered as describing the present representation butwe feel that making this particular level explicit makes visualisation of thecontroller activity much easier.) The other slight modification is recognitionthat a large number of goals may be prevail at any one time.

6.5.2.3 The function of the supervisory loop is management of the continuous taskactivity. It is here that intentions are generated to perform task related actions.(Please note that action may be no more than gathering additional information,by directing perceptual resources or, at more cost by making inputs whichmake more information accessible.) The general idea is that the controlleroperates at the supervisory level until:

a) conditions arise which allow action to achieve existing goals

b) some event arises , and is recognised as requiring action, e.g.new aircraft enters system, conflict is detected

c) criteria values are reached which require action, i.e. aircraftdeviates, a coordination is not completed, in the expectedtime.

When an intention is generated the controller embarks on an ATC activity.

6.5.2.4 We make a number of psychological assumptions about the nature of thisscanning loop.

a) Performing this activity should require as little resource aspossible. Ideally it should also be very highly practised andskilled, employing low cost human resources. The suggestionis also that it should operate as an AUTOMATIC PROCESSin the sense employed by Shiffrin and Schneider [34].

b) It does not necessarily cease to operate when the controller isperforming a more specific task although it may operate at

i) lower efficiency

ii) with higher thresholds or more likely slowerinformation accumulation to reach threshold forimportant events.

The purpose of this assumption is to explain interruption oftasks to react to special conditions and alarms.

c) There is a tendency to always return to the loop after othertasks are performed.

6.5.2.5 Similarly, there are a number of assumptions related to the task performance.



a) Seeing a task through to completion is ‘psychologicallysatisfying’. We call this the principal of PsychologicalClosure (a term that has been used elsewhere with a similarmeaning).

b) The performance of tasks may take place as either AutomaticProcessing, Controlled Processing [34] or a combination ofthe two.

c) When in Automatic Mode, it is only practicable to interrupt atask at the end of one of the automatic ‘chunks’. This isanalogous to the limitation on the ability to generate verbalreports at similar stages of activity described by Ericsson andSimon [35].

d) In Controlled Processing mode, there will be points in thecompletion of a task where interruption will be less costly andfrustrating. Effectively this will correspond to the completionof ‘subtasks’ where some measure if psychological closure isprovided.

e) At such break points the controller will be more susceptible todetection of warnings and other changes in the priorities ofinformation on the interface.

f) An important aspect of the scanning is that there is anincidental learning effect as additional information isabsorbed. This information may accumulate over time.

6.5.2.6 This final assumption is potentially of considerable importance. Theinformation gathered in this way plays an important role in helping the user tonavigate in the display. It MAY also be an important contributor tomaintaining the controllers situational awareness (or picture). A corollary ofthis, which may be testable, is that an interface which directs the user’sattention in too focussed and systematic a way will restrict or prevent thegrowth of situation awareness.

6.5.3 How the Model is Reflected in the REFGHMI.

6.5.3.1 Explicit Design to Support Monitoring

6.5.3.1.1 The REFGHMI builds on the observations of ODID IV already describedand tries to enhance and facilitate the observed patterns of use. Supportfor the supervisory loop is identified as an interface function explicitly, aswell as the need for direct ATC task performance. Individual elements ofthe interface are seen as supporting one or both of the roles ofsupervision or task performance to a greater or lesser extent.

6.5.3.1.2 The supervisory role is seen as requiring the summary information,presented in a manner which requires very low shallow processing by theuser. Significant change should be shown by a physical change ratherthan (or as well as) a change in content. The change should draw theattention to a location and that location should provide access, eitherthrough further perceptual processing, or through physical input, to theadditional information or functionality necessary to fulfil the ATC task



requirement. It should act as the gateway to action. This is most readilyillustrated by the example of a warning state such as the STCA or themanually input warning of the interconsole marker. Both of theseinvolve a physical change of colour that stands out, either during physicalscanning or a change which occurs towards the periphery of the user’sattention. This draws the eye to the location on the RPVD where thecontroller can either evaluate the situation and act or require moreinformation. The elastic vector and aircraft label provide the means, atthe location to immediately input the modification of the aircraftclearance. The cursor entering the highlighted aircraft label also providesadditional information fields as well as highlighting that aircraft on anyother display. The controller is effectively given the choice of being‘drawn in’ to the interaction.

6.5.3.1.3 As a more general example the role of the PC can be considered. In theREFGHMI the Supervisory element of the PC’s task is providedprimarily by the RPVD, the SILs, the MESSAGE WINDOWS and theCRD. The task or executive element is supported primarily by theRPVD and the MESSAGE Windows and the VAW. The CRD is usedalmost exclusively for Supervision, task scheduling and prioritisation.The VAW almost exclusively for completing task activities identifiedelsewhere. The RPVD in particular can serve both functions because ofthe highly layered way in which information is structured both forpresentation and access. It is possible for the controller to both scansummary information and interact more deeply as a function of the focusof attention at the point of interaction.

6.5.3.2 Designing for Interruptability

6.5.3.2.1 One of the most important aspects of multi-threaded activity is theoperator has to readily switch from one task to another as the prioritieschange moment to moment. This implies that not only should thechanging priorities be clearly discernible, the objective of the previoussection, but that the cost of switching should be minimised. An interfacecan address this in a number of ways. The principal means employed forthe REFGHMI is by attempting to make sure that:

a) action sequences remain as short as possible.

b) interrupted action sequences can be resumed, recovering asmuch as possible of previous activity.

c) the system did not change organisation and layout unpromptedand any automatic updating was highly predictable.

6.5.3.3 Status and Value of the Model

6.5.3.3.1 In summary, this model is intended to help the designer think about howcomplex, continuous, multi-threaded task activity can be conducted andmanaged. Firstly, it helps to understand and explain why certain aspectsof the design work better than others and as far as the REFGHMI isconcerned, that is its primary function. It serves to explain the observedpattern of activity in ODID and the anticipated pattern for the REFGHMI.It has also helped provide criteria for design decisions.

6.5.3.3.2 In the longer term it may help to identify, where and how additionalfunctionality should be realised in the interface. It certainly played animportant role in the conception of the Advanced HMI for PD1 [1],



leading to the identification of the Planning Communications Manager asa Tool at the Supervisory Level for the PC for the management of thedelays inherent in the used of datalink for advanced planning. However,it should be emphasised that the model is only a means for integrating anumber of human factors/psychological principles and observations intoa framework for thinking about controller task activity. It has nor beenvalidated in detail. Its value, as we indicated at the beginning of thischapter, will be shown only if it helps to produce more usable interfacesfor ATC.

6.6 ... and a ‘Last Word’ about what has been leftout

6.6.1 What has been left out

6.6.1 There are a number of ideas and influences which have been left out of thischapter, principally because they are not yet well enough formulated to beclearly presented. The most important of these relate to the supremeimportance of trying to understand the functionality required of a human-machine system and express it in a form that is independent of theimplementation concept. The idea is that this then allows a clearer perspectiveon how the implementation is realised, not only through software and interfacedesign, but also through decisions about the organisational structuring ofteams (with both human and computational elements) and the media chosen torealise the functionality. These things are becoming increasingly important aswe try to design for the role of the human in a complex work situation and tryto move beyond cliches about ‘automation’ and ‘man in the loop’.

6.6.2 For the moment, all we can offer in this context is some ‘good advice’, andfollowing in Erzberger’s tradition [36], offer this short list of DOs andDON’Ts.

DO really ‘think’ about system functionality.

DO consider human intentions (starting with why anyonewould ever WANT to use this clever function you haveinvented?).

DO try to put yourself in the place of the people using thesystem as opposed to expecting them to step into yourshoes.

DO try to separate the core functionality of the system fromartefacts in the way in which it is currently implemented.

DON’T spend too long trying to find a fix for a mechanism at anyparticular level of functionality. The need is often anindication of a problem at a higher level. If a mechanismis inconsistent or presenting a problem, go back up tohigher levels of the functional analysis where a differentdecision can often design out the problem.



Notes on Section 6

1 Attributed to Bill Buxton during an Open Floor debate at the Conference of theBritish Computer Society Human Computer Interaction Specialist Group, Universityof York, 23-26 September 1986.

2 It can readily be argued that this is a highly undesirable feature in most cases anyway.The ‘nagging’ interface can be a source of considerable irritation and frustration.

3 Remember that this is an interface for development and testing. Other rules mayhave to apply, perhaps even for legal reasons, in an operational setting.

4 It has always been an objective of REFGHMI and PD1 that the user should bethinking always at the operational level and that the input level should be automatic.

5 It was originally intended that these layers should be reflected in system hardware.This difficult requirement s not demanded by PD1 or the present REFGHMI.

6 The controllers who participated in ODID IV were unanimous in their approval in theway in which colour was employed. Only two points of dissatisfaction were noted.Firstly, the use of the STCA Red colour on the callsign of aircraft in conflict was notliked. Secondly, the Grey employed for aircraft that had been handed over sufferedfrom a reduction in legibility, as well as the reduction in saliency, which wasintended.

7 For those more familiar with the literature on visual perception, it is recognised bythe authors that this distinction between visual search and reading represents asimplification. As we will see in §6.5, there is a notion of overall SCANNING orMONITORING activity which involves more than just the RPVD and precedes theidentification of a particular target. At the other end the READING processes mayalso include an element of template matching as well as the fuller reading processes.

8 Unfortunately, the references are not immediately to hand. I recollect an article inCognitive Psychology before 1981, (perhaps by Just and Carpenter) whichdemonstrated that while individual alphanumeric characters can be identified onlywithin a small region close to the centre of the visual field of a fixation (3-4characters) coarser, lower spatial frequency information could be processed out to 9or 10 characters. It was postulated that this allowed sufficient information to beextracted to identify small prepositions and endings like ‘ing’ in order to permit moreefficient placement of the next fixation during reading.

Similarly, there is work by David Navon (circa 1977) which shows that in letterrecognition, lower spatial frequencies are processed before higher ones and work onthe psychophysics of vision which again suggests the prior processing of low spatialfrequencies.

These lines of work converge to suggest that outline shape information could beemployed to guide search behaviour.

9 This look is not merely decorative. The textural quality of the environment providesmechanisms to indicate the status of radio buttons, the icon/buttons of the toolbox,etc.

10 A totally opaque label is much more effective in obscuring the information of anoverlapped label. Currently, all the mechanisms suggested to deal with this problem,require movement of the mouse pointer to the location of the overlap.

11 It is anticipated that this should be entirely possible. It is understood that the SwissAdministration has already enjoyed some success with a similar strategy


ReferencesVersion: 1.0 i

References1. PHARE Document PD1 Facility Specification. R.M. Gingell, B. Bradford and

S.A. Fox. November 1993.

2. ODID IV Simulation Report. EEC Note 269/94. June 1994.

3. The ODID III Real-Time Simulation, EEC Report No. 242, September 1991.

4. EATCHIP: ODID Report and Guidelines. EUROCONTROL, ExternalRelations Section, May 1993.

5. OSF/Motif Style Guide, Release 1.1, Open Software Foundation, Prentice-Hall, 1991.

6. Apple Style Guide

7. Hollan, Hutchinson and Norman, D.A. (1986). "Direct Manipulation" inNorman, D.A., and Draper, S. (eds.), "User Centered System Design",Lawrence Erlbaum.

8. Tognazzini, B. (1992) “Tog on Interface”, Addison-Wesley PublishingCompany, Reading, Mass.

9. Common Operational Performance Specifications (COPS) for the ControllerWorking Position, Version 6-91/1, EUROCONTROL.

10. Specification for the Third ODID Real-Time Simulation, CEE WorkingDocument, Ref: OPS/330/56/3, July 1989.

11. ODID IV Simulation Description, EEC Note No. 15/93, September 1993.

12. Boff, K.R. & Lincoln, J.E. (1988). Engineering Data Compendium. HumanEngineering Division, Harry G. Armstrong Aerospace Medical ResearchLaboratory, Wright-Paterson Air Force Base, OH 45433.

13. Snyder, H.L., (1988). ‘ Image Quality’ in Helander, M. (ed). Handbook ofHuman Computer Interaction, North Holland. 1988.

14. Snyder, H.L., and Maddox, M.E. (1978). Information transfer from computer-generated, dot matrix displays. Virginia Polytechnic and State UniversityTechnical Report HFL-78-3.

15. Welford, A.T., (1968). Fundamentals of Skill, London: Methuen.

16. Card, S.K., Moran, T.P., Newell, A. (1983). The Psychology of Human-Computer Interaction. Lawrence Erlbaum Associates.

17. ODID IV Facility Specification, Version A (Technical), Amended September21

18. Verplank, W., (1987) The Design of Graphical User Interfaces. Tutorialpresented at theThird Conference of the British Computer Society Human-Computer Interaction Specialist Group, University of Exeter, England. 7-11September 1987.

19. ODID IV Controller’s Booklet. EUROCONTROL Experimental Centre, July1993.

20. Reynolds, L., and Metcalfe, C. (1992). The Interim NATS Standard for theUse of Colour on Air Traffic Control Displays. CS Report 9213. Issue 1.2.


ReferencesVersion: 1.0 ii

21. Rapid Prototyping of ‘Multi-Sector Planning’ HMI. EEC Note No. 17/93,October 1993.

22. Whitfield. D., Ball, R.G., and Ord, G. (1980). Some human factors aspects ofcomputer-aiding concepts for air traffic controllers. Human Factors 1980.

23. Whitfield, D., and Jackson, A. (1982).The Air Traffic Controller's 'Picture' asan Example of a Mental Model. in Proc of the IFAC/IFIP/IFORS/IEA Conf.on 'Analysis, Design, and Evaluation of Man-Machine Systems,' Baden-Baden, September 1982.

24. Jackson, A., (1988). Keeping the Controller in the Loop: The ATCO’s Rolein Future Systems DRA (M) ATC Systems Research Division Review toCAA, 1988.

25. Connolly, D.W., Spanier, G. and Champion F. (1975) Color DisplayEvaluation for Air Traffic Control FAA Report No. FAA-RD-75-39.

26. Narborough-Hall, C.S. (1985) Recommendations for applying colour codingto air traffic control displays. Displays, 131-137, 1985.

27. David, H. and Roelofsen, J., (1986) Use of Colour in Electronic DataDisplays (Second Study). Task AT02a, WPDG 2/86/OS, Report Number 199,EUROCONTROL Experimental Centre.

28. Reynolds , L. (1995). How to Use Colour on ATC Radar Displays.

29. Role of Man Within PHARE, PHARE Document 93-70-35, Prepared by thePHARE Working Group “Role of Man’, EUROCONTROL, June 1993.

30. Air Traffic System-Supported Coordination (SYSCO): Concept andFunctional Description, Version 1 - December 1992, EUROCONTROLBrussels, 1992.

31. Norman, D.A., and Draper, S.W., (1986). User Centered System Design.Lawrence Erlbaum Associates, Hillsdale N.J.

32. Prototype HMI for the AS09 Study, EUROCONTROL Experimental Centre1995.

33. Norman, D.A., (1981). Categorization of Action Slips. PsychologicalReview, 88, 1-15.

34. Shiffrin, R.M., and Schneider, W., (1977). Controlled and automatic humaninformation processing: II Perceptual Learning, automatic attending, and ageneral theory. Psychological Review 84, 127-190.

35. Ericsson K.A. & Simon, H.A. (1984). Protocol Analysis: Verbal Reports asData, MIT Press, Cambridge, Mass.

36. Erzberger, H. (1988). Automation Tools for Air Traffic Control. ATC-2000Seminar, EUROCONTROL 25 Anniversary, Luxembourg 1988.


Translation of SummaryVersion: 1.0 Traduction - 1

Traduction en français del’ Introduction et de l’ “ExecutiveSummary” (Chapitre 1)

1 Objectif1.1 Ce rapport fournit une description de l'état de l'art’ des Interfaces

Homme-Machine (IHM) graphiques pour le contrôle de trafic aérien en-route, quand il est réalisé par un Contrôleur Organique (PlanningController (PC) et un Contrôleur Radariste (Tactical Controller (TC)). Ildécrit les fonctionnalités nécessaires à la réalisation des tâches des deuxtypes de contrôleurs PC et TC mais il ne fournit que desrecommandations minimum quant à la nature du matériel (hardware) àemployer pour le poste de travail du contrôleur (Controller WorkingPosition (CWP)). En d'autres termes, on suppose l'utilisation d'écransgraphiques à haute résolution sans spécifier ni la nature des écransphysiques ni les logiciels employés. Toutes fois, cette spécificationconvient à une implémentation X-window, sous UNIX, pour des écranscouleur 2000 x 2000, configuration prise actuellement comme normedans le domaine du développement des Systèmes de Contrôle de TraficAérien. Des mécanismes sont également fournis pour satisfaire les casoù l' interface doit être distribuée sur plus d'un écran d'affichage .

1.2 Cette spécification a été rédigée avec l'intention de fournir une référenceen matière d' IHM au sol (Reference Ground Human Machine Interface(REFGHMI)) (et non pour les IHM embarquées), référence à utiliser nonseulement comme base de mesures mais également comme point dedépart pour le développement d' IHM explorant et exploitant desfonctionnalités plus sophistiquées utilisant les techniques avancées tellesque le datalink air-sol, la prédiction améliorée de trajectoire, laplanification multi-secteurs, etc. Pour cette raison, cette spécification estbasée sur ‘le meilleur système en route qui puisse être implémentéaujourd’hui’. Par conséquent, elle pourrait également être utiliséecomme point de départ pour spécifier l' harmonisation des IHMdéveloppées par les différentes autorités nationales. (Par ailleurs, cedocument, peut être considéré comme une première étape dans larédaction d'un Guide de Style pour les IHM dans le domaine ATC ).

1.3 L'accent a été mis sur la dimension pragmatique. L'objectif est de fournirles materiaux de base (des principes et des mécanismes d'affichage,d'interaction et d'usage de la couleur), qui puissent être étendus et utilisésde façon transparente pour satisfaire les besoins des différents utilisateurspotentiels.

1.4 Cette spécification représente une synthèse ainsi qu'une reprise del'activité de conception qui avait été conduite par les auteurs et beaucoup



d’autres pendant un certain nombre d'années (cf. §2 pour une descriptionplus détaillée des origines de la spécification). Il en résulte que la plupartdes principes, mécanismes et implémentations décrits ont été essayés ettestés au cours d'études et d'évaluations antérieures.

2 Origines de la Spécification actuelle2.1 De nombreux travaux et individus ont contribué à l' évolution de cette

spécification. Le prédécesseur le plus immédiat de L'IHM décrite dans cedocument est l' IHM du Système de Référence pour le premierDemonstrateur PHARE1 (PD1). La spécification de cette IHM a étéproduite par le Centre Expérimental d'EUROCONTROL, pour et sous lecontrôle du groupe PHARE Ground Human Machine Interface (GHMI)2.On notera que le présent document n'est pas la spécification de l'IHM duSystème de Référence de PD1. Il représente plutôt, à la fois unesimplification et une extension de l' IHM implémentée actuellement dansPD1, reprenant la plupart de ses functionalities essentielles, de cescaractéristiques et mécanismes. Les IHM implémentées dans PD1 sontdécrites dans les différents paragraphes de [1].

2.2 L' IHM de Référence pour PD13 est elle-même, directement dérivée desrésultats du Groupe ODID4, et plus particulièrement des simulationsODID III (Organisation 2) et ODID IV dans lesquellesles états deEUROCONTROL et surtout, la France, la Suisse et le Danemark ont étéparticulièrement impliqués [2],[3]. Les fonctionnalités fondamentalestestées aux cours de ces simulations sont reprises dans le REFGHMI.Pendant ODID IVbis, ces mêmes fonctionnalités ont été présentées à untrès grand nombre de contrôleurs. Leurs réactions, ainsi que les résultatsdes simulations, ont servi de guide pour la re-conception de l' IHM avecle souci d'integrer ces concepts opérationnels en une IHM plus cohérenteet plus tolérante aux erreurs. La documentation détaillée et complète d'ODID IV5 a servi de fondation à la spécification de l'IHM de Référencede PD1 ainsi qu'au présent document. Les simulations elles-mêmes ontfourni une des évaluations par ‘prototypage ’les plus approfondies. Deplus, les démonstrations ODID IV bis ont présenté l' IHM à une trèsgrande variété de contrôleurs de différentes administrations nationalespermettant ainsi une re-conception reflètant une plus grande variété decultures ATC que d'ordinaire.

2.3 En termes de principes généraux d'Interaction Homme Machine, lesprincipales sources ont été, en ce qui concerne le domainespécifiquement orienté ATC, le document ‘EATCHIP, ODID : report andguidelines’ [4], qui résume les leçons d' ODID I, II, et III, sinon lesguides de style des environnements graphiques les plus répandues [5],[6]. Enfin, les aides les plus claires et les plus fondamentalesproviennent elles, peut être, du papier de Hollan, Hutchinson et Normansur la manipulation directe [7] et de l'amusant livre plein d'enseignementsde Bruce Tognazzini sur la conception d' IHM [8]. L'expériencepersonnelle de l'un des auteurs sur le prototypage d'un SystèmeElectronique de Strips et d' IHM Graphiques pour des postes de travailexpérimentaux a été également fortement utilisée6. Une revue détailléedes principes et pratiques dans le domaine des Facteurs Humains sur



lesquels reposent le processus de re-conception et la compréhension de laprésente interface est proposée dans le chapitre 6

3 Contenu du Document et Comment le lire.3.1. La spécification de l'IHM est divisée en cinq chapitres principaux

(Chapitres 2-6 ) et divers Appendices Techniques. Les Chapitres sontintitulés comme suit :

Chapitre 2 Evénements et Modèle d'Interaction

Chapitre 3 Caractéristiques Générales d'Affichage et Gestion de Fenêtres

Chapitre 4 Spécification de la Visualisation Radar pour l'IHM du Système de Référence

Chapitre 5 Spécification des Eléments d'Affichage Auxiliaires de l'IHM du Système de Référence

Chapitre 6 Facteurs Humains : Idées Importantes, Principes et Modèles

3.2. Les deux premiers chapitres traitent de la forme de l' IHM, de sonarchitecture et de ses éléments de base qui peuvent être associés de sorteà constituer la fonctionnalité souhaitée. La dÈfinition de cesinformations est un pré-requis pour la spécification de l' IHM duSystème de Référence mais elle est aussi le fondement sur lequel touteextension ou modification de l'interface doit être construite.

3.3. Les Chapitres 4 et 5 fournissent une description détaillée du contenu, dela représentation, des fonctionnalités et des mécanismes d'interaction de l'IHM. L' IHM du Système de Référence contient quatre des cinqprincipaux éléments composant ODID IV. A savoir :

• la fenêtre d'affichage de la Visualisation Radar ou Plan ViewDisplay (PVD)

• la fenêtre d'affichage des conflits ou Conflict Risk Display(CRD)

• la fenêtre d'affichage du profil vertical d'un avion ou VerticalAid Window (VAW)

• la fenêtre d'affichage dans le plan horizontal d'un conflit aumoment de la séparation minimum entre les deux avions ouConflict Zoom Window (CZW).

3.4 Un élément n’a pas été répris ici. La fenêtre d'affichage dans le planhorizontal de la route d'un avion ou Horizontal Aid Window (HAW) quifut peu utilisée dans le contexte d' ODID IV. Le Chapitre 4 traite de laVisualisation Radar (PVD) et ses éléments fondamentaux. Le Chapitre 5décrit les autres éléments affichés.

3.5 Le Chapitre 6 traite des Facteurs Humains à savoir les principes etpratiques qui ont guidé à la fois le processus de re-conception réalisé àpartir d' ODID ainsi que les tentatives suivantes pour créer unearchitecture d' interface adaptée à la tâche actuelle et à l' extension futurede l' interface.



3.6 Les notes de bas de page et les Appendices Techniques sont à utiliser encomplément. Diverses notes, à la fin de chaque Chapitre, fournissent debrèves explications et/ou extensions. Les Appendices Techniquescontiennent des explications détaillées sur des sujets particuliers, desexemples, ainsi que des données et des tableaux qui ne pouvaient êtreconvenablement insérés dans le texte.

Les Appendices Techniques sont les suivants :

Appendice 1: Classification des Couches d'affichage de l' Interface

Appendice 2: Représentation Graphique de la Structure des fenêtres

Appendice 3: Palettes des couleurs proposées

Appendice 4: Tableau des couleurs de référence

4 Comment lire ce document4.1 Ce document peut être utilisé de diverses façons. Pour ceux qui

s'intéressent à la spécification de l'IHM en tant que telle ( sesfonctionnalités opérationnelles ou une possible implémentation ) le textepeut être suivi normalement en faisant référence aux Notes etAppendices.

4.2 Pour ceux qui s'intéressent à la conception de l'IHM (en opposition a soncontenu ) ou pour ceux qui ont besoin d'ajouter ou de changer unefonctionnalité de l' IHM, le Chapitre 6 devra être lu en premier. Celadevrait fournir un cadre pour la compréhension des choix de conceptionqui ont été réalisés et qui pourraient servir subséquemment en casd'adjonction de fonctions.

4.3 Il est prévu qu'il puisse y avoir des révisions de ce document afin desuivre les évolutions du REFGHMI dans le temps.

Notes sur l’ "Executive Summary"

1 Programme for Harmonisation of Air traffic management Research inEUROCONTROL.

2 Les commentaires, critiques et suggestions du groupe PHARE GHMI ont contribuésconsiderablement à clarifier les idées exprimées dans le présent document.

3 D'autre part, les interfaces des organisations avancées de PHARE PD1, représententune augmentation significative des fonctionnalités d'ODID IV

4 Operational Display and Input Development Group. Une collaboration internationaleentre responsables des autoritÈs opÈrationelles pour la conduite des quatreprincipales simulations (ODID I to IV) entre 1986 et 1993. Le premier auteurtravailla pour le Groupe ODID de 1989 à1993 et le second auteur fut responsable desmesures relatives aux facteurs humains pour ODID IV.

5 Les auteurs aimeraient exprimer leur sincere remerciements au Groupe ODID pouravoir mis à disposition toute leur documentation et plus particulierement auxmembres suivants de l'équipe ODID IV : à Brétigny, Bob Graham, Dave Young,



Chris Brain et à Bruxelles, Vic Day, Poul Jørgensen et Geoff Gasté pour nous avoirdonné tant d'accès au systeme et pour avoir répondu à nos innombrables questions.Leur patience, quand ils ont regardé nos modifications, ont été hautementrecommendables.

6 Avec Messieurs Ball et Dean entre 1988 et 1990 à DRA(M) sous le sponsoring de laCAA.


Appendix 1Version: 1.0 1

Appendix 1

Prioritisation of Display Layers

Parent Window 2

Parent Window n

Worktop

Child 2.1

Child 2.n

Display Screen Prioritisation

System Dialogue Boxes

Cursors

General Toolbox (Parent 1)

Priority

CLOCK Window

1. Parent Windows are:The Radar Plan View Display The Message Windows The Conflict Risk Display The Vertical Aid Window The Conflict Zoom Window

2. Within the sub-stack shown as B2, a CLICK of button B2 on a parent or child in a family (e.g. F3) will cause that whole family to move to the top of the B2 sub- stack.

B2Child 3.1Child 3.2

Parent Window 3

F2

F3



Appendix 2

Graphical Appearance of Supportive WindowStructures

A2.1 General Principles

A2.1.1 The Elements making up the frames and mechanisms of the windows(furniture) will be given a slight impression of depth in broadly in keepingwith Motif. This will be achieved by creating an impression of illuminationfrom a source at an infinite distance beyond the top left hand corner of thedisplays. The impression will be produced by giving all rectangular surfaces,which are to be perceived as ‘proud’, a brighter left and top edges and darkerright and bottom edges. Objects which are to be seen as ‘indented’ will beinfilled with more darker with similar chromatic characteristics to the proudlevels and the rules for edges will be reversed, i.e. top and left edges will bedarker and bottom and right will be brighter.

A2.1.2 All elements of the window furniture which must be selected by the mousewill be at least 4mm (13 pixels, but more usefully 14 pixels) across theirshortest dimension.

A2.1.3 The colours employed for the furniture will be based on the RCA Palette forLow Foreground Items L3 [20]. Additional shades may be requires to allowfor the depth impression described in §A2.1.1.

A2.2 Dimensions

A2.2.1 An actual size mock-up for the active area of an Intergraph or Sony displaysuggests that the following approximate sizes are reasonable.

Name bar and slider rack width 8mm or 28 pixels

Highlighting/shading width 1.5mm or 4 or 5 pixels

Window Name Fonts 14 point Sans Serif

A2.3 Specifications of Palette for Window Elements

A2.3.1 The window furniture palettes in the mock-up are based on the RCA LowForeground Palette L3. In total 10 colours are employed within the windowstructures. Appendix 3 illustrates the entire colour palette used for the PD1interface and Appendix 4 contains the Master Colour Table for all objects inthe REFGHMI

A2.3.2 The mock-up has used RCA Low Foreground Blue (RGB% 44,55,66 termedWindow Blue, or WBlue) as the main infill for window furniture. To allow forlighting effects, two variant colours have been added to this palette.

WBlue Highlight RGB% 64,75,86 used for highlit edges

WBlue DepressedRGB% 24,35,54 used for ‘depressed’ WBlue objects



A2.3.3 Similary, sliders and radio buttons use RCA Low Foreground Palette L3(RGB% 68,57,41) termed Window Fawn. (WFawn) Once again, two variants:

WFawn HighlightRGB% 88,77,61 and

WFawn Depressed RGB% 48,37,21 were generated.

A2.3.4 The existing Grey Lines colour (RGB% 20,20,20) is used for all shaded edgesand for providing structure where required.

A2.3.5 Black (RGB% 0,0,0) and White (RGB% 100,100,100) are used for text onbuttons, icons and name/handles.

A2.3.6 WFawn Restriction (RGB% 65,21,20) is used to indicate the inability to closethe Radar Window completely from the General Toolbox.

A2.3.7 Advanced Ground (RGB% 70,50,50) and Advanced Pink Text (RGB%92,68,68) are used to provide structure to window re-sizing handles.



Appendix 3

Suggested Color Palettes

REFGHMI Master Palette as of 10/4/95

Black

White

ADV Pink Ground

Beacon Text/ Route Lines

ADV Pink Text

Concerned Mustard

Warning Yellow

CRD Background

CRD Frame Highlight

LandMass

COORD Pink Text/Ground

Restricted on Land

Restricted on Sea

Restricted on Sector on Land

Restricted on Sector on Sea

Sea

Sector on Land

Sector on Sea

Window Blue (Frame Body)

WBlue Highlight

Shadow Grey

WBlue Depressed

WFawn Restriction

Conflict Red

Desktop

RGB% 0, 0 ,0

RGB% 100,100,100

RGB% 70, 50, 50

RGB% 92, 68, 68

RGB% 65, 65, 65

RGB% 72, 61, 28

RGB% 100, 10, 10

RGB% 100, 90, 12

RGB% 48, 45, 45

RGB% 75, 75, 75

RGB% 29, 32, 29

RGB% 36, 34, 34

RGB% 100, 41, 60

RGB% 37, 30, 30

RGB% 39, 34, 36

RGB% 38, 33, 33

RGB% 42, 37, 37

RGB% 39, 39, 41

RGB% 39, 37, 37

RGB% 42, 42, 42

RGB%

RGB% 82, 18, 18

RGB% 78, 39, 20

RGB% 63, 58, 27

RGB% 44, 55, 66

RGB% 64, 75, 86

RGB% 20, 20, 20

RGB% 24, 35, 54

WFawn Depressed

RGB% 48, 37, 21

WFawn Highlight

RGB% 88, 77, 61

Window FawnRGB% 68, 57, 41

RGB% 65, 21, 20

Transparent Conflict 60%

Trans Conflict on Conflict

Trans Conflict on Risk

Transparent Risk 60%

63, 26, 26

Green (COORD) RGB% 46,88,31



Appendix 4

Master Colour Table for REFGHMI



REVISED MASTER COLOUR TABLE (Changes in Italics) Revision v0.3, 23/5/95 (AJ)

For Sony Trinitron, on Mac Quadra 700 MacDraw Pro with Supervideo 256 col graphics adaptor SuperMac Platinum Monitor

Function Description Name Red Green Blue Red Green Blue0-255 0-255 0-255

Worktop General Background Worktop 29 32 29 74 82 740 0 0

Universal Other or Transferred Beacon Grey 65 65 65 166 166 166(Task States) Advanced Information ADVANCED Pink 92 68 68 235 173 173

Assumed WHITE 100 100 100 255 255 255Concerned CONCERNED Mustard 72 61 28 184 156 71Co-ordination Colour COORD Pink 100 41 60 255 105 153Alert Warning Yellow 100 90 12 255 230 31Manual Warning Colour Warning Yellow 100 90 12 255 230 31Conflict Colour/STCA RED 100 10 10 255 26 26

Window Move Handle WBlue 44 55 66 112 140 168Frame WBlue 44 55 66 112 140 168Sliders WFawn 68 57 41 173 145 105Highlight edges (Frames) Window Highlight 64 75 86 163 191 219Highlight edges (Sliders) Slider Highlight 88 77 61 224 196 156Shaded edges (all) Shadow Grey 20 20 20 51 51 51Resizing Handle(Move Button Optional)

General Move Handle WBlue 44 55 66 112 140 168Toolbox Window Button /Icon - Normal WFawn 68 57 41 173 145 105

Window Button/Icon - DepressedWFawn/Dep 48 37 21 122 94 54Menu Button/Icon - Normal WBlue 44 55 66 112 140 168Menu Button/Icon - Depressed WBlue/Dep 24 35 54 61 89 138Button Restriction Window Restriction 65 21 20 166 54 51



Function Description Name Red Green Blue Red Green BlueRADAR General Window as above WBlue, etc

Range Markers (bottom and left) WBlue 36 34 34 92 87 87

Land Mass R/Grey 35 LAND 36 34 34 92 87 87

Water Mass B/Grey 40 SEA 39 39 41 99 99 105

Sector on Land Sector on Land 39 37 37 99 94 94

Sector on Water Sector on Water 42 42 42 107 107 107

Sector Edge Enhance (option) 0 0 0

Minor Route (thin line) Grey 65 65 65 65 166 166 166

Major Route (thickened line) 44 46 48 112 117 122

Beacon Grey 65 65 65 65 166 166 166

Beacon Text Grey 65 65 65 65 166 166 166

Beacon Highlight Grey 65 65 65 65 166 166 166

Restricted on Land Restricted on Land 37 30 30 94 77 77

Restricted on Sea Restricted on Sea 39 34 36 99 87 92

Restricted on Sector on Land Res + Sect+ Land 38 33 33 97 84 84

Restricted on Sector on Sea Res + Sect + Sea 42 37 37 107 94 94

Airways

TMA NOT DEFINED

Aircraft Symbol Black 0 0 0 0 0 0

Heading Vector Black 0 0 0 0 0 0

Leader Line to label White 100 100 100 255 255 255

RADAR Labels Other or Transferred (TEXT) Beacon Grey 65 65 65 166 166 166

(unselected) Advanced Information (TEXT) ADVANCED Pink 92 68 68 235 173 173

Assumed (TEXT) White 100 100 100 255 255 255

Concerned (TEXT) CONCERNED Mustard 72 61 28 184 156 71

Co-ordination Colour (TEXT) COORD Pink 100 41 60 255 105 153

0 0 0

RADAR Labels Other or Transferred Beacon Grey 48 45 45 122 115 115

(selected) Advanced Information ADVANCED Pink 92 68 68 235 173 173

BACKGROUNDS Assumed White 100 100 100 255 255 255

Concerned CONCERNED Mustard 72 61 28 184 156 71

Co-ordination Colour COORD Pink 100 41 60 255 105 153



Function Description Name Red Green Blue Red Green BlueRADAR Switch Box Fill (active/on) WBlue/Dep 24 35 54 61 89 138

Toolbox Switch Box Fill (inactive/off) Window Highlight 64 75 86 163 191 219

Radio Button Fill (selected) WFawn/Dep 48 37 21 122 94 54

Radio Button Fill (unselected) WFawn 68 57 41 173 145 105

Modal Cursors, elastic vectors & text) Warning Yellow 100 90 12 255 230 31

CRD General Window as above WBlue, etc

CRD Background CRD Background Grey 48 45 45 122 115 115

CRD partition Highlight CRD Highlight Grey 75 75 75 75 191 191 191

CRD Partition Shadow Shadow Grey 20 20 20 51 51 51

Others as radar colours

VAW General Window as above WBlue, etc

VAW Background CRD Background Grey 48 45 45 122 115 115

Sector Background Sector on Land 39 37 37 99 94 94

Conflict Fill (in Sector) Trans Conflict 60% 63 26 26 161 66 66

Risk Fill Trans Risk 60% 63 58 27 161 148 69

Conflict Risk Overlap TranspConlict on Risk 78 39 20 199 99 51

Conflict/Conflict overlap Transp Con on Con 82 18 18 209 46 46

Axes and text Black 0 0 0 0 0 0

Flight Level lines Shadow Grey 20 20 20 51 51 51

Traject of ACFT Green 46 88 31 117 224 79

Traject in Conflict Conflict Red 100 10 10 255 26 26

Traject at Risk Warning Yellow 100 90 12 255 230 31

XFL and PEL Headers White 100 100 100 255 255 255

CZW as radar colours

european organisation for the safety of air - free home page

Documents