EUROCONTROL · EUROCONTROL EXPERIMENTAL CENTRE IRELAND 2000 REAL-TIME SIMULATION EEC Report No. 366...

EUROPEAN ORGANISATIONFOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL EXPERIMENTAL CENTRE

IRELAND 2000REAL-TIME SIMULATION

EEC Report No. 366

Project SIM-S-E1_IRL

Issued: September 2001

The information contained in this document is the property of the EUROCONTROL Agency and no part should be reproduced in anyform without the Agency’s permission.

The views expressed herein do not necessarily reflect the official views or policy of the Agency.

EUROCONTROL

REPORT DOCUMENTATION PAGE

Reference:EEC Report No.366

Security Classification:Unclassified

Originator:EEC – OPS(Operational Services)

Originator (Corporate Author) Name/Location:EUROCONTROL Experimental CentreCentre de Bois des BordesB.P.15F – 91222 Brétigny-sur-Orge CEDEXFRANCETelephone : +33 (0)1 69 88 75 00

Sponsor:Irish Aviation Authority (IAA)

Sponsor (Contract Authority) Name/Location:Irish Aviation AuthorityAviation HouseHawkins StreetDublin 2IrelandTelephone: + 353 1 6031100 / 6718655

TITLE:IRELAND 2000 (IRL2000) REAL-TIME SIMULATION

AuthorD. HOULIHAN

Date09/01

Pagesxii + 126

Figures21

Tables4

Appendix2

References8

EATMP TaskSpecification

-

ProjectSIM-S-E1_IRL-

IRL2000

Task No. Sponsor

-

Period1999 - 2000

Distribution Statement:(a) Controlled by: Manager - Simulation Programme(b) Special Limitations: None(c) Copy to NTIS: YES / NODescriptors (keywords):

Ireland - Real-Time Simulation – IRL2000 - ATC Tasks - FIR/UIR - EATCHIP - Electronic Co-ordination -MTCD - OLDI - SYSCO - Safety Nets - Colour Displays - Interactive Radar Labels - Touch Input Device -Mouse - Sectorisation - - TMA - Human Machine Interface (HMI) – CAIRDE 2000 – MAESTRO.

Abstract:This report describes a EUROCONTROL real-time simulation study conducted on behalf of the Irish AviationAuthority. The study aimed to assist the IAA in preparing for the commissioning of their new Civil AviationIntegrated Radar Display Equipment (CAIRDE 2000), using an advanced ATM system. The study evaluatedthe operational impact of the HMI (Human Machine Interface) and assessed the potential roles ofExecutive and Planning controllers in the new system. Secondary objectives focused on sectorisationconfigurations and operating procedures specific to the Shannon and Dublin air traffic control centres.Phase I of the study assessed a flight progress strip environment with co-ordination by telephone. PhaseII assessed a more automated system without flight progress strips while introducing System SupportedCo-ordination (SYSCO) and Medium Term Conflict Detection (MTCD). The airspace tested includedEnroute, TMA, Approach and Departure sectors as well as the Oceanic interface with the ShanwickOceanic Control Area (OCA). Traffic samples representing forecast levels up to 2007 were simulated.

Ireland 2000 Real-Time Simulation

EEC Report No. 366 v

EUROCONTROL

SUMMARY

The IRL2000 real-time simulation took place at the EUROCONTROL Experimental Centrebetween March 6th and March 31st 2000. The Irish Aviation Authority (IAA) plans to implement anew ATM System – CAIRDE 2000 [Civil Aviation Integrated Radar Display Equipment]. Thissystem will enable the Authority to provide safe and cost effective services to its customers in thefirst decade of the new millennium, in line with the forecast growth in air traffic.

The CAIRDE 2000 system design will incorporate the latest technology available, offeringoptimised system support for the controller (in terms of safety, reliability and flexibility), whileendeavouring to maximise efficiency and reduce human error at the system interface.

A total of twenty-four air traffic controllers (13 from Shannon, 9 from Dublin and 2 from the IAATraining Centre) participated in the IRL2000 simulation. The controllers gained hands-onexperience of the proposed CAIRDE 2000 system during a total of 98 hours of simulation timeprovided during the acceptance, training and measured exercise evaluation periods. The highdegree of Operational Controller input to (and their improved knowledge of) the new systemfunctionality will prove extremely beneficial to the IAA before system implementation.

Five simulated organisations evaluated the operational impact of the HMI (Human MachineInterface) and assessed the potential roles of Executive and Planning controllers in the newsystem. Simulation design complemented the previous fast-time simulation of Irish Airspace (EECTask No. F01/EEC Note No. 20/97) with secondary objectives focusing on sectorisationconfigurations and operating procedures specific to Shannon and Dublin air traffic control centres.

Apart from the introduction of a windows-style radar display supported by inputs via a three-buttonmouse, the main features of the controller interface were the inclusion of electronic SystemSupported Co-ordination (SYSCO), Medium Term Conflict Detection and Safety Nets such asShort Term Conflict Alert and Area Proximity Warning. Valuable data on the effective use of listinformation, track label interaction and the use of colour in an automated system (with and withoutflight progress strips) was obtained which will assist the IAA in specifying the new features andfunctionality of the CAIRDE 2000 system.

The simulation of various airspace and sectorisation configurations also provided worthwhileassistance towards resolving problems that will exist with vertical sectorisation plans and labelstate functionality as designed and defined by the manufacturer.

To conclude, the simulation was extremely important to Ireland. As the IAA looks to the installationof a new ATC system in the next few years, the active involvement of the controllers in the designand evaluation of the system and airspace proposals was of enormous value for the long-termsuccess of the CAIRDE 2000 project. The simulation output will be a significant contribution to thenew system specification.


vi EEC Report No. 366

EUROCONTROL

ACKNOWLEDGEMENTS

The members of the EUROCONTROL project team wish to express their appreciation for the assistanceafforded them by the Irish Aviation Authority (IAA) during the preparation and testing phases of the IRELAND2000 real-time simulation. A special thanks to Messrs. Paul Conroy, Niall McGrath, Pat McCarthy and WillieFuller for their expertise, assistance, co-operation and hard work. The excellent input provided by Messrs.Pat Ryan, George Ormsby, Mick Thompson, John Casey, and Terry Deegan during the project was also verymuch appreciated, as was the valuable advice, support and liaison tendered by Messrs. Mick Weldon and J.McGrath and by Jean-Louis Garcia from the Service Technique de la Navigation Aerienne (STNA).

The author would also like to thank all the EUROCONTROL staff who worked with him on theIRL2000 project. In particular Jean-Philippe Rafidison the Simulation Technical Co-ordinator whoefficiently configured and managed a very complex simulation facility and also Rod McGregor(Deputy Project Manager IRL2000) whose HMI expertise was invaluable.

Thanks must also go Yvette Fauchot, Veronique Begault, Josee Bralet and Peter Slingerland fortheir excellent work throughout the simulation.

Finally, thanks to the Irish controllers from Dublin and Shannon who participated in the simulation.They all displayed a high level of professionalism and enthusiasm and it is their input that providedthe results to be found in this report.

Photo 1: Ireland 2000 Real-time Simulation – EEC, Brétigny: 6th to 31st March 2000


EEC Report No. 366 vii

EUROCONTROL

TABLE OF CONTENTS

LIST OF FIGURES......................................................................................................................................... VIIILIST OF TABLES .......................................................................................................................................... VIIIANNEX I - MAPS ........................................................................................................................................... VIIIANNEX II - OPERATIONS ROOM FLOORPLANS....................................................................................... VIIILIST OF GRAPHS ........................................................................................................................................... IXLIST OF PHOTOS............................................................................................................................................ IXACRONYMS AND ABBREVIATIONS.............................................................................................................. XREFERENCES................................................................................................................................................ XII1. INTRODUCTION.........................................................................................................................................12. IRELAND 2000 - SIMULATION OBJECTIVES..........................................................................................23. IRELAND 2000 - SIMULATION CONDUCT ..............................................................................................3

3.1. AIRSPACE...........................................................................................................................................33.2. TEMPORARY SEGREGATED AREAS...............................................................................................33.3. TRAFFIC SAMPLES............................................................................................................................43.4. TRAFFIC SAMPLE ANALYSIS............................................................................................................43.5. ORGANISATIONS ...............................................................................................................................53.6. EXERCISE PROGRAMME..................................................................................................................73.7. SIMULATED ATC SYSTEM ................................................................................................................83.8. CONTROLLER WORKING POSITION ...............................................................................................93.9. ATC PROCEDURES AND CONTROLLER TASKS ..........................................................................11

4. RESULTS - OBJECTIVE 1.......................................................................................................................144.1. INTRODUCTION ...............................................................................................................................144.2. GENERAL HMI RESULTS.................................................................................................................154.3. DATA INPUT AND WINDOWS MANAGEMENT RESULTS .............................................................184.4. LABEL AND TRACK RESULTS ........................................................................................................194.5. FLIGHT PROGRESS STRIPS...........................................................................................................254.6. DATA LIST WINDOWS......................................................................................................................26

5. RESULTS - OBJECTIVE 2.......................................................................................................................355.1. INTRODUCTION ...............................................................................................................................355.2. AREA PROXIMITY WARNING (APW) ..............................................................................................355.3. SHORT TERM CONFLICT ALERT (STCA) ......................................................................................355.4. DYNAMIC FLIGHT LEG (DFL) ..........................................................................................................365.5. CONFLICT AND RISK DISPLAY (CRD) ...........................................................................................37

6. RESULTS - OBJECTIVE 3.......................................................................................................................436.1. INTRODUCTION ...............................................................................................................................436.2. CONTROLLER ROLE RESULTS......................................................................................................44

7. RESULTS - OBJECTIVE 4.......................................................................................................................487.1. INTRODUCTION ...............................................................................................................................487.2. IRL2000 ENVIRONMENT..................................................................................................................487.3. CO-ORDINATION RESULTS ............................................................................................................51

8. RESULTS - OBJECTIVE 5.......................................................................................................................538.1. INTRODUCTION ...............................................................................................................................538.2. SHANNON / DUBLIN INTERFACE RESULTS..................................................................................548.3. SHANNON SPECIFIC OBJECTIVES RESULTS ..............................................................................558.4. DUBLIN SPECIFIC OBJECTIVE RESULTS .....................................................................................58

9. CONCLUSIONS AND RECOMMENDATIONS ........................................................................................629.1. OBJECTIVE 1 ....................................................................................................................................629.2. OBJECTIVE 2 ....................................................................................................................................719.3. OBJECTIVE 3 ....................................................................................................................................729.4. OBJECTIVE 4 ....................................................................................................................................749.5. OBJECTIVE 5 ....................................................................................................................................75

TRADUCTION EN LANGUE FRANÇAISE DU RESUME, DE L’INTRODUCTION, DES OBJECTIFS, DES CONCLUSIONS ET RECOMMANDATIONS..........................................................................................81ANNEX I .........................................................................................................................................................107ANNEX II ........................................................................................................................................................119


viii EEC Report No. 366

EUROCONTROL

LIST OF FIGURESFigure 1: Radar Window .......................................................................................................................... 14Figure 2: Example of “Unconcerned” labels ............................................................................................ 16Figure 3: Example of “Advance Warning” label ....................................................................................... 16Figure 4: Example of “Assumed” label..................................................................................................... 16Figure 5: Example of “Concerned” label .................................................................................................. 17Figure 6: Example of Selected label format............................................................................................. 17Figure 7: Extended Label Window (ELW)................................................................................................ 17Figure 8: Three-button mouse ................................................................................................................. 18Figure 9: Example of Sector Inbound List (SIL)....................................................................................... 28Figure 10: Sector List (SEL)....................................................................................................................... 30Figure 11: Example of Arrival List .............................................................................................................. 31Figure 12: Example of Departure List ........................................................................................................ 31Figure 13: Example of Hold List................................................................................................................. 33Figure 14: Example of APW Display.......................................................................................................... 35Figure 15: Conflict and Risk Display.......................................................................................................... 37Figure 16: Parameters used for Conflict and Risk Warnings..................................................................... 38Figure 17: Co-ordination Horizontal Sector Boundary............................................................................... 49Figure 18: Co-ordination Vertical Sector Boundary ................................................................................... 49Figure 19: Co-ordination Super Sector with Vertical Boundaries .............................................................. 50Figure 20: Example of Message-Out Window ........................................................................................... 51Figure 21: Example of Message-In Window.............................................................................................. 51

LIST OF TABLESTable 1: Temporary Segregated Areas ........................................................................................................ 3Table 2: Traffic Sample Percentage Growth Rates...................................................................................... 4Table 3: Hold Stack Allocation...................................................................................................................... 7Table 4: Exercise Programme...................................................................................................................... 8

ANNEX I - MAPSMap 1: Organisation A.............................................................................................................................. 109Map 2: Organisation B.............................................................................................................................. 110Map 3: Organisation C.............................................................................................................................. 111Map 4: Organisation D.............................................................................................................................. 112Map 5: Organisation E.............................................................................................................................. 113Map 6: Shannon Low Level – Organisation A .......................................................................................... 114Map 7: Shannon Low Level – Organisation B .......................................................................................... 115Map 8: Dublin CTA – Organisations A,B, C, D......................................................................................... 116Map 9: Dublin CTA – Organisation E ....................................................................................................... 117

ANNEX II - OPERATIONS ROOM FLOORPLANSOperations Room - Organisation A .......................................................................................................... 122Operations Room - Organisation B .......................................................................................................... 123Operations Room - Organisation C .......................................................................................................... 124Operations Room - Organisation D .......................................................................................................... 125Operations Room - Organisation E .......................................................................................................... 126


EEC Report No. 366 ix

EUROCONTROL

LIST OF GRAPHSGraph 1: Label Selection Difficulty ...........................................................................................................19Graph 2: OCM Accessibility......................................................................................................................23Graph 3: Displayed List Items ..................................................................................................................27Graph 4: Displayed SIL Information .........................................................................................................28Graph 5: SIL Information - PLC................................................................................................................29Graph 6: SIL Information - EXC................................................................................................................29Graph 7: Input - SIL or Radar Label .........................................................................................................31Graph 8: Use of Arrival List ......................................................................................................................32Graph 9: Use of Departure List.................................................................................................................32Graph 10: Use of Hold List .........................................................................................................................34Graph 11: Legibility of STCA Label Block ..................................................................................................36Graph 12: CRD Tools Usefulness ..............................................................................................................39Graph 13: MTCD Tools Accuracy...............................................................................................................40Graph 14: CRD Priority...............................................................................................................................40Graph 15: CRD Prediction Failure..............................................................................................................41Graph 16: CRD – PLC Workload Reduction ..............................................................................................41Graph 17: MTCD Situational Awareness ...................................................................................................42Graph 18: MTCD Safety .............................................................................................................................42Graph 19: PLC/EXC Teamwork .................................................................................................................44Graph 20: PLC/EXC Task Allocation..........................................................................................................45

LIST OF PHOTOSPhoto 1: Ireland 2000 Real-time Simulation – EEC, Brétigny: 6th to 31st March 2000................................. viPhoto 2: Ireland 2000 Real-time Simulation Operations Room ..................................................................10Photo 3: Example of Dublin ATCC Controller Working Positions (CWP) ...................................................46Photo 4: Example of Shannon ATCC Controller Working Positions (CWP) ...............................................47Photo 5: Ireland 2000 Real-time Simulation Operations Room ................................................................121


x EEC Report No. 366

EUROCONTROL

ACRONYMS AND ABBREVIATIONSAbbreviation Definition Abbreviation Definition

AB Action Button EXC Executive ControllerACT Activation Message FDPS Flight Data Processing SystemADEP Aerodrome of Departure FIN Final Approach Sector [Dublin]ADES Aerodrome of Destination FIR Flight Information RegionAFL Actual Flight Level [SSR Mode C] FL Flight LevelAHDG (ahdg) Assigned Heading FPL Flight PlanAIP Aeronautical Information Publication Ft (ft) FeetAMAN Arrival Manager FXPT FIR Exit PointAMSL Above Mean Sea Level GND GroundAPN North Hold Approach Sector [Dublin] GP1 Gapli 1 Sector [Shannon High-level]APP Shannon Approach Sector GR1 Giper 1 Sector [Shannon High-level]APS South Hold Approach Sector [Dublin] HMI Human Machine InterfaceAPW Area Proximity Warning HPT Holding PointARC (arc) Assigned Rate of Change [i.e. climb/descent] IAA Irish Aviation AuthorityARN Dublin North Area Sector IAC Irish Air CorpsARR Arrival List [Window] IATMS Irish Air Traffic Management SystemARS Dublin South Area Sector IB Information ButtonARW Dublin West Area Sector ICAO International Civil Aviation OrganisationASP (asp) Assigned Speed IPAS Integrated (data) Preparation and Analysis

SystemASSR Assigned SSR Code IRL Ireland Feed SectorATC Air Traffic Control ISA Instantaneous Self Assessment [Workload

Model]ATCC Air Traffic Control Centre LATCC London Air Traffic Control CentreATCO Air Traffic Control Officer LND Land End Feed SectorATM Air Traffic Management LOA (LoA) Letters of AgreementBB1 Baban 1 Sector [Shannon High-level] LON London Feed SectorBST Brest Feed Sector LOW Shannon Low Level SectorCAIRDE Civil Aviation Integrated Radar Display

EquipmentMACC Manchester Area Control Centre

CBT Computer Based Training MAE Maestro Master PositionCFL Cleared Flight Level MAESTRO Moyen d’Aide a l’Ecoulement Sequence du

Traffic avec Recherche d’OptimisationCRD Conflict and Risk Display MATCC Manchester Air Traffic Control CentreCRNA/O Centre en Route de la Navigation Aerienne

OuestMATS Manual of Air Traffic Services

CTA Control Area MOA4 Military Operations Area 4CWP Controller Working Position MOA6 Military Operations Area 6DATCC Dublin Air Traffic Control Centre MOA7 Military Operations Area 7DCT Direct MTCD Medium Term Conflict DetectionDEP Dublin Departure Mhz Mega HertzDEP Departure List [Window] N NorthDFL Dynamic Flight Leg NAT North Atlantic TrackDL1 Dolip 1 Sector [Shannon High-level] NLO Shannon North Low SectorDL2 Dolip 2 Sector [Shannon High-level] NM (nm) Nautical MilesDUB Dublin VOR No. NumberE East OCA Oceanic Control AreaEAT Estimated Approach Time OCM Oceanic Clearance MessageEATCHIP European Air Traffic Control Harmonisation

and Integration ProgrammeODS Operator Display System

EEC Eurocontrol Experimental Centre OFL Oceanic Flight LevelEID5 Danger Area 5 OLDI On-line Data InterchangeEID6 Danger Area 6 Org. OrganisationELW Extended Label Window PEL Planned Entry Level


EEC Report No. 366 xi

EUROCONTROL

Abbreviation Definition Abbreviation DefinitionPLC Planning Controller SOTA Shannon Oceanic Transition AreaPOACC Prestwick Oceanic Air Traffic Control

CentreSPA Super Sector A [Shannon High-level]

R/T Radio Telephony SPB Super Sector B [Shannon High-level]R15 Restricted Area 15 SPC Super Sector C [Shannon High-level]R16 Restricted Area 16 SPD Super Sector D [Shannon High-level]RET Rapid Exit Taxiway SPE Super Sector E [Shannon High-level]RNAV Area Navigation SPF Super Sector F [Shannon High-level]ROF Request on Frequency [Message] SSR Secondary Surveillance RadarRPS Radar Position Symbol STAR(S) Standard Arrival Route(s)RVSM Reduced Vertical Separation Minima STCA Short Term Conflict AlertRwy Runway STNA Service Technique de la Navigation

AerienneSATCC Shannon Air Traffic Control Centre SWK Shanwick Feed SectorSB Special Button SYSCO System Supported Co-ordinationScATCC Scottish Air Traffic Control Centre TL Transition LevelScOACC Scottish and Oceanic Area Control

CentreTMA Terminal Area

SEA Irish Sea Feed Sector TMA Shannon TMA SectorSEL Sector List [Window] TSA Temporary Segregated AreaSFC Surface [Ground Level / Sea Level] TWR Tower Feed Sector [Dublin]SH2 Shannon 2 Sector [Shannon High-level] UIR Upper Information RegionSH3 Shannon 3 Sector [Shannon High-level] UTA Upper Terminal AreaSI Sector Indicator [Co-ordination Partner] VFR Visual Flight RulesSID(S) Standard Instrument Departure(s) VHF Very High FrequencySIL Sector Inbound List [Window] VOR VHF Omni RangeSLO Shannon South Low Sector W WestSOCA Shanwick Oceanic Control Area XFL Exit Flight LevelSOT SOTA Feed Sector XPT Exit Point


xii EEC Report No. 366

EUROCONTROL

REFERENCES

[1] Ireland 2000 Real-time Simulation Facility Specification Part 1 – Operational Conduct andAnalysis.

[2] Eurocontrol Experimental Centre Fast-time Airspace Model Simulation of Irish Airspace -EEC Note No. 20/97.

[3] MAESTRO User’s Manual.

[4] Ireland 2000 Real-time Simulation Facility Specification Part 2 –Technical.

[5] Ireland 2000 Real-time Simulation System Handbook.

[6] Ireland 2000 Real-time Simulation Controller Information Book.

[7] Ireland 2000 Real-time Simulation Pilot Information Book.

[8] AIP Ireland.


EEC Report No. 366 1

EUROCONTROL

1. INTRODUCTION

The IRL2000 real-time simulation took place at the EUROCONTROL Experimental Centrebetween March 6th and March 31st 2000. The simulation was designed to meet therequirements of the Irish Aviation Authority (IAA).

This report describes the objectives, working organisations and parameters used in thesimulation, together with an analysis of the results obtained and the conclusions drawn.

The current Irish ATM System (CAIRDE) was commissioned in 1990 and while it meetsEATCHIP requirements it utilises 1980’s technologies and is not capable of expansion and ofincorporating new technologies such as HMI and modern ATC tools.

The IAA plans to implement a new ATM System (CAIRDE 2000) which will enable theAuthority to provide safe and cost effective services to its customers in the first decade of thenew millennium, in line with the forecast growth in air traffic.

The simulation evaluated the operational impact of the HMI (Human Machine Interface) andassessed the potential roles of Executive and Planning controllers in the new system.Secondary objectives focused on sectorisation configurations and operating proceduresspecific to Shannon and Dublin air traffic control centres.

The airspace simulated included Enroute, TMA, Approach and Departure sectors as well asthe Oceanic interface with the Shanwick Oceanic Control Area (OCA).

The simulation was divided into two phases. The first phase assessed a flight progress stripenvironment with co-ordination by telephone. The second phase assessed a moreautomated system without flight progress strips while introducing System Supported Co-ordination (SYSCO) and Medium Term Conflict Detection (MTCD).

This simulation is extremely important to Ireland. As the IAA looks to the installation of a newATC system in the next few years, the active involvement of the controllers in designing andevaluating the system and airspace proposals is essential to the long term success of theCAIRDE 2000 project.


2 EEC Report No. 366

EUROCONTROL

2. IRELAND 2000 - SIMULATION OBJECTIVES

The simulation objectives include an overall high-level evaluation of the HMI and workingmethods as well as station objectives specific to Shannon ATCC and Dublin ATCCoperations. For each objective, a short piece of italic text has been added to give a moreprecise definition of the objective.

The objectives of the simulation were:

1. Evaluate the operational impact of the HMI for the CAIRDE 2000 system.To gather subjective feedback from the participating controllers on the usability andoperational suitability of the CAIRDE 2000 HMI as simulated with paper-strips. The EECwill additionally provide a facility to simulate an enhanced automated system that willenable the client to preview possible future developments of the system.

2. Assess the operational impact of the new system ATC Tools, Safety Nets andMonitoring Aids.To gather subjective feedback and system recordings on the usability and utility of thenew ATC tools provided.

3. Evaluate the potential roles of Executive and Planning Controllers in the simulatedsystem.To obtain controller feedback on a proposed distribution of work tasks betweenExecutive and Planning controllers and, if necessary, to compare this configuration withother configurations proposed during the simulation based on the experience acquiredfrom working with the new system.

4. Assess the operational impact of System Supported Co-ordination (SYSCO)To gather subjective feedback from the participating controllers and system recordingson the usability and operational utility of SYSCO, both with partial functionality andpaper-strips, and with added functionality in a strip-less environment.

5. Investigate further the findings of the fast-time study regarding airspace changesto both Shannon and Dublin. Specifically to assess the operational impact of thefollowing changes:

a) Re-sectorisation of Shannon ATCC - Low Level.

b) Re-sectorisation of Shannon ATCC - High Level.

c) Re-sectorisation of Dublin ATCC.

d) Use of one-man sectors in Dublin ATCC.

e) Introduction of an Arrival Manager system (MAESTRO) at Dublin ATCC.

f) Implementation of parallel runway operations at Dublin Airport.

g) Use of 3nm separation between aircraft on final approach to Runway 10R.

h) Use of new SIDS/STARS for State and regional airports.

i) Use of holding patterns at new positions 15nm on the final approach to Shannon.

j) Use of procedures for dealing with High Level traffic inbound to Belfast Airport.

k) Re-positioning of the DINIL and NASRI holds and the Dublin CTA western boundary.



EUROCONTROL

3. IRELAND 2000 - SIMULATION CONDUCT3.1. AIRSPACE

The simulated airspace was divided into either “Measured” or “Feed” sectors. Measuredsectors represented the study airspace of the simulation and were simulated as realisticallyas possible. Feed sectors provided a suitable interface with the surrounding airspacewithout representing in full the actual sectorisation.

The measured sectors included the entire airspace managed by the IAA. This includesdelegated airspace from LATCC, MACC and ScOACC to Dublin ATCC together withdelegated airspace from LATCC and CRNA/O to Shannon ATCC.

The surrounding countries and sectors were represented by feed sectors. SEA (Irish Sea)exclusively fed the Dublin ATCC. LON (London), LND (Lands End), BST (Brest) and SWK(Shanwick) exclusively fed Shannon ATCC. In certain exercises the SOTA (SOT) area wasrepresented by a feed.

TWR (Dublin Tower) handled departure and arrival traffic at Dublin. IRL (Ireland) handled allarrival and departure traffic at Shannon, Cork and the regional airports and also provided theShannon interface to Dublin in those organisations where Shannon Low-Level was notsimulated.

As the feed sectors in the simulation combine a number of separate sectors, the sectorboundaries and frequency allocations often differ to those of the real environment.

Full details of the simulated airspace can be found in the Ireland 2000 Real-time SimulationFacility Specification Part 1 – Operational Conduct and Analysis [Reference 1].

3.2. TEMPORARY SEGREGATED AREAS

Temporary segregated areas include military activity areas, danger areas and prohibitedareas as defined in AIP–Ireland. Video maps were used to represent all temporarysegregated areas. The Area Proximity Warning (APW) feature was evaluated for EID5,MOA6 and MOA7, however the military airspace was considered to be inactive in allorganisations.

These areas were defined as follows:

Reference Vertical LimitsEID5 GND / FL140 (for APW test purposes)EID6 GND / 8000 ft AMSLR15 GND / 2000 ft AMSLR16 GND / FL100MOA4 GND / FL100MOA6 FL330 / FL380 (for APW test purposes)MOA7 FL300 / FL360 (for APW test purposes)

Table 1: Temporary Segregated Areas



EUROCONTROL

3.3. TRAFFIC SAMPLESIn order to enable a realistic replication of existing operations within the simulated airspacethe IAA supplied separate traffic recordings for Shannon and Dublin ATCC’s.

The Shannon traffic samples were based upon 2 three-hour sets of westbound NAT trafficrecording from 22 and 29 August 1998 and 2 three-hour sets of eastbound NAT trafficrecordings from 11 and 12 July 1998. The Dublin traffic sample was based on a three-hourset of traffic combined from recordings from 3 and 22 July 1998.

The IAA and EEC agreed on percentage traffic growth rates to represent Medium Term(2002) and Long Term (2007) forecast traffic levels as predicted in 1999.

The percentage increases applied were based on data derived from ICAO (NAT TrafficForecasting Group) and EUROCONTROL (Air Traffic Statistics and Forecasts).

The details of the percentage growth rates applied to the 1998 traffic samples are as follows:

Medium TermEuropean andDomestic

Transatlantic

30% 20%Long TermEuropean andDomestic

Transatlantic

85% 45%

Table 2: Traffic Sample Percentage Growth RatesFor training purposes traffic samples representing 50% of the Medium Term were used.

Reduced Vertical Separation Minima (RVSM), above FL290 and up to FL420, were assumedto be in force in all exercises as they already exist for Shannon High-Level sectors andshould be in place for all Irish Airspace by year 2002.

3.4. TRAFFIC SAMPLE ANALYSISNormally the methodology for traffic sample analysis is based on the identification of suitablesimulation periods with the help of the Integrated Preparation and Analysis System (IPAS)Tool.

For Shannon and Dublin this arrangement was not suitable for the following reasons:

• Shannon High-Level Westbound NAT traffic require an Oceanic Clearance which bothrestricts and ensures their entry to Oceanic airspace in terms of exit point, time, flightlevel and speed.

• Shannon High-Level Eastbound NAT traffic enter the Shannon FIR/UIR based on similaroperating procedures applied on their departure from Continental American airports.

• Enhancement of the above NAT traffic to Medium Term and Long Term forecast levelswas best achieved by the Shannon project team whose expertise and skill in theapplication of oceanic clearance procedures was vital.

• The Dublin project team divided the Dublin traffic sample into three overlapping partsthat best represented busy departure, arrival and mixed flows.



EUROCONTROL

• Domestic traffic between Dublin, Shannon and the regional airports was tailored to suitthe requirements of the simulated organisations.

• As Shannon and Dublin traffic was simulated in all exercises, simulation start times forDublin traffic ware adjusted to fit the start times applied for Shannon Eastbound andWestbound NAT traffic.

It must be noted, however, that the IPAS tool was used very effectively to ensure accurateprofile validation and correct sector sequence.

3.5. ORGANISATIONSInitially, six airspace organisations were prepared (Org. A-F). Each organisation incorporatedaspects derived from the results of the EEC Fast-time Airspace Model Simulation of IrishAirspace - EEC Note No. 20/97 - [Reference 2].

During the course of the simulation Organisation F was dropped with the agreement of theclient, in order to ensure a more thorough evaluation and analysis of the first fiveorganisations.

The basic elements of the simulated organisations are described below.

3.5.1. Organisation AOrganisation A simulated a westerly flow of oceanic traffic (NAT) in a Shannon High-levelsectorisation of the Shannon UTA that included the northern portion of the Shannon OceanicTransition Area (SOTA) airspace. Shannon Low-level simulated a single Low-level sector(LOW), a Terminal Area sector (TMA) and Shannon Approach (APP).

The High-level sectors Shannon 3 (SH3) and Dolip 2 (DL2) were not measured in Org. A.The reason for this was that traffic profiles in these sectors required manipulation to ensurethat controllers could cope in a two-sector High-level configuration with medium and longterm forecast traffic levels.

However, the interface from Shannon Low-level (LOW) to the High-level sectors (SH3 andDL2) was measured.

Dublin evaluated the current sectorisation plan of North Area (ARN), South Area (ARS),North Hold Approach (APN) and South Hold Approach (APS).

Active runway usage at Dublin and Shannon airports varied during Org. A.

When Runway 10R was active at Dublin, Runway 06 was active at Shannon. StandardArrivals (STARS) to Dublin Runway 10R were to the western holding stacks at DINIL andNASRI. STARS to Shannon Runway 06 were to the southern holding stack at FOY.

When Runway 28L was active at Dublin, Runway 24 was active at Shannon. StandardArrivals (STARS) to Dublin Runway 28L were to the eastern holding stacks at ROKNA andTULSO. STARS to Shannon Runway 24 were to the northern holding stack at SCARF.

The introduction of a Rapid Exit Taxiway (RET) on Runway 28L at Dublin permitted theapplication of 3nm separation between aircraft on final approach.

See Maps - Annex I: Map 1 - Organisation A.



EUROCONTROL

3.5.2. Organisation BOrganisation B simulated the same westerly flow of oceanic traffic (NAT) and same ShannonHigh-level sectorisation.

In this organisation, however, Shannon Low-level simulated two Low-level sectors –Shannon Low North (NLO) and Shannon Low South (SLO) along with TMA and APP.

Once again, the High-level sectors Shannon 3 (SH3) and Dolip 2 (DL2) were not measured.

However, the interface from Shannon Low North (NLO) and Shannon Low South (SLO) tothe High-level sectors (SH3 and DL2) was measured.

Dublin evaluated the introduction of a Departure sector (DEP).

Dublin and Shannon active runway configurations were unchanged.

See Maps - Annex I: Map 2 - Organisation B.

3.5.3. Organisation COrganisation C simulated the same westerly flow of oceanic traffic (NAT) in a Shannon High-level five-sector configuration that included the northern portion of SOTA airspace. ShannonLow-level was not simulated.

Dublin evaluated the introduction of a Final Approach sector (FIN) and the MAESTRO arrivalmanager. The DEP sector was not simulated.

Dublin and Shannon active runway configurations were unchanged.

See Maps - Annex I: Map 3 - Organisation C.

3.5.4. Organisation DOrganisation D simulated an easterly flow of oceanic traffic (NAT) in a Shannon High-levelfive-sector configuration of SOTA airspace that included the southern part of the ShannonUTA.

Dublin evaluated the implementation of both the Departure (DEP) and Final Approach (FIN)sectors together with the MAESTRO arrival manager.

In addition to the runway configurations applied in the previous organisations, Dublinsimulated the introduction of a parallel runway (Runway 10L/28R) in some exercises. NewSIDS were described for Runway10L/28R. This runway was designated solely for departingtraffic when parallel runways were in use. Runway 10R/28L was designated for arrivingtraffic in all exercises.

See Maps - Annex I: Map 4 - Organisation D.



EUROCONTROL

3.5.5. Organisation EOrganisation E simulated a westerly flow of oceanic traffic (NAT) in a Shannon High-levelfive-sector configuration of SOTA airspace that included the southern part of the ShannonUTA.

Dublin evaluated manning each sector solely with an Executive Controller (EXC). Thisfacilitated the inclusion of an extra sector – West Area (ARW), together with the FinalApproach (FIN) and Departure (DEP) sectors. In addition, Dublin evaluated the use ofparallel runways and the MAESTRO arrival manager.

See Maps - Annex I: Map 5 - Organisation E.

Active runways were Runway 28R for departures and Runway 28L for arrivals. NewStandard Arrivals (STARS) were described for Runway 28L. In effect, the TMA entry pointdetermined the holding stack allocated for arriving aircraft. The stack allocation applied isshown in the table below:

Hold Stack TMA Entry PointROKNA BOYNE LAMBU LIFFYTULSO TOLKA VATRYNASRI BEPAN OMAAR SHELI FYLISDINIL CONRO GELKI

