SUMMARY REPORT OF THE EVP AMAN ROME REAL TIME … · 1.3 ARRIVAL MANAGER AMAN AMAN is a Decision Support Tool (DST) and provides the controller with information on a calculated sequence

EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EUROCONTROL EXPERIMENTAL CENTRE

SUMMARY REPORT OF THE EVP AMAN ROME REAL TIME SIMULATION 2004

EEC Note No. 17/05

Project European ATM Reference Validation Platform

Issued: August 2005

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 Note No. 17/05

Security Classification: Unclassified

Originator: EEC – ATM (Air Traffic Management)

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: Ente Nazionale Assistenza al Volo SpA (ENAV), EUROCONTROL Experimental Centre, the European Air Traffic Management (EATM) Programme of EUROCONTROL and the European Commission (EC) Directorate General for Transport and Energy (DG TREN)

Sponsor (Contract Authority) Name/Location: EUROCONTROL Agency 96, Rue de la Fusée B -1130 Brussels Telephone: +32 2 729 90 11 WEB Site: www.eurocontrol.int

TITLE: SUMMARY REPORT OF THE EVP AMAN ROME REAL TIME SIMULATION 2004

Authors Alan Drew

Peter Martin

Date 08/2005

Pages viii + 27

Figures 0

Tables 0

Annexes 2

References --

Project SSP-EVP

Task No. Sponsor

Period 2005

Distribution Statement: (a) Controlled by: Head of ATM (b) Special Limitations: None (c) Copy to NTIS: YES / NO

Descriptors (keywords): AMAN, Arrival Management, Sequencing, Trajectory Prediction

Abstract: This report of the EVP AMAN Rome Real time simulation presents the main findings from the simulation conducted at the ENAV Experimental Centre Rome in October 2004. The simulation was conducted over a three week period with eleven controllers from Rome ACC as part of a series of studies looking at issues associated with the introduction of Decision Support Tools, in this case an Arrival Management Tool, into the ATM environment The report describes the preparation and simulation process and summarises findings on the main deliverables of the project: validation issues linked to Human Factors and Usability. The report also discusses issued associated with the configuration and use of the AMAN tool itself and provides recommendations on future work.

Summary Report on the EVP AMAN Rome Real-Time Simulation 2004 EUROCONTROL

Project SSP-EVP - EEC Note No. 17/05 v

FOREWORD

This report of the EVP AMAN Rome Real time simulation presents the main findings from the simulation conducted at the ENAV Experimental Centre Rome in October 2004. The simulation was conducted over a three week period with eleven controllers from Rome ACC as part of a series of studies looking at issues associated with the introduction of Decision Support Tools, in this case an Arrival Management Tool, into the ATM environment The report describes the preparation and simulation process and summarises findings on the main deliverables of the project: validation issues linked to Human Factors and Usability. The report also discusses issued associated with the configuration and use of the AMAN tool itself and provides recommendations on future work.

EUROCONTROL Summary Report on the EVP AMAN Rome Real-Time Simulation 2004

vi Project SSP-EVP - EEC Note No. 17/05

ACKNOWLEDGEMENTS

The EVP project is sponsored by the European Commission (EC) The authors would like to thank the AMAN RTS team and supporting companies Deep Blue, SICTA and Barco. In particular they would like to thank ENAV for hosting the simulation at their Experimental Centre in Rome, the support staff and pilots and the controllers from Rome ACC for their participation.


Project SSP-EVP - EEC Note No. 17/05 vii

DEFINITIONS AND ACRONYMS ACC Area Control Centre ADS-B Automatic Dependent Surveillance -Broadcast AMAN Arrival Manager ASAS Airborne Separation Assistance System ATC Air Traffic Control ATCO Air Traffic Controller ATM Air Traffic Management DST Decision Support Tools EC European Commission EEC Eurocontrol Experimental Centre ENAV Ente Nazionale di Assistenza al Volo LFV LuftFartsVerket EVP European Reference ATM Validation Platform FAF Final Approach Fix FL Flight Level FPL Flight Plan HMI Human Machine Interface IAF Intermediate Approach Fix MTCD Medium Term Conflict Detection OCU Operational Concept of Use PC Planning Controller R/T Radio Telephony RTA Required Time of Arrival RTO Required Time Over RTS Real Time Simulation SM Sequence Manager TC Tactical Controller TP Trajectory Predictor TTL Time to Lose TTG Time to Gain UNL Unlimited XFL Exit Flight Level


viii Project SSP-EVP - EEC Note No. 17/05

TABLE OF CONTENTS

FOREWORD ................................................................................................................................................... V ACKNOWLEDGEMENTS............................................................................................................................... VI DEFINITIONS AND ACRONYMS ................................................................................................................. VII 1. INTRODUCTION....................................................................................................................................1 1.1 DOCUMENT OVERVIEW ......................................................................................................................1 1.2 EVP AND AMAN ....................................................................................................................................1 1.3 ARRIVAL MANAGER AMAN .................................................................................................................2 2. THE PREPARATION PHASE ................................................................................................................3 2.1 PHASE ONE...........................................................................................................................................3 2.2 PHASE TWO..........................................................................................................................................3 2.3 SIMULATION CONDITIONS..................................................................................................................4 3. THE REAL-TIME SIMULATION.............................................................................................................5 3.1 THE SIMULATION PLAN.......................................................................................................................5 3.2 VALIDATION OBJECTIVES...................................................................................................................6 3.3 THE SIMULATION PLATFORM ............................................................................................................6 3.4 SIMULATION TRAFFIC AND AIRSPACE .............................................................................................6 3.5 CONTROLLER TASKS AND PROCEDURES.......................................................................................7 3.6 QUANTITATIVE ANALYSIS...................................................................................................................9 4. FINDINGS FOR VALIDATION OBJECTIVE ONE CONTROLLER ROLES AND

