The full report

Transcription

The full report

EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION
EUROCONTROL
EUROCONTROL EXPERIMENTAL CENTRE
IRELAND 2000
REAL-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 any
form without the Agency’s permission.
The views expressed herein do not necessarily reflect the official views or policy of the Agency.
REPORT DOCUMENTATION PAGE
Reference:
EEC Report No.366
Originator:
EEC – OPS
(Operational Services)
Security Classification:
Unclassified
Originator (Corporate Author) Name/Location:
EUROCONTROL Experimental Centre
Centre de Bois des Bordes
B.P.15
F – 91222 Brétigny-sur-Orge CEDEX
FRANCE
Telephone : +33 (0)1 69 88 75 00
Sponsor (Contract Authority) Name/Location:
Irish Aviation Authority
Aviation House
Hawkins Street
Dublin 2
Ireland
Telephone: + 353 1 6031100 / 6718655
Sponsor:
Irish Aviation Authority (IAA)
TITLE:
IRELAND 2000 (IRL2000) REAL-TIME SIMULATION
Author
D. HOULIHAN
EATMP Task
Specification
-
Date
09/01
Pages
xii + 126
Project
SIM-S-E1_IRLIRL2000
Figures
21
Tables
4
Task No. Sponsor
-
Appendix
2
References
8
Period
1999 - 2000
Distribution Statement:
(a) Controlled by:
Manager - Simulation Programme
(b) Special Limitations: None
(c) Copy to NTIS:
YES / NO
Descriptors (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 Aviation
Authority. The study aimed to assist the IAA in preparing for the commissioning of their new Civil Aviation
Integrated Radar Display Equipment (CAIRDE 2000), using an advanced ATM system. The study evaluated
the operational impact of the HMI (Human Machine Interface) and assessed the potential roles of
Executive and Planning controllers in the new system. Secondary objectives focused on sectorisation
configurations 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. Phase
II assessed a more automated system without flight progress strips while introducing System Supported
Co-ordination (SYSCO) and Medium Term Conflict Detection (MTCD). The airspace tested included
Enroute, TMA, Approach and Departure sectors as well as the Oceanic interface with the Shanwick
Oceanic Control Area (OCA). Traffic samples representing forecast levels up to 2007 were simulated.
Ireland 2000 Real-Time Simulation
EUROCONTROL
SUMMARY
The IRL2000 real-time simulation took place at the EUROCONTROL Experimental Centre
between March 6th and March 31st 2000. The Irish Aviation Authority (IAA) plans to implement a
new ATM System – CAIRDE 2000 [Civil Aviation Integrated Radar Display Equipment]. This
system will enable the Authority to provide safe and cost effective services to its customers in the
first 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, offering
optimised system support for the controller (in terms of safety, reliability and flexibility), while
endeavouring 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 IAA
Training Centre) participated in the IRL2000 simulation. The controllers gained hands-on
experience of the proposed CAIRDE 2000 system during a total of 98 hours of simulation time
provided during the acceptance, training and measured exercise evaluation periods. The high
degree of Operational Controller input to (and their improved knowledge of) the new system
functionality will prove extremely beneficial to the IAA before system implementation.
Five simulated organisations evaluated the operational impact of the HMI (Human Machine
Interface) and assessed the potential roles of Executive and Planning controllers in the new
system. Simulation design complemented the previous fast-time simulation of Irish Airspace (EEC
Task No. F01/EEC Note No. 20/97) with secondary objectives focusing on sectorisation
configurations 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-button
mouse, the main features of the controller interface were the inclusion of electronic System
Supported Co-ordination (SYSCO), Medium Term Conflict Detection and Safety Nets such as
Short Term Conflict Alert and Area Proximity Warning. Valuable data on the effective use of list
information, track label interaction and the use of colour in an automated system (with and without
flight progress strips) was obtained which will assist the IAA in specifying the new features and
functionality of the CAIRDE 2000 system.
The simulation of various airspace and sectorisation configurations also provided worthwhile
assistance towards resolving problems that will exist with vertical sectorisation plans and label
state functionality as designed and defined by the manufacturer.
To conclude, the simulation was extremely important to Ireland. As the IAA looks to the installation
of a new ATC system in the next few years, the active involvement of the controllers in the design
and evaluation of the system and airspace proposals was of enormous value for the long-term
success of the CAIRDE 2000 project. The simulation output will be a significant contribution to the
new system specification.
EEC Report No. 366
v
EUROCONTROL
ACKNOWLEDGEMENTS
The members of the EUROCONTROL project team wish to express their appreciation for the assistance
afforded them by the Irish Aviation Authority (IAA) during the preparation and testing phases of the IRELAND
2000 real-time simulation. A special thanks to Messrs. Paul Conroy, Niall McGrath, Pat McCarthy and Willie
Fuller 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 very
much 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 the
IRL2000 project. In particular Jean-Philippe Rafidison the Simulation Technical Co-ordinator who
efficiently 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 for
their 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 provided
the results to be found in this report.
Photo 1: Ireland 2000 Real-time Simulation – EEC, Brétigny: 6th to 31st March 2000
vi
EEC Report No. 366
EUROCONTROL
TABLE OF CONTENTS
LIST OF FIGURES......................................................................................................................................... VIII
LIST OF TABLES .......................................................................................................................................... VIII
ANNEX I - MAPS ........................................................................................................................................... VIII
ANNEX II - OPERATIONS ROOM FLOORPLANS....................................................................................... VIII
LIST OF GRAPHS ........................................................................................................................................... IX
LIST OF PHOTOS............................................................................................................................................ IX
ACRONYMS AND ABBREVIATIONS.............................................................................................................. X
REFERENCES ................................................................................................................................................ XII
1. INTRODUCTION.........................................................................................................................................1
2. IRELAND 2000 - SIMULATION OBJECTIVES..........................................................................................2
3. IRELAND 2000 - SIMULATION CONDUCT ..............................................................................................3
3.1. AIRSPACE ...........................................................................................................................................3
3.2. TEMPORARY SEGREGATED AREAS...............................................................................................3
3.3. TRAFFIC SAMPLES............................................................................................................................4
3.4. TRAFFIC SAMPLE ANALYSIS............................................................................................................4
3.5. ORGANISATIONS ...............................................................................................................................5
3.6. EXERCISE PROGRAMME..................................................................................................................7
3.7. SIMULATED ATC SYSTEM ................................................................................................................8
3.8. CONTROLLER WORKING POSITION ...............................................................................................9
3.9. ATC PROCEDURES AND CONTROLLER TASKS ..........................................................................11
4. RESULTS - OBJECTIVE 1.......................................................................................................................14
4.1. INTRODUCTION ...............................................................................................................................14
4.2. GENERAL HMI RESULTS.................................................................................................................15
4.3. DATA INPUT AND WINDOWS MANAGEMENT RESULTS .............................................................18
4.4. LABEL AND TRACK RESULTS ........................................................................................................19
4.5. FLIGHT PROGRESS STRIPS...........................................................................................................25
4.6. DATA LIST WINDOWS......................................................................................................................26
5.1. INTRODUCTION ...............................................................................................................................35
5.2. AREA PROXIMITY WARNING (APW) ..............................................................................................35
5.3. SHORT TERM CONFLICT ALERT (STCA) ......................................................................................35
5.4. DYNAMIC FLIGHT LEG (DFL) ..........................................................................................................36
5.5. CONFLICT AND RISK DISPLAY (CRD) ...........................................................................................37
6.1. INTRODUCTION ...............................................................................................................................43
6.2. CONTROLLER ROLE RESULTS ......................................................................................................44
7.1. INTRODUCTION ...............................................................................................................................48
7.2. IRL2000 ENVIRONMENT..................................................................................................................48
7.3. CO-ORDINATION RESULTS ............................................................................................................51
8.1. INTRODUCTION ...............................................................................................................................53
8.2. SHANNON / DUBLIN INTERFACE RESULTS..................................................................................54
8.3. SHANNON SPECIFIC OBJECTIVES RESULTS ..............................................................................55
8.4. DUBLIN SPECIFIC OBJECTIVE RESULTS .....................................................................................58
9. CONCLUSIONS AND RECOMMENDATIONS ........................................................................................62
9.1. OBJECTIVE 1 ....................................................................................................................................62
9.2. OBJECTIVE 2 ....................................................................................................................................71
9.3. OBJECTIVE 3 ....................................................................................................................................72
9.4. OBJECTIVE 4 ....................................................................................................................................74
9.5. OBJECTIVE 5 ....................................................................................................................................75
TRADUCTION EN LANGUE FRANÇAISE DU RESUME, DE L’INTRODUCTION, DES OBJECTIFS,
DES CONCLUSIONS ET RECOMMANDATIONS..........................................................................................81
ANNEX I .........................................................................................................................................................107
ANNEX II ........................................................................................................................................................119
EEC Report No. 366
vii
EUROCONTROL
LIST OF FIGURES
Figure 1:
Figure 2:
Figure 3:
Figure 4:
Figure 5:
Figure 6:
Figure 7:
Figure 8:
Figure 9:
Figure 10:
Figure 11:
Figure 12:
Figure 13:
Figure 14:
Figure 15:
Figure 16:
Figure 17:
Figure 18:
Figure 19:
Figure 20:
Figure 21:
Radar Window .......................................................................................................................... 14
Example of “Unconcerned” labels ............................................................................................ 16
Example of “Advance Warning” label ....................................................................................... 16
Example of “Assumed” label..................................................................................................... 16
Example of “Concerned” label .................................................................................................. 17
Example of Selected label format............................................................................................. 17
Extended Label Window (ELW)................................................................................................ 17
Three-button mouse ................................................................................................................. 18
Example of Sector Inbound List (SIL)....................................................................................... 28
Sector List (SEL)....................................................................................................................... 30
Example of Arrival List .............................................................................................................. 31
Example of Departure List ........................................................................................................ 31
Example of Hold List................................................................................................................. 33
Example of APW Display.......................................................................................................... 35
Conflict and Risk Display.......................................................................................................... 37
Parameters used for Conflict and Risk Warnings..................................................................... 38
Co-ordination Horizontal Sector Boundary............................................................................... 49
Co-ordination Vertical Sector Boundary ................................................................................... 49
Co-ordination Super Sector with Vertical Boundaries .............................................................. 50
Example of Message-Out Window ........................................................................................... 51
Example of Message-In Window .............................................................................................. 51
LIST OF TABLES
Table 1: Temporary Segregated Areas ........................................................................................................ 3
Table 2: Traffic Sample Percentage Growth Rates...................................................................................... 4
Table 3: Hold Stack Allocation...................................................................................................................... 7
Table 4: Exercise Programme ...................................................................................................................... 8
ANNEX I - MAPS
Map 1: Organisation A .............................................................................................................................. 109
Map 2: Organisation B .............................................................................................................................. 110
Map 3: Organisation C.............................................................................................................................. 111
Map 4: Organisation D.............................................................................................................................. 112
Map 5: Organisation E .............................................................................................................................. 113
Map 6: Shannon Low Level – Organisation A .......................................................................................... 114
Map 7: Shannon Low Level – Organisation B .......................................................................................... 115
Map 8: Dublin CTA – Organisations A,B, C, D......................................................................................... 116
Map 9: Dublin CTA – Organisation E ....................................................................................................... 117
ANNEX II - OPERATIONS ROOM FLOORPLANS
Operations Room - Organisation A .......................................................................................................... 122
Operations Room - Organisation B .......................................................................................................... 123
Operations Room - Organisation C .......................................................................................................... 124
Operations Room - Organisation D .......................................................................................................... 125
Operations Room - Organisation E .......................................................................................................... 126
viii
EEC Report No. 366
EUROCONTROL
LIST OF GRAPHS
Graph 1:
Graph 2:
Graph 3:
Graph 4:
Graph 5:
Graph 6:
Graph 7:
Graph 8:
Graph 9:
Graph 10:
Graph 11:
Graph 12:
Graph 13:
Graph 14:
Graph 15:
Graph 16:
Graph 17:
Graph 18:
Graph 19:
Graph 20:
Label Selection Difficulty ...........................................................................................................19
OCM Accessibility......................................................................................................................23
Displayed List Items ..................................................................................................................27
Displayed SIL Information .........................................................................................................28
SIL Information - PLC ................................................................................................................29
SIL Information - EXC................................................................................................................29
Input - SIL or Radar Label .........................................................................................................31
Use of Arrival List ......................................................................................................................32
Use of Departure List.................................................................................................................32
Use of Hold List .........................................................................................................................34
Legibility of STCA Label Block ..................................................................................................36
CRD Tools Usefulness ..............................................................................................................39
MTCD Tools Accuracy...............................................................................................................40
CRD Priority...............................................................................................................................40
CRD Prediction Failure..............................................................................................................41
CRD – PLC Workload Reduction ..............................................................................................41
MTCD Situational Awareness ...................................................................................................42
MTCD Safety .............................................................................................................................42
PLC/EXC Teamwork .................................................................................................................44
PLC/EXC Task Allocation..........................................................................................................45
LIST OF PHOTOS
th
st
Photo 1: Ireland 2000 Real-time Simulation – EEC, Brétigny: 6 to 31 March 2000................................. vi
Photo 2: Ireland 2000 Real-time Simulation Operations Room ..................................................................10
Photo 3: Example of Dublin ATCC Controller Working Positions (CWP) ...................................................46
Photo 4: Example of Shannon ATCC Controller Working Positions (CWP) ...............................................47
Photo 5: Ireland 2000 Real-time Simulation Operations Room ................................................................121
EEC Report No. 366
ix
EUROCONTROL
ACRONYMS AND ABBREVIATIONS
Abbreviation
x
Definition
Abbreviation
Definition
AB
Action Button
EXC
Executive Controller
ACT
Activation Message
FDPS
Flight Data Processing System
ADEP
Aerodrome of Departure
FIN
Final Approach Sector [Dublin]
ADES
Aerodrome of Destination
FIR
Flight Information Region
AFL
Actual Flight Level [SSR Mode C]
FL
Flight Level
AHDG (ahdg)
Assigned Heading
FPL
Flight Plan
AIP
Aeronautical Information Publication
Ft (ft)
Feet
AMAN
Arrival Manager
FXPT
FIR Exit Point
AMSL
Above Mean Sea Level
GND
Ground
APN
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 Interface
APW
Area Proximity Warning
HPT
Holding Point
ARC (arc)
Assigned Rate of Change [i.e. climb/descent]
IAA
Irish Aviation Authority
ARN
Dublin North Area Sector
IAC
Irish Air Corps
ARR
Arrival List [Window]
IATMS
Irish Air Traffic Management System
ARS
Dublin South Area Sector
IB
Information Button
ARW
Dublin West Area Sector
ICAO
International Civil Aviation Organisation
ASP (asp)
Assigned Speed
IPAS
Integrated (data) Preparation and Analysis
System
ASSR
Assigned SSR Code
IRL
Ireland Feed Sector
ATC
Air Traffic Control
ISA
Instantaneous Self Assessment [Workload
Model]
ATCC
Air Traffic Control Centre
LATCC
London Air Traffic Control Centre
ATCO
Air Traffic Control Officer
LND
Land End Feed Sector
ATM
Air Traffic Management
LOA (LoA)
Letters of Agreement
BB1
Baban 1 Sector [Shannon High-level]
LON
London Feed Sector
BST
Brest Feed Sector
LOW
Shannon Low Level Sector
CAIRDE
Civil Aviation Integrated Radar Display
Equipment
MACC
Manchester Area Control Centre
CBT
Computer Based Training
MAE
Maestro Master Position
CFL
Cleared Flight Level
MAESTRO
Moyen d’Aide a l’Ecoulement Sequence du
Traffic avec Recherche d’Optimisation
CRD
Conflict and Risk Display
MATCC
Manchester Air Traffic Control Centre
CRNA/O
Centre en Route de la Navigation Aerienne
Ouest
MATS
Manual of Air Traffic Services
CTA
Control Area
MOA4
Military Operations Area 4
CWP
Controller Working Position
MOA6
DATCC
Dublin Air Traffic Control Centre
MOA7
DCT
Direct
MTCD
Medium Term Conflict Detection
DEP
Dublin Departure
Mhz
Mega Hertz
DEP
Departure List [Window]
N
North
DFL
Dynamic Flight Leg
NAT
North Atlantic Track
DL1
Dolip 1 Sector [Shannon High-level]
NLO
Shannon North Low Sector
DL2
Dolip 2 Sector [Shannon High-level]
NM (nm)
Nautical Miles
DUB
Dublin VOR
No.
Number
E
East
OCA
Oceanic Control Area
EAT
Estimated Approach Time
OCM
Oceanic Clearance Message
EATCHIP
European Air Traffic Control Harmonisation
and Integration Programme
ODS
Operator Display System
EEC
Eurocontrol Experimental Centre
OFL
Oceanic Flight Level
EID5
Danger Area 5
OLDI
On-line Data Interchange
EID6
Danger Area 6
Org.
Organisation
ELW
Extended Label Window
PEL
Planned Entry Level
EEC Report No. 366
Abbreviation
Definition
EUROCONTROL
Abbreviation
Definition
PLC
Planning Controller
SOTA
Shannon Oceanic Transition Area
POACC
Prestwick Oceanic Air Traffic Control
Centre
SPA
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 Radar
RPS
Radar Position Symbol
STAR(S)
Standard Arrival Route(s)
RVSM
Reduced Vertical Separation Minima
STCA
Short Term Conflict Alert
Rwy
Runway
STNA
Service Technique de la Navigation
Aerienne
SATCC
Shannon Air Traffic Control Centre
SWK
Shanwick Feed Sector
SB
Special Button
SYSCO
System Supported Co-ordination
ScATCC
Scottish Air Traffic Control Centre
TL
Transition Level
ScOACC
Scottish and Oceanic Area Control
Centre
TMA
Terminal Area
SEA
Irish Sea Feed Sector
TMA
Shannon TMA Sector
SEL
Sector List [Window]
TSA
Temporary Segregated Area
SFC
Surface [Ground Level / Sea Level]
TWR
Tower Feed Sector [Dublin]
SH2
Shannon 2 Sector [Shannon High-level]
UIR
Upper Information Region
SH3
Shannon 3 Sector [Shannon High-level]
UTA
Upper Terminal Area
SI
Sector Indicator [Co-ordination Partner]
VFR
Visual Flight Rules
SID(S)
Standard Instrument Departure(s)
VHF
Very High Frequency
SIL
Sector Inbound List [Window]
VOR
VHF Omni Range
SLO
Shannon South Low Sector
W
West
SOCA
Shanwick Oceanic Control Area
XFL
Exit Flight Level
SOT
SOTA Feed Sector
XPT
Exit Point
EEC Report No. 366
xi
EUROCONTROL
REFERENCES
[1]
Ireland 2000 Real-time Simulation Facility Specification Part 1 – Operational Conduct and
Analysis.
[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.
xii
EEC Report No. 366
1.
EUROCONTROL
INTRODUCTION
The IRL2000 real-time simulation took place at the EUROCONTROL Experimental Centre
between March 6th and March 31st 2000. The simulation was designed to meet the
requirements of the Irish Aviation Authority (IAA).
This report describes the objectives, working organisations and parameters used in the
simulation, 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 meets
EATCHIP requirements it utilises 1980’s technologies and is not capable of expansion and of
incorporating new technologies such as HMI and modern ATC tools.
The IAA plans to implement a new ATM System (CAIRDE 2000) which will enable the
Authority to provide safe and cost effective services to its customers in the first decade of the
new millennium, in line with the forecast growth in air traffic.
The simulation evaluated the operational impact of the HMI (Human Machine Interface) and
assessed the potential roles of Executive and Planning controllers in the new system.
Secondary objectives focused on sectorisation configurations and operating procedures
specific to Shannon and Dublin air traffic control centres.
The airspace simulated included Enroute, TMA, Approach and Departure sectors as well as
the Oceanic interface with the Shanwick Oceanic Control Area (OCA).
The simulation was divided into two phases. The first phase assessed a flight progress strip
environment with co-ordination by telephone. The second phase assessed a more
automated system without flight progress strips while introducing System Supported Coordination (SYSCO) and Medium Term Conflict Detection (MTCD).
This simulation is extremely important to Ireland. As the IAA looks to the installation of a new
ATC system in the next few years, the active involvement of the controllers in designing and
evaluating the system and airspace proposals is essential to the long term success of the
CAIRDE 2000 project.
EEC Report No. 366
1
EUROCONTROL
2.
IRELAND 2000 - SIMULATION OBJECTIVES
The simulation objectives include an overall high-level evaluation of the HMI and working
methods as well as station objectives specific to Shannon ATCC and Dublin ATCC
operations. For each objective, a short piece of italic text has been added to give a more
precise 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 and
operational suitability of the CAIRDE 2000 HMI as simulated with paper-strips. The EEC
will additionally provide a facility to simulate an enhanced automated system that will
enable the client to preview possible future developments of the system.
2. Assess the operational impact of the new system ATC Tools, Safety Nets and
Monitoring Aids.
To gather subjective feedback and system recordings on the usability and utility of the
new ATC tools provided.
3. Evaluate the potential roles of Executive and Planning Controllers in the simulated
system.
To obtain controller feedback on a proposed distribution of work tasks between
Executive and Planning controllers and, if necessary, to compare this configuration with
other configurations proposed during the simulation based on the experience acquired
from 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 recordings
on the usability and operational utility of SYSCO, both with partial functionality and
paper-strips, and with added functionality in a strip-less environment.
5. Investigate further the findings of the fast-time study regarding airspace changes
to both Shannon and Dublin. Specifically to assess the operational impact of the
following changes:
2
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.
EEC Report No. 366
3.
IRELAND 2000 - SIMULATION CONDUCT
3.1.
AIRSPACE
EUROCONTROL
The simulated airspace was divided into either “Measured” or “Feed” sectors. Measured
sectors represented the study airspace of the simulation and were simulated as realistically
as possible. Feed sectors provided a suitable interface with the surrounding airspace
without representing in full the actual sectorisation.
The measured sectors included the entire airspace managed by the IAA. This includes
delegated airspace from LATCC, MACC and ScOACC to Dublin ATCC together with
delegated 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 was
represented by a feed.
TWR (Dublin Tower) handled departure and arrival traffic at Dublin. IRL (Ireland) handled all
arrival and departure traffic at Shannon, Cork and the regional airports and also provided the
Shannon interface to Dublin in those organisations where Shannon Low-Level was not
simulated.
As the feed sectors in the simulation combine a number of separate sectors, the sector
boundaries 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 Simulation
Facility Specification Part 1 – Operational Conduct and Analysis [Reference 1].
3.2.
TEMPORARY SEGREGATED AREAS
Temporary segregated areas include military activity areas, danger areas and prohibited
areas as defined in AIP–Ireland. Video maps were used to represent all temporary
segregated areas. The Area Proximity Warning (APW) feature was evaluated for EID5,
MOA6 and MOA7, however the military airspace was considered to be inactive in all
organisations.
These areas were defined as follows:
Reference
EID5
EID6
R15
R16
MOA4
MOA6
MOA7
Vertical Limits
GND / FL140 (for APW test purposes)
GND / 8000 ft AMSL
GND / 2000 ft AMSL
GND / FL100
GND / FL100
FL330 / FL380 (for APW test purposes)
FL300 / FL360 (for APW test purposes)
Table 1: Temporary Segregated Areas
EEC Report No. 366
3
EUROCONTROL
3.3.
TRAFFIC SAMPLES
In order to enable a realistic replication of existing operations within the simulated airspace
the 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 traffic
recording from 22 and 29 August 1998 and 2 three-hour sets of eastbound NAT traffic
recordings from 11 and 12 July 1998. The Dublin traffic sample was based on a three-hour
set 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 Traffic
Forecasting 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 Term
European
Domestic
30%
Long Term
European
Domestic
85%
and
Transatlantic
20%
and
Transatlantic
45%
Table 2: Traffic Sample Percentage Growth Rates
For training purposes traffic samples representing 50% of the Medium Term were used.
Reduced Vertical Separation Minima (RVSM), above FL290 and up to FL420, were assumed
to be in force in all exercises as they already exist for Shannon High-Level sectors and
should be in place for all Irish Airspace by year 2002.
3.4.
TRAFFIC SAMPLE ANALYSIS
Normally the methodology for traffic sample analysis is based on the identification of suitable
simulation 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:
4
•
Shannon High-Level Westbound NAT traffic require an Oceanic Clearance which both
restricts and ensures their entry to Oceanic airspace in terms of exit point, time, flight
level and speed.
•
Shannon High-Level Eastbound NAT traffic enter the Shannon FIR/UIR based on similar
operating procedures applied on their departure from Continental American airports.
•
Enhancement of the above NAT traffic to Medium Term and Long Term forecast levels
was best achieved by the Shannon project team whose expertise and skill in the
application of oceanic clearance procedures was vital.
•
The Dublin project team divided the Dublin traffic sample into three overlapping parts
that best represented busy departure, arrival and mixed flows.
EEC Report No. 366
EUROCONTROL
•
Domestic traffic between Dublin, Shannon and the regional airports was tailored to suit
the requirements of the simulated organisations.
•
As Shannon and Dublin traffic was simulated in all exercises, simulation start times for
Dublin traffic ware adjusted to fit the start times applied for Shannon Eastbound and
Westbound NAT traffic.
It must be noted, however, that the IPAS tool was used very effectively to ensure accurate
profile validation and correct sector sequence.
3.5.
ORGANISATIONS
Initially, six airspace organisations were prepared (Org. A-F). Each organisation incorporated
aspects derived from the results of the EEC Fast-time Airspace Model Simulation of Irish
Airspace - EEC Note No. 20/97 - [Reference 2].
During the course of the simulation Organisation F was dropped with the agreement of the
client, in order to ensure a more thorough evaluation and analysis of the first five
organisations.
The basic elements of the simulated organisations are described below.
3.5.1.
Organisation A
Organisation A simulated a westerly flow of oceanic traffic (NAT) in a Shannon High-level
sectorisation of the Shannon UTA that included the northern portion of the Shannon Oceanic
Transition 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 ensure
that controllers could cope in a two-sector High-level configuration with medium and long
term forecast traffic levels.
However, the interface from Shannon Low-level (LOW) to the High-level sectors (SH3 and
DL2) 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. Standard
Arrivals (STARS) to Dublin Runway 10R were to the western holding stacks at DINIL and
NASRI. 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. Standard
Arrivals (STARS) to Dublin Runway 28L were to the eastern holding stacks at ROKNA and
TULSO. 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 the
application of 3nm separation between aircraft on final approach.
See Maps - Annex I: Map 1 - Organisation A.
EEC Report No. 366
5
EUROCONTROL
3.5.2.
Organisation B
Organisation B simulated the same westerly flow of oceanic traffic (NAT) and same Shannon
High-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) to
the 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 C
Organisation C simulated the same westerly flow of oceanic traffic (NAT) in a Shannon Highlevel five-sector configuration that included the northern portion of SOTA airspace. Shannon
Low-level was not simulated.
Dublin evaluated the introduction of a Final Approach sector (FIN) and the MAESTRO arrival
manager. 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 D
Organisation D simulated an easterly flow of oceanic traffic (NAT) in a Shannon High-level
five-sector configuration of SOTA airspace that included the southern part of the Shannon
UTA.
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, Dublin
simulated the introduction of a parallel runway (Runway 10L/28R) in some exercises. New
SIDS were described for Runway10L/28R. This runway was designated solely for departing
traffic when parallel runways were in use. Runway 10R/28L was designated for arriving
traffic in all exercises.
See Maps - Annex I: Map 4 - Organisation D.
6
EEC Report No. 366
3.5.5.
EUROCONTROL
Organisation E
Organisation E simulated a westerly flow of oceanic traffic (NAT) in a Shannon High-level
five-sector configuration of SOTA airspace that included the southern part of the Shannon
UTA.
Dublin evaluated manning each sector solely with an Executive Controller (EXC). This
facilitated the inclusion of an extra sector – West Area (ARW), together with the Final
Approach (FIN) and Departure (DEP) sectors. In addition, Dublin evaluated the use of
parallel 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. New
Standard Arrivals (STARS) were described for Runway 28L. In effect, the TMA entry point
determined the holding stack allocated for arriving aircraft. The stack allocation applied is
shown in the table below:
Hold Stack
ROKNA
TULSO
NASRI
DINIL
TMA Entry Point
BOYNE
LAMBU
TOLKA
VATRY
BEPAN
OMAAR
CONRO
GELKI
LIFFY
SHELI
FYLIS
Table 3: Hold Stack Allocation
3.5.6.
Sectorisation
The five simulated organisations incorporated various sectorisation configurations. These
included oceanic interface, en-route and TMA sectors.
Full details of all simulated sectors, both measured and feed, can be found in the Ireland
2000 Real-time Simulation Facility Specification Part 1 – Operational Conduct and Analysis
[Reference 1].
3.6.
EXERCISE PROGRAMME
An exercise programme was constructed which allowed for three simulation exercises per
day. Briefing and de-briefing periods were included as required.
Forty-one measured exercises were completed while a further eight exercise slots were
allocated for familiarisation and system training. The exercise programme was carefully
constructed in order to optimise the evaluation of the simulation objectives.
Each organisation (except Org. A), was investigated with medium-term and long-term
forecast traffic. The client opted to cancel the simulation of Org. A long-term traffic, following
appraisal of the initial simulation results achieved with medium-term traffic.
As Runway 28 and Runway 24 are the more prevalent active runway configuration for Dublin
and 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 opposed
to Dublin Runway 10; Shannon Runway 06 was 5:1.
EEC Report No. 366
7
EUROCONTROL
The table below shows the exercise programme that was eventually completed.
Week
Org.
1
B
A
A
B
Number
of Exercises
2
3
3
6
2
B
C
1
6
D
6
E
D
D
C
C
B
E
4
3
3
2
3
2
5
3
4
Traffic Level
50% of Medium-term S/D
50% of Medium-term S/D
Medium-term S/D
3 Medium-term S/D
3 Long-term S/D
1 Long-term S/D
3 Medium-term S/D
3 Long-term S/D
3 Medium-term S / Long
Term D
3 Long-term S/D
4 Medium-term S/D
50% of Long-term S/D
3 Medium-term S/D
2 Medium-term S/D
3 Long-term S/D
2 Medium-term S/D
2 Medium-term S/D
3 Long-term S/D
Objective
Training
Training
Evaluation Org. A
Evaluation Org. B
Evaluation Org B
Evaluation Org C
Evaluation Org D
Evaluation Org D
Training Phase II (P.II)
Evaluation Org D (P.II)
Evaluation Org C (P.II)
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 from
Shannon and Dublin. The staffing plan took into account each controller’s qualifications and
recent experience and ensured that each variation of organisation was evaluated from as
many different control positions as possible.
3.7.
SIMULATED ATC SYSTEM
The simulated ATC system represented as closely as possible the main specifications of the
Irish Air Traffic Management System (IATMS). This advanced ATC system incorporates
many features from the EATCHIP III development programme and requirements defined for
the 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 while
incorporating System Supported Co-ordination (SYSCO) and Medium Term Conflict
Detection (MTCD).
An arrival manager system (MAESTRO) was simulated for Dublin. MAESTRO is a multiairport and multi-runway decision-making tool for sequencing the arrival traffic to several
airports and / or runways. A full description of the MAESTRO system is contained within the
MAESTRO User’s Manual [Reference 3].
The ATC system employed an advanced Operator Display System (ODS) including
extensive use of colour. Advanced flight data processing techniques were used to provide
controllers with short-term warnings of potential losses of separation and penetration of
danger areas. A three-button mouse was the sole input and data access device, through
which the controller interacted with the following facilities:
8
EEC Report No. 366
EUROCONTROL
Screen Configuration
All screen configurations including range, filters, label orientation, selectable windows and
displayed maps were set via an iconifiable on-screen control panel.
Interactive Track Labels
In this electronic system the track label became an integral tool for the controller. The label
had 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-ordination
The controller could negotiate planned sector entry levels (PEL), sector exit levels (XFL) and
direct routes via electronic means.
Electronic List Data
Electronic lists displayed sector entry and exit conditions for each flight, and allowed this
information to be verified, modified or electronically co-ordinated.
Quick Information Access
The controller had instantaneous access to certain flight information, such as a Dynamic
Flight Leg (DFL) and other flight display windows.
Notebook Functions
The controller could enter Assigned Headings, Assigned Speeds, and Assigned Rates of
Climb/Descent as well as Direct Routes directly into the track label for display in place of
marking the information on paper flight strips.
Medium Term Conflict Detection
The system provided Shannon controllers with warnings of system calculated potential flight
conflicts, up to 30 minutes before the start of each conflict.
Safety Nets
The 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 prior
to the infringement.
Certain objectives concerning specific elements of the simulated system and controller
interface are addressed in this report. However, a full description of the simulated system is
contained within the Ireland 2000 Real-time Simulation Facility Specification Part 2 Technical [Reference 4].
3.8.
CONTROLLER WORKING POSITION
The 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.
EEC Report No. 366
9
EUROCONTROL
Where a sector had two positions, an Executive Controller position (EXC) and a Planning
Controller position (PLC), the CWP provided to each position was identical with the same
functionality. Only operational rules and the specified tasks of the two controllers prompted
the setting of different screen configurations. In addition to the provision of strip printers for
all simulated sectors, MAESTRO monitors displayed arrival traffic data to all Dublin ATCC
measured and feed sectors.
Adjacent 'Feed' Sectors
Six 'Feed Sector' controllers were equipped with Sony™ 20" square monitors. Special
functionality 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 directly
as pilot inputs, allowing the sector to operate without a dedicated pseudo-pilot.
3.8.1.
Operations Room Configuration
The Operations room was configured with 26 Controller Working Positions including the
MAESTRO master position. The Operations Room layout remained unchanged from
organisation to organisation. However, the number of CWP’s used depended on the
sectorisation and manning configuration being simulated. The various configurations
simulated were: (See Operations Room Floorplans - Annex II).
•
•
•
•
•
•
•
•
•
•
•
•
Dublin Area
Dublin Area
Dublin Approach
Dublin Approach
Dublin Departure
Shannon High-level
Shannon High-level
Shannon Low-level
Shannon Low-level
Shannon TMA
Shannon Approach
Feed Sectors
2 two-man sectors with/without MAESTRO
3 one-man sectors with/without MAESTRO
2 one-man sectors
3 one-man sectors
1 one-man sector
2 two-man sectors
5 two-man sectors
1 two-man sector
2 two-man sectors
1 two-man sector
1 one-man sector
6 Sectors
(4-5 CWP)
(3-4 CWP)
(2 CWP)
(3 CWP)
(1 CWP)
(4 CWP)
(10 CWP)
(2 CWP)
(4 CWP)
(2 CWP)
(1 CWP)
(6 CWP)
Photo 2: Ireland 2000 Real-time Simulation Operations Room
10
EEC Report No. 366
3.9.
EUROCONTROL
ATC PROCEDURES AND CONTROLLER TASKS
ATC Procedures applied during the simulation were as far as possible the same as in current
operation (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-tuned
during 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 system
requires a considerable amount of controller input to function correctly. The details of the
controller interaction with the system are provided in the Ireland 2000 Real-time Simulation
System Handbook [Reference 5].
The Executive functions remained the same as in Phase I (with flight progress strips) and
Phase II (without flight progress strips). In Phase I where flight strips were provided the PLC
was 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, managed
each sector. In the case of one-man sectors, the EXC assumed the responsibilities of both
EXC and PLC.
The following terms were used in the en-route environment for the purpose of
standardisation:
3.9.2.
•
Sector - The area of control responsibility (delegated airspace) of the sector team.
•
EXC controller - Radar Position: The position which is in direct communication with the
aircraft and which uses radar information as the primary means of separation.
•
PLC controller - Planning Position: The position responsible for co-ordination and the
organisation and planning tasks concerning traffic entering and leaving the sector.
Simulation Phase II Procedures
Current Operational Procedures, as laid down, were applied at all times except in the cases
where new procedures had been specified for the period of the simulation.
3.9.3.
Responsibilities
The responsibilities of individual controllers are explained below. This description is the
result of the experience of other real-time simulations using similar systems and was
proposed as a basis on which to commence the simulation where further assessment was
conducted.
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).
EEC Report No. 366
11
EUROCONTROL
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 & Dynamic Flight Legs.
Assists the Executive Controller with co-ordination accept, reject or counter proposal in
Message-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 telephone
if 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 the
Planning Controller to input and co-ordinate changes as required.
Is responsible for ensuring that exit conditions are achieved.
Is responsible for Transfer input.
12
EEC Report No. 366
3.9.4.
EUROCONTROL
Shannon TMA and Approach Control
The division of responsibility and draft working practices for the TMA and Approach
controllers was the subject of review during the simulation in order to develop appropriate
procedures.
3.9.5.
Dublin Procedures
The current working practices (at time of simulation) at Dublin differ significantly from those
recommended previously for en-route sectors. The concept of 'shared' airspace meant that
new procedures and roles relevant to this specific working environment were developed.
Requirements for these were explored during the simulation.
3.9.6.
Hybrid Feed sectors
The simulation employed some “Hybrid” feed sectors. These sectors are unlike normal
sectors 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 are
transmitted 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” calls
on the frequency in the normal way.
Although Hybrid Feed sectors are simple sectors to manage, several special functions are
provided. A full description of these functions can be found in the Ireland 2000 Real-time
Simulation System Handbook [Reference 5].
Further project information for participating controllers and pilots can be found in the
following 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].
EEC Report No. 366
13
EUROCONTROL
4.
RESULTS - OBJECTIVE 1
CONTROLLER INTERFACE (HMI) EVALUATION
Evaluate the operational impact of the HMI for the CAIRDE 2000 system.
4.1.
INTRODUCTION
The simulated ATC system represented as closely as possible the main specifications of the
Irish Air Traffic Management System (IATMS). This advanced ATC system incorporates
many features from the EATCHIP III development programme and requirements defined for
the Irish Aviation Authority (IAA). The system was simulated in two phases. Phase I
assessed a flight progress strip environment with co-ordination by telephone. Phase II
assessed a more automated system without the use of flight progress strips while
incorporating System Supported Co-ordination (SYSCO) and Medium Term Conflict
Detection (MTCD).
The Human Machine Interface (HMI) in the system simulated for Ireland 2000, was a
complex display combining flight and radar information, airspace and aeronautical
information, and system derived information on the projected trajectory for each flight.
Interaction with the system through the HMI was an essential feature, which provided input
to the system and feedback to the controller.
A full description of the Ireland 2000 HMI is available in the Ireland 2000 Real-time
Simulation Facility Specification Part 2 - Technical [Reference 4] and in the Ireland 2000
Real-time Simulation System handbook [Reference 5].
The main elements of the HMI were a large Radar Window that included comprehensive
radar label information (Track symbol, Mode C and Flight Plan Information), a Radar Toolbox
Window for accessing the radar window set-up controls, information windows with list and
graphical data, and a three-button mouse input device.
Figure 1: Radar Window
14
EEC Report No. 366
4.1.1.
EUROCONTROL
Pre-Simulation Overview
In order to assess correctly the in-depth results of the HMI analysis, (the majority of which is
based on controller feedback), it is important to take into account the profiles, in terms of
experience and expertise, of the participating controllers.
The majority (70%) of the participating controllers was in the 45-55 age-bracket with between
16 to 32 year’s experience while some of the younger controllers had less than five years
experience 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 had
varied levels of experience in the use of the mouse input device and the windows operating
system.
4.2.
GENERAL HMI RESULTS
The HMI provided for the Ireland 2000 simulation was very well accepted by the participating
controllers. The use of colour in the display of data was also very well received. While some
controllers had little or no experience of mouse input devices or windows environments they
adapted very quickly to the system. In fact, 95% agreed that a windows style environment
was a positive step for future ATC systems and that the mouse was a suitable device for
interacting with the system.
The vast majority (91%) considered the screen size appropriate while 78% felt that the
screen layout should not be changed. A large number (80%) agreed that the radar toolbox
offered enough flexibility, however, most controllers felt that the configuration options
available were not optimised.
The general consensus was that a similar HMI would form an acceptable basis for an
operational system. 77% agreed that the integration of multiple display/input windows 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 with
conflict information, interactive radar labels and lists provided a satisfactory system that
permitted the removal of paper flight progress strips.
4.2.1.
Label and track Information
The format and functionality of the track label was a key feature of the simulated HMI which
provided four different label formats.
•
•
•
•
Standard Label
Reduced Label
Uncorrelated Label
Extended Label (Window)
EEC Report No. 366
15
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 the
flight.
Figure 3: Example of “Advance Warning” label
Figure 4: Example of “Assumed” label
16
EEC Report No. 366
EUROCONTROL
Figure 5: Example of “Concerned” label
A Selected label format was displayed when the mouse cursor was moved over a standard
label. The Selected label displayed all fields (cancelling the minimum information rule) and
Line 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. This
information was displayed in a separate window at a pre-set location in the top left portion of
the 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
Concerned labels
Advance Warning labels
Assumed labels
EEC Report No. 366
Light Grey text (Mustard for Dublin)
Mustard text
Light Blue
White
17
EUROCONTROL
The reason for the use of Mustard for Dublin is explained later in this report when describing
Colour (Section 4.4.1 refers).
A detailed description of the label formats is provided in the Ireland 2000 Real-time
Simulation System Handbook [Reference 5].
The controllers could dialogue with the system through interactive fields in the label, using
the 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 with
the system. The left button was designated the ‘Action Button’ (for inputting data), the right
button the ‘Information Button’ (for displaying data) and the middle button, the ‘Special
Button’, reserved for additional functions.
ACTION BUTTON (AB)
SPECIAL BUTTON (SB)
INFORMATION BUTTON (IB)
Figure 8: Three-button mouse
4.3.
DATA INPUT AND WINDOWS MANAGEMENT RESULTS
4.3.1.
Three Button Mouse
The controllers indicated that the mouse was acceptable as a means of data input. While
they quickly became familiar with the mouse functionality, some confusion was initially
experienced as the functionality differed to that of the instruction handbook in that the
positions of the Information Button (IB) and Special Button (SB) were reversed. Therefore,
some controllers experienced difficulty with the association and identification of the mouse
buttons. The controllers recommended that different surface textures could assist with button
identification.
Mouse reliability was considered of paramount importance for controller confidence. In the
event of a mouse failure, it must be possible to replace it quickly and efficiently with minimum
disturbance for the controller and no effect to the windows operating system. CWP design
should also take account of the different requirements of left-handed and right-handed
operators.
4.3.2.
Windows and Pop-up Menus
While the vast majority of the controllers (95%) agreed that a windows style environment
was 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 radar
screen could 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 radar screen are optimised.
The controllers found the pop-up menus easy to handle with adequate and easily selectable
options. Some difficulties were experienced with incorrect default settings resulting in
cumbersome scrolling to select the desired value. The Shannon controllers recommended
that the Cleared Flight Level (CFL) pop-up should default to 500ft. increments below 10000ft.
18
EEC Report No. 366
EUROCONTROL
to facilitate usage for VFR traffic operations. In fact, the CAIRDE 2000 system will cater for
this in two ways.
•
•
4.4.
Aircraft who are filed on VFR flight plans will have a pop-up menu of 500ft increments up
to FL195.
Level increments of 500ft will be available for all pop-up menus for altitudes of 5000ft
and below.
LABEL AND TRACK RESULTS
The majority of the controllers (80%) agreed that the range of information displayed in the
radar 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?
91.67%
100
80
60
40
8.33%
20
0
Y es
No
Graph 1: Label Selection Difficulty
This negative result was due to the fact that in the first weeks of the simulation interaction
with the labels proved almost impossible due to label jumping. The physical act of label
selection was very difficult as controllers consistently found that unconcerned labels would
select when they were trying to select the desired assumed, advance warning or concerned
label. In effect, label sensitivity and transparency created controller frustration with the
system and unnecessary extra workload.
On the positive side, the controllers were better able to identify the problems anticipated with
the new system and provided excellent recommendations (as detailed below) on how these
might be overcome.
Label selection should be by moving the mouse over the label or track symbol. The ‘press
and hold’ feature, applied later in the simulation, for selection of Unconcerned labels,
significantly reduced unnecessary interaction with these labels. Most controllers would
prefer that individual label selection should be limited to as small a 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 label
de-confliction was available in the simulation but the controllers found this feature annoying
as the constant ‘staggered movement effect’ of the radar labels on the screen proved more
of a distraction than a help.
EEC Report No. 366
19
EUROCONTROL
Label movement should be simple and flexible. The controllers appreciated the various
methods available to resolve label overlap. The ‘drag and drop’ functionality was preferred
to the use of pre-set positions. The pre-set positions allow the controller to choose a predefined position for all labels on the radar screen. Drag and drop provided even greater
flexibility for label management. Although this involved extra work, controllers said that they
refreshed their mental traffic picture as they manually relocated the labels and did not find it
too tiresome. Indeed, a functionality that allowed the controller to select pre-set positions for
individual labels or sets of labels (eastbound, westbound, arriving, departing) would be
advantageous.
Controllers often experienced difficulty in associating the track label with the Radar Position
Symbol (RPS), particularly when the label orientation was west to north-west of the RPS. In
these 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 first
field of the label. In addition, the lead line should be colour coded to distinguish it from the
speed vector and dynamic flight leg.
4.4.1.
Colours
The use of colours for labels and lists was very successful, with 83% of the controllers
stating that the use of colour coding for labels and text was logical and understandable. In
fact, 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 very
good. The colour brilliance was reduced during the simulation as, although it was
considered very good for the track labels, it became a little bit uncomfortable when a lot of
text was presented in the various lists provided. The White for ‘Assumed’ aircraft was also
considered to be too bright and the brilliance should be reduced.
The IRL2000 HMI specified extensive use of background colour change to highlight
information. Subtle change of background colour was very successfully used to crosshighlight all data associated with a particular flight. For example, when the mouse cursor
came to rest on a radar label not only was the Extended Label Window (ELW) updated with
the appropriate flight details but the related lists (SIL, SEL, DEP, and ARR) were also
presented with a highlighted background. The background colour change for this type of
highlighting was just sufficient to ensure that the data could be easily located but legibility of
text was not affected. Controllers greatly appreciated the effectiveness of this feature.
Shannon and Dublin controllers had different views regarding the Mustard and Grey colours
selected for ‘Concerned’ and ’Unconcerned’ labels respectively.
Shannon found the Mustard to 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 Grey
colour for Unconcerned labels. The Dublin TMA is shared simultaneously by several
controllers operating various sector positions. The Controllers felt that the aircraft state
system as simulated, was not particularly suitable for their operations. Controllers stated
that although certain aircraft could be considered as ‘Unconcerned” to their sector, it was still
important that they were clearly visible. The Grey was not suitable, so Mustard was used for
all ‘Concerned’ and ‘Unconcerned’ labels in Dublin CTA. This was an improvement, but not
considered the ideal solution (See STCA Results Section 5.3.1). Recommendations for
further improvements varied from brightening the Mustard colour to altering the Callsign and
Actual Flight Level (AFL) fields to White.
20
EEC Report No. 366
EUROCONTROL
In effect, the methodology of defining and displaying ‘Concerned’ and ‘Unconcerned’ traffic
to 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 the
ambient lighting conditions where the system is installed.
4.4.2.
Fields
The Callsign field highlight colour (Yellow) was considered to be good and should also
appear in all relevant lists. During the simulation, (and for the future system), Callsign
highlight was and will be only available between CWP’s of the same sector. Callsign
highlights on ‘Advance Warning’ labels were not over-ridden by White when these labels
changed to transfer-in mode following handover by the upstream sector. In effect, this
meant that the receiving sector was unaware of the handover proposition. Ideally, a
highlighted ‘Advance Warning’ aircraft should change to White ‘Transfer-In’ mode on
handover, and revert to highlight, once the aircraft has been assumed. Controllers also
stated 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 the
same colour should appear in all relevant windows.
Clicking on the inter-active fields of the selected label with the action button opened their
related pop-up window menus. Default values were defined for the pop-up window menus
but in some cases these did not work correctly, resulting in unnecessary scrolling in the popup window to select the desired value. This caused frustration and increased the workload
for the controllers. The problem was further exacerbated by the fact that the principle of XFL
default levels between sectors was not fully understood and employed correctly by some
controllers. AT times XFL’s were entered that were not related to the next sector thus
removing it from the sequence. This resulted in aircraft being abrogated from the correct
receiving sector. Abrogation, a modification that implies that an aircraft will no longer enter
into 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 label
state changed to ‘Unconcerned’.
The main observations of the controllers with regards to the label fields and their related popup 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:
Field 1
XFL
Field 2
OFL
Field 3
FXPT
Field 4
XPT
Ideally, when XFL=OFL and FXPT=XPT, the default should be to Fields 1 and 2
respectively.
EEC Report No. 366
21
EUROCONTROL
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.
Dublin
The Assume/Hold functionality in the Callsign menu, (mentioned above in the Shannon
observations), was tested extensively by the Dublin controllers. They found it to be very
useful but were divided as to whether or not the default should be to Assume or
Assume/Hold. Some felt that the default to Assume/Hold would result in inadvertent
placement of aircraft in the Hold list. There was no consensus on whether the Assume and
Assume/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 the
very busy Dublin TMA. Further investigation and assessment of the minimum requirement of
mandatory fields should be undertaken
Controllers recorded instances where they transferred aircraft from their sector in error by
inadvertently clicking on the mouse action button (AB). A short delay facility in the system
acknowledgement of inter-sector transfers would permit controllers to retrieve (‘Undo
Transfer’) incorrectly transferred aircraft.
4.4.3.
Exit Flight Level (XFL) Defaults
XFL default settings in the electronic system posed many problems for controllers. In Dublin
CTA, where area, approach and departure controllers share usage of the same airspace the
limitations of the system could be easily overcome. However, the more complicated
sectorisation configuration of Shannon ATCC (Low-Level/High-Level) with vertically superposed sectors proved more difficult to solve.
The example diagram below best explains the main problem.
FL340
Sector 2
FL335
FL330
Sector 1
For an aircraft whose RFL would involve climb from Sector 1 to Sector 2 the problem is what
XFL default setting should be applied. If XFL=PEL is used, the aircraft remains at FL330
and the upper sector (Sector 2) would have no ‘Advance Warning’ label (Light Blue) for the
aircraft until the aircraft co-ordination was proposed. If default XFL=FL340, the aircraft is
seen in ‘Advance Warning’ state in the upper sector but the lower sector (Sector 1) can climb
the aircraft into the sector above without co-ordination.
The majority stated that they needed to have the ‘Advance Warning’ label but did not want
the lower sector to have the right to climb without co-ordination. One possible solution
22
EEC Report No. 366
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 every
aircraft and impact on controller workload.
Further evaluation, concerning the authority to climb to the agreed XFL subject to coordination by telephone on potential conflicts, will be required. Controllers also stated that
climbs following co-ordination should be immediate and coincident with transfer of aircraft.
4.4.4.
Oceanic Clearances
Shannon High-Level controllers received Oceanic Clearance Message (OCM) information
via 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 they
agreed that the availability of oceanic clearances in the ELW led to a reduction in their
workload. They preferred, however to access oceanic clearance information through the
SEL.
Oceanic clearance information was more easily accessible
from the SEL than from the ELW?
Slightly Disagree
7,14%
14,30%
Disagree
Slightly Agree
7,14%
Agree
35,71%
35,71%
Strongly Agree
Graph 2: OCM Accessibility
4.4.5.
VFR Enroute
The simulated system employed pre-determined sector sequence parameters for Shannon
and Dublin ATCCs. This created a problem for VFR operations in Shannon Low-Level
where controllers required a more dynamic versatile system, which precluded the definition
of a fixed flight plan and fixed sector sequence. Dublin ATCC opted not to simulate VFR
operations.
To obtain the necessary flexibility the Low-Level controller was able to select the next sector
and send advance information (via Force ACT) when required. This would change the label
in 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.
EEC Report No. 366
23
EUROCONTROL
4.4.6.
Direct and Re-routing
Controllers were able to re-route aircraft direct to any point in the flight planned route using
the Elastic Vector. If the destination point they selected was not on the original flight plan it
was input by the system into the Assigned Heading field (AHDG). In the system, when using
the DCT functionality, co-ordination will only place when the new point selected is in the
current next sector in the sector sequence, and the aircraft is ACT Out. If a DCT point is
selected in any other sector, the new route will not be co-ordinated. However, the trajectory
will be updated and a new sector sequence will be created. In this case, the original next
sector is abrogated and the next sector receives a short notice ACT (normally following
telephone co-ordination). Abrogation, a modification that implies that an aircraft will no
longer enter into 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 label state changed to ‘Unconcerned’.
The controllers stated that the abrogation function was very useful and that the green
callsign proved very noticeable. In the system being provided to the IAA, abrogation will
trigger a message in the ‘Message In’ window. The general consensus was that the callsign
colour change was both preferable and sufficient, with no requirement for message
information and that abrogation should force through all pre-set filters.
Dublin controllers did not use the DCT functionality much although they considered it a
useful option. The Shannon controllers used the functionality extensively, particularly in the
large long High-Level sectors. They found it to be a very useful function and made the
following observations and recommendations.
•
•
•
•
•
4.4.7.
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
and following transfer to the downstream sector the destination point should appear in
the downstream sector AHDG field.
Skip
Situations occur where a flight may transit a sector for only a short time period. In these
cases, controllers may choose not to have the aircraft on frequency. The skip functionality
allowed 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 to
transfer by the upstream sector. In the simulated system, it was not possible to cancel the
Skip option therefore a ‘confirm skip’ message was triggered requiring a second click on the
AB before the function was activated. The Skip activation, in turn, froze all co-ordination
conditions to the skipped sector. No further changes to sector entry or exit conditions were
permitted.
Controllers were comfortable with the skip functionality but stated that execution by the PLC
should be only after consultation with the EXC. The radar label in the skipped 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 the availability of the ‘confirm skip’
message controllers stated that an ‘Unskip’ functionality would be required.
24
EEC Report No. 366
4.5.
FLIGHT PROGRESS STRIPS
4.5.1.
Introduction
EUROCONTROL
The use of flight progress strips in the simulation was the subject of much discussion and
debate between the IAA and EEC project teams. The simulated CAIRDE 2000 ATM system
was mainly based on specifications derived from the EATCHIP Manual of the EATCHIP III
Automated 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 in
order to correctly evaluate the HMI in such a system the use of flight progress strips should
be excluded.
The IAA, on the other hand, is faced with the responsibility of providing a fully operational
and reliable system on schedule. The system requested from Airsys ATM will include full
flight progress strip facilities.
System progression will be evolutionary rather than
revolutionary, to avoid the sudden change to a stripless environment which could prove
extremely problematic. Use of strips during the simulation will assist in the determination of
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. The
first phase aimed at gathering subjective feedback from the participating controllers on the
usability and operational suitability of the CAIRDE 2000 system as simulated with flight
progress strips. In the second phase, the EEC provided an enhanced automated system
that enabled the controllers to evaluate possible future developments to the system.
Phase I simulated full flight progress strip functionality but did not include Medium Term
Conflict Detection (MTCD) and Conflict Risk Display (CRD). Co-ordination was by
telephone 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 coordination indications shown in the radar label, ELW and data lists. There were no flight
progress strips.
4.5.2.
Controller Feedback
The controllers were concerned as to the ergonomics of the CWP set-up (including strips) for
the new system. Current suites operate with a single radar display for the EXC and a flight
progress strip board for the PLC. In Dublin ACC the flight progress strip boards are
designed to geographically represent the control area.
The CAIRDE 2000 system provides radar displays for the Executive and Planning
controllers. Difficulties exist in allocating suitable CWP working areas to cater for flight
progress strip and mouse pad needs. Keyboard requirements will further exacerbate this
problem. In Shannon High-Level, the sheer volume of aircraft made it impossible to
sectorise the strip board. The controllers found it impossible to keep the flight progress
strips up to date while simultaneously maintaining the electronic system. The consensus
was that the electronic system was preferable and easier to manage. Controllers found that
when they abandoned the strips it greatly improved the “in-suite” teamwork between the
EXC and PLC.
Indeed, in Phase II with SYSCO co-ordination and other added
functionalities, 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 and
migration to a “stripless” environment should be addressed sooner rather than later.
EEC Report No. 366
25
EUROCONTROL
Despite having to overcome teething problems with regards to printing strips, errors in strip
details and duplication of strips, the controllers worked extremely hard with the simulated
system. They were commended for their efforts to try to maintain both systems (electronic
and flight progress strip) while safely handling long-term heavy traffic levels forecast for
2007.
Regardless of these problems the controllers stated that it was difficult to handle more than
10 aircraft while maintaining the flight progress strips and the electronic system. It became
impossible to work radar labels, lists and strips at the same time. During the simulation, the
PLC loaded the strips into the strip holders and boards. This took up valuable time and
caused a distraction from interaction with the system. In fact, the only way to keep strips up
to date was for the PLC to ignore his radar display. All PLC’s preferred to maintain the
electronic system through the radar display rather than maintain strips.
Controllers felt that the Dynamic Flight Leg (DFL) function helped replace the planning role
of the strip board while appropriate sorting in the lists (SIL, SEL etc.) could suitably replace
strips. On the other hand, for tracking aircraft in holding patterns, caution was urged in the
use of Hold Lists as a replacement for strips until sufficient experience was attained and
Hold List functionality was fully evaluated.
In the simulation, the Shannon High-Level PLC did not perform many of the normal functions
related to oceanic separations, clearances, re-clearances and revisions. This important
aspect of operations will require further evaluation, particularly in terms of a stripless
environment. However, experience gained during the simulation indicated that these safety
issues could be handled more efficiently by the electronic stripless system.
Whereas, the move to a paperless system may not prove too difficult, the controllers reiterated their view that the electronic system must work well while providing user-friendly
input with correct default values
4.6.
DATA LIST WINDOWS
In the simulated IRL2000 ATM system tabular text data list windows were used to present
various types of lists and co-ordination messages that supplemented the radar data on all
control positions. The lists expanded dynamically in width as well as height (number of text
lines) according to the defined fields and presented information.
4.6.1.
General List Results
Controller reaction to the various lists available was mixed. A slight majority felt that 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 be enhanced if in
each list (except for the Hold List), the Callsign field was the only mandatory field. This field
should be placed on the left, with all other fields optionally selectable. When lists were
closed and subsequently re-opened they should default to the controller’s programmed
preference.
In two-man suites the PLC tended to spend more time watching the lists rather than the
radar picture. Interaction with the lists proved more difficult as the level of traffic and
subsequent volume of list data increased. Although page lists occupy more screen space
than scroll lists, problems were often encountered with essential flight data being hidden as a
result of the scrolling function.
26
EEC Report No. 366
EUROCONTROL
The number of displayed items in a list without having to scroll was satisfactory?
14,28%
Slightly Disagree
19,05%
Disagree
19,05%
Slightly Agree
42,86%
Agree
Strongly Agree
4,76%
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 to
manually delete unrequired flights from the list would prove advantageous.
As the simulation progressed and controller experience increased, the tactical selection and
use 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 displayed
in the radar window. The information presented in the SIL could provide entry flight data
before a track label was visible in the radar window. In Phase II of the simulation this
enabled the controller to initiate or respond to co-ordination before the track label was
visible. This facility was also available in the Sector List (SEL).
Information for each pending flight was displayed as a single line (strip) with default sorting
according to Entry Time (ETE), Entry Point (EPT), Departure Aerodrome (ADEP) and
Destination Aerodrome (ADES). When an aircraft changed status from ‘Advance Warning’
to ‘Assumed’ the information was deleted from the list. The strip was highlighted when the
aircraft selected label was raised in the radar window, and inversely when the SIL line was
selected, the aircraft selected label was displayed on the radar window (and in any other
displayed list).
The SIL window automatically re-sized when new entries were added, however the window
stopped resizing and a scroll bar was provided when the list reached 7 lines. Individual SILs
were placed at pre-defined default positions on the screen. The controller could then
reposition SILs to suit his/her personal requirements. The number of SILs required
depended on the sector configuration. Sector Entry Points were often combined so that
flights entering through the same geographical border were displayed in one SIL (sorted by
entry point).
EEC Report No. 366
27
EUROCONTROL
Figure 9: Example of Sector Inbound List (SIL)
Optional fields such as XFL, XPT, ADEP, ADES, SI and ASSR could be selected or
deselected through the ‘Options’ pop-up menu. When optional fields were deselected the
SIL compacted left, reducing the width of the displayed window.
4.6.3.
Sector Inbound List Results
The controllers main conclusions and recommendations highlight 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 allocation for eastbound flows. Scrolling created some difficulties with
regards 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 generally
preferred to interact directly with the radar label.
The information displayable in the SILs was appropriate?
S lig h t ly D is a g r e e
D is a g r e e
4 ,7 6 %
4 ,7 6 %
2 3 ,8 2 %
S lig h t ly A g r e e
5 7 ,1 4 %
A g re e
S t r o n g ly A g r e e
9 ,5 2 %
Graph 4: Displayed SIL Information
For Shannon controllers, reaction differed as to the need for the information displayed in the
SIL depending on whether the controller role was a planning or tactical one. Surprisingly,
executive controllers favoured the need for the SIL information more than planning
controllers. The reasons for this may be that the EXC often operated on a shorter range and
therefore did not always see the ‘Advance Warning’ aircraft. Secondly, many planning
controllers preferred to use the SEL rather than the SIL, as it provided more optional
information including oceanic clearance data.
28
EEC Report No. 366
EUROCONTROL
You don’t need the information in the SIL when acting as Planning Controller (PLC)?
19,04%
Slightly Disagree
14,29%
Disagree
Strongly Disagree
Slightly Agree
9,52%
4,76%
38,10%
Agree
Strongly Agree
14,29%
Graph 5: SIL Information - PLC
You don’t need the information in the SIL when acting as Radar Controller (EXC)?
23,81%
Slightly Disagree
14,29%
Disagree
23,81%
Strongly Disagree
Slightly Agree
14,29%
Agree
14,29%
Strongly Agree
9,51%
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 relevant
information for ‘Advance Warning’, ‘Assumed’ and ‘Concerned’ flights through the sector.
Information for each aircraft was displayed as a single line (strip) with default sorting
according to Entry Point (EPT), Entry Time (ETE) and Planned Entry Level (PEL). The strip
was highlighted when the aircraft selected label was raised in the radar window, and
inversely when the SEL line was selected, the aircraft selected label was displayed on the
radar window (and in any other displayed list). Entry fields were subsequently deleted on
Assume Control and the complete line was removed on sector exit.
The SEL window re-sizing functionality was similar to that previously described for the SIL
but, in this case, scrolling did not commence until the list reached 10 lines. A large selection
of optional fields - see the Ireland 2000 Real-time Simulation System Handbook [Reference
4] - could be selected or deselected through the ‘Options’ pop-up menu. When optional
fields were deselected the SEL compacted left, reducing the width of the displayed window.
EEC Report No. 366
29
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 received
from the previous sector. Entry fields were subsequently deleted on Assume Control and the
complete line was removed on sector exit.
4.6.5.
Sector List Results
The 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 once
again considered it useful but supplementary to their needs.
Shannon controllers highlighted sorting and scrolling as the main problems encountered with
use of the Sector List. Controllers sometimes had difficulty in finding aircraft in the SEL. The
default 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 PEL
would be more suitable.
Despite this measure, problems would still exist. Controller opinion was mixed regarding
further sorting and scrolling methods. Sorting according to label-state provides advantages
and disadvantages particularly when scrolling is used. If, for example, ‘Assumed’ aircraft
were sorted to the top of the list, scrolling would hide some (or all) text lines of ‘Advance
Warning’ aircraft that might not be visible on the radar window and also could be the subject
of co-ordination proposals.
A page list with no scrolling would be better but this has the disadvantage that the SEL can
then become extremely big and occupies a large area of the radar window. On the other
hand, the controllers do not require the display of ‘Concerned’ aircraft. This, in turn, would
help reduce window size.
Another recommended improvement to the SEL was a further sorting facility for Oceanic
Clearance Message (OCM) fields of Entry Point (EPT), Oceanic Flight Level (OFL) followed
by Oceanic Entry Time (ETE).
Finally, although controllers could input to the system via the SEL instead of the radar label
their preferred method was via the radar label.
30
EEC Report No. 366
EUROCONTROL
Did you prefer the sector list as a means of input to the system instead of the radar label?
N ever
2 3 ,8 1 %
3 8 ,1 0 %
R a r e ly
2 8 ,5 7 %
S o m e t im e s
R e g u la r ly
9 ,5 2 %
Graph 7: Input - SEL or Radar Label
4.6.6.
Arrival and Departure Lists
The Arrival and Departures Lists were windows provided to Dublin and Shannon controllers
to display flight data on aircraft landing at and departing from Dublin, Shannon and specified
regional airports within the Shannon FIR. Each aircraft was displayed as a single list line
containing relevant data. These lists functioned using the SEL principle, in that information
was 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 of
Destination (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 the
destination aerodrome.
Figure 11: Example of Arrival List
The Departure List was sorted for each Departure Airport (ADEP) by Estimated Time of
Departure (ETD), Exit Flight Level (XFL) and Exit Point (XPT). The list provided specific
data on the Standard Instrument Departure (SID), Cleared Flight Level (CFL), Aircraft
Type/Weight category and assigned SSR code.
Figure 12: Example of Departure List
EEC Report No. 366
31
EUROCONTROL
4.6.7.
Arrival and Departure List results
The 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 widely
accepted and considered far more useful with 63% of the controllers stating that they always
or regularly used it compared to 36% in the case of the Arrival List. Interestingly, not a single
controller indicated that he/she felt that the Arrival List was rarely useful
Was the Arrival List Useful?
R a r e ly
3 6 ,8 3 %
N ever
S o m e t im e s
2 6 ,3 2 %
R e g u la r ly
2 6 ,3 2 %
A lw a y s
1 0 ,5 3 %
Graph 8: Use of Arrival List
Indeed, 75% of the controllers stated that they rarely (65%) or never (10%) used the arrival
list as a means of input data to the system. One should note however, that use of the Arrival
List was mainly by busy approach or TMA sectors where surveillance of and interaction with
the radar label was invariably more intensified.
Was the Departure List Useful?
R a r e ly
5 ,2 6 %
2 1 ,0 5 %
N ever
S o m e t im e s
1 0 ,5 3 %
R e g u la r ly
3 1 ,5 8 %
A lw a y s
3 1 ,5 8 %
Graph 9: Use of Departure List
The controllers were reasonably pleased with the sorting specifications for the Arrival and
Departure Lists but recommended some improvements. They stated that in the Arrival List
an ‘Assumed’, Advance Warning’ and ‘Concerned’ label–state sort order would be better
while the Tower sequence for Departures should automatically update the sequence in the
Departure List.
32
EEC Report No. 366
4.6.8.
EUROCONTROL
Hold List
Hold Lists were provided to Dublin (Area and Approach) and Shannon (Low-Level, TMA and
Approach) controllers. Note that the Hold List provided during the simulation differed from
the list proposed by Airsys ATM in that it included a dynamic sort on CFL. This function will
only 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 hold
and closed when the last aircraft was instructed to leave the hold. Input of instructions was
via 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 the
controllers, 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 removed
form the Hold List via the ‘Leave Hold’ option on the Callsign menu (also accessible from the
Hold List and SEL).
4.6.9.
Hold List Results
The Hold List was used extensively throughout the simulation by Dublin controllers.
Shannon controllers used the functionality less as only two of the five simulated
organisations included Low-Level operation. The Hold List proved to be very successful with
the vast majority of controllers stating that it was ‘Always’ or ‘Regularly’ useful.
EEC Report No. 366
33
EUROCONTROL
Was the Hold List useful?
Never
10,00%
Sometimes
10,00%
Regularly
30,00%
Always
50,00%
Graph 10: Use of Hold List
They found the Hold List to be both clear and simple. While indicating that they would like
similar functionality in the CAIRDE 2000 system they recommended further modifications in
terms of both operational and sorting functionality.
Operational Functionality
The ability to put ‘Advance Warning’ aircraft in the Hold List would be useful for reserving
levels 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’ aircraft
display the PEL and not the CFL. The Hold pop-up menu should default to the holds
relevant to the sector. Ideally, when an aircraft was below the minimum hold level the list
should only display the AFL.
Sorting Functionality
The scrolling facility (when 15 lines were reached) was not safe in that use of a single list for
all holds (sorted by hold) often obscured vital data on aircraft in some holds. A separate
Hold List provided for each HPT and the removal of the scrolling facility would rectify this
problem. 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 aircraft
would sort by AFL.
34
EEC Report No. 366
5.
EUROCONTROL
CONTROLLER INTERFACE (HMI) EVALUATION
Assess the operational impact of the new system ATC Tools, Safety Nets and
Monitoring Aids
5.1.
INTRODUCTION
The simulated system supported the detection of Area Proximity Warning (APW), Short
Term Conflict Alert (STCA) and Dynamic Flight Leg (DFL) display for aircraft route
projection. 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 not
employed as they considered it unsuitable for their TMA environment where the majority of
aircraft operate on climb and descent profiles.
5.2.
AREA PROXIMITY WARNING (APW)
Area Proximity Warning (APW) provided warnings on civil incursions into Temporary
Segregated Areas (TSA) such as Military Activity Areas and Danger or Restricted Areas. A
90-second look-ahead predicted the vertical and horizontal position of an aircraft, in relation
to defined volumes of airspace and also recognised if a CFL value meant incursion would
not occur.
The warning was indicated to the controller by display of the letters APW in Yellow in Line 0
of the track label. The warning was cancelled when the aircraft left the defined volume of
airspace.
Figure 14: Example of APW Display
5.2.1.
APW Results
All controllers stated that the APW was very suitable. They felt that the yellow text was very
noticeable and coupled with the audio alarm expected in the CAIRDE 2000 system, they
anticipate 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 radar
track (unlike the Medium Term Conflict Detection [MTCD], which used updated flight plan
information). A 90-second look ahead detected if two aircraft tracks would infringe a predetermined separation minimum. STCA warnings were issued from the time the conflict was
predicted until finally resolved. STCA also took CFL inputs into account to reduce false
alerts. Again in all cases, if the CFL was broken (level bust) the warning would be reapplied.
In order to reduce the incidence of false alarms, the warning time was kept as short as
possible leaving sufficient time for a controller to take action. The in-built design of the
EEC Report No. 366
35
EUROCONTROL
STCA ensures operation at the last possible moment in a situation that the controller has not
resolved.
The simulated STCA displayed a Red label-border around the label-block. In addition, the
Callsign field was highlighted Red. The alert remained until the STCA detected that the
conflict prediction and conflict no longer existed.
5.3.1.
STCA Results
The vast majority of controllers agreed that the activation of the STCA always (67%) or
regularly (24%) attracted their attention quickly. However, when asked about the suitability
of the data-block display the response was far more critical.
When STCA was activated was data in the Label-Block legible?
Never
4,76%
Rarely
28,57%
Sometimes
66,67%
Regularly
Always
Graph 11: Legibility of STCA Label Block
All controllers stated a dislike of the style of the STCA display. The Red border on the labelblock was considered a distraction and unnecessary. The Red background highlight of the
Callsign field was extremely difficult to read when the label was in the ‘Concerned’ (Mustard)
state. Overlapping labels caused further ambiguity and frustration. Suppressed labels of
aircraft in Hold Lists did not display any STCA warnings.
The controllers put forward three major recommendations for STCA display characteristics.
These were:
•
•
•
5.4.
The Radar Position Symbol (RPS), Label lead line, Speed Vector and History Dots
should 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.
DYNAMIC FLIGHT LEG (DFL)
The Dynamic Flight Leg displayed the aircraft route from the current radar track position until
the end of the flight, as a solid green line with conflict sections marked in red. Forecast
times at waypoints were displayed adjacent to each point. It was possible to have the DFL
displayed for more than one aircraft simultaneously.
The controllers use of the Dynamic Flight Leg during the simulation indicated that it was
potentially 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
36
EEC Report No. 366
EUROCONTROL
was employed as the primary tool for providing route, sector sequence and conflict
information when the controllers were handling high traffic levels and reference to other tools
and lists became difficult.
5.4.1.
Dynamic Flight Leg Results
The DFL received strong support from those controllers that used it. They considered it to
be a very powerful tool, particularly when used in conjunction with MTCD where it should be
selectable from the Conflict and Risk Display (CRD). The colours used were considered to
be quite good but some controllers felt that the thickness of the display lines should be
reduced. Controllers stressed that the DFL should be updated when the DCT function was
used.
5.5.
CONFLICT AND RISK DISPLAY (CRD)
The Conflict and Risk Display (CRD) was a display element of the Medium term Conflict
Detection (MTCD) function during the simulation.
In an ATCC employing paper flight progress strips, the calculation and notification of future
conflicts can be carried out by a controller, following comparison of reporting point estimates
and flight levels for each aircraft crossing the sector. The calculation can be made in
advance of the aircraft track being displayed on the radar screen, once flight information is
received and recorded on the flight progress strips.
In the advanced 'stripless' environment simulated in Phase II, the calculation of future
conflicts was replaced by the MTCD function. This information was then notified to the
controllers through indications on the Dynamic Flight Leg (DFL) and in the Conflict and Risk
Display (CRD).
The functionality and display characteristics of the CRD for Planning and Executive
controllers 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 Radar
toolbox.
The MTCD logic replaced the reporting point estimates used to forecast the progress of each
flight with a calculation using the horizontal element of the aircraft trajectory. When two
aircraft were forecast to infringe a pre-determined separation distance, the horizontal conflict
was 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 if
the conflict was 'real'. If the planning levels for a conflict pair overlapped, the result was
considered to show a 'risk of conflict'. The risk was used to assist the controller in planning
the evolution of the two flights from planned sector entry level (PEL) to sector exit level
(XFL).
EEC Report No. 366
37
EUROCONTROL
A warning was determined to be a RISK if, Routes crossed and Level Bands
overlapped as defined below:
Before Assume of The lowest of
AFL
Control:
PEL
XFL
The highest of
AFL
PEL
XFL
After Assume of
The lowest of
AFL
Control:
CFL
XFL
The highest of
AFL
CFL
XFL
A warning was determined to be a CONFLICT if, Routes crossed and Level
Bands overlapped as defined below:
Before Assume of The lowest of
AFL
Control:
PEL
The highest of
AFL
PEL
After Assume of
The lowest of
AFL
Control:
CFL
The highest of
AFL
CFL
Figure 16: Parameters used for Conflict and Risk Warnings
Conflicts were indicated in red and risks were indicated in yellow. The display could also be
filtered to remove the display of risks. Following controller recommendations from previous
simulations (and in line with the concept of MTCD as a planning tool), the display of conflicts
involving 2 assumed aircraft under the responsibility of the Executive controller, could also
be suppressed, greatly reducing the number of conflicts presented.
MTCD was provided in Shannon Airspace based on two defined volumes of airspace. Note
again that Dublin ATCC opted not to employ MTCD as they considered it unsuitable for their
TMA environment where the majority of aircraft operate on climb and descent profiles.
Volume 1
The limits of the Shannon UIR/FIR, West of 13W and South of 50N.
Volume 2
The limits of the Shannon UIR/FIR, East of 13W and North of 50N, excluding Shannon
Approach (APP).
The MTCD minimum horizontal separation parameter was 15nm in Volume 1 and 8nm in
Volume 2. The greater separation defined in Volume 1 took account of the degradation in
radar coverage west of the 13W line of longitude and south of the 50N line of latitude. The
minimum vertical separation for both volumes was 1000 ft.
38
EEC Report No. 366
5.5.1.
EUROCONTROL
Conflict and Risk Display Results
The 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 for
the tool to prove an effective controller aid. The accuracy of the aircraft trajectory must be
assured as it forms the basis for the computation. The tasks for Executive and Planning
Controllers using the MTCD tool must be correctly distributed and finally the requirement for
information displayed to the Planner and Executive must be suitably defined.
An evaluation of the Conflict Risk Display also includes an evaluation of the other elements
that make up the complete MTCD function. Although the simulation did not attempt an indepth investigation of each of the separate MTCD elements, useful information was gained
through controller feedback that will aid the further development of Medium Term Conflict
Detection.
Did you find the CRD tools useful to identify conflicts and risks in your sector?
Rarely
Regularly
7,00%
37,00%
56,00%
Sometimes
Graph 12: CRD Tools Usefulness
Overall, the controllers supported the use of the CRD, although with reservations. All but
one of the controllers found the tool ‘regularly or ‘sometimes’ useful. The Shannon
controllers 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 conflict
predictions made. When asked if they ever had problems with the accuracy of conflict and
risk detection in the MTCD tools 36% indicated that they ‘regularly’ did while 43% stated that
accuracy problems ‘sometimes’ existed. Comments indicated that there were many
instances where too many false risks were shown. As a result, in high workload situations
frustration and confidence were affected, and the CRD window was ignored. As mentioned
earlier in this report, sometimes when aircraft had been given DCT the updated DFL was not
updated in the MTCD feature. Controllers stressed the need to check the information
presented, supporting the view that improvement in the accuracy of information (and
updating) will be required.
EEC Report No. 366
39
EUROCONTROL
Were there ever problems with the accuracy of conflict and risk detection in the MTCD tools?
Rarely
21,00%
Regularly
36,00%
43,00%
Sometimes
Graph 13: MTCD Tools Accuracy
On the positive side, the majority agreed that all of the appropriate information concerning
risks and conflicts was ‘always’ or ‘regularly’ available in the MTCD tools. Some controllers
felt that the presentation of time and separation was not always easy to understand but
training and experience should overcome this. Indeed, the majority also felt that the CRD
did reduce their workload and assisted them in better prioritising their tasks.
Did the CRD help you to prioritise conflicts and risks?
Never
7,00%
Rarely
7,00%
Regularly
33,00%
53,00%
Sometimes
Graph 14: CRD Priority
Most controllers identified some instances where the system failed to predict risk and/or
conflict situations. However, they agreed that with improvements in the accuracy of the
detection, task allocation and information display, the tool should achieve better acceptance
and may prove to be a powerful aid to assist controllers to handle the increasing traffic
volumes forecast for the future.
40
EEC Report No. 366
EUROCONTROL
Were there risk or conflict situations the system failed to predict?
Never
8,00%
Rarely
Regularly
38,00%
8,00%
46,00%
Sometimes
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 with
the system. However, the controllers pointed out that due to the fact that the CRD was a
tabular display only, it was not possible to select affected labels from it. They recommended
that the ability to interact with labels through the CRD would assist in the reduction of
controller 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 the
PLC. PLC feelings concerning the question of whether the CRD reduced workload was
mixed, but as mentioned in the previous paragraph, they believe the system can be
improved.
As a PLC, did you feel that using the CRD reduced your workload?
Never
7,00%
28,00%
Rarely
Regularly
29,00%
Sometimes
29,00%
Always
7,00%
Graph 16: CRD – PLC Workload Reduction
5.5.2.
Situational Awareness
One issue associated with controller operation of new planning tools such as MTCD is the
effect their usage may have on situational awareness, and indeed, the follow-on impact on
safety. Clearly it is important to ensure that controllers maintain an appropriate situational
awareness for the conduct of their activities.
EEC Report No. 366
41
EUROCONTROL
Controllers (particularly the PLC’s) had to quickly adapt to new operating procedures while
responding to MTCD warnings. The tool provided early warnings on potential conflicts but
quite often the aircraft affected were outside the radar range selected. Planners had to learn
to adjust to variable selection of radar range to efficiently utilise the MTCD feature. This
sometimes caused confusion over the situational timeframe in which they were working.
They commented, however, that as a planning tool the MTCD enhanced conflict-handling
capability provided a suitable replacement for flight progress strips.
In effect, the controllers considered that their situational awareness was not significantly
affected.
When using MTCD did you manage to maintain a degree of situational awareness that you
deemed necessary?
Never
7,00%
36,00%
Regularly
36,00%
Sometimes
Always
21,00%
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 lack
of situational awareness.
Did you feel safety was impacted by a lack of situational awareness?
Never
21,00%
Rarely
36,00%
43,00%
Sometimes
Graph 18: MTCD Safety
However, as situational awareness was not significantly affected and indeed, in some cases
improved, safety concerns are slight, particularly as proper training before implementation
should ensure sufficient experience.
42
EEC Report No. 366
6.
EUROCONTROL
CONTROLLER PROCEDURES
Evaluate the potential roles of Executive and Planning Controllers in the simulated
system
6.1.
INTRODUCTION
Prior to the simulation the IAA carried out a controller task allocation project to assist in the
determination of on-suite task distribution between Executive (EXC) and Planning (PLC)
controllers. These tasks were based on current operating practises in Shannon and Dublin
air traffic control centres. To further assist in the assessment of task distribution between the
EXC and PLC the EEC provided an example of suitable roles based on experience gained
from other real-time simulations using similar automated systems. These roles were as
follows:
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).
• 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.
• 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.
• 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 main
responsibility was “Advance Warning” or pending flights, while the Executive Controller's
prime responsibility was 'Assumed' flights. However, the task description did not restrict
EEC Report No. 366
43
EUROCONTROL
team co-operation and either controller was free to assist the other as required. Both
control positions were identical in technical functionality, allowing the sector team (EXC and
PLC) to evolve other working methods and re-distribute the sector tasks if desirable. Task
division was not a factor for the single manned sectors.
The combination of the above task allocation scenarios provided a yardstick which assisted
the participating controllers in the collection of valuable feedback on a proposed distribution
of Executive and Planning controller roles. As the controllers had unanimously agreed that
the PLC could not manually update strips and correctly refresh the electronic system
simultaneously, the results derived were based on a no-flight progress strip environment.
6.2.
CONTROLLER ROLE RESULTS
The controllers stated that the functionality of each control position should be identical to
enable the controllers themselves to create an appropriate task division and not have one
imposed by the system. This also allowed them to modify the task division when traffic
levels increased or decreased. They did feel that the PLC and EXC were able to work
together 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 the
management of the sector?
65,00%
Regularly
Sometimes
Always
13,00%
22,00%
Graph 19: PLC/EXC Teamwork
Although the roles of the PLC and EXC were reasonably well defined, the task allocation
between Planning Controller and Executive Controller was not always clear. This may have
been a result of allowing too much flexibility in the system configuration, or a result of the
short simulation period in gaining familiarity with the roles. While some versatility was
incorporated to allow for a distribution of workload, some actions (e.g. CFL input) although
considered the key responsibility of one controller, were often shared between the two sector
controllers. The impact of this indistinct task allocation was minimal although confusion over
individual responsibilities occasionally surfaced.
The case for such inter-operability was discussed during the debriefing sessions. The
controllers were divided on the procedure that should apply for 'CFL input' and 'Assume
Input'. Some controllers stated that only the Executive Controller should make these inputs.
44
EEC Report No. 366
EUROCONTROL
At issue was the amount each input contributed towards maintaining the 'radar picture' and
whether sharing of these tasks meant a degradation of the Executive Controller's situational
awareness and control.
Further consideration is recommended before placing any restriction on the system
functionality. Any limitation may be implemented using controller procedures thereby
allowing flexibility while the implications are fully evaluated.
Were you unclear as to whether certain tasks should be performed by the PLC or the EXC?
Rarely
18,00%
Regularly
18,00%
Sometimes
Always
60,00%
4,00%
Graph 20: PLC/EXC Task Allocation
All controllers agreed that the implementation of the new ATM system technology would
result in a change of role assignments between the Executive and Planning controllers.
Subjective debriefing sessions led to the following conclusions and recommendations.
EEC Report No. 366
45
EUROCONTROL
Dublin ATCC
The Dublin controllers were unanimous in their opinion that the EXC should continue to
provide the radar service while the PLC would electronically interface with and update the
various windows and text lists that will eventually replace the flight progress strip
management functions currently in use.
Controller roles will require further review and critical assessment when the final
configuration 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. The
on-suite position of EXC and PLC was not considered relevant for the automated paperless
environment.
The Executive controller should:
•
•
•
•
•
46
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.
EEC Report No. 366
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 an
eastbound oceanic flow) and could interface with other windows (e.g. Referred CRD) when
required.
Photo 4: Example of Shannon ATCC Controller Working Positions (CWP)
EEC Report No. 366
47
EUROCONTROL
7.
CO-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 from
one 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 is
then transferred when it is at the boundary. Where this communication is carried out by
telephone, the passing of data on individual flights is a major support task, particularly at
Area Control Centres.
The operational use of connections between Flight Data Processing Systems (FDPS), for the
purpose 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 in
the EUROCONTROL Standard for On-line Data Interchange Edition 1, which was
subsequently revised as Edition 2. The upgrade from OLDI Edition 1 to Edition 2 is generally
known as System Supported Co-ordination (SYSCO).
7.2.
IRL2000 ENVIRONMENT
The assessment of SYSCO during the simulation was split into two separate phases. The
first phase assessed co-ordination by telephone while the second phase assessed a more
automated system without the use of flight progress strips.
The full specifications for each phase are provided in the Ireland 2000 Real-time Simulation
System 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 coordination before transmission of the ACT message. After transmission of the ACT message
co-ordination was by telephone.
The second phase supported full electronic co-ordination between all sectors and centres
without the use of flight progress strips.
For each flight an Activation Message (ACT) was transmitted 15 minutes prior to the sector
exit boundary, with all revisions after this treated as 'Referred Revisions', in that they had to
be agreed by both controllers. The system supported Planned Entry Flight Level (PEL), Exit
Flight Level (XFL) and Direct (DCT) co-ordination as well as Transfer of Control and Request
on Frequency (ROF) messages.
Co-ordination was possible to 'propose', 'counter-propose' or 'reject' a proposal. Messages
were displayed in the Co-ordination Windows and also coded into the track label and list
HMI.
48
EEC Report No. 366
EUROCONTROL
Correct sector sequence and co-ordination partners were determined from the aircraft
trajectory, which was modified following the controller input of data. If a controller input a
new XFL or DCT, this updated the aircraft trajectory (and formulated a new sector sequence
if required).
Sector SH2
Proposed
XFL
Original
XFL
Proposed
PEL
Original
PEL
Sector BR3
Figure 17: Co-ordination Horizontal Sector Boundary
7.2.1.
Electronic Co-ordination in the Vertical Plane
Input of a new XFL value (after ACT) was displayed as a PEL co-ordination at the next
sector. When agreed the new value would update the aircraft trajectory. When two sectors
are superposed such as Cork 1 (CK1) and Super F (SPF) were in IRL2000, the boundary
between the two sectors is found in the vertical plane. For these cases, special functionality
was required. Firstly the display of XFL/PEL becomes problematic. Displaying the boundary
level (FL355) for all aircraft was not operationally suitable; therefore the target level for the
flight was treated as the XFL/PEL value.
Regularly the rule, 'Climb as soon as possible, descend as late as possible' is used to
construct an aircraft's trajectory, as it represents the most economic profile for the aircraft.
However, in the vertically split sector environment, the new XFL value must be applied
immediately rather than at the end of the sector, to correctly reflect the profile of the aircraft
and construct the new sector sequence.
Proposed
XFL 290
Sector SPF
Boundary Level F355
Sector CK1
Proposed
PEL 290
Figure 18: Co-ordination Vertical Sector Boundary
The problems associated with vertically split sectors were increased with the superposing of
Shannon 3 (SH3) over both North Low (NLO) and South Low (SLO).
If for example, Shannon 3 (SH3) proposed a new XFL for descent to South Low (SLO), while
the aircraft was still flying over North Low (NLO), the agreed XFL value was 'applied
immediately' (Example A) updating the trajectory and bringing North Low (NLO) 'incorrectly'
EEC Report No. 366
49
EUROCONTROL
into the sector sequence. If the XFL was applied 'as late as possible' (Example B) then coordination was possible with South Low (SLO). However in this case, Shannon 3 (SH3) was
never able to propose a descent to North Low (NLO).
XFL 230
Example A
Sector SH3
XFL 230
Example B
Boundary Level F245
EFL 230
Sector NLO
EFL 230
Sector SLO
Figure 19: Co-ordination Super Sector with Vertical Boundaries
Note
The client team reduced occurrences of this problem during the simulation by maintaining a
predefined sector sequence and by assuring in as far as possible that sectorisation
configurations did not include a sector superposed over two or more sectors. In reality, the
problems related to superposing one sector over two or more sectors in a vertically split
configuration will prove far more difficult to resolve.
7.2.2.
Electronic Co-ordination in the Horizontal Plane
As with controller inputs in the vertical plane, DCT inputs in the horizontal plane caused a recalculation of the trajectory. As co-ordination takes place between two co-ordination
partners, this could have the effect of bringing other sectors into the sequence, without their
consent or option of refusal. In order to reduce this risk and to ensure that co-ordination of
route changes always took place, several rules were imposed on the DCT functionality.
The DCT input could be made to points within the current sector at any time. However, a
DCT to points in the next sector could only be made if an Activation Message (ACT) had
been sent, therefore ensuring the DCT was treated as a 'Referred Revision' requiring the
approval of the next sector. If no ACT had been sent this could be initiated before the
scheduled time from the Callsign Menu (Force ACT). When the DCT input placed the profile
of the flight into a sector that was not originally in the predefined sector sequence, thus
creating a new next sector, no co-ordination was required and the original next sector was
abrogated.
7.2.3.
Co-ordination Interface
Two windows were provided to enable co-ordination messages to be sent and received. The
Message-Out (co-ordination out) window displayed messages sent to others sectors. The
Message-In (co-ordination in) window displayed messages received from other sectors,
awaiting a response. The windows were only displayed when a message was present and
resized to display additional messages. Messages were sorted in time order with the earliest
message at the top.
50
EEC Report No. 366
EUROCONTROL
Figure 20: Example of Message-Out Window
The Co-ordination windows allowed changes for flights to be proposed. Proposals could be
accepted or rejected and if necessary counter-proposals could be sent. Co-ordination was
possible 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 to
assist the controllers in identifying which co-ordinations were awaiting a response. A coordination message was displayed in the Co-ordination window, with the data element also
shown in the track label and other lists (i.e. SIL/SEL/ARR/DEP) in the appropriate (pink) coordination colour.
7.3.
CO-ORDINATION RESULTS
7.3.1.
Phase I
The co-ordination specifications In Phase I, where flight progress strips were used, were
limited in terms of SYSCO functionality. In effect, no Message In/Out windows were
provided. New values reflecting changes (e.g. XFL, DCT) entered before ACT transmission
were shown in the normal aircraft state colour. After ACT transmission co-ordination was by
telephone. Flight strips were also updated to reflect the agreed changes. Updates in the
electronic system were displayed in ‘Green’ in the downstream sector’s label and lists. The
downstream sector could acknowledge the co-ordination proposal and no counter proposal
was possible.
From Day One of the simulation it was obvious that planning controllers would experience
severe difficulty with co-ordination in that in proved extremely difficult to simultaneously
update the flight progress strips and electronic system while also coping with heavy
telephone usage. This problem was further exacerbated when traffic was increased to longterm future traffic levels.
7.3.2.
Phase II
Phase II provided full SYSCO functionality. Message In/Out windows were provided.
Counter-proposal of co-ordination proposals was possible. However, the response to a
counter-proposal was limited to either ACCEPT or REJECT. A REJECT was followed by a
telephone 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 well
able to manage without flight progress strips. Dublin controllers opted not to use SYSCO as
the preferred to communicate by voice and/or intercom. They considered this method to be
more suitable in terms of speed and user-friendliness to their dynamic approach and shared
EEC Report No. 366
51
EUROCONTROL
airspace environment. They noted however that inter-sector transfers initiated in error could
not be undone. This problem proved extremely frustrating and will need to be addressed in
the 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-ordination
information. The vast majority (83%) stated that detailed information on inbound aircraft was
always available in reasonable time. While they considered that the presentation of coordination information in the track labels was reasonably clear and unambiguous, they
recommended that different co-ordination colours should be used to differentiate between
co-ordination in and co-ordination out. Our experience from previous simulations concurs
with this. Indeed, this recommendation was further highlighted by the fact that 88% of the
controllers preferred to co-ordinate via the data label rather than the Message In/Out
windows.
Over 70% stated that the electronic transfer was preferable to the current system
methodology and that the transfer functions significantly reduced their workload compared
with normal working practises. On the other hand while 70% agreed that the capability to
hand-over a flight to the downstream sector and receive an acceptance reduced workload
compared with manual methods, they also stated that the capability to only accept or reject a
counter-proposal was a significant limitation. Indeed, in complex situations they felt it was
not 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 operational
shortcomings.
The display of a 'Default XFL' value for flights climbing from a High-level sector to a Super
sector 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 lower
than the highest level in the High-level sector (for descending traffic) was used this allowed
controllers to climb or descend aircraft to these levels without co-ordination and without
knowledge of other conflicting aircraft.
The controllers recommended that for co-ordination the ‘Default XFL’ should be the first level
of 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. Acceptance
of co-ordination should imply clearance to climb or descend. Subsequently, all climbs and
transfers should be immediate.
Careful sector design will be required to avoid flights clipping small segments of adjacent
airspace and to allow standard DCT routes to be applied without generating sector sequence
anomalies. While large sectors with straight-line boundaries are preferred, sector design
must also accommodate traffic flows and sector capacity limitations, sometimes inhibiting
ideal design.
Although the provision of vertically split sectors in the IRL2000 simulation raised several
pertinent issues; the controllers strongly supported the use of system supported electronic
co-ordination. Comments from the controllers identified benefits such as greatly reduced
telephone communication, faster and more silent co-ordination, and a reduction in ATC task
load.
52
EEC Report No. 366
8.
EUROCONTROL
AIRSPACE AND ATC PROCEDURES
Investigate further the findings of the fast-time study regarding airspace changes to
both Shannon and Dublin. Specifically to assess the operational impact of the
following changes:
•
•
•
•
•
•
•
•
•
•
•
8.1.
Re-sectorisation of Shannon ATCC - Low Level.
INTRODUCTION
The above Shannon / Dublin station specific objectives were derived from the results,
conclusions and recommendations of an Airspace Model Simulation of Irish Airspace carried
out 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 controller
workload of future sectorisation plans for the land area sectors (including Dublin) and also
the impact of future traffic, procedures and equipment. The objective of the Fast-Time study
was the optimisation of ATM systems in Ireland so that the requirements of the users would
be met and that the anticipated growth in air traffic to 2001, in line with EUROCONTROL
forecasts, would be catered for in the appropriate airspace structures and operating
procedures.
The above listed objectives, simulated in five separate organisations, encompass widely
ranging issues involving sectorisation configurations (including the Shannon / Dublin
interface), manning levels, medium and long term traffic level forecasts. Furthermore,
specific station objectives included ATC procedures, positioning of holding patterns, parallel
runway operations and Arrival Management (AMAN).
To facilitate the analysis of the objectives this chapter is divided into three main results
sections pertaining to:
•
•
•
Shannon / Dublin Interface Results
Shannon Specific Objectives Results
Dublin Specific Objectives Results
EEC Report No. 366
53
EUROCONTROL
8.2.
SHANNON / DUBLIN INTERFACE RESULTS
The Shannon / Dublin interface was simulated in Organisations A and B. The interface was
based 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 for
approaches to Rwy10 at Dublin. The airspace between 0630°W and 0730°W from FL195 to
FL245 was delegated to Shannon Low-level to facilitate their handling of traffic overflying
Dublin transiting to/from Shannon, Cork and various regional airports.
Shannon controllers found that the delegated airspace was not sufficient and that increased
co-ordination was required to cope with transiting traffic, particularly when long term forecast
traffic levels were tested. Dublin agreed that increased co-ordination had been generated
but emphasised their view that co-ordination was not required as both centres could see the
traffic and a review of current Letters of Agreement and inter-centre co-ordination
procedures could easily resolve this problem.
Another aspect of the delegated airspace issue was the fact that Shannon felt that the
airspace was only required by Dublin when Rwy10 was active whereas they regularly
required it for climb and descent of traffic. They considered that the use of delegated
airspace (not necessarily confined to the dimensions simulated) should be flexible and not
specifically or permanently assigned to either centre.
Dublin however, insists that the extension of their airspace to 0730°West (up to FL245) is
necessary 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 traffic
levels, as already at current traffic levels, the eastern holds of ROKNA and TULSO are
regularly 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’s
requirements was not resolved before the simulation. Therefore a compromise was reached
in 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 Lowlevel was not being simulated.
Further evaluation and discussion of the delegated airspace issue is recommended before
any final concrete decisions or conclusions can be drawn.
8.2.1.
Use of procedures for dealing with High Level traffic inbound to Belfast Airport
All the controllers agreed that the procedures for dealing with High-Level traffic outbound
from and inbound to Belfast Airport worked very well. In practice, Dublin climbed traffic to
FL230 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 of
Dublin VOR) and released the traffic to Dublin for further descent. No co-ordination was
required.
54
EEC Report No. 366
8.3.
EUROCONTROL
SHANNON SPECIFIC OBJECTIVES RESULTS
These results assess the operational impact of re-sectorisation configurations in Shannon
Low-level and Shannon High-level as well as procedures related to new SIDS/STARS for
State 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 Level
Apart 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 offshore
airspace 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 A
proved extremely difficult. Controllers felt that there was far too much traffic on the
frequency. Their ability to deal with the traffic volume was also impaired by the flight strip
printing and dissemination problems that existed throughout Phase I of the simulation. Their
consensus 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 SLO
and they opted to focus their attention on further simulation of this, without using flight
progress strips.
Shannon North Low (NLO) and Shannon South Low (SLO)
This two-sector configuration was simulated in Organisation B using both medium and longterm forecast traffic levels. This configuration worked quite well although some controllers
identified the possible need for another low level sector to cope with future traffic levels
anticipated for Cork and Waterford. A better solution to this problem could be to re-assess
the geographical dimensions of the NLO/SLO sectors and in particular re-locate the interface
boundary between NLO and SLO further south. This, coupled with further evaluation of the
dimensions 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 NLO
and SLO to cope with situations when the TMA hold was full. They also recommended that
the control of arriving and departing traffic to/from Kerry should be the responsibility of the
TMA controllers.
In Organisations A (LOW) and B (NLO/SLO) the transfer of all offshore airspace west of
1030° West to Shannon High-level worked very well and should be implemented.
Shannon TMA
Organisations A and B also assessed the implementation of a proposed TMA sector within
the Shannon FIR. Following simulation, all controllers confirmed the necessity for a TMA
sector while recommending various improvements in terms of design and operating
procedures, as outlined below.
The geographical dimensions of the TMA should be re-assessed with defined Entry and Exit
Points structured to comply with current lower and upper ATC routes. The simulated design
did not allow much room to the east for manoeuvring aircraft. New ATC procedures will be
required for the interface between low-level and high-level sectors and the TMA. The design
of new SIDS/STARS will need to comply with TMA entry/exit points for traffic departing from
and arriving to Shannon and the regional airports. STARS should be used in preference to
EEC Report No. 366
55
EUROCONTROL
radar vectoring as this could prove to be too complex. Radar co-ordination procedures will
also be required.
The controllers stated that the TMA should be manned by at least two controllers. The TMA
hold should control all aircraft from the level above the transition level (TL) up to FL140. The
TMA planning controller should assign levels to the low-level sectors (NLO/SLO) when they
become 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 in
Organisations A and B. Long-term traffic levels quickly caused problems for APP with high
R/T loading. Proper maintenance of the electronic HMI made it impossible to simultaneously
use flight progress strips, even with medium-term traffic levels.
The controllers
recommended that the APP controller should be responsible for aircraft holding at the TL in
the 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 to
Shannon
In Organisations A and B the Entry Fixes to the holding patterns (SCARF and FOY) were
initially positioned at 15nm on final approach to runways 24 and 06 respectively. The
controllers quickly found these locations to be unsuitable due to the amount of label clutter
generated on final approach. All the controllers agreed that the holds should be offset from
the final approach paths and discussions resulted in numerous suggestions for suitably repositioned sites. New locations were finally agreed siting SCARF at 5240°N 0820°W (south
of 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 the
availability 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 airports
Simplified SIDS and STARS for Shannon, Cork and the regional airports were specifically
designed for the simulation. Full details of the SIDS/STARS used can be found in the
Ireland 2000 Real-time Simulation Facility Specification Part 1 – Operational Conduct and
Analysis [Reference 1].
The Shannon SIDS worked quite well. All controllers liked the fact that departure routes
were clear of arrival routes. The default levels applied proved suitable, removing
unnecessary co-ordination. During the simulation, the Rwy24 SID for departures to Dublin
(DUB2B) followed a left turn. When the NLO/SLO sectorisation was simulated controllers
felt that a right turn after departure would have been more suitable. The STARS simulated
were based on the original positioning of the hold fixes on final approach. Following the
repositioning 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. The
controllers suggested that future SIDS/STARS should be designed with regards to the
requirements of the NLO/SLO and TMA sectors. In effect, SIDS terminating at TMA exit
points and STARS commencing at TMA entry points, would ensure that the sector sequence
for departing and arriving traffic was correctly addressed.
The regional airports SIDS/STARS generally worked very well. Controllers had no difficulty
with 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 the
relevant sector’s departure list. Arriving aircraft were descended to the TL (FL60) and
56
EEC Report No. 366
EUROCONTROL
transferred to the Ireland Domestic Feed Sector, when clear of departing traffic. The
controllers agreed that if the new system included on-line connections to the regional airports
and proper radar coverage was available, there should be no requirement for co-ordination
between Shannon and the regional airports.
They, therefore, recommended that
SIDS/STARS should be developed for all regional airports.
8.3.4.
Re-sectorisation of Shannon ATCC - High Level
Three Organisations (C, D and E) focused on different sectorisation configurations for
Shannon High-level. In brief, Organisation C simulated a westerly flow of oceanic traffic in a
sectorisation configuration encompassing the Shannon UTA and the northern portion of
SOTA airspace. Organisation D simulated an easterly flow of oceanic traffic in a
sectorisation configuration encompassing all SOTA airspace and the southern portion of the
Shannon UTA. Finally, Organisation E simulated a westerly flow of oceanic traffic in a
second sectorisation configuration encompassing SOTA airspace and the southern portion
of the Shannon UTA.
Full details of the Shannon High-Level Sectorisations simulated can be found in the Ireland
2000 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 high
traffic loads on the same track and could prove essential when RVSM is introduced in
Europe. The use of the Super sectors was also considered very beneficial. The level split
between the vertical sectors differed depending on the direction of the oceanic traffic flow. In
Organisations C and E (westerly flow) the level split applied was FL335, whereas FL355 was
used in Organisation D (easterly flow). There was not enough time during the simulation to
test other variables for each organisation. Following detailed examination and analysis of
the traffic samples the client selected the level splits for simulation in each organisation. In
real operations the strategic selection of level splits between the vertical sectors could be
advantageous.
Sector design, an area much evaluated for Shannon Low-level, proved to be the main
problem faced when simulating Shannon High-level. In this case however the problems
were related more to the HMI than the sector dimensions. At present, electronic systems
have great difficulty with vertical sectorisation plans in terms of trajectory prediction and
calculation of climb and descent profiles. This, in turn, can seriously effect sector sequence
computation, thereby creating erroneous electronic co-ordination messages.
As mentioned in the previous chapter, these problems can be greatly reduced by careful
sector design that reduces clipping of sector segments and accommodates traffic flows.
However, the sectorisation used in Shannon High-level, which is dynamically and
strategically modified to meet oceanic track requirements will prove extremely difficult to
replicate in the future system where the HMI emphasis is based on label state, colour, sector
sequence and SYSCO co-ordination.
EEC Report No. 366
57
EUROCONTROL
8.4.
DUBLIN SPECIFIC OBJECTIVE RESULTS
These results assess the operational impact of re-sectorisation configurations in the Dublin
CTA as well as ATC procedures relating to SIDS/STARS, parallel runway operations, hold
stack usage, arrival management and separation of aircraft on final approach to Runway
10R at Dublin airport.
8.4.1.
Re-sectorisation of Dublin ATCC
The Dublin strategy for re-sectorisation evaluation involved a step-by-step introduction of
new sectors and ATC procedures. While Organisations A and B mainly focused on the
Shannon/Dublin interface, the Dublin sectorisation evolved from the present day
sectorisation, in Org. A, to the introduction of a Departure sector (DEP) in Org. B. Further
organisations simulated other new sector combinations evaluating the introduction of a Final
Approach sector (FIN) and a western sector (ARW). Simplified SIDS and STARS were
specifically designed for use during the simulation. Medium and long-term forecast traffic
was tested using Runways 10L/28R with exercises concentrating on Runway 28L and 28R
operations. Please note that parallel runways do not currently exist at Dublin but were
considered to exist for simulation purposes.
Full details of the Dublin ATCC Sectorisations simulated can be found in Annex I and also in
the Ireland 2000 Real-time Simulation Facility Specification Part 1 – Operational Conduct
and Analysis [Reference 1].
Dublin Departure (DEP)
The DEP sector, manned by a single Executive Controller, accepted departing aircraft from
the Tower (TWR) feed sector. Operating within a 15nm radius of the airfield, the DEP
controller 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 it
significantly reduced the workload currently experienced by Area sector controllers, with
regards to the identification and handling of departing traffic. While co-ordination was
occasionally required with the Approach sectors to resolve conflicts controllers disapproved
of the practice of routinely running departing jet aircraft to the markers (as opposed to
3000ft.) 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 and
HMI. All controllers endorsed the appropriateness of the labels, Exit point information and
pre-defined default levels.
Final Approach (FIN)
The FIN sector, manned by a single Executive Controller, accepted traffic from the North
Hold Approach (APN) and South Hold Approach (APS) sectors and sequenced them for final
approach, transferring them to the Tower (TWR) feed sector when appropriate. 3nm
separation was permitted (in all organisations) on final approach to Rwy28L (Rwy28R was
used solely for departures), due to the planned introduction of a rapid exit taxiway for Rwy28
at Dublin airport. 5nm separation was used for approach to Rwy10R (Rwy10L was used
solely for departures).
Controllers reaction to the introduction of the FIN sector was also positive but they stressed
that new procedures and more experience would be required to optimise it’s impact. Before
the simulation, approach controllers had no previous experience in the application of 3nm
separation on final approach. They found it extremely difficult to apply this tight separation
successfully due to the limited dimensions of the airspace permitted for its use. The FIN
controller tended to take control of traffic further and further from final approach in order to
close gaps between aircraft departing from the holding stacks. Many controllers considered
that the application of 3nm separation on final approach from 15nm to touchdown was too
58
EEC Report No. 366
EUROCONTROL
restrictive. Extensive training and experience will be required to perfect skills in the
application of 3nm separation involving strict use of speed control and new working
procedures. The controllers recommended a review of, and extension to, the airspace
permitted for application of 3nm separation.
Dublin West Area (ARW)
The ARW sector, manned by a single Executive Controller, was introduced in Organisation E
in conjunction with the use of one-man sectors. Results are shown in the forthcoming
section 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 in
use 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 and
holding 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 to
current practices in that both Hold Approach sectors co-ordinated verbally with the FIN
controller for arrival sequencing. Verbal co-ordination was preferred to telephone and/or
electronic co-ordination as the Hold Approach controllers sat each side of the FIN controller
with their relevant Area controller positioned to their other side. The controllers considered
the introduction of the FIN sector to be a reasonably easy transition from current practices
that would improve with new working procedures and experience.
All controllers registered their satisfaction concerning the suitability of the airspace and the
selection 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 in
that (as mentioned earlier), it significantly reduced their workload related to the identification
and handling of departing traffic. There was consensus with regards the FL90 (non-jets) and
FL100 (jets) default flight levels for departing traffic but some controllers felt that the default
flight level of FL120 for arriving traffic was too restrictive. Inter-sector co-ordination with APN
and APS was verbal whereas on the few occasions that co-ordination was required with the
DEP sector, voice and telephone usage was half-and-half.
8.4.2.
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 the
north and west. The planning controllers were removed from the ARN and ARS sectors
leaving a configuration using one Executive Controller in each simulated sector. It must be
stressed that simulation of one-man sectors was an effort to reduce workload by spreading it
evenly between three as opposed to two executive controllers. It should not be seen in any
way 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 in
the Ireland 2000 Real-time Simulation Facility Specification Part 1 – Operational Conduct
and Analysis [Reference 1].
The ARW sector took all traffic previously handled by ARN (except for flights on the B1 and
W911D), 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 both
the APN and APS approach sectors. Controller first impressions were that the ARW sector
worked quite well, alleviating workload in the busier ARN and ARS sectors. However, further
examination of how to handle simultaneous northbound overflights on the UP600 and UR14
EEC Report No. 366
59
EUROCONTROL
will be required. The interface between ARW and all adjacent sectors of Shannon and
Dublin will also need further investigation.
Organisation E also introduced new parameters including re-designed SIDS and STARS
linked to a Four-Quadrant Hold scenario as well as parallel runway operations for Rwy28L
and Rwy28R. Feedback results on these parameters are outlined in paragraphs 8.4.3 and
8.4.4.
8.4.3.
Re-positioning of the DINIL and NASRI holds and the Dublin CTA western
boundary
The western holds of DINIL and NASRI were simulated in their new positions in all
organisations simulated. The relocation of the Dublin CTA western boundary permitted the
use of these holds and their inherent buffer airspace requirements. Their new location
further from the airport facilitated vectoring to all runways, particularly Rwy10R. Their
position also facilitated departure flows in that they reduced the area of conflict between
departing and holding traffic.
The Four Quadrant Hold scenario gave ARN sole control of the ROKNA hold, ARS sole
control 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 used
irrespective of the runway in use, whereas, in previous organisations holds were linked to the
runway in use - ROKNA and TULSO for Rwy28L and DINIL and NASRI for Rwy10R. New
SIDS/STARS were designed to comply with the 4-Quadrant scenario. In Org. E all exercises
were based on the use of Rwy28L for arrivals and Rwy28R for departures. The Controllers
also stated that re-positioning of the western holds gave approach controllers sufficient
space and time to integrate traffic from DINIL and NASRI with traffic from ROKNA and
TULSO.
However, as mentioned earlier, the extension of the Dublin CTA to 0730°W could seriously
impact on Shannon Low-level operations, particularly when traffic is being held above FL140
at DINIL and/or NASRI.
8.4.4.
Implementation of parallel runway operations at Dublin Airport
Organisations D and E included simulation of parallel runway operations using 3nm
separation on final approach to Rwy28L and 5nm separation on final approach to Rwy10R.
With parallel runway operations Rwy28R and Rwy10L were designated solely for departures
with Rwy28L and Rwy10R designated solely for arrivals. The main reason for this was to
remove the need for preparation of STARS for the newly installed 28R/10L runway. This
also provided another advantage in that it simplified and facilitated the preparation of the
data for the MAESTRO arrival management system.
The controllers agreed that the introduction of the parallel runway had an extremely
beneficial effect in that it provided a runway free to readily cope with all departures and
allowed consistent use of 3nm separation to aircraft on approach to Rwy28L. However, new
procedures and working practices would be required before implementation. The controllers
believe that the absence of a parallel runway at Dublin could serious impact ATC operations
in terms of holding and delay to departures, when long-term forecast traffic becomes a
reality.
60
EEC Report No. 366
8.4.5.
EUROCONTROL
Use of 3nm separation between aircraft on final approach to Runway 10R
The 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 the
various technical difficulties encountered, necessitated the cancellation (with client
agreement) of Organisation F where simulation of Rwy10L and Rwy10R operations was
intended.
8.4.6.
Introduction of an Arrival Manager system (MAESTRO) at Dublin ATCC
The MAESTRO Arrival Manager was introduced in selected exercises during simulation of
Organisations C, D and E. The heavy long-term forecast traffic levels simulated in these
organisations, coupled with the fact that the controllers had no previous experience in, or
procedures for, the use of the tool, limited its evaluation. In effect, controllers did not use the
AMAN system but monitored its operation with valuable assistance and advice from an
experienced operator - Claude Barret, an air traffic controller based at Charles DeGaulle
airport. Jean Louis Garcia of STNA also assisted when possible.
The controllers were impressed by the system and put forward various recommendations as
to 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’s
airspace is similar to Dublin’s in that the main approach is very close to the adjacent Malmo
FIR boundary. Controllers there use the tool to successfully regulate and optimise the flow
of arriving traffic at the TMA entry points. All controllers recommended that IAA management
should send ATCO groups to Copenhagen to study their operating procedures. This would
greatly assist the preparation of operating procedures for Dublin.
They also highlighted the fact that the installation of the MAESTRO system at Dublin would
require the co-operation of both Manchester and London ATCC’s.
They felt that MAESTRO would prove valuable for creating gaps on approach to
accommodate departure flows in single runway operations.
The APN and APS approach controllers found that when the system was set to runway
mode it was difficult to quickly pick out their respective aircraft. Sector-linked colour coding
of the aircraft callsigns in the display would solve this problem.
All controllers felt that the MAESTRO system should include functions that provided
minimum and maximum holding times as well as hold stack to runway times. Set up for the
holds would require new letters of agreement with MATCC/LATCC. After the holds the
sequence should be determined by the approach sectors, using their vectoring skills to
optimise the flow of traffic to the runways.
Finally, with regards to the siting of the MAESTRO display, area and approach controller
opinion was unanimous. The display should be stand-alone on the CWP and not integrated
within the 2k x 2k radar screen.
EEC Report No. 366
61
EUROCONTROL
9.
CONCLUSIONS AND RECOMMENDATIONS
The Irish Aviation Authority plans to implement a new ATM System - CAIRDE 2000 (Civil
Aviation Integrated Radar Display Equipment) which will enable the Authority to provide safe
and cost effective services to its customers in the first decade of the new millennium, in line
with 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 and
planning controllers. Secondary objectives concentrated on sectorisation configurations and
operating procedures specific to the Shannon and Dublin air traffic control centres.
The airspace simulated included Enroute, TMA, Approach and Departure sectors as well as
the Oceanic interface with the Shanwick Oceanic Control Area (OCA).
The simulation successfully achieved the many objectives set out at the project conception
and was extremely important to Ireland as part of the IAA installation plans for its new ATC
system. The participating controllers gained valuable experience working in an automated
HMI environment incorporating advanced safety features and a fully stripless environment.
Their motivation and professionalism in the evaluation of the system and airspace proposals
was of enormous value for the long-term success of the CAIRDE project. The simulation
output will be a significant contribution to the new system specification.
A summary of the conclusions and recommendations in relation to the detailed objectives is
provided below:
9.1.
OBJECTIVE 1
Controller Interface (HMI) Evaluation
Evaluate 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 2000
HMI 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 and
that 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 an
operational system. Most controllers agreed that the integration of multiple display/input
windows 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 standalone and not integrated within the radar window.
Significantly, 82% of the controllers agreed that the combination of dynamic flight leg with
conflict information, interactive radar labels and lists provided a satisfactory system that
permitted the removal of paper flight progress strips.
62
EEC Report No. 366
9.1.1.
EUROCONTROL
Three Button Mouse
The controllers indicated that the mouse was acceptable as a means of data input. While
they quickly became familiar with the mouse functionality, some confusion was initially
experienced as the functionality differed to that of the instruction handbook in that the
positions of the Information Button (IB) and Special Button (SB) were reversed. Therefore,
some controllers experienced difficulty with the association and identification of the mouse
buttons. The controllers recommended that different surface textures could assist with
button identification.
Mouse reliability was considered of paramount importance for controller confidence. In the
event of a mouse failure, it must be possible to replace it quickly and efficiently with minimum
disturbance for the controller and no effect to the windows operating system. CWP design
should also take account of the different requirements of left-handed and right-handed
operators.
9.1.2.
Windows and Pop-up Menus
While the vast majority of the controllers agreed that a windows style environment was 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 radar screen
could 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 radar
screen are optimised.
The controllers found the pop-up menus easy to handle with adequate easily selectable
options. However, some difficulties were experienced with incorrect default settings resulting
in cumbersome scrolling to select the desired value.
9.1.3.
Label and track results
The majority of the controllers (80%) agreed that the range of information displayed in the
radar labels (Unselected, Selected and Extended Label Window) was appropriate. However,
in the first weeks of the simulation, label selection and management proved extremely
difficult. Controllers stated that the physical act of label selection proved awkward as
controllers consistently found that unconcerned labels would select when they were trying to
select the desired assumed, advance warning or concerned label. In effect, label sensitivity
and transparency created controller frustration with the system and unnecessary extra
workload.
The controllers recommended that label selection should be by moving the mouse over the
label or track symbol. A ‘press and hold’ feature, applied later in the simulation, for selection
of Unconcerned labels, significantly reduced unnecessary interaction with these labels. Most
controllers said they would prefer that individual label selection should be limited to as small
a 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 label
de-confliction was available in the simulation but the controllers found this feature annoying
as the constant ‘staggered movement effect’ of the radar labels on the screen proved more
of a distraction than a help.
They recommended that label movement should be simple and flexible and appreciated the
various methods available to resolve label overlap. The ‘drag and drop’ functionality was
preferred to the pre-set positions. Pre-set positions allowed controllers to choose a predefined position for all labels on the radar screen. Drag and drop provided even greater
flexibility for label management. Although this involved extra work, controllers felt that they
EEC Report No. 366
63
EUROCONTROL
refreshed their mental traffic picture as they manually relocated the labels and did not find it
too tiresome. Indeed, a functionality that allowed the controller to select pre-set positions for
individual labels or sets of labels (eastbound, westbound, arriving, departing) would be
advantageous.
Controllers often experienced difficulty in associating the track label with the Radar Position
Symbol (RPS), particularly when the label orientation was west to north-west of the RPS. In
these 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 first
field of the label. In addition, the lead line should be colour coded to distinguish it from the
speed vector and dynamic flight leg.
9.1.4.
Colours
The use of colours for labels (and lists) was very successful, with the vast majority of
controllers stating that the use of colour coding for labels and text was logical and
understandable 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 very
good. The colour brilliance was reduced during the simulation as although it was considered
very good for the track labels, it became a little bit uncomfortable when a lot of text was
presented in the various lists provided. The White for ‘Assumed’ aircraft was also
considered to be too bright and they recommended that the brilliance should be reduced.
The IRL2000 HMI specified extensive use of background colour change to highlight
information. Subtle change of background colour was very successfully used to crosshighlight all data associated with a particular flight. For example, when the mouse cursor
came to rest on a radar label not only was the Extended Label Window (ELW) updated with
the appropriate flight details but the related lists (SIL, SEL, DEP, and ARR) were also
presented with a highlighted background. The background colour change for this type of
highlighting was just sufficient to ensure that the data could be easily located but legibility of
text was not affected. Controllers greatly appreciated the effectiveness of this feature.
Shannon and Dublin controllers had different views regarding the Mustard and Grey colours
selected for ‘Concerned’ and ’Unconcerned’ labels respectively. Shannon found the Mustard
to 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 Grey
colour for Unconcerned labels. In real operations, the Dublin TMA is shared simultaneously
by several controllers operating various sector positions. The Controllers felt that the aircraft
state system as simulated, was not particularly suitable for their operations. Controllers
stated that although certain aircraft could be considered as ‘Unconcerned” to their sector, it
was still important that they were clearly visible. The found the Grey to be unsuitable, so
Mustard was used for all ‘Concerned’ and ‘Unconcerned’ labels in Dublin CTA. This was an
improvement, but not considered the ideal solution (See STCA Results Section 5.3.1).
Recommendations for further improvements varied from brightening the Mustard colour to
altering the Callsign and Actual Flight Level (AFL) fields to White. In short, the methodology
of defining and displaying ‘Concerned’ and ‘Unconcerned’ traffic to each Dublin sector
individually, requires further investigation.
64
EEC Report No. 366
9.1.5.
EUROCONTROL
Fields
The controllers stated that the Callsign field highlight colour (Yellow) was good and should
also appear in all relevant lists. During the simulation, (and for the future system), Callsign
highlight was and will be only available between CWP’s of the same sector. Callsign
highlights on ‘Advance Warning’ labels were not over-ridden by White when these labels
changed to transfer-in mode following handover by the upstream sector. In effect, this
meant that the receiving sector was unaware of the handover proposition. Ideally, a
highlighted ‘Advance Warning’ aircraft should change to White ‘Transfer-In’ mode on
handover, and revert to highlight, once the aircraft has been assumed. Controllers also
stated 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 the
same colour should appear in all relevant windows.
Clicking on the inter-active fields of the selected label with the action button opened their
related pop-up window menus. Default values were defined for the pop-up window menus
but in some cases these did not work correctly, resulting in unnecessary scrolling in the popup window to select the desired value. This caused frustration and increased the workload
for the controllers. The problem was further exacerbated by the fact that the principle of XFL
default levels between sectors was not fully understood and employed correctly by some
controllers. AT times XFL’s were entered that were not related to the next sector thus
removing it from the sequence. This resulted in aircraft being abrogated from the correct
receiving sector. Abrogation, a modification that implies that an aircraft will no longer enter
into 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 label
state changed to ‘Unconcerned’.
The main observations of the controllers with regards to the label fields and their related popup 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.
Dublin
The Assume/Hold functionality in the Callsign menu, (mentioned above in the Shannon
observations), was tested extensively by the Dublin controllers. They found it to be very
useful but were divided as to whether or not the default should be to Assume or
Assume/Hold. Some felt that the default to Assume/Hold would result in inadvertent
placement of aircraft in the Hold list. There was no consensus on whether the Assume and
Assume/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 the
very busy Dublin TMA. Further investigation and assessment of the minimum requirement of
mandatory fields should be undertaken
EEC Report No. 366
65
EUROCONTROL
Controllers recorded instances where they transferred aircraft from their sector in error by
inadvertently clicking on the mouse action button (AB). A short delay facility in the system
acknowledgement of inter-sector transfers would permit controllers to retrieve (‘Undo
Transfer’) incorrectly transferred aircraft.
9.1.6.
Exit Flight Level (XFL) Defaults
XFL default settings in the electronic system posed many problems for controllers. In Dublin
CTA, where area, approach and departure controllers share usage of the same airspace the
limitations of the system could be easily overcome. However, the more complicated
sectorisation configuration of Shannon ATCC (Low-Level/High-Level) with vertically superposed sectors proved more difficult to solve. The main problem encountered was which XFL
to apply for an aircraft whose Requested Flight Level (RFL) would involve climb from one
sector to another sector directly above. Use of the RFL would permit the lower sector to
climb the aircraft into the sector above without co-ordination whereas use of the lower
sector’s Planned Entry Level (PEL) would result in no display of an ‘Advance Warning’ label
in the downstream sector until co-ordination was proposed.
The majority of controllers stated that they needed to have the ‘Advance Warning’ label but
did not want the lower sector to have the right to climb without co-ordination. One possible
solution 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
every aircraft and impact on controller workload.
Further evaluation, concerning the authority to climb to the agreed XFL subject to coordination by telephone on potential conflicts, will be required. Controllers also stated that
climbs following co-ordination should be immediate and coincident with transfer of aircraft.
9.1.7.
Oceanic Clearances
Shannon High-Level controllers received Oceanic Clearance Message (OCM) information
via 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 they
agreed that the availability of oceanic clearances in the ELW led to a reduction in their
workload. They preferred, however to access oceanic clearance information through the
SEL.
9.1.8.
VFR Enroute
The simulated system employed pre-determined sector sequence parameters for Shannon
and Dublin ATCCs. This created a problem for VFR operations in Shannon Low-Level
where controllers required a more dynamic versatile system, which precluded the definition
of a fixed flight plan and fixed sector sequence. Dublin ATCC opted not to simulate VFR
operations.
To obtain the necessary flexibility the Low-Level controller was able to select the next sector
and send advance information (via Force ACT) when required. This would change the label
in 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.
66
EEC Report No. 366
9.1.9.
EUROCONTROL
Direct and Re-routing
Dublin controllers did not use the DCT functionality much although they considered it a
useful option. The Shannon controllers, on the other hand, used the functionality
extensively, particularly in the large long High-Level sectors. They found it to be a very
useful 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 the
downstream sector AHDG field.
Controllers were able to re-route aircraft direct to any point in the flight planned route using
the Elastic Vector. If the destination point they selected was not on the original flight plan it
was input by the system into the Assigned Heading field (AHDG). In the system, when using
the DCT functionality, co-ordination will only place when the new point selected is in the
current next sector in the sector sequence, and the aircraft is ACT Out. If a DCT point is
selected in any other sector, the new route will not be co-ordinated. However, the trajectory
will be updated and a new sector sequence will be created. In this case, the original next
sector is abrogated and the next sector receives a short notice ACT (normally following
telephone co-ordination). Abrogation, a modification that implies that an aircraft will no
longer enter into 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 label state changed to ‘Unconcerned’.
The controllers stated that the abrogation function was very useful and the green callsign
very noticeable. In the system being provided to the IAA, abrogation will trigger a message
in the ‘Message In’ window. The general consensus was that the callsign colour change was
both preferable and sufficient, with no requirement for message information and that
abrogation should force through all pre-set filters.
9.1.10. Skip
Controllers were comfortable with the skip functionality but stated that execution by the PLC
should be only after consultation with the EXC. They stated that the radar label in the
skipped sector should remain in the “Concerned’ state until sector exit. Ideally, the coordination process between the sectors should not be frozen. In addition, despite the
availability of a ‘confirm skip’ message controllers stated that an ‘Unskip’ functionality would
be required.
9.1.11. Flight progress strips
The use of flight progress strips in the simulation was the subject of much discussion and
debate between the IAA and EEC project teams. The simulated CAIRDE 2000 ATM system
was mainly based on specifications derived from the EATCHIP Manual of the EATCHIP III
Automated system. This is a fully automated system designed to operate without progress
strips. The advice and opinion of the EEC, based on extensive experience in this area, was
that in order to correctly evaluate the HMI in such a system the use of flight progress strips
should be excluded.
EEC Report No. 366
67
EUROCONTROL
The IAA, on the other hand, is faced with the responsibility of providing a fully operational
and reliable system on schedule. The system requested from Airsys ATM will include full
flight progress strip facilities. System progression will be evolutionary rather than
revolutionary, to avoid the sudden change to a stripless environment which could prove
extremely problematic. Use of strips during the simulation would assist in the determination
of 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 Term
Conflict Detection (MTCD) and Conflict Risk Display (CRD). Co-ordination was by
telephone 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 coordination indications shown in the radar label, ELW and data lists. There were no flight
progress strips.
The controllers were concerned as to the ergonomics of the CWP set-up (including strips) for
the new system. Current suites operate with a single radar display for the EXC and a flight
progress strip board for the PLC. In Dublin ACC the flight progress strip boards are
designed to geographically represent the control area.
The CAIRDE 2000 system provides radar displays for the Executive and Planning
controllers. Difficulties exist in allocating suitable CWP working areas to cater for flight
progress strip and mousepad needs. Keyboard requirements will further exacerbate this
problem. In Shannon High-Level, the sheer volume of aircraft made it impossible to
sectorise the strip board. The controllers found it impossible to keep the flight progress
strips up to date while simultaneously maintaining the electronic system. The consensus
was that the electronic system was preferable and easier to manage. Controllers found that
when they abandoned the strips it greatly improved the “in-suite” teamwork between the
EXC and PLC. Indeed, in Phase II with SYSCO co-ordination and other added
functionalities, 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 and
migration to a “stripless” environment should be addressed sooner rather than later.
Despite having to overcome teething problems with regards to printing strips, errors in strip
details and duplication of strips, the controllers worked extremely hard with the simulated
system. They were commended for their efforts to try to maintain both systems (electronic
and flight progress strip) while safely handling long-term heavy traffic levels forecast for
2007.
Despite these problems the controllers stated that it was difficult to handle more than 10
aircraft while maintaining the flight progress strips and the electronic system. It became
impossible to work radar labels, lists and strips at the same time. During the simulation, the
PLC loaded the strips into the strip holders and boards. This took up valuable time and
caused a distraction from interaction with the system. In fact, the only way to keep strips up
to date was for the PLC to ignore his radar display. All PLC’s preferred to maintain the
electronic system through the radar display rather than maintain strips.
Controllers felt that the Dynamic Flight Leg (DFL) function helped replace the planning role
of the strip board while appropriate sorting in the lists (SIL, SEL etc.) could suitably replace
strips. On the other hand, for tracking aircraft in holding patterns, caution was urged in the
use of Hold Lists as a replacement for strips until sufficient experience was attained and
Hold List functionality was fully evaluated.
68
EEC Report No. 366
EUROCONTROL
In the simulation, the Shannon High-Level PLC did not perform many of the normal functions
related to oceanic separations, clearances, re-clearances and revisions. This important
aspect of operations will require further evaluation, particularly in terms of a stripless
environment. However, experience gained during the simulation indicated that these safety
issues could be handled more efficiently by the electronic stripless system.
Whereas, the move to a paperless system may not prove too difficult, the controllers reiterated their view that the electronic system must work well while providing user-friendly
input with correct default values.
9.1.12. Data list Windows
Generally, controller reaction to the various lists available was mixed. A slight majority felt
that the text in the lists was easy to read but could be improved if the text used was ‘normalunderlined’ rather than ‘bold’. The consensus was that selection of window size would be
enhanced if in each list (except for the Hold List), the Callsign field was the only mandatory
field. This field should be placed on the left, with all other fields optionally selectable. When
lists were closed and subsequently re-opened they should default to the controller’s
programmed preference.
In two-man suites the PLC tended to spend more time watching the lists rather than the
radar picture. Interaction with the lists proved more difficult as the level of traffic and
subsequent volume of list data increased. Although page lists occupy more screen space
than scroll lists, problems were often encountered with essential flight data being hidden as a
result 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)
Shannon High-Level controllers found the SILs particularly useful with SSR code allocation
for eastbound flows. Scrolling created some difficulties with regards 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 generally preferred to interact directly
with the radar label.
For Shannon controllers, reaction differed as to the need for the information displayed in the
SIL depending on whether the controller role was a planning or tactical one. Surprisingly,
executive controllers favoured the need for the SIL information more than planning
controllers. The reasons for this may be that the EXC often operated on a shorter range and
therefore did not always see the ‘Advance Warning’ aircraft. Secondly, many planning
controllers preferred to use the SEL rather than the SIL, as it provided more optional
information including oceanic clearance data.
9.1.14. Sector List (SEL)
The controllers re-iterated their preference for a single mandatory callsign field in the SEL
Shannon controllers used the SEL window more than their colleagues from Dublin, who once
again considered it useful but supplementary to their needs.
EEC Report No. 366
69
EUROCONTROL
Shannon controllers highlighted sorting and scrolling as the main problems encountered with
use of the Sector List. Controllers sometimes had difficulty in finding aircraft in the SEL. The
default 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 PEL
would be more suitable.
Despite this measure, problems would still exist. Controller opinion was mixed regarding
further sorting and scrolling methods. Sorting according to label-state provides advantages
and disadvantages particularly when scrolling is used. If, for example, ‘Assumed’ aircraft
were sorted to the top of the list, scrolling would hide some (or all) text lines of ‘Advance
Warning’ aircraft that might not be visible on the radar window and also could be the subject
of co-ordination proposals. A page list with no scrolling would be better but this has the
disadvantage that the SEL can then become extremely big and occupies a large area of the
radar 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 Lists
The 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-thirds
of the controllers stating that they always or regularly used it compared to one-third in the
case of the Arrival List. One should note however that use of the Arrival List was normally by
busy approach or TMA sectors where surveillance of and interaction with the radar label is
invariably more intensified. The controllers were reasonably pleased with the sorting
specifications for the Arrival and Departure Lists but recommended some improvements. In
the Arrival List an ‘Assumed’, Advance Warning’ and ‘Concerned’ label–state sort order
would be better while the Tower sequence for Departures should automatically update the
sequence in the Departure List.
9.1.16. Hold List
The Hold List was used extensively throughout the simulation by Dublin controllers.
Shannon controllers used the functionality less as only two of the five simulated
organisations 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 they
would like similar functionality in the CAIRDE 2000 system they recommended further
modifications in terms of both operational and sorting functionality.
Operational Functionality
The ability to put ‘Advance Warning’ aircraft in the Hold List would be useful for reserving
levels 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’ aircraft
display the PEL and not the CFL. The Hold pop-up menu should default to the holds
relevant to the sector. Ideally, when an aircraft was below the minimum hold level the list
should only display the AFL.
Sorting Functionality
The scrolling facility (when 15 lines were reached) was not safe in that use of a single list for
all holds (sorted by hold) often obscured vital data on aircraft in some holds. A separate
Hold List provided for each HPT and the removal of the scrolling facility would rectify this
problem. 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 aircraft
would sort by AFL.
70
EEC Report No. 366
9.2.
EUROCONTROL
OBJECTIVE 2
Controller Interface (HMI) Evaluation
Assess 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 very
noticeable and coupled with the audio alarm expected in the CAIRDE 2000 system, they
anticipate 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 their
attention quickly. However, when asked about the suitability of the data-block display the
response was far more critical. 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 the Callsign field was extremely difficult to read when the
label was in the ‘Concerned’ (Mustard) state. Overlapping labels caused further ambiguity
and frustration. Suppressed labels of aircraft in Hold Lists did not display any STCA
warnings.
The controllers put forward three major recommendations for STCA display characteristics.
These were:
•
•
•
9.2.3.
The Radar Position Symbol (RPS), Label lead line, Speed Vector and History Dots
should 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.
Dynamic Flight Leg (DFL)
The controllers use of the Dynamic Flight Leg during the simulation indicated that it was
potentially 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
was employed as the primary tool for providing route, sector sequence and conflict
information when the controllers were handling high traffic levels and reference to other tools
and lists became difficult.
The DFL received strong support from those controllers that used it. They considered it to
be a very powerful tool, particularly when used in conjunction with MTCD where it should be
selectable from the Conflict and Risk Display (CRD). The colours used were considered to
be quite good but some controllers felt that the thickness of the display lines should be
reduced. Controllers stressed that the DFL should be updated when the DCT function was
used.
EEC Report No. 366
71
EUROCONTROL
9.2.4.
Conflict and risk Display (CRD)
Overall, the controllers supported the use of the CRD, although with reservations. All but
one of the controllers found the tool ‘regularly or ‘sometimes’ useful. The Shannon
controllers stated that the MTCD feature would be very useful for planning support in HighLevel 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 conflict
predictions made. Comments indicated that there were many instances where too many
false risks were shown. As a result, in high workload situations frustration and confidence
were affected, and the CRD window was ignored.
On top of this, controllers identified some instances where the system failed to predict risk
and/or conflict situations. However, they agreed that with improvements in the accuracy of
the detection, task allocation and information display, the tool should achieve better
acceptance and may prove to be a powerful aid to assist controllers handle the increasing
traffic volumes forecast for the future.
On the positive side, the majority agreed that all of the appropriate information concerning
risks and conflicts was usually available in the MTCD tools. Some controllers felt that the
presentation of time and separation was not always easy to understand but training and
experience should overcome this. The majority felt that the CRD reduced their workload and
assisted them in better prioritising their tasks. They recommended that an ability to interact
with 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 while
responding to MTCD warnings. The tool provided early warnings on potential conflicts but
quite often the aircraft affected were outside the radar range selected. Planners had to learn
to adjust to variable selection of radar range to efficiently utilise the MTCD feature. This
sometimes caused confusion over the situational timeframe in which they were working.
They commented, however, that as a planning tool the MTCD enhanced conflict-handling
capability provided a suitable replacement for flight progress strips.
9.3.
OBJECTIVE 3
Controller Procedures
Evaluate the potential roles of Executive and Planning Controllers in the simulated
system
The controllers stated that the functionality of each control position should be identical to
enable the controllers themselves to create an appropriate task division and not have one
imposed by the system. This also allowed them to modify the task division when traffic
levels increased or decreased. They did feel that the PLC and EXC were able to work
together 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 allocation
between Planning Controller and Executive Controller was not always clear. This may have
been a result of allowing too much flexibility in the system configuration, or a result of the
short simulation period in gaining familiarity with the roles. While some versatility was
incorporated to allow for a distribution of workload, some actions (e.g. CFL input), although
considered the key responsibility of one controller, were often shared between the two sector
controllers. The impact of this indistinct task allocation was minimal although confusion over
individual responsibilities occasionally surfaced.
The case for such inter-operability was discussed during the debriefing sessions. The
controllers were divided on the procedure that should apply for 'CFL input' and 'Assume
72
EEC Report No. 366
EUROCONTROL
Input'. Some felt that only the Executive Controller should make these inputs. At issue was
the amount each input contributed towards maintaining the 'radar picture' and whether
sharing of these tasks meant a degradation of the Executive Controller's situational
awareness and control.
Further consideration is recommended before placing any restriction on the system
functionality. Any limitation may be implemented using controller procedures thereby
allowing flexibility while the implications are fully evaluated.
Finally, the controllers agreed that the implementation of the new ATM system technology
would result in a change of role assignments between the Executive and Planning controllers
and put forward the following recommendations.
Dublin ATCC
•
•
The EXC should continue to provide the radar service while the PLC would electronically
interface with and update the various windows and text lists that will eventually replace
the flight progress strip management functions currently in use.
Controller roles will require further review and critical assessment when the final
configuration 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 use
the SIL at times (e.g. first sector in an eastbound oceanic flow) and could interface with other
windows (e.g. Referred CRD) when required.
EEC Report No. 366
73
EUROCONTROL
9.4.
OBJECTIVE 4
Co-ordination
Assess the operational impact of System Supported Co-ordination (SYSCO)
In Phase I (limited SYSCO functionality) the planning controllers experienced severe
difficulty with co-ordination in that in proved extremely difficult to simultaneously update the
flight 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 traffic
levels.
When the full SYSCO functionality was provided (Phase II) the controllers stated that they
were well able to manage without flight progress strips. Dublin controllers opted not to use
SYSCO as the preferred to communicate by voice and/or intercom. They considered this
method to be more suitable in terms of speed and user-friendliness to their dynamic
approach and shared airspace environment. They noted however that inter-sector transfers
initiated in error could not be undone. This problem proved extremely frustrating and will
need to be addressed in the future system.
The Shannon controllers found SYSCO to be extremely useful and generally agreed that the
Message In/Out windows were important for understanding co-ordination information. The
vast majority stated that detailed information on inbound aircraft was always available in
reasonable time. While they considered that the presentation of co-ordination information in
the track labels was reasonably clear and unambiguous, they recommended that different
co-ordination colours should be used to differentiate between co-ordination in and coordination out. Our experience from previous simulations concurs with this. Indeed, this
recommendation was further highlighted by the fact that 88% of the controllers preferred to
co-ordinate via the data label rather than the Message In/Out windows.
Over 70% stated that the electronic transfer was preferable to the current system
methodology and that the transfer functions significantly reduced their workload compared
with normal working practises. On the other hand while 70% agreed that the capability to
hand-over a flight to the downstream sector and receive an acceptance reduced workload
compared with manual methods, they also stated that the capability to only accept or reject a
counter-proposal was a significant limitation. Indeed, in complex situations they felt it was
not 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 operational
shortcomings.
The display of a 'Default XFL' value for flights climbing from a High-level sector to a Super
sector 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 lower
than the highest level in the High-level sector (for descending traffic) was used this allowed
controllers to climb or descend aircraft to these levels without co-ordination and without
knowledge of other conflicting aircraft.
The controllers recommended that for co-ordination the ‘Default XFL’ should be the first level
of 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. Acceptance
of co-ordination should imply clearance to climb or descend. Subsequently, all climbs and
transfers should be immediate.
74
EEC Report No. 366
EUROCONTROL
Careful sector design will be required to avoid flights clipping small segments of adjacent
airspace and to allow standard DCT routes to be applied without generating sector sequence
anomalies. While large sectors with straight-line boundaries are preferable, sector design
must also accommodate traffic flows and sector capacity limitations, sometimes inhibiting
ideal design.
Although the provision of vertically split sectors in the IRL2000 simulation raised several
pertinent issues; the controllers strongly supported the use of system supported electronic
co-ordination. Comments from the controllers identified benefits such as greatly reduced
telephone communication, faster and more silent co-ordination, and a reduction in ATC task
load.
9.5.
OBJECTIVE 5
Airspace and Procedures
Investigate further the findings of the fast-time study regarding airspace changes to
both Shannon and Dublin. Specifically to assess the operational impact of the
following changes:
• Re-sectorisation of Shannon ATCC - Low Level.
9.5.1.
•
•
•
•
•
•
•
•
•
•
Shannon / Dublin Interface
Shannon controllers found that the delegated airspace was not sufficient and that increased
co-ordination was required to cope with transiting traffic, particularly when long term forecast
traffic levels were tested. Dublin agreed that increased co-ordination had been generated
but emphasised their view that co-ordination was not required as both centres could see the
traffic and a review of current Letters of Agreement and inter-centre co-ordination
procedures could easily resolve this problem.
Another aspect of the delegated airspace issue was the fact that Shannon felt that the
airspace was only required by Dublin when Rwy10 was active whereas they regularly
required it for climb and descent of traffic. They considered that the use of delegated
airspace (not necessarily confined to the dimensions simulated) should be flexible and not
specifically or permanently assigned to either centre.
EEC Report No. 366
75
EUROCONTROL
Dublin however, insists that the extension of their airspace to 0730°West (up to FL245) is
necessary 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 traffic
levels, as already at current traffic levels, the eastern holds of ROKNA and TULSO are
regularly 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’s
requirements was not resolved before the simulation. Therefore a compromise was reached
in 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 Lowlevel was not being simulated.
Further evaluation and discussion of the delegated airspace issue is recommended before
any final concrete decisions or conclusions can be drawn.
9.5.2.
Use of procedures for dealing with High Level traffic inbound to Belfast Airport
All the controllers agreed that the procedures for dealing with High-Level traffic outbound
from and inbound to Belfast Airport worked very well.
9.5.3.
Re-sectorisation of Shannon ATCC – Low Level
Shannon Low (LOW)
The handling of forecast medium-term traffic in the LOW sector during Organisation A
proved extremely difficult. Controllers felt that there was far too much traffic on the
frequency. Their ability to deal with the traffic volume was also impaired by the flight strip
printing and dissemination problems that existed throughout Phase I of the simulation. Their
consensus 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 SLO
and they opted to focus their attention on further simulation of this, without using flight
progress strips.
Shannon North Low (NLO) and Shannon South Low (SLO)
This configuration worked quite well although some controllers identified the possible need
for another low level sector to cope with future traffic levels anticipated for Cork and
Waterford. A better solution to this problem could be to re-assess the geographical
dimensions of the NLO/SLO sectors and in particular re-locate the interface boundary
between NLO and SLO further south. This, coupled with further evaluation of the
dimensions 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 NLO
and SLO to cope with situations when the TMA hold was full. They also recommended that
the control of arriving and departing traffic to/from Kerry should be the responsibility of the
TMA controllers.
In Organisations A (LOW) and B (NLO/SLO) the transfer of all offshore airspace west of
1030° West to Shannon High-level worked very well and the controllers recommended that
it should be implemented.
76
EEC Report No. 366
EUROCONTROL
Shannon TMA
All controllers confirmed the necessity for a TMA sector while recommending various
improvements in terms of design and operating procedures, as outlined below.
The geographical dimensions of the TMA should be re-assessed with defined Entry and Exit
Points structured to comply with current lower and upper ATC routes. The simulated design
did not allow much room to the east for manoeuvring aircraft. New ATC procedures will be
required for the interface between low-level and high-level sectors and the TMA. The design
of new SIDS/STARS will need to comply with TMA entry/exit points for traffic departing from
and arriving to Shannon and the regional airports. STARS should be used in preference to
radar vectoring as this could prove to be too complex. Radar co-ordination procedures will
also be required.
The controllers stated that the TMA should be manned by at least two controllers. The TMA
hold should control all aircraft from the level above the transition level (TL) up to FL140. The
TMA planning controller should assign levels to the low-level sectors (NLO/SLO) when they
become 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. Proper
maintenance of the electronic HMI made it impossible to simultaneously use flight progress
strips, even with medium-term traffic levels. The controllers recommended that the APP
controller should be responsible for aircraft holding at the TL in the simulated holds of
SCARF (Rwy24 Active) and FOY (Rwy06 Active).
9.5.4.
Use of holding patterns at new positions 15nm on the final approach to
Shannon
In Organisations A and B the Entry Fixes to the holding patterns (SCARF and FOY) were
initially positioned at 15nm on final approach to runways 24 and 06 respectively. The
controllers quickly found these locations to be unsuitable due to the amount of label clutter
generated on final approach. All the controllers agreed that the holds should be offset from
the final approach paths and discussions resulted in numerous suggestions for suitably repositioned sites. New locations were finally agreed siting SCARF at 5240°N 0820°W (south
of 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 the
availability 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 airports
The Shannon SIDS worked quite well. All controllers liked the fact that departure routes
were clear of arrival routes. The default levels applied proved suitable, removing
unnecessary co-ordination. During the simulation, the Rwy24 SID for departures to Dublin
(DUB2B) followed a left turn. When the NLO/SLO sectorisation was simulated controllers
felt that a right turn after departure would have been more suitable. The controllers
suggested that future SIDS/STARS should be designed with regards to the requirements of
the NLO/SLO and TMA sectors. In effect, SIDS terminating at TMA exit points and STARS
commencing at TMA entry points, would ensure that the sector sequence for departing and
arriving traffic was correctly addressed.
The regional airports SIDS/STARS generally worked very well. Controllers had no difficulty
with 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 the
relevant sector’s departure list. Arriving aircraft were descended to the TL (FL60) and
transferred to the Ireland Domestic Feed Sector, when clear of departing traffic. The
EEC Report No. 366
77
EUROCONTROL
controllers agreed that if the new system included on-line connections to the regional airports
and proper radar coverage was available, there should be no requirement for co-ordination
between Shannon and the regional airports.
They, therefore, recommended that
SIDS/STARS should be developed for all regional airports.
9.5.6.
Re-sectorisation of Shannon ATCC - High Level
The controllers found that the vertical sectors provided an excellent method of handling high
traffic loads on the same track and could prove essential when RVSM is introduced in
Europe. The use of the Super sectors was also considered very beneficial. The controllers
pointed out that in real operations the strategic selection of level splits between the vertical
sectors could prove advantageous.
Sector design, an area much evaluated for Shannon Low-level, proved to be the main
problem faced when simulating Shannon High-level. In this case however the problems
were related more to the HMI than the sector dimensions. At present, electronic systems
have great difficulty with vertical sectorisation plans in terms of trajectory prediction and
calculation of climb and descent profiles. This, in turn, can seriously effect sector sequence
computation, thereby creating erroneous electronic co-ordination messages.
These problems can be greatly reduced by careful sector design that reduces clipping of
sector segments and accommodates traffic flows. However, the sectorisation used in
Shannon High-level, which is dynamically and strategically modified to meet oceanic track
requirements will prove extremely difficult to replicate in the future system where the HMI
emphasis is based on label state, colour, sector sequence and SYSCO co-ordination.
9.5.7.
Re-sectorisation of Dublin ATCC
Dublin Departure (DEP)
Controller reaction to the introduction of the DEP sector was very positive. All agreed that it
significantly reduced the workload currently experienced by Area sector controllers, with
regards to the identification and handling of departing traffic. While co-ordination was
occasionally required with the Approach sectors to resolve conflicts, controllers disapproved
of the practice of routinely running departing jet aircraft to the markers (as opposed to
3000ft.) 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 and
HMI.
Final Approach (FIN)
Controllers reaction to the introduction of the FIN sector was also positive but they stressed
that new procedures and more experience would be required to optimise it’s impact. Before
the simulation, approach controllers had no previous experience in the application of 3nm
separation on final approach. They found it extremely difficult to apply this tight separation
successfully due to the limited dimensions of the airspace permitted for its use. The FIN
controller tended to take control of traffic further and further from final approach in order to
close gaps between aircraft departing from the holding stacks. Many controllers considered
that the application of 3nm separation on final approach from 15nm to touchdown was too
restrictive. Extensive training and experience will be required to perfect skills in the
application of 3nm separation involving strict use of speed control and new working
procedures. The controllers recommended a review of, and extension to, the airspace
permitted for application of 3nm separation.
78
EEC Report No. 366
9.5.8.
EUROCONTROL
A third area sector – Dublin West Area (ARW), manned by a single Executive Controller was
introduced to handle traffic from the north and west. The planning controllers were removed
from the ARN and ARS sectors leaving a configuration using one Executive Controller in
each simulated sector. The ARW sector took all traffic previously handled by ARN (except
for flights on the B1 and W911D), 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 both the APN and APS approach sectors. Controller first impressions were
that the ARW sector worked quite well, alleviating workload in the busier ARN and ARS
sectors. However, further examination of how to handle simultaneous northbound overflights
on the UP600 and UR14 will be required. The interface between ARW and all adjacent
sectors of Shannon and Dublin will also need further investigation.
9.5.9.
Re-positioning of the DINIL and NASRI holds and the Dublin CTA western
boundary
The western holds of DINIL and NASRI were simulated in their new positions in all
organisations simulated. The relocation of the Dublin CTA western boundary permitted the
use of these holds and their inherent buffer airspace requirements. Their location further
from the airport facilitated vectoring to all runways by giving approach controllers sufficient
space and time to integrate traffic from DINIL and NASRI with traffic from ROKNA and
TULSO. Their position also facilitated departure flows in that they reduced the area of
conflict between departing and holding traffic.
However, the extension of the Dublin CTA to 0730°W could seriously impact on Shannon
Low-level operations, particularly when traffic is being held above FL140 at DINIL and/or
NASRI.
9.5.10. Implementation of parallel runway operations at Dublin Airport
The controllers agreed that the introduction of the parallel runway had an extremely
beneficial effect in that it provided a runway free to readily cope with all departures and
allowed consistent use of 3nm separation to aircraft on approach to Rwy28L. However, new
procedures and working practices would be required before implementation. The controllers
believe that the absence of a parallel runway at Dublin could serious impact ATC operations
in terms of holding and delay to departures, when long-term forecast traffic becomes a
reality.
9.5.11. Use of 3nm separation between aircraft on final approach to Runway 10R
The 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 the
various technical difficulties encountered, necessitated the cancellation (with client
agreement) of Organisation F where simulation of Rwy10L and Rwy10R operations was
intended.
EEC Report No. 366
79
EUROCONTROL
9.5.12. Introduction of an Arrival Manager system (MAESTRO) at Dublin ATCC
The controllers were impressed by the system and put forward various recommendations as
to 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’s
airspace is similar to Dublin’s in that the main approach is very close to the adjacent Malmo
FIR boundary. Controllers there use the tool to successfully regulate and optimise the flow
of arriving traffic at the TMA entry points. All controllers recommended that IAA management
should send ATCO groups to Copenhagen to study their operating procedures. This would
greatly assist the preparation of operating procedures for Dublin.
They also highlighted the fact that the installation of the MAESTRO system at Dublin would
require the co-operation of both Manchester and London ATCC’s.
They felt that MAESTRO would prove valuable for creating gaps on approach to
accommodate departure flows in single runway operations.
The APN and APS approach controllers found that when the system was set to runway
mode it was difficult to quickly pick out their respective aircraft. Sector-linked colour coding
of the aircraft callsigns in the display would solve this problem.
All controllers felt that the MAESTRO system should include functions that provided
minimum and maximum holding times as well as hold stack to runway times. Set up for the
holds would require new letters of agreement with MATCC/LATCC. After the holds the
sequence should be determined by the approach sectors, using their vectoring skills to
optimise the flow of traffic to the runways.
Finally, with regards to the siting of the MAESTRO display, area and approach controller
opinion was unanimous. The display should be stand-alone on the CWP and not integrated
within the 2k x 2k radar screen.
80
EEC Report No. 366
Ireland 2000 Simulation en temps accéléré
EUROCONTROL
TRADUCTION EN LANGUE FRANÇAISE DU RESUME, DE L’INTRODUCTION, DES
OBJECTIFS, DES CONCLUSIONS ET RECOMMANDATIONS
RESUME
La simulation en temps réel IRL2000 s’est déroulée au Centre Expérimental
d’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 alliant
sécurité et efficacité économique, en accord avec les prévisions de croissance du trafic
aérien.
Conçu sur la base des technologies les plus récentes, le système CAIRDE 2000 vise à faire
bénéficier le contrôleur d’une assistance automatisée optimale (en termes de sécurité, de
fiabilité et de flexibilité) tout en essayant de maximiser l’efficacité et de réduire la marge
d’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 de
Dublin et 2 du Centre de formation de l’IAA) ont pris part à la simulation IRL2000. Ceux-ci
ont pu acquérir une expérience pratique du système CAIRDE 2000 pendant un total de 98
heures 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 nouvelles
fonctionnalités (et leur familiarisation avec ces dernières) se révélera extrêmement
bé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 de
l’interface homme machine (IHM) et le rôle que les contrôleurs exécutifs et de planification
pourraient respectivement jouer dans le cadre du nouveau système. Le scénario de
simulation visait à compléter la précédente simulation en temps accéléré de l’espace aérien
irlandais (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édures
d’exploitation propres aux centres de contrôle de la circulation aérienne de Shannon et de
Dublin.
Outre l’adoption d’un affichage radar à fenêtres multiples, avec saisie des données au
moyen d’une souris à trois boutons, l’interface contrôleur présentait les principales
caractéristiques suivantes : coordination automatisée électronique (SYSCO), détection des
conflits à moyen terme et filets de sauvegarde tels que dispositif d’alerte aux conflits à court
terme (STCA) et avertissement de proximité de zone protégée (APW). La simulation a
permis 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ème
automatisé (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 également
apporté des renseignements intéressants de nature à résoudre les problèmes que poseront
les plans de sectorisation verticale et la fonction d’affichage du statut des étiquettes, telle
que conçue et définie par le fabricant.
Rapport CEE No. 366
81
EUROCONTROL
En conclusion, cette simulation aura revêtu une importance capitale pour l’Irlande. L’IAA
envisageant la mise en place d’un nouveau système ATC dans le courant des prochaines
années, la participation active des contrôleurs à l’élaboration et à l’évaluation des
propositions 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 simulation
contribueront de façon substantielle à la définition des spécifications du nouveau système.
82
Rapport CEE No. 366
1.
EUROCONTROL
INTRODUCTION
La simulation en temps réel IRL2000 s’est déroulée au Centre Expérimental
d’EUROCONTROL du 6 au 31 mars 2000. Son objectif était de répondre aux besoins
spé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 de
ladite simulation. Il analyse également les résultats obtenus et présente les conclusions qui
en ont été tirées.
L’actuel système ATM irlandais (CAIRDE) a été mis en service en 1990. Bien qu’il soit
conforme aux spécifications EATCHIP, ce système repose sur des technologies datant des
années 1980 et n’est plus en mesure d’évoluer ni d’intégrer de nouvelles technologies
comme 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 lui
permettra d’offrir à ses clients, au cours de la première décennie du nouveau millénaire, des
services alliant sécurité et efficacité économique, en accord avec les prévisions de
croissance du trafic aérien.
Le but premier de la simulation était d’évaluer l’incidence opérationnelle de l’interface
homme machine (IHM) et le rôle que les contrôleurs exécutifs et de planification pourraient
respectivement jouer dans le cadre du nouveau système. Les objectifs secondaires avaient
trait à la configuration des secteurs et aux procédures d’exploitation propres aux centres de
contrô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ôle
océanique (OCA) de Shanwick.
La simulation s’est articulée en deux phases. La première consistait à évaluer un
environnement fondé sur l’utilisation de bandes de progression de vol et le recours à la
coordination par téléphone. La seconde portait sur l’évaluation d’un système plus
automatisé, n’utilisant pas de bandes de progression de vol et faisant intervenir un double
dispositif 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 en
place d’un nouveau système ATC dans le courant des prochaines années, la participation
active des contrôleurs à l’élaboration et à l’évaluation des propositions relatives au système
et à l’espace aérien est déterminante pour la réussite à long terme du projet CAIRDE 2000.
Rapport CEE No. 366
83
EUROCONTROL
2.
OBJECTIFS
La simulation porte sur une évaluation globale de haut niveau de l’IHM et des méthodes de
travail, à quoi s’ajoute une série d’objectifs secondaires propres aux activités des ATCC de
Shannon et de Dublin. Chacun des objectifs énumérés ci-dessous est accompagné d’un bref
commentaire 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 que
simulée avec utilisation de bandes de progression de vol. Le CEE fournira en outre un
dispositif destiné à simuler un système à automatisation plus poussée, grâce auquel le
client pourra prévisualiser certaines évolutions escomptées du système.
2.
Évaluer l’incidence opérationnelle des outils ATC, des filets de sauvegarde et des
aides à la surveillance du nouveau système.
Récolter des avis et des enregistrements de données ayant trait à la conception
ergonomique et technique des nouveaux outils ATC mis à disposition.
3.
Évaluer le rôle que les contrôleurs exécutifs et de planification pourraient
respectivement jouer dans le système simulé.
Recueillir les réactions des contrôleurs quant au mode de répartition des tâches
envisagé 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, à la
lumiè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 de
données, sur l’ergonomie et l’utilité opérationnelle de la SYSCO, aussi bien dans le cas
d’un système à fonctionnalités limitées avec bandes de progression de vol que dans
celui d’un dispositif enrichi fonctionnant sans bandes papier.
5. Approfondir l’examen des conclusions de l’étude en temps accéléré sur les
changements envisagés dans les espaces aériens de Shannon et de Dublin. Plus
spécifiquement, évaluer l’incidence opérationnelle des modifications suivantes :
a)
b)
c)
d)
e)
f)
g)
h)
i)
j)
k)
84
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 de
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.
Rapport CEE No. 366
3.
EUROCONTROL
CONCLUSIONS ET RECOMMANDATIONS
L’Administration de l’Aviation Civile Irlandaise a l’intention de mettre en œuvre un nouveau
systè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 nouveau
millénaire, des services alliant sécurité et efficacité économique, en accord avec les
prévisions de croissance du trafic aérien.
La simulation avait pour objectifs premiers d’évaluer l’incidence opérationnelle d’une
interface homme machine (IHM) ainsi que les rôles envisagés respectivement pour les
contrôleurs exécutifs et de planification. Les objectifs secondaires, quant à eux, portaient
essentiellement sur la configuration des secteurs et les procédures d’exploitation propres
aux 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ôle
océanique (OCA) de Shanwick.
La simulation a atteint avec succès les multiples objectifs définis au stade de la conception
du 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ôleurs
participants ont acquis une expérience précieuse de l’exercice du métier en environnement
IHM automatisé intégrant des dispositifs de sécurité évolués ainsi qu’en environnement sans
bandes de progression de vol. La motivation et le professionnalisme dont ils ont fait preuve
lors 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ésultats
de la simulation contribueront de façon substantielle à la définition des spécifications du
nouveau système.
On trouvera ci-après une synthèse des conclusions et recommandations pour chacun des
objectifs 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 que
proposé par l’IAA, procède d’un choix avisé : l’interface a été bien acceptée par les
contrô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 et
que 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ème
opérationnel a recueilli un large consensus. La plupart des contrôleurs se sont déclarés
favorables à l’intégration des différentes fenêtres d’affichage / de saisie dans un écran
unique, à l’exception de l’écran MAESTRO qui, sur la recommandation unanime des
contrôleurs de Dublin, devrait rester autonome et ne pas être incorporé dans la fenêtre
radar.
Constat significatif, 82 % des contrôleurs ont indiqué que l’utilisation combinée du tronçon de
vol dynamique (DFL), des informations sur les conflits, des étiquettes radar interactives et
des listes leur offrait un moyen satisfaisant de se passer des bandes de progression de vol
sur papier.
Rapport CEE No. 366
85
EUROCONTROL
3.1.1.
Souris à trois boutons
La souris a été jugée acceptable en tant qu'outil de saisie des données. Bien que les
contrôleurs se soient familiarisés rapidement avec les fonctions de la souris, une certaine
confusion est apparue au début du fait que ces fonctions ne correspondaient pas aux
explications fournies dans le manuel d’utilisation. Le bouton droit (Information Button) et le
bouton 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 ont
suggéré d’utiliser des textures superficielles différentes pour faciliter l’identification des
boutons.
La fiabilité de la souris joue un rôle primordial dans la confiance des contrôleurs. En cas de
défaillance, la souris doit pouvoir être remplacée rapidement et efficacement, avec un
minimum 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 tenir
compte des besoins particuliers des opérateurs, selon qu’ils sont gauchers ou droitiers.
3.1.2.
Fenêtres et menus contextuels
Si, dans leur grande majorité, les contrôleurs ont reconnu qu’un environnement à fenêtres
multiples constituait une innovation positive pour les futurs systèmes ATC, un tiers d’entre
eux ont cependant indiqué avoir éprouvé des difficultés à manipuler, déplacer et
redimensionner les fenêtres. Certains contrôleurs se sont demandé si l’écran radar était
réellement compatible avec le nombre et la taille des fenêtres jugés nécessaires. Il devrait
néanmoins être possible, moyennant une attribution prédéfinie des fenêtres utiles au
contrôleur exécutif (EXC) et au contrôleur de planification (PLC), d’optimiser les zones de
visualisation sur l’écran radar de chacun des postes de travail.
Les contrôleurs ont trouvé que les menus contextuels étaient d’un maniement aisé, compte
tenu 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 ont
dû se livrer à une manœuvre de défilement peu pratique pour sélectionner la valeur
souhaitée.
3.1.3.
Résultats concernant les étiquettes et les pistes
La majorité des contrôleurs (80 %) a jugé adéquat l’éventail des informations affichées dans
les é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 de
sé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ée
correspondant à un vol pris en charge (Assumed), à un avertissement anticipé (Advance
Warning) 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ème
ainsi 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 la
souris 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 Unconcerned
a permis de réduire considérablement les interactions inutiles avec ces étiquettes. La
plupart 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 du
texte de l’étiquette radar.
86
Rapport CEE No. 366
EUROCONTROL
Comme c’est le cas avec tous les systèmes de visualisation de ce genre, le chevauchement
des étiquettes radar a posé problème. Le dispositif de suppression automatique des conflits
entre é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 et
souple, et ont ensuite évalué les différentes méthodes possibles pour résoudre le problème
du chevauchement des étiquettes. La fonction de type « glisser-déposer » a été préférée au
système de positionnement prédéfini ; ce dernier permettait aux contrôleurs de
prédéterminer l’emplacement des étiquettes sur l’écran radar, mais la fonction « glisserdéposer » offrait davantage de souplesse au niveau de la gestion des étiquettes. Bien
qu'elle entraîne une charge de travail supplémentaire, les contrôleurs ont estimé que cette
méthode leur permettait de rafraîchir leur image mentale de la situation du trafic à mesure
qu'ils déplaçaient manuellement les étiquettes, et qu'elle ne générait pas une fatigue
excessive. De fait, une fonctionnalité permettant au contrôleur de sélectionner des positions
prédéfinies correspondant à des étiquettes individuelles ou à des groupes d’étiquettes (en
direction 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 avec
le symbole de position radar (RPS), notamment lorsque l’orientation de l’étiquette
correspondait à 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 surmonter
cet obstacle, les contrôleurs ont recommandé que le leader se rattache au premier champ
de l’étiquette. De plus, le leader devrait être assorti d’un code de couleur le distinguant du
vecteur de vitesse et du tronçon de vol dynamique.
3.1.4.
Couleurs
L’utilisation de couleurs pour les étiquettes (et les listes) a donné de très bons résultats, les
contrôleurs affirmant, dans leur grande majorité, que le recours à des codes de couleur pour
les é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 des
couleurs a été atténué pendant la simulation car, bien que jugé très bon pour les étiquettes
de piste, il est devenu quelque peu incommodant lorsqu’une grande quantité de texte
apparaissait dans les différentes listes affichées. Le blanc désignant un aéronef « pris en
charge » (Assumed Aircraft) a également été jugé trop brillant par les contrôleurs, qui ont
recommandé d’en estomper l’éclat.
L'IHM IRL2000 ménageait un recours systématique au changement de la couleur d'arrièreplan pour mettre les informations en évidence. Les nuances de couleur d'arrière-plan pour
faire ressortir toutes les données associées à un vol particulier ont été exploitées avec
succès. Par exemple, lorsque le pointeur de la souris s’arrêtait sur une étiquette radar, non
seulement la fenêtre d’étiquette étendue (ELW) était actualisée, avec toutes les informations
de vol utiles, mais les listes apparentées (SIL, SEL, DEP et ARR) s’affichaient également
avec un arrière-plan mis en évidence. Le changement de la couleur d’arrière-plan pour ce
type 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 ont
grandement apprécié l’efficacité de cette fonction.
Les contrôleurs des centres de Shannon et de Dublin ont émis des avis différents au sujet
des couleurs moutarde et grise, associées respectivement aux statuts d’étiquette Concerned
et Unconcerned. Ceux de Shannon ont jugé le jaune moutarde adéquat, mais ont estimé
que l’éclat du gris devait être atténué.
Rapport CEE No. 366
87
EUROCONTROL
Les contrôleurs de Dublin ont rencontré de sérieux problèmes avec le système d’indication
du statut des aéronefs et l’attribution de la couleur grise aux étiquettes Unconcerned. Dans
la réalité, la TMA de Dublin est gérée par plusieurs contrôleurs exploitant simultanément
différents postes de secteur. Les contrôleurs ont jugé que le système d’indication du statut
des aéronefs, tel qu’il était simulé, n’était pas particulièrement adapté à leurs conditions de
travail. En effet, bien que certains aéronefs puissent être considérés comme Unconcerned
par rapport au secteur dont ils ont la charge, il était néanmoins important que ces aéronefs
soient nettement visibles. Le gris ayant été jugé inadapté à cet effet, c’est le jaune moutarde
qui a été retenu pour toutes les étiquettes Concerned et Unconcerned dans la région de
contrôle de Dublin. Même s’il représente une amélioration, ce choix n’a pas été perçu
comme la solution idéale (voir section 5.3.1 traitant des résultats STCA). Les autres
améliorations proposées allaient du renforcement de la couleur jaune moutarde ou au choix
du blanc pour les champs Indicatif d’appel et Niveau de vol effectif (AFL). En résumé, la
méthode utilisée pour identifier et visualiser le trafic aérien Concerned et Unconcerned par
rapport à chaque secteur de Dublin considéré isolément, nécessite d’être étudiée plus avant.
3.1.5.
Champs
Les contrôleurs ont indiqué que la couleur utilisée pour mettre en évidence le champ Indicatif
d’appel (jaune) était un bon choix et qu’il convenait d’en faire aussi usage dans toutes les
listes 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 de
contrôleur d’un même secteur. Le blanc ne se substituait pas aux mises en surbrillance de
l’indicatif d’appel sur les étiquettes Advance Warning lorsque ces étiquettes passaient en
mode de transfert entrant, suite au transfert de contrôle par le secteur en amont. Cela
signifie que, dans la pratique, le secteur récepteur n’avait pas connaissance de la
proposition de transfert. Idéalement, un aéronef mis en surbrillance du fait de son statut
Advance Warning devrait passer en mode de transfert entrant (blanc) au moment du
transfert de contrôle et revenir en surbrillance une fois qu’il a été pris en charge. Les
contrôleurs ont également affirmé que la mise en surbrillance du champ d’indicatif d’appel
devrait 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 de
l’étiquette sélectionnée provoquait l’ouverture des menus-fenêtre contextuels
correspondants. Des valeurs par défaut avaient été définies pour les menus-fenêtre
contextuels, 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 valeur
souhaitée. Il en est résulté une certaine frustration, et un surcroît de travail pour les
contrôleurs. Le problème était encore exacerbé par le fait que certains contrôleurs ne
maîtrisaient pas totalement le principe des niveaux XFL par défaut entre secteurs, de sorte
qu’ils l’appliquaient incorrectement. De temps à autre, des XFL sans rapport avec le secteur
suivant étaient introduits, ce qui avait pour effet d’éliminer ledit secteur de la séquence. En
conséquence, l’aéronef était « radié » du secteur censé le recevoir. La « radiation », qui
signifie qu’un aéronef n’entrera plus dans l’espace aérien d’un secteur déterminé, fait
apparaître un indicatif d’appel de couleur verte sur l’étiquette radar du secteur où la radiation
a été opérée. Les contrôleurs accusaient réception de l’information en cliquant sur l’indicatif
d’appel, après quoi le statut de l’étiquette prenait la valeur Unconcerned.
Les principales observations formulées par les contrôleurs concernant les champs
d’étiquette et leurs fenêtres contextuelles peuvent se résumer comme suit :
88
Rapport CEE No. 366
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 ont
occasionné une certaine confusion, notamment en ce qui concerne les départs de
Shannon.
• Il conviendrait d’ajouter une fonction Assume / Hold au menu de l’indicatif d’appel, afin
de permettre aux contrôleurs TMA et d’approche de placer des aéronefs directement
dans la liste des attentes.
• L’affichage du nombre de Mach dans l’étiquette sélectionnée est superflu.
Dublin
La fonction Assume / Hold du menu de l’indicatif d’appel (évoquée ci-dessus dans les
observations 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 / Hold
pourrait avoir comme conséquence que des aéronefs soient renvoyés par mégarde sur la
liste des attentes. La question de savoir si les options Assume et Assume / Hold devaient
apparaître l’une à la suite de l’autre ou séparément dans la fenêtre contextuelle n’a pas
dé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ès
fréquentée de Dublin. D’autres études et évaluations portant sur les exigences minimales
applicables 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 depuis
leur 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 de
transfert d’un secteur à l’autre permettrait aux contrôleurs de récupérer (Undo Transfer) un
aé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é bon
nombre de problèmes aux contrôleurs. Dans la CTA de Dublin, où les contrôleurs
régionaux, d’approche et des départs se partagent l’utilisation du même espace aérien, les
restrictions inhérentes au système ont pu être surmontées facilement. En revanche, la
configuration 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 principale
difficulté rencontrée était de savoir quel XFL il convenait d’assigner à un aéronef dont le
niveau de vol demandé (RFL) impliquait le passage d’un secteur donné à celui situé juste
au-dessus. Le recours au RFL permettait au secteur inférieur de faire monter l’aéronef vers
le secteur situé au-dessus sans la moindre coordination, tandis que l’emploi du niveau
d’entrée planifié (PEL) du secteur inférieur entraînait le non-affichage de l’étiquette Advance
Warning 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 ne
souhaitait pas pour autant que le secteur inférieur puisse faire monter l’aéronef sans
coordination. 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.
Rapport CEE No. 366
89
EUROCONTROL
Cette formule exige toutefois une coordination à un stade ultérieur pour chaque aéronef et a
une incidence sur la charge de travail des contrôleurs.
D’autres évaluations seront nécessaires en ce qui concerne l’autorisation de faire monter les
vols au XFL approuvé, moyennant une coordination par téléphone afin de prévenir les
conflits 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 des
aéronefs.
3.1.7.
Autorisations océaniques
Les contrôleurs de l’espace aérien supérieur de Shannon recevaient les messages
d’autorisation océanique (OCM) via la fenêtre d’étiquette étendue (ELW) et la liste des
secteurs (SEL). Si la majorité (75 %) d’entre eux a fait observer qu’il n’était pas évident de
savoir à 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 diminution
de la charge de travail. Il n’empêche toutefois qu’ils préféraient accéder aux informations
relatives aux autorisations océaniques via la SEL.
3.1.8.
VFR en route
Le système simulé utilisait des paramètres de séquence sectorielle prédéfinis pour les ATCC
de Shannon et de Dublin. Il en est résulté un problème pour les vols VFR dans l’espace
aérien inférieur de Shannon, où l’exercice du contrôleur nécessitait un système plus
polyvalent et plus dynamique, excluant la définition d’un plan de vol et d’une séquence de
secteurs 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érien
inférieur avait la possibilité de sélectionner le secteur suivant et d’envoyer des informations
anticipées (via la fonction Force ACT), si nécessaire. Cela avait pour effet de modifier
l’é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éacheminements
Les 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é cette
fonctionnalité, en particulier dans les secteurs étendus des couches supérieures. Ils l’ont
qualifiée de très utile et ont formulé les observations et recommandations suivantes à son
égard.
•
•
•
•
•
90
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êmement
difficile.
Lors de la délimitation des secteurs, il convient d’accorder une attention et un soin tout
particuliers aux courants de trafic et d’éviter au maximum les tronçons courts au sein
d’un secteur.
Des problèmes sont survenus lors de l’utilisation du vecteur élastique, les contrôleurs de
planification de l’espace aérien supérieur devant fréquemment sélectionner une très
longue distance pour visualiser le point de destination souhaité.
Le point de destination choisi au moyen de la fonction DCT devrait apparaître dans le
champ AHDG. À l’issue d’un transfert de contrôle au secteur en aval, le point de
destination devrait apparaître dans le champ AHDG dudit secteur.
Rapport CEE No. 366
EUROCONTROL
Le vecteur élastique permettait aux contrôleurs de réacheminer un aéronef directement vers
n’importe quel point figurant sur l’itinéraire de vol planifié. Si le point de destination
sélectionné ne figurait pas sur le plan de vol initial, c’est le système qui se chargeait de
l’introduire dans le champ Assigned Heading (AHDG). Dans le futur système, lorsqu’on
utilisera la fonction DCT, la coordination n’interviendra que lorsque le nouveau point
sé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 ne
fera pas l’objet d’une coordination. La trajectoire sera néanmoins actualisée et une nouvelle
séquence de secteurs sera établie. Dans ce cas, le secteur suivant initial est radié et le
nouveau secteur reçoit un ACT avec préavis court (en principe, après une coordination par
téléphone). La « radiation », qui signifie qu’un aéronef n’entrera plus dans l’espace aérien
d’un secteur déterminé, fait apparaître un indicatif d’appel de couleur verte sur l’étiquette
radar du secteur où la radiation a été opérée. Les contrôleurs accusent réception de
l’information en cliquant sur l’indicatif d’appel, après quoi le statut de l’étiquette prend la
valeur Unconcerned.
Les contrôleurs ont affirmé que la fonction de radiation était très utile et l’indicatif d’appel de
couleur verte bien perceptible. Sur le système fourni à l’IAA, une radiation déclenchera
l’apparition d’un message dans la fenêtre Message In. De l’avis général, le changement de
couleur de l’indicatif d’appel est à la fois préférable et suffisant, toute information
supplémentaire étant superflue ; la radiation devrait, quant à elle, s’imposer au travers de
tous 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ès
concertation avec l’EXC. L’étiquette radar dans le secteur concerné devrait conserver le
statut Concerned jusqu’à ce que l’aéronef ait quitté ledit secteur. Idéalement, la procédure
de coordination entre les secteurs ne devrait pas être « gelée ». En outre, nonobstant
l’affichage d’un message de confirmation (Confirm skip), les contrôleurs ont jugé nécessaire
de disposer d’une fonction Unskip.
3.1.11. Bandes de progression de vol
Le 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 ATM
CAIRDE 2000 simulé s’inspirait, pour l’essentiel, des spécifications du manuel relatif au
système automatisé EATCHIP III. Il s’agit d’un système entièrement automatisé, conçu pour
fonctionner sans bandes de progression de vol. Pour le CEE, qui s’appuyait sur une solide
expérience en la matière, l’évaluation correcte de l’IHM d’un tel système commandait
d’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 fiable
dans les délais prévus. Le dispositif commandé à Airsys ATM intégrera l’ensemble des
fonctions associées aux bandes de progression de vol. L’évolution du système sera plus
progressive que révolutionnaire, afin d’éviter le passage brutal à un environnement sans
bandes, ce qui pourrait occasionner de sérieux problèmes. L’utilisation de bandes de
progression 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 deux
phases.
Rapport CEE No. 366
91
EUROCONTROL
La phase I a simulé la totalité des fonctions liées aux bandes de progression de vol, mais
non 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 coordination
In/Out.
La phase II a simulé la détection des conflits à moyen terme (MTCD) et l’affichage des
risques 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 dans
l’étiquette radar, la fenêtre ELW et les listes de données. Aucune bande de progression de
vol n’a été utilisée.
Les contrôleurs se sont dits préoccupés par l’ergonomie du CWP (y compris pour ce qui est
des bandes de progression de vol) dans le nouveau système. Les postes de travail actuels
se composent d’un simple écran radar pour le contrôleur exécutif et d’un tableau de
présentation des bandes de progression de vol pour le contrôleur de planification. Au CCR
de Dublin, ces tableaux sont conçus de manière à représenter géographiquement la région
de 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 de
présentation et le tapis de souris ne va pas sans poser des problèmes. Et à ces difficultés
s’ajouteront celles inhérentes aux claviers. Dans l’espace aérien supérieur de Shannon, le
volume du trafic rend à lui seul impossible toute sectorisation du tableau porte-strips. Les
contrôleurs ont estimé qu’il leur était impossible d’assurer à la fois la mise à jour des bandes
de progression de vol et la gestion du système électronique. Dans ces conditions, la
préférence est allée au système électronique, jugé plus facile à gérer. Les contrôleurs ont
trouvé que l’abandon des bandes de progression de vol améliorait considérablement le
travail d’équipe entre l’EXC et le PLC au sein de chaque poste de travail. De fait, durant la
phase 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 recourir
aux bandes de progression de vol. En résumé, l’utilisation des bandes de progression de
vol 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, avec
l’impression des bandes, des erreurs dans le contenu de ces dernières et des cas de double
emploi, les contrôleurs n’ont pas ménagé leur peine pour faire fonctionner le système
simulé. Leurs efforts pour gérer les deux systèmes (électronique et avec bandes de
progression de vol) tout en prenant en charge, dans de bonnes conditions de sécurité, les
importants 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 charge
plus de 10 aéronefs dans un environnement mixte, avec et sans bandes de progression de
vol. Il s’est avéré impossible d’utiliser simultanément les étiquettes radar, les listes et les
bandes. Pendant la simulation, le PLC devait placer les bandes sur les porte-strips et les
tableaux de progression de vol. Cette opération prenait un temps considérable, au détriment
de l’interaction du contrôleur avec le système. En fait, pour pouvoir actualiser les bandes, le
PLC 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 tri
adéquat opéré dans les listes (SIL, SEL, etc.) permettait de remplacer avantageusement les
bandes. Par ailleurs, en ce qui concerne le suivi des aéronefs dans les circuits d’attente, la
prudence a été recommandée quant à l’utilisation de listes d’attente en remplacement des
bandes 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.
92
Rapport CEE No. 366
EUROCONTROL
Dans le cadre de la simulation, le PLC responsable de l’espace aérien supérieur de
Shannon n’a pas exécuté bon nombre des fonctions normales en rapport avec les
séparations, autorisations, modifications d’autorisation et révisions océaniques. Ce volet
important des activités de contrôle devra être évalué plus avant, en particulier dans la
perspective 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 être
ré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 qui
suppose 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ées
D’une manière générale, les différentes listes proposées ont suscité des réactions en sens
divers 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 des
fenêtres serait meilleur encore si, dans chaque liste (excepté la liste des attentes), l’indicatif
d’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 ensuite
réouvertes, leur présentation par défaut devrait refléter les préférences définies par chaque
contrôleur.
Dans le cas des postes de travail biplaces, le PLC regardait généralement davantage les
listes que l’image radar. L’interaction avec les listes s’est révélée plus difficile à mesure que
le volume de trafic et la quantité de données de listage s’y rapportant augmentaient. Bien
que 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 certaines
donné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’appel
obligatoire et unique (dans la SIL), complété par des options à sélectionner et un système de
classement par ordre de priorité fondé sur le statut des étiquettes d’aéronefs. Les
contrôleurs de l’espace aérien supérieur de Shannon ont jugé les SIL particulièrement utiles
en combinaison avec l’allocation de codes SSR pour les courants de trafic en direction de
l’est. Le défilement a engendré certaines difficultés au niveau de l’affichage des
informations pertinentes. Les contrôleurs de Dublin n’ont guère utilisé les SIL. Ils y ont vu
une fonction utile, certes, mais non indispensable, et ont généralement préféré interagir
directement avec l’étiquette radar.
Quant aux contrôleurs de Shannon, leur réaction au sujet de la pertinence des informations
contenues 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 SIL
que les contrôleurs de planification. L’une des explications possibles est que les EXC
travaillaient souvent à courte distance et ne voyaient dès lors pas toujours les aéronefs
ayant le statut Advance Warning. Par ailleurs, nombre de contrôleurs de planification
préféraient utiliser la SEL plutôt que la SIL, car la première fournissait davantage
d’informations à caractère optionnel, parmi lesquelles les données relatives aux
autorisations océaniques.
Rapport CEE No. 366
93
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 et
unique dans la SEL, complété par des options à sélectionner et un système de classement
par ordre de priorité fondé sur le statut des étiquettes d’aéronefs. Les contrôleurs de
Shannon ont davantage utilisé la fenêtre SEL que leurs collègues de Dublin, qui, cette fois-ci
encore, 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 la
SEL. 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 plus
opportune.
Mais une telle mesure corrective n’empêchera pas certains problèmes de subsister. Les
avis des contrôleurs étaient mitigés quant à la mise au point d’autres méthodes de tri et de
défilement. Un tri effectué sur la base du statut des étiquettes comporte des avantages et
des inconvénients, en particulier lorsque la fonction de défilement est utilisée. Si , par
exemple, les aéronefs « pris en charge » (Assumed) étaient classés en tête de liste, le
défilement ferait disparaître certaines des (ou toutes les) lignes de texte correspondant aux
aéronefs ayant le statut Advance Warning, lesquels pourraient ne pas être visibles sur
l’écran radar et faire également l’objet de propositions de coordination. Une liste sous forme
de page, sans possibilité de défilement, serait une meilleure solution, mais aurait pour
inconvénient que la SEL risquerait alors de devenir extrêmement longue et occuperait une
portion importante de la fenêtre radar. Par ailleurs, les contrôleurs n’ont pas besoin de
visualiser 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éparts
Les contrôleurs étaient partagés quant à l’utilité des listes des arrivées et départs. La liste
des départs a été plus largement acceptée et jugée nettement plus utile, deux tiers des
contrôleurs affirmant qu’ils l’utilisaient systématiquement ou régulièrement, contre un tiers
seulement dans le cas de la liste des arrivées. Il convient cependant de noter que la liste
des arrivées n’était généralement utilisée que par les secteurs d’approche ou de TMA très
fréquentés, où la surveillance des étiquettes radar et l’interaction avec celles-ci sont, par
nécessité, plus marquées. Bien que relativement satisfaits des spécifications de tri
appliqué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 des
statuts d’étiquette Assumed, Advance Warning et Concerned serait plus indiqué, tandis que
la séquence des départs de la tour de contrôle devrait actualiser automatiquement la
séquence des vols dans la liste des départs.
3.1.16. Liste des attentes
La liste des attentes a été abondamment utilisée tout au long de la simulation par les
contrôleurs de Dublin. Les contrôleurs de Shannon en ont fait un usage moindre, étant
donné que seules deux des cinq organisations simulées englobaient l’espace aérien
inférieur. La liste des attentes a donné toute satisfaction. Les contrôleurs l’ont trouvée à la
fois 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.
94
Rapport CEE No. 366
EUROCONTROL
Fonctions d’exploitation
La possibilité de placer un aéronef de statut Advance Warning sur la liste des attentes serait
utile 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 et
non le CFL. Le menu contextuel de la liste des attentes devrait faire apparaître par défaut
les attentes se rapportant au secteur concerné. Idéalement, lorsqu’un aéronef évolue en
dessous du seuil d’attente, la liste ne devrait afficher que l’AFL.
Fonctions de tri
La fonction de défilement (disponible au-delà de 15 lignes) n’était pas sûre, en ce sens
qu’une liste unique de tous les aéronefs en attente (classés par circuit d’attente) masquait
souvent des données vitales concernant des aéronefs maintenus en attente. Une liste des
attentes distincte pour chaque HPT et la suppression de la fonction de défilement
permettraient 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 plusieurs
aéronefs auraient le même CFL, le tri secondaire ferait en sorte que les aéronefs soient
classé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 des
aides à 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 le
texte se remarque très bien et le couplage de l'affichage avec l'alarme sonore prévue sur le
système CAIRDE 2000 devrait, de l'avis général, déboucher sur un dispositif de sécurité des
plus utiles.
3.2.2.
Avertissement de conflit à court terme (STCA)
Les contrôleurs ont, dans leur grande majorité, estimé que l'activation du STCA avait
rapidement attiré leur attention. En revanche, ils se sont montrés beaucoup plus critiques
quant au mode de visualisation des blocs de données. Pas un ne semble avoir apprécié le
style d'affichage du STCA. Le bord rouge du bloc d'étiquette a été jugé dérangeant et
inutile. La mise en évidence sur fond rouge du champ d'indicatif d'appel rendait la lecture
difficile lorsque l'étiquette affichait le statut Concerned (jaune moutarde). La superposition
des étiquettes était une source supplémentaire d'ambiguïtés et d'irritation. Les étiquettes
supprimées d'aéronefs figurant sur les listes des attentes n'affichaient aucun avertissement
STCA.
Les contrôleurs ont formulé trois recommandations importantes en ce qui concerne les
caractéristiques d'affichage du STCA :
•
•
•
le symbole de position radar (RPS), le leader, le vecteur de vitesse et les points de
position 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.
Rapport CEE No. 366
95
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ère
constitue potentiellement un élément hautement utile du progiciel IHM. Peu utilisée dans la
TMA de Dublin, cette fonction a, en revanche, été largement exploitée dans l'espace aérien
plus étendu de l'ATCC de Shannon. Confrontés à des niveaux de trafic élevés, les
contrôleurs se servaient de la fonction DFL en tant qu'outil primaire pour obtenir des
données sur les routes, la séquence des secteurs et les conflits lorsqu'ils étaient occupés et
que 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 eu
recours. Ces derniers ont estimé qu'il s'agissait d'un outil très puissant, en particulier
lorsque ladite fonction était exploitée en association avec la MTCD, auquel cas il devrait
alors ê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 les
lignes d'affichage gagneraient à être plus fines. Les contrôleurs ont fait valoir que le DFL
devrait ê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ès
utile à l'appui de la planification dans les secteurs supérieurs. Elle pourrait également se
révéler utile dans les secteurs inférieurs mais serait inutilisable en TMA. Il importe, pour la
crédibilité de l'outil, que les contrôleurs aient confiance dans les prévisions de conflits. Or de
multiples 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ôleurs
qui, 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 de
prédire des situations de risque et/ou de conflit. Les intéressés sont néanmoins convenus
que, moyennant une série d'améliorations au niveau de la précision de détection, de
l'attribution des tâches et de l'affichage des données, l'outil devrait être mieux accepté et se
révéler d'une grande utilité pour aider les contrôleurs à faire face à l'augmentation prévue
des volumes de trafic.
Pour ce qui est des aspects positifs, la majorité des contrôleurs ont reconnu que les
informations utiles concernant les risques et conflits étaient généralement données par les
outils MTCD. D'aucuns ont estimé que la représentation du temps et de la séparation n'était
pas 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 de
travail et leur avait permis de mieux sérier leurs tâches. Afin de réduire encore cette charge
de travail, ils recommandent que la possibilité leur soit offerte d'interagir avec les étiquettes
via le CRD.
Les contrôleurs (en particulier les PLC) ont dû s'adapter rapidement à de nouvelles
procédures d'exploitation tout en réagissant aux avertissements MTCD. L'outil générait des
pré-alertes de conflits potentiels mais bien souvent, les aéronefs concernés se situaient audelà 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 en
est résulté, par moments, une certaine confusion au niveau du contexte temporel dans
lequel ces contrôleurs opéraient. Les intéressés ont néanmoins fait valoir qu'en tant qu'outil
de planification, la MTCD améliorait la capacité de traitement des conflits et pourrait
utilement remplacer les bandes de progression de vol.
96
Rapport CEE No. 366
3.3.
EUROCONTROL
Objectif 3
Procédures de contrôle
Évaluer le rôle que les contrôleurs exécutifs et de planification pourraient
respectivement jouer dans le système simulé
Les contrôleurs ont estimé que les fonctionnalités devraient être identiques sur chacun des
postes de contrôle de sorte qu'ils puissent organiser eux-mêmes la répartition des tâches au
lieu de devoir se conformer à celle que leur impose le système. Une telle approche leur
permettrait également de modifier cette répartition des tâches en fonction de l'importance du
trafic. Les participants ont indiqué que les deux contrôleurs (PLC et EXC) étaient en mesure
de fonctionner en tandem et que les rôles, tels que définis, permettaient un tel travail
d'équipe.
Bien que les rôles respectifs du PLC et l'EXC aient été raisonnablement bien définis, la
répartition des tâches entre les deux acteurs n'était pas toujours très claire. On peut y voir le
résultat d'une trop grande souplesse au niveau de la configuration du système ou du peu de
temps 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 la
responsabilité essentielle de l'un des deux contrôleurs, étaient fréquemment partagées entre
les deux responsables de secteur. Sans conséquences graves, cette répartition indistincte
des tâches a toutefois engendré, par moments, une certaine confusion sur le plan des
responsabilité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. La
question était de savoir dans quelle mesure chaque nouvelle saisie contribuait au maintien
de l'image radar et si le partage de ces tâches n'était pas de nature à nuire à la perception
que 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 restriction
au niveau des fonctionnalités du système. Des limitations peuvent être instaurées par la
voie de procédures de contrôle de façon à ménager une certaine souplesse dans l'attente
d'une évaluation complète des incidences.
Enfin, les contrôleurs s'étant accordés à reconnaître que la mise en œuvre du nouveau
système ATM se traduirait par une nouvelle répartition des tâches entre le contrôleur
exé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 le
contrôleur de planification gérera et actualisera les différentes fenêtres et listes de texte
qui remplaceront, à terme, les fonctions actuelles de gestion des bandes de progression
de 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.
Rapport CEE No. 366
97
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 les
fenêtres et listes (SEL, SIL, CRD, messages In/Out, ARR, DEP et attentes). L'EXC pourrait
toutefois utiliser lui aussi ponctuellement la SIL (par ex. premier secteur d'un courant
océanique à direction de l'est) et interfacer si nécessaire avec d'autres fenêtres (Referred
CRD).
3.4.
Objectif 4
Coordination
É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é de
sérieuses difficultés à assurer la coordination en ce sens qu'il s'est révélé extrêmement ardu
d'actualiser les bandes de progression de vol et le système électronique tout en prenant en
charge les nombreux échanges téléphoniques. La difficulté s'est accrue lorsque l'on a
injecté 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és
largement en mesure de se passer des bandes de progression de vol. Les contrôleurs de
Dublin ont choisi de délaisser la coordination automatisée au profit de la communication
verbale et/ou par interphone. Selon eux, cette dernière méthode convenait davantage, par
sa rapidité et sa convivialité, à leur approche dynamique et à leur environnement d'espace
aérien partagé. Ils ont cependant noté que les transferts intersecteurs déclenchés par erreur
ne pouvaient plus être annulés. Cette lacune s'est révélée particulièrement irritante, aussi
sera-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 les
fenêtres des messages In/Out étaient importantes pour comprendre les données de
coordination. La grande majorité d'entre eux ont indiqué que les informations détaillées sur
les vols à l'arrivée étaient toujours disponibles dans un délai raisonnable. Bien que la
présentation des données de coordination sur les étiquettes de piste leur ait paru
relativement claire et sans équivoque, les participants ont cependant recommandé d'utiliser
des couleurs différentes pour distinguer les opérations de coordination à l'entrée et à la
sortie. Outre qu'elle rejoint les conclusions de précédentes simulations, cette
recommandation est corroborée par le fait que 88% des contrôleurs préféraient coordonner
98
Rapport CEE No. 366
EUROCONTROL
les opérations de contrôle au moyen des étiquettes de données plutôt qu'à l'aide des
fenêtres de messages In/Out.
Plus de 70 % des intéressés ont indiqué que le transfert électronique était préférable aux
méthodes actuelles et que les fonctions y étant associées réduisaient considérablement leur
charge de travail par rapport aux pratiques en usage. Par ailleurs, si 70 % des participants
ont concédé que la possibilité de transférer un vol au secteur aval, et d'en recevoir
l'acceptation, allégeait leur charge de travail par rapport aux méthodes manuelles, ils ont
aussi estimé que le fait de ne pouvoir qu'accepter ou rejeter une contre-proposition
constituait une sévère restriction d'emploi. À telle enseigne que ces mêmes contrôleurs se
sont déclarés dans l'impossibilité d'assurer efficacement une coordination électronique en
situation complexe.
La coordination avec les secteurs adjacents s'est révélée efficace et n'a engendré que peu
de problèmes. Dans le cas de secteurs scindés dans le plan vertical, plusieurs carences
d'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 passent
d'un secteur supérieur à un super secteur ou qui descendent d'un super secteur pour
pénétrer dans un secteur supérieur a été longuement débattue. Le fait d'utiliser une valeur
XFL 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 sans
coordination, 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 la
coordination, correspondre au premier niveau du secteur récepteur (ce qui aurait pour effet
d'activer le statut d'étiquette Advance Warning pour ce secteur). Une coordination
téléphonique devrait s'ensuivre pour confirmer l'acceptation.
L'acceptation de la
coordination devrait sous-entendre l'autorisation de montée ou de descente. Les montées et
transferts devraient ensuite avoir lieu immédiatement.
Un soin tout particulier devra être apporté à la sectorisation, afin d'éviter que des vols
n'empruntent de petits segments des espaces aériens adjacents et de permettre l'utilisation
de routes directes standard sans générer d'anomalies dans la séquence des secteurs. Bien
qu'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, de
sorte 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ôleurs
participant à la simulation IRL2000 se sont dits très favorables à l'utilisation de la
coordination électronique. Au nombre des avantages cités par les participants figurent la
réduction sensible des échanges téléphoniques, le caractère à la fois plus expéditif et plus
silencieux de la coordination et l'allègement de la charge de travail ATC.
Rapport CEE No. 366
99
EUROCONTROL
3.5.
Objectif 5
Espace aérien et procédures
Approfondir l’examen des conclusions de l’étude en temps accéléré sur les
changements envisagés dans les espaces aériens de Shannon et de Dublin. Plus
spé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 / Dublin
Les contrôleurs de Shannon ont considéré que l'espace aérien délégué était trop exigu et
que la gestion des vols en transit avait engendré un surcroît de travail de coordination, en
particulier lors de la simulation des niveaux de trafic prévus à long terme. Tout en
reconnaissant qu'une coordination plus intensive avait été requise, les contrôleurs de Dublin
ont fait valoir qu'une telle coordination était en fait superflue puisque les deux centres
pouvaient visualiser le trafic et qu'en tout état de cause, une simple révision des Lettres
d'accord et procédures de coordination intercentres actuellement en vigueur permettrait de
remédier facilement au problème.
S'agissant encore de la problématique de l'espace aérien délégué, les contrôleurs de
Shannon ont noté que Dublin n'utilisait ledit espace que lorsque la piste 10 était en service
alors qu'eux-mêmes en avaient régulièrement besoin pour faire monter ou descendre des
vols. Selon eux, l'utilisation de l'espace aérien délégué (tel que délimité pour les besoins de
la simulation ou non) devrait se faire avec souplesse, sans attribution spécifique ou
permanente à l'un ou l'autre des deux centres.
Dublin souligne, pour sa part, que l'extension de son espace aérien jusqu'à 0730°W (et
jusqu'au FL 245) est nécessaire afin d'englober les zones tampons des nouveaux points
d'attente ouest DINIL et NASRI. La possibilité d'utiliser ces points jusqu'au FL 240 est jugée
indispensable pour pouvoir face aux niveaux de trafic escomptés à long terme, vu que dans
les conditions de trafic actuelles, les points d'attente ROKNA et TULSO, situés à l'est, sont
déjà exploités régulièrement (après coordination avec le LATCC) au-delà de leurs limites
publiées.
Pour rappel, la question de savoir comment satisfaire les exigences respectives de Shannon
et 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
100
Rapport CEE No. 366
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 pas
simulé.
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 des
conclusions définitives sur le sujet.
3.5.2.
Utilisation de procédures de prise en charge du trafic en altitude à destination
de l’aéroport de Belfast
Les contrôleurs se sont accordés à reconnaître que les procédures de prise en charge du
trafic en altitude en provenance ou à destination de l'aéroport de Belfast fonctionnaient très
bien.
3.5.3.
Nouvelle sectorisation de l’espace aérien inférieur de l’ATCC de Shannon
Espace aérien inférieur de Shannon (LOW)
La prise en charge, dans le cadre de l'organisation A, des niveaux de trafic prévus à moyen
terme 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 au
volume de trafic était également entravée par les problèmes d'impression et de diffusion des
bandes de progression de vol qui ont marqué toute la Phase I de la simulation. Dans ces
circonstances, ils ont jugé inutile de simuler le secteur LOW sur la base des prévisions de
trafic à long terme. La situation appelant clairement, selon eux, une configuration à deux
secteurs (NLO et SLO), ils ont choisi de se concentrer sur la simulation d'une telle
organisation, 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 trafic
escomptés pour Cork et Waterford. Il pourrait être préférable de revoir les dimensions
géographiques des secteurs NLO/SLO et, surtout, de déplacer davantage vers le sud la
limite d'interface entre ces deux secteurs. Associée à une réévaluation des dimensions du
secteur 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 TMA
serait 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'espace
aérien océanique à l'ouest de la longitude 1030°W au secteur supérieur de Shannon a très
bien fonctionné, et les contrôleurs ont recommandé que cette procédure soit mise en
pratique.
TMA de Shannon
Les contrôleurs ont, sans exception, confirmé la nécessité d'un secteur TMA, tout en
recommandant diverses améliorations en termes de conception et de procédures
opérationnelles.
Ainsi, le tracé de la TMA devrait être revu, avec des points d'entrée et de sortie spécifiques
correspondant aux routes ATC actuelles dans l'espace inférieur et supérieur. La zone
simulée n'offrait guère d'espace de manœuvre dans sa partie est. De nouvelles procédures
ATC sont à définir pour l'interface entre les secteurs inférieur et supérieur et la TMA. Les
nouveaux SID et STAR devront tenir compte des points d'entrée-sortie de TMA pour le trafic
au départ et à l'arrivée de Shannon et des aéroports régionaux. Les STAR devraient être
Rapport CEE No. 366
101
EUROCONTROL
utilisés de préférence au guidage vectoriel radar, ce dernier risquant de se révéler trop
complexe. 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édiatement
supérieur au niveau de transition (TL) jusqu'au FL 140. Le contrôleur de planification de la
TMA devrait attribuer les niveaux de vol aux secteurs inférieurs (NLO/SLO) à mesure de leur
disponibilité. Le TL et les niveaux en deçà devraient être placés sous le contrôle du secteur
d'approche.
Approche de Shannon (APP)
Confrontés aux volumes de trafic prévus pour le long terme, les contrôleurs d'approche ont
rapidement connu des problèmes de surcharge R/T. Malgré une maintenance adéquate de
l'interface électronique entre le contrôleur et la machine, il s'est révélé impossible d'utiliser
en parallèle les bandes de progression de vol, même en appliquant les niveaux
prévisionnels de trafic à moyen terme. Les contrôleurs ont recommandé de confier au
contrôle d'approche la responsabilité des aéronefs en attente au TL sur les points simulés
de 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 la
trajectoire d'approche finale de Shannon
Dans 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 de
l'importance du brouillage d'étiquettes généré en approche finale. Les contrôleurs ont
unanimement estimé qu'il convenait de décaler ces points par rapport aux trajectoires
d'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 de
la piste 24) et le point FOY en coordonnées 5245°N 0924°W (au nord de l'approche de la
piste 06). À défaut d'être idéale, cette solution s'est avérée bien meilleure. Par ailleurs, une
forte proportion de contrôleurs s'est prononcée en faveur de la fixation de deux points
d'attente pour chacune des pistes (comme à Dublin), situés de part et d'autre des approches
finales.
3.5.5.
Utilisation de nouveaux SID / STAR pour les aéroports nationaux et régionaux
Les SID de Shannon se sont révélés satisfaisants à l'usage. Tous les contrôleurs ont
apprécié le fait que les routes de départ soient séparées des routes d'arrivée. Les niveaux
par défaut étaient adéquats et ont rendu toute coordination superflue. Dans le scénario de
simulation initial, le SID de la piste 24 pour les vols vers Dublin (DUB2B) s'effectuait par un
virage à gauche. Lorsque la sectorisation NLO/SLO a été simulée, les contrôleurs ont
estimé qu'un virage à droite après le décollage aurait été plus indiqué. Les participants ont
par ailleurs suggéré qu'à l'avenir, les SID et STAR soient définis en tenant dûment compte
des secteurs NLO/SLO et TMA. De fait, en faisant aboutir les SID aux points de sortie de
TMA et en faisant débuter les STAR aux points d'entrée de TMA, on aurait l'assurance que
la 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. Les
contrôleurs n'ont éprouvé aucune difficulté à prendre en charge les aéronefs décollant de
ces aéroports avec une autorisation de montée initiale jusqu'à 5000 pieds, sans coordination
préalable. Les départs imminents de tous les aéroports apparaissaient dans les listes de
départs des secteurs correspondants. Les aéronefs à l'arrivée étaient guidés en descente
jusqu'au TL (FL 60), puis transférés au secteur d'entrée pour les vols intérieurs en Irlande
une fois dégagés du trafic au départ. De l'avis des participants, pour peu que le nouveau
102
Rapport CEE No. 366
EUROCONTROL
système comporte des connexions en ligne avec les aéroports régionaux et qu'une
couverture radar adéquate soit mise en place, aucune coordination ne devrait être
nécessaire entre Shannon et lesdits aéroports. Aussi recommandent-ils d'élaborer des SID
et STAR pour tous les aéroports régionaux.
3.5.6.
Nouvelle sectorisation de l’espace aérien supérieur de l’ATCC de Shannon
Les contrôleurs ont estimé que le recours à des secteurs superposés constituait une
excellente méthode pour prendre en charge des volumes de trafic élevé sur une même
trajectoire, 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. Les
participants ont fait remarquer qu'en conditions d'exploitation réelles, la sélection stratégique
des 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 de
Shannon, a été la principale pierre d'achoppement lors de la simulation de l'espace
supérieur. Dans ce dernier cas, les difficultés étaient toutefois davantage imputables à l'IHM
qu'aux dimensions des secteurs. Au stade actuel, la sectorisation dans le plan vertical pose
encore énormément de problèmes aux systèmes électroniques, en termes de prévision de
trajectoires et de calcul des profils de montée et de descente. Ces difficultés ne sont pas
sans 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. Il
convient de noter toutefois que la sectorisation utilisée dans la simulation de l'espace aérien
supérieur de Shannon, caractérisée par des modifications dynamiques et stratégiques pour
répondre aux impératifs du trafic océanique, sera extrêmement difficile à reproduire dans le
cadre du futur système, où l'interface homme machine fonctionne essentiellement sur la
base 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 Dublin
Départs de Dublin (DEP)
Les contrôleurs ont très favorablement accueilli la création d'un secteur DEP. De l'avis
général, cette initiative permettait de réduire sensiblement la charge de travail actuelle des
contrôleurs de secteur de zone au niveau de l'identification et de la prise en charge des vols
au départ. Bien qu'une coordination avec les secteurs d'approche se soit révélée par
moments nécessaire pour résoudre certains conflits, les contrôleurs se sont élevés contre la
pratique consistant à acheminer systématiquement les aéronefs à réaction au départ
jusqu'aux balises (au lieu de 3000 pieds) avant de les faire virer, afin de prévenir les conflits
avec 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 de
l'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 familiarisation
seront nécessaires pour en tirer plus largement parti. L'application d'une séparation de 3
MN en approche finale était totalement nouvelle pour les contrôleurs d'approche. Ces
derniers ont éprouvé énormément de difficultés à appliquer correctement un espacement
aussi faible en raison de l'exiguïté de l'espace aérien réservé à cet effet. Le contrôleur FIN
avait tendance à prendre les vols en charge à une distance de plus en plus éloignée de
l'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
Rapport CEE No. 366
103
EUROCONTROL
finale à partir d'une distance de 15 MN jusqu'au toucher des roues était trop restrictive. Une
formation et une expérience plus poussées seront requises pour parfaire les compétences
des contrôleurs en matière d'application d'une séparation de 3 MN fondée sur l'utilisation
stricte du contrôle de vitesse et de nouvelles procédures de travail. Les contrôleurs ont
recommandé que soit revue, et étendue, la zone dans laquelle une séparation de 3 NM est
permise.
3.5.8.
Utilisation de secteurs à contrôleur unique à l’ATCC de Dublin
Un troisième secteur de zone baptisé « Dublin West Area » (ARW), géré par un seul
contrôleur exécutif, a été créé aux fins de prendre en charge les vols en provenance du nord
et de l'ouest. Les contrôleurs de planification ont été retirés des secteurs ARN et ARS, la
configuration comportant alors un contrôleur exécutif par secteur simulé. Le secteur ARW a
pris en charge l'ensemble du trafic précédemment géré par le secteur ARN (à l'exception
des vols sur les routes B1 et W911D) et par le secteur ARS (à l'exception des vols sur les
routes R14 et B39). L'ARW contrôlait par ailleurs les deux points d'attente ouest (DINIL et
NASRI) 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 relativement
bien et déchargeait efficacement les secteurs ARN et ARS, plus encombrés. Il sera
toutefois nécessaire d'analyser plus avant la manière de prendre en charge les survols
simultanés en direction du nord sur les routes UP600 et UR14. L'interface entre l'ARW et
tous les secteurs adjacents de Shannon et Dublin devra également être étudiée de manière
plus approfondie.
3.5.9.
Repositionnement des points d’attente DINIL et NASRI et déplacement de la
limite occidentale de la CTA de Dublin
Les points d'attente ouest DINIL et NASRI ont été simulés à leur nouvel emplacement dans
toutes les organisations. Le déplacement de la limite occidentale de la CTA de Dublin a
permis d'utiliser ces deux points d'attente ainsi que leurs zones tampons respectives. Le fait
d'avoir éloigné les points DINIL et NASRI de l'aéroport a eu pour effet de faciliter le guidage
vers toutes les pistes, en ménageant un espace et des délais suffisants aux contrôleurs
d'approche pour intégrer le trafic en provenance de ces points avec celui des points ROKNA
et TULSO. Ce repositionnement a également facilité l'écoulement des courants de trafic au
dé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 incidences
considérables sur les opérations dans l'espace aérien inférieur de Shannon, en particulier
lorsque 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 Dublin
Les contrôleurs ont estimé que la mise en service d'une piste parallèle était doublement
avantageuse en ce sens qu'il devenait possible de faire décoller aisément tous les vols au
départ et d'appliquer de manière systématique une séparation de 3 MN aux aéronefs en
approche 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 des
participants, avoir des incidences considérables sur les opérations ATC, en termes
d'attentes et de retards au décollage, lorsque les prévisions de trafic à long terme seront
devenues réalité.
104
Rapport CEE No. 366
EUROCONTROL
3.5.11. Instauration d’une séparation de 3 MN entre les aéronefs en approche finale de
la piste 10R
L'application d’une séparation de 3 MN entre les aéronefs en approche finale de la piste 10R
n'a, malheureusement, pas fait l'objet d'une évaluation. Le réaménagement des différentes
organisations comme suite aux difficultés techniques rencontrées au cours de la simulation a
en effet entraîné l'annulation (avec le consentement du client) de l'organisation F, qui
pré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 Dublin
Les contrôleurs se sont déclarés impressionnés par le système et ont formulé une série de
recommandations 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 beaucoup
d'éloges. L'espace aérien de Copenhague est fort semblable à celui de Dublin en ce sens
que l'approche principale se situe à proximité immédiate de la limite de la FIR adjacente de
Malmö. Les contrôleurs danois utilisent le système avec succès pour réguler et optimiser les
courants de trafic à l'arrivée aux points d'entrée de TMA. Les contrôleurs ont unanimement
recommandé à 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 grandement
l'élaboration de procédures spécifiques pour Dublin.
Les participants ont par ailleurs souligné que l'installation du système MAESTRO à Dublin
nécessiterait le concours des ATCC de Manchester et de Londres.
Le système MAESTRO serait particulièrement utile pour créer des intervalles en approche
par lesquels s'écouleraient les courants au départ dans le cadre d'une exploitation à piste
unique.
Les contrôleurs d'approche des secteurs APN et APS ont indiqué avoir éprouvé des
difficultés à identifier rapidement les aéronefs qui leur étaient destinés lorsque le système
fonctionnait en mode « piste ». L'affichage des indicatifs d'appel selon un code de couleurs
par secteur résoudrait ce problème.
De l'avis général, le système MAESTRO devrait pouvoir fournir les temps d'attente minimum
et maximum ainsi que la durée de vol de la pile d'attente à la piste. L'organisation des points
d'attente nécessitera de nouvelles lettres d'accord avec MATCC/LATCC. La séquence
depuis les points d'attente devrait être déterminée par les secteurs d'approche, qui auraient
recours 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 que
l'affichage du système MAESTRO devrait être distinct sur le pupitre de contrôle et non
intégré à l'écran radar 2k X 2k.
Rapport CEE No. 366
105
EUROCONTROL
106
Rapport CEE No. 366
EUROCONTROL
ANNEX I
IRL 2000 REAL-TIME SIMULATION
MAPS
Rapport CEE No. 366
107
EUROCONTROL
108
Rapport CEE No. 366
EUROCONTROL
Map 1: Organisation A
Rapport CEE No. 366
109
EUROCONTROL
Map 2: Organisation B
110
Rapport CEE No. 366
EUROCONTROL
Map 3: Organisation C
Rapport CEE No. 366
111
EUROCONTROL
Map 4: Organisation D
112
Rapport CEE No. 366
EUROCONTROL
Map 5: Organisation E
Rapport CEE No. 366
113
EUROCONTROL
Map 6: Shannon Low Level – Organisation A
114
Rapport CEE No. 366
EUROCONTROL
Map 7: Shannon Low Level – Organisation B
Rapport CEE No. 366
115
EUROCONTROL
Map 8: Dublin CTA – Organisations A,B, C, D
116
Rapport CEE No. 366
EUROCONTROL
Map 9: Dublin CTA – Organisation E
Rapport CEE No. 366
117
EUROCONTROL
118
Rapport CEE No. 366
EUROCONTROL
ANNEX II
IRL 2000 REAL-TIME SIMULATION
Operations Room Floorplans
Rapport CEE No. 366
119
EUROCONTROL
120
Rapport CEE No. 366
EUROCONTROL
photo 5: Ireland 2000 Real-time Simulation Operations Room
Rapport CEE No. 366
121
EUROCONTROL
40
41
42
43
44
45
28"
28"
28"
28"
28"
28"
AMAN
IRL2000
ORG.A
AMAN
Hybrid
TWR
118.6
Hybrid
IRL
118.7
Hybrid
SWK
127.9
Hybrid
LON
133.6
Hybrid
LND
132.95
FEED
SEA
135.57
SH3
132.15
EXC
28"
1
PLC
28"
21
Strp.pr.
21"
26
Strp.pr.
6
DL2
PLC
28"
ARS
AMAN
134.27
124.65
EXC
28"
2
PLC
28"
22
Strp.pr.
EXC
28"
Strp.pr.
11
D
U
B
L
I
N
EXC
28"
APS
119.55
3
28"
23
Strp.pr. AMAN
Strp.pr.
28"
Strp.pr.
10
Strp.pr.
EXC
28"
9
Strp.pr.
EXC
ARN
129.17
28"
TMA
120.2
PLC
28"
Strp.pr.
124.7
PLC
28"
24
EXC
28"
4
AMAN
S
H
A
N
N
O
N
Strp.pr.
Strp.pr.
27
APN
121.1
LOW
AMAN
28"
7
8
28"
PLC
28"
25
EXC
28"
5
Strp.pr.
APP
121.4
EXC
28"
12
SUPERVISION
25.02.00/SLI
Operations Room - Organisation A
122
Rapport CEE No. 366
EUROCONTROL
40
41
42
43
44
45
28"
28"
28"
28"
28"
28"
AMAN
IRL2000
ORG.B
AMAN
Hybrid
Hybrid
TWR
IRL
118.6
118.7
Hybrid
SWK
127.9
Hybrid
LON
133.6
Hybrid
LND
132.95
FEED
SEA
135.57
SH3
132.15
EXC
28"
1
PLC
28"
21
Strp.pr.
21"
26
Strp.pr.
6
DL2
PLC
28"
ARS
AMAN
124.65
EXC
28"
2
PLC
28"
22
APS
NLO
127.5
119.55
EXC
PLC
28"
3
28"
23
Strp.pr. AMAN
Strp.pr.
28"
Strp.pr.
10
Strp.pr.
EXC
28"
9
Strp.pr.
EXC
ARN
129.17
28"
TMA
120.2
PLC
28"
Strp.pr.
124.7
PLC
28"
24
EXC
28"
4
S
H
A
N
N
O
N
Strp.pr.
Strp.pr.
27
APN
121.1
SLO
AMAN
28"
7
8
28"
Strp.pr.
Strp.pr.
D
U
B
L
I
N
EXC
EXC
28"
11
134.27
28"
25
EXC
28"
5
Strp.pr.
AMAN
EXC
PLC
DEP
APP
121.4
EXC
28" 12
118.5
SUPERVISION
25.02.00/SLI
Operations Room - Organisation B
Rapport CEE No. 366
123
EUROCONTROL
40
41
42
43
44
45
28"
28"
28"
28"
28"
28"
AMAN
AMAN
Hybrid
TWR
118.6
Hybrid
IRL
118.7
Hybrid
SWK
127.9
Hybrid
LON
133.6
Hybrid
LND
132.95
FEED
SEA
135.57
SH2
132.15
26
21"
EXC
28"
PLC
Strp.pr.
6
1
PLC
28"
21
Strp.pr.
DL2
134.27
124.65
EXC
28"
2
PLC
28"
22
Strp.pr.
Strp.pr.
D
U
B
L
I
N
28"
EXC
28"
11
EXC
MAE
ARS
AMAN
IRL2000
ORG.C
EXC
28"
APS
BR3
131.15
119.55
EXC
PLC
Strp.pr. AMAN
10
EXC
28"
Strp.pr.
FIN
135.6
EXC
ARN
129.17
SPB
135.22
PLC
28"
Strp.pr.
APN
121.1
SPA
PLC
28"
24
EXC
28"
4
S
H
A
N
N
O
N
Strp.pr.
Strp.pr.
27
23
Strp.pr.
AMAN
28"
7
28"
121.87
Strp.pr.
9
3
Strp.pr.
EXC
28"
28"
PLC
28"
25
EXC
28"
5
Strp.pr.
AMAN
28" 12
8
28"
SUPERVISION
25.02.00/SLI
Operations Room - Organisation C
124
Rapport CEE No. 366
EUROCONTROL
40
41
42
43
44
45
28"
28"
28"
28"
28"
28"
AMAN
AMAN
Hybrid
Hybrid
TWR
118.6
IRL
118.7
Hybrid
SWK
127.9
Hybrid
LON
133.6
Hybrid
LND
132.95
FEED
SEA
135.57
DL1
132.15
26
21"
EXC
28"
PLC
Strp.pr.
6
1
PLC
28"
21
Strp.pr.
SPE
134.27
124.65
EXC
28"
2
PLC
28"
22
Strp.pr.
Strp.pr.
D
U
B
L
I
N
28"
EXC
28"
11
EXC
MAE
ARS
AMAN
IRL2000
ORG.D
EXC
28"
APS
GP1
131.15
119.55
EXC
PLC
Strp.pr. AMAN
10
EXC
28"
Strp.pr.
FIN
8
28"
135.6
EXC
ARN
129.17
SPF
135.22
PLC
28"
Strp.pr.
APN
121.1
CK1
PLC
28"
24
EXC
28"
4
S
H
A
N
N
O
N
Strp.pr.
Strp.pr.
27
23
Strp.pr.
AMAN
28"
7
28"
121.87
Strp.pr.
9
3
Strp.pr.
EXC
28"
28"
PLC
28"
25
EXC
28"
5
Strp.pr.
AMAN
EXC
28" 12
DEP
118.5
SUPERVISION
25.02.00/SLI
Operations Room - Organisation D
Rapport CEE No. 366
125
EUROCONTROL
40
41
42
43
44
45
28"
28"
28"
28"
28"
28"
AMAN
AMAN
Hybrid
TWR
118.6
Hybrid
IRL
118.7
Hybrid
SWK
127.9
Hybrid
LON
133.6
Hybrid
BST
133.0
FEED
SEA
135.57
SPC
132.15
EXC
21"
36
6
134.27
AMAN
EXC
D
U
B
L
I
N
EXC
28"
1
PLC
28"
21
EXC
28"
2
PLC
28"
22
ARS
Strp.pr.
124.65
Strp.pr.
11
28"
Strp.pr.
GN1
28"
EXC
MAE
28"
Strp.pr.
IRL2000
ORG.E
APS
SPD
131.15
119.55
EXC
PLC
Strp.pr. AMAN
10
EXC
28"
Strp.pr.
FIN
APN
121.1
EXC
8
28"
135.6
ARN
129.17
GR1
135.22
EXC
28"
Strp.pr.
BN1
PLC
28"
24
EXC
28"
4
S
H
A
N
N
O
N
Strp.pr.
Strp.pr.
13
23
Strp.pr.
AMAN
28"
7
28"
121.87
Strp.pr.
9
3
Strp.pr.
EXC
28"
28"
ARW
136.05
PLC
28"
25
EXC
28"
5
Strp.pr.
AMAN
EXC
28" 12
DEP
118.5
SUPERVISION
25.02.00/SLI
Operations Room - Organisation E
126
Rapport CEE No. 366

The full report

Transcription

Similar documents

VOL. 71, NO. 3 Avril -- April 2012 - AAFI

a/w 2011 media kit

hindrance to traffic on june 22, 2014 / ironman mont

Bulletin O`Sullivan 2012 - Collège O`Sullivan de Montréal

Early golf in Arcachon

Sortie nationale le 12 juillet

Part 9 - French-Canadian Heritage Society of Michigan

Long-Standing Members` Exhibition À l`occasion du 25e

Icon - Enterprise Ireland

Moving Objects from Geographic Pasts to Virtual Presence Objets