Interactions:

Advanced controller displays, an ATM essential

E. KesselerNLR, Amsterdam

e-mail: kesseler@nlr.nl

E. G. KnapenNLR, Amsterdam

e-mail: knapen@nlr.nl

3rd USA/Europe Air Traffic Management R&D Seminar Napoli,13-16 June 2000

Abstract

Saturation of the Air Traffic Management (ATM)system, combined with limited opportunities to in-crease the capacity based on current practice, pro-vide the economic incentive to improve ATM.

Over the years, ATM has evolved into a set of finelytuned interactions between air traffic controllers,procedures and ATM systems. The resulting con-troller display is defined based on extensive experi-ence displaying a relatively limited set of radar andflightplan information.

Concurrent research at various European establish-ments has provided several stand-alone ATM tools,based on human-centered ATM concepts, which aimto provide the required capacity increase while main-taining or increasing current safety levels. To avoidincreasing controller workload and/or error rates, at-tention needs to be paid to the interaction betweenthe controller, these ATM tools and existing ATMsystems.

This paper describes a large scale multi-nationalexercise in which several different ATM tools fromvarious European organizations were integrated intoa tool-cluster on a real-time simulation platform. Adedicated, integrated Human Machine Interface wasdesigned and implemented.

The expense and time consumption of such exer-cises demands a “first-time-right” approach. Themajor lesson learned from the interactions betweenadvanced ATM tools and the controllers is thata “human-centered” approach (i.e. providing sys-tem functionalities based on the needs of the con-troller and the task requirements) is essential. Thishuman-centered approach contrasts with the tra-ditional “technology-centered” approach which ismainly driven by the capabilities of the technologyemployed. The implications for ATM system devel-opment, like a shift from the waterfall model to aspiral development model, are addressed.

1 Introduction

In a “human-centered” Air Traffic Management(ATM) paradigm, the displays which convey the traf-fic information to the Air Traffic Controller (ATCo)form an essential component of the total system.With the advent of various new advanced ATMtools, the ATCo can be provided with a lot of newand potentially useful information. Every developerof advanced ATM tools is acutely aware of the factthat a tool’s success critically depends on its inter-action with the controller and its integration withthe ATM concept. As in any safety conscious indus-try, there is a tendency to rely on proven technologyabove promising, but unproven, new concepts andsolutions.

Tool developers traditionally do not base their Hu-man Machine Interface (HMI) on an underlying the-ory for the total task of the ATCo. Instead, HMIdesigns tend to be based on what can be done prac-tically and efficiently, using the HMI of the existingtarget ATM system as a constraint. This approachis known as the “technology-push” or “technology-centered” approach.

The alternative to the technology-centered approachis the human-centered approach to ATM systemdesign. The human-centered approach starts bydefining the characteristics of the underlying ATMconcept. Based on this, an integrated view of thetask of the ATCo is developed, including his inter-actions with the supporting ATM tools.

The current state-of-the-art does not allow full vali-dation of new ATM concepts without real-time simu-lations. These simulations involve real ATCo’s usingthe tools in a representative environment under arealistic workload.

The innovation presented in this paper was to startwith a coherent ATM concept. Subsequently a set ofnovel ATM tools, each of which had earned its mer-its in stand-alone experiments, was combined into a

- 1 -

new integrated ATM environment. The results wereevaluated using a variegated group of ATCo’s, withmany years of experience each, from various Euro-pean countries. The evaluation used simulated hightraffic density scenarios.

Section 2 contains a cursory overview of the oper-ational ATM concept. This concept has been de-veloped using a human-centered approach, whiletaking into account the capabilities of the avail-able advanced ATM tools and capabilities to shareinformation with the pilot using the AeronauticalTelecommunication Network (ATN).

Section 3 provides a short description of the exper-iment, including an excerpt of the operational eval-uation of the experiment indicating its success. Sec-tions two and three provide the information neededto fully appreciate the description of the problem en-countered in the en-route case, contained in section4. Subsequently, section 5 provides the analysis froma technical perspective, while section 6 summarisesthe findings in the conclusions. Details of the ATCoHMI are presented in Appendix A.

2 Operational ATM concept