WORKING METHODS.........................................................................................................................10 4.1 SEQUENCE MANAGER ROLE ...........................................................................................................10 4.2 ROLES AND WORKING METHODS OF THE AREA CONTROLLERS .............................................10 4.3 ROLES AND WORKING METHODS OF THE APPROACH CONTROLLERS...................................10 5. FINDINGS FOR VALIDATION OBJECTIVE TWO USABILITY...........................................................12 5.1 IAF AND LANDING LIST DIFFERENCES. ..........................................................................................12 5.2 THE RE-ROUTING TOOL....................................................................................................................12 5.3 SM POSITION......................................................................................................................................12 5.4 UNR......................................................................................................................................................12 5.5 PROBE FUNCTIONALITY ...................................................................................................................13 5.6 OTHER.................................................................................................................................................13 5.7 EATM AND TIMELINE .........................................................................................................................13 5.8 HMI REDESIGN PROPOSAL ..............................................................................................................13 6. FINDINGS FOR VALIDATION OBJECTIVE THREE: OVERALL IMPACT .........................................14 6.1 GENERAL CONSIDERATIONS...........................................................................................................14 6.2 IMPACT ON CONTROLLERS WORK.................................................................................................14 6.3 IMPACT ON SAFETY, ECONOMIC AND CAPACITY ISSUES. ........................................................15 7. FINDINGS ASSOCIATED WITH THE CONFIGURATION AND FUNCTIONALITY OF AMAN..........17 7.1 AMAN CONFIGURATION AND STABILITY ISSUES..........................................................................17 7.2 THE IMPACT OF THE CHOICE OF AIRSPACE.................................................................................18 7.3 ALLOCATION OF DELAY....................................................................................................................19 7.4 SPECIFIC OPERATIONAL ASPECTS ................................................................................................20 8. CONCLUSIONS AND RECOMMENDATIONS....................................................................................21 8.1 CONCLUSIONS ...................................................................................................................................21 8.2 RECOMMENDATIONS FOR SSP BUSINESS AREA.........................................................................21 8.3 RECOMMENDATIONS FOR ENAV ....................................................................................................22 ANNEX 1: DOCUMENTATION ......................................................................................................................25 ANNEX 2: AIRSPACE MAP ...........................................................................................................................27


Project SSP-EVP - EEC Note No. 17/05 1

1. INTRODUCTION

1.1 DOCUMENT OVERVIEW This document is the summary report on the EVP Rome AMAN real-time simulation which took place at the ENAV Experimental Centre, Rome with controllers from Rome ACC in October 2004. It is in eight sections:

• Chapter One provides an overview of EVP and AMAN, • Chapter Two describes the preparation phases, • Chapter Three describes the real-time simulation itself, • Chapter Four presents a summary of the conclusions for Validation Objective One:

Controller Roles and Working Methods, • Chapter Five presents a summary of the conclusions for Validation Objective Two:

Usability, • Chapter Six presents a summary of the conclusions for Validation Objective Three: Overall

impact, • Chapter Seven presents a summary of issues associated with the use of AMAN and • Chapter Eight presents conclusions and recommendations for future work.

The findings reported here for the most part come from deliverables produced by the AMAN team members. A full list of the documentation can be found in Annex 1.

1.2 EVP AND AMAN

The AMAN project is part of the European Reference ATM Validation Platform project (EVP).

The aim of the EVP is to validate Air/Ground concepts through simulation and shadow-mode trials based on ADS-B, ASAS and Sequencing Tools. The focus of the activity is towards validation trials using live data (both at the EEC and at National Service Providers sites’). The results will be used to develop EUROCONTROL recommendations for future system and procedure enhancements by member states.

The principal stakeholders to EVP are the EEC as project leaders, the EC as sponsor and the LFV (Sweden) and ENAV (Italy) as service providers. Target sites are Malmö, Arlanda and Rome ACCs.

ENAV considers that the introduction of AMAN is a necessary step to manage the increasing demand faced by Rome ACC and to this end has set up a program called A4C planned to lead to the introduction of an Arrival Manager.

The AMAN Rome Real-Time simulation was part of a series of studies looking at the introduction of arrival management (classical sequence and time advisories) and delay sharing (extending the horizon of control actions to meet pre-determined time constraints) functionality into the ATM environment. It consisted of a number of key events:

• Development of an operational concept • Testing and verification of the platform at the EEC and on-site • Validation exercises at the EEC • Feedback from controller evaluation on-site • A real-time simulation • Reporting of results


Initial work on the ideas had already been conducted with the LFV in the Stockholm approach area. This simulation investigated the introduction of an AMAN into a more complex environment, the Rome approach and some en-route sectors extending out to Milan.

Working method descriptions were produced which gave an operational viewpoint on how the output from AMAN can be efficiently used by both a Sequence Manager (SM) and the Planning and the Tactical controllers.

1.3 ARRIVAL MANAGER AMAN AMAN is a Decision Support Tool (DST) and provides the controller with information on a calculated sequence to the runway. AMAN calculates times for aircraft to arrive at designated fixes (Intermediate Approach Fix, IAF). In the process of calculating sequences, AMAN also calculates what time to lose may be required (TTL) and this information can be displayed in any or all sectors within an ACC. An EATM interface was developed to display this information (Reference 4). The sectors considered for the Rome RTS included the Milan, NW, NE, TS and UNR sectors. The times to lose are described as AMAN advisories and these advisories are displayed in the label of each Fiumicino arrival aircraft. In the simulation AMAN advisories were related to Required Time Over (RTO) the Intermediate Approach Fixes, Tarquinia (TAQ), Campagnano (CMP) and Ciampino (CIA). (Reference Map in Annex 2). The AMAN sequence calculation process is not based on a criterion of 'First Come First Served' but AMAN was configured to have specific criteria (minimum total delay) applied for delay distribution in a fair and unbiased manner. The overall result of AMAN calculation is that the controllers in all sectors have 'an arrival plan' which is monitored and updated by the system. The AMAN advice supports the controller in his work while requiring changes to his working methods. A key role is played by a Sequence Manager who coordinates actions and can intervene if necessary on the proposed sequence.

2 Project SSP-EVP - EEC Note No. 17/05



2. THE PREPARATION PHASE

2.1 PHASE ONE A team led by EUROCONTROL and ENAV and consisting of management, operational and technical expertise started to work in 2003 with the production of an Operational Concept of Use document. This document described the philosophy of introducing AMAN into an EATM working environment alongside other Decision Support Tools such as Medium Term Conflict Detection (MTCD) and proposed some initial ideas on working methods of both en-route and approach controllers. In agreement with ENAV the simulation initially planned to look at several aspects of AMAN including:

• investigating the introduction of an AMAN into the Rome environment and in particular to evaluate controller working methods and configuration aspects of the AMAN Tool,

• evaluating the interface developed for AMAN by the EATM programme (which replaced the traditional timeline display),

• investigating the potential for delay sharing that AMAN offered, • investigating the implications of using AMAN with MTCD in one sector, Milan.