Table 3: Hold Stack Allocation

3.5.6. SectorisationThe five simulated organisations incorporated various sectorisation configurations. Theseincluded oceanic interface, en-route and TMA sectors.

Full details of all simulated sectors, both measured and feed, can be found in the Ireland2000 Real-time Simulation Facility Specification Part 1 – Operational Conduct and Analysis[Reference 1].

3.6. EXERCISE PROGRAMMEAn exercise programme was constructed which allowed for three simulation exercises perday. Briefing and de-briefing periods were included as required.

Forty-one measured exercises were completed while a further eight exercise slots wereallocated for familiarisation and system training. The exercise programme was carefullyconstructed in order to optimise the evaluation of the simulation objectives.

Each organisation (except Org. A), was investigated with medium-term and long-termforecast traffic. The client opted to cancel the simulation of Org. A long-term traffic, followingappraisal of the initial simulation results achieved with medium-term traffic.

As Runway 28 and Runway 24 are the more prevalent active runway configuration for Dublinand Shannon respectively, the client focused on the simulation of this configuration. Thus,the ratio in favour of the combination of Dublin Runway 28; Shannon Runway 24 as opposedto Dublin Runway 10; Shannon Runway 06 was 5:1.



EUROCONTROL

The table below shows the exercise programme that was eventually completed.

Week Org. Numberof Exercises

Traffic Level Objective

1 BAAB

2336

50% of Medium-term S/D50% of Medium-term S/DMedium-term S/D3 Medium-term S/D3 Long-term S/D

TrainingTrainingEvaluation Org. AEvaluation Org. B

2 BC

D

16

6

1 Long-term S/D3 Medium-term S/D3 Long-term S/D3 Medium-term S / LongTerm D3 Long-term S/D

Evaluation Org BEvaluation Org C

Evaluation Org D

3 EDDC

4332

4 Medium-term S/D50% of Long-term S/D3 Medium-term S/D2 Medium-term S/D

Evaluation Org DTraining Phase II (P.II)Evaluation Org D (P.II)Evaluation Org C (P.II)

4 CBE

325

3 Long-term S/D2 Medium-term S/D2 Medium-term S/D3 Long-term S/D

Evaluation Org C (P.II)Evaluation Org B (P.II)Evaluation Org E (P.II)

S/D = Shannon / Dublin

Table 4: Exercise Programme

The staffing of sectors followed a strict rotation drawn up by the client representatives fromShannon and Dublin. The staffing plan took into account each controller’s qualifications andrecent experience and ensured that each variation of organisation was evaluated from asmany different control positions as possible.

3.7. SIMULATED ATC SYSTEMThe simulated ATC system represented as closely as possible the main specifications of theIrish Air Traffic Management System (IATMS). This advanced ATC system incorporatesmany features from the EATCHIP III development programme and requirements defined forthe Irish Aviation Authority (IAA). The system was simulated in two phases. Phase I (P.I)assessed a flight progress strip environment with co-ordination by telephone. Phase II (P.II)assessed a more automated system without the use of flight progress strips whileincorporating System Supported Co-ordination (SYSCO) and Medium Term ConflictDetection (MTCD).

An arrival manager system (MAESTRO) was simulated for Dublin. MAESTRO is a multi-airport and multi-runway decision-making tool for sequencing the arrival traffic to severalairports and / or runways. A full description of the MAESTRO system is contained within theMAESTRO User’s Manual [Reference 3].

The ATC system employed an advanced Operator Display System (ODS) includingextensive use of colour. Advanced flight data processing techniques were used to providecontrollers with short-term warnings of potential losses of separation and penetration ofdanger areas. A three-button mouse was the sole input and data access device, throughwhich the controller interacted with the following facilities:



EUROCONTROL

Screen ConfigurationAll screen configurations including range, filters, label orientation, selectable windows anddisplayed maps were set via an iconifiable on-screen control panel.

Interactive Track LabelsIn this electronic system the track label became an integral tool for the controller. The labelhad three main functions.

• Display essential flight plan information.• Provide interaction to enter controller inputs to the system.• Display Safety Net warnings when necessary.

Electronic Civil Co-ordinationThe controller could negotiate planned sector entry levels (PEL), sector exit levels (XFL) anddirect routes via electronic means.

Electronic List DataElectronic lists displayed sector entry and exit conditions for each flight, and allowed thisinformation to be verified, modified or electronically co-ordinated.

Quick Information AccessThe controller had instantaneous access to certain flight information, such as a DynamicFlight Leg (DFL) and other flight display windows.

Notebook FunctionsThe controller could enter Assigned Headings, Assigned Speeds, and Assigned Rates ofClimb/Descent as well as Direct Routes directly into the track label for display in place ofmarking the information on paper flight strips.

Medium Term Conflict DetectionThe system provided Shannon controllers with warnings of system calculated potential flightconflicts, up to 30 minutes before the start of each conflict.

Safety NetsThe system provided warnings relating to Short Term Conflict Alert (loss of radar separation)and Area Proximity Warning (temporary segregated area incursion) up to two minutes priorto the infringement.

Certain objectives concerning specific elements of the simulated system and controllerinterface are addressed in this report. However, a full description of the simulated system iscontained within the Ireland 2000 Real-time Simulation Facility Specification Part 2 -Technical [Reference 4].

3.8. CONTROLLER WORKING POSITIONThe measured Controller Working Position consisted of:

• A Sony™ 20" square colour display, providing a multiple window, working environment.• A Hewlett Packard™ processor and BARCO™ graphics card.• A mouse device equipped with three input buttons.• A digital communication system (Audio-LAN) with Headset, speaker, footswitch and

panel mounted Push-to-talk facility.• An Instantaneous Self-Assessment (ISA) subjective workload input device.



EUROCONTROL

Where a sector had two positions, an Executive Controller position (EXC) and a PlanningController position (PLC), the CWP provided to each position was identical with the samefunctionality. Only operational rules and the specified tasks of the two controllers promptedthe setting of different screen configurations. In addition to the provision of strip printers forall simulated sectors, MAESTRO monitors displayed arrival traffic data to all Dublin ATCCmeasured and feed sectors.

Adjacent 'Feed' SectorsSix 'Feed Sector' controllers were equipped with Sony™ 20" square monitors. Specialfunctionality was attached to a Feed Sector CWP, known as a 'Hybrid' Working position.The Hybrid incorporated a piloting function so that controller inputs were interpreted directlyas pilot inputs, allowing the sector to operate without a dedicated pseudo-pilot.

3.8.1. Operations Room ConfigurationThe Operations room was configured with 26 Controller Working Positions including theMAESTRO master position. The Operations Room layout remained unchanged fromorganisation to organisation. However, the number of CWP’s used depended on thesectorisation and manning configuration being simulated. The various configurationssimulated were: (See Operations Room Floorplans - Annex II).

• Dublin Area 2 two-man sectors with/without MAESTRO (4-5 CWP)• Dublin Area 3 one-man sectors with/without MAESTRO (3-4 CWP)• Dublin Approach 2 one-man sectors (2 CWP)• Dublin Approach 3 one-man sectors (3 CWP)• Dublin Departure 1 one-man sector (1 CWP)• Shannon High-level 2 two-man sectors (4 CWP)• Shannon High-level 5 two-man sectors (10 CWP)• Shannon Low-level 1 two-man sector (2 CWP)• Shannon Low-level 2 two-man sectors (4 CWP)• Shannon TMA 1 two-man sector (2 CWP)• Shannon Approach 1 one-man sector (1 CWP)• Feed Sectors 6 Sectors (6 CWP)

Photo 2: Ireland 2000 Real-time Simulation Operations Room



EUROCONTROL

3.9. ATC PROCEDURES AND CONTROLLER TASKSATC Procedures applied during the simulation were as far as possible the same as in currentoperation (at the time of simulation) at the ATC Centre of origin, either Dublin or Shannon.New procedures relating to station specific objectives were defined before and fine-tunedduring the simulation.

Phase II of the simulation focused on the assessment of the potential roles of the Executive(EXC) and Planning Controllers (PLC) in the new system. The simulated ATC systemrequires a considerable amount of controller input to function correctly. The details of thecontroller interaction with the system are provided in the Ireland 2000 Real-time SimulationSystem Handbook [Reference 5].

The Executive functions remained the same as in Phase I (with flight progress strips) andPhase II (without flight progress strips). In Phase I where flight strips were provided the PLCwas only required to make simple inputs to update the system on trajectory changes.

3.9.1. ACC Controllers (EXC and PLC)A team of two controllers, whose responsibilities were divided as explained below, managedeach sector. In the case of one-man sectors, the EXC assumed the responsibilities of bothEXC and PLC.

The following terms were used in the en-route environment for the purpose ofstandardisation:

• Sector - The area of control responsibility (delegated airspace) of the sector team.

• EXC controller - Radar Position: The position which is in direct communication with theaircraft and which uses radar information as the primary means of separation.

• PLC controller - Planning Position: The position responsible for co-ordination and theorganisation and planning tasks concerning traffic entering and leaving the sector.

3.9.2. Simulation Phase II ProceduresCurrent Operational Procedures, as laid down, were applied at all times except in the caseswhere new procedures had been specified for the period of the simulation.

3.9.3. ResponsibilitiesThe responsibilities of individual controllers are explained below. This description is theresult of the experience of other real-time simulations using similar systems and wasproposed as a basis on which to commence the simulation where further assessment wasconducted.

Sector entry - before the entry of the flight into the sector

Planning Controller

Verifies entry conditions for each new flight (SIL, SEL).

Detects potential conflicts at entry to sector - uses MTCD & Dynamic Flight Legs.Resolves those conflicts as required (modification of PEL).



EUROCONTROL

Executive Controller

Reads the new FPL element displayed in SIL, SEL.

Is responsible for any SKIP initiation.

Flight within the sector

Planning Controller

Monitors the sector frequency and assists the Executive Controller to detect and resolveconflict situations - uses MTCD & Dynamic Flight Legs.

Assists the Executive Controller with co-ordination accept, reject or counter proposal inMessage-In window - uses telephone if required.


Is responsible for Assume input (on first R/T contact).

Is responsible for radio communication with pilots.

Is responsible for providing the required separation between aircraft.

Is responsible for conflict detection and resolution.

Is responsible for tactical co-ordination radar to radar with adjacent sectors - uses telephoneif required.

Is responsible for CFL, DCT, AHDG, ARC, ASP, input orders.

Before the aircraft exits the sector

Planning Controller

Evaluates sector exit conditions in co-operation with Executive Controller.

If directed by the Executive Controller inputs XFL changes and co-ordinates as required.


Is responsible for determining suitable exit conditions, either inputs changes or directs thePlanning Controller to input and co-ordinate changes as required.

Is responsible for ensuring that exit conditions are achieved.

Is responsible for Transfer input.



EUROCONTROL

3.9.4. Shannon TMA and Approach ControlThe division of responsibility and draft working practices for the TMA and Approachcontrollers was the subject of review during the simulation in order to develop appropriateprocedures.

3.9.5. Dublin ProceduresThe current working practices (at time of simulation) at Dublin differ significantly from thoserecommended previously for en-route sectors. The concept of 'shared' airspace meant thatnew procedures and roles relevant to this specific working environment were developed.Requirements for these were explored during the simulation.

3.9.6. Hybrid Feed sectorsThe simulation employed some “Hybrid” feed sectors. These sectors are unlike normalsectors in that the controller not only acts as controller but also as pilot.

The controller has no R/T communications with aircraft. Certain controller orders aretransmitted electronically to the piloting system such as CFL, Heading, Direct, and Speed.The aircraft in return (as seen on the radar picture) responds automatically.

The Transfer order transfers the aircraft to the next sector where a “real pseudo pilot” callson the frequency in the normal way.

Although Hybrid Feed sectors are simple sectors to manage, several special functions areprovided. A full description of these functions can be found in the Ireland 2000 Real-timeSimulation System Handbook [Reference 5].

Further project information for participating controllers and pilots can be found in thefollowing documents:

• The Ireland 2000 Real-time Simulation Controller Information Book [Reference 6].

• The Ireland 2000 Real-time Simulation Pilot Information Book [Reference 7].

• AIP Ireland [Reference 8].



EUROCONTROL

4. RESULTS - OBJECTIVE 1CONTROLLER INTERFACE (HMI) EVALUATION

Evaluate the operational impact of the HMI for the CAIRDE 2000 system.

4.1. INTRODUCTIONThe simulated ATC system represented as closely as possible the main specifications of theIrish Air Traffic Management System (IATMS). This advanced ATC system incorporatesmany features from the EATCHIP III development programme and requirements defined forthe Irish Aviation Authority (IAA). The system was simulated in two phases. Phase Iassessed a flight progress strip environment with co-ordination by telephone. Phase IIassessed a more automated system without the use of flight progress strips whileincorporating System Supported Co-ordination (SYSCO) and Medium Term ConflictDetection (MTCD).

The Human Machine Interface (HMI) in the system simulated for Ireland 2000, was acomplex display combining flight and radar information, airspace and aeronauticalinformation, and system derived information on the projected trajectory for each flight.Interaction with the system through the HMI was an essential feature, which provided inputto the system and feedback to the controller.

A full description of the Ireland 2000 HMI is available in the Ireland 2000 Real-timeSimulation Facility Specification Part 2 - Technical [Reference 4] and in the Ireland 2000Real-time Simulation System handbook [Reference 5].

The main elements of the HMI were a large Radar Window that included comprehensiveradar label information (Track symbol, Mode C and Flight Plan Information), a Radar ToolboxWindow for accessing the radar window set-up controls, information windows with list andgraphical data, and a three-button mouse input device.

Figure 1: Radar Window



EUROCONTROL

4.1.1. Pre-Simulation OverviewIn order to assess correctly the in-depth results of the HMI analysis, (the majority of which isbased on controller feedback), it is important to take into account the profiles, in terms ofexperience and expertise, of the participating controllers.

The majority (70%) of the participating controllers was in the 45-55 age-bracket with between16 to 32 year’s experience while some of the younger controllers had less than five yearsexperience at their current ATCC.

83% of the controllers had no previous experience of real-time simulation.

With the exception of two controllers, all had previously used personal computers and hadvaried levels of experience in the use of the mouse input device and the windows operatingsystem.

4.2. GENERAL HMI RESULTSThe HMI provided for the Ireland 2000 simulation was very well accepted by the participatingcontrollers. The use of colour in the display of data was also very well received. While somecontrollers had little or no experience of mouse input devices or windows environments theyadapted very quickly to the system. In fact, 95% agreed that a windows style environmentwas a positive step for future ATC systems and that the mouse was a suitable device forinteracting with the system.

The vast majority (91%) considered the screen size appropriate while 78% felt that thescreen layout should not be changed. A large number (80%) agreed that the radar toolboxoffered enough flexibility, however, most controllers felt that the configuration optionsavailable were not optimised.

The general consensus was that a similar HMI would form an acceptable basis for anoperational system. 77% agreed that the integration of multiple display/input windows into asingle display was a good idea, except in the case of the MAESTRO display, where theDublin controllers unanimously recommended that this display should be stand-alone andnot integrated within the radar window.

Significantly, 82% of the controllers agreed that the combination of dynamic flight leg withconflict information, interactive radar labels and lists provided a satisfactory system thatpermitted the removal of paper flight progress strips.

4.2.1. Label and track InformationThe format and functionality of the track label was a key feature of the simulated HMI whichprovided four different label formats.

• Standard Label• Reduced Label• Uncorrelated Label• Extended Label (Window)



EUROCONTROL

Label format also reflected the Control State of the aircraft.

For Unconcerned and Uncorrelated flights a reduced label format was provided.

Figure 2: Example of “Unconcerned” labels

A Standard label format was provided for “Advance Warning”, “Assumed” and “Concerned”aircraft with the display of additional information necessary for the planning and control of theflight.

Figure 3: Example of “Advance Warning” label

Figure 4: Example of “Assumed” label



EUROCONTROL

Figure 5: Example of “Concerned” label

A Selected label format was displayed when the mouse cursor was moved over a standardlabel. The Selected label displayed all fields (cancelling the minimum information rule) andLine 4, containing the ahdg, asp and arc fields, to enable values to be input.

Figure 6: Example of Selected label format

The Extended Label Window (ELW) gave comprehensive details on the flight. Thisinformation was displayed in a separate window at a pre-set location in the top left portion ofthe screen. The ELW location could be re-set as required.

Figure 7: Extended Label Window (ELW)

Different colours were used to represent the aircraft label control states.

• Unconcerned labels Light Grey text (Mustard for Dublin)• Concerned labels Mustard text• Advance Warning labels Light Blue• Assumed labels White



EUROCONTROL

The reason for the use of Mustard for Dublin is explained later in this report when describingColour (Section 4.4.1 refers).

A detailed description of the label formats is provided in the Ireland 2000 Real-timeSimulation System Handbook [Reference 5].

The controllers could dialogue with the system through interactive fields in the label, usingthe three-button mouse. Once the mouse cursor was placed over a field, a ‘single click’ or‘press and hold’ action with either the left, middle or right button initiated an interaction withthe system. The left button was designated the ‘Action Button’ (for inputting data), the rightbutton the ‘Information Button’ (for displaying data) and the middle button, the ‘SpecialButton’, reserved for additional functions.

Figure 8: Three-button mouse

4.3. DATA INPUT AND WINDOWS MANAGEMENT RESULTS4.3.1. Three Button Mouse

The controllers indicated that the mouse was acceptable as a means of data input. Whilethey quickly became familiar with the mouse functionality, some confusion was initiallyexperienced as the functionality differed to that of the instruction handbook in that thepositions of the Information Button (IB) and Special Button (SB) were reversed. Therefore,some controllers experienced difficulty with the association and identification of the mousebuttons. The controllers recommended that different surface textures could assist with buttonidentification.

Mouse reliability was considered of paramount importance for controller confidence. In theevent of a mouse failure, it must be possible to replace it quickly and efficiently with minimumdisturbance for the controller and no effect to the windows operating system. CWP designshould also take account of the different requirements of left-handed and right-handedoperators.

4.3.2. Windows and Pop-up MenusWhile the vast majority of the controllers (95%) agreed that a windows style environmentwas a positive step for future ATC systems, one third experienced problems with handling,moving and re-sizing the windows. Some controllers were sceptical as to whether the radarscreen could suitably accommodate the number and size of windows that they feltnecessary. However, pre-determined allocation of required windows to the ExecutiveController (EXC) and Planning Controller (PLC) should ensure that the viewing areas of eachposition’s radar screen are optimised.

The controllers found the pop-up menus easy to handle with adequate and easily selectableoptions. Some difficulties were experienced with incorrect default settings resulting incumbersome scrolling to select the desired value. The Shannon controllers recommendedthat the Cleared Flight Level (CFL) pop-up should default to 500ft. increments below 10000ft.

ACTION BUTTON (AB)

SPECIAL BUTTON (SB)

INFORMATION BUTTON (IB)



EUROCONTROL

to facilitate usage for VFR traffic operations. In fact, the CAIRDE 2000 system will cater forthis in two ways.

• Aircraft who are filed on VFR flight plans will have a pop-up menu of 500ft increments upto FL195.

• Level increments of 500ft will be available for all pop-up menus for altitudes of 5000ftand below.

4.4. LABEL AND TRACK RESULTSThe majority of the controllers (80%) agreed that the range of information displayed in theradar labels (Unselected, Selected and Extended Label Window) was appropriate. However,label selection and management proved to be extremely difficult.

Was the selection of the correct radar label difficult?

Graph 1: Label Selection Difficulty

This negative result was due to the fact that in the first weeks of the simulation interactionwith the labels proved almost impossible due to label jumping. The physical act of labelselection was very difficult as controllers consistently found that unconcerned labels wouldselect when they were trying to select the desired assumed, advance warning or concernedlabel. In effect, label sensitivity and transparency created controller frustration with thesystem and unnecessary extra workload.

On the positive side, the controllers were better able to identify the problems anticipated withthe new system and provided excellent recommendations (as detailed below) on how thesemight be overcome.

Label selection should be by moving the mouse over the label or track symbol. The ‘pressand hold’ feature, applied later in the simulation, for selection of Unconcerned labels,significantly reduced unnecessary interaction with these labels. Most controllers wouldprefer that individual label selection should be limited to as small a background area aspossible outside the text of the radar label.

As with all display systems of this type, radar label overlap was an issue. Automatic labelde-confliction was available in the simulation but the controllers found this feature annoyingas the constant ‘staggered movement effect’ of the radar labels on the screen proved moreof a distraction than a help.

91.67%

8.33%

0

20

40

60

80

100

Yes No



EUROCONTROL

Label movement should be simple and flexible. The controllers appreciated the variousmethods available to resolve label overlap. The ‘drag and drop’ functionality was preferredto the use of pre-set positions. The pre-set positions allow the controller to choose a pre-defined position for all labels on the radar screen. Drag and drop provided even greaterflexibility for label management. Although this involved extra work, controllers said that theyrefreshed their mental traffic picture as they manually relocated the labels and did not find ittoo tiresome. Indeed, a functionality that allowed the controller to select pre-set positions forindividual labels or sets of labels (eastbound, westbound, arriving, departing) would beadvantageous.

Controllers often experienced difficulty in associating the track label with the Radar PositionSymbol (RPS), particularly when the label orientation was west to north-west of the RPS. Inthese cases the gap between the end of the leader line and the track label was excessive.To overcome this, the controllers recommended that the lead line should attach to the firstfield of the label. In addition, the lead line should be colour coded to distinguish it from thespeed vector and dynamic flight leg.

4.4.1. ColoursThe use of colours for labels and lists was very successful, with 83% of the controllersstating that the use of colour coding for labels and text was logical and understandable. Infact, 80% agreed that the status of each aircraft was always clearly identified by its colour.

The general consensus was that the Light Blue for the ‘Advance Warning’ label was verygood. The colour brilliance was reduced during the simulation as, although it wasconsidered very good for the track labels, it became a little bit uncomfortable when a lot oftext was presented in the various lists provided. The White for ‘Assumed’ aircraft was alsoconsidered to be too bright and the brilliance should be reduced.

The IRL2000 HMI specified extensive use of background colour change to highlightinformation. Subtle change of background colour was very successfully used to cross-highlight all data associated with a particular flight. For example, when the mouse cursorcame to rest on a radar label not only was the Extended Label Window (ELW) updated withthe appropriate flight details but the related lists (SIL, SEL, DEP, and ARR) were alsopresented with a highlighted background. The background colour change for this type ofhighlighting was just sufficient to ensure that the data could be easily located but legibility oftext was not affected. Controllers greatly appreciated the effectiveness of this feature.

Shannon and Dublin controllers had different views regarding the Mustard and Grey coloursselected for ‘Concerned’ and ’Unconcerned’ labels respectively.

Shannon found the Mustard to be suitable but felt that the Grey colour brilliance should bereduced.

Dublin experienced severe problems with the aircraft state system and the use of the Greycolour for Unconcerned labels. The Dublin TMA is shared simultaneously by severalcontrollers operating various sector positions. The Controllers felt that the aircraft statesystem as simulated, was not particularly suitable for their operations. Controllers statedthat although certain aircraft could be considered as ‘Unconcerned” to their sector, it was stillimportant that they were clearly visible. The Grey was not suitable, so Mustard was used forall ‘Concerned’ and ‘Unconcerned’ labels in Dublin CTA. This was an improvement, but notconsidered the ideal solution (See STCA Results Section 5.3.1). Recommendations forfurther improvements varied from brightening the Mustard colour to altering the Callsign andActual Flight Level (AFL) fields to White.



EUROCONTROL

In effect, the methodology of defining and displaying ‘Concerned’ and ‘Unconcerned’ trafficto each Dublin sector individually, requires further investigation.

Finally, it is important to bear in mind that fine-tuning of RGB values is best achieved in theambient lighting conditions where the system is installed.

4.4.2. FieldsThe Callsign field highlight colour (Yellow) was considered to be good and should alsoappear in all relevant lists. During the simulation, (and for the future system), Callsignhighlight was and will be only available between CWP’s of the same sector. Callsignhighlights on ‘Advance Warning’ labels were not over-ridden by White when these labelschanged to transfer-in mode following handover by the upstream sector. In effect, thismeant that the receiving sector was unaware of the handover proposition. Ideally, ahighlighted ‘Advance Warning’ aircraft should change to White ‘Transfer-In’ mode onhandover, and revert to highlight, once the aircraft has been assumed. Controllers alsostated that the Callsign field highlight should penetrate through all filters set within the sector.

The controllers found the Pink field highlighting to be very good and recommended that thesame colour should appear in all relevant windows.

Clicking on the inter-active fields of the selected label with the action button opened theirrelated pop-up window menus. Default values were defined for the pop-up window menusbut in some cases these did not work correctly, resulting in unnecessary scrolling in the pop-up window to select the desired value. This caused frustration and increased the workloadfor the controllers. The problem was further exacerbated by the fact that the principle of XFLdefault levels between sectors was not fully understood and employed correctly by somecontrollers. AT times XFL’s were entered that were not related to the next sector thusremoving it from the sequence. This resulted in aircraft being abrogated from the correctreceiving sector. Abrogation, a modification that implies that an aircraft will no longer enterinto a sector’s airspace, triggers a green callsign in the radar label of the abrogated sector.The controllers acknowledged the event by clicking on the callsign, whereupon the labelstate changed to ‘Unconcerned’.

The main observations of the controllers with regards to the label fields and their related pop-up windows were as follows:

ShannonThe Oceanic Flight Level (OFL) was too far offset from the Exit Flight Level (XFL).

When the XFL and OFL are the same value, the OFL should default to the XFL position, andhave a different colour.

When the Sector Exit Point (XPT) and FIR Exit Point (FXPT) are the same, the defaultshould be the point name in the FXPT position.

Field 1 Field 2 Field 3 Field 4Line 3 of the label should read:XFL OFL FXPT XPT

Ideally, when XFL=OFL and FXPT=XPT, the default should be to Fields 1 and 2respectively.



EUROCONTROL

The positions of the ADES and ADEP fields in the ELW caused some confusion, particularlywith departures from Shannon.

An Assume/Hold functionality should be added to the Callsign menu to allow TMA andApproach controllers to put aircraft directly into the Hold list.

There is no requirement to have the Mach number displayed in the Selected label.

DublinThe Assume/Hold functionality in the Callsign menu, (mentioned above in the Shannonobservations), was tested extensively by the Dublin controllers. They found it to be veryuseful but were divided as to whether or not the default should be to Assume orAssume/Hold. Some felt that the default to Assume/Hold would result in inadvertentplacement of aircraft in the Hold list. There was no consensus on whether the Assume andAssume/Hold options should be located consecutively or separately in the pop-up window.This will require further evaluation.

The controllers felt that a ‘minimum requirements’ label size would facilitate operations in thevery busy Dublin TMA. Further investigation and assessment of the minimum requirement ofmandatory fields should be undertaken

Controllers recorded instances where they transferred aircraft from their sector in error byinadvertently clicking on the mouse action button (AB). A short delay facility in the systemacknowledgement of inter-sector transfers would permit controllers to retrieve (‘UndoTransfer’) incorrectly transferred aircraft.

4.4.3. Exit Flight Level (XFL) DefaultsXFL default settings in the electronic system posed many problems for controllers. In DublinCTA, where area, approach and departure controllers share usage of the same airspace thelimitations of the system could be easily overcome. However, the more complicatedsectorisation configuration of Shannon ATCC (Low-Level/High-Level) with vertically super-posed sectors proved more difficult to solve.

The example diagram below best explains the main problem.

For an aircraft whose RFL would involve climb from Sector 1 to Sector 2 the problem is whatXFL default setting should be applied. If XFL=PEL is used, the aircraft remains at FL330and the upper sector (Sector 2) would have no ‘Advance Warning’ label (Light Blue) for theaircraft until the aircraft co-ordination was proposed. If default XFL=FL340, the aircraft isseen in ‘Advance Warning’ state in the upper sector but the lower sector (Sector 1) can climbthe aircraft into the sector above without co-ordination.

The majority stated that they needed to have the ‘Advance Warning’ label but did not wantthe lower sector to have the right to climb without co-ordination. One possible solution

Sector 2

Sector 1

FL335

FL330

FL340



EUROCONTROL

suggested was that the projected profile should be correctly displayed with either ‘???’ or‘XFL’ inserted in the label field. This, however, would require a late co-ordination on everyaircraft and impact on controller workload.

Further evaluation, concerning the authority to climb to the agreed XFL subject to co-ordination by telephone on potential conflicts, will be required. Controllers also stated thatclimbs following co-ordination should be immediate and coincident with transfer of aircraft.

4.4.4. Oceanic ClearancesShannon High-Level controllers received Oceanic Clearance Message (OCM) informationvia the Extended Label Window (ELW) and the Sector List (SEL). While the majority (75%)of the controllers stated that it was not obvious when the OCM was received by a flight theyagreed that the availability of oceanic clearances in the ELW led to a reduction in theirworkload. They preferred, however to access oceanic clearance information through theSEL.

Oceanic clearance information was more easily accessiblefrom the SEL than from the ELW?

Graph 2: OCM Accessibility

4.4.5. VFR EnrouteThe simulated system employed pre-determined sector sequence parameters for Shannonand Dublin ATCCs. This created a problem for VFR operations in Shannon Low-Levelwhere controllers required a more dynamic versatile system, which precluded the definitionof a fixed flight plan and fixed sector sequence. Dublin ATCC opted not to simulate VFRoperations.

To obtain the necessary flexibility the Low-Level controller was able to select the next sectorand send advance information (via Force ACT) when required. This would change the labelin the selected upstream sector from ‘Unconcerned’ (Grey) to ‘Advance Warning’ (Light Blue)and copied the Cleared Flight Level (CFL) value to the XFL/PEL field.

In all cases the functionality provided was found suitable.

7,14%

14,30%

7,14%

35,71%

35,71%Strongly Agree

Agree

Slightly Agree

Disagree

Slightly Disagree



EUROCONTROL

4.4.6. Direct and Re-routingControllers were able to re-route aircraft direct to any point in the flight planned route usingthe Elastic Vector. If the destination point they selected was not on the original flight plan itwas input by the system into the Assigned Heading field (AHDG). In the system, when usingthe DCT functionality, co-ordination will only place when the new point selected is in thecurrent next sector in the sector sequence, and the aircraft is ACT Out. If a DCT point isselected in any other sector, the new route will not be co-ordinated. However, the trajectorywill be updated and a new sector sequence will be created. In this case, the original nextsector is abrogated and the next sector receives a short notice ACT (normally followingtelephone co-ordination). Abrogation, a modification that implies that an aircraft will nolonger enter into a sector’s airspace, triggers a green callsign in the radar label of theabrogated sector. The controllers acknowledged the event by clicking on the callsign,whereupon the label state changed to ‘Unconcerned’.

The controllers stated that the abrogation function was very useful and that the greencallsign proved very noticeable. In the system being provided to the IAA, abrogation willtrigger a message in the ‘Message In’ window. The general consensus was that the callsigncolour change was both preferable and sufficient, with no requirement for messageinformation and that abrogation should force through all pre-set filters.

Dublin controllers did not use the DCT functionality much although they considered it auseful option. The Shannon controllers used the functionality extensively, particularly in thelarge long High-Level sectors. They found it to be a very useful function and made thefollowing observations and recommendations.

• The colour was good• Aircraft routing DCT crossing several sector boundaries in a short space of time will be

an extremely difficult problem for the electronic system.• Effort and attention should be given to the design of sectors to focus on traffic flows and

optimise avoidance of short sector legs.• Problems were encountered using the elastic vector as the high-Level planning

controllers often needed to select a very long range to view the desired destinationpoint.

• The destination point selected with the DCT functionality should show in the AHDG fieldand following transfer to the downstream sector the destination point should appear inthe downstream sector AHDG field.

4.4.7. SkipSituations occur where a flight may transit a sector for only a short time period. In thesecases, controllers may choose not to have the aircraft on frequency. The skip functionalityallowed the transfer of an aircraft from the “offering” sector to the “next plus one”downstream sector. Skip is initiated by the sector choosing not to work an aircraft prior totransfer by the upstream sector. In the simulated system, it was not possible to cancel theSkip option therefore a ‘confirm skip’ message was triggered requiring a second click on theAB before the function was activated. The Skip activation, in turn, froze all co-ordinationconditions to the skipped sector. No further changes to sector entry or exit conditions werepermitted.

Controllers were comfortable with the skip functionality but stated that execution by the PLCshould be only after consultation with the EXC. The radar label in the skipped sector shouldremain in the “Concerned’ state until sector exit. Ideally, the co-ordination process betweenthe sectors should not be frozen. In addition, despite the availability of the ‘confirm skip’message controllers stated that an ‘Unskip’ functionality would be required.



EUROCONTROL

4.5. FLIGHT PROGRESS STRIPS4.5.1. Introduction

The use of flight progress strips in the simulation was the subject of much discussion anddebate between the IAA and EEC project teams. The simulated CAIRDE 2000 ATM systemwas mainly based on specifications derived from the EATCHIP Manual of the EATCHIP IIIAutomated system. This is a fully automated system designed to operate without strips.The advice and opinion of the EEC, based on extensive experience in this area, was that inorder to correctly evaluate the HMI in such a system the use of flight progress strips shouldbe excluded.

The IAA, on the other hand, is faced with the responsibility of providing a fully operationaland reliable system on schedule. The system requested from Airsys ATM will include fullflight progress strip facilities. System progression will be evolutionary rather thanrevolutionary, to avoid the sudden change to a stripless environment which could proveextremely problematic. Use of strips during the simulation will assist in the determination ofthe projected time-scale for possible migration to a fully automated stripless system.

To meet the needs of the client and EEC, the simulation was divided into two phases. Thefirst phase aimed at gathering subjective feedback from the participating controllers on theusability and operational suitability of the CAIRDE 2000 system as simulated with flightprogress strips. In the second phase, the EEC provided an enhanced automated systemthat enabled the controllers to evaluate possible future developments to the system.

Phase I simulated full flight progress strip functionality but did not include Medium TermConflict Detection (MTCD) and Conflict Risk Display (CRD). Co-ordination was bytelephone and no co-ordination In/Out windows were provided.

Phase II simulated Medium Term Conflict Detection (MTCD) and Conflict Risk Display(CRD). Full SYSCO Co-ordination was provided with Message In/Out windows and co-ordination indications shown in the radar label, ELW and data lists. There were no flightprogress strips.

4.5.2. Controller FeedbackThe controllers were concerned as to the ergonomics of the CWP set-up (including strips) forthe new system. Current suites operate with a single radar display for the EXC and a flightprogress strip board for the PLC. In Dublin ACC the flight progress strip boards aredesigned to geographically represent the control area.