The Programme for Harmonised Air Traffic Manage-ment Research in EUROCONTROL (PHARE), setup in 1989 and completed at the end of 1998, wasconducted by the ATM research centers of the UK,France, Germany and the Netherlands, plus EURO-CONTROL Experimental Centre (EEC). It aimedto ”organise, coordinate and conduct studies and ex-periments aimed at investigating the feasibility andmerits of a future air-ground integrated air trafficmanagement system in all phases of flight” [12].

PHARE’s main concept enhancements relevant tothis paper were:

• integration of the air and ground systems;

• support of the pilot and the ATCo with auto-mated tools while retaining the human-in-the-loop paradigm for both the aircraft and theground side;

• introduction of 4D-trajectory negotiation and4D-planning in a multi-sector environment.

Implementation of these enhancements had to leadto a prototype of an ATM environment up to the taskof dealing with predicted 2005-2015 traffic levels [10].This represents a 150% increase over 1995 levels [13].

Use of 4D-planning in space and time requires moreaccurate navigational performance on the side of theaircraft. To share this information with the ground

system, a digital communication channel (data link)has to be present. With the same high quality in-formation becoming available to both the pilot andthe ATCo, automated tools can be utilised to reduceworkload and enhance situational awareness. Ex-amples are a flight path monitor, long term conflictdetection and resolution tools and arrival/departureschedulers. Although the PHARE concept allowsfor user preferred trajectories from Standard Instru-ment Departure (SID) to Standard Arrival Route(STAR), the example discussed relates only to theen-route phase. However a similar problem has beenencountered in the approach phase, which furthersupports the conclusions.

To ensure that all these elements that gather, com-municate and process information work togetherand can be visualised to the pilot and the ATCo ina consistent and intuitive way, a coherent, human-centered ATM concept had to be established. ForPHARE, this concept was built around the use of4D-trajectories.

Tools provide the pilot and the ATCo with a visu-alisation of an aircraft’s trajectory and allow theseusers to obtain more information of and make mod-ifications to the 4D-trajectory. Using the datalink,trajectories are automatically communicated andnegotiated between the ground systems and the air-craft. All advanced tools work on the basis of trajec-tories (e.g. the flight path monitor verifies whetheractual position updates from the surveillance toolconform with the agreed 4D-trajectory).

The same integrated, human-centered approach isalso used for the design of the ATCo HMI. As aresult, information is combined and shown as muchas possible in the familiar radar display. When in-formation is shown in more than one window, this isdone in a consistent way and selecting one instanceof the representation will also highlight all other in-stances [5].

As a result, the ATCo HMI becomes more intuitivewhich reduces the learning time. Inconsistencies be-tween different representations of the same informa-tion are avoided. More information on the PHAREoperational concepts can be obtained from [10], [11],[12] and [14].

3 Experiment description

Due to the inherent complexity of ATM systems,data need to be collected and analysed to verify newATM concepts. The amount of detail needed fora realistic assessment requires large real-time sim-ulations to arrive at a judgment on the proposedconcepts [8]. [13] even states that a full understand-

- 2 -

ing of the operational concept only comes when areal-time simulation is available. This paper de-scribes the PHARE Demonstrator 3 (PD/3) and itsextension the PD/3 Continuation Trial (PD/3 CT).The findings discussed would not have been obtainedin a less realistic environment, confirming the needfor such costly exercises.

From an operational perspective en-route air trafficcontrol in PD/3 required the integration of the fol-lowing tools:

• trajectory predictor (TP)

• negotiation manager (NM)

• conflict probe (CP)

• problem solver (PS)

• flight path monitor (FPM)

• ground human machine interface (GHMI).

Most of these tools, with the exception of theGHMI, were developed in different locations usingthe technology-centered approach. The resultingtools had been integrated into the various ATMsystems in local use. These ATM tools were sub-sequently to be integrated into a tool-federation,or “tool-cluster” in project parlance, on NLR’sAir traffic control Research Simulator (NARSIM).NARSIM’s client/server based architecture (calledGEAR), is designed to facilitate the integration ofvarious components, even when supplied by differentorganisations. Figure 1 depicts the architecture ofthe resulting PD/3 simulator as used in the PD/3CT.

Live Aircraft

STCA

PATN

SPL

Radar/Track

NM

A/C Perf(Bada)

Airspace IFPMeteo