Preparation of the simulation platform at ENAV began in March 2004. This was the first simulation with the AMAN tool and there was a significant amount of work to be done to achieve a technically stable platform. In particular problems associated with the Trajectory Predictor (TP) meant that the AMAN advice on TTL and sequence was initially very unstable and much time was taken to correct this. This instability problem was never fully resolved but could be managed operationally by the controllers. In March and April a series of technical, operational and site acceptance tests (SATs) took place. These identified modifications to the platform and operational concept. Full details of change requests and problems reported throughout the preparation and simulation period are provided in the Simulation Technical Report (Reference 10). Originally it was intended to use an algorithm specifically developed in the tool to allocate delay according to certain pre-defined rules. Experience in the SATs showed that this was not feasible from an operational and technical point of view and this formalised approach to delay sharing was replaced by a more operationally-orientated solution. The simulation was postponed just before training was due to start following unforeseen problems over controller availability. This created the opportunity to improve the platform technically and revise the operational concept in what became known as Phase 2.

2.2 PHASE TWO The initial operational concept proposal had focused on specific controller working methods between the planning and tactical roles working autonomously to implement the advised delay. It also focused heavily on the interaction with MTCD. Over the first phase of preparation it had become obvious that for the AMAN to work successfully there was a need to enhance the existing role of the Coordinator in Rome ACC and develop what became known as the Sequence Manager position. It was also decided to remove MTCD from the evaluations. MTCD had only been planned for use in one sector and the removal of formalised delay sharing and the relatively light arrival traffic (due to the absence of contextual traffic) simulated meant that there was little benefit to be gained in the simulation. It was considered that given the relatively high risk of integrating the tool into the platform and subsequently producing relevant simulation exercises involving AMAN, effort should be concentrated elsewhere.

EUROCONTROL Summary Report on the EVP AMAN Rome Real-Time Simulation 2004 Work to implement all of these changes culminated in a successful SAT 4 in September.

2.3 SIMULATION CONDITIONS This was the first look at arrival management under simulation conditions at Rome and it is important to record a number of things linked to the conditions of the simulation in order to fully appreciate the results.

• The simulation was a prototyping exercise whereby initial ideas evolved during the development. The limited time available with the Rome controllers due to operational demands did not enable the operational procedures to be developed with as much detail as would have been desirable.

• The simulation training period was relatively short and conducted during the first week. During this time the controllers had to learn the simulator functionality, the HMI, conduct a number of baseline exercises and be introduced to the AMAN concept, display and working procedures.

• The use of the current airspace limited the amount of useful feedback and the absence of

the final approach portion of the flight (normally handled by TN1, TN2 and ARR) created problems in fully assessing the impact of the use of AMAN. In addition the objective of replacing orbital with linear holding led, in some cases, to unrealistic operational interventions.

• The AMAN parameters used were based on an initial evaluation of the preferred

configuration and were not changed during the simulation.

• The Sequence Manager display needed further development to support the working methods.

While these conditions were important in occasionally affecting the quality of useful feedback many were known prior to the simulation and the objectives set accordingly. They are, however, important elements which should be taken into account in future work.




3. THE REAL-TIME SIMULATION

3.1 THE SIMULATION PLAN

A simulation plan was developed to evaluate and to evolve the working methods and system use following feedback and proposals from the Rome controllers and to evaluate the effect of introducing AMAN into the Rome ACC environment.

For the purposes of evaluating these elements the following approach was taken:

• The airspace represented as closely as possible (given the limitations of the simulation platform) the current situation,

• Working methods were developed which represented an initial view on how the controllers should work with the AMAN advice

• The AMAN tool was configured according to best estimates of what was appropriate and a limited amount of functionality developed for investigation.

The principal aim of the simulation was to evaluate the proposed working methods and by discussions and feedback develop more efficient procedures and use of the system. A formal validation plan ensured that all of the relevant feedback was captured and could be used in refining the concept (Reference 3).

In this respect, while the controller performance was of interest as a guide on the suitability of the concept, we were more concerned with obtaining their views on which features worked well, what needed to be done to eliminate problems and how the various elements could be adapted to provide workable procedures.

The simulation took place over three weeks in October 2004 with eleven controllers from Rome ACC. Three of these controllers were available to alternately man the Sequence Manager position while the others rotated around the sectors according to their ratings.

The simulation involved:

• Providing controllers decision support in terms of a computer generated optimised sequence to the runway and the resulting Time to Lose advisories (TTL) on particular beacons displayed in the EATM interface. As part of the project objectives an EATM compliant HMI, replacing the traditional ‘timeline’ arrival manager display, was developed for evaluation.

• Defining new working methods for the controllers and Sequence Manager, the major changes being the use of computer assistance, a change in the planning horizon and certain aspects of ‘time based’ control.

• Training the controllers on the concept, working positions and working methods.

• Running Baseline “Organisation One” exercises to provide a starting point for evaluation of subsequent changes with the AMAN organisations.

• Running an AMAN “Organisation Two” with pre-defined procedures.

• Reviewing and modifying these procedures in a number of formal and informal simulation sessions.

• Running an AMAN “Organisation Three” following the feedback and proposals from controllers.


3.2 VALIDATION OBJECTIVES

EVP AMAN Rome RTS High Level Objectives were as follows:

1. Evaluate and Develop the proposed roles and working methods with AMAN of the:

• Planner and Tactical Controllers managing en-route sectors.

• Planner and Tactical Controllers managing approach sectors1.

• Sequence Manager.

2. Evaluate and develop the display requirements for presenting AMAN advisories on the EATM interface.

3. Evaluate the overall effect of the introduction of AMAN with these working methods and

display on traffic management.

Following ATM2000+ strategic objectives the study focused on looking at Human Involvement and Commitment criteria with the addition of a further objective, “Usability”, due to project requirements.

3.3 THE SIMULATION PLATFORM The simulation was built on a standard Eurocontrol ESCAPE platform (EAT2003A release) consisting of 12 CWPs. Full details on the platform can be found in the Facility Specification Document listed in the Annex (Reference 2). The specific characteristic of the platform was the integration of the Arrival Manager and the replacement of the timeline normally associated with the arrival manager by an EATM HMI integrating AMAN information into the interface. New simulator functionality had been developed during the preparation phase including:

• An input facility for alternative routings. • use of speed in trajectory calculations. • use of input CFL in trajectory calculations.

The simulation platform performed well during the simulation. In total 33 exercises were run (10 Training, 4 measured baselines, 15 measured AMAN, 3 experimental and 1 scenario) and only one measured exercise lost for technical reasons.

3.4 SIMULATION TRAFFIC AND AIRSPACE Six traffic samples were prepared for the measured exercises representing a variety of traffic densities and complexity and having a peak demand of 40 arrivals per hour. A number of other traffic samples were prepared for training, scenario and experimental exercises.