The CAIRDE 2000 system provides radar displays for the Executive and Planningcontrollers. Difficulties exist in allocating suitable CWP working areas to cater for flightprogress strip and mouse pad needs. Keyboard requirements will further exacerbate thisproblem. In Shannon High-Level, the sheer volume of aircraft made it impossible tosectorise the strip board. The controllers found it impossible to keep the flight progressstrips up to date while simultaneously maintaining the electronic system. The consensuswas that the electronic system was preferable and easier to manage. Controllers found thatwhen they abandoned the strips it greatly improved the “in-suite” teamwork between theEXC and PLC. Indeed, in Phase II with SYSCO co-ordination and other addedfunctionalities, controllers stated that they were well able to manage without strips. In short,the use of flight progress strips was deemed not to be viable with the new system andmigration to a “stripless” environment should be addressed sooner rather than later.



EUROCONTROL

Despite having to overcome teething problems with regards to printing strips, errors in stripdetails and duplication of strips, the controllers worked extremely hard with the simulatedsystem. They were commended for their efforts to try to maintain both systems (electronicand flight progress strip) while safely handling long-term heavy traffic levels forecast for2007.

Regardless of these problems the controllers stated that it was difficult to handle more than10 aircraft while maintaining the flight progress strips and the electronic system. It becameimpossible to work radar labels, lists and strips at the same time. During the simulation, thePLC loaded the strips into the strip holders and boards. This took up valuable time andcaused a distraction from interaction with the system. In fact, the only way to keep strips upto date was for the PLC to ignore his radar display. All PLC’s preferred to maintain theelectronic system through the radar display rather than maintain strips.

Controllers felt that the Dynamic Flight Leg (DFL) function helped replace the planning roleof the strip board while appropriate sorting in the lists (SIL, SEL etc.) could suitably replacestrips. On the other hand, for tracking aircraft in holding patterns, caution was urged in theuse of Hold Lists as a replacement for strips until sufficient experience was attained andHold List functionality was fully evaluated.

In the simulation, the Shannon High-Level PLC did not perform many of the normal functionsrelated to oceanic separations, clearances, re-clearances and revisions. This importantaspect of operations will require further evaluation, particularly in terms of a striplessenvironment. However, experience gained during the simulation indicated that these safetyissues could be handled more efficiently by the electronic stripless system.

Whereas, the move to a paperless system may not prove too difficult, the controllers re-iterated their view that the electronic system must work well while providing user-friendlyinput with correct default values

4.6. DATA LIST WINDOWSIn the simulated IRL2000 ATM system tabular text data list windows were used to presentvarious types of lists and co-ordination messages that supplemented the radar data on allcontrol positions. The lists expanded dynamically in width as well as height (number of textlines) according to the defined fields and presented information.

4.6.1. General List ResultsController reaction to the various lists available was mixed. A slight majority felt that the textin the lists was easy to read but could be improved if the text used was ‘normal-underlined’rather than ‘bold’. The consensus was that selection of window size would be enhanced if ineach list (except for the Hold List), the Callsign field was the only mandatory field. This fieldshould be placed on the left, with all other fields optionally selectable. When lists wereclosed and subsequently re-opened they should default to the controller’s programmedpreference.

In two-man suites the PLC tended to spend more time watching the lists rather than theradar picture. Interaction with the lists proved more difficult as the level of traffic andsubsequent volume of list data increased. Although page lists occupy more screen spacethan scroll lists, problems were often encountered with essential flight data being hidden as aresult of the scrolling function.



EUROCONTROL

The number of displayed items in a list without having to scroll was satisfactory?

Graph 3: Displayed List Items

Ideally, lists should automatically sort from the top according to label state with an‘Assumed’, ‘Advance Warning’, ‘Concerned’ and ‘Unconcerned’ order of priority. A facility tomanually delete unrequired flights from the list would prove advantageous.

As the simulation progressed and controller experience increased, the tactical selection anduse of lists was noticeably enhanced.

4.6.2. Sector Inbound List (SIL)The Sector Inbound List was a tabular window containing data on all flights entering a sector.The main function of the SIL was to display flight data on aircraft before they were displayedin the radar window. The information presented in the SIL could provide entry flight databefore a track label was visible in the radar window. In Phase II of the simulation thisenabled the controller to initiate or respond to co-ordination before the track label wasvisible. This facility was also available in the Sector List (SEL).

Information for each pending flight was displayed as a single line (strip) with default sortingaccording to Entry Time (ETE), Entry Point (EPT), Departure Aerodrome (ADEP) andDestination Aerodrome (ADES). When an aircraft changed status from ‘Advance Warning’to ‘Assumed’ the information was deleted from the list. The strip was highlighted when theaircraft selected label was raised in the radar window, and inversely when the SIL line wasselected, the aircraft selected label was displayed on the radar window (and in any otherdisplayed list).

The SIL window automatically re-sized when new entries were added, however the windowstopped resizing and a scroll bar was provided when the list reached 7 lines. Individual SILswere placed at pre-defined default positions on the screen. The controller could thenreposition SILs to suit his/her personal requirements. The number of SILs requireddepended on the sector configuration. Sector Entry Points were often combined so thatflights entering through the same geographical border were displayed in one SIL (sorted byentry point).

4,76%

19,05%

19,05%

14,28%

42,86%

Strongly Agree

Agree

Slightly Agree

Disagree

Slightly Disagree



EUROCONTROL

Figure 9: Example of Sector Inbound List (SIL)

Optional fields such as XFL, XPT, ADEP, ADES, SI and ASSR could be selected ordeselected through the ‘Options’ pop-up menu. When optional fields were deselected theSIL compacted left, reducing the width of the displayed window.

4.6.3. Sector Inbound List ResultsThe controllers main conclusions and recommendations highlight the preference for a singlemandatory callsign field (in the SIL) with selectable options and a prioritised sorting systembased on aircraft label state. Shannon High-Level controllers found the SILs particularlyuseful with SSR code allocation for eastbound flows. Scrolling created some difficulties withregards to the display of relevant information. Dublin controllers did not use the SILs much.They considered them a useful facility but not a mandatory requirement and generallypreferred to interact directly with the radar label.

The information displayable in the SILs was appropriate?

Graph 4: Displayed SIL Information

For Shannon controllers, reaction differed as to the need for the information displayed in theSIL depending on whether the controller role was a planning or tactical one. Surprisingly,executive controllers favoured the need for the SIL information more than planningcontrollers. The reasons for this may be that the EXC often operated on a shorter range andtherefore did not always see the ‘Advance Warning’ aircraft. Secondly, many planningcontrollers preferred to use the SEL rather than the SIL, as it provided more optionalinformation including oceanic clearance data.

9 ,5 2 %

4 ,7 6 %

4 ,7 6 %

2 3 ,8 2 %5 7 ,1 4 %

S tro n g ly A g re e

A g re e

S lig h t ly A g re e

D is a g re e

S lig h t ly D is a g re e



EUROCONTROL

You don’t need the information in the SIL when acting as Planning Controller (PLC)?

Graph 5: SIL Information - PLC

You don’t need the information in the SIL when acting as Radar Controller (EXC)?

Graph 6: SIL Information - EXC

4.6.4. Sector List (SEL)The Sector List was a tabular window combining entry and exit data with other relevantinformation for ‘Advance Warning’, ‘Assumed’ and ‘Concerned’ flights through the sector.Information for each aircraft was displayed as a single line (strip) with default sortingaccording to Entry Point (EPT), Entry Time (ETE) and Planned Entry Level (PEL). The stripwas highlighted when the aircraft selected label was raised in the radar window, andinversely when the SEL line was selected, the aircraft selected label was displayed on theradar window (and in any other displayed list). Entry fields were subsequently deleted onAssume Control and the complete line was removed on sector exit.

The SEL window re-sizing functionality was similar to that previously described for the SILbut, in this case, scrolling did not commence until the list reached 10 lines. A large selectionof optional fields - see the Ireland 2000 Real-time Simulation System Handbook [Reference4] - could be selected or deselected through the ‘Options’ pop-up menu. When optionalfields were deselected the SEL compacted left, reducing the width of the displayed window.

14,29%

38,10%

4,76%

9,52%

14,29%

19,04%

Strongly Agree

Agree

Slightly Agree

Strongly Disagree

Disagree

Slightly Disagree

9,51%

14,29%

14,29%

14,29%

23,81%

23,81%

Strongly Agree

Agree

Slightly Agree

Strongly Disagree

Disagree

Slightly Disagree



EUROCONTROL

Figure 10: Sector List (SEL)

The display colour of the text for each flight reflected the label-state in Advance Warning,Assumed or Concerned colour, with information first displayed when the ACT was receivedfrom the previous sector. Entry fields were subsequently deleted on Assume Control and thecomplete line was removed on sector exit.

4.6.5. Sector List ResultsThe controllers re-iterated their preference for a single mandatory callsign field (in the SEL)with selectable options and a prioritised sorting system based on aircraft label state.Shannon controllers used the SEL window more than their colleagues from Dublin, who onceagain considered it useful but supplementary to their needs.

Shannon controllers highlighted sorting and scrolling as the main problems encountered withuse of the Sector List. Controllers sometimes had difficulty in finding aircraft in the SEL. Thedefault sorting provided was Entry Point (EPT), Entry Time (ETE) and Planned Entry Level(PEL). They suggested that the modification of these sort criteria to ETE, EPT and PELwould be more suitable.

Despite this measure, problems would still exist. Controller opinion was mixed regardingfurther sorting and scrolling methods. Sorting according to label-state provides advantagesand disadvantages particularly when scrolling is used. If, for example, ‘Assumed’ aircraftwere sorted to the top of the list, scrolling would hide some (or all) text lines of ‘AdvanceWarning’ aircraft that might not be visible on the radar window and also could be the subjectof co-ordination proposals.

A page list with no scrolling would be better but this has the disadvantage that the SEL canthen become extremely big and occupies a large area of the radar window. On the otherhand, the controllers do not require the display of ‘Concerned’ aircraft. This, in turn, wouldhelp reduce window size.

Another recommended improvement to the SEL was a further sorting facility for OceanicClearance Message (OCM) fields of Entry Point (EPT), Oceanic Flight Level (OFL) followedby Oceanic Entry Time (ETE).

Finally, although controllers could input to the system via the SEL instead of the radar labeltheir preferred method was via the radar label.



EUROCONTROL

Did you prefer the sector list as a means of input to the system instead of the radar label?

Graph 7: Input - SEL or Radar Label

4.6.6. Arrival and Departure ListsThe Arrival and Departures Lists were windows provided to Dublin and Shannon controllersto display flight data on aircraft landing at and departing from Dublin, Shannon and specifiedregional airports within the Shannon FIR. Each aircraft was displayed as a single list linecontaining relevant data. These lists functioned using the SEL principle, in that informationwas only deleted on sector exit (rather than as for the SILs, on Assume of Control).

The Arrival List contained specific information on arriving aircraft to each Aerodrome ofDestination (ADES) sorted by Entry Time (ETE), Planned Entry Level (PEL) and Entry Point(EPT). Data also included the allocated Standard Arrival Route (STAR), Cleared Flight Level(CFL), Aircraft Type/Weight category and an Estimated Time of Arrival (ETA) at thedestination aerodrome.

Figure 11: Example of Arrival List

The Departure List was sorted for each Departure Airport (ADEP) by Estimated Time ofDeparture (ETD), Exit Flight Level (XFL) and Exit Point (XPT). The list provided specificdata on the Standard Instrument Departure (SID), Cleared Flight Level (CFL), AircraftType/Weight category and assigned SSR code.

Figure 12: Example of Departure List

9 ,5 2 %

2 8 , 5 7 %

3 8 , 1 0 %

2 3 ,8 1 %

R e g u la r ly

S o m e t im e s

R a r e ly

N e v e r



EUROCONTROL

4.6.7. Arrival and Departure List resultsThe controllers had different views as to the usefulness of the Arrivals and Departure Lists.36% of the controllers stated that the Arrival List was never useful, whereas only 5%indicated a similar opinion for the Departure List. The Departure List was more widelyaccepted and considered far more useful with 63% of the controllers stating that they alwaysor regularly used it compared to 36% in the case of the Arrival List. Interestingly, not a singlecontroller indicated that he/she felt that the Arrival List was rarely useful

Was the Arrival List Useful?

Graph 8: Use of Arrival List

Indeed, 75% of the controllers stated that they rarely (65%) or never (10%) used the arrivallist as a means of input data to the system. One should note however, that use of the ArrivalList was mainly by busy approach or TMA sectors where surveillance of and interaction withthe radar label was invariably more intensified.

Was the Departure List Useful?

Graph 9: Use of Departure List

The controllers were reasonably pleased with the sorting specifications for the Arrival andDeparture Lists but recommended some improvements. They stated that in the Arrival Listan ‘Assumed’, Advance Warning’ and ‘Concerned’ label–state sort order would be betterwhile the Tower sequence for Departures should automatically update the sequence in theDeparture List.

3 1 ,5 8 %

3 1 ,5 8 %

1 0 ,5 3 %

2 1 ,0 5 %

5 ,2 6 %

A lw a y s

R e g u la r ly

S o m e t im e s

N e v e r

R a re ly

1 0 ,5 3 %

2 6 ,3 2 %

2 6 ,3 2 %

3 6 ,8 3 %

A lw a y s

R e g u la r ly

S o m e t im e s

N e v e r

R a re ly



EUROCONTROL

4.6.8. Hold ListHold Lists were provided to Dublin (Area and Approach) and Shannon (Low-Level, TMA andApproach) controllers. Note that the Hold List provided during the simulation differed fromthe list proposed by Airsys ATM in that it included a dynamic sort on CFL. This function willonly be available through the Stack manager Window in the Airsys system.

The Hold List Window opened automatically when an aircraft was instructed to enter the holdand closed when the last aircraft was instructed to leave the hold. Input of instructions wasvia the Hold option in the Callsign menu. This displayed a pop-up to select ROKNA, TULSO,DINIL or NASRI (for Dublin) and FOY or SCARF for Shannon. During the simulation, an‘Assume-Hold’ modification was added to the Callsign menu. This greatly assisted thecontrollers, in terms of time and effort, to update the system when traffic levels were high.The information provided in the Hold List included a radar label display check-box, Callsign,AFL (Mode C plus trend arrow), CFL, Holding Point (HPT) and Expected Approach Time(EAT).

Figure 13: Example of Hold List

Hold list sorting was by HPT and CFL (PEL if Transfer-In). An aircraft could be removedform the Hold List via the ‘Leave Hold’ option on the Callsign menu (also accessible from theHold List and SEL).

4.6.9. Hold List ResultsThe Hold List was used extensively throughout the simulation by Dublin controllers.Shannon controllers used the functionality less as only two of the five simulatedorganisations included Low-Level operation. The Hold List proved to be very successful withthe vast majority of controllers stating that it was ‘Always’ or ‘Regularly’ useful.



EUROCONTROL

Was the Hold List useful?

Graph 10: Use of Hold ListThey found the Hold List to be both clear and simple. While indicating that they would likesimilar functionality in the CAIRDE 2000 system they recommended further modifications interms of both operational and sorting functionality.

Operational FunctionalityThe ability to put ‘Advance Warning’ aircraft in the Hold List would be useful for reservinglevels for aircraft cruising at flight levels below those currently occupied in a hold. This,however, currently creates difficulties with an electronic system as Advance Warning’ aircraftdisplay the PEL and not the CFL. The Hold pop-up menu should default to the holdsrelevant to the sector. Ideally, when an aircraft was below the minimum hold level the listshould only display the AFL.

Sorting FunctionalityThe scrolling facility (when 15 lines were reached) was not safe in that use of a single list forall holds (sorted by hold) often obscured vital data on aircraft in some holds. A separateHold List provided for each HPT and the removal of the scrolling facility would rectify thisproblem. The primary sort key should be on CFL followed by a secondary sort key for AFL.Thus, if two or more aircraft had the same CFL the secondary sort would ensure that aircraftwould sort by AFL.

30,00%

10,00%

10,00%

50,00%Always

Regularly

Sometimes

Never



EUROCONTROL

5. RESULTS - OBJECTIVE 2

CONTROLLER INTERFACE (HMI) EVALUATION

Assess the operational impact of the new system ATC Tools, Safety Nets andMonitoring Aids

5.1. INTRODUCTIONThe simulated system supported the detection of Area Proximity Warning (APW), ShortTerm Conflict Alert (STCA) and Dynamic Flight Leg (DFL) display for aircraft routeprojection. Medium Term Conflict Detection (MTCD) with inherent Conflict and Risk Display(CRD) was provided for Shannon ATCC. At the request of Dublin ATCC, MTCD was notemployed as they considered it unsuitable for their TMA environment where the majority ofaircraft operate on climb and descent profiles.

5.2. AREA PROXIMITY WARNING (APW)Area Proximity Warning (APW) provided warnings on civil incursions into TemporarySegregated Areas (TSA) such as Military Activity Areas and Danger or Restricted Areas. A90-second look-ahead predicted the vertical and horizontal position of an aircraft, in relationto defined volumes of airspace and also recognised if a CFL value meant incursion wouldnot occur.

The warning was indicated to the controller by display of the letters APW in Yellow in Line 0of the track label. The warning was cancelled when the aircraft left the defined volume ofairspace.

Figure 14: Example of APW Display

5.2.1. APW ResultsAll controllers stated that the APW was very suitable. They felt that the yellow text was verynoticeable and coupled with the audio alarm expected in the CAIRDE 2000 system, theyanticipate that it will prove to be a very useful safety tool.

5.3. SHORT TERM CONFLICT ALERT (STCA)The Short Term Conflict Alert (STCA) feature was based on a projection of the aircraft radartrack (unlike the Medium Term Conflict Detection [MTCD], which used updated flight planinformation). A 90-second look ahead detected if two aircraft tracks would infringe a pre-determined separation minimum. STCA warnings were issued from the time the conflict waspredicted until finally resolved. STCA also took CFL inputs into account to reduce falsealerts. Again in all cases, if the CFL was broken (level bust) the warning would be re-applied.

In order to reduce the incidence of false alarms, the warning time was kept as short aspossible leaving sufficient time for a controller to take action. The in-built design of the



EUROCONTROL

STCA ensures operation at the last possible moment in a situation that the controller has notresolved.

The simulated STCA displayed a Red label-border around the label-block. In addition, theCallsign field was highlighted Red. The alert remained until the STCA detected that theconflict prediction and conflict no longer existed.

5.3.1. STCA ResultsThe vast majority of controllers agreed that the activation of the STCA always (67%) orregularly (24%) attracted their attention quickly. However, when asked about the suitabilityof the data-block display the response was far more critical.

When STCA was activated was data in the Label-Block legible?

Graph 11: Legibility of STCA Label Block

All controllers stated a dislike of the style of the STCA display. The Red border on the label-block was considered a distraction and unnecessary. The Red background highlight of theCallsign field was extremely difficult to read when the label was in the ‘Concerned’ (Mustard)state. Overlapping labels caused further ambiguity and frustration. Suppressed labels ofaircraft in Hold Lists did not display any STCA warnings.

The controllers put forward three major recommendations for STCA display characteristics.These were:

• The Radar Position Symbol (RPS), Label lead line, Speed Vector and History Dotsshould all display in Red.

• The RPS should always remain visible.• The text of Callsign, AFL and Sector Indicator (SI) fields should always appear in White

with Red background highlight.

5.4. DYNAMIC FLIGHT LEG (DFL)The Dynamic Flight Leg displayed the aircraft route from the current radar track position untilthe end of the flight, as a solid green line with conflict sections marked in red. Forecasttimes at waypoints were displayed adjacent to each point. It was possible to have the DFLdisplayed for more than one aircraft simultaneously.

The controllers use of the Dynamic Flight Leg during the simulation indicated that it waspotentially a very useful element of the HMI package. While not used much in Dublin’s TMA,it was used extensively in the larger airspace of Shannon ATCC. The Dynamic Flight Leg

28,57%

4,76%

66,67%

Always

Regularly

Sometimes

Rarely

Never



EUROCONTROL

was employed as the primary tool for providing route, sector sequence and conflictinformation when the controllers were handling high traffic levels and reference to other toolsand lists became difficult.

5.4.1. Dynamic Flight Leg ResultsThe DFL received strong support from those controllers that used it. They considered it tobe a very powerful tool, particularly when used in conjunction with MTCD where it should beselectable from the Conflict and Risk Display (CRD). The colours used were considered tobe quite good but some controllers felt that the thickness of the display lines should bereduced. Controllers stressed that the DFL should be updated when the DCT function wasused.

5.5. CONFLICT AND RISK DISPLAY (CRD)The Conflict and Risk Display (CRD) was a display element of the Medium term ConflictDetection (MTCD) function during the simulation.

In an ATCC employing paper flight progress strips, the calculation and notification of futureconflicts can be carried out by a controller, following comparison of reporting point estimatesand flight levels for each aircraft crossing the sector. The calculation can be made inadvance of the aircraft track being displayed on the radar screen, once flight information isreceived and recorded on the flight progress strips.

In the advanced 'stripless' environment simulated in Phase II, the calculation of futureconflicts was replaced by the MTCD function. This information was then notified to thecontrollers through indications on the Dynamic Flight Leg (DFL) and in the Conflict and RiskDisplay (CRD).

The functionality and display characteristics of the CRD for Planning and Executivecontrollers is explained in the Ireland 2000 Real-time Simulation System Handbook[Reference 5].

Figure 15: Conflict and Risk Display

The CRD could be displayed (on or off) by selection of the CRD pilot button in the Radartoolbox.

The MTCD logic replaced the reporting point estimates used to forecast the progress of eachflight with a calculation using the horizontal element of the aircraft trajectory. When twoaircraft were forecast to infringe a pre-determined separation distance, the horizontal conflictwas further assessed to determine if vertical separation was also infringed.The vertical analysis used values known to the system such as AFL and CFL to determine ifthe conflict was 'real'. If the planning levels for a conflict pair overlapped, the result wasconsidered to show a 'risk of conflict'. The risk was used to assist the controller in planningthe evolution of the two flights from planned sector entry level (PEL) to sector exit level(XFL).



EUROCONTROL

A warning was determined to be a RISK if, Routes crossed and Level Bandsoverlapped as defined below:Before Assume ofControl:

The lowest of AFLPELXFL

The highest of AFLPELXFL

After Assume ofControl:

The lowest of AFLCFLXFL

The highest of AFLCFLXFL

A warning was determined to be a CONFLICT if, Routes crossed and LevelBands overlapped as defined below:Before Assume ofControl:

The lowest of AFLPEL

The highest of AFLPEL

After Assume ofControl:

The lowest of AFLCFL

The highest of AFLCFL

Figure 16: Parameters used for Conflict and Risk Warnings

Conflicts were indicated in red and risks were indicated in yellow. The display could also befiltered to remove the display of risks. Following controller recommendations from previoussimulations (and in line with the concept of MTCD as a planning tool), the display of conflictsinvolving 2 assumed aircraft under the responsibility of the Executive controller, could alsobe suppressed, greatly reducing the number of conflicts presented.

MTCD was provided in Shannon Airspace based on two defined volumes of airspace. Noteagain that Dublin ATCC opted not to employ MTCD as they considered it unsuitable for theirTMA environment where the majority of aircraft operate on climb and descent profiles.

Volume 1The limits of the Shannon UIR/FIR, West of 13W and South of 50N.

Volume 2The limits of the Shannon UIR/FIR, East of 13W and North of 50N, excluding ShannonApproach (APP).

The MTCD minimum horizontal separation parameter was 15nm in Volume 1 and 8nm inVolume 2. The greater separation defined in Volume 1 took account of the degradation inradar coverage west of the 13W line of longitude and south of the 50N line of latitude. Theminimum vertical separation for both volumes was 1000 ft.



EUROCONTROL

5.5.1. Conflict and Risk Display ResultsThe CRD tool forms one element of the overall MTCD function presented to the controllers.Three elements of the MTCD function are currently being developed and are necessary forthe tool to prove an effective controller aid. The accuracy of the aircraft trajectory must beassured as it forms the basis for the computation. The tasks for Executive and PlanningControllers using the MTCD tool must be correctly distributed and finally the requirement forinformation displayed to the Planner and Executive must be suitably defined.

An evaluation of the Conflict Risk Display also includes an evaluation of the other elementsthat make up the complete MTCD function. Although the simulation did not attempt an in-depth investigation of each of the separate MTCD elements, useful information was gainedthrough controller feedback that will aid the further development of Medium Term ConflictDetection.

Did you find the CRD tools useful to identify conflicts and risks in your sector?

Graph 12: CRD Tools Usefulness

Overall, the controllers supported the use of the CRD, although with reservations. All butone of the controllers found the tool ‘regularly or ‘sometimes’ useful. The Shannoncontrollers stated that the MTCD feature would be very useful for planning support in High–Level sectors. It could prove useful in Low-Level sectors but would be unusable in the TMA.An important requirement for the tool is that controllers have confidence in the conflictpredictions made. When asked if they ever had problems with the accuracy of conflict andrisk detection in the MTCD tools 36% indicated that they ‘regularly’ did while 43% stated thataccuracy problems ‘sometimes’ existed. Comments indicated that there were manyinstances where too many false risks were shown. As a result, in high workload situationsfrustration and confidence were affected, and the CRD window was ignored. As mentionedearlier in this report, sometimes when aircraft had been given DCT the updated DFL was notupdated in the MTCD feature. Controllers stressed the need to check the informationpresented, supporting the view that improvement in the accuracy of information (andupdating) will be required.

37,00%

7,00%

56,00%

Sometimes

Regularly

Rarely



EUROCONTROL

Were there ever problems with the accuracy of conflict and risk detection in the MTCD tools?

Graph 13: MTCD Tools Accuracy

On the positive side, the majority agreed that all of the appropriate information concerningrisks and conflicts was ‘always’ or ‘regularly’ available in the MTCD tools. Some controllersfelt that the presentation of time and separation was not always easy to understand buttraining and experience should overcome this. Indeed, the majority also felt that the CRDdid reduce their workload and assisted them in better prioritising their tasks.

Did the CRD help you to prioritise conflicts and risks?

Graph 14: CRD Priority

Most controllers identified some instances where the system failed to predict risk and/orconflict situations. However, they agreed that with improvements in the accuracy of thedetection, task allocation and information display, the tool should achieve better acceptanceand may prove to be a powerful aid to assist controllers to handle the increasing trafficvolumes forecast for the future.

36,00%

21,00%

43,00%

Sometimes

Regularly

Rarely

33,00%

7,00%

7,00%

53,00%Sometimes

Regularly

Rarely

Never



EUROCONTROL

Were there risk or conflict situations the system failed to predict?

Graph 15: CRD Prediction Failure

The majority agreed that interaction with the MTCD tools was ‘regularly’ (50%) or‘sometimes’ (21%) logical and easy. This will no doubt improve after longer experience withthe system. However, the controllers pointed out that due to the fact that the CRD was atabular display only, it was not possible to select affected labels from it. They recommendedthat the ability to interact with labels through the CRD would assist in the reduction ofcontroller workload.

In general, the Planning Controller in a suite handled responsive action to MTCD warnings.Some suites preferred, through in-sector EXC/PLC co-ordination, to share the responsibility.Nevertheless, in all except one of these cases, the resolution action was mainly taken by thePLC. PLC feelings concerning the question of whether the CRD reduced workload wasmixed, but as mentioned in the previous paragraph, they believe the system can beimproved.

As a PLC, did you feel that using the CRD reduced your workload?

Graph 16: CRD – PLC Workload Reduction

5.5.2. Situational AwarenessOne issue associated with controller operation of new planning tools such as MTCD is theeffect their usage may have on situational awareness, and indeed, the follow-on impact onsafety. Clearly it is important to ensure that controllers maintain an appropriate situationalawareness for the conduct of their activities.

8,00%

38,00%

8,00%

46,00%

Sometimes

Regularly

Rarely

Never

7,00%

29,00%

29,00%

28,00%

7,00%

Always

Sometimes

Regularly

Rarely

Never



EUROCONTROL

Controllers (particularly the PLC’s) had to quickly adapt to new operating procedures whileresponding to MTCD warnings. The tool provided early warnings on potential conflicts butquite often the aircraft affected were outside the radar range selected. Planners had to learnto adjust to variable selection of radar range to efficiently utilise the MTCD feature. Thissometimes caused confusion over the situational timeframe in which they were working.They commented, however, that as a planning tool the MTCD enhanced conflict-handlingcapability provided a suitable replacement for flight progress strips.

In effect, the controllers considered that their situational awareness was not significantlyaffected.

When using MTCD did you manage to maintain a degree of situational awareness that youdeemed necessary?

Graph 17: MTCD Situational Awareness

In fact, the majority stated that MTCD tools ‘improved’ (43%) or had ‘no impact’ (21%)whatsoever on their situational awareness.

The controllers remained divided over the question of whether safety was impacted by a lackof situational awareness.

Did you feel safety was impacted by a lack of situational awareness?

Graph 18: MTCD SafetyHowever, as situational awareness was not significantly affected and indeed, in some casesimproved, safety concerns are slight, particularly as proper training before implementationshould ensure sufficient experience.

21,00%

7,00%36,00%

36,00%

Always

Sometimes

Regularly

Never

36,00%

21,00%

43,00%Sometimes

Rarely

Never



EUROCONTROL

6. RESULTS - OBJECTIVE 3CONTROLLER PROCEDURES

Evaluate the potential roles of Executive and Planning Controllers in the simulatedsystem

6.1. INTRODUCTIONPrior to the simulation the IAA carried out a controller task allocation project to assist in thedetermination of on-suite task distribution between Executive (EXC) and Planning (PLC)controllers. These tasks were based on current operating practises in Shannon and Dublinair traffic control centres. To further assist in the assessment of task distribution between theEXC and PLC the EEC provided an example of suitable roles based on experience gainedfrom other real-time simulations using similar automated systems. These roles were asfollows:

Sector entry – before the entry of the flight into the sector

Planning Controller• Verifies entry conditions for each new flight (SIL, SEL).• Detects potential conflicts at entry to sector - uses MTCD & extended flight legs.• Resolves those conflicts as required (modification of PEL).

Executive Controller• Reads the new FPL element displayed in SIL, SEL.• Is responsible for any SKIP initiation.

Flight within the sector

Planning Controller• Monitors the sector frequency and assists the Executive controller to detect and resolve

conflict situations - uses MTCD & extended flight legs.• Assists the Executive controller with co-ordination accept, reject or counter proposal in

Message-In window - uses telephone if required.

Executive Controller• Is responsible for Assume input (on first R/T contact).• Is responsible for radio communication with pilots.• Is responsible for providing the required separation between aircraft.• Is responsible for conflict detection and resolution.• Is responsible for tactical co-ordination radar to radar with adjacent sectors - uses

telephone if required.• Is responsible for CFL, ahdg, arc, asp, input orders.

Before the aircraft exits the sector

Planning Controller• Determines, in co-operation with Executive controller, sector exit conditions - is

responsible for XFL input.

Executive Controller• Is responsible for ensuring that exit conditions are achieved.• Is responsible for Transfer input.The task definition was based on the premise that the Planning Controller's mainresponsibility was “Advance Warning” or pending flights, while the Executive Controller'sprime responsibility was 'Assumed' flights. However, the task description did not restrict



EUROCONTROL

team co-operation and either controller was free to assist the other as required. Bothcontrol positions were identical in technical functionality, allowing the sector team (EXC andPLC) to evolve other working methods and re-distribute the sector tasks if desirable. Taskdivision was not a factor for the single manned sectors.

The combination of the above task allocation scenarios provided a yardstick which assistedthe participating controllers in the collection of valuable feedback on a proposed distributionof Executive and Planning controller roles. As the controllers had unanimously agreed thatthe PLC could not manually update strips and correctly refresh the electronic systemsimultaneously, the results derived were based on a no-flight progress strip environment.

6.2. CONTROLLER ROLE RESULTSThe controllers stated that the functionality of each control position should be identical toenable the controllers themselves to create an appropriate task division and not have oneimposed by the system. This also allowed them to modify the task division when trafficlevels increased or decreased. They did feel that the PLC and EXC were able to worktogether as a team and generally agreed that the defined roles permitted this teamwork.

Did you consider that the PLC and EXC were able to work together as a team in themanagement of the sector?

Graph 19: PLC/EXC Teamwork

Although the roles of the PLC and EXC were reasonably well defined, the task allocationbetween Planning Controller and Executive Controller was not always clear. This may havebeen a result of allowing too much flexibility in the system configuration, or a result of theshort simulation period in gaining familiarity with the roles. While some versatility wasincorporated to allow for a distribution of workload, some actions (e.g. CFL input) althoughconsidered the key responsibility of one controller, were often shared between the two sectorcontrollers. The impact of this indistinct task allocation was minimal although confusion overindividual responsibilities occasionally surfaced.

The case for such inter-operability was discussed during the debriefing sessions. Thecontrollers were divided on the procedure that should apply for 'CFL input' and 'AssumeInput'. Some controllers stated that only the Executive Controller should make these inputs.

22,00%

13,00%

65,00%

Always

Sometimes

Regularly



EUROCONTROL

At issue was the amount each input contributed towards maintaining the 'radar picture' andwhether sharing of these tasks meant a degradation of the Executive Controller's situationalawareness and control.

Further consideration is recommended before placing any restriction on the systemfunctionality. Any limitation may be implemented using controller procedures therebyallowing flexibility while the implications are fully evaluated.

Were you unclear as to whether certain tasks should be performed by the PLC or the EXC?

Graph 20: PLC/EXC Task Allocation

All controllers agreed that the implementation of the new ATM system technology wouldresult in a change of role assignments between the Executive and Planning controllers.

Subjective debriefing sessions led to the following conclusions and recommendations.

4,00%

60,00%

18,00%

18,00%

Always

Sometimes

Regularly

Rarely



EUROCONTROL

Dublin ATCC

The Dublin controllers were unanimous in their opinion that the EXC should continue toprovide the radar service while the PLC would electronically interface with and update thevarious windows and text lists that will eventually replace the flight progress stripmanagement functions currently in use.

Controller roles will require further review and critical assessment when the finalconfiguration of the proposed system has been determined.

Photo 3: Example of Dublin ATCC Controller Working Positions (CWP)

Shannon ATCC

The Shannon controllers devised specific sets of duties for the EXC and PLC positions. Theon-suite position of EXC and PLC was not considered relevant for the automated paperlessenvironment.

The Executive controller should:

• Assume aircraft.• Interact with the CFL on giving clearance.• Transfer aircraft.• Handle most of the R/T.• Interface with XFL in ‘Advance Warning’ blue label.



EUROCONTROL

The Planning controller should:

• Interact with the PEL.• Use the DCT function.• Handle some of the R/T.• Co-ordinate by telephone (when required).• Interface with the XFL in the ‘Assumed’ white label.• Manage the SEL and check oceanic clearances.

The Planning controller should manage most Window and List operations (such as SEL, SIL,CRD, Message-In, Message-Out, ARR, DEP and Hold).