Executive Supervisor

DL

PATs FPM PATs AM

PR GroundServer

TN GroundServer

ISA Server

GHMI(s)15

PATs TP(s)7

Air TP (s)3

ATSPD3

BlipIO(s)24

ATCoDis(s)3

TID(s)15

R/T ClientMain R/TProgram

AlternativeCP (s) 4

Main PATs CP

VVD(s)3

PD/3 server

communication between servers

actual airborne part of PD/3

TN = Trajectory NegotiationTID = Touch Input DisplayTP = Trajectory PredictorVVD = Vertical View Display

A/C Perf = Aircraft PerformanceAM = Arrival ManagerATCoDIS = ATCo DisplayATSPD3 = PD/3 Air Traffic ServerBLIP IO = Pseudopilot positionCP = Conflict Probe

DL = Data LinkFPM = Flight Path MonitorGHMI = Ground HMIIFP = Initial FlighPlan ISA = Instantaneous Self AssessmentNM = Negotiation Manager

PATN = PHARE ATNPAT = PHARE Advanced ToolPR = Position ReportingR/T = Radio/TelephonySPL = System FlightPlanSTCA = Short Term Conflict Alert

Figure 1: PD/3 system architecture

- 3 -

As can be seen in figure 1, the GHMI serves as theintegration of all ATM system communication withthe ATCo, that is, for the user it is the glue of theATM system. Consequently any inconsistency in theunderlying ATM tools will be detected as a problemin the GHMI module. Unexpected behaviour of thesystem as discussed in this paper, led to the need forthe PD3/CT project.

To give an indication of the effort of executing a ma-jor real-time simulation, 25 ATCo’s from 8 countriesevaluated the PD/3 tool-cluster at NLR during thePD/3 CT trials. The exercise consisted of 3 mea-sured sectors complemented by 5 feeder sectors and3 holding areas. The simulated traffic was generatedby 15 pseudo pilots ‘flying’ up to 300 simulated air-craft complemented by real pilots flying a researchaircraft. Various exercises used traffic up to twicethe traffic of the busiest day of 1996.

The considerable costs as well as the deployment ofscarce human resources like ATCo’s required thatthe experiment be “first-time-right”. The mere ex-istence of the PD/3 CT implies that in this case asecond try was required. The need for this secondexperiment was partly caused by problems that be-came visible during the tool integration, an exampleof which is described in section four and analysed insection 5.

From an operational point of view the PD/3 CTexperiment was successful. During the evaluations,ATCo’s mentioned feeling confident about handlingthe expected air traffic volumes for the period 2005-2015. More information about the results of thePD/3 CT can be obtained in [13].

4 En-route case

Based on the PHARE ATM concept described insection two, an integrated HMI has been designed.From an ATCo’s point of view, this HMI integratesthe Highly Interactive Problem Solver (HIPS) toolwith the trajectory prediction tool. The HIPS isa stand-alone tool developed using the technology-centered approach. A dedicated HMI has been im-plemented and the tool has earned its merits instand-alone simulations, that is simulations in whichthe HIPS is integrated into an environment akin tocurrent ATC systems.

Similarly, the TP tool was based on an Experimen-

tal Flight Management System, which has proven itsworth in many simulations. This TP was build usingthe technology-centered approach and integrated inNARSIM, the simulation platform used. This re-useof proven tools for combined experiments forms thecore of the PHARE way of working. Its success hasbeen documented in [4].

The ATM concept requires a tool which allows theATCo to intuitively modify a 4D-trajectory andobtain real-time response to the proposed modifi-cations. The HIPS is designed to provide this. Inorder to obtain the real-time response (and due toits development as a separate tool), however, theHIPS uses its own computationally efficient trajec-tory prediction. In the integration platform, a fullaccuracy trajectory prediction tool is required. Thistool is needed by subsequent modules (e.g. a conflictdetection tool) which require the TP’s full precision.Consequently neither tool can be omitted.

To follow the human-centered design approach, theATCo needs a consistent presentation. The designchoice was to construct an HMI which shields thedifferences between these two autonomous tools fromthe ATCo. Figure 2 provides a screen of the resultingHMI. It shows that the conflict probe has detected apotential conflict, based on information from the fullaccuracy trajectory predictor. For a larger imageand a full description of all relevant features of thisHMI please refer to appendix A.