1 For the purpose of the EVP AMAN Rome RTS “approach sectors” are those including the IAFs and thus being the last in dealing with the AMAN Advisories; while “en-route sectors” are upstream sectors with respect to approach ones, involved in the first part of the AMAN advisories management.




The traffic samples were, for the most part, well received by the controllers with an overall acceptable degree of realism. One caveat raised was that the samples lacked some contextual problems, in particular concerning LIRF departure streams which interact with the arrival flows. Despite this the samples were considered satisfactory for the simulation objectives. The airspace used for the simulation consisted of a subset of the Rome ACC sectors which were slightly modified:

• TS Sector – USR and TS combined -TS GND/UNL • Milan Sector – MIW and MIE combined – MIL FL295/UNL • Northwest Sector – NW1 and NW2 combined – NW GND/UNL • Northeast Sector – NE1 and NE2 combined – NE GND/UNL • UNR Sector – UN sectors and TN sectors combined GND/UNL

These sectors are described as measured sectors and ATM activity in these sectors was the subject of study during the simulation. These sectors were surrounded by three Feed sectors:

• Feed West (automatic) • Feed East (automatic) • Dep.

The simulation area can be found in the map in the Annex 2.

3.5 CONTROLLER TASKS AND PROCEDURES Differences with current practice Roles and working methods (Reference 1) proposed were derived by those applied in Rome ACC, with the following differences:

• No UN2 role that exists in Rome ACC in charge of over-flying traffic and holding management, this latter upon TN-COO instructions. Due to this absence during the RTS over-flying traffic was be managed by UNR TC, while holdings were not supported,

• the absence of paper strips in UNR sector and Coordinator position, thus clearances currently noted down on paper strips were input in the system in accordance with EATM HMI principles,

• The introduction of UNR PC role, currently not applied in Rome ACC. This was mitigation for the missing elements presented above, since the UNR PC was intended to reduce the UNR TC workload, assuming most of coordination, planning and data inputting tasks.

EUROCONTROL Summary Report on the EVP AMAN Rome Real-Time Simulation 2004 Baseline procedures The Baseline organisation was intended to reflect as much as possible today’s current environment, roles, working methods and practices (see Reference 6). Deviations from standard procedures were:

• UNR sector assumed some limited tasks and functions of the TN sector. • Arrival flights to LIRF and LIRA automatically proceeded on transfer to a pseudo sector

(TN sector). • Default transfer to TN sector FL070 or below with automatic co-ordination approval. • Default coordinated FL for inbound traffic to Naples was FL170 while departure traffic from

Naples was FL160. The introduction of AMAN necessitated a need for change from how the controllers work at Rome ACC. Specific controller roles and working methods were developed and proposed to the controllers to be applied during the first part of the RTS (namely in Org.Two): Sequence Manager

• a Sequence Manager (SM) was responsible for the arrival traffic management in the overall simulated airspace. He monitored the approach sequence defined by AMAN and made adjustments (either modifying the landing list or providing MI, NE, NW, TS, and UNR sector controllers with precise instructions of delay absorption or gain) in order to smooth the arrival traffic management and to reduce the overall delay.

UNR PC.

• UNR PC was responsible for ensuring conformance to the proposed landing sequence in UNR sector. He coordinated with the SM any change in the Landing List (LL) impacting on inbound traffic in UNR and/or proposed changes. In addition to these tasks the UNR PC coordinated entry conditions with adjacent sectors and updated the system according to UNR TC clearances.

UNR TC

• UNR TC cleared all a/c to comply with a pre-sequencing phase as established by the SM and complied with AMAN advisories associated with the inbound traffic in his sector.

NE, NW and TS

• NE, NW, TS sectors controllers played standard TC/PC roles in use in Rome ACC and applied delay actions defined in the working methods or suggested by the SM in order to absorb the delay and thus to smooth the arrival traffic management in the downstream sectors. These procedures were based on the idea of Intervention Areas introduced to ensure that the controllers acted at the appropriate time (i.e. not too soon enabling the advice to become stable) on aircraft having TTL entering their sector.

MILAN

• MI sector controllers were not intended to deal with AMAN advisories. They analysed the AMAN advisories in the labels and monitored their stability.




Refinements for Organisation Three

On the basis of the experience of the first two weeks, a process of refinement of the controller roles and working methods was carried out during the second part of the RTS. The main modifications introduced were:

• refinement of the separation of roles between SM and UNR PC. • a simplification of the SM working methods. • an enlargement of the Intervention Areas. • a simplification of the Area Controllers Working Methods.

3.6 QUANTITATIVE ANALYSIS The Data Set for quantitative analysis and comparisons consisted of three measured baseline exercises and five measured exercise in both AMAN Organisations. The baseline exercises were intended to provide the controllers with additional practice sessions on the simulator and if possible some reference data against which the subsequent AMAN exercises could be compared. These two purposes were in some respects contradictory and only limited statistical analysis was possible. Subsequently the experimental plan specifically called for changes to take place between Organisation Two and Three. Such a plan prevents the normal ‘mixing’ of exercises whereby changes in behaviour can be isolated to some degree from the learning effect which in this simulation was significant. Nevertheless some interesting trends were observed. A detailed report on the analysis is available in Reference 7. These results were primarily used to support the Human Factors analysis that is reported in the next section and to help to analysis some of the issues associated with AMAN behaviour. The principal findings are now summarised.

The introduction of the arrival manager did not cause an increase in interventions on the arrival traffic. It did however show a shift in interventions from the UNR sector to the upstream sectors confirming their increased involvement.

The baseline organisations reflected the current practice of direct routings whereas for the AMAN organisations this was largely replaced by speed and heading clearances.

Communication usage was similar across the organisations but showed a reduction in the number of calls initiated from the sectors to the SM in the final organisation.

The stability of the AMAN advice shows a slight improvement in the final organisation along with a slight reduction in the delay advice.

The intervention of the SM increased with Organisation Three and there is an indication that there was an improvement in both their ability to recover from ‘bad’ choices and to absorb higher delays.

In summary it can be said that the controllers became more confident in their use of the system and their ability to handle the traffic as the simulation progressed. This could be attributed both to the changes in the working methods and to familiarisation with the system. Although these results cannot be treated as definitive they confirm the subjective opinions given by the controllers.

Chapters Four, Five and Six now report on the Human Factors and Usability objectives of the simulation.



4. FINDINGS FOR VALIDATION OBJECTIVE ONE CONTROLLER ROLES

AND WORKING METHODS