However, the Executive controller could also use the SIL at times (e.g. first sector in aneastbound oceanic flow) and could interface with other windows (e.g. Referred CRD) whenrequired.

Photo 4: Example of Shannon ATCC Controller Working Positions (CWP)



EUROCONTROL

7. RESULTS - OBJECTIVE 4CO-ORDINATION

Assess the operational impact of System Supported Co-ordination (SYSCO)7.1. INTRODUCTION

Flights that are provided with an ATC service are transferred from sector to sector and fromone ATC unit to the next, in a manner designed to ensure safety. In order to achieve this,data on the sector (or ATC unit) boundary is co-ordinated in advance. Control of the flight isthen transferred when it is at the boundary. Where this communication is carried out bytelephone, the passing of data on individual flights is a major support task, particularly atArea Control Centres.

The operational use of connections between Flight Data Processing Systems (FDPS), for thepurpose of replacing such verbal messages, referred to as On-line Data Interchange (OLDI),began within Europe in the early nineteen-eighties.

Common rules and message formats for implementation were agreed and incorporated inthe EUROCONTROL Standard for On-line Data Interchange Edition 1, which wassubsequently revised as Edition 2. The upgrade from OLDI Edition 1 to Edition 2 is generallyknown as System Supported Co-ordination (SYSCO).

7.2. IRL2000 ENVIRONMENTThe assessment of SYSCO during the simulation was split into two separate phases. Thefirst phase assessed co-ordination by telephone while the second phase assessed a moreautomated system without the use of flight progress strips.

The full specifications for each phase are provided in the Ireland 2000 Real-time SimulationSystem Handbook [Reference 5].

The co-ordination environment provided in the IRL2000 simulation differed in each phase.

The first phase involved a flight progress strip environment supported by electronic co-ordination before transmission of the ACT message. After transmission of the ACT messageco-ordination was by telephone.

The second phase supported full electronic co-ordination between all sectors and centreswithout the use of flight progress strips.

For each flight an Activation Message (ACT) was transmitted 15 minutes prior to the sectorexit boundary, with all revisions after this treated as 'Referred Revisions', in that they had tobe agreed by both controllers. The system supported Planned Entry Flight Level (PEL), ExitFlight Level (XFL) and Direct (DCT) co-ordination as well as Transfer of Control and Requeston Frequency (ROF) messages.

Co-ordination was possible to 'propose', 'counter-propose' or 'reject' a proposal. Messageswere displayed in the Co-ordination Windows and also coded into the track label and listHMI.


EEC Report No. 366

EUROCONTROL

Correct sector sequence and co-ordination partners were determined from the aircrafttrajectory, which was modified following the controller input of data. If a controller input anew XFL or DCT, this updated the aircraft trajectory (and formulated a new sector sequenceif required).

F

7.2.1. Electronic Co-Input of a new Xsector. When agare superposed between the twowas required. Filevel (FL355) forflight was treated

Regularly the ruconstruct an aircHowever, in theimmediately rathand construct the

The problems asShannon 3 (SH3

If for example, Sthe aircraft wasimmediately' (Ex

Sector SH2

49

igure 17: Co-ordination Horizontal Sector Boundary

ordination in the Vertical PlaneFL value (after ACT) was displayed as a PEL co-ordination at the next

reed the new value would update the aircraft trajectory. When two sectorssuch as Cork 1 (CK1) and Super F (SPF) were in IRL2000, the boundary sectors is found in the vertical plane. For these cases, special functionalityrstly the display of XFL/PEL becomes problematic. Displaying the boundary all aircraft was not operationally suitable; therefore the target level for the as the XFL/PEL value.

le, 'Climb as soon as possible, descend as late as possible' is used toraft's trajectory, as it represents the most economic profile for the aircraft. vertically split sector environment, the new XFL value must be applieder than at the end of the sector, to correctly reflect the profile of the aircraft new sector sequence.

Figure 18: Co-ordination Vertical Sector Boundary

sociated with vertically split sectors were increased with the superposing of) over both North Low (NLO) and South Low (SLO).

hannon 3 (SH3) proposed a new XFL for descent to South Low (SLO), while still flying over North Low (NLO), the agreed XFL value was 'appliedample A) updating the trajectory and bringing North Low (NLO) 'incorrectly'

OriginalPEL

OriginalXFL

ProposedPEL

ProposedXFL

Sector BR3

ProposedPEL 290

Boundary Level F355

ProposedXFL 290

Sector SPF

Sector CK1


50

EUROCONTROL

into the sector sequence. If the XFL was applied 'as late as possible' (Example B) then co-ordination was possible with South Low (SLO). However in this case, Shannon 3 (SH3) wasnever able to propose a descent to North Low (NLO).

Figure 19: Co-ordination Super Sector with Vertical Boun

NoteThe client team reduced occurrences of this problem during the simulapredefined sector sequence and by assuring in as far as possibconfigurations did not include a sector superposed over two or more problems related to superposing one sector over two or more sectoconfiguration will prove far more difficult to resolve.

7.2.2. Electronic Co-ordination in the Horizontal PlaneAs with controller inputs in the vertical plane, DCT inputs in the horizoncalculation of the trajectory. As co-ordination takes place betwepartners, this could have the effect of bringing other sectors into the seconsent or option of refusal. In order to reduce this risk and to ensureroute changes always took place, several rules were imposed on the D

The DCT input could be made to points within the current sector at aDCT to points in the next sector could only be made if an Activationbeen sent, therefore ensuring the DCT was treated as a 'Referred Rapproval of the next sector. If no ACT had been sent this could bscheduled time from the Callsign Menu (Force ACT). When the DCT inof the flight into a sector that was not originally in the predefined screating a new next sector, no co-ordination was required and the oriabrogated.

7.2.3. Co-ordination InterfaceTwo windows were provided to enable co-ordination messages to be seMessage-Out (co-ordination out) window displayed messages sent toMessage-In (co-ordination in) window displayed messages receivedawaiting a response. The windows were only displayed when a messresized to display additional messages. Messages were sorted in time message at the top.

Boundary Level F245

XFL 230Example A Sector SH3

Sector NLO Sector SLO

XFL 230Example B

EFL 230
EFL 230
EEC Report No. 366

daries

tion by maintaining ale that sectorisation

sectors. In reality, thers in a vertically split

tal plane caused a re-en two co-ordinationquence, without their that co-ordination of

CT functionality.

ny time. However, a Message (ACT) hadevision' requiring thee initiated before theput placed the profileector sequence, thusginal next sector was

nt and received. The others sectors. The from other sectors,age was present andorder with the earliest



EUROCONTROL

Figure 20: Example of Message-Out Window

The Co-ordination windows allowed changes for flights to be proposed. Proposals could beaccepted or rejected and if necessary counter-proposals could be sent. Co-ordination waspossible on Planned Entry Flight Level (PEL), Exit Flight Level (XFL) and Direct (DCT)requests.

Figure 21: Example of Message-In Window

Proposed data (XFL/PEL) sent to and received from other sectors was displayed in pink toassist the controllers in identifying which co-ordinations were awaiting a response. A co-ordination message was displayed in the Co-ordination window, with the data element alsoshown in the track label and other lists (i.e. SIL/SEL/ARR/DEP) in the appropriate (pink) co-ordination colour.

7.3. CO-ORDINATION RESULTS7.3.1. Phase I

The co-ordination specifications In Phase I, where flight progress strips were used, werelimited in terms of SYSCO functionality. In effect, no Message In/Out windows wereprovided. New values reflecting changes (e.g. XFL, DCT) entered before ACT transmissionwere shown in the normal aircraft state colour. After ACT transmission co-ordination was bytelephone. Flight strips were also updated to reflect the agreed changes. Updates in theelectronic system were displayed in ‘Green’ in the downstream sector’s label and lists. Thedownstream sector could acknowledge the co-ordination proposal and no counter proposalwas possible.

From Day One of the simulation it was obvious that planning controllers would experiencesevere difficulty with co-ordination in that in proved extremely difficult to simultaneouslyupdate the flight progress strips and electronic system while also coping with heavytelephone usage. This problem was further exacerbated when traffic was increased to long-term future traffic levels.

7.3.2. Phase IIPhase II provided full SYSCO functionality. Message In/Out windows were provided.Counter-proposal of co-ordination proposals was possible. However, the response to acounter-proposal was limited to either ACCEPT or REJECT. A REJECT was followed by atelephone explanation. All co-ordination proposals and counter-proposals were displayed in‘Pink’ in the labels, lists and Message In/Out windows.

When the full SYSCO functionality was provided the controllers stated that they were wellable to manage without flight progress strips. Dublin controllers opted not to use SYSCO asthe preferred to communicate by voice and/or intercom. They considered this method to bemore suitable in terms of speed and user-friendliness to their dynamic approach and shared



EUROCONTROL

airspace environment. They noted however that inter-sector transfers initiated in error couldnot be undone. This problem proved extremely frustrating and will need to be addressed inthe future system.

The Shannon controllers found SYSCO to be extremely useful with the majority (75%)agreeing that the Message In/Out windows were important for understanding co-ordinationinformation. The vast majority (83%) stated that detailed information on inbound aircraft wasalways available in reasonable time. While they considered that the presentation of co-ordination information in the track labels was reasonably clear and unambiguous, theyrecommended that different co-ordination colours should be used to differentiate betweenco-ordination in and co-ordination out. Our experience from previous simulations concurswith this. Indeed, this recommendation was further highlighted by the fact that 88% of thecontrollers preferred to co-ordinate via the data label rather than the Message In/Outwindows.

Over 70% stated that the electronic transfer was preferable to the current systemmethodology and that the transfer functions significantly reduced their workload comparedwith normal working practises. On the other hand while 70% agreed that the capability tohand-over a flight to the downstream sector and receive an acceptance reduced workloadcompared with manual methods, they also stated that the capability to only accept or reject acounter-proposal was a significant limitation. Indeed, in complex situations they felt it wasnot possible to effectively handle co-ordination electronically.

Co-ordination with adjacent sectors was effective with few problems encountered. However,co-ordination between vertically split sectors underlined several technical and operationalshortcomings.

The display of a 'Default XFL' value for flights climbing from a High-level sector to a Supersector or descending from a Super sector to a High-level was discussed at length. If a‘Default XFL’ higher than the lowest level in the Super sector (for climbing traffic) or lowerthan the highest level in the High-level sector (for descending traffic) was used this allowedcontrollers to climb or descend aircraft to these levels without co-ordination and withoutknowledge of other conflicting aircraft.