The ATCo investigates a solution to this conflict us-ing the intuitive interface of the HIPS to “pick” thetrajectory and “drag” it outside infringement area.The real-time response of the HIPS is an essentialfeature for this problem solving activity. Figure 3shows the resulting trajectory. In order to minimisedisturbance of the aircraft’s preferred trajectory, thesolution only just avoids the warning area of theinfringing second aircraft. To inform the ATCo, thered areas on the Plan View Display (PVD) and thevertical view display have disappeared, however theconflict remains in the “conflict and risk display” asat this moment the modified trajectory has not yetbeen accepted.

After the ATCo is satisfied with a solution, it needsto be validated using the full accuracy trajectory pre-dictor. This is accomplished by clicking on the val-idate button of the “trajectory support tool” sub-window.

- 4 -

Figure 2: Interactive ATM tool detects possible conflict

Figure 3: Controller solves conflict with interactive tool, minimizing trajectory interference

- 5 -

Figure 4: Slower, full accuracy tool discards solution

Figure 5: Controller solves conflict again with interactive tool

- 6 -

Figure 6: Second solution confirmed by full accuracy tool

As shown in figure 4, the result of the trajectorypredictor’s more accurate modeling of the aircraft’sturn behaviour is that the conflict re-occurs. Al-though the resulting vertical separation infringementis significantly reduced, the solution is of course un-acceptable.

Consequently the ATCo has to pay attention to thisconflict again, by proposing a second solution (seefigure 5). Due to the time delay involved this sec-ond problem solving action disturbs the schedulingof mental tasks by the ATCo. As such this is nota minor technical inconvenience, but a major in-terference with the ATCo’s routine distribution ofeffort over his normal tasks of monitoring, control-ling, checking, diagnosing and problem solving [8].Of the HMI design guidelines of [6] (see section A.1)the “be consistent” and “minimise the use of modes”has been violated.

To conclude the example, figure 6 shows that the sec-ond solution is validated by the full accuracy trajec-tory prediction tool. Subsequently this solution hasbeen sent to the pilot and acknowledged. The con-flict disappears from the “conflict and risk display”.As these solutions rely on intermediate points whichcan not be known in advance, the human-centeredapproach requires the use of a digital data link to

provide this information to the pilot.

5 Case analysis

5.1 Human-centered approach

In the example provided, effort has been made to im-plement a human-centered solution. Both the ATMconcept and the GHMI design complied with thisapproach and were appreciated by the ATCo’s. Theresulting intermittent failure of the implementationwas caused by two tools. These independently de-veloped tools were not integrated but merely har-monised. Consequently in special circumstances theybehaved inconsistently. This kind of problem can besolved by extending the human-centered approach tothe integration of separate tools into tool-clusters ortool-federations. Such integration comprises:

• using consistent input data. Partly, this can beaccomplished by splitting a tool into separatemodules and using Application ProgrammingInterfaces (APIs) to unambiguously define theinterfaces. The input processing should thenbe a separate module apart from the actual al-gorithm. A similar argument holds for splittingoutput processing in separate modules;

• analysing the sensitivity of the integrated tool-

- 7 -

cluster for inaccuracies in the input data pro-vided;

• redesigning the computationally efficient tra-jectory prediction tool based on a conservativeapproximation of the results of the full accu-racy trajectory prediction tool.

In the operational evaluation the ATCo’s agreedthat the inconsistencies between the HIPS and theTP tool caused confusion [13]. This confirms thatsuch issues should be dealt with prior to embarkingon costly full-scale experiments.

5.2 HMI

To avoid inconsistencies in the ATCo HMI, the APIsof all components should be agreed upon as early aspossible. These APIs can be used to test interactionsbetween tools for inconsistencies and deadlocks. Thisapproach can be extended to assess the response timeof tool-clusters. Using appropriate methods, this canbe done before the tools themselves are implemented.These checks reduce the number of defects that showup later in the development process, at which timeresolving them is more expensive [1].

The conflict and risk display received mixed reviews,indicating that more work needs to be done on thisdisplay. Possibly this is the result of this displaybeing technology-centered (it was easy to provide)instead of human-centered (based on what the ATConeeds to know for his task). This conclusion is sup-ported by the development of the Activity PredictorDisplay within PHARE [5] as a replacement of theconflict and risk display.