The study was a first look at the operational issues involved in introducing an AMAN into the Rome environment and provided useful feedback on areas for refinement in future work. Validation Objective One looked at Controllers Roles and Working Methods, in particular

• The Sequence Manager Role • The Roles and working methods of the Area Controllers • The Roles and working methods of the Approach Controllers

Full details can be found in Reference 8. A summary of the main conclusions is presented below.

4.1 SEQUENCE MANAGER ROLE

The RTS results confirmed the key role of the SM in the AMAN environment.

The controllers involved in the RTS considered this role essential for the inbound traffic management supported by AMAN. A high level of acceptability and suitability was also associated with this role.

The main effects of the introduction of AMAN (compared to the current day operation with a Coordinator) were:

• an enlargement of the working horizon, • an enhanced planning role, • a more standardised working method.

4.2 ROLES AND WORKING METHODS OF THE AREA CONTROLLERS

The RTS results confirmed the appropriateness of involving the area controllers in inbound traffic management. This was considered a fundamental means to guarantee an orderly and expeditious inbound traffic flow and to re-distribute the overall workload.

In general the introduction of AMAN with the proposed roles was not expected to involve radical changes in the roles currently played in the operational environment. As a consequence the roles proposed for the area controllers were appreciated as acceptable and suitable to Rome ACC.

AMAN was considered a cooperative tool enhancing (indeed requiring) the cooperation of the area controllers in arrival traffic management to the extent that they become an integral part of the arrivals process. It had a limited impact on the tactical role in the area sectors.

4.3 ROLES AND WORKING METHODS OF THE APPROACH CONTROLLERS

The partition of the tasks associated with the sequence management among three controllers (namely SM, UNR PC and UNR TC) was appreciated by the controllers.

The main problem concerned an overlap in roles between SM and UNR PC which was improved during the simulation but remained a problem. This was not unexpected as the position is new and further refining of the roles is necessary.

It was considered fundamental to involve the area controllers in the inbound traffic management (thanks to the enlargement of the SM working horizon) and to reduce the perceived workload in the approach positions.



In terms of overall controller performances the introduction of AMAN (with these working methods and display) impacted on the controllers perceived workload implying a workload shift from the approach sectors to the area sectors that was considered acceptable by the controllers involved in the RTS.

Evaluation of the approach controller position was however difficult due to the absence of the TNR controller and the position of the IAFs. This latter point is particularly important and is further discussed in 7.2.



5. FINDINGS FOR VALIDATION OBJECTIVE TWO USABILITY In general the EATM HMI interface developed for the simulation worked well. The short time with the controllers did not permit all of the necessary refinements but acceptance was in general good. The Usability Study highlighted some deficiencies and proposed solutions and a design process. Full details can be found in Reference 8.

5.1 IAF AND LANDING LIST DIFFERENCES. Information on the sequence number was available in the Landing List but not in those associated with the IAFs. This caused problems for the area controllers when deciding on how to implement delay absorption strategies without knowledge of the final landing sequence. This problem is part of the larger problem of evaluating the effect of removing the timeline (see 5.7).

5.2 THE RE-ROUTING TOOL The re-routing tool had been introduced relatively quickly. It had become obvious during the preparation that the controllers, when instructing aircraft to follow certain standard routes to absorb delay, needed a quick way to update the system .The re-routing tool provided a means to do this by enabling the controllers to select from a list of pre-defined options. While it performed well it was lacking in a number of features and was found to be inadequate in three areas:

• The list of pre-defined alternative routes was not complete • The alternative routes were only available for inbound traffic • There was no ‘probe’ functionality (see 5.5 below)

5.3 SM POSITION The usability issues associated with the SM position concerned the range and visibility of the required airspace and use of specific input functionality such as insert, re-insert etc. While the SM position was generally considered complete there were problems with the amount of information on the screen. To work properly the SM needs to display four lists and to use a map size large enough to cover all the simulated sectors. This results in a crowded display. Some of the functionality developed for changing the position of the aircraft in the landing list was too demanding in terms of effort and needs to be redesigned.

5.4 UNR Although the working methods evolved during the study allowing the UNR controller to change the sequence he did not have access at the HMI level and had to ask the SM to update the Landing List with the modifications defined by the approach controllers. This unnecessarily increased the perceived workload of both SM and UNR PC and highlighted the importance of ensuring the evolution of the HMI with the concept.



5.5 PROBE FUNCTIONALITY The issue of whether Probe functionality would be useful in helping to support the controller in their enhanced planning role was raised. This is a general issue with decision support tools and was outside the scope of the simulation objectives. In addition a Probe facility could lessen the ease by which controllers could introduce small errors into the system causing significant changes in the sequence and advice

5.6 OTHER A number of general low level usability issues were identified including

• The use of yellow for high priority • Use of single speed vector • The leader line occasionally obscured the label • The use of the range and bearing tool

In addition a number of other functions were not tested (gap information, highlighting function, runway slot insertion etc).

5.7 EATM AND TIMELINE One of the key elements in the AMAN concept under study was the replacement of the traditional timeline with a display containing the information conforming to EATM principles. This essentially meant presenting time to lose information in the label and developing a number of inbound lists. The study did not permit any conclusions to be drawn on the advantages and /or disadvantage of the EATM interface over the traditional AMAN timeline. A formal comparison of theses two methods of display was outside the validation scope of the project but nevertheless feedback on the EATM display was collected. A number of issues were raised which can be associated with the loss of ‘implicit’ information available from a timeline display and which is lost when the display is transformed. One such is the so called ‘Gap’ information i.e. how much slack is available in a particular sequence. The area controllers commented on the lack of this information. When taking decisions on intervention the area controllers felt that they needed to know the consequences on the downstream situation of their actions and would therefore benefit from more information on the sequence. Another associated issue is the granularity of the displayed values. The display of TTL information in the HMI requires a conversion of the value in seconds produced by AMAN into minutes for the EATM label. This raises two questions; how to truncate or round values in seconds into minutes and what magnitude of variation in seconds should trigger a change in the displayed value in minutes?

5.8 HMI REDESIGN PROPOSAL For each Usability problem identified an initial possible redesign proposal was made. These were then brought together into a proposal for an overall redesign process. Further studies should evaluate this and continue to study the requirements for AMAN information display on the EATM interface.



6. FINDINGS FOR VALIDATION OBJECTIVE THREE: OVERALL IMPACT

6.1 GENERAL CONSIDERATIONS The simulation received a general positive feedback from the Rome controllers. The concept was considered interesting and potentially useful for distributing delays and optimising the inbound traffic management. Full details can be found in Reference 8.