The controllers recommended that for co-ordination the ‘Default XFL’ should be the first levelof the receiving sector (in order to trigger the ‘Advance Warning’ label state for that sector.This should be followed up by telephone co-ordination to confirm acceptance. Acceptanceof co-ordination should imply clearance to climb or descend. Subsequently, all climbs andtransfers should be immediate.

Careful sector design will be required to avoid flights clipping small segments of adjacentairspace and to allow standard DCT routes to be applied without generating sector sequenceanomalies. While large sectors with straight-line boundaries are preferred, sector designmust also accommodate traffic flows and sector capacity limitations, sometimes inhibitingideal design.

Although the provision of vertically split sectors in the IRL2000 simulation raised severalpertinent issues; the controllers strongly supported the use of system supported electronicco-ordination. Comments from the controllers identified benefits such as greatly reducedtelephone communication, faster and more silent co-ordination, and a reduction in ATC taskload.



EUROCONTROL

8. RESULTS - OBJECTIVE 5AIRSPACE AND ATC PROCEDURES

Investigate further the findings of the fast-time study regarding airspace changes toboth Shannon and Dublin. Specifically to assess the operational impact of thefollowing changes:

• Re-sectorisation of Shannon ATCC - Low Level.• Re-sectorisation of Shannon ATCC - High Level.• Re-sectorisation of Dublin ATCC.• Use of one-man sectors in Dublin ATCC.• Introduction of an Arrival Manager system (MAESTRO) at Dublin ATCC.• Implementation of parallel runway operations at Dublin Airport.• Use of 3nm separation between aircraft on final approach to Runway 10R.• Use of new SIDS/STARS for State and regional airports.• Use of holding patterns at new positions 15nm on the final approach to Shannon.• Use of procedures for dealing with High Level traffic inbound to Belfast Airport.• Re-positioning of the DINIL and NASRI holds and the Dublin CTA western boundary.

8.1. INTRODUCTIONThe above Shannon / Dublin station specific objectives were derived from the results,conclusions and recommendations of an Airspace Model Simulation of Irish Airspace carriedout by the EUROCONTROL Experimental Centre between 1996 and 1997 – EEC Task No.F01 / EEC Note No. 20/97 [Reference 2]. The study evaluated the impact on controllerworkload of future sectorisation plans for the land area sectors (including Dublin) and alsothe impact of future traffic, procedures and equipment. The objective of the Fast-Time studywas the optimisation of ATM systems in Ireland so that the requirements of the users wouldbe met and that the anticipated growth in air traffic to 2001, in line with EUROCONTROLforecasts, would be catered for in the appropriate airspace structures and operatingprocedures.

The above listed objectives, simulated in five separate organisations, encompass widelyranging issues involving sectorisation configurations (including the Shannon / Dublininterface), manning levels, medium and long term traffic level forecasts. Furthermore,specific station objectives included ATC procedures, positioning of holding patterns, parallelrunway operations and Arrival Management (AMAN).

To facilitate the analysis of the objectives this chapter is divided into three main resultssections pertaining to:

• Shannon / Dublin Interface Results• Shannon Specific Objectives Results• Dublin Specific Objectives Results



EUROCONTROL

8.2. SHANNON / DUBLIN INTERFACE RESULTSThe Shannon / Dublin interface was simulated in Organisations A and B. The interface wasbased on the conclusions derived from the fast time simulation of Irish Airspace. In effect,the Dublin CTA was extended to 0730° West to provide an enlarged radar vectoring area forapproaches to Rwy10 at Dublin. The airspace between 0630°W and 0730°W from FL195 toFL245 was delegated to Shannon Low-level to facilitate their handling of traffic overflyingDublin transiting to/from Shannon, Cork and various regional airports.

Shannon controllers found that the delegated airspace was not sufficient and that increasedco-ordination was required to cope with transiting traffic, particularly when long term forecasttraffic levels were tested. Dublin agreed that increased co-ordination had been generatedbut emphasised their view that co-ordination was not required as both centres could see thetraffic and a review of current Letters of Agreement and inter-centre co-ordinationprocedures could easily resolve this problem.

Another aspect of the delegated airspace issue was the fact that Shannon felt that theairspace was only required by Dublin when Rwy10 was active whereas they regularlyrequired it for climb and descent of traffic. They considered that the use of delegatedairspace (not necessarily confined to the dimensions simulated) should be flexible and notspecifically or permanently assigned to either centre.

Dublin however, insists that the extension of their airspace to 0730°West (up to FL245) isnecessary to encompass the buffer areas of the new western holds of DINIL and NASRI.The ability to use these holds up to FL240 is considered vital to cope with long term trafficlevels, as already at current traffic levels, the eastern holds of ROKNA and TULSO areregularly being used (following co-ordination with LATCC) above their published limits.

It is important to remember that the problem of how to facilitate both Shannon and Dublin’srequirements was not resolved before the simulation. Therefore a compromise was reachedin that the requirements of Shannon Low-level were addressed in Organisations A and B,whereas Dublin’s requirements were tested in Organisations C, D and E, as Shannon Low-level was not being simulated.

Further evaluation and discussion of the delegated airspace issue is recommended beforeany final concrete decisions or conclusions can be drawn.

8.2.1. Use of procedures for dealing with High Level traffic inbound to Belfast AirportAll the controllers agreed that the procedures for dealing with High-Level traffic outboundfrom and inbound to Belfast Airport worked very well. In practice, Dublin climbed traffic toFL230 and released the traffic to Shannon High-Level for further climb. Shannon High-level,descended traffic inbound to Belfast to FL240 (level FL240 approximately 10nm south ofDublin VOR) and released the traffic to Dublin for further descent. No co-ordination wasrequired.



EUROCONTROL

8.3. SHANNON SPECIFIC OBJECTIVES RESULTSThese results assess the operational impact of re-sectorisation configurations in ShannonLow-level and Shannon High-level as well as procedures related to new SIDS/STARS forState and regional airports and revised positioning of holding patterns for Shannon airport.

Maps displaying the Shannon re-sectorisation configurations can be found in Annex I.

8.3.1. Re-sectorisation of Shannon ATCC – Low LevelApart from the delegated airspace issue related to the Shannon/Dublin interface,Organisations A and B concentrated on Shannon Low-level specific objectives.Sectorisation configurations simulated in turn, a single sector (LOW) and two sector(NLO/SLO) scenario in conjunction with a TMA and Approach (APP) sector. All offshoreairspace west of 1030° West was transferred to Shannon High-level.

Shannon Low (LOW)The handling of forecast medium-term traffic in the LOW sector during Organisation Aproved extremely difficult. Controllers felt that there was far too much traffic on thefrequency. Their ability to deal with the traffic volume was also impaired by the flight stripprinting and dissemination problems that existed throughout Phase I of the simulation. Theirconsensus was that there was no point in simulating LOW with long-term forecast traffic.They stated that there was a definite need for the two-sector configuration of NLO and SLOand they opted to focus their attention on further simulation of this, without using flightprogress strips.

Shannon North Low (NLO) and Shannon South Low (SLO)This two-sector configuration was simulated in Organisation B using both medium and long-term forecast traffic levels. This configuration worked quite well although some controllersidentified the possible need for another low level sector to cope with future traffic levelsanticipated for Cork and Waterford. A better solution to this problem could be to re-assessthe geographical dimensions of the NLO/SLO sectors and in particular re-locate the interfaceboundary between NLO and SLO further south. This, coupled with further evaluation of thedimensions of the proposed TMA sector and refined ATC procedures, should be sufficient.

All controllers stated that separate holds (FL150 and upwards) would be required for NLOand SLO to cope with situations when the TMA hold was full. They also recommended thatthe control of arriving and departing traffic to/from Kerry should be the responsibility of theTMA controllers.

In Organisations A (LOW) and B (NLO/SLO) the transfer of all offshore airspace west of1030° West to Shannon High-level worked very well and should be implemented.

Shannon TMAOrganisations A and B also assessed the implementation of a proposed TMA sector withinthe Shannon FIR. Following simulation, all controllers confirmed the necessity for a TMAsector while recommending various improvements in terms of design and operatingprocedures, as outlined below.

The geographical dimensions of the TMA should be re-assessed with defined Entry and ExitPoints structured to comply with current lower and upper ATC routes. The simulated designdid not allow much room to the east for manoeuvring aircraft. New ATC procedures will berequired for the interface between low-level and high-level sectors and the TMA. The designof new SIDS/STARS will need to comply with TMA entry/exit points for traffic departing fromand arriving to Shannon and the regional airports. STARS should be used in preference to



EUROCONTROL

radar vectoring as this could prove to be too complex. Radar co-ordination procedures willalso be required.

The controllers stated that the TMA should be manned by at least two controllers. The TMAhold should control all aircraft from the level above the transition level (TL) up to FL140. TheTMA planning controller should assign levels to the low-level sectors (NLO/SLO) when theybecome available. The TL and below should be under the control of the Approach sector.

As stated earlier, the TMA should control arrivals to, and departures from, Kerry.

Shannon Approach (APP)A single Executive Controller manned the APP sector for all exercises tested inOrganisations A and B. Long-term traffic levels quickly caused problems for APP with highR/T loading. Proper maintenance of the electronic HMI made it impossible to simultaneouslyuse flight progress strips, even with medium-term traffic levels. The controllersrecommended that the APP controller should be responsible for aircraft holding at the TL inthe simulated holds of SCARF (Rwy24 Active) and FOY (Rwy06 Active).

8.3.2. Use of holding patterns at new positions 15nm on the final approach toShannonIn Organisations A and B the Entry Fixes to the holding patterns (SCARF and FOY) wereinitially positioned at 15nm on final approach to runways 24 and 06 respectively. Thecontrollers quickly found these locations to be unsuitable due to the amount of label cluttergenerated on final approach. All the controllers agreed that the holds should be offset fromthe final approach paths and discussions resulted in numerous suggestions for suitably re-positioned sites. New locations were finally agreed siting SCARF at 5240°N 0820°W (southof the approach to Rwy24) and FOY at 5245°N 0924°W (north of the approach to Rwy06).These proved to be far better but not ideal. There was also wide support indicated for theavailability of two hold fixes for each runway (similar to the system used at Dublin),positioned each side of the final approaches.

8.3.3. Use of new SIDS/STARS for State and regional airportsSimplified SIDS and STARS for Shannon, Cork and the regional airports were specificallydesigned for the simulation. Full details of the SIDS/STARS used can be found in theIreland 2000 Real-time Simulation Facility Specification Part 1 – Operational Conduct andAnalysis [Reference 1].

The Shannon SIDS worked quite well. All controllers liked the fact that departure routeswere clear of arrival routes. The default levels applied proved suitable, removingunnecessary co-ordination. During the simulation, the Rwy24 SID for departures to Dublin(DUB2B) followed a left turn. When the NLO/SLO sectorisation was simulated controllersfelt that a right turn after departure would have been more suitable. The STARS simulatedwere based on the original positioning of the hold fixes on final approach. Following therepositioning of these fixes, it was not possible in the time available, to redesign the STARS.This meant that some aircraft on STARS did not behave as originally expected. Thecontrollers suggested that future SIDS/STARS should be designed with regards to therequirements of the NLO/SLO and TMA sectors. In effect, SIDS terminating at TMA exitpoints and STARS commencing at TMA entry points, would ensure that the sector sequencefor departing and arriving traffic was correctly addressed.

The regional airports SIDS/STARS generally worked very well. Controllers had no difficultywith aircraft departing from regional airports on an initial climb clearance to 5000 feet,without any prior co-ordination. Imminent departures from all airports were displayed in therelevant sector’s departure list. Arriving aircraft were descended to the TL (FL60) and



EUROCONTROL

transferred to the Ireland Domestic Feed Sector, when clear of departing traffic. Thecontrollers agreed that if the new system included on-line connections to the regional airportsand proper radar coverage was available, there should be no requirement for co-ordinationbetween Shannon and the regional airports. They, therefore, recommended thatSIDS/STARS should be developed for all regional airports.

8.3.4. Re-sectorisation of Shannon ATCC - High LevelThree Organisations (C, D and E) focused on different sectorisation configurations forShannon High-level. In brief, Organisation C simulated a westerly flow of oceanic traffic in asectorisation configuration encompassing the Shannon UTA and the northern portion ofSOTA airspace. Organisation D simulated an easterly flow of oceanic traffic in asectorisation configuration encompassing all SOTA airspace and the southern portion of theShannon UTA. Finally, Organisation E simulated a westerly flow of oceanic traffic in asecond sectorisation configuration encompassing SOTA airspace and the southern portionof the Shannon UTA.

Full details of the Shannon High-Level Sectorisations simulated can be found in the Ireland2000 Real-time Simulation Facility Specification Part 1 – Operational Conduct and Analysis[Reference 1].

The controllers found that the vertical sectors provided an excellent method of handling hightraffic loads on the same track and could prove essential when RVSM is introduced inEurope. The use of the Super sectors was also considered very beneficial. The level splitbetween the vertical sectors differed depending on the direction of the oceanic traffic flow. InOrganisations C and E (westerly flow) the level split applied was FL335, whereas FL355 wasused in Organisation D (easterly flow). There was not enough time during the simulation totest other variables for each organisation. Following detailed examination and analysis ofthe traffic samples the client selected the level splits for simulation in each organisation. Inreal operations the strategic selection of level splits between the vertical sectors could beadvantageous.

Sector design, an area much evaluated for Shannon Low-level, proved to be the mainproblem faced when simulating Shannon High-level. In this case however the problemswere related more to the HMI than the sector dimensions. At present, electronic systemshave great difficulty with vertical sectorisation plans in terms of trajectory prediction andcalculation of climb and descent profiles. This, in turn, can seriously effect sector sequencecomputation, thereby creating erroneous electronic co-ordination messages.

As mentioned in the previous chapter, these problems can be greatly reduced by carefulsector design that reduces clipping of sector segments and accommodates traffic flows.However, the sectorisation used in Shannon High-level, which is dynamically andstrategically modified to meet oceanic track requirements will prove extremely difficult toreplicate in the future system where the HMI emphasis is based on label state, colour, sectorsequence and SYSCO co-ordination.



EUROCONTROL

8.4. DUBLIN SPECIFIC OBJECTIVE RESULTSThese results assess the operational impact of re-sectorisation configurations in the DublinCTA as well as ATC procedures relating to SIDS/STARS, parallel runway operations, holdstack usage, arrival management and separation of aircraft on final approach to Runway10R at Dublin airport.

8.4.1. Re-sectorisation of Dublin ATCCThe Dublin strategy for re-sectorisation evaluation involved a step-by-step introduction ofnew sectors and ATC procedures. While Organisations A and B mainly focused on theShannon/Dublin interface, the Dublin sectorisation evolved from the present daysectorisation, in Org. A, to the introduction of a Departure sector (DEP) in Org. B. Furtherorganisations simulated other new sector combinations evaluating the introduction of a FinalApproach sector (FIN) and a western sector (ARW). Simplified SIDS and STARS werespecifically designed for use during the simulation. Medium and long-term forecast trafficwas tested using Runways 10L/28R with exercises concentrating on Runway 28L and 28Roperations. Please note that parallel runways do not currently exist at Dublin but wereconsidered to exist for simulation purposes.

Full details of the Dublin ATCC Sectorisations simulated can be found in Annex I and also inthe Ireland 2000 Real-time Simulation Facility Specification Part 1 – Operational Conductand Analysis [Reference 1].

Dublin Departure (DEP)The DEP sector, manned by a single Executive Controller, accepted departing aircraft fromthe Tower (TWR) feed sector. Operating within a 15nm radius of the airfield, the DEPcontroller climbed aircraft to the pre-defined default levels of FL90 (for non-jets) and FL110(for jets), transferring them to the relevant Area sectors when clear of arriving traffic.

Controller reaction to the introduction of the DEP sector was very positive. All agreed that itsignificantly reduced the workload currently experienced by Area sector controllers, withregards to the identification and handling of departing traffic. While co-ordination wasoccasionally required with the Approach sectors to resolve conflicts controllers disapprovedof the practice of routinely running departing jet aircraft to the markers (as opposed to3000ft.) before turning them, in order to avoid conflicts with arriving or own sector traffic.Consensus was reached regarding the suitability of the airspace, operating procedures andHMI. All controllers endorsed the appropriateness of the labels, Exit point information andpre-defined default levels.

Final Approach (FIN)The FIN sector, manned by a single Executive Controller, accepted traffic from the NorthHold Approach (APN) and South Hold Approach (APS) sectors and sequenced them for finalapproach, transferring them to the Tower (TWR) feed sector when appropriate. 3nmseparation was permitted (in all organisations) on final approach to Rwy28L (Rwy28R wasused solely for departures), due to the planned introduction of a rapid exit taxiway for Rwy28at Dublin airport. 5nm separation was used for approach to Rwy10R (Rwy10L was usedsolely for departures).

Controllers reaction to the introduction of the FIN sector was also positive but they stressedthat new procedures and more experience would be required to optimise it’s impact. Beforethe simulation, approach controllers had no previous experience in the application of 3nmseparation on final approach. They found it extremely difficult to apply this tight separationsuccessfully due to the limited dimensions of the airspace permitted for its use. The FINcontroller tended to take control of traffic further and further from final approach in order toclose gaps between aircraft departing from the holding stacks. Many controllers consideredthat the application of 3nm separation on final approach from 15nm to touchdown was too



EUROCONTROL

restrictive. Extensive training and experience will be required to perfect skills in theapplication of 3nm separation involving strict use of speed control and new workingprocedures. The controllers recommended a review of, and extension to, the airspacepermitted for application of 3nm separation.

Dublin West Area (ARW)The ARW sector, manned by a single Executive Controller, was introduced in Organisation Ein conjunction with the use of one-man sectors. Results are shown in the forthcomingsection assessing the impact of one-man sectors.

North Hold Approach (APN) and South Hold Approach (APS)In Organisations A and B, APN and APS operations mirrored normal procedures currently inuse at Dublin, apart from occasional co-ordinations when the DEP sector was introduced.Approach controllers co-ordinated verbally with Area controllers with regards to arriving andholding traffic and vectored aircraft on to the localiser for final approach to the runway in use.

In Organisations C, D and E the implementation of the FIN sector resulted in changes tocurrent practices in that both Hold Approach sectors co-ordinated verbally with the FINcontroller for arrival sequencing. Verbal co-ordination was preferred to telephone and/orelectronic co-ordination as the Hold Approach controllers sat each side of the FIN controllerwith their relevant Area controller positioned to their other side. The controllers consideredthe introduction of the FIN sector to be a reasonably easy transition from current practicesthat would improve with new working procedures and experience.

All controllers registered their satisfaction concerning the suitability of the airspace and theselection of FL110 as the default flight level.

Dublin North Area (ARN) and Dublin South Area (ARS)The ARN and ARS sector controllers fully supported the introduction of the DEP sector inthat (as mentioned earlier), it significantly reduced their workload related to the identificationand handling of departing traffic. There was consensus with regards the FL90 (non-jets) andFL100 (jets) default flight levels for departing traffic but some controllers felt that the defaultflight level of FL120 for arriving traffic was too restrictive. Inter-sector co-ordination with APNand APS was verbal whereas on the few occasions that co-ordination was required with theDEP sector, voice and telephone usage was half-and-half.

8.4.2. Use of one-man sectors in Dublin ATCC.Organisation E assessed one-man sectors. In effect, a third area sector – Dublin West Area(ARW), manned by a single Executive Controller was introduced to handle traffic from thenorth and west. The planning controllers were removed from the ARN and ARS sectorsleaving a configuration using one Executive Controller in each simulated sector. It must bestressed that simulation of one-man sectors was an effort to reduce workload by spreading itevenly between three as opposed to two executive controllers. It should not be seen in anyway as an attempt to reduce the required staffing at Dublin ATCC.

Full details of the one-man sector configuration simulated in Organisation E can be found inthe Ireland 2000 Real-time Simulation Facility Specification Part 1 – Operational Conductand Analysis [Reference 1].

The ARW sector took all traffic previously handled by ARN (except for flights on the B1 andW911D), and all traffic previously handled by ARS (except for flights on the R14 and B39).ARW controlled both western holds (DINIL and NASRI), transferring arriving traffic to boththe APN and APS approach sectors. Controller first impressions were that the ARW sectorworked quite well, alleviating workload in the busier ARN and ARS sectors. However, furtherexamination of how to handle simultaneous northbound overflights on the UP600 and UR14



EUROCONTROL

will be required. The interface between ARW and all adjacent sectors of Shannon andDublin will also need further investigation.

Organisation E also introduced new parameters including re-designed SIDS and STARSlinked to a Four-Quadrant Hold scenario as well as parallel runway operations for Rwy28Land Rwy28R. Feedback results on these parameters are outlined in paragraphs 8.4.3 and8.4.4.

8.4.3. Re-positioning of the DINIL and NASRI holds and the Dublin CTA westernboundaryThe western holds of DINIL and NASRI were simulated in their new positions in allorganisations simulated. The relocation of the Dublin CTA western boundary permitted theuse of these holds and their inherent buffer airspace requirements. Their new locationfurther from the airport facilitated vectoring to all runways, particularly Rwy10R. Theirposition also facilitated departure flows in that they reduced the area of conflict betweendeparting and holding traffic.

The Four Quadrant Hold scenario gave ARN sole control of the ROKNA hold, ARS solecontrol of the TULSO hold and ARW sole control of the DINIL and NASRI western holds.The principle behind the 4-Quadrant scenario was that these holds would be usedirrespective of the runway in use, whereas, in previous organisations holds were linked to therunway in use - ROKNA and TULSO for Rwy28L and DINIL and NASRI for Rwy10R. NewSIDS/STARS were designed to comply with the 4-Quadrant scenario. In Org. E all exerciseswere based on the use of Rwy28L for arrivals and Rwy28R for departures. The Controllersalso stated that re-positioning of the western holds gave approach controllers sufficientspace and time to integrate traffic from DINIL and NASRI with traffic from ROKNA andTULSO.

However, as mentioned earlier, the extension of the Dublin CTA to 0730°W could seriouslyimpact on Shannon Low-level operations, particularly when traffic is being held above FL140at DINIL and/or NASRI.

8.4.4. Implementation of parallel runway operations at Dublin AirportOrganisations D and E included simulation of parallel runway operations using 3nmseparation on final approach to Rwy28L and 5nm separation on final approach to Rwy10R.With parallel runway operations Rwy28R and Rwy10L were designated solely for departureswith Rwy28L and Rwy10R designated solely for arrivals. The main reason for this was toremove the need for preparation of STARS for the newly installed 28R/10L runway. Thisalso provided another advantage in that it simplified and facilitated the preparation of thedata for the MAESTRO arrival management system.

The controllers agreed that the introduction of the parallel runway had an extremelybeneficial effect in that it provided a runway free to readily cope with all departures andallowed consistent use of 3nm separation to aircraft on approach to Rwy28L. However, newprocedures and working practices would be required before implementation. The controllersbelieve that the absence of a parallel runway at Dublin could serious impact ATC operationsin terms of holding and delay to departures, when long-term forecast traffic becomes areality.



EUROCONTROL

8.4.5. Use of 3nm separation between aircraft on final approach to Runway 10RThe use of 3nm separation between aircraft on final approach to Rwy10R was, unfortunately,not evaluated. The re-arrangement of the organisations during the simulation due to thevarious technical difficulties encountered, necessitated the cancellation (with clientagreement) of Organisation F where simulation of Rwy10L and Rwy10R operations wasintended.

8.4.6. Introduction of an Arrival Manager system (MAESTRO) at Dublin ATCCThe MAESTRO Arrival Manager was introduced in selected exercises during simulation ofOrganisations C, D and E. The heavy long-term forecast traffic levels simulated in theseorganisations, coupled with the fact that the controllers had no previous experience in, orprocedures for, the use of the tool, limited its evaluation. In effect, controllers did not use theAMAN system but monitored its operation with valuable assistance and advice from anexperienced operator - Claude Barret, an air traffic controller based at Charles DeGaulleairport. Jean Louis Garcia of STNA also assisted when possible.

The controllers were impressed by the system and put forward various recommendations asto how the system would best serve Dublin’s requirements.

The system is currently in use in Copenhagen where it is held in high regard. Copenhagen’sairspace is similar to Dublin’s in that the main approach is very close to the adjacent MalmoFIR boundary. Controllers there use the tool to successfully regulate and optimise the flowof arriving traffic at the TMA entry points. All controllers recommended that IAA managementshould send ATCO groups to Copenhagen to study their operating procedures. This wouldgreatly assist the preparation of operating procedures for Dublin.

They also highlighted the fact that the installation of the MAESTRO system at Dublin wouldrequire the co-operation of both Manchester and London ATCC’s.

They felt that MAESTRO would prove valuable for creating gaps on approach toaccommodate departure flows in single runway operations.

The APN and APS approach controllers found that when the system was set to runwaymode it was difficult to quickly pick out their respective aircraft. Sector-linked colour codingof the aircraft callsigns in the display would solve this problem.

All controllers felt that the MAESTRO system should include functions that providedminimum and maximum holding times as well as hold stack to runway times. Set up for theholds would require new letters of agreement with MATCC/LATCC. After the holds thesequence should be determined by the approach sectors, using their vectoring skills tooptimise the flow of traffic to the runways.

Finally, with regards to the siting of the MAESTRO display, area and approach controlleropinion was unanimous. The display should be stand-alone on the CWP and not integratedwithin the 2k x 2k radar screen.



EUROCONTROL

9. CONCLUSIONS AND RECOMMENDATIONS

The Irish Aviation Authority plans to implement a new ATM System - CAIRDE 2000 (CivilAviation Integrated Radar Display Equipment) which will enable the Authority to provide safeand cost effective services to its customers in the first decade of the new millennium, in linewith the forecast growth in air traffic.

The main simulation objectives focused on the evaluation of the operational impact of a HMI(Human Machine Interface) and assessed the potential roles anticipated for executive andplanning controllers. Secondary objectives concentrated on sectorisation configurations andoperating procedures specific to the Shannon and Dublin air traffic control centres.

The airspace simulated included Enroute, TMA, Approach and Departure sectors as well asthe Oceanic interface with the Shanwick Oceanic Control Area (OCA).

The simulation successfully achieved the many objectives set out at the project conceptionand was extremely important to Ireland as part of the IAA installation plans for its new ATCsystem. The participating controllers gained valuable experience working in an automatedHMI environment incorporating advanced safety features and a fully stripless environment.Their motivation and professionalism in the evaluation of the system and airspace proposalswas of enormous value for the long-term success of the CAIRDE project. The simulationoutput will be a significant contribution to the new system specification.

A summary of the conclusions and recommendations in relation to the detailed objectives isprovided below:

9.1. OBJECTIVE 1Controller Interface (HMI) EvaluationEvaluate the operational impact of the HMI for the CAIRDE 2000 system

The general results indicate that the move proposed by the IAA towards the CAIRDE 2000HMI is sound with the interface being well accepted by the participating controllers, 95%identifying that a windows style environment was a positive step for future ATC systems andthat the mouse was a suitable device for interacting with the system.

The general consensus was that a similar HMI would form an acceptable basis for anoperational system. Most controllers agreed that the integration of multiple display/inputwindows into a single display was a good idea, except in the case of the MAESTRO display,where the Dublin controllers unanimously recommended that this display should be stand-alone and not integrated within the radar window.

Significantly, 82% of the controllers agreed that the combination of dynamic flight leg withconflict information, interactive radar labels and lists provided a satisfactory system thatpermitted the removal of paper flight progress strips.



EUROCONTROL

9.1.1. Three Button MouseThe controllers indicated that the mouse was acceptable as a means of data input. Whilethey quickly became familiar with the mouse functionality, some confusion was initiallyexperienced as the functionality differed to that of the instruction handbook in that thepositions of the Information Button (IB) and Special Button (SB) were reversed. Therefore,some controllers experienced difficulty with the association and identification of the mousebuttons. The controllers recommended that different surface textures could assist withbutton identification.

Mouse reliability was considered of paramount importance for controller confidence. In theevent of a mouse failure, it must be possible to replace it quickly and efficiently with minimumdisturbance for the controller and no effect to the windows operating system. CWP designshould also take account of the different requirements of left-handed and right-handedoperators.

9.1.2. Windows and Pop-up MenusWhile the vast majority of the controllers agreed that a windows style environment was apositive step for future ATC systems, one third experienced problems with handling, movingand re-sizing the windows. Some controllers were sceptical as to whether the radar screencould suitably accommodate the number and size of windows that they felt necessary.However, pre-determined allocation of required windows to the Executive Controller (EXC)and Planning Controller (PLC) should ensure that the viewing areas of each position’s radarscreen are optimised.

The controllers found the pop-up menus easy to handle with adequate easily selectableoptions. However, some difficulties were experienced with incorrect default settings resultingin cumbersome scrolling to select the desired value.

9.1.3. Label and track resultsThe majority of the controllers (80%) agreed that the range of information displayed in theradar labels (Unselected, Selected and Extended Label Window) was appropriate. However,in the first weeks of the simulation, label selection and management proved extremelydifficult. Controllers stated that the physical act of label selection proved awkward ascontrollers consistently found that unconcerned labels would select when they were trying toselect the desired assumed, advance warning or concerned label. In effect, label sensitivityand transparency created controller frustration with the system and unnecessary extraworkload.

The controllers recommended that label selection should be by moving the mouse over thelabel or track symbol. A ‘press and hold’ feature, applied later in the simulation, for selectionof Unconcerned labels, significantly reduced unnecessary interaction with these labels. Mostcontrollers said they would prefer that individual label selection should be limited to as smalla background area as possible outside the text of the radar label.

As with all display systems of this type, radar label overlap was an issue. Automatic labelde-confliction was available in the simulation but the controllers found this feature annoyingas the constant ‘staggered movement effect’ of the radar labels on the screen proved moreof a distraction than a help.

They recommended that label movement should be simple and flexible and appreciated thevarious methods available to resolve label overlap. The ‘drag and drop’ functionality waspreferred to the pre-set positions. Pre-set positions allowed controllers to choose a pre-defined position for all labels on the radar screen. Drag and drop provided even greaterflexibility for label management. Although this involved extra work, controllers felt that they



EUROCONTROL

refreshed their mental traffic picture as they manually relocated the labels and did not find ittoo tiresome. Indeed, a functionality that allowed the controller to select pre-set positions forindividual labels or sets of labels (eastbound, westbound, arriving, departing) would beadvantageous.

Controllers often experienced difficulty in associating the track label with the Radar PositionSymbol (RPS), particularly when the label orientation was west to north-west of the RPS. Inthese cases the gap between the end of the leader line and the track label was excessive.To overcome this, the controllers recommended that the lead line should attach to the firstfield of the label. In addition, the lead line should be colour coded to distinguish it from thespeed vector and dynamic flight leg.

9.1.4. ColoursThe use of colours for labels (and lists) was very successful, with the vast majority ofcontrollers stating that the use of colour coding for labels and text was logical andunderstandable and that the status of each aircraft was always clearly identified by its colour.

The general consensus was that the Light Blue for the ‘Advance Warning’ label was verygood. The colour brilliance was reduced during the simulation as although it was consideredvery good for the track labels, it became a little bit uncomfortable when a lot of text waspresented in the various lists provided. The White for ‘Assumed’ aircraft was alsoconsidered to be too bright and they recommended that the brilliance should be reduced.

The IRL2000 HMI specified extensive use of background colour change to highlightinformation. Subtle change of background colour was very successfully used to cross-highlight all data associated with a particular flight. For example, when the mouse cursorcame to rest on a radar label not only was the Extended Label Window (ELW) updated withthe appropriate flight details but the related lists (SIL, SEL, DEP, and ARR) were alsopresented with a highlighted background. The background colour change for this type ofhighlighting was just sufficient to ensure that the data could be easily located but legibility oftext was not affected. Controllers greatly appreciated the effectiveness of this feature.

Shannon and Dublin controllers had different views regarding the Mustard and Grey coloursselected for ‘Concerned’ and ’Unconcerned’ labels respectively. Shannon found the Mustardto be suitable but felt that the Grey colour brilliance should be reduced.

Dublin experienced severe problems with the aircraft state system and the use of the Greycolour for Unconcerned labels. In real operations, the Dublin TMA is shared simultaneouslyby several controllers operating various sector positions. The Controllers felt that the aircraftstate system as simulated, was not particularly suitable for their operations. Controllersstated that although certain aircraft could be considered as ‘Unconcerned” to their sector, itwas still important that they were clearly visible. The found the Grey to be unsuitable, soMustard was used for all ‘Concerned’ and ‘Unconcerned’ labels in Dublin CTA. This was animprovement, but not considered the ideal solution (See STCA Results Section 5.3.1).Recommendations for further improvements varied from brightening the Mustard colour toaltering the Callsign and Actual Flight Level (AFL) fields to White. In short, the methodologyof defining and displaying ‘Concerned’ and ‘Unconcerned’ traffic to each Dublin sectorindividually, requires further investigation.



EUROCONTROL

9.1.5. FieldsThe controllers stated that the Callsign field highlight colour (Yellow) was good and shouldalso appear in all relevant lists. During the simulation, (and for the future system), Callsignhighlight was and will be only available between CWP’s of the same sector. Callsignhighlights on ‘Advance Warning’ labels were not over-ridden by White when these labelschanged to transfer-in mode following handover by the upstream sector. In effect, thismeant that the receiving sector was unaware of the handover proposition. Ideally, ahighlighted ‘Advance Warning’ aircraft should change to White ‘Transfer-In’ mode onhandover, and revert to highlight, once the aircraft has been assumed. Controllers alsostated that the Callsign field highlight should penetrate through all filters set within the sector.

The controllers found the Pink field highlighting to be very good and recommended that thesame colour should appear in all relevant windows.

Clicking on the inter-active fields of the selected label with the action button opened theirrelated pop-up window menus. Default values were defined for the pop-up window menusbut in some cases these did not work correctly, resulting in unnecessary scrolling in the pop-up window to select the desired value. This caused frustration and increased the workloadfor the controllers. The problem was further exacerbated by the fact that the principle of XFLdefault levels between sectors was not fully understood and employed correctly by somecontrollers. AT times XFL’s were entered that were not related to the next sector thusremoving it from the sequence. This resulted in aircraft being abrogated from the correctreceiving sector. Abrogation, a modification that implies that an aircraft will no longer enterinto a sector’s airspace, triggers a green callsign in the radar label of the abrogated sector.The controllers acknowledged the event by clicking on the callsign, whereupon the labelstate changed to ‘Unconcerned’.

The main observations of the controllers with regards to the label fields and their related pop-up windows were as follows:

Shannon• The Oceanic Flight Level (OFL) was too far offset from the Exit Flight Level (XFL).• When the XFL and OFL are the same value, the OFL should default to the XFL position,

and have a different colour.• When the Sector Exit Point (XPT) and FIR Exit Point (FXPT) are the same, the default

should be the point name in the FXPT position.• Line 3 of the label should read: XFL; OFL; FXPT; XPT.• The positions of the ADES and ADEP fields in the ELW caused some confusion,

particularly with departures from Shannon.• An Assume/Hold functionality should be added to the Callsign menu to allow TMA and

Approach controllers to put aircraft directly into the Hold list.• There is no requirement to have the Mach number displayed in the Selected label.

DublinThe Assume/Hold functionality in the Callsign menu, (mentioned above in the Shannonobservations), was tested extensively by the Dublin controllers. They found it to be veryuseful but were divided as to whether or not the default should be to Assume orAssume/Hold. Some felt that the default to Assume/Hold would result in inadvertentplacement of aircraft in the Hold list. There was no consensus on whether the Assume andAssume/Hold options should be located consecutively or separately in the pop-up window.This will require further evaluation.The controllers felt that a ‘minimum requirements’ label size would facilitate operations in thevery busy Dublin TMA. Further investigation and assessment of the minimum requirement ofmandatory fields should be undertaken



EUROCONTROL

Controllers recorded instances where they transferred aircraft from their sector in error byinadvertently clicking on the mouse action button (AB). A short delay facility in the systemacknowledgement of inter-sector transfers would permit controllers to retrieve (‘UndoTransfer’) incorrectly transferred aircraft.

9.1.6. Exit Flight Level (XFL) DefaultsXFL default settings in the electronic system posed many problems for controllers. In DublinCTA, where area, approach and departure controllers share usage of the same airspace thelimitations of the system could be easily overcome. However, the more complicatedsectorisation configuration of Shannon ATCC (Low-Level/High-Level) with vertically super-posed sectors proved more difficult to solve. The main problem encountered was which XFLto apply for an aircraft whose Requested Flight Level (RFL) would involve climb from onesector to another sector directly above. Use of the RFL would permit the lower sector toclimb the aircraft into the sector above without co-ordination whereas use of the lowersector’s Planned Entry Level (PEL) would result in no display of an ‘Advance Warning’ labelin the downstream sector until co-ordination was proposed.

The majority of controllers stated that they needed to have the ‘Advance Warning’ label butdid not want the lower sector to have the right to climb without co-ordination. One possiblesolution suggested was that the projected profile should be correctly displayed with either‘???’ or ‘XFL’ inserted in the label field. This, however, would require a late co-ordination onevery aircraft and impact on controller workload.

Further evaluation, concerning the authority to climb to the agreed XFL subject to co-ordination by telephone on potential conflicts, will be required. Controllers also stated thatclimbs following co-ordination should be immediate and coincident with transfer of aircraft.

9.1.7. Oceanic ClearancesShannon High-Level controllers received Oceanic Clearance Message (OCM) informationvia the Extended Label Window (ELW) and the Sector List (SEL). While the majority (75%)of the controllers stated that it was not obvious when the OCM was received by a flight theyagreed that the availability of oceanic clearances in the ELW led to a reduction in theirworkload. They preferred, however to access oceanic clearance information through theSEL.

9.1.8. VFR EnrouteThe simulated system employed pre-determined sector sequence parameters for Shannonand Dublin ATCCs. This created a problem for VFR operations in Shannon Low-Levelwhere controllers required a more dynamic versatile system, which precluded the definitionof a fixed flight plan and fixed sector sequence. Dublin ATCC opted not to simulate VFRoperations.

To obtain the necessary flexibility the Low-Level controller was able to select the next sectorand send advance information (via Force ACT) when required. This would change the labelin the selected upstream sector from ‘Unconcerned’ (Grey) to ‘Advance Warning’ (Light Blue)and copied the Cleared Flight Level (CFL) value to the XFL/PEL field.

In all cases the controllers agreed that the functionality provided was found suitable.



EUROCONTROL

9.1.9. Direct and Re-routingDublin controllers did not use the DCT functionality much although they considered it auseful option. The Shannon controllers, on the other hand, used the functionalityextensively, particularly in the large long High-Level sectors. They found it to be a veryuseful function and made the following observations and recommendations.

• The colour was good.• Aircraft routing DCT crossing several sector boundaries in a short space of time will be

an extremely difficult problem for the electronic system.• Effort and attention should be given to the design of sectors to focus on traffic flows and

optimise avoidance of short sector legs.• Problems were encountered using the elastic vector as the high-Level planning

controllers often needed to select a very long range to view the desired destination point.• The destination point selected with the DCT functionality should show in the AHDG field.

Following transfer to the downstream sector the destination point should appear in thedownstream sector AHDG field.

Controllers were able to re-route aircraft direct to any point in the flight planned route usingthe Elastic Vector. If the destination point they selected was not on the original flight plan itwas input by the system into the Assigned Heading field (AHDG). In the system, when usingthe DCT functionality, co-ordination will only place when the new point selected is in thecurrent next sector in the sector sequence, and the aircraft is ACT Out. If a DCT point isselected in any other sector, the new route will not be co-ordinated. However, the trajectorywill be updated and a new sector sequence will be created. In this case, the original nextsector is abrogated and the next sector receives a short notice ACT (normally followingtelephone co-ordination). Abrogation, a modification that implies that an aircraft will nolonger enter into a sector’s airspace, triggers a green callsign in the radar label of theabrogated sector. The controllers acknowledged the event by clicking on the callsign,whereupon the label state changed to ‘Unconcerned’.

The controllers stated that the abrogation function was very useful and the green callsignvery noticeable. In the system being provided to the IAA, abrogation will trigger a messagein the ‘Message In’ window. The general consensus was that the callsign colour change wasboth preferable and sufficient, with no requirement for message information and thatabrogation should force through all pre-set filters.

9.1.10. SkipControllers were comfortable with the skip functionality but stated that execution by the PLCshould be only after consultation with the EXC. They stated that the radar label in theskipped sector should remain in the “Concerned’ state until sector exit. Ideally, the co-ordination process between the sectors should not be frozen. In addition, despite theavailability of a ‘confirm skip’ message controllers stated that an ‘Unskip’ functionality wouldbe required.

9.1.11. Flight progress stripsThe use of flight progress strips in the simulation was the subject of much discussion anddebate between the IAA and EEC project teams. The simulated CAIRDE 2000 ATM systemwas mainly based on specifications derived from the EATCHIP Manual of the EATCHIP IIIAutomated system. This is a fully automated system designed to operate without progressstrips. The advice and opinion of the EEC, based on extensive experience in this area, wasthat in order to correctly evaluate the HMI in such a system the use of flight progress stripsshould be excluded.



EUROCONTROL

The IAA, on the other hand, is faced with the responsibility of providing a fully operationaland reliable system on schedule. The system requested from Airsys ATM will include fullflight progress strip facilities. System progression will be evolutionary rather thanrevolutionary, to avoid the sudden change to a stripless environment which could proveextremely problematic. Use of strips during the simulation would assist in the determinationof the projected time-scale for possible migration to a fully automated stripless system.

To meet the needs of the client and EEC, the simulation was divided into two phases.

Phase I simulated full flight progress strip functionality but did not include Medium TermConflict Detection (MTCD) and Conflict Risk Display (CRD). Co-ordination was bytelephone and no co-ordination In/Out windows were provided.

Phase II simulated Medium Term Conflict Detection (MTCD) and Conflict Risk Display(CRD). Full SYSCO Co-ordination was provided with Message In/Out windows and co-ordination indications shown in the radar label, ELW and data lists. There were no flightprogress strips.

The controllers were concerned as to the ergonomics of the CWP set-up (including strips) forthe new system. Current suites operate with a single radar display for the EXC and a flightprogress strip board for the PLC. In Dublin ACC the flight progress strip boards aredesigned to geographically represent the control area.

The CAIRDE 2000 system provides radar displays for the Executive and Planningcontrollers. Difficulties exist in allocating suitable CWP working areas to cater for flightprogress strip and mousepad needs. Keyboard requirements will further exacerbate thisproblem. In Shannon High-Level, the sheer volume of aircraft made it impossible tosectorise the strip board. The controllers found it impossible to keep the flight progressstrips up to date while simultaneously maintaining the electronic system. The consensuswas that the electronic system was preferable and easier to manage. Controllers found thatwhen they abandoned the strips it greatly improved the “in-suite” teamwork between theEXC and PLC. Indeed, in Phase II with SYSCO co-ordination and other addedfunctionalities, controllers stated that they were well able to manage without strips. In short,the use of flight progress strips was deemed not to be viable with the new system andmigration to a “stripless” environment should be addressed sooner rather than later.

Despite having to overcome teething problems with regards to printing strips, errors in stripdetails and duplication of strips, the controllers worked extremely hard with the simulatedsystem. They were commended for their efforts to try to maintain both systems (electronicand flight progress strip) while safely handling long-term heavy traffic levels forecast for2007.Despite these problems the controllers stated that it was difficult to handle more than 10aircraft while maintaining the flight progress strips and the electronic system. It becameimpossible to work radar labels, lists and strips at the same time. During the simulation, thePLC loaded the strips into the strip holders and boards. This took up valuable time andcaused a distraction from interaction with the system. In fact, the only way to keep strips upto date was for the PLC to ignore his radar display. All PLC’s preferred to maintain theelectronic system through the radar display rather than maintain strips.

Controllers felt that the Dynamic Flight Leg (DFL) function helped replace the planning roleof the strip board while appropriate sorting in the lists (SIL, SEL etc.) could suitably replacestrips. On the other hand, for tracking aircraft in holding patterns, caution was urged in theuse of Hold Lists as a replacement for strips until sufficient experience was attained andHold List functionality was fully evaluated.



EUROCONTROL

In the simulation, the Shannon High-Level PLC did not perform many of the normal functionsrelated to oceanic separations, clearances, re-clearances and revisions. This importantaspect of operations will require further evaluation, particularly in terms of a striplessenvironment. However, experience gained during the simulation indicated that these safetyissues could be handled more efficiently by the electronic stripless system.

Whereas, the move to a paperless system may not prove too difficult, the controllers re-iterated their view that the electronic system must work well while providing user-friendlyinput with correct default values.

9.1.12. Data list WindowsGenerally, controller reaction to the various lists available was mixed. A slight majority feltthat the text in the lists was easy to read but could be improved if the text used was ‘normal-underlined’ rather than ‘bold’. The consensus was that selection of window size would beenhanced if in each list (except for the Hold List), the Callsign field was the only mandatoryfield. This field should be placed on the left, with all other fields optionally selectable. Whenlists were closed and subsequently re-opened they should default to the controller’sprogrammed preference.

In two-man suites the PLC tended to spend more time watching the lists rather than theradar picture. Interaction with the lists proved more difficult as the level of traffic andsubsequent volume of list data increased. Although page lists occupy more screen spacethan scroll lists, problems were often encountered with essential flight data being hidden as aresult of the scrolling function.

9.1.13. Sector Inbound List (SIL)The controllers highlighted the preference for a single mandatory callsign field (in the SIL)with selectable options and a prioritised sorting system based on aircraft label state.Shannon High-Level controllers found the SILs particularly useful with SSR code allocationfor eastbound flows. Scrolling created some difficulties with regards to the display ofrelevant information. Dublin controllers did not use the SILs much. They considered them auseful facility but not a mandatory requirement and generally preferred to interact directlywith the radar label.

For Shannon controllers, reaction differed as to the need for the information displayed in theSIL depending on whether the controller role was a planning or tactical one. Surprisingly,executive controllers favoured the need for the SIL information more than planningcontrollers. The reasons for this may be that the EXC often operated on a shorter range andtherefore did not always see the ‘Advance Warning’ aircraft. Secondly, many planningcontrollers preferred to use the SEL rather than the SIL, as it provided more optionalinformation including oceanic clearance data.

9.1.14. Sector List (SEL)The controllers re-iterated their preference for a single mandatory callsign field in the SELwith selectable options and a prioritised sorting system based on aircraft label state.Shannon controllers used the SEL window more than their colleagues from Dublin, who onceagain considered it useful but supplementary to their needs.



EUROCONTROL

Shannon controllers highlighted sorting and scrolling as the main problems encountered withuse of the Sector List. Controllers sometimes had difficulty in finding aircraft in the SEL. Thedefault sorting provided was Entry Point (EPT), Entry Time (ETE) and Planned Entry Level(PEL). They suggested that the modification of these sort criteria to ETE, EPT and PELwould be more suitable.

Despite this measure, problems would still exist. Controller opinion was mixed regardingfurther sorting and scrolling methods. Sorting according to label-state provides advantagesand disadvantages particularly when scrolling is used. If, for example, ‘Assumed’ aircraftwere sorted to the top of the list, scrolling would hide some (or all) text lines of ‘AdvanceWarning’ aircraft that might not be visible on the radar window and also could be the subjectof co-ordination proposals. A page list with no scrolling would be better but this has thedisadvantage that the SEL can then become extremely big and occupies a large area of theradar window. On the other hand, the controllers do not require the display of ‘Concerned’aircraft. This, in turn, would help reduce window size.

9.1.15. Arrival and Departure ListsThe controllers had different views as to the usefulness of the Arrivals and Departure Lists.The Departure List was more widely accepted and considered far more useful with two-thirdsof the controllers stating that they always or regularly used it compared to one-third in thecase of the Arrival List. One should note however that use of the Arrival List was normally bybusy approach or TMA sectors where surveillance of and interaction with the radar label isinvariably more intensified. The controllers were reasonably pleased with the sortingspecifications for the Arrival and Departure Lists but recommended some improvements. Inthe Arrival List an ‘Assumed’, Advance Warning’ and ‘Concerned’ label–state sort orderwould be better while the Tower sequence for Departures should automatically update thesequence in the Departure List.

9.1.16. Hold ListThe Hold List was used extensively throughout the simulation by Dublin controllers.Shannon controllers used the functionality less as only two of the five simulatedorganisations included Low-Level operation. The Hold List proved to be very successful.The controllers found the Hold List to be both clear and simple. While indicating that theywould like similar functionality in the CAIRDE 2000 system they recommended furthermodifications in terms of both operational and sorting functionality.

Operational FunctionalityThe ability to put ‘Advance Warning’ aircraft in the Hold List would be useful for reservinglevels for aircraft cruising at flight levels below those currently occupied in a hold. This,however, currently creates difficulties with an electronic system as Advance Warning’ aircraftdisplay the PEL and not the CFL. The Hold pop-up menu should default to the holdsrelevant to the sector. Ideally, when an aircraft was below the minimum hold level the listshould only display the AFL.

Sorting FunctionalityThe scrolling facility (when 15 lines were reached) was not safe in that use of a single list forall holds (sorted by hold) often obscured vital data on aircraft in some holds. A separateHold List provided for each HPT and the removal of the scrolling facility would rectify thisproblem. The primary sort key should be on CFL followed by a secondary sort key for AFL.Thus, if two or more aircraft had the same CFL the secondary sort would ensure that aircraftwould sort by AFL.



EUROCONTROL

9.2. OBJECTIVE 2Controller Interface (HMI) EvaluationAssess the operational impact of the new ATC Tools, Safety Nets and Monitoring Aids

9.2.1. Area proximity Warning (APW)All controllers stated that the APW was very suitable. They felt that the yellow text was verynoticeable and coupled with the audio alarm expected in the CAIRDE 2000 system, theyanticipate that it will prove to be a very useful safety tool.

9.2.2. Short Term Conflict Alert (STCA)The vast majority of controllers agreed that the activation of the STCA attracted theirattention quickly. However, when asked about the suitability of the data-block display theresponse was far more critical. All controllers stated a dislike of the style of the STCAdisplay. The Red border on the label-block was considered a distraction and unnecessary.The Red background highlight of the Callsign field was extremely difficult to read when thelabel was in the ‘Concerned’ (Mustard) state. Overlapping labels caused further ambiguityand frustration. Suppressed labels of aircraft in Hold Lists did not display any STCAwarnings.

The controllers put forward three major recommendations for STCA display characteristics.These were:

• The Radar Position Symbol (RPS), Label lead line, Speed Vector and History Dotsshould all display in Red.

• The RPS should always remain visible.• The text of Callsign, AFL and Sector Indicator (SI) fields should always appear in White

with Red background highlight.

9.2.3. Dynamic Flight Leg (DFL)The controllers use of the Dynamic Flight Leg during the simulation indicated that it waspotentially a very useful element of the HMI package. While not used much in Dublin’s TMA,it was used extensively in the larger airspace of Shannon ATCC. The Dynamic Flight Legwas employed as the primary tool for providing route, sector sequence and conflictinformation when the controllers were handling high traffic levels and reference to other toolsand lists became difficult.

The DFL received strong support from those controllers that used it. They considered it tobe a very powerful tool, particularly when used in conjunction with MTCD where it should beselectable from the Conflict and Risk Display (CRD). The colours used were considered tobe quite good but some controllers felt that the thickness of the display lines should bereduced. Controllers stressed that the DFL should be updated when the DCT function wasused.



EUROCONTROL

9.2.4. Conflict and risk Display (CRD)Overall, the controllers supported the use of the CRD, although with reservations. All butone of the controllers found the tool ‘regularly or ‘sometimes’ useful. The Shannoncontrollers stated that the MTCD feature would be very useful for planning support in High-Level sectors. It could prove useful in Low-Level sectors but would be unusable in the TMA.An important requirement for the tool is that controllers have confidence in the conflictpredictions made. Comments indicated that there were many instances where too manyfalse risks were shown. As a result, in high workload situations frustration and confidencewere affected, and the CRD window was ignored.

On top of this, controllers identified some instances where the system failed to predict riskand/or conflict situations. However, they agreed that with improvements in the accuracy ofthe detection, task allocation and information display, the tool should achieve betteracceptance and may prove to be a powerful aid to assist controllers handle the increasingtraffic volumes forecast for the future.

On the positive side, the majority agreed that all of the appropriate information concerningrisks and conflicts was usually available in the MTCD tools. Some controllers felt that thepresentation of time and separation was not always easy to understand but training andexperience should overcome this. The majority felt that the CRD reduced their workload andassisted them in better prioritising their tasks. They recommended that an ability to interactwith labels through the CRD would further assist in the reduction of controller workload

Controllers (particularly the PLC’s) had to quickly adapt to new operating procedures whileresponding to MTCD warnings. The tool provided early warnings on potential conflicts butquite often the aircraft affected were outside the radar range selected. Planners had to learnto adjust to variable selection of radar range to efficiently utilise the MTCD feature. Thissometimes caused confusion over the situational timeframe in which they were working.They commented, however, that as a planning tool the MTCD enhanced conflict-handlingcapability provided a suitable replacement for flight progress strips.

9.3. OBJECTIVE 3Controller ProceduresEvaluate the potential roles of Executive and Planning Controllers in the simulatedsystem

The controllers stated that the functionality of each control position should be identical toenable the controllers themselves to create an appropriate task division and not have oneimposed by the system. This also allowed them to modify the task division when trafficlevels increased or decreased. They did feel that the PLC and EXC were able to worktogether as a team and generally agreed that the defined roles permitted this teamwork.

Although the roles of the PLC and EXC were reasonably well defined, the task allocationbetween Planning Controller and Executive Controller was not always clear. This may havebeen a result of allowing too much flexibility in the system configuration, or a result of theshort simulation period in gaining familiarity with the roles. While some versatility wasincorporated to allow for a distribution of workload, some actions (e.g. CFL input), althoughconsidered the key responsibility of one controller, were often shared between the two sectorcontrollers. The impact of this indistinct task allocation was minimal although confusion overindividual responsibilities occasionally surfaced.

The case for such inter-operability was discussed during the debriefing sessions. Thecontrollers were divided on the procedure that should apply for 'CFL input' and 'Assume



EUROCONTROL

Input'. Some felt that only the Executive Controller should make these inputs. At issue wasthe amount each input contributed towards maintaining the 'radar picture' and whethersharing of these tasks meant a degradation of the Executive Controller's situationalawareness and control.

Further consideration is recommended before placing any restriction on the systemfunctionality. Any limitation may be implemented using controller procedures therebyallowing flexibility while the implications are fully evaluated.

Finally, the controllers agreed that the implementation of the new ATM system technologywould result in a change of role assignments between the Executive and Planning controllersand put forward the following recommendations.

Dublin ATCC

• The EXC should continue to provide the radar service while the PLC would electronicallyinterface with and update the various windows and text lists that will eventually replacethe flight progress strip management functions currently in use.

• Controller roles will require further review and critical assessment when the finalconfiguration of the proposed system has been determined.

Shannon ATCC

The Executive controller should:

• Assume aircraft.• Interact with the CFL on giving clearance.• Transfer aircraft.• Handle most of the R/T.• Interface with XFL in ‘Advance Warning’ blue label.

The Planning controller should:

• Interact with the PEL.• Use the DCT function.• Handle some of the R/T.• Co-ordinate by telephone (when required).• Interface with the XFL in the ‘Assumed’ white label.• Manage the SEL and check oceanic clearances.

Furthermore, the PLC should manage most Window and List operations (such as SEL, SIL,CRD, Message-In, Message-Out, ARR, DEP and Hold). However, the EXC could also usethe SIL at times (e.g. first sector in an eastbound oceanic flow) and could interface with otherwindows (e.g. Referred CRD) when required.



EUROCONTROL

9.4. OBJECTIVE 4Co-ordinationAssess the operational impact of System Supported Co-ordination (SYSCO)

In Phase I (limited SYSCO functionality) the planning controllers experienced severedifficulty with co-ordination in that in proved extremely difficult to simultaneously update theflight progress strips and electronic system while also coping with heavy telephone usage.This problem was further exacerbated when traffic was increased to long-term future trafficlevels.

When the full SYSCO functionality was provided (Phase II) the controllers stated that theywere well able to manage without flight progress strips. Dublin controllers opted not to useSYSCO as the preferred to communicate by voice and/or intercom. They considered thismethod to be more suitable in terms of speed and user-friendliness to their dynamicapproach and shared airspace environment. They noted however that inter-sector transfersinitiated in error could not be undone. This problem proved extremely frustrating and willneed to be addressed in the future system.

The Shannon controllers found SYSCO to be extremely useful and generally agreed that theMessage In/Out windows were important for understanding co-ordination information. Thevast majority stated that detailed information on inbound aircraft was always available inreasonable time. While they considered that the presentation of co-ordination information inthe track labels was reasonably clear and unambiguous, they recommended that differentco-ordination colours should be used to differentiate between co-ordination in and co-ordination out. Our experience from previous simulations concurs with this. Indeed, thisrecommendation was further highlighted by the fact that 88% of the controllers preferred toco-ordinate via the data label rather than the Message In/Out windows.

Over 70% stated that the electronic transfer was preferable to the current systemmethodology and that the transfer functions significantly reduced their workload comparedwith normal working practises. On the other hand while 70% agreed that the capability tohand-over a flight to the downstream sector and receive an acceptance reduced workloadcompared with manual methods, they also stated that the capability to only accept or reject acounter-proposal was a significant limitation. Indeed, in complex situations they felt it wasnot possible to effectively handle co-ordination electronically.

Co-ordination with adjacent sectors was effective with few problems encountered. However,co-ordination between vertically split sectors underlined several technical and operationalshortcomings.

The display of a 'Default XFL' value for flights climbing from a High-level sector to a Supersector or descending from a Super sector to a High-level was discussed at length. If a‘Default XFL’ higher than the lowest level in the Super sector (for climbing traffic) or lowerthan the highest level in the High-level sector (for descending traffic) was used this allowedcontrollers to climb or descend aircraft to these levels without co-ordination and withoutknowledge of other conflicting aircraft.

The controllers recommended that for co-ordination the ‘Default XFL’ should be the first levelof the receiving sector (in order to trigger the ‘Advance Warning’ label state for that sector.This should be followed up by telephone co-ordination to confirm acceptance. Acceptanceof co-ordination should imply clearance to climb or descend. Subsequently, all climbs andtransfers should be immediate.



EUROCONTROL

Careful sector design will be required to avoid flights clipping small segments of adjacentairspace and to allow standard DCT routes to be applied without generating sector sequenceanomalies. While large sectors with straight-line boundaries are preferable, sector designmust also accommodate traffic flows and sector capacity limitations, sometimes inhibitingideal design.

Although the provision of vertically split sectors in the IRL2000 simulation raised severalpertinent issues; the controllers strongly supported the use of system supported electronicco-ordination. Comments from the controllers identified benefits such as greatly reducedtelephone communication, faster and more silent co-ordination, and a reduction in ATC taskload.

9.5. OBJECTIVE 5Airspace and ProceduresInvestigate further the findings of the fast-time study regarding airspace changes toboth Shannon and Dublin. Specifically to assess the operational impact of thefollowing changes:• Re-sectorisation of Shannon ATCC - Low Level.

• Re-sectorisation of Shannon ATCC - High Level.

• Re-sectorisation of Dublin ATCC.

• Use of one-man sectors in Dublin ATCC.

• Introduction of an Arrival Manager system (MAESTRO) at Dublin ATCC.

• Implementation of parallel runway operations at Dublin Airport.

• Use of 3nm separation between aircraft on final approach to Runway 10R.

• Use of new SIDS/STARS for State and regional airports.

• Use of holding patterns at new positions 15nm on the final approach to Shannon.

• Use of procedures for dealing with High Level traffic inbound to Belfast Airport.

• Re-positioning of the DINIL and NASRI holds and the Dublin CTA western boundary.

9.5.1. Shannon / Dublin InterfaceShannon controllers found that the delegated airspace was not sufficient and that increasedco-ordination was required to cope with transiting traffic, particularly when long term forecasttraffic levels were tested. Dublin agreed that increased co-ordination had been generatedbut emphasised their view that co-ordination was not required as both centres could see thetraffic and a review of current Letters of Agreement and inter-centre co-ordinationprocedures could easily resolve this problem.

Another aspect of the delegated airspace issue was the fact that Shannon felt that theairspace was only required by Dublin when Rwy10 was active whereas they regularlyrequired it for climb and descent of traffic. They considered that the use of delegatedairspace (not necessarily confined to the dimensions simulated) should be flexible and notspecifically or permanently assigned to either centre.



EUROCONTROL

Dublin however, insists that the extension of their airspace to 0730°West (up to FL245) isnecessary to encompass the buffer areas of the new western holds of DINIL and NASRI.The ability to use these holds up to FL240 is considered vital to cope with long term trafficlevels, as already at current traffic levels, the eastern holds of ROKNA and TULSO areregularly being used (following co-ordination with LATCC) above their published limits.

It is important to remember that the problem of how to facilitate both Shannon and Dublin’srequirements was not resolved before the simulation. Therefore a compromise was reachedin that the requirements of Shannon Low-level were addressed in Organisations A and B,whereas Dublin’s requirements were tested in Organisations C, D and E, as Shannon Low-level was not being simulated.

Further evaluation and discussion of the delegated airspace issue is recommended beforeany final concrete decisions or conclusions can be drawn.

9.5.2. Use of procedures for dealing with High Level traffic inbound to Belfast AirportAll the controllers agreed that the procedures for dealing with High-Level traffic outboundfrom and inbound to Belfast Airport worked very well.

9.5.3. Re-sectorisation of Shannon ATCC – Low LevelShannon Low (LOW)The handling of forecast medium-term traffic in the LOW sector during Organisation Aproved extremely difficult. Controllers felt that there was far too much traffic on thefrequency. Their ability to deal with the traffic volume was also impaired by the flight stripprinting and dissemination problems that existed throughout Phase I of the simulation. Theirconsensus was that there was no point in simulating LOW with long-term forecast traffic.They stated that there was a definite need for the two-sector configuration of NLO and SLOand they opted to focus their attention on further simulation of this, without using flightprogress strips.

Shannon North Low (NLO) and Shannon South Low (SLO)This configuration worked quite well although some controllers identified the possible needfor another low level sector to cope with future traffic levels anticipated for Cork andWaterford. A better solution to this problem could be to re-assess the geographicaldimensions of the NLO/SLO sectors and in particular re-locate the interface boundarybetween NLO and SLO further south. This, coupled with further evaluation of thedimensions of the proposed TMA sector and refined ATC procedures, should be sufficient.

All controllers stated that separate holds (FL150 and upwards) would be required for NLOand SLO to cope with situations when the TMA hold was full. They also recommended thatthe control of arriving and departing traffic to/from Kerry should be the responsibility of theTMA controllers.

In Organisations A (LOW) and B (NLO/SLO) the transfer of all offshore airspace west of1030° West to Shannon High-level worked very well and the controllers recommended thatit should be implemented.



EUROCONTROL

Shannon TMAAll controllers confirmed the necessity for a TMA sector while recommending variousimprovements in terms of design and operating procedures, as outlined below.

The geographical dimensions of the TMA should be re-assessed with defined Entry and ExitPoints structured to comply with current lower and upper ATC routes. The simulated designdid not allow much room to the east for manoeuvring aircraft. New ATC procedures will berequired for the interface between low-level and high-level sectors and the TMA. The designof new SIDS/STARS will need to comply with TMA entry/exit points for traffic departing fromand arriving to Shannon and the regional airports. STARS should be used in preference toradar vectoring as this could prove to be too complex. Radar co-ordination procedures willalso be required.

The controllers stated that the TMA should be manned by at least two controllers. The TMAhold should control all aircraft from the level above the transition level (TL) up to FL140. TheTMA planning controller should assign levels to the low-level sectors (NLO/SLO) when theybecome available. The TL and below should be under the control of the Approach sector.

Shannon Approach (APP)Long-term traffic levels quickly caused problems for APP with high R/T loading. Propermaintenance of the electronic HMI made it impossible to simultaneously use flight progressstrips, even with medium-term traffic levels. The controllers recommended that the APPcontroller should be responsible for aircraft holding at the TL in the simulated holds ofSCARF (Rwy24 Active) and FOY (Rwy06 Active).

9.5.4. Use of holding patterns at new positions 15nm on the final approach toShannonIn Organisations A and B the Entry Fixes to the holding patterns (SCARF and FOY) wereinitially positioned at 15nm on final approach to runways 24 and 06 respectively. Thecontrollers quickly found these locations to be unsuitable due to the amount of label cluttergenerated on final approach. All the controllers agreed that the holds should be offset fromthe final approach paths and discussions resulted in numerous suggestions for suitably re-positioned sites. New locations were finally agreed siting SCARF at 5240°N 0820°W (southof the approach to Rwy24) and FOY at 5245°N 0924°W (north of the approach to Rwy06).These proved to be far better but not ideal. There was also wide support indicated for theavailability of two hold fixes for each runway (similar to the system used at Dublin),positioned each side of the final approaches.

9.5.5. Use of new SIDS/STARS for State and regional airportsThe Shannon SIDS worked quite well. All controllers liked the fact that departure routeswere clear of arrival routes. The default levels applied proved suitable, removingunnecessary co-ordination. During the simulation, the Rwy24 SID for departures to Dublin(DUB2B) followed a left turn. When the NLO/SLO sectorisation was simulated controllersfelt that a right turn after departure would have been more suitable. The controllerssuggested that future SIDS/STARS should be designed with regards to the requirements ofthe NLO/SLO and TMA sectors. In effect, SIDS terminating at TMA exit points and STARScommencing at TMA entry points, would ensure that the sector sequence for departing andarriving traffic was correctly addressed.

The regional airports SIDS/STARS generally worked very well. Controllers had no difficultywith aircraft departing from regional airports on an initial climb clearance to 5000 feet,without any prior co-ordination. Imminent departures from all airports were displayed in therelevant sector’s departure list. Arriving aircraft were descended to the TL (FL60) andtransferred to the Ireland Domestic Feed Sector, when clear of departing traffic. The



EUROCONTROL

controllers agreed that if the new system included on-line connections to the regional airportsand proper radar coverage was available, there should be no requirement for co-ordinationbetween Shannon and the regional airports. They, therefore, recommended thatSIDS/STARS should be developed for all regional airports.

9.5.6. Re-sectorisation of Shannon ATCC - High LevelThe controllers found that the vertical sectors provided an excellent method of handling hightraffic loads on the same track and could prove essential when RVSM is introduced inEurope. The use of the Super sectors was also considered very beneficial. The controllerspointed out that in real operations the strategic selection of level splits between the verticalsectors could prove advantageous.Sector design, an area much evaluated for Shannon Low-level, proved to be the mainproblem faced when simulating Shannon High-level. In this case however the problemswere related more to the HMI than the sector dimensions. At present, electronic systemshave great difficulty with vertical sectorisation plans in terms of trajectory prediction andcalculation of climb and descent profiles. This, in turn, can seriously effect sector sequencecomputation, thereby creating erroneous electronic co-ordination messages.

These problems can be greatly reduced by careful sector design that reduces clipping ofsector segments and accommodates traffic flows. However, the sectorisation used inShannon High-level, which is dynamically and strategically modified to meet oceanic trackrequirements will prove extremely difficult to replicate in the future system where the HMIemphasis is based on label state, colour, sector sequence and SYSCO co-ordination.

9.5.7. Re-sectorisation of Dublin ATCCDublin Departure (DEP)Controller reaction to the introduction of the DEP sector was very positive. All agreed that itsignificantly reduced the workload currently experienced by Area sector controllers, withregards to the identification and handling of departing traffic. While co-ordination wasoccasionally required with the Approach sectors to resolve conflicts, controllers disapprovedof the practice of routinely running departing jet aircraft to the markers (as opposed to3000ft.) before turning them, in order to avoid conflicts with arriving or own sector traffic.Consensus was reached regarding the suitability of the airspace, operating procedures andHMI.

Final Approach (FIN)Controllers reaction to the introduction of the FIN sector was also positive but they stressedthat new procedures and more experience would be required to optimise it’s impact. Beforethe simulation, approach controllers had no previous experience in the application of 3nmseparation on final approach. They found it extremely difficult to apply this tight separationsuccessfully due to the limited dimensions of the airspace permitted for its use. The FINcontroller tended to take control of traffic further and further from final approach in order toclose gaps between aircraft departing from the holding stacks. Many controllers consideredthat the application of 3nm separation on final approach from 15nm to touchdown was toorestrictive. Extensive training and experience will be required to perfect skills in theapplication of 3nm separation involving strict use of speed control and new workingprocedures. The controllers recommended a review of, and extension to, the airspacepermitted for application of 3nm separation.



EUROCONTROL

9.5.8. Use of one-man sectors in Dublin ATCC.A third area sector – Dublin West Area (ARW), manned by a single Executive Controller wasintroduced to handle traffic from the north and west. The planning controllers were removedfrom the ARN and ARS sectors leaving a configuration using one Executive Controller ineach simulated sector. The ARW sector took all traffic previously handled by ARN (exceptfor flights on the B1 and W911D), and all traffic previously handled by ARS (except for flightson the R14 and B39). ARW controlled both western holds (DINIL and NASRI), transferringarriving traffic to both the APN and APS approach sectors. Controller first impressions werethat the ARW sector worked quite well, alleviating workload in the busier ARN and ARSsectors. However, further examination of how to handle simultaneous northbound overflightson the UP600 and UR14 will be required. The interface between ARW and all adjacentsectors of Shannon and Dublin will also need further investigation.

9.5.9. Re-positioning of the DINIL and NASRI holds and the Dublin CTA westernboundaryThe western holds of DINIL and NASRI were simulated in their new positions in allorganisations simulated. The relocation of the Dublin CTA western boundary permitted theuse of these holds and their inherent buffer airspace requirements. Their location furtherfrom the airport facilitated vectoring to all runways by giving approach controllers sufficientspace and time to integrate traffic from DINIL and NASRI with traffic from ROKNA andTULSO. Their position also facilitated departure flows in that they reduced the area ofconflict between departing and holding traffic.However, the extension of the Dublin CTA to 0730°W could seriously impact on ShannonLow-level operations, particularly when traffic is being held above FL140 at DINIL and/orNASRI.

9.5.10. Implementation of parallel runway operations at Dublin AirportThe controllers agreed that the introduction of the parallel runway had an extremelybeneficial effect in that it provided a runway free to readily cope with all departures andallowed consistent use of 3nm separation to aircraft on approach to Rwy28L. However, newprocedures and working practices would be required before implementation. The controllersbelieve that the absence of a parallel runway at Dublin could serious impact ATC operationsin terms of holding and delay to departures, when long-term forecast traffic becomes areality.

9.5.11. Use of 3nm separation between aircraft on final approach to Runway 10RThe use of 3nm separation between aircraft on final approach to Rwy10R was, unfortunately,not evaluated. The re-arrangement of the organisations during the simulation due to thevarious technical difficulties encountered, necessitated the cancellation (with clientagreement) of Organisation F where simulation of Rwy10L and Rwy10R operations wasintended.



EUROCONTROL

9.5.12. Introduction of an Arrival Manager system (MAESTRO) at Dublin ATCCThe controllers were impressed by the system and put forward various recommendations asto how the system would best serve Dublin’s requirements.

The system is currently in use in Copenhagen where it is held in high regard. Copenhagen’sairspace is similar to Dublin’s in that the main approach is very close to the adjacent MalmoFIR boundary. Controllers there use the tool to successfully regulate and optimise the flowof arriving traffic at the TMA entry points. All controllers recommended that IAA managementshould send ATCO groups to Copenhagen to study their operating procedures. This wouldgreatly assist the preparation of operating procedures for Dublin.

They also highlighted the fact that the installation of the MAESTRO system at Dublin wouldrequire the co-operation of both Manchester and London ATCC’s.

They felt that MAESTRO would prove valuable for creating gaps on approach toaccommodate departure flows in single runway operations.

The APN and APS approach controllers found that when the system was set to runwaymode it was difficult to quickly pick out their respective aircraft. Sector-linked colour codingof the aircraft callsigns in the display would solve this problem.

All controllers felt that the MAESTRO system should include functions that providedminimum and maximum holding times as well as hold stack to runway times. Set up for theholds would require new letters of agreement with MATCC/LATCC. After the holds thesequence should be determined by the approach sectors, using their vectoring skills tooptimise the flow of traffic to the runways.

Finally, with regards to the siting of the MAESTRO display, area and approach controlleropinion was unanimous. The display should be stand-alone on the CWP and not integratedwithin the 2k x 2k radar screen.

Ireland 2000 Simulation en temps accéléré

Rapport CEE No. 366 81

EUROCONTROL

TRADUCTION EN LANGUE FRANÇAISE DU RESUME, DE L’INTRODUCTION, DESOBJECTIFS, DES CONCLUSIONS ET RECOMMANDATIONS

RESUMELa simulation en temps réel IRL2000 s’est déroulée au Centre Expérimentald’EUROCONTROL du 6 au 31 mars 2000. L’Administration de l’Aviation Civile irlandaise(IAA) a l'intention de mettre en œuvre un nouveau système ATM, baptisé CAIRDE 2000(Civil Aviation Integrated Radar Display Equipment). Ce système permettra à l’IAA d’offrir àses clients, au cours de la première décennie du nouveau millénaire, des services alliantsécurité et efficacité économique, en accord avec les prévisions de croissance du traficaérien.

Conçu sur la base des technologies les plus récentes, le système CAIRDE 2000 vise à fairebénéficier le contrôleur d’une assistance automatisée optimale (en termes de sécurité, defiabilité et de flexibilité) tout en essayant de maximiser l’efficacité et de réduire la marged’erreur humaine au niveau de l’interface système.

Au total, vingt-quatre contrôleurs de la circulation aérienne (13 provenant de Shannon, 9 deDublin et 2 du Centre de formation de l’IAA) ont pris part à la simulation IRL2000. Ceux-ciont pu acquérir une expérience pratique du système CAIRDE 2000 pendant un total de 98heures de simulation, incluant les phases de réception, de formation et d’évaluation chiffrée.L’apport considérable des contrôleurs opérationnels à la définition des nouvellesfonctionnalités (et leur familiarisation avec ces dernières) se révélera extrêmementbénéfique pour l’IAA avant la mise en œuvre du système.

Cinq types d’organisation ont été simulés aux fins d’évaluer l’incidence opérationnelle del’interface homme machine (IHM) et le rôle que les contrôleurs exécutifs et de planificationpourraient respectivement jouer dans le cadre du nouveau système. Le scénario desimulation visait à compléter la précédente simulation en temps accéléré de l’espace aérienirlandais (tâche CEE n° F01 / note CEE n° 20/97) en l’assortissant d’objectifs secondaires,qui avait plus particulièrement trait à la configuration des secteurs et aux procéduresd’exploitation propres aux centres de contrôle de la circulation aérienne de Shannon et deDublin.

Outre l’adoption d’un affichage radar à fenêtres multiples, avec saisie des données aumoyen d’une souris à trois boutons, l’interface contrôleur présentait les principalescaractéristiques suivantes : coordination automatisée électronique (SYSCO), détection desconflits à moyen terme et filets de sauvegarde tels que dispositif d’alerte aux conflits à courtterme (STCA) et avertissement de proximité de zone protégée (APW). La simulation apermis d’obtenir des informations précieuses sur l’exploitation efficace des données de liste,l’interaction avec les étiquettes de pistes et l’emploi de la couleur dans un systèmeautomatisé (avec ou sans bandes de progression de vol). Ces informations aideront l’IAA àspécifier les nouvelles caractéristiques et fonctions du système CAIRDE 2000.

La simulation de différentes configurations d’espace aérien et de secteurs a égalementapporté des renseignements intéressants de nature à résoudre les problèmes que poserontles plans de sectorisation verticale et la fonction d’affichage du statut des étiquettes, telleque conçue et définie par le fabricant.


82 Rapport CEE No. 366

EUROCONTROL

En conclusion, cette simulation aura revêtu une importance capitale pour l’Irlande. L’IAAenvisageant la mise en place d’un nouveau système ATC dans le courant des prochainesannées, la participation active des contrôleurs à l’élaboration et à l’évaluation despropositions relatives au système et à l’espace aérien s’est avérée d’une très grande utilitépour la réussite à long terme du projet CAIRDE 2000. Les résultats de la simulationcontribueront de façon substantielle à la définition des spécifications du nouveau système.



EUROCONTROL

1. INTRODUCTIONLa simulation en temps réel IRL2000 s’est déroulée au Centre Expérimentald’EUROCONTROL du 6 au 31 mars 2000. Son objectif était de répondre aux besoinsspécifiques de l’Administration de l’Aviation Civile Irlandaise (IAA).

Le présent rapport décrit les objectifs, l’organisation pratique ainsi que les paramètres deladite simulation. Il analyse également les résultats obtenus et présente les conclusions quien ont été tirées.

L’actuel système ATM irlandais (CAIRDE) a été mis en service en 1990. Bien qu’il soitconforme aux spécifications EATCHIP, ce système repose sur des technologies datant desannées 1980 et n’est plus en mesure d’évoluer ni d’intégrer de nouvelles technologiescomme l’interface homme machine (IHM) et les outils ATC modernes.

L’IAA a l’intention de mettre en œuvre un nouveau système ATM (CAIRDE 2000), qui luipermettra d’offrir à ses clients, au cours de la première décennie du nouveau millénaire, desservices alliant sécurité et efficacité économique, en accord avec les prévisions decroissance du trafic aérien.

Le but premier de la simulation était d’évaluer l’incidence opérationnelle de l’interfacehomme machine (IHM) et le rôle que les contrôleurs exécutifs et de planification pourraientrespectivement jouer dans le cadre du nouveau système. Les objectifs secondaires avaienttrait à la configuration des secteurs et aux procédures d’exploitation propres aux centres decontrôle de la circulation aérienne de Shannon et de Dublin.

L’espace aérien simulé englobait des secteurs en route, de région de contrôle terminal(TMA), d’approche et de départ, ainsi que l’interface océanique, avec la région de contrôleocéanique (OCA) de Shanwick.

La simulation s’est articulée en deux phases. La première consistait à évaluer unenvironnement fondé sur l’utilisation de bandes de progression de vol et le recours à lacoordination par téléphone. La seconde portait sur l’évaluation d’un système plusautomatisé, n’utilisant pas de bandes de progression de vol et faisant intervenir un doubledispositif de coordination automatisée (SYSCO) et de détection des conflits à moyen terme(MTCD).

Cette simulation revêt une importance capitale pour l’Irlande. L’IAA envisageant la mise enplace d’un nouveau système ATC dans le courant des prochaines années, la participationactive des contrôleurs à l’élaboration et à l’évaluation des propositions relatives au systèmeet à l’espace aérien est déterminante pour la réussite à long terme du projet CAIRDE 2000.



EUROCONTROL

2. OBJECTIFSLa simulation porte sur une évaluation globale de haut niveau de l’IHM et des méthodes detravail, à quoi s’ajoute une série d’objectifs secondaires propres aux activités des ATCC deShannon et de Dublin. Chacun des objectifs énumérés ci-dessous est accompagné d’un brefcommentaire en italique, destiné à en préciser la nature.

Objectifs poursuivis :

1. Évaluer l’incidence opérationnelle de l’IHM sur le système CAIRDE 2000.conception ergonomique et technique de l’IHM du système CAIRDE 2000, telle quesimulée avec utilisation de bandes de progression de vol. Le CEE fournira en outre undispositif destiné à simuler un système à automatisation plus poussée, grâce auquel leclient pourra prévisualiser certaines évolutions escomptées du système.

2. Évaluer l’incidence opérationnelle des outils ATC, des filets de sauvegarde et desaides à la surveillance du nouveau système.Récolter des avis et des enregistrements de données ayant trait à la conceptionergonomique et technique des nouveaux outils ATC mis à disposition.

3. Évaluer le rôle que les contrôleurs exécutifs et de planification pourraientrespectivement jouer dans le système simulé.Recueillir les réactions des contrôleurs quant au mode de répartition des tâchesenvisagé entre contrôleurs exécutifs et contrôleurs de planification et, si nécessaire,confronter ce dernier à d’autres configurations, proposées au cours de la simulation, à lalumière de l’expérience acquise dans le maniement du nouveau système.

4. Évaluer l’incidence opérationnelle de la coordination automatisée (SYSCO).Recueillir l’avis des contrôleurs participants et rassembler des enregistrements dedonnées, sur l’ergonomie et l’utilité opérationnelle de la SYSCO, aussi bien dans le casd’un système à fonctionnalités limitées avec bandes de progression de vol que danscelui d’un dispositif enrichi fonctionnant sans bandes papier.

5. Approfondir l’examen des conclusions de l’étude en temps accéléré sur leschangements envisagés dans les espaces aériens de Shannon et de Dublin. Plusspécifiquement, évaluer l’incidence opérationnelle des modifications suivantes :

a) Redécoupage des secteurs de l’espace aérien inférieur de l’ATCC de Shannon ;b) Redécoupage des secteurs de l’espace aérien supérieur de l’ATCC de Shannon ;c) Redécoupage des secteurs de l’ATCC de Dublin ;d) Utilisation de secteurs à contrôleur unique à l’ATCC de Dublin ;e) Mise en œuvre d’un gestionnaire des arrivées (MAESTRO) à l’ATCC de Dublin ;f) Mise en exploitation de pistes parallèles à l’aéroport de Dublin ;g) Instauration d’une séparation de 3 MN entre les aéronefs en approche finale de la piste