The message in/out displays were not deemed rel-evant by the ATCo’s. This illustrates Karat’s [6]guideline that the HMI has to be consistent which inthis case means providing information in the ATCo’spreferred graphical format instead of the tabular for-mat used.

The Sector Inbound Lists were not used frequently,again due to the presentation in a tabular format.This is especially significant as even during periodsof high workload more frequent use of these lists didnot occur.

5.3 System development

The previous three cases support another importantfinding: this experiment confirms that a waterfallbased system development approach (like [3]), al-though convenient for system developers, is not al-ways appropriate, because:

• some system characteristics can only be judgedwhen a prototype is made available to theusers. The waterfall model does not permitthis early in the development process;

• during the system realisation phase the opera-tional concept will mature resulting in evolvingsystem requirements. The waterfall model as-sumes frozen requirements.

Consequently a spiral development model [2] is moreappropriate to arrive at the final system to be usedin the resource expensive real-time simulation. Forother application areas the same conclusion has beenreached [7].

5.4 Software metrics

To put the size of the GHMI module into perspec-tive, information is provided in table 1 about theimplementation size of various parts of the PD/3simulation platform. All module sizes are expressedin units of thousand lines of code (KLOC) includingcomments. Programming languages used to imple-ment the modules are Ada, C++ and C.

The figures in table 1 support the conclusion that theATCo HMI is an essential module in any real-timeATC simulation. Remember also that tool inconsis-tencies as seen from the users’ perspective may onlyshow up in the HMI. Therefore appropriate atten-tion needs to be paid to this module during systemdevelopment.

Module Description KLOCGHMI PD/3 Ground HMI 221FPM PD/3 Flightpath Monitor 35AM PD/3 Arrival Manager 20NM PD/3 Negotiation Manager 20ATS Air Traffic Server 20CP PD/3 Conflict Probe 16SPL System Flightplan Server 8

Table 1: Relative component size

The figures also show that implementing an algo-rithm is only a minor part of the total process fromalgorithm to useful prototype.

The relative size of the GHMI module with respectto the ATCo tools and even the entire simulationplatform, implies that a design based on generic dis-play software (resulting in a smaller product specificdescription) can lead to a large reduction in real-isation time and costs. The resulting early proto-types comply with the spiral development model. AtNLR, wARP is a project aimed at implementing suchgeneric display software [9].

- 8 -

6 Conclusions

To accommodate ever increasing air traffic in ahuman-in-the-loop ATM system, capacity needs tobe extended by increasing the productivity of theATCo’s. This can be accomplished by providingthem with advanced tools which enhance their effi-ciency.

Advanced ATM tools are usually conceived, devel-oped and evaluated independently, including a ded-icated locally optimized HMI. The most promisingtools are subsequently integrated into existing ATMenvironments. During this process the tool’s HMIis integrated with the existing ATM system. Thistraditional technology-centered approach can yieldunexpected inconsistencies, which may reduce anypotential capacity gains. It may even lead to unjus-tified repudiation of the tools being evaluated.

Based on the experience described, a better way toproceed is the human-centered approach. Startingfrom a clear ATM concept to guide the design de-cisions to be made, human factors considerationsshould be taken into account from the start of thedevelopment process. Items to take into account dur-ing this human-centered system development processare:

• treat the ATCo HMI as an essential part of anysimulation development project;

• design an HMI based on the ATCo’s infor-mation needs instead of what is available andcheck the ATCo’s reaction during actual usage;

• take HMI guidelines seriously, especially withrespect to consistency and intuitive use;

• use generic modules and tools to constructcomplex ATCo and pilot HMIs;

• use APIs early in the system development pro-cess to check consistency and timing require-ments within tool-clusters;

• use a spiral software development model in-stead of a waterfall model;

• use consistent or harmonised algorithms (i.e.fast response type algorithms that produceconservative estimates of the results of the full-precision tools within the same tool-cluster);

• analyse data accuracy required by various toolswithin the tool-cluster;

• use consistent data sets between tools.

Integration tests of tool-clusters are a necessary stepbetween research and an industrial product. Thesetests are expensive and time consuming. What