The idea of involving the area controllers in the management of the inbound traffic was appreciated as a means to guarantee an orderly and expeditious inbound traffic flow and to re-distribute the overall workload.

The cooperative nature of the tool was generally appreciated.

Some concerns were raised referring to the acceptability and suitability of this concept in the specific environment of Rome ACC due to two principal reasons: the fact that the RTS was clearly focussed on the arrival traffic management and some important aspects of arrival traffic management were missing (holdings, contextual traffic etc).

6.2 IMPACT ON CONTROLLERS WORK Perceived workload

According to the controllers’ opinion collected by means of debriefs, interviews and questionnaires the introduction of AMAN, with the proposed and refined working methods and the proposed display, resulted in an acceptable level of controller workload.

The working methods were considered likely to slightly increase the overall area controllers’ workload, but this increase was considered acceptable because:

• it corresponded to a decrease of the controllers workload in the approach sectors

• it increased the quality of the work, particularly with reference to the arrival traffic management

Increased planner empowerment as a consequence of new working concepts is often expected to lead to a balancing of the PC and TC workload. In these exercises the PC workload did slightly increase but this did not result in a reduced workload for the TC. The slight increase of the perceived workload was accepted by the area controllers as a consequence of their involvement in the arrival traffic management and the increased quality of the overall work.

Impact on teamwork

AMAN had a positive impact on the controllers’ teamwork. The cooperative nature of the tool requires an increase of both inter and intra-sector teamwork.

The intra-sector teamwork concerned the cooperation of PC and TC of the same sector increased since the PC supported the TC in monitoring and dealing with the AMAN advisories.

The inter-sector teamwork concerns the cooperation between controllers managing different sectors. It was largely unaffected by the introduction of the AMAN. Impact on situation awareness

The results revealed that the introduction of AMAN provided limited advantages in terms of situational awareness with respect to the current situation of Rome ACC



The introduction of the SM, the involvement of the area controllers in the arrival traffic management and the increase of the inter and intra-sector cooperation had lead to the expectation that the overall situational awareness would increase but limits were identified in the situational awareness of both SM and area controllers.

• the SM situational awareness was limited to the inbound traffic,

• the area controllers picture of the inbound traffic was limited to the traffic in their own sector.

Impact on trust

The controllers had a quite high level of trust in the overall system (the combination of AMAN concept, AMAN display and controller roles and working methods)

An important issue concerned how AMAN could deal with situations such as bunching of traffic flows which today controllers keep together for operational purposes but which would be broken up by AMAN when constructing an optimised sequence (see 7.4).

Impact on job satisfaction

The RTS results revealed a quite high level of controllers’ job satisfaction.

This job satisfaction was particularly evident in the area controllers, who appreciated the idea of being involved in the arrival traffic management and thus contributing to workload reduction in the approach sectors. They were also convinced that a better quality of the overall work was observable as result of the introduction of AMAN, with the proposed/refined working methods and display.

The job satisfaction of the approach controllers was less clear. The introduction of AMAN implies a support for the approach controllers but also a limitation of their freedom of initiative. Impact on perceived flexibility

The RTS results revealed a quite low level of controllers’ perceived flexibility.

According to the controllers’ opinion the overall system that is the combination of AMAN concept, AMAN display and controller roles and working methods, was rigid and did not allow them to deviate from the pre-defined rules and working methods.

6.3 IMPACT ON SAFETY, ECONOMIC AND CAPACITY ISSUES. The primary objective of the simulation due to the maturity of the concept related to the Human Commitment and Involvement and Usability High Level Objectives. Validation of Safety, Capacity and Economics and Environment was outside the scope of this initial AMAN work. Nevertheless some issues were reported under these topics. Safety The low level of maturity of both the working procedures developed for the tool and the configuration of the tool itself meant that it was too early to conduct any significant evaluation of the safety implications of introducing AMAN. A safety session following the SAFLEARN (see Reference 11) procedures was conducted during the third week of the simulation. The early stage in the development of both working methods and tool and the lack of relevant operational reports meant that this session did not identify any specific safety issues. Initial thinking was that future work should focus on issues associated with workload shift, reduction in complexity and standardisation of the arrival management tasks.



Economic Economic and environmental benefits would be expected to come from, among other factors more efficient delay absorption, shorter routes and more continuous descent profiles. While the working methods reduced some last minute tactical vectoring some controllers thought that the resulting flight profiles (often early descent, vectoring and some use of speed control) were not sustainable from either an operational or economic/environmental view. The issue of how delay should be managed was a contentious issue which requires future work in particular involving pilots and airline companies. This question is obviously closely linked to the desired working methods and resulting sector configuration.

Capacity

Capacity issues in terms of AMAN concern en-route or approach sector capacity, SM capacity and/or runway capacity2. It is the latter which is the primary concern. In general the controller uses his experience and skill to ensure that he constructs a sequence (and achieves the minimum separation compliant with safety needs) which, as often as possible, makes the best use of the runway. AMAN could be expected to influence this by presenting the approach controller with a smoother ‘less complicated’ arrival stream. This change is expected to bring the practical achievable runway capacity closer to the theoretical on a sustained basis. The constraints of the simulation (in particular the absence of TNR), were such that it was not possible to test this hypothesis. Nevertheless a number of positive indications were observed which could support this idea.

Controllers felt the traffic arrived, in general in a smoother, more organised way, they required less tactical intervention to achieve the desired separations and the arrival management task became, in some respects, more standardised. Future work should investigate in more detail this aspect of AMAN.

2 By runway capacity we use the definition of the average number of aircraft per hour which can land for a defined level of delay on the runway during a sustained busy period.



7. FINDINGS ASSOCIATED WITH THE CONFIGURATION AND FUNCTIONALITY OF AMAN

This simulation was the first real test of the arrival manager configured and used extensively on the ESCAPE platform. In cases where arrival management tools have been introduced into an operational environment it has taken many months, if not years, to develop and refine the operational use. AMAN has many configuration parameters by which the tool can be parameterised to meet the precise operational needs. These can affect things such as sequence and advice stability, rate and time of automatic updates etc. Such refinement was obviously outside the scope of the RTS and the approach taken was to make a few reasonable assumptions on appropriate configuration parameters and to use these as the basis for initial evaluation. This section reports on some of the issues arising including the configuration of the AMAN tool, the impact of the choice of airspace, questions related to the allocation of delay and some specific operational aspects. (see also reference 9)

7.1 AMAN CONFIGURATION AND STABILITY ISSUES. There is a compromise necessary between delay stability in en-route airspace and sequence stability in approach. In essence what is wished for is the following:

• Create a stable plan (with an accurate, predictable RTO and therefore stable TTL for an aircraft over an IAF) at a certain time horizon.(to be determined). In general the position in the sequence for a flight in an upstream sector is less important.

• Present this (or give via a SM position) to the en-route controller so that he acts preferably

only once on the TTL.

• Implement this plan in an efficient, economic and environmentally satisfactory way.

• Deliver traffic to the APP controller, respecting the times (TTL =0), in a way that enables him to optimize the final phase of the flight respecting the RTA.

• At IAF bypass the task of AMAN can be considered finished.

Currently the simulation platform does not adequately support this concept. The simulation suffered from the inadequacies of the Trajectory Prediction algorithm that was used in the ESCAPE platform and as a result AMAN advice throughout the simulation was unstable. There were two problems with the TP. The first is due to inaccurate initial ETO calculation. This results in the aircraft initially being inserted into the wrong position in the sequence with TTL advice based on estimates which are known to be wrong. The second is that there are often many subsequent updates and revision of this ETO during the progress of the flight triggering recalculations of both the sequence and the advice. Both effects can lead to the SM making manual updates to correct the sequence, creating additional workload.



Advisories instability is increased by the fact positions in the sequence are frozen too early (excluding events such as new insertion of flights or ETO changes of more than 2 or 3 minutes which are current thresholds for re-sequencing). If a flight is within the frozen area but has not passed its IAF, and if the flight is given a new ETO (e.g. the route is changed from CWP), the flight is re-scheduled (RTO change, or TTG/TTL advisory change), but is never re-sequenced automatically, whatever the value of ETO change. If the flight is delayed, following flights will be delayed accordingly, and a manual intervention is required to correct the sequence. One solution would be to allow re-sequencing following a large ETO change even in the frozen part but this was not tested during the simulation Another problem which can lead to advisories instability is that the effect of speed changes are only calculated immediately by ESCAPE TP if the flight is in cruise phase. If not, a new ETO is not calculated, and the ETO will be slightly and regularly changed, via conformance monitoring.

7.2 THE IMPACT OF THE CHOICE OF AIRSPACE IAF Bypass The sectorisation and IAFs need to be designed to benefit from the introduction of AMAN.

A consequence of the choice of sectorisation in the simulation was that IAFs were in the centre of the UNR sector.

The UNR PC (in cooperation with the SM) tended to intervene on the final part of the sequence in order to clear away the delays assigned to the first a/c in the sequence, and consequently reduce the delays assigned to the rest of the traffic. In order to achieve maximum runway capacity, automatic scheduling before preferred arrival time was replaced by a manual rescheduling (e.g. IAF bypass) from the controller, in case of gaps in the sequence. During the RTS, ATCOs usually succeeded in reducing these sequence gaps by performing Go Direct to MIKSO and GOLPO (direct routes to the FAF). This also raised display issues. When the controller performs an IAF bypass a new IAF (IAF’) is calculated by an orthogonal projection of the initial IAF on the new trajectory (closest point of the IAF on the new trajectory). This point, IAF’, is the new AMAN sequencing point. The displayed IAF sequence is then a mix of flights sequenced on the “normal” IAF, and on projected IAFs. Opinions on this question were divergent among controllers some of whom preferred to remove these flights from IAF sequence. This issue is still open. Time to Gain information The question of AMAN allocating Time to Gain information became particularly sensitive as controllers worked on achieving appropriate final spacing. Automatic rescheduling which would involve allocating Time to Gain (TTG ) was not suitable for 2 main reasons:

• TTG advice is only based on the BADA maximum acceleration profile, i.e. a flight may be given a TTG only if its current speed is lower than maximum speed and capabilities of route shortcuts are not taken into account.

• A TTG may be given to a flight only in case of consistency between P4D TP and ESCAPE

TP which was very rare during a simulation.

The way TTG advisories have to be managed is still an open issue and was not studied during the simulation.