10R ;h) Utilisation de nouveaux SID / STAR pour les aéroports nationaux et régionaux ;i) Repositionnement des circuits d’attente à une distance de 15 MN sur la trajectoire

d’approche finale de Shannon ;j) Utilisation de procédures de prise en charge du trafic en altitude à destination de

l’aéroport de Belfast ;k) Repositionnement des points d’attente DINIL et NASRI et déplacement de la limite

occidentale de la CTA de Dublin.



EUROCONTROL

3. CONCLUSIONS ET RECOMMANDATIONS

L’Administration de l’Aviation Civile Irlandaise a l’intention de mettre en œuvre un nouveausystème ATM, baptisé CAIRDE 2000 (Civil Aviation Integrated Radar Display Equipment),qui lui permettra d’offrir à ses clients, au cours de la première décennie du nouveaumillénaire, des services alliant sécurité et efficacité économique, en accord avec lesprévisions de croissance du trafic aérien.

La simulation avait pour objectifs premiers d’évaluer l’incidence opérationnelle d’uneinterface homme machine (IHM) ainsi que les rôles envisagés respectivement pour lescontrôleurs exécutifs et de planification. Les objectifs secondaires, quant à eux, portaientessentiellement sur la configuration des secteurs et les procédures d’exploitation propresaux centres de contrôle de la circulation aérienne de Shannon et de Dublin.

L’espace aérien simulé englobait les secteurs en route, de région de contrôle terminal(TMA), d’approche et de départ, ainsi que l’interface océanique, avec la région de contrôleocéanique (OCA) de Shanwick.

La simulation a atteint avec succès les multiples objectifs définis au stade de la conceptiondu projet et s’est révélée d’une importance capitale pour l’Irlande, dans le cadre des plansélaborés par l’IAA pour la mise en œuvre de son nouveau système ATC. Les contrôleursparticipants ont acquis une expérience précieuse de l’exercice du métier en environnementIHM automatisé intégrant des dispositifs de sécurité évolués ainsi qu’en environnement sansbandes de progression de vol. La motivation et le professionnalisme dont ils ont fait preuvelors de l’évaluation des propositions relatives au système et à l’espace aérien ont constituéun apport des plus précieux pour la réussite à long terme du projet CAIRDE. Les résultatsde la simulation contribueront de façon substantielle à la définition des spécifications dunouveau système.

On trouvera ci-après une synthèse des conclusions et recommandations pour chacun desobjectifs spécifiques :

3.1. ObjectiF 1Évaluation de l'interface contrôleur (IHM)Évaluer l’incidence opérationnelle de l’IHM sur le système CAIRDE 2000

Les résultats globaux tendent à démontrer que le passage à l’IHM CAIRDE 2000, tel queproposé par l’IAA, procède d’un choix avisé : l’interface a été bien acceptée par lescontrôleurs participants. En effet, 95 % d’entre eux estimernt qu’un environnement àfenêtres multiples constituait un développement intéressant pour les futurs systèmes ATC etque la souris permettait d’interagir efficacement avec le système.

L’idée selon laquelle une telle IHM pourrait servir de base acceptable pour un systèmeopérationnel a recueilli un large consensus. La plupart des contrôleurs se sont déclarésfavorables à l’intégration des différentes fenêtres d’affichage / de saisie dans un écranunique, à l’exception de l’écran MAESTRO qui, sur la recommandation unanime descontrôleurs de Dublin, devrait rester autonome et ne pas être incorporé dans la fenêtreradar.

Constat significatif, 82 % des contrôleurs ont indiqué que l’utilisation combinée du tronçon devol dynamique (DFL), des informations sur les conflits, des étiquettes radar interactives etdes listes leur offrait un moyen satisfaisant de se passer des bandes de progression de volsur papier.



EUROCONTROL

3.1.1. Souris à trois boutonsLa souris a été jugée acceptable en tant qu'outil de saisie des données. Bien que lescontrôleurs se soient familiarisés rapidement avec les fonctions de la souris, une certaineconfusion est apparue au début du fait que ces fonctions ne correspondaient pas auxexplications fournies dans le manuel d’utilisation. Le bouton droit (Information Button) et lebouton médian (Special Button) étaient en effet inversés. Aussi certains contrôleurs ont-ilséprouvé des difficultés à associer et à identifier les boutons de la souris. Les contrôleurs ontsuggéré d’utiliser des textures superficielles différentes pour faciliter l’identification desboutons.

La fiabilité de la souris joue un rôle primordial dans la confiance des contrôleurs. En cas dedéfaillance, la souris doit pouvoir être remplacée rapidement et efficacement, avec unminimum de dérangements pour le contrôleur et sans incidence sur l’environnement àfenêtres multiples. La conception du poste de travail de contrôleur (CWP) devrait aussi tenircompte des besoins particuliers des opérateurs, selon qu’ils sont gauchers ou droitiers.

3.1.2. Fenêtres et menus contextuelsSi, dans leur grande majorité, les contrôleurs ont reconnu qu’un environnement à fenêtresmultiples constituait une innovation positive pour les futurs systèmes ATC, un tiers d’entreeux ont cependant indiqué avoir éprouvé des difficultés à manipuler, déplacer etredimensionner les fenêtres. Certains contrôleurs se sont demandé si l’écran radar étaitréellement compatible avec le nombre et la taille des fenêtres jugés nécessaires. Il devraitnéanmoins être possible, moyennant une attribution prédéfinie des fenêtres utiles aucontrôleur exécutif (EXC) et au contrôleur de planification (PLC), d’optimiser les zones devisualisation sur l’écran radar de chacun des postes de travail.

Les contrôleurs ont trouvé que les menus contextuels étaient d’un maniement aisé, comptetenu de la facilité avec laquelle ils permettent de sélectionner les options appropriées.Toutefois, les paramètres par défaut n’étant pas toujours corrects, certains contrôleurs ontdû se livrer à une manœuvre de défilement peu pratique pour sélectionner la valeursouhaitée.

3.1.3. Résultats concernant les étiquettes et les pistesLa majorité des contrôleurs (80 %) a jugé adéquat l’éventail des informations affichées dansles étiquettes radar (fenêtre d’étiquette non sélectionnée, sélectionnée et étendue).Néanmoins, pendant les premières semaines de la simulation, la sélection et la gestion desétiquettes s’est avérée extrêmement difficile. Les contrôleurs ont indiqué que l’opération desélection des étiquettes était malaisée : régulièrement, des étiquettes non pertinentes(Unconcerned) étaient sélectionnées lorsqu’ils essayaient de cliquer sur l’étiquette souhaitéecorrespondant à un vol pris en charge (Assumed), à un avertissement anticipé (AdvanceWarning) ou à un vol concerné (Concerned). De fait, la sensibilité et la transparence desétiquettes a engendré chez les contrôleurs un sentiment de frustration à l’égard du systèmeainsi qu’un surcroît de travail inutile.

Les contrôleurs ont recommandé que la sélection s’opère par déplacement du pointeur de lasouris sur l’étiquette ou le symbole de piste. Le recours ultérieur, pendant la simulation, àune fonction de type « appuyer et maintenir » pour sélectionner les étiquettes Unconcerneda permis de réduire considérablement les interactions inutiles avec ces étiquettes. Laplupart des contrôleurs ont exprimé leur préférence pour une sélection individuelle desétiquettes qui se limite à une zone en arrière-plan la plus petite possible, située en dehors dutexte de l’étiquette radar.



EUROCONTROL

Comme c’est le cas avec tous les systèmes de visualisation de ce genre, le chevauchementdes étiquettes radar a posé problème. Le dispositif de suppression automatique des conflitsentre étiquettes était certes disponible lors de la simulation, mais les contrôleurs ont jugécette fonction dérangeante, l’effet permanent de « mouvement décalé » produit par lesétiquettes radar sur l’écran se révélant plus perturbant qu’utile.

Les contrôleurs ont recommandé que le mouvement des étiquettes soit à la fois simple etsouple, et ont ensuite évalué les différentes méthodes possibles pour résoudre le problèmedu chevauchement des étiquettes. La fonction de type « glisser-déposer » a été préférée ausystème de positionnement prédéfini ; ce dernier permettait aux contrôleurs deprédéterminer l’emplacement des étiquettes sur l’écran radar, mais la fonction « glisser-déposer » offrait davantage de souplesse au niveau de la gestion des étiquettes. Bienqu'elle entraîne une charge de travail supplémentaire, les contrôleurs ont estimé que cetteméthode leur permettait de rafraîchir leur image mentale de la situation du trafic à mesurequ'ils déplaçaient manuellement les étiquettes, et qu'elle ne générait pas une fatigueexcessive. De fait, une fonctionnalité permettant au contrôleur de sélectionner des positionsprédéfinies correspondant à des étiquettes individuelles ou à des groupes d’étiquettes (endirection de l’est, en direction de l’ouest, à l’arrivée, au départ) serait un avantage.

Les contrôleurs ont fréquemment éprouvé des difficultés à associer l’étiquette de piste avecle symbole de position radar (RPS), notamment lorsque l’orientation de l’étiquettecorrespondait à la direction ouest – nord-ouest par rapport au RPS. Dans ces cas de figure,l’écart entre l’extrémité du leader et l’étiquette de piste était trop important. Pour surmontercet obstacle, les contrôleurs ont recommandé que le leader se rattache au premier champde l’étiquette. De plus, le leader devrait être assorti d’un code de couleur le distinguant duvecteur de vitesse et du tronçon de vol dynamique.

3.1.4. CouleursL’utilisation de couleurs pour les étiquettes (et les listes) a donné de très bons résultats, lescontrôleurs affirmant, dans leur grande majorité, que le recours à des codes de couleur pourles étiquettes et le texte était logique et compréhensible, et que le statut de chaque aéronefétait toujours clairement identifiable grâce à sa couleur.

Le bleu clair associé à l’étiquette Advance Warning a recueilli tous les suffrages. L’éclat descouleurs a été atténué pendant la simulation car, bien que jugé très bon pour les étiquettesde piste, il est devenu quelque peu incommodant lorsqu’une grande quantité de texteapparaissait dans les différentes listes affichées. Le blanc désignant un aéronef « pris encharge » (Assumed Aircraft) a également été jugé trop brillant par les contrôleurs, qui ontrecommandé d’en estomper l’éclat.

L'IHM IRL2000 ménageait un recours systématique au changement de la couleur d'arrière-plan pour mettre les informations en évidence. Les nuances de couleur d'arrière-plan pourfaire ressortir toutes les données associées à un vol particulier ont été exploitées avecsuccès. Par exemple, lorsque le pointeur de la souris s’arrêtait sur une étiquette radar, nonseulement la fenêtre d’étiquette étendue (ELW) était actualisée, avec toutes les informationsde vol utiles, mais les listes apparentées (SIL, SEL, DEP et ARR) s’affichaient égalementavec un arrière-plan mis en évidence. Le changement de la couleur d’arrière-plan pour cetype de mise en évidence était juste suffisant pour faire en sorte que les données puissentêtre localisées facilement sans pour autant nuire à la lisibilité du texte. Les contrôleurs ontgrandement apprécié l’efficacité de cette fonction.

Les contrôleurs des centres de Shannon et de Dublin ont émis des avis différents au sujetdes couleurs moutarde et grise, associées respectivement aux statuts d’étiquette Concernedet Unconcerned. Ceux de Shannon ont jugé le jaune moutarde adéquat, mais ont estiméque l’éclat du gris devait être atténué.



EUROCONTROL

Les contrôleurs de Dublin ont rencontré de sérieux problèmes avec le système d’indicationdu statut des aéronefs et l’attribution de la couleur grise aux étiquettes Unconcerned. Dansla réalité, la TMA de Dublin est gérée par plusieurs contrôleurs exploitant simultanémentdifférents postes de secteur. Les contrôleurs ont jugé que le système d’indication du statutdes aéronefs, tel qu’il était simulé, n’était pas particulièrement adapté à leurs conditions detravail. En effet, bien que certains aéronefs puissent être considérés comme Unconcernedpar rapport au secteur dont ils ont la charge, il était néanmoins important que ces aéronefssoient nettement visibles. Le gris ayant été jugé inadapté à cet effet, c’est le jaune moutardequi a été retenu pour toutes les étiquettes Concerned et Unconcerned dans la région decontrôle de Dublin. Même s’il représente une amélioration, ce choix n’a pas été perçucomme la solution idéale (voir section 5.3.1 traitant des résultats STCA). Les autresaméliorations proposées allaient du renforcement de la couleur jaune moutarde ou au choixdu blanc pour les champs Indicatif d’appel et Niveau de vol effectif (AFL). En résumé, laméthode utilisée pour identifier et visualiser le trafic aérien Concerned et Unconcerned parrapport à chaque secteur de Dublin considéré isolément, nécessite d’être étudiée plus avant.