appear to be minor inconveniences from a tech-nical point of view can even invalidate an entireexercise. This implies the need for a “first-time-right” approach. Unlike the traditional technology-centered approach, a human-centered approach com-bined with a spiral development process is essentialto obtain this “first-time-right” objective.

Acronyms

4D defining points in space and timeAPI Application Programming InterfaceATCo Air Traffic ControllerATM Air Traffic ManagementATN Aeronautical Telecommunication

NetworkCP Conflict ProbeEEC EUROCONTROL Experimental CentreFPM Flight Path MonitorGHMI Ground Human Machine InterfaceHIPS Highly Interactive Problem SolverHMI Human Machine InterfaceNARSIM NLR’s Air traffic control Research

SimulatorNLR National Aerospace LaboratoryNM Negotiation ManagerKLOC one thousand Lines Of CodePHARE Programme for Harmonised ATM

Research in EUROCONTROLPD/3 PHARE Demonstrator 3PD/3 CT PD/3 Continuation TrialPS Problem SolverPVD Plan View DisplaySID Standard Instrument DepartureSTAR Standard Arrival RouteTMA Terminal Movement AreaTP Trajectory PredictorTST Trajectory Support ToolwARP ATCoDis Redesign Project

References[1] B. Boehm, Software Engineering Economics,p.40, Prentice-Hall, Englewood Cliffs, 1981.

[2] B. Boehm, “A spiral model for software develop-ment and enhancement”, in Computer, volume 21,number 5, pp. 61-72, IEEE, 1988.

[3] ESA Software Engineering Standards, ESA PSS-05-0, issue 2, ESA, February 1991.

[4] M. van Gool, PHARE final report, Doc 99-70-09,EUROCONTROL, Brussels, 1999.

[5] Jackson, A., Pichancourt, I., et al., PD/3 GroundHuman Machine Interface Specification, version 2.1,EUROCONTROL, Brussels, August 1997.

- 9 -

[6] C.M. Karat, R. Campbell, T. Fiegel, “Compar-ison of empirical testing and walkthrough methodsin user interface evaluation”, CHI92 Conference pro-ceedings, pp. 397-404, Association for ComputingMachinery (ACM), New York, 1992.

[7] E. Kesseler, “Quality first, measuring a safety-critical embedded software development process”, In-ternational Conference on Product Focused SoftwareProcess Improvement Profes’99, VTT, Finland, ISBN951-38-5271-7 or NLR-TP-99272, 1999.

[8] J. Kjaer-Hansen, Human factors in the develop-ment of air traffic management systems, HUM.ET1,ST13.4000-REP-01, EATCHIP, EUROCONTROL,Brussels, 1998.

[9] E.G. Knapen, ATCoDis Redesign Project, Userand Software Requirements document, NLR-TR-99417(private publication), NLR, October 1999.

[10] NLR/EEC/CENA, PD/3 Operational ScenariosDocument Volume 1, DOC97-70-04, January 1997.

[11] NLR/EEC/CENA, PD/3 Operational ScenariosDocument Volume 2, DOC97-70-08, March 1997.

[12] http://www.eurocontrol.be/projects/ eatmp/phare

[13] W. Post, NLR PHARE demonstration 3 FinalReport, DOC 99-70-01, EUROCONTROL, Brussels,2000.

[14] I.A.B. Wilson, Trajectory Negotiation in a Multi-sector Environment, DOC 97-70-14, June 1998.

- 10 -

A Detailed description of the Ground HMI

Fig

ure

7:O

verv

iew

pict

ure

ofth

eP

HA

RE

AT

Co

HM

I

- 11 -

A.1 Design guidelines

In order to appreciate the functions and complex-ity of the Human Machine Interface (HMI), the HMIwill be described in detail. For some features thedesign rationale will be provided. [6] developed thefollowing design guidelines to ensure the usability ofHMI’s:

• use a simple and natural dialogue

• provide an intuitive visual layout

• speak the user’s language

• be consistent

• provide feedback

• provide clearly marked exits

• provide shortcuts

• provide assistance. (This requirement is notapplicable as the HMI is used by highly skilledusers which have been specially trained on,amongst others, the HMI)

• allow user customisation

• minimise mode effects

• support input device continuity.