A work around to avoid unwanted TTG was to only allow “insert after” inputs (and not “insert before” at the SM position. This however only guaranteed that there will be no TTG advisory immediately after the re-sequencing. Internal processing meant that occasionally the flight was “stuck” to the preceding flight (e.g. if a longer route is given to the flight, it may be re-scheduled with a TTG).

7.3 ALLOCATION OF DELAY Delay History The current mode of operation of AMAN does not take into account ‘Delay History’. The initial preferred arrival time (ie the ETO as calculated with the initial FPL) is lost and during a run the RTOs at the end of the flights can be very different from the RTOs at the beginning3. Optimisation is based on the current ETO (current delays), not on the initial ETO (initial delays). This means that AMAN is equitable as regards delay based on the current situation and does not take into account the fact that aircraft may already have experienced delay for arrival management purposes. The consequence can be paradoxical, the more the controller acts early on a flight which is given a TTL advisory, so as to try to match its RTO, the more the flight is penalised compared to other flights. Under such circumstances there is no incentive for aircraft to absorb delay early and does not meet one of the requirements of improving predictability. This situation was made worse in the simulation by the unnecessary updates caused by the TP. Another associated issue is the fact AMAN has several delay optimisation criteria which it can use when determining a sequence. However these criteria are only taken into account on initial determination of the sequence and are subsequently disregarded. This means that in a situation with many re-sequencing and updates ‘optimisation’ is much reduced. Delay Sharing The simulation was initially intended to look at formalised delay sharing. By this is meant that the AMAN tool calculates delay (TTL) for each flight and distributes it among successive sectors. Each sector gets a maximum time to absorb, depending on its shape and size. Two delay sharing modes are possible: “as late as possible” and “evenly spread”. During the preparation phase it was discovered that the way delay sharing is currently implemented was not suitable. The algorithm did not take into account the fact that a particular sector had achieved the necessary reduction of delay for a particular sector and that on ETO update delays were reallocated to the concerned sector. Thereafter it was proposed to define delay sharing rules which were informal and implicit in the working methods. The current size and shape of sectors such as NW significantly affected the way that such delay could be absorbed. A preferred approach would have been to apply small speed reductions but this was in general impossible due to the small size of the sectors.

3 Analysis showed that this could be as much as 3 minutes over a flight duration of 40 minutes

EUROCONTROL Summary Report on the EVP AMAN Rome Real-Time Simulation 2004 7.4 SPECIFIC OPERATIONAL ASPECTS Bunching In current operations it is the generally preferred practice when there are groups (bunches) of aircraft notably from the sea for the controller to treat the bunch as a single group. This practice, while not being entirely equitable with other traffic arriving, say, from the North, makes operational sense as it enables controllers to handle the traffic more efficiently and avoids complicated crossing manoeuvres. AMAN did not support this mode of operation and produced sequences which mix traffic from the bunch with other traffic. In the simulation the controllers were asked to try and respect the AMAN sequence with obvious operational problems. It may be necessary to modify the AMAN algorithms to deal with this issue. Operational view vs AMAN view ATCOs sometimes reported that the AMAN sequence was not consistent with the radar view. The problem is mainly due to ETO changes. An automatic re-sequencing happens when a flight is given an ETO change larger than a configured threshold. This can be due to inaccurate initial ETOs (TP problem) or subsequent changes. A first solution is to reduce the thresholds for re-sequencing. This would improve the consistency between the sequence and the radar view, but this would also increase sequence instability. In practice it may be desirable to reduce the automatic thresholds or, better, introduce a “really free part” of the sequence (upstream sectors), where each ETO change would lead to re-sequencing. This second solution could be to use a configuration with an extended TMA. (a facility introduced after an EVP request, but never tested). This distinguishes 2 areas, one far away the runway, where re-sequencing is allowed according to the chosen thresholds and an area around the runway, e.g. 20 minutes before the runway, where automatic re-sequencing is not allowed. With this configuration, small thresholds could be set keeping complete stability for the sequence near the runway, and allowing many re-sequencings in upstream sectors, where stability is not essential. This would mean that there would be two different thresholds: e.g. 2 or 3 minutes in downstream sector, where we need sequence stability and 10 or 20 seconds in upstream sectors, where sequence stability is not crucial. This would require changes to the tool. A third solution could be to keep the history of ETO changes at AMAN level. This would allow re-sequencings when the total ETO change (the sum of the successive small ETO changes since the initial ETO which was the reference for the choice of the position of the flight within the sequence) is higher than the threshold. Time vs distance separation An important operational point which was encountered during the simulation was that AMAN requires the controller to work in a way different from his current standard practice. AMAN behaviour is based on time information, whereas ATCOs work is based mainly on distance information (separation between flights). Rome controllers sometimes commented on AMAN indicated separations larger than they thought appropriate. The separation ensured is based on minimum separation table in NM. This is transformed into time distance using speed tables. In fact, the overall philosophies are not the same. Rome controllers are used to ensure a minimum separation of 5NM between successive flights within en-route sectors and to increase time separation when flights approach the runway, whereas the AMAN advisories are computed in order to ensure the minimum separation of 3NM as soon as possible.




8. CONCLUSIONS AND RECOMMENDATIONS

8.1 CONCLUSIONS The simulation was a first look at the introduction of an AMAN into a EATM working environment using as target the Rome airspace. It achieved the first integration of an AMAN tool into the ESCAPE platform and identified the impact of the trajectory prediction on AMAN and the consequences and possible solutions to the use and configuration of the tool itself. It provided a first evaluation of the AMAN EATM interface in a simulation and a usability study has highlighted problems and a possible redesign process. For ENAV it provided useful first feedback on how an AMAN tool could improve arrival management and provided a first look into proposed working methods, in particular for a proposed Sequence Manager position. The simulation was conducted with the current airspace and highlighted the consequences of airspace design on the use of AMAN (the AMAN configuration needs significant work to enable the tool to better support some preferred operational procedures). Controllers generally felt that it significantly increased the cooperation between en-route and approach and in general, provided a more ordered flow to the IAFs. The support offered by AMAN in identifying at an early stage a preferred sequence and the delay necessary to organise the traffic resulted in a more orderly flow of traffic to the IAFs. Although there is much work to be done in defining the exact new roles and responsibilities the focus on the controllers working as a team to manage the arrivals and to be less ‘sector’ focused was greatly appreciated. Future work in Gate to Gate WP3 (ENAV ) and WP4 (EEC) simulations will evaluate new airspace, different IAFs, the HMI Timeline issue etc. and will build on the experience gained from this first simulation.

8.2 RECOMMENDATIONS FOR SSP BUSINESS AREA The following recommendations are proposed for future work:

1. Undertake a follow-up study to look at the issues involved in Delay sharing

2. Undertake a study looking at decision support tools integration issues (including AMAN, MTCD)

3. Follow up Usability findings

4. Revise the Operational concept including findings from this study and other AMAN

work.

5. Conduct a study looking at the issues associated with the operational use of AMAN

6. Conduct a study comparing the advantages and disadvantages of Timeline and EATM HMI.


8.3 RECOMMENDATIONS FOR ENAV The following recommendations are proposed:

1. ENAV form a working group to identify precisely the objectives and desired benefits from the introduction of an arrival management tool into Rome ACC.

2. An operational group review and propose:

• The airspace configuration, sectorisation and routings,

• The controllers’ methods of working, both sequence management and sector,

• The configuration and functionality of the arrival management tool. 3. A program of studies are planned looking particularly at

• New airspace design including the procedures for two runway operations

• The impact on TN

• The Sequence Manager position and working methods

• The requirements and procedures for holding.

4. A wider discussion with airlines and airport authorities is needed to confirm requirements

and best strategies for delay sharing.




ANNEXES


Page left intentionally blank




ANNEX 1 - DOCUMENTATION

1. Facility Specification Part One Operations, G Matrella, October 23rd 2004

2. Facility Specification Part Two Technical,A Wyart, October 8th 2004

3. Facility Specification Part Three Validation Plan, P Lanzi, S Tiberia, P Battino, A Drew, October 15th 2004

4. HMI Handbook EVP AMAN RTS Rome, Oct/Nov 2004

5. AMAN Rome Real Time Simulation Controller Handbook, A Drew, October 12th 2004

6. EVP Report on Baseline Data Collection in Rome ACC, P Lanzi, M Petrella, July 28th 2004

7. EVP AMAN RTS Analysis Results, S Tiberia, 18th February 2005

8. Report on Human factors and Usability assessment of EVP AMAN Rome, P Lanzi, May

27th 2005

9. AMAN Issues Rome RTS, R Sagon, November 2004

10. AMAN RTS Simulation Technical Report, A Wyart, October 15th 2004

11. SAFLearn Final Report for AMAN, D Bonini, April 2005


Page left intentionally blank




ANNEX 2 AIRSPACE MAP



Documents

SUMMARY REPORT OF THE EVP AMAN ROME REAL TIME … · 1.3 ARRIVAL MANAGER AMAN AMAN is a Decision Support Tool (DST) and provides the controller with information on a calculated sequence