3.1.5. ChampsLes contrôleurs ont indiqué que la couleur utilisée pour mettre en évidence le champ Indicatifd’appel (jaune) était un bon choix et qu’il convenait d’en faire aussi usage dans toutes leslistes pertinentes. Pendant la simulation (et dans le cadre du futur système), la mise enévidence de l’indicatif d’appel était, et sera, uniquement disponible entre postes de travail decontrôleur d’un même secteur. Le blanc ne se substituait pas aux mises en surbrillance del’indicatif d’appel sur les étiquettes Advance Warning lorsque ces étiquettes passaient enmode de transfert entrant, suite au transfert de contrôle par le secteur en amont. Celasignifie que, dans la pratique, le secteur récepteur n’avait pas connaissance de laproposition de transfert. Idéalement, un aéronef mis en surbrillance du fait de son statutAdvance Warning devrait passer en mode de transfert entrant (blanc) au moment dutransfert de contrôle et revenir en surbrillance une fois qu’il a été pris en charge. Lescontrôleurs ont également affirmé que la mise en surbrillance du champ d’indicatif d’appeldevrait passer au travers de tous les filtres placés à l’intérieur du secteur.

Les contrôleurs ont estimé très satisfaisant le choix du rose comme couleur de mise enévidence et en ont recommandé l’utilisation dans toutes les fenêtres concernées.

Le fait de cliquer, au moyen du bouton gauche de la souris, sur les champs interactifs del’étiquette sélectionnée provoquait l’ouverture des menus-fenêtre contextuelscorrespondants. Des valeurs par défaut avaient été définies pour les menus-fenêtrecontextuels, mais, dans certains cas, ces paramètres ne fonctionnaient pas correctement,imposant à l’utilisateur une opération de défilement inutile pour sélectionner la valeursouhaitée. Il en est résulté une certaine frustration, et un surcroît de travail pour lescontrôleurs. Le problème était encore exacerbé par le fait que certains contrôleurs nemaîtrisaient pas totalement le principe des niveaux XFL par défaut entre secteurs, de sortequ’ils l’appliquaient incorrectement. De temps à autre, des XFL sans rapport avec le secteursuivant étaient introduits, ce qui avait pour effet d’éliminer ledit secteur de la séquence. Enconséquence, l’aéronef était « radié » du secteur censé le recevoir. La « radiation », quisignifie qu’un aéronef n’entrera plus dans l’espace aérien d’un secteur déterminé, faitapparaître un indicatif d’appel de couleur verte sur l’étiquette radar du secteur où la radiationa été opérée. Les contrôleurs accusaient réception de l’information en cliquant sur l’indicatifd’appel, après quoi le statut de l’étiquette prenait la valeur Unconcerned.

Les principales observations formulées par les contrôleurs concernant les champsd’étiquette et leurs fenêtres contextuelles peuvent se résumer comme suit :



EUROCONTROL

Shannon• Le niveau de vol océanique (OFL) est trop éloigné du niveau de vol de sortie (XFL).• Lorsque les niveaux XFL et OFL ont la même valeur, l’OFL devrait se positionner par

défaut sur l’XFL et apparaître dans une couleur différente.• Lorsque le point de sortie de secteur (XPT) et le point de sortie de FIR (FXPT) sont

identiques, la valeur par défaut devrait correspondre à la dénomination du point àl’emplacement FXPT.

• La troisième ligne de l’étiquette devrait se présenter comme suit : XFL ; OFL ; FXPT ;XPT.

• Les positions respectives des champs ADES et ADEP dans la fenêtre ELW ontoccasionné une certaine confusion, notamment en ce qui concerne les départs deShannon.

• Il conviendrait d’ajouter une fonction Assume / Hold au menu de l’indicatif d’appel, afinde permettre aux contrôleurs TMA et d’approche de placer des aéronefs directementdans la liste des attentes.

• L’affichage du nombre de Mach dans l’étiquette sélectionnée est superflu.

DublinLa fonction Assume / Hold du menu de l’indicatif d’appel (évoquée ci-dessus dans lesobservations relatives à Shannon) a été abondamment testée par les contrôleurs de Dublin.Ceux-ci l’ont jugée très utile, mais étaient divisés quant à savoir si la valeur par défaut devaitêtre Assume ou Assume / Hold. Aux dires de certains, le fait d’opter pour Assume / Holdpourrait avoir comme conséquence que des aéronefs soient renvoyés par mégarde sur laliste des attentes. La question de savoir si les options Assume et Assume / Hold devaientapparaître l’une à la suite de l’autre ou séparément dans la fenêtre contextuelle n’a pasdébouché sur un consensus. D’autres évaluations seront dès lors nécessaires.

Les contrôleurs ont estimé qu’une taille d’étiquette répondant à des « exigences minimales »faciliterait le déroulement des opérations dans la région de contrôle terminale trèsfréquentée de Dublin. D’autres études et évaluations portant sur les exigences minimalesapplicables aux champs obligatoires mériteraient d’être entreprises.Les contrôleurs ont rapporté des cas où ils avaient transféré par erreur un aéronef depuisleur secteur en cliquant par inadvertance sur le bouton gauche de la souris (Action Button).L’existence d’une fonction de temporisation dans le dispositif de confirmation des ordres detransfert d’un secteur à l’autre permettrait aux contrôleurs de récupérer (Undo Transfer) unaéronef transféré par erreur.

3.1.6. Valeurs par défaut du niveau de vol de sortie (XFL)Les paramètres par défaut du XFL spécifiés dans le système électronique ont posé bonnombre de problèmes aux contrôleurs. Dans la CTA de Dublin, où les contrôleursrégionaux, d’approche et des départs se partagent l’utilisation du même espace aérien, lesrestrictions inhérentes au système ont pu être surmontées facilement. En revanche, laconfiguration plus complexe de l’ATCC de Shannon (espace aérien inférieur / supérieur),avec ses secteurs superposés, s’est avérée plus problématique à gérer. La principaledifficulté rencontrée était de savoir quel XFL il convenait d’assigner à un aéronef dont leniveau de vol demandé (RFL) impliquait le passage d’un secteur donné à celui situé justeau-dessus. Le recours au RFL permettait au secteur inférieur de faire monter l’aéronef versle secteur situé au-dessus sans la moindre coordination, tandis que l’emploi du niveaud’entrée planifié (PEL) du secteur inférieur entraînait le non-affichage de l’étiquette AdvanceWarning dans le secteur en aval jusqu’à ce que la coordination soit proposée.

La majorité des contrôleurs a déclaré avoir besoin de l’étiquette Advance Warning, mais nesouhaitait pas pour autant que le secteur inférieur puisse faire monter l’aéronef sanscoordination. Une des solutions proposées consistait à faire en sorte que le profil projetésoit affiché correctement, avec les codes « ??? » ou « XFL » dans le champ d’étiquette.



EUROCONTROL

Cette formule exige toutefois une coordination à un stade ultérieur pour chaque aéronef et aune incidence sur la charge de travail des contrôleurs.

D’autres évaluations seront nécessaires en ce qui concerne l’autorisation de faire monter lesvols au XFL approuvé, moyennant une coordination par téléphone afin de prévenir lesconflits potentiels. Les contrôleurs ont également indiqué que les montées consécutives àune coordination devraient intervenir immédiatement et coïncider avec le transfert desaéronefs.

3.1.7. Autorisations océaniquesLes contrôleurs de l’espace aérien supérieur de Shannon recevaient les messagesd’autorisation océanique (OCM) via la fenêtre d’étiquette étendue (ELW) et la liste dessecteurs (SEL). Si la majorité (75 %) d’entre eux a fait observer qu’il n’était pas évident desavoir à quel moment un aéronef avait reçu l’OCM, les contrôleurs se sont accordés àreconnaître que l’affichage des autorisations océaniques sur l’ELW entraînait une diminutionde la charge de travail. Il n’empêche toutefois qu’ils préféraient accéder aux informationsrelatives aux autorisations océaniques via la SEL.

3.1.8. VFR en routeLe système simulé utilisait des paramètres de séquence sectorielle prédéfinis pour les ATCCde Shannon et de Dublin. Il en est résulté un problème pour les vols VFR dans l’espaceaérien inférieur de Shannon, où l’exercice du contrôleur nécessitait un système pluspolyvalent et plus dynamique, excluant la définition d’un plan de vol et d’une séquence desecteurs fixes. L’ATCC de Dublin a choisi de ne pas simuler les opérations VFR.

Pour obtenir le degré de souplesse requis, le contrôleur responsable de l’espace aérieninférieur avait la possibilité de sélectionner le secteur suivant et d’envoyer des informationsanticipées (via la fonction Force ACT), si nécessaire. Cela avait pour effet de modifierl’étiquette dans le secteur amont sélectionné, son statut passant de Unconcerned (gris) àAdvance Warning (bleu clair), et de reproduire la valeur du niveau de vol autorisé (CFL)dans le champ XFL/PEL.

Dans tous les cas, cette fonctionnalité a été jugée appropriée.

3.1.9. Itinéraires directs et réacheminementsLes contrôleurs de Dublin n’ont guère eu recours à la fonction DCT, même s’ils ont jugécette option utile. En revanche, les contrôleurs de Shannon ont abondamment exploité cettefonctionnalité, en particulier dans les secteurs étendus des couches supérieures. Ils l’ontqualifiée de très utile et ont formulé les observations et recommandations suivantes à sonégard.

• La couleur était adéquate.• La prise en charge, par le système électronique, d’aéronefs acheminés en DCT et

devant traverser plusieurs limites de secteur en un bref laps de temps sera extrêmementdifficile.

• Lors de la délimitation des secteurs, il convient d’accorder une attention et un soin toutparticuliers aux courants de trafic et d’éviter au maximum les tronçons courts au seind’un secteur.

• Des problèmes sont survenus lors de l’utilisation du vecteur élastique, les contrôleurs deplanification de l’espace aérien supérieur devant fréquemment sélectionner une trèslongue distance pour visualiser le point de destination souhaité.

• Le point de destination choisi au moyen de la fonction DCT devrait apparaître dans lechamp AHDG. À l’issue d’un transfert de contrôle au secteur en aval, le point dedestination devrait apparaître dans le champ AHDG dudit secteur.



EUROCONTROL

Le vecteur élastique permettait aux contrôleurs de réacheminer un aéronef directement versn’importe quel point figurant sur l’itinéraire de vol planifié. Si le point de destinationsélectionné ne figurait pas sur le plan de vol initial, c’est le système qui se chargeait del’introduire dans le champ Assigned Heading (AHDG). Dans le futur système, lorsqu’onutilisera la fonction DCT, la coordination n’interviendra que lorsque le nouveau pointsélectionné figure dans le secteur suivant de la séquence prévue et que l’ACT est désactivé.Si un point DCT est sélectionné dans n’importe quel autre secteur, le nouvel itinéraire nefera pas l’objet d’une coordination. La trajectoire sera néanmoins actualisée et une nouvelleséquence de secteurs sera établie. Dans ce cas, le secteur suivant initial est radié et lenouveau secteur reçoit un ACT avec préavis court (en principe, après une coordination partéléphone). La « radiation », qui signifie qu’un aéronef n’entrera plus dans l’espace aériend’un secteur déterminé, fait apparaître un indicatif d’appel de couleur verte sur l’étiquetteradar du secteur où la radiation a été opérée. Les contrôleurs accusent réception del’information en cliquant sur l’indicatif d’appel, après quoi le statut de l’étiquette prend lavaleur Unconcerned.

Les contrôleurs ont affirmé que la fonction de radiation était très utile et l’indicatif d’appel decouleur verte bien perceptible. Sur le système fourni à l’IAA, une radiation déclencheral’apparition d’un message dans la fenêtre Message In. De l’avis général, le changement decouleur de l’indicatif d’appel est à la fois préférable et suffisant, toute informationsupplémentaire étant superflue ; la radiation devrait, quant à elle, s’imposer au travers detous les filtres prédéfinis.

3.1.10. Fonction « Skip »Les contrôleurs se sont déclarés parfaitement à l’aise avec la fonction de saut de secteur(skip), mais ont toutefois indiqué que son activation par le PLC ne devrait avoir lieu qu’aprèsconcertation avec l’EXC. L’étiquette radar dans le secteur concerné devrait conserver lestatut Concerned jusqu’à ce que l’aéronef ait quitté ledit secteur. Idéalement, la procédurede coordination entre les secteurs ne devrait pas être « gelée ». En outre, nonobstantl’affichage d’un message de confirmation (Confirm skip), les contrôleurs ont jugé nécessairede disposer d’une fonction Unskip.

3.1.11. Bandes de progression de volLe recours aux bandes de progression de vol dans le cadre de la simulation a donné lieu àde nombreux débats entre les équipes de projet de l’IAA et du CEE. Le système ATMCAIRDE 2000 simulé s’inspirait, pour l’essentiel, des spécifications du manuel relatif ausystème automatisé EATCHIP III. Il s’agit d’un système entièrement automatisé, conçu pourfonctionner sans bandes de progression de vol. Pour le CEE, qui s’appuyait sur une solideexpérience en la matière, l’évaluation correcte de l’IHM d’un tel système commandaitd’exclure l’utilisation des bandes de progression de vol.

De son côté, l’IAA a la responsabilité de fournir un système pleinement opérationnel et fiabledans les délais prévus. Le dispositif commandé à Airsys ATM intégrera l’ensemble desfonctions associées aux bandes de progression de vol. L’évolution du système sera plusprogressive que révolutionnaire, afin d’éviter le passage brutal à un environnement sansbandes, ce qui pourrait occasionner de sérieux problèmes. L’utilisation de bandes deprogression de vol pendant la simulation contribuerait ainsi à mieux situer le moment propiceà une migration éventuelle vers un environnement sans bandes, entièrement automatisé.

Afin de satisfaire les besoins du client et du CEE, la simulation s’est déroulée en deuxphases.



EUROCONTROL

La phase I a simulé la totalité des fonctions liées aux bandes de progression de vol, maisnon la détection de conflits à moyen terme (MTCD) ni l’affichage des risques de conflit(CRD). La coordination se faisait par téléphone, sans aucune fenêtre de coordinationIn/Out.

La phase II a simulé la détection des conflits à moyen terme (MTCD) et l’affichage desrisques de conflit (CRD). La coordination s’effectuait de manière entièrement automatisée àl’aide de fenêtres de messages In/Out, les données de coordination apparaissant dansl’étiquette radar, la fenêtre ELW et les listes de données. Aucune bande de progression devol n’a été utilisée.

Les contrôleurs se sont dits préoccupés par l’ergonomie du CWP (y compris pour ce qui estdes bandes de progression de vol) dans le nouveau système. Les postes de travail actuelsse composent d’un simple écran radar pour le contrôleur exécutif et d’un tableau deprésentation des bandes de progression de vol pour le contrôleur de planification. Au CCRde Dublin, ces tableaux sont conçus de manière à représenter géographiquement la régionde contrôle.

Le système CAIRDE 2000 attribue un écran radar aux deux contrôleurs (EXC et PLC).L’aménagement de surfaces de travail suffisantes, sur le CWP, pour intégrer le tableau deprésentation et le tapis de souris ne va pas sans poser des problèmes. Et à ces difficultéss’ajouteront celles inhérentes aux claviers. Dans l’espace aérien supérieur de Shannon, levolume du trafic rend à lui seul impossible toute sectorisation du tableau porte-strips. Lescontrôleurs ont estimé qu’il leur était impossible d’assurer à la fois la mise à jour des bandesde progression de vol et la gestion du système électronique. Dans ces conditions, lapréférence est allée au système électronique, jugé plus facile à gérer. Les contrôleurs onttrouvé que l’abandon des bandes de progression de vol améliorait considérablement letravail d’équipe entre l’EXC et le PLC au sein de chaque poste de travail. De fait, durant laphase II, qui comportait la coordination automatisée et d’autres fonctions supplémentaires,les contrôleurs ont déclaré avoir été parfaitement en mesure de gérer le trafic sans recouriraux bandes de progression de vol. En résumé, l’utilisation des bandes de progression devol ne paraît pas viable avec le nouveau système et la migration vers un environnement« sans bandes » devrait être étudiée à bref délai.

Bien qu’ayant dû surmonter divers problèmes de démarrage en rapport, notamment, avecl’impression des bandes, des erreurs dans le contenu de ces dernières et des cas de doubleemploi, les contrôleurs n’ont pas ménagé leur peine pour faire fonctionner le systèmesimulé. Leurs efforts pour gérer les deux systèmes (électronique et avec bandes deprogression de vol) tout en prenant en charge, dans de bonnes conditions de sécurité, lesimportants volumes de trafic prévus à l’horizon 2007 leur ont valu des éloges.Outre ces problèmes, les contrôleurs ont indiqué qu’il leur était difficile de prendre en chargeplus de 10 aéronefs dans un environnement mixte, avec et sans bandes de progression devol. Il s’est avéré impossible d’utiliser simultanément les étiquettes radar, les listes et lesbandes. Pendant la simulation, le PLC devait placer les bandes sur les porte-strips et lestableaux de progression de vol. Cette opération prenait un temps considérable, au détrimentde l’interaction du contrôleur avec le système. En fait, pour pouvoir actualiser les bandes, lePLC devait négliger son écran radar. Les PLC ont tous préféré faire fonctionner le systèmeélectronique via l’affichage radar plutôt que se consacrer à la mise à jour des bandes.

Les contrôleurs ont estimé que la fonction DFL (tronçon de vol dynamique) contribuait àremplacer la fonction de planification du tableau de progression de vol, tandis qu’un triadéquat opéré dans les listes (SIL, SEL, etc.) permettait de remplacer avantageusement lesbandes. Par ailleurs, en ce qui concerne le suivi des aéronefs dans les circuits d’attente, laprudence a été recommandée quant à l’utilisation de listes d’attente en remplacement desbandes de progression de vol, aussi longtemps qu’une expérience suffisante n’aura pas étéacquise et que la fonctionnalité Hold List n’aura pas fait l’objet d’une évaluation approfondie.



EUROCONTROL

Dans le cadre de la simulation, le PLC responsable de l’espace aérien supérieur deShannon n’a pas exécuté bon nombre des fonctions normales en rapport avec lesséparations, autorisations, modifications d’autorisation et révisions océaniques. Ce voletimportant des activités de contrôle devra être évalué plus avant, en particulier dans laperspective d’un environnement sans bandes de progression de vol. L’expérience acquise àla faveur de la simulation a toutefois montré que ces questions de sécurité pouvaient êtreréglées plus efficacement dans le contexte d’un système électronique sans bandes.

Si l’adoption d’un système sans support papier peut s’envisager avec une relative aisance,les contrôleurs ont insisté sur la nécessité qu’un tel système fonctionne correctement, ce quisuppose un mode de saisie des données convivial et des valeurs par défaut correctes.

3.1.12. Fenêtres contenant les listes de donnéesD’une manière générale, les différentes listes proposées ont suscité des réactions en sensdivers de la part des contrôleurs. Une faible majorité a estimé que le contenu des listesétait, certes, lisible mais pourrait être amélioré si le texte était affiché en caractères « normal– souligné » plutôt qu’en « gras ». La plupart ont reconnu que le choix de la taille desfenêtres serait meilleur encore si, dans chaque liste (excepté la liste des attentes), l’indicatifd’appel constituait l’unique champ obligatoire. Ce champ devrait être disposé à gauche,tous les autres champs étant facultatifs. Lorsque les listes sont fermées et ensuiteréouvertes, leur présentation par défaut devrait refléter les préférences définies par chaquecontrôleur.

Dans le cas des postes de travail biplaces, le PLC regardait généralement davantage leslistes que l’image radar. L’interaction avec les listes s’est révélée plus difficile à mesure quele volume de trafic et la quantité de données de listage s’y rapportant augmentaient. Bienque les listes sous forme de pages prennent plus de place sur l’écran que les listes àdéfilement, des problèmes sont fréquemment apparus en raison du masquage de certainesdonnées de vol essentielles par la fonction de défilement.

3.1.13. Liste des aéronefs en rapprochement (SIL)Les contrôleurs ont clairement exprimé leur préférence pour un champ d’indicatif d’appelobligatoire et unique (dans la SIL), complété par des options à sélectionner et un système declassement par ordre de priorité fondé sur le statut des étiquettes d’aéronefs. Lescontrôleurs de l’espace aérien supérieur de Shannon ont jugé les SIL particulièrement utilesen combinaison avec l’allocation de codes SSR pour les courants de trafic en direction del’est. Le défilement a engendré certaines difficultés au niveau de l’affichage desinformations pertinentes. Les contrôleurs de Dublin n’ont guère utilisé les SIL. Ils y ont vuune fonction utile, certes, mais non indispensable, et ont généralement préféré interagirdirectement avec l’étiquette radar.

Quant aux contrôleurs de Shannon, leur réaction au sujet de la pertinence des informationscontenues dans la SIL différait selon que leur rôle était de nature stratégique ou tactique.Constat étonnant, les contrôleurs exécutifs étaient davantage demandeurs des données SILque les contrôleurs de planification. L’une des explications possibles est que les EXCtravaillaient souvent à courte distance et ne voyaient dès lors pas toujours les aéronefsayant le statut Advance Warning. Par ailleurs, nombre de contrôleurs de planificationpréféraient utiliser la SEL plutôt que la SIL, car la première fournissait davantaged’informations à caractère optionnel, parmi lesquelles les données relatives auxautorisations océaniques.



EUROCONTROL

3.1.14. Liste des secteurs (SEL)Les contrôleurs ont réaffirmé leur préférence pour un champ d’indicatif d’appel obligatoire etunique dans la SEL, complété par des options à sélectionner et un système de classementpar ordre de priorité fondé sur le statut des étiquettes d’aéronefs. Les contrôleurs deShannon ont davantage utilisé la fenêtre SEL que leurs collègues de Dublin, qui, cette fois-ciencore, l’ont jugée utile mais non essentielle par rapport à leurs besoins.

Les contrôleurs de Shannon ont désigné les opérations de tri et de défilement comme étantà l’origine des principaux problèmes rencontrés dans l’utilisation de la liste des secteurs.Les contrôleurs ont, par moments, éprouvé des difficultés à localiser un aéronef dans laSEL. Les critères de tri définis par défaut étaient : point d’entrée (EPT), heure d’entrée(ETE) et niveau d’entrée planifié (PEL). La séquence ETE, EPT et PEL serait plusopportune.

Mais une telle mesure corrective n’empêchera pas certains problèmes de subsister. Lesavis des contrôleurs étaient mitigés quant à la mise au point d’autres méthodes de tri et dedéfilement. Un tri effectué sur la base du statut des étiquettes comporte des avantages etdes inconvénients, en particulier lorsque la fonction de défilement est utilisée. Si , parexemple, les aéronefs « pris en charge » (Assumed) étaient classés en tête de liste, ledéfilement ferait disparaître certaines des (ou toutes les) lignes de texte correspondant auxaéronefs ayant le statut Advance Warning, lesquels pourraient ne pas être visibles surl’écran radar et faire également l’objet de propositions de coordination. Une liste sous formede page, sans possibilité de défilement, serait une meilleure solution, mais aurait pourinconvénient que la SEL risquerait alors de devenir extrêmement longue et occuperait uneportion importante de la fenêtre radar. Par ailleurs, les contrôleurs n’ont pas besoin devisualiser les aéronefs ayant le statut Concerned. Cet élément contribuerait, quant à lui, àréduire la taille de la fenêtre.

3.1.15. Listes des arrivées et départsLes contrôleurs étaient partagés quant à l’utilité des listes des arrivées et départs. La listedes départs a été plus largement acceptée et jugée nettement plus utile, deux tiers descontrôleurs affirmant qu’ils l’utilisaient systématiquement ou régulièrement, contre un tiersseulement dans le cas de la liste des arrivées. Il convient cependant de noter que la listedes arrivées n’était généralement utilisée que par les secteurs d’approche ou de TMA trèsfréquentés, où la surveillance des étiquettes radar et l’interaction avec celles-ci sont, parnécessité, plus marquées. Bien que relativement satisfaits des spécifications de triappliquées aux listes des arrivées et départs, les contrôleurs ont néanmoins proposéquelques améliorations. Dans la liste des arrivées, un ordre de classement en fonction desstatuts d’étiquette Assumed, Advance Warning et Concerned serait plus indiqué, tandis quela séquence des départs de la tour de contrôle devrait actualiser automatiquement laséquence des vols dans la liste des départs.

3.1.16. Liste des attentesLa liste des attentes a été abondamment utilisée tout au long de la simulation par lescontrôleurs de Dublin. Les contrôleurs de Shannon en ont fait un usage moindre, étantdonné que seules deux des cinq organisations simulées englobaient l’espace aérieninférieur. La liste des attentes a donné toute satisfaction. Les contrôleurs l’ont trouvée à lafois claire et simple. Tout en indiquant qu’ils souhaiteraient disposer d’une fonctionnalitésimilaire sur le système CAIRDE 2000, ils ont recommandé plusieurs modifications touchantà la fois aux fonctions d’exploitation et de tri.



EUROCONTROL

Fonctions d’exploitationLa possibilité de placer un aéronef de statut Advance Warning sur la liste des attentes seraitutile en ce sens qu’elle permettrait de réserver des niveaux de vol pour les aéronefs croisantà des niveaux inférieurs à ceux occupés, au moment considéré, dans un circuit d’attente.Pour le moment, cette proposition est difficile à mettre en œuvre sur un systèmeélectronique, étant donné qu’un aéronef ayant le statut Advance Warning affiche le PEL etnon le CFL. Le menu contextuel de la liste des attentes devrait faire apparaître par défautles attentes se rapportant au secteur concerné. Idéalement, lorsqu’un aéronef évolue endessous du seuil d’attente, la liste ne devrait afficher que l’AFL.

Fonctions de triLa fonction de défilement (disponible au-delà de 15 lignes) n’était pas sûre, en ce sensqu’une liste unique de tous les aéronefs en attente (classés par circuit d’attente) masquaitsouvent des données vitales concernant des aéronefs maintenus en attente. Une liste desattentes distincte pour chaque HPT et la suppression de la fonction de défilementpermettraient de corriger ce problème. La clé de tri primaire devrait s’appliquer au CFL,suivie d’une clé de tri secondaire portant sur l’AFL. Ainsi, dans le cas où deux ou plusieursaéronefs auraient le même CFL, le tri secondaire ferait en sorte que les aéronefs soientclassés en fonction de leur AFL.

3.2. Objectif 2Évaluation de l'interface contrôleur (IHM)Évaluer l’incidence opérationnelle des outils ATC, des filets de sauvegarde et desaides à la surveillance du nouveau système.

3.2.1. Avertisseur de proximité de zone protégée (APW)Les contrôleurs ont, tous, jugé l'APW particulièrement approprié. Le jaune utilisé pour letexte se remarque très bien et le couplage de l'affichage avec l'alarme sonore prévue sur lesystème CAIRDE 2000 devrait, de l'avis général, déboucher sur un dispositif de sécurité desplus utiles.

3.2.2. Avertissement de conflit à court terme (STCA)Les contrôleurs ont, dans leur grande majorité, estimé que l'activation du STCA avaitrapidement attiré leur attention. En revanche, ils se sont montrés beaucoup plus critiquesquant au mode de visualisation des blocs de données. Pas un ne semble avoir apprécié lestyle d'affichage du STCA. Le bord rouge du bloc d'étiquette a été jugé dérangeant etinutile. La mise en évidence sur fond rouge du champ d'indicatif d'appel rendait la lecturedifficile lorsque l'étiquette affichait le statut Concerned (jaune moutarde). La superpositiondes étiquettes était une source supplémentaire d'ambiguïtés et d'irritation. Les étiquettessupprimées d'aéronefs figurant sur les listes des attentes n'affichaient aucun avertissementSTCA.

Les contrôleurs ont formulé trois recommandations importantes en ce qui concerne lescaractéristiques d'affichage du STCA :

• le symbole de position radar (RPS), le leader, le vecteur de vitesse et les points deposition antérieure devraient être affichés en rouge ;

• le RPS devrait rester visible en permanence ;• le texte du champ de l'indicatif, de l'AFL et de l'indicateur de secteur (SI) devrait toujours

apparaître en blanc sur fond de mise en évidence rouge.



EUROCONTROL

3.2.3. Tronçon de vol dynamique (DFL)Il ressort de l'utilisation faite, par les contrôleurs, de la fonction DFL que cette dernièreconstitue potentiellement un élément hautement utile du progiciel IHM. Peu utilisée dans laTMA de Dublin, cette fonction a, en revanche, été largement exploitée dans l'espace aérienplus étendu de l'ATCC de Shannon. Confrontés à des niveaux de trafic élevés, lescontrôleurs se servaient de la fonction DFL en tant qu'outil primaire pour obtenir desdonnées sur les routes, la séquence des secteurs et les conflits lorsqu'ils étaient occupés etque le recours aux autres outils et listes devenait plus problématique.

La fonction DFL a recueilli l'adhésion sans réserve de tous les contrôleurs qui y avaient eurecours. Ces derniers ont estimé qu'il s'agissait d'un outil très puissant, en particulierlorsque ladite fonction était exploitée en association avec la MTCD, auquel cas il devraitalors être possible de la sélectionner à partir de l'affichage des conflits et des risques (CRD).Si le choix des couleurs a été jugé satisfaisant, plusieurs contrôleurs ont estimé que leslignes d'affichage gagneraient à être plus fines. Les contrôleurs ont fait valoir que le DFLdevrait être actualisé en cas d'utilisation de la fonction DCT.

3.2.4. Affichage des conflits et des risques (CRD)Globalement favorables au CRD, les contrôleurs ont toutefois émis certaines réserves à sonégard. Tous sauf un ont considéré que l'outil en question était « régulièrement » ou« parfois » utile. Les contrôleurs de Shannon ont indiqué que la fonction MTCD serait trèsutile à l'appui de la planification dans les secteurs supérieurs. Elle pourrait également serévéler utile dans les secteurs inférieurs mais serait inutilisable en TMA. Il importe, pour lacrédibilité de l'outil, que les contrôleurs aient confiance dans les prévisions de conflits. Or demultiples cas ont été signalés où le système a généré un nombre trop élevé de faux risques.Il en est résulté une certaine irritation et un manque de confiance de la part des contrôleursqui, confrontés à une charge de travail élevée, ont préféré se passer de la fenêtre CRD.

À cela s'ajoute le fait que les contrôleurs ont recensé des cas où le système avait omis deprédire des situations de risque et/ou de conflit. Les intéressés sont néanmoins convenusque, moyennant une série d'améliorations au niveau de la précision de détection, del'attribution des tâches et de l'affichage des données, l'outil devrait être mieux accepté et serévéler d'une grande utilité pour aider les contrôleurs à faire face à l'augmentation prévuedes volumes de trafic.

Pour ce qui est des aspects positifs, la majorité des contrôleurs ont reconnu que lesinformations utiles concernant les risques et conflits étaient généralement données par lesoutils MTCD. D'aucuns ont estimé que la représentation du temps et de la séparation n'étaitpas toujours aisée à interpréter, probablement par manque d'entraînement et d'expérience.La plupart des contrôleurs ont indiqué que le CRD avait effectivement réduit leur charge detravail et leur avait permis de mieux sérier leurs tâches. Afin de réduire encore cette chargede travail, ils recommandent que la possibilité leur soit offerte d'interagir avec les étiquettesvia le CRD.

Les contrôleurs (en particulier les PLC) ont dû s'adapter rapidement à de nouvellesprocédures d'exploitation tout en réagissant aux avertissements MTCD. L'outil générait despré-alertes de conflits potentiels mais bien souvent, les aéronefs concernés se situaient au-delà de la distance radar sélectionnée. Les contrôleurs de planification ont donc dûapprendre à jouer avec la distance radar pour exploiter efficacement la fonction MTCD. Il enest résulté, par moments, une certaine confusion au niveau du contexte temporel danslequel ces contrôleurs opéraient. Les intéressés ont néanmoins fait valoir qu'en tant qu'outilde planification, la MTCD améliorait la capacité de traitement des conflits et pourraitutilement remplacer les bandes de progression de vol.



EUROCONTROL

3.3. Objectif 3Procédures de contrôleÉvaluer le rôle que les contrôleurs exécutifs et de planification pourraientrespectivement jouer dans le système simulé

Les contrôleurs ont estimé que les fonctionnalités devraient être identiques sur chacun despostes de contrôle de sorte qu'ils puissent organiser eux-mêmes la répartition des tâches aulieu de devoir se conformer à celle que leur impose le système. Une telle approche leurpermettrait également de modifier cette répartition des tâches en fonction de l'importance dutrafic. Les participants ont indiqué que les deux contrôleurs (PLC et EXC) étaient en mesurede fonctionner en tandem et que les rôles, tels que définis, permettaient un tel travaild'équipe.

Bien que les rôles respectifs du PLC et l'EXC aient été raisonnablement bien définis, larépartition des tâches entre les deux acteurs n'était pas toujours très claire. On peut y voir lerésultat d'une trop grande souplesse au niveau de la configuration du système ou du peu detemps accordé aux contrôleurs pour se familiariser à leur rôle dans le cadre de la simulation.Bien qu'une certaine souplesse ait été ménagée sur le plan de la répartition des tâches,certaines actions (comme la saisie du CFL), considérées comme relevant de laresponsabilité essentielle de l'un des deux contrôleurs, étaient fréquemment partagées entreles deux responsables de secteur. Sans conséquences graves, cette répartition indistinctedes tâches a toutefois engendré, par moments, une certaine confusion sur le plan desresponsabilités individuelles.

Le bien-fondé d'une telle interopérabilité a été débattu au cours des séances de débriefing,les contrôleurs étant divisés quant à la procédure à suivre pour la saisie du CFL et de l'AOC.Une partie d'entre eux a estimé que seul le contrôleur exécutif devait opérer ces saisies. Laquestion était de savoir dans quelle mesure chaque nouvelle saisie contribuait au maintiende l'image radar et si le partage de ces tâches n'était pas de nature à nuire à la perceptionque le contrôleur exécutif a de la situation générale et à la façon dont il la maîtrise.

Un examen plus approfondi de la question s'impose avant d'envisager la moindre restrictionau niveau des fonctionnalités du système. Des limitations peuvent être instaurées par lavoie de procédures de contrôle de façon à ménager une certaine souplesse dans l'attented'une évaluation complète des incidences.

Enfin, les contrôleurs s'étant accordés à reconnaître que la mise en œuvre du nouveausystème ATM se traduirait par une nouvelle répartition des tâches entre le contrôleurexécutif et le contrôleur de planification, ils ont formulé les recommandations ci-après.

ATCC de Dublin