Where relevant these guidelines will be referred to inthe following detailed HMI description.

A.2 General features

In figure 7 four main windows are visible. The gen-eral features applicable for each window are:

• the basic design principle is, that for charac-teristics which are not ATC-specific, the be-haviour should be similar to PC-based windowssystems. In cases where this would result in adeviation from existing ATC systems, compat-ibility with existing ATC systems prevailed. Inthis way the ATCo’s expectations can be metand the learning effort reduced in accordancewith the first three design guidelines.

This choice is fine for an experiment. In an op-erational system the conversion training mightbe less of a problem, however the fast evolutionof commercial window systems might result ina need to regularly update the available HMIto the new features of commercial windows sys-tems;

• a standard use of the window decorations:

– each window is labeled with an identifica-tion inside the upper window border;

– each window can be re-sized using the fa-miliar dragging of the border. In regularwindows applications changing the win-dow size sometimes results in a differentscale and sometimes does not. To avoidsuch inconsistencies, the actual radar dis-play has two extra controls, which allowwindow resizing with constant scale andconstant area respectively.

• for those windows which display an area(“PLAN VIEW DISPLAY” and “PROFILEDISPLAY BMA714”), the slide bars can beused to select the display area. The size ofthe slide bar indicates the relative size of thedisplayed area with respect to the total areaavailable;

• the colours, font size, and default availabil-ity, size and position of each window can besaved. Up to ten preferred configurations canbe stored in accordance with the customisationguideline;

• a window may contain sub-windows. The sub-windows can be positioned inside or outside thecorresponding window.

A.3 Plan View Display

The major window is labelled ”PLAN VIEW DIS-PLAY”. This window provides all information whichis currently available in traditional ATC systems.The major features are:

• the active sector (Belgium Upper Airspace) isdepicted in a lighter shade of the backgroundcolour;

• in order to be intuitive, the window mimics aconventional radar display for the standard fea-tures;

• only flights which satisfy the filtering rules aredisplayed. Note that these rules are contextspecific; when a trajectory is edited using theHIPS (Highly Interactive Problem Solver), allflights not involved with this trajectory are au-tomatically made invisible;

• minimum label information is provided. On re-quest extended labels can be provided. Labelcolours are used consistently to provide statusinformation on the flight. Labels of aircraft inneed of an ATCo action are boxed;

• the selected trajectory is shown in green. Onlythis trajectory can be modified by the ATCo.The label will be be highlighted and expandedinto a full label;

- 12 -

• a yellow area depicts a warning (another air-craft is close but will not infringe the separa-tion criteria);

• a red area depicts a conflict (another aircraft ispredicted to infringe the separation criteria);

• the “ACC-3” and “BR AC” sub-windows listall aircraft which will enter the active sectorfrom the ACC-3 or BR AC sector respectively.The “DEFAULT” sub-window collects all re-maining aircraft. The border above these sub-windows provides the radio frequency of thecorresponding sector.

• the “Message IN” sub-window lists the sta-tus of the incoming messages for the ATCo.For consistency one area is used for systemmessages, messages from adjacent centers anddownlink messages from the aircraft;

• the “Message OUT” sub-window lists the sta-tus of all outgoing messages from the ATCo.This list is empty in figure 7;

• the selected trajectory can be modified inter-actively by picking any point on the trajectoryand dragging it to the desired position. In or-der to provide an intuitive interface, the trajec-tory and the displayed conflicts and warningswill change immediately. This requirement im-poses real-time requirements on the underlyingtrajectory prediction and conflict detection al-gorithms.

A.4 Profile Display

The “PROFILE DISPLAY - BMA714” provides avertical view of the selected flight. The major fea-tures are:

• the vertical scale with flight level information;

• the horizontal scale with distance informationin nautical miles;

• for consistency the selected trajectory is shownin the same colour as on the Plan View Display;

• different display filtering rules apply for thezones in the horizontal and vertical views;

• the full label of the selected aircraft is high-lighted and displayed on top of the display;

• a yellow area indicates a vertical warning. Notethat these yellow areas relate to other flightsthan the yellow areas in the PVD;

• a red area indicates a conflict. Note that thisconflict is the same as the one shown in thePVD. A conflict only exists when both the hor-izontal and vertical separation criteria are pre-dicted to be infringed;

• the selected trajectory can be modified inter-actively by picking any point on the trajectoryand dragging it to the desired position. Thesame real-time algorithms are used as in thePVD.

A.5 Conflict and Risk Display

The “Conflict and Risk Display” provides a severityindication for all conflicts. The vertical axis providesthe “separation at point of closest approach” in nau-tical miles, the horizontal axis provides the “time toloss of separation” in minutes. The black boxes areused to scale each axis. On the left the callsigns ofeach conflicting aircraft pair are provided.

- 13 -

Note that for an operational display the annotationat the axis would be omitted to improve picture clar-ity.

A.6 General Toolbox

The last window, labelled “General Tool Box: Sec-tor MSAW Tactical” provides information on the se-lected display configuration. The buttons are:

• “CRD” for the “Conflict and Risk Display”,which is selected in this example;

• “HIPS” for the HIPS display, which is selected;

• “ELW” for Extended Label Window, which isnot selected;

• “PREF” to store or retrieve the preferences forup to ten display configuration settings;

• “FLEX” for flexibility. This button is intendedfor developers only. It allows changes to evenmore characteristics of the display, like the fontsused;

• the time of the simulation in the familiarhours:minutes:seconds format.

A.7 TST sub-window

In case the selected tra-jectory is modified theHIPS tool will providefeedback in real-time. Thespecial TST (TrajectorySupport Tool) sub-windowappears automatically toprovide the necessary feed-back. It is labeledwith the flight’s call-sign (“BMA714”, in fig-ure 7). For consistencyadjacent sectors and air-craft are treated in thesame way.

The function of the but-tons is (describing thebuttons from the topdownwards):

• “cancel” will remove any modification;

• the three buttons labelled with a left, upwardand right pointing arrow are used to start thetrajectory negotiation with the upstream sec-tor, aircraft and downstream sector respectively.The button labelled FC is used to deliver a For-malised Clearance to the aircraft;

• “register” will set the modified and validatedtrajectory to the active trajectory;

• “accept” will accept a proposal from either anadjacent center or an aircraft. Note that a pro-posed trajectory can only be rejected by sub-mitting a counter proposal;

• “validate” will validate the trajectory by us-ing the full precision trajectory prediction tool.Due to its higher accuracy the trajectory pre-dictor can not calculate trajectories fast enoughfor interactive use;

• the top row of the six colour buttons displaysthe status of an incoming trajectory from theadjacent sectors, an incoming trajectory from apilot and an outgoing trajectory to an adjacentsector respectively;

• the bottom three colour buttons are used torecall the current, the original and the work-ing trajectory. To ensure consistency the samecolour coding is used as for the trajectory onthe PVD and the profile display;

• the “history” section shows the last few otherflights of which the trajectories were modified.

- 14 -

Biographical information

NameErnst Kesseler

Present positionHead Embedded Systems DepartmentInformation and CommunicationTechnology Division

Brief introduction

• graduated from the University of Amsterdam(Dutch Drs degree)

• at the Dutch National Aerospace Laboratory(NLR) Amsterdam since 1980

• completed projects include

– flight simulation systems

– wind tunnel systems

– mission critical satellite software

– safety critical avionics software

– quality assurance

– Air Traffic Management systems (includ-ing CNS/ATM system analysis and de-sign, real-time simulation, conflict probes,short term conflict alert)

– Aeronautical Telecommunication Net-work systems

• previous activities

– system analysis

– software design

– implementation

– quality assurance

– project management

– consultancy

– trainer

NameEd Knapen

Present positionSoftware EngineerEmbedded Systems DepartmentICT Division

Brief introduction• graduated from the Eindhoven University of

Technology (Dutch Ir. degree)

• graduated from the post-masters SoftwareTechnology program at the Stan Ackermans In-stitute, Centre for Technological Design (MTDdegree)

• at the Dutch National Aerospace Laboratory(NLR) since 1996

• completed projects include

– design and implementation of cockpit dis-plays

– studies for Human Machine Interface userrequirements

– European distributed ATM simulationprograms

– HMI development for AeronauticalTelecommunication Network systems

– Air Traffic Controller Display design

• previous activities

– system analysis

– software design

– implementation

– project management

– consultancy

- 15 -