• Le contrôleur exécutif devrait continuer à assurer le service radar tandis que lecontrôleur de planification gérera et actualisera les différentes fenêtres et listes de textequi remplaceront, à terme, les fonctions actuelles de gestion des bandes de progressionde vol.

• La répartition des rôles entre les deux contrôleurs nécessitera un nouvel examen,assorti d'une évaluation critique, lorsque la configuration définitive du système proposéaura été arrêtée.



EUROCONTROL

ATCC de Shannon

Le contrôleur exécutif devrait :

• prendre les aéronefs en charge ;• interagir avec le CFL au moment de la délivrance de l'autorisation ;• transférer les aéronefs ;• assurer l'essentiel des échanges R/T• interfacer avec le XFL au niveau de l'étiquette bleue Advance Warning.

Le contrôleur de planification devrait :

• interagir avec le PEL ;• exploiter la fonction DCT ;• prendre en charge une partie des échanges R/T ;• assurer la coordination téléphonique (s'il y a lieu) ;• interfacer avec le XFL au niveau de l'étiquette blanche Assumed ;• gérer le SEL et vérifier les autorisations océaniques.

Il conviendrait en outre que le PLC gère l'essentiel des opérations faisant intervenir lesfenêtres et listes (SEL, SIL, CRD, messages In/Out, ARR, DEP et attentes). L'EXC pourraittoutefois utiliser lui aussi ponctuellement la SIL (par ex. premier secteur d'un courantocéanique à direction de l'est) et interfacer si nécessaire avec d'autres fenêtres (ReferredCRD).

3.4. Objectif 4CoordinationÉvaluer l’incidence opérationnelle de la coordination automatisée (SYSCO)

Dans le cadre de la Phase I (SYSCO limitée), les contrôleurs de planification ont éprouvé desérieuses difficultés à assurer la coordination en ce sens qu'il s'est révélé extrêmement ardud'actualiser les bandes de progression de vol et le système électronique tout en prenant encharge les nombreux échanges téléphoniques. La difficulté s'est accrue lorsque l'on ainjecté les niveaux de trafic correspondant aux prévisions à long terme.

Dès la mise en œuvre de la SYSCO intégrale (Phase II), les contrôleurs se sont déclaréslargement en mesure de se passer des bandes de progression de vol. Les contrôleurs deDublin ont choisi de délaisser la coordination automatisée au profit de la communicationverbale et/ou par interphone. Selon eux, cette dernière méthode convenait davantage, parsa rapidité et sa convivialité, à leur approche dynamique et à leur environnement d'espaceaérien partagé. Ils ont cependant noté que les transferts intersecteurs déclenchés par erreurne pouvaient plus être annulés. Cette lacune s'est révélée particulièrement irritante, aussisera-t-il nécessaire d'y remédier sur le futur système.

Les contrôleurs de Shannon ont jugé la SYSCO extrêmement utile et estimé que lesfenêtres des messages In/Out étaient importantes pour comprendre les données decoordination. La grande majorité d'entre eux ont indiqué que les informations détaillées surles vols à l'arrivée étaient toujours disponibles dans un délai raisonnable. Bien que laprésentation des données de coordination sur les étiquettes de piste leur ait parurelativement claire et sans équivoque, les participants ont cependant recommandé d'utiliserdes couleurs différentes pour distinguer les opérations de coordination à l'entrée et à lasortie. Outre qu'elle rejoint les conclusions de précédentes simulations, cetterecommandation est corroborée par le fait que 88% des contrôleurs préféraient coordonner



EUROCONTROL

les opérations de contrôle au moyen des étiquettes de données plutôt qu'à l'aide desfenêtres de messages In/Out.

Plus de 70 % des intéressés ont indiqué que le transfert électronique était préférable auxméthodes actuelles et que les fonctions y étant associées réduisaient considérablement leurcharge de travail par rapport aux pratiques en usage. Par ailleurs, si 70 % des participantsont concédé que la possibilité de transférer un vol au secteur aval, et d'en recevoirl'acceptation, allégeait leur charge de travail par rapport aux méthodes manuelles, ils ontaussi estimé que le fait de ne pouvoir qu'accepter ou rejeter une contre-propositionconstituait une sévère restriction d'emploi. À telle enseigne que ces mêmes contrôleurs sesont déclarés dans l'impossibilité d'assurer efficacement une coordination électronique ensituation complexe.

La coordination avec les secteurs adjacents s'est révélée efficace et n'a engendré que peude problèmes. Dans le cas de secteurs scindés dans le plan vertical, plusieurs carencesd'ordre technique et opérationnel ont toutefois été mises en évidence.

La question de l'affichage d'une valeur XFL par défaut pour les vols en évolution qui passentd'un secteur supérieur à un super secteur ou qui descendent d'un super secteur pourpénétrer dans un secteur supérieur a été longuement débattue. Le fait d'utiliser une valeurXFL par défaut supérieure au niveau le plus bas du super secteur (pour le trafic en montée)ou inférieure au niveau le plus élevé du secteur supérieur (pour le trafic en descente)permettait aux contrôleurs de faire monter ou descendre les aéronefs à ces niveaux sanscoordination, et dans l'ignorance des autres aéronefs en conflit.

De l'avis des contrôleurs, la valeur du XFL par défaut devrait, pour les besoins de lacoordination, correspondre au premier niveau du secteur récepteur (ce qui aurait pour effetd'activer le statut d'étiquette Advance Warning pour ce secteur). Une coordinationtéléphonique devrait s'ensuivre pour confirmer l'acceptation. L'acceptation de lacoordination devrait sous-entendre l'autorisation de montée ou de descente. Les montées ettransferts devraient ensuite avoir lieu immédiatement.

Un soin tout particulier devra être apporté à la sectorisation, afin d'éviter que des volsn'empruntent de petits segments des espaces aériens adjacents et de permettre l'utilisationde routes directes standard sans générer d'anomalies dans la séquence des secteurs. Bienqu'il soit préférable d'envisager de larges secteurs au tracé rectiligne, la sectorisation doitégalement tenir compte des courants de trafic et des limites de capacité des secteurs, desorte qu'il sera parfois nécessaire de s'écarter du concept idéal.

En dépit de plusieurs problèmes sérieux liés à la superposition des secteurs, les contrôleursparticipant à la simulation IRL2000 se sont dits très favorables à l'utilisation de lacoordination électronique. Au nombre des avantages cités par les participants figurent laréduction sensible des échanges téléphoniques, le caractère à la fois plus expéditif et plussilencieux de la coordination et l'allègement de la charge de travail ATC.



EUROCONTROL

3.5. Objectif 5Espace aérien et procéduresApprofondir l’examen des conclusions de l’étude en temps accéléré sur leschangements envisagés dans les espaces aériens de Shannon et de Dublin. Plusspécifiquement, évaluer l’incidence opérationnelle des modifications suivantes :• redécoupage des secteurs de l’espace aérien inférieur de l’ATCC de Shannon ;• redécoupage des secteurs de l’espace aérien supérieur de l’ATCC de Shannon ;• redécoupage des secteurs de l’ATCC de Dublin ;• utilisation de secteurs à contrôleur unique à l’ATCC de Dublin• mise en œuvre d’un gestionnaire des arrivées (MAESTRO) à l’ATCC de Dublin ;• mise en exploitation de pistes parallèles à l’aéroport de Dublin ;• instauration d’une séparation de 3 MN entre les aéronefs en approche finale de la piste

10R ;• utilisation de nouveaux SID / STAR pour les aéroports nationaux et régionaux ;• repositionnement des circuits d'attente à une distance de 15 MN sur la trajectoire

d'approche finale de Shannon ;• utilisation de procédures de prise en charge du trafic en altitude à destination l’aéroport

de Belfast ;• repositionnement des points d’attente DINIL et NASRI et déplacement de la limite

occidentale de la CTA de Dublin.

3.5.1. Interface Shannon / DublinLes contrôleurs de Shannon ont considéré que l'espace aérien délégué était trop exigu etque la gestion des vols en transit avait engendré un surcroît de travail de coordination, enparticulier lors de la simulation des niveaux de trafic prévus à long terme. Tout enreconnaissant qu'une coordination plus intensive avait été requise, les contrôleurs de Dublinont fait valoir qu'une telle coordination était en fait superflue puisque les deux centrespouvaient visualiser le trafic et qu'en tout état de cause, une simple révision des Lettresd'accord et procédures de coordination intercentres actuellement en vigueur permettrait deremédier facilement au problème.

S'agissant encore de la problématique de l'espace aérien délégué, les contrôleurs deShannon ont noté que Dublin n'utilisait ledit espace que lorsque la piste 10 était en servicealors qu'eux-mêmes en avaient régulièrement besoin pour faire monter ou descendre desvols. Selon eux, l'utilisation de l'espace aérien délégué (tel que délimité pour les besoins dela simulation ou non) devrait se faire avec souplesse, sans attribution spécifique oupermanente à l'un ou l'autre des deux centres.

Dublin souligne, pour sa part, que l'extension de son espace aérien jusqu'à 0730°W (etjusqu'au FL 245) est nécessaire afin d'englober les zones tampons des nouveaux pointsd'attente ouest DINIL et NASRI. La possibilité d'utiliser ces points jusqu'au FL 240 est jugéeindispensable pour pouvoir face aux niveaux de trafic escomptés à long terme, vu que dansles conditions de trafic actuelles, les points d'attente ROKNA et TULSO, situés à l'est, sontdéjà exploités régulièrement (après coordination avec le LATCC) au-delà de leurs limitespubliées.

Pour rappel, la question de savoir comment satisfaire les exigences respectives de Shannonet Dublin n'avait pas été résolue avant le début de la simulation. Un compromis a donc ététrouvé en ce sens que les besoins spécifiques de l'espace aérien inférieur de Shannon ont



EUROCONTROL

été pris en considération dans les organisations A et B, tandis que ceux de Dublin ont étéanalysés dans les organisations C, D et E, l'espace aérien inférieur de Shannon n'étant passimulé.

La problématique de l'espace aérien délégué appelle de plus amples évaluations etéchanges de vues avant que l'on puisse prendre des décisions concrètes ou tirer desconclusions définitives sur le sujet.

3.5.2. Utilisation de procédures de prise en charge du trafic en altitude à destinationde l’aéroport de BelfastLes contrôleurs se sont accordés à reconnaître que les procédures de prise en charge dutrafic en altitude en provenance ou à destination de l'aéroport de Belfast fonctionnaient trèsbien.

3.5.3. Nouvelle sectorisation de l’espace aérien inférieur de l’ATCC de ShannonEspace aérien inférieur de Shannon (LOW)La prise en charge, dans le cadre de l'organisation A, des niveaux de trafic prévus à moyenterme dans le secteur LOW s'est révélée extrêmement ardue. Les contrôleurs ont estiméque le trafic était beaucoup trop important sur la fréquence. Leur aptitude à faire face auvolume de trafic était également entravée par les problèmes d'impression et de diffusion desbandes de progression de vol qui ont marqué toute la Phase I de la simulation. Dans cescirconstances, ils ont jugé inutile de simuler le secteur LOW sur la base des prévisions detrafic à long terme. La situation appelant clairement, selon eux, une configuration à deuxsecteurs (NLO et SLO), ils ont choisi de se concentrer sur la simulation d'une telleorganisation, sans recourir aux bandes de progression de vol.

Shannon North Low (NLO) et Shannon South Low (SLO)Cette configuration a donné de bons résultats, encore que certains contrôleurs aient proposéla création d'un troisième secteur inférieur pour prendre en charge les niveaux de traficescomptés pour Cork et Waterford. Il pourrait être préférable de revoir les dimensionsgéographiques des secteurs NLO/SLO et, surtout, de déplacer davantage vers le sud lalimite d'interface entre ces deux secteurs. Associée à une réévaluation des dimensions dusecteur TMA proposé et à un affinement des procédures ATC, cette mesure devrait suffire.

Les contrôleurs sont tous convenus de la nécessité de prévoir des points d'attente distincts(FL 150 et au-delà) pour les secteurs NLO et SLO, pour les cas où le point d'attente de TMAserait complet. Ils ont également recommandé de confier la responsabilité du trafic àl'arrivée et au départ de Kerry aux contrôleurs de la TMA.

Dans les organisations A (LOW) et B (NLO/SLO), le transfert de l'ensemble de l'espaceaérien océanique à l'ouest de la longitude 1030°W au secteur supérieur de Shannon a trèsbien fonctionné, et les contrôleurs ont recommandé que cette procédure soit mise enpratique.

TMA de ShannonLes contrôleurs ont, sans exception, confirmé la nécessité d'un secteur TMA, tout enrecommandant diverses améliorations en termes de conception et de procéduresopérationnelles.

Ainsi, le tracé de la TMA devrait être revu, avec des points d'entrée et de sortie spécifiquescorrespondant aux routes ATC actuelles dans l'espace inférieur et supérieur. La zonesimulée n'offrait guère d'espace de manœuvre dans sa partie est. De nouvelles procéduresATC sont à définir pour l'interface entre les secteurs inférieur et supérieur et la TMA. Lesnouveaux SID et STAR devront tenir compte des points d'entrée-sortie de TMA pour le traficau départ et à l'arrivée de Shannon et des aéroports régionaux. Les STAR devraient être



EUROCONTROL

utilisés de préférence au guidage vectoriel radar, ce dernier risquant de se révéler tropcomplexe. Des procédures de coordination radar seront également nécessaires.

Les contrôleurs ont indiqué que la TMA devrait être gérée par deux contrôleurs au minimum.Le point d'attente TMA devrait contrôler tous les aéronefs à partir du niveau immédiatementsupérieur au niveau de transition (TL) jusqu'au FL 140. Le contrôleur de planification de laTMA devrait attribuer les niveaux de vol aux secteurs inférieurs (NLO/SLO) à mesure de leurdisponibilité. Le TL et les niveaux en deçà devraient être placés sous le contrôle du secteurd'approche.

Approche de Shannon (APP)Confrontés aux volumes de trafic prévus pour le long terme, les contrôleurs d'approche ontrapidement connu des problèmes de surcharge R/T. Malgré une maintenance adéquate del'interface électronique entre le contrôleur et la machine, il s'est révélé impossible d'utiliseren parallèle les bandes de progression de vol, même en appliquant les niveauxprévisionnels de trafic à moyen terme. Les contrôleurs ont recommandé de confier aucontrôle d'approche la responsabilité des aéronefs en attente au TL sur les points simulésde SCARF (piste 24 en service) et FOY (piste 06 en service).

3.5.4. Repositionnement des circuits d'attente à une distance de 15 MN sur latrajectoire d'approche finale de ShannonDans les organisations A et B, les points d'entrée dans les circuits d'attente (SCARF et FOY)se situaient initialement à 15 MN sur la trajectoire d'approche finale des pistes 24 et 06,respectivement. L'emplacement de ces points a été vite jugé inadéquat en raison del'importance du brouillage d'étiquettes généré en approche finale. Les contrôleurs ontunanimement estimé qu'il convenait de décaler ces points par rapport aux trajectoiresd'approche finale et ont formulé de nombreuses propositions en ce sens. Il a finalement étédécidé de situer le point SCARF en coordonnées 5240°N 0820°W (au sud de l'approche dela piste 24) et le point FOY en coordonnées 5245°N 0924°W (au nord de l'approche de lapiste 06). À défaut d'être idéale, cette solution s'est avérée bien meilleure. Par ailleurs, uneforte proportion de contrôleurs s'est prononcée en faveur de la fixation de deux pointsd'attente pour chacune des pistes (comme à Dublin), situés de part et d'autre des approchesfinales.

3.5.5. Utilisation de nouveaux SID / STAR pour les aéroports nationaux et régionauxLes SID de Shannon se sont révélés satisfaisants à l'usage. Tous les contrôleurs ontapprécié le fait que les routes de départ soient séparées des routes d'arrivée. Les niveauxpar défaut étaient adéquats et ont rendu toute coordination superflue. Dans le scénario desimulation initial, le SID de la piste 24 pour les vols vers Dublin (DUB2B) s'effectuait par unvirage à gauche. Lorsque la sectorisation NLO/SLO a été simulée, les contrôleurs ontestimé qu'un virage à droite après le décollage aurait été plus indiqué. Les participants ontpar ailleurs suggéré qu'à l'avenir, les SID et STAR soient définis en tenant dûment comptedes secteurs NLO/SLO et TMA. De fait, en faisant aboutir les SID aux points de sortie deTMA et en faisant débuter les STAR aux points d'entrée de TMA, on aurait l'assurance quela séquence des secteurs pour le trafic à l'arrivée et au départ est correctement respectée.

Les SID et STAR des aéroports régionaux ont généralement donné toute satisfaction. Lescontrôleurs n'ont éprouvé aucune difficulté à prendre en charge les aéronefs décollant deces aéroports avec une autorisation de montée initiale jusqu'à 5000 pieds, sans coordinationpréalable. Les départs imminents de tous les aéroports apparaissaient dans les listes dedéparts des secteurs correspondants. Les aéronefs à l'arrivée étaient guidés en descentejusqu'au TL (FL 60), puis transférés au secteur d'entrée pour les vols intérieurs en Irlandeune fois dégagés du trafic au départ. De l'avis des participants, pour peu que le nouveau



EUROCONTROL

système comporte des connexions en ligne avec les aéroports régionaux et qu'unecouverture radar adéquate soit mise en place, aucune coordination ne devrait êtrenécessaire entre Shannon et lesdits aéroports. Aussi recommandent-ils d'élaborer des SIDet STAR pour tous les aéroports régionaux.

3.5.6. Nouvelle sectorisation de l’espace aérien supérieur de l’ATCC de ShannonLes contrôleurs ont estimé que le recours à des secteurs superposés constituait uneexcellente méthode pour prendre en charge des volumes de trafic élevé sur une mêmetrajectoire, et pourrait se révéler indispensable lors de l'introduction de la RVSM en Europe.L'utilisation de supersecteurs a également été jugée particulièrement bénéfique. Lesparticipants ont fait remarquer qu'en conditions d'exploitation réelles, la sélection stratégiquedes niveaux de démarcation entre secteurs superposés pourrait se révéler intéressante.

La conception des secteurs, largement analysée dans le cas de l'espace aérien deShannon, a été la principale pierre d'achoppement lors de la simulation de l'espacesupérieur. Dans ce dernier cas, les difficultés étaient toutefois davantage imputables à l'IHMqu'aux dimensions des secteurs. Au stade actuel, la sectorisation dans le plan vertical poseencore énormément de problèmes aux systèmes électroniques, en termes de prévision detrajectoires et de calcul des profils de montée et de descente. Ces difficultés ne sont passans incidences sur la détermination de la séquence des secteurs et peuvent conduire àl'émission de messages de coordination électroniques erronés.

Il est possible de pallier ces problèmes en s'appliquant, dans la conception des secteurs, àprévenir les empiètements sur les secteurs adjacents et à intégrer les courants de trafic. Ilconvient de noter toutefois que la sectorisation utilisée dans la simulation de l'espace aériensupérieur de Shannon, caractérisée par des modifications dynamiques et stratégiques pourrépondre aux impératifs du trafic océanique, sera extrêmement difficile à reproduire dans lecadre du futur système, où l'interface homme machine fonctionne essentiellement sur labase du statut d'étiquette, des couleurs, de la séquence des secteurs et de la coordinationélectronique.

3.5.7. Nouvelle sectorisation de l’ATCC de DublinDéparts de Dublin (DEP)Les contrôleurs ont très favorablement accueilli la création d'un secteur DEP. De l'avisgénéral, cette initiative permettait de réduire sensiblement la charge de travail actuelle descontrôleurs de secteur de zone au niveau de l'identification et de la prise en charge des volsau départ. Bien qu'une coordination avec les secteurs d'approche se soit révélée parmoments nécessaire pour résoudre certains conflits, les contrôleurs se sont élevés contre lapratique consistant à acheminer systématiquement les aéronefs à réaction au départjusqu'aux balises (au lieu de 3000 pieds) avant de les faire virer, afin de prévenir les conflitsavec les vols à l'arrivée ou avec le trafic dans le secteur. Un consensus s'est dégagé quantà l'adéquation de l'organisation de l'espace aérien, des procédures opérationnelles et del'interface homme machine.

Approche finale (FIN)Les contrôleurs ont également réservé un accueil favorable à l'instauration d'un secteur FIN,mais en soulignant toutefois que de nouvelles procédures et une plus grande familiarisationseront nécessaires pour en tirer plus largement parti. L'application d'une séparation de 3MN en approche finale était totalement nouvelle pour les contrôleurs d'approche. Cesderniers ont éprouvé énormément de difficultés à appliquer correctement un espacementaussi faible en raison de l'exiguïté de l'espace aérien réservé à cet effet. Le contrôleur FINavait tendance à prendre les vols en charge à une distance de plus en plus éloignée del'approche finale afin de combler les intervalles entre les aéronefs quittant les piles d'attente.Nombre de contrôleurs ont estimé que l'application d'une séparation de 3 MN en approche



EUROCONTROL

finale à partir d'une distance de 15 MN jusqu'au toucher des roues était trop restrictive. Uneformation et une expérience plus poussées seront requises pour parfaire les compétencesdes contrôleurs en matière d'application d'une séparation de 3 MN fondée sur l'utilisationstricte du contrôle de vitesse et de nouvelles procédures de travail. Les contrôleurs ontrecommandé que soit revue, et étendue, la zone dans laquelle une séparation de 3 NM estpermise.

3.5.8. Utilisation de secteurs à contrôleur unique à l’ATCC de DublinUn troisième secteur de zone baptisé « Dublin West Area » (ARW), géré par un seulcontrôleur exécutif, a été créé aux fins de prendre en charge les vols en provenance du nordet de l'ouest. Les contrôleurs de planification ont été retirés des secteurs ARN et ARS, laconfiguration comportant alors un contrôleur exécutif par secteur simulé. Le secteur ARW apris en charge l'ensemble du trafic précédemment géré par le secteur ARN (à l'exceptiondes vols sur les routes B1 et W911D) et par le secteur ARS (à l'exception des vols sur lesroutes R14 et B39). L'ARW contrôlait par ailleurs les deux points d'attente ouest (DINIL etNASRI) et assurait le transfert du trafic à l'arrivée vers les secteurs d'approche APN et APS.À première vue, les contrôleurs ont considéré que le secteur ARW fonctionnait relativementbien et déchargeait efficacement les secteurs ARN et ARS, plus encombrés. Il seratoutefois nécessaire d'analyser plus avant la manière de prendre en charge les survolssimultanés en direction du nord sur les routes UP600 et UR14. L'interface entre l'ARW ettous les secteurs adjacents de Shannon et Dublin devra également être étudiée de manièreplus approfondie.

3.5.9. Repositionnement des points d’attente DINIL et NASRI et déplacement de lalimite occidentale de la CTA de DublinLes points d'attente ouest DINIL et NASRI ont été simulés à leur nouvel emplacement danstoutes les organisations. Le déplacement de la limite occidentale de la CTA de Dublin apermis d'utiliser ces deux points d'attente ainsi que leurs zones tampons respectives. Le faitd'avoir éloigné les points DINIL et NASRI de l'aéroport a eu pour effet de faciliter le guidagevers toutes les pistes, en ménageant un espace et des délais suffisants aux contrôleursd'approche pour intégrer le trafic en provenance de ces points avec celui des points ROKNAet TULSO. Ce repositionnement a également facilité l'écoulement des courants de trafic audépart en réduisant la zone de conflit entre vols au départ et en attente.L'extension de la CTA de Dublin jusqu'à 0730°W pourrait cependant avoir des incidencesconsidérables sur les opérations dans l'espace aérien inférieur de Shannon, en particulierlorsque le trafic est maintenu au-dessus du FL 140 à DINIL et/ou à NASRI.

3.5.10. Mise en exploitation de pistes parallèles à l’aéroport de DublinLes contrôleurs ont estimé que la mise en service d'une piste parallèle était doublementavantageuse en ce sens qu'il devenait possible de faire décoller aisément tous les vols audépart et d'appliquer de manière systématique une séparation de 3 MN aux aéronefs enapproche de la piste 28L. De nouvelles procédures et modalités de travail devront toutefoisêtre préalablement définies. L'absence d'une piste parallèle à Dublin pourrait, de l'avis desparticipants, avoir des incidences considérables sur les opérations ATC, en termesd'attentes et de retards au décollage, lorsque les prévisions de trafic à long terme serontdevenues réalité.



EUROCONTROL

3.5.11. Instauration d’une séparation de 3 MN entre les aéronefs en approche finale dela piste 10RL'application d’une séparation de 3 MN entre les aéronefs en approche finale de la piste 10Rn'a, malheureusement, pas fait l'objet d'une évaluation. Le réaménagement des différentesorganisations comme suite aux difficultés techniques rencontrées au cours de la simulation aen effet entraîné l'annulation (avec le consentement du client) de l'organisation F, quiprévoyait la simulation des opérations sur les pistes 10L et 10R.

3.5.12. Mise en œuvre d’un gestionnaire des arrivées (MAESTRO) à l’ATCC de DublinLes contrôleurs se sont déclarés impressionnés par le système et ont formulé une série derecommandations quant à la manière dont il pourrait servir au mieux les besoins de Dublin.

Le système MAESTRO est actuellement en service à Copenhague où il suscite beaucoupd'éloges. L'espace aérien de Copenhague est fort semblable à celui de Dublin en ce sensque l'approche principale se situe à proximité immédiate de la limite de la FIR adjacente deMalmö. Les contrôleurs danois utilisent le système avec succès pour réguler et optimiser lescourants de trafic à l'arrivée aux points d'entrée de TMA. Les contrôleurs ont unanimementrecommandé à la Direction de l'IAA d'envoyer des groupes d'ATCO à Copenhague pour yétudier les procédures opérationnelles en usage. Une telle initiative faciliterait grandementl'élaboration de procédures spécifiques pour Dublin.

Les participants ont par ailleurs souligné que l'installation du système MAESTRO à Dublinnécessiterait le concours des ATCC de Manchester et de Londres.

Le système MAESTRO serait particulièrement utile pour créer des intervalles en approchepar lesquels s'écouleraient les courants au départ dans le cadre d'une exploitation à pisteunique.

Les contrôleurs d'approche des secteurs APN et APS ont indiqué avoir éprouvé desdifficultés à identifier rapidement les aéronefs qui leur étaient destinés lorsque le systèmefonctionnait en mode « piste ». L'affichage des indicatifs d'appel selon un code de couleurspar secteur résoudrait ce problème.

De l'avis général, le système MAESTRO devrait pouvoir fournir les temps d'attente minimumet maximum ainsi que la durée de vol de la pile d'attente à la piste. L'organisation des pointsd'attente nécessitera de nouvelles lettres d'accord avec MATCC/LATCC. La séquencedepuis les points d'attente devrait être déterminée par les secteurs d'approche, qui auraientrecours au guidage vectoriel pour optimiser l'écoulement du trafic vers les pistes.

Enfin, les contrôleurs, toutes catégories confondues, ont été unanimes à considérer quel'affichage du système MAESTRO devrait être distinct sur le pupitre de contrôle et nonintégré à l'écran radar 2k X 2k.



EUROCONTROL



EUROCONTROL

ANNEX I

IRL 2000 REAL-TIME SIMULATION

MAPS



EUROCONTROL



EUROCONTROL

Map 1: Organisation A



EUROCONTROL

Map 2: Organisation B



EUROCONTROL

Map 3: Organisation C



EUROCONTROL

Map 4: Organisation D



EUROCONTROL

Map 5: Organisation E



EUROCONTROL

Map 6: Shannon Low Level – Organisation A



EUROCONTROL

Map 7: Shannon Low Level – Organisation B



EUROCONTROL

Map 8: Dublin CTA – Organisations A,B, C, D



EUROCONTROL

Map 9: Dublin CTA – Organisation E



EUROCONTROL



EUROCONTROL

ANNEX II

IRL 2000 REAL-TIME SIMULATION

Operations Room Floorplans



EUROCONTROL



EUROCONTROL

photo 5: Ireland 2000 Real-time Simulation Operations Room



EUROCONTROL

28"

28"

28"

Strp.pr.

25.02.00/SLI

28"

28"

28"

Strp.pr.

Strp.pr.

Strp.pr.

SUPERVISION

28"28"28"28"

Hybrid

PLC

28"

EXC

EXC

Hybrid Hybrid

PLC

EXC 28"

Strp.pr.

EXC

IRL2000

TWR118.7

28"

Hybrid

APP121.4

LON118.6

LND135.57

41 42 43 44

27

9

7

10

12

25

5

3

SEA133.6

SWK132.95

DUBLI

SANN

45

28" 23

AMAN

28"

Strp.pr.

EXC11

28" EXC6

28"

Strp.pr.

PLC26

28"PLC

EXC 28"

Strp.pr.

24

4

28"

Strp.pr.

EXC

PLC

2

28" 22

28"

Strp.pr.

EXC

PLC

1

28" 21

ORG.A

129.17ARN

AMAN

28"8

121.1APN

AMAN

119.55APS

AMAN

124.65ARS

21"

N

TMA120.2

LOW124.7

DL2134.27

SH3132.15

ON

28"

Hybrid

IRL127.9

40

HStrp.pr.

FEED

AMAN AMAN

Strp.pr.

Strp.pr.

Operations Room - Organisation A



EUROCONTROL

28"

28"

28"

Strp.pr.

118.5

28"

28"

28"

Strp.pr.

Strp.pr.

Strp.pr.

SUPERVISION

EXC

PLC

28"

EXC

EXC

PLC

EXC 28"

Strp.pr.

EXC

IRL2000

DEPAPP121.4

27

9

7

10

12

25

5

3

DUBLI

SANN

28" 23

AMAN

28"

Strp.pr.

EXC11

28" EXC6

28"

Strp.pr.

PLC26

28"PLC

EXC 28"

Strp.pr.

24

4

28"

Strp.pr.

EXC

PLC

2

28" 22

28"

Strp.pr.

EXC

PLC

1

28" 21

ORG.B

129.17ARN

AMAN

28"8

121.1APN

AMAN

119.55APS

AMAN

124.65ARS

21"

N

TMA120.2

SLO124.7

DL2134.27

SH3132.15

ON

HStrp.pr.

NLO127.5

PLC

EXC

28"28"28"28"

Hybrid Hybrid Hybrid

TWR118.7

28"

Hybrid

LON118.6

LND135.57

41 42 43 44

SEA133.6

SWK132.95

45

28"

Hybrid

IRL127.9

40

FEED

AMAN AMAN

25.02.00/SLI

Strp.pr.

Strp.pr.

Operations Room - Organisation B



EUROCONTROL

28"

28"

28"

Strp.pr.

25.02.00/SLI

28"

28"

28"

Strp.pr.

Strp.pr.

Strp.pr.

SUPERVISION

PLC

28"

EXC

EXC

PLC

EXC 28"

Strp.pr.

IRL2000

27

9

7

10

12

25

5

3

DUBLI

SANN

28" 23

AMAN

28"

Strp.pr.

EXC11

28" EXC6

28"

Strp.pr.

PLC26

28"PLC

EXC 28"

Strp.pr.

24

4

28"

Strp.pr.

EXC

PLC

2

28" 22

28"

Strp.pr.

EXC

PLC

1

28" 21

ORG.C

129.17ARN

AMAN

28"8

121.1APN

AMAN

119.55APS

AMAN

124.65ARS

21" MAE

N

SPB135.22

SPA135.6

DL2134.27

SH2132.15

ON

HStrp.pr.

BR3131.15

PLC

EXC

121.87FIN

EXC

EXC

28"28"28"28"

Hybrid Hybrid

TWR

28"

Hybrid

LON118.6

LND135.57

41 42 43 44

SEA133.6

SWK132.95

45

28"

Hybrid

127.9

40

FEED

AMAN AMAN

Strp.pr.

Hybrid

118.7IRL

Strp.pr.

Operations Room - Organisation C



EUROCONTROL

28"

28"

28"

Strp.pr.

25.02.00/SLI

28"

28"

28"

Strp.pr.

Strp.pr.

Strp.pr.

SUPERVISION

PLC

28"

EXC

EXC

PLC

EXC 28"

Strp.pr.

IRL2000

27

9

7

10

12

25

5

3

DUBLI

SANN

28" 23

AMAN

28"

Strp.pr.

EXC11

28" EXC6

28"

Strp.pr.

PLC26

28"PLC

EXC 28"

Strp.pr.

24

4

28"

Strp.pr.

EXC

PLC

2

28" 22

28"

Strp.pr.

EXC

PLC

1

28" 21

ORG.D

129.17ARN

AMAN

28"8

121.1APN

AMAN

119.55APS

AMAN

124.65ARS

21" MAE

N

SPF135.22

CK1135.6

SPE134.27

DL1132.15

ON

HStrp.pr.

GP1131.15

PLC

EXC

121.87FIN

EXC

EXC

28"28"28"28"

Hybrid Hybrid

TWR

28"

Hybrid

LON118.6

LND135.57

41 42 43 44

SEA133.6

SWK132.95

45

28"

Hybrid

127.9

40

FEED

AMAN AMAN

118.5DEPEXC

Strp.pr.

Hybrid

118.7IRL

Strp.pr.

Operations Room - Organisation D



EUROCONTROL

28"

28"

28"

Strp.pr.

28"

28"

28"

Strp.pr.

Strp.pr.

Strp.pr.

SUPERVISION

28"

EXC

EXC

PLC

EXC 28"

Strp.pr.

IRL2000

13

9

7

10

12

25

5

3

DUBLI

SANN

28" 23

AMAN

28"

Strp.pr.

EXC11

28" EXC6

28"

Strp.pr.

36

28"PLC

EXC 28"

Strp.pr.

24

4

28"

Strp.pr.

EXC

PLC

2

28" 22

28"

Strp.pr.

EXC

PLC

1

28" 21

ORG.E

136.05ARW

AMAN

28"8

129.17ARN

AMAN

119.55APS

AMAN

124.65ARS

21" MAE

N

GR1135.22

BN1135.6

GN1134.27

SPC132.15

ON

HStrp.pr.

SPD131.15

PLC

EXC

121.87FIN

EXC 118.5DEP

EXC

121.1APN

EXC

EXC

28"28"28"28"

Hybrid Hybrid

TWR

28"

Hybrid

LON118.6

BST135.57

41 42 43 44

SEA133.6

SWK133.0

45

28"

Hybrid

127.9

40

FEED

AMAN AMAN

25.02.00/SLI

Strp.pr.

Hybrid

118.7IRL

Strp.pr.

Operations Room - Organisation E

EUROCONTROL · EUROCONTROL EXPERIMENTAL CENTRE IRELAND 2000 REAL-TIME SIMULATION EEC Report No. 366...

Documents

Transcript of EUROCONTROL · EUROCONTROL EXPERIMENTAL CENTRE IRELAND 2000 REAL-TIME SIMULATION EEC Report No. 366...