022 TAAM Operational Evaluation

EUROPEAN ORGANISATIONFOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL EXPERIMENTAL CENTRE

TAAM Operational Evaluation

EEC Report N° 351

Project SIM-S-E8

Issued: August 2000

The information contained in this document is the property of the EUROCONTROL Agency and no part shouldbe 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.

EUROCONTROL

EATCHIP TaskSpecification

-

Project Task N° Sponsor Period

Author Date

SIM-S-E8 - October 99 / June 00

Pages Figures Tables Appendix References

8/00 X + 79 33 12 9 9

(a) Controlled by: . . . . . . . Simulation Service Manager(b) Special Limitations: . . . None(c) Copy to NTIS: . . . . . . . YES / NO

TAAM, RAMS, SIMMOD, Controller workload, Fast -Time simulators, Airspace modelling, Airport modelling.

An operational evaluation of the TAAM (Total Airspace and Airport Modeller) fast-time simulation tool wasconducted in EUROCONTROL agency between October 1999 and May 2000.

The overall objective was to make an operational assessment of the TAAM capabilities to fulfil EUROCONTROL requirements to model the operations of airports and ATM issues associated with airspace.

The overall evaluation project was divided into 2 sub-projects: en-route/TMA sub-project, conducted at theEUROCONTROL Experimental Centre and Airport sub-project, conducted at EUROCONTROLHeadquarters.

The TAAM simulator has been found efficient. Auxiliary tools to process the output data should be availa-ble in order to use all the data generated by the simulator.

REPORT DOCUMENTATION PAGE

Reference: Security Classification: EEC Report N° 351 Unclassified

Distribution Statement:

Descriptors (keywords):

Abstract:

TITLE:TAAM Operational Evaluation

Originator: Originator (Corporate Author) Name/Location:EUROCONTROL Experimental CentreCentre des Bois des BordesB.P. 15FR - 91222 Brétigny-sur-Orge CEDEXTel.: +33 (0)1 69 88 75 00Fax.:+33 (0)1 60 85 15 04

EEC - OPS(Real-time Simulation Operations)

Louis SILLARDFrançois VERGNE

Bruno DESART

Sponsor: Sponsor (Contract Authority) Name / Location:

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

EUROCONTROL Experimental CentrePublications Office

Centre des Bois des BordesB.P. 15

91222 - BRETIGNY-SUR-ORGE CEDEXFrance


Project SIM-S-E8 - EEC Report n° 351 V

In the context of airport and airspace modelling the EUROCONTROL agency has performed anoperational evaluation of the TAAM (Total Airspace and Airport Modelling) fast-time simulatordeveloped by the Preston Group. This evaluation took place between October 1999 and May2000.

The overall objective of this evaluation was to make an operational assessment of the TAAMcapabilities to fulfil EUROCONTROL requirements to model the operations of airports and ATMissues associated with airspace.

Two evaluations teams were allocated to this EEC project, one from EUROCONTROLHeadquarters for the airport part and one from the Experimental Centre for the En-route/TMA part.The evaluation project started in October 99 with a 10 day training course provided by the PrestonGroup in Brétigny to familiarise the staff allocated to the project to the use of TAAM. Then, the 2teams worked on their own sub-projects to build the scenarios which were to be simulated duringthe evaluation. An advanced training session took place in February 2000 during 5 days inBrussels to demonstrate advanced functions of the TAAM simulator to the people involved in thetwo sub-projects.

The team in charge of the airport sub-project conducted it’s evaluation of the simulator while doinga simulation for the Brussels airport authorities (BIAC – Brussels International Airport Company).The team in Brétigny in charge of the en-route TMA sub-project redid one exercise of the CzechRepublic fast-time simulation run in 1998 using RAMS simulator (EEC F24 project). For both sub-projects, other exercises were added in order to have a more comprehensive view of theTAAM capabilities and of it’s potential usage for doing R & D simulations.

The EUROCONTROL teams were assisted during the evaluation by TAAM experts contracted bythe Preston Group to an external company to help in the use of the system. This assistance wentuntil the end of the evaluation in the Headquarters while it was stopped during December 99 forthe EEC team.

A contract, taking into account the agreed procedures between EUROCONTROL and the PrestonGroup was signed on 21 September 1999.

SUMMARY

EUROCONTROL

TABLE OF CONTENTS

EUROCONTROL TAAM Operational Evaluation

Project SIM-S-E8 - EEC Report n° 351VI

ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VIII

1. INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.OBJECTIVES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

3.AIRPORT SUB-PROJECT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.1. . . . . . . . . Airport Evaluation Sub-Project Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.1.1 . . . . . . Sub-Project Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23.1.2 . . . . . . Evaluation Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

3.2. . . . . . . . . Baseline Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.2.1 . . . . . . Collect and Compile Baseline Airport Operations Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3.2.1.1. . . . . Digitizing Airport Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33.2.1.2. . . . . Modifying and Enhancing Airport Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43.2.1.3. . . . . Importing Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4A) . . . . . . . Traffic Schedule Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4B) . . . . . . . Aircraft Classification, Aircraft type and Market Segment Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5C) . . . . . . . Aircraft Performance Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5D) . . . . . . . Operational Rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6E) . . . . . . . Sector Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.1.4. . . . . TAAM Facilities for Data Entry and Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7A) . . . . . . . Project Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7B) . . . . . . . The Interactive Data Input System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8C) . . . . . . . IDIS Graphics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9D) . . . . . . . Individual Airport Data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10E) . . . . . . . Validation by Airport Operations Experts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.2 . . . . . . Perform Baseline Model Runs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2.1. . . . . Simulation Run Performance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.2.2.2. . . . . Graphical Simulation Run Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2.3. . . . . Raw Output Data Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2.2.4. . . . . Evaluation of the Report Presentation Facility (RPF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.2.3 . . . . . . Simulation Post-Processing Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.3.1. . . . . Baseline Results vs CFMU Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.2.3.2. . . . . Simulated vs Measured Runway Occupancy Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.2.3.3. . . . . Connecting Flights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2.3.4. . . . . Baseline Results vs Airport Experts’ Judgement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3. . . . . . . . . Sensitivity Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.1 . . . . . . . TAAM Stability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3.2 . . . . . . . Traffic Increase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4. . . . . . . . . Airport Management Improvement Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.4.1 . . . . . Runway Selection Strategy and Use of an Additional Existing Runway for Departures . . . 253.4.2 . . . . . . New Taxiway and Departure on 25L . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.4.3 . . . . . . Runway Extension Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.4 . . . . . . Additional Parking Positions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4.5 . . . . . . Environmental Procedures - TAAM-INM Integration Evaluation . . . . . . . . . . . . . . . . . . . . 293.4.6 . . . . . . Some Future Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.5. . . . . . . . . SIMMOD-TASIME vs TAAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.1 . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.2 . . . . . . Brief Description of SIMMOD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303.5.3 . . . . . . Simulation Outputs comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.5.4 . . . . . . Technical comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.5.5 . . . . . . Effort consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.EN-ROUTE & TMA PART . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1. . . . . . . . . Description of the En-route/TMA sub-project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.1 . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.2 . . . . . . Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.3 . . . . . . Typical Simulation request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.4 . . . . . . Typical Simulation results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.4.1. . . . . Number of flights per sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.4.2. . . . . Sector working times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.1.4.3. . . . . Controller workload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.4.4. . . . . Analysis of conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.4.5. . . . . Penalties on the flights (such as delays) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.4.6. . . . . Capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37


Project SIM-S-E8 - EEC Report n° 351 VII

EUROCONTROL

French Translation (green pages) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

Green pages: French translation of the summary, the introduction, objectives and conclusions

Pages vertes : Traduction en langue française du résumé, de l’introduction, des objectifs et des conclusions

4.1.5 . . . . . . . Simulated projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.1.5.1 . . . . . . Base organisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

A) . . . . . . . F24 project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38B) . . . . . . . Reference project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.1.6 . . . . . . The CTL (Control) project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.7 . . . . . . The TMA project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.8 . . . . . . The R&D project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.1.8.1. . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.8.2. . . . . Contents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.1.9 . . . . . . The military project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2. . . . . . . . . Running a project using TAAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.1 . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.2.2 . . . . . . Data preparation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2.2.1. . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.2.2. . . . . Traffic samples (F24 CTL R&D and Military projects). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.2.3. . . . . Flight level restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.2.4. . . . . Entry times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.2.5. . . . . Airspace design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.2.6. . . . . Airspace operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.2.7. . . . . Software aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.2.2.8. . . . . Conclusion data preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2.3 . . . . . . Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.3.1. . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.3.2. . . . . Conflict detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.2.3.3. . . . . Conflict resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.3.4. . . . . Speed of the system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

4.2.4 . . . . . . Analysis and results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2.4.1. . . . . General results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A) . . . . . . . Number of flights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45B) . . . . . . . Sector working times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45C) . . . . . . . Controller workload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46D) . . . . . . . Analysis of conflicts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46E) . . . . . . . Penalties on the flights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46F) . . . . . . . Capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.2.4.2. . . . . CTL Project particularities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.2.4.3. . . . . TMA project particularities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.4.4. . . . . R&D project particularities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.2.4.5. . . . . Military project particularities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.2.4.6. . . . . Other projects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3. . . . . . . . . RAMS and TAAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.1 . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.2 . . . . . . Number of flights per sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.3.3 . . . . . . Sector working times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.3.1. . . . . Working time modelling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.3.3.2. . . . . RAMS TAAM workload distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.3.4 . . . . . . Controller workload. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.3.4.1. . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 534.3.4.2. . . . . Global workload comparison. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3.5 . . . . . . Summary of RAMS TAAM compared results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5. GENERAL CONCLUSIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.1 . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 565.2 . . . . . . . Number of flights per sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Appendix 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59Appendix 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60Appendix 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61Appendix 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Appendix 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Appendix 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64Appendix 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Appendix 8 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66Appendix 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

ACC . . . . . . . . . . . . Area Control CentreAMOC . . . . . . . . . . ATFM MOdelling CapabilityANS . . . . . . . . . . . . Air Navigation Services (Czech Republic)ATC . . . . . . . . . . . . Air Traffic ControlATCC . . . . . . . . . . . Air Traffic Control CentreATFM . . . . . . . . . . . Air Traffic Flow ManagementATM . . . . . . . . . . . . Air Traffic ManagementCDE . . . . . . . . . . . . Common Desktop EnvironmentCFMU . . . . . . . . . . . Central Flow Management UnitCVSM . . . . . . . . . . . Conventional Vertical Separation MinimaCTL . . . . . . . . . . . . (Air Traffic) ControlDFS . . . . . . . . . . . . Deutsche Flugsicherung GmbHEEC . . . . . . . . . . . . EUROCONTROL Experimental CentreEMEU . . . . . . . . . . . EUROCONTROL Military Expert UnitETA . . . . . . . . . . . . Estimated Time of ArrivalETD . . . . . . . . . . . . Estimated Time of DepartureFMS . . . . . . . . . . . . Flight Management SystemGAT . . . . . . . . . . . . General Air TrafficGTOOL. . . . . . . . . . Graphical ToolIDIS . . . . . . . . . . . . Interactive Data Input DisplayIFR . . . . . . . . . . . . . Instrument Flight RulesINM. . . . . . . . . . . . . Integrated Noise ModelMSP . . . . . . . . . . . . Multi Sector PlanningOAT . . . . . . . . . . . . Operational Air TrafficPMP . . . . . . . . . . . . Project Management PlanRAMS . . . . . . . . . . . Reorganised ATC Mathematical SimulatorR&D . . . . . . . . . . . . Research and DevelopmentRPF . . . . . . . . . . . . Report Presentation FacilityR/T . . . . . . . . . . . . . RadiotelephonyRTF . . . . . . . . . . . . Radio TelephonyRVSM . . . . . . . . . . . Reduced Vertical Separation MinimaSID . . . . . . . . . . . . . Standard Instrument Departure (route)SIM . . . . . . . . . . . . . Simulation ProgramSIMMOD . . . . . . . . . US Federal Aviation Administration’s Airport and Airspace Simulation ModelSTAR . . . . . . . . . . . Standard Arrival RouteTAAM . . . . . . . . . . . Total Airport and Airspace ModellerTMA . . . . . . . . . . . . Terminal Manoeuvring AreaTPG . . . . . . . . . . . . The Preston GroupVFR . . . . . . . . . . . . Visual Flight Rules

ABBREVIATIONS


Project SIM-S-E8 - EEC Report n° 351VIII


Project SIM-S-E8 - EEC Report n° 351 IX

REFERENCES OF THE DOCUMENT

PROJECT TEAM

EUROCONTROL

Ref. 1 . . . . . . . . . . . . . . . . . . . . . . TPG, TAAM Simulation Project PlanningRef. 2 . . . . . . . . . . . . . . . . . . . . . . TPG, TAAM Beginner’s GuideRef. 3 . . . . . . . . . . . . . . . . . . . . . . TPG, TAAM Reference Manual Ref. 4 . . . . . . . . . . . . . . . . . . . . . . TPG, TAAM Practical Guide Ref. 5 . . . . . . . . . . . . . . . . . . . . . . EUROCONTROL, TAAM Evaluation Log BookRef. 6 . . . . . . . . . . . . . . . . . . . . . . TPG, Aircraft Performance Data, Using in TAAM,

. . . . . . . . . . . . . . . . . . . . . . . . . . Draft Proposal, Nov. 1999Ref. 7 . . . . . . . . . . . . . . . . . . . . . . TAAM Operational Evaluation Project

. . . . . . . . . . . . . . . . . . . . . . . . . . Management Plan (PMP-TAAM)Ref. 8 . . . . . . . . . . . . . . . . . . . . . . TAAM Operational Evaluation Process Document.

. . . . . . . . . . . . . . . . . . . . . . . . . . (En-route TMA)Ref. 9 . . . . . . . . . . . . . . . . . . . . . . TAAM Operational Process Document (Airports) Contract . . . . . . . . . . . . . . . . . . . . C2.2109E/99 Project Management Plan. . . . . . . PMP-TAAM 8/9/1999

Name . . . . . . . . . . . . . . . . . . . . . . Function

Bernard BEDETTI . . . . . . . . . . . . Hardware expert

Bruno DESART . . . . . . . . . . . . . . Airport Operation Expert

Béatrice GROS . . . . . . . . . . . . . . Software Expert

Donald HUGHES . . . . . . . . . . . . . Airport Task Co-ordinator

Jean-Luc JANSZEN . . . . . . . . . . F/T Simulation Expert

Mike LOGHIDES . . . . . . . . . . . . . Airport Sub-Project Manager

Louis SILLARD . . . . . . . . . . . . . . Project Manager & En-Route TMA Sub-Project Manager

François VERGNE. . . . . . . . . . . . F/T Simulation Expert

Project SIM-S-E8 - EEC Report n°351X


Project SIM-S-E8 - EEC Report n°351 1

1. INTRODUCTION

An operational evaluation of the TAAM (Total Airspace and Airport Modeller) fast-timesimulation tool was conducted in the EUROCONTROL agency.

The overall evaluation was divided into 2 sub-projects:

! En-route/TMA sub-project conducted at the Experimental Centre;

! Airport sub-project, conducted at EUROCONTROL headquarters.

A first training session took place at the EEC during October 1999 and an advanced session in February 2000 in Haren.

This document contains an overview and the main results of the evaluation. The conclusions and recommendations are incorporated in this document. Nevertheless, fordetails relating to particular aspects, it is suggested to refer to the TAAM OperationalEvaluation Process Document, Part 1 (Ref 5) and Part 2 (Ref.9).

The TAAM evaluation project has started just after the release of TAAM+ by the PrestonGroup. Two consecutive versions (TAAM V1.0S and V1.0.1S) have been used during theevaluation. Four licences were provided by the Preston Group. Two were used for the airport evaluation in HQ and two others at the EEC for the en-route/TMA part.

2. OBJECTIVES

The overall objective was to make an operational assessment of the TAAM capabilities tofulfil EUROCONTROL requirements to model the operations of airports and ATM issuesassociated with airspace.

Specific objectives were to compare TAAM capabilities with existing tools used by EUROCONTROL, and explore TAAM capabilities to address ATM R & D issues.

The comparative tools currently used are SIMMOD for airport studies and RAMS(Reorganised ATC Mathematical Simulator) for En-route/TMA simulations.

The evaluation of architecture and source code were not within the scope of this project.

TAAM Operational Evaluation EUROCONTROL

Project SIM-S-E8 - EEC Report n°3512

3. AIRPORT SUB-PROJECT

3.1 AIRPORT EVALUATION SUB-PROJECT OVERVIEW

3.1.1 Sub-Project Definition

The airport evaluation sub-project has been defined in three separate phases:

! Baseline simulation of a selected airport;

! Sensitivity tests on the model;

! Simulation runs for selected airport improvements.

The Brussels airport was selected as the basis for the study, due to the proximity toEUROCONTROL and the willingness of the Airport Authority (BIAC – BrusselsInternational Airport Company) to co-operate in the process of data collection and scenario refinement.

A study related to runway capacity assessment was recently conducted by EUROCONTROL on behalf of the Belgian Ministry of Transport. This activity was considered a success and has created a good working relationship between the projectteam and the Supervisory Team that included representatives of BIAC, Belgocontrol andIATA. It has also meant that some of the data used for the study was immediately available for input to the TAAM evaluation.

More detail on the three individual phases, including the work breakdown and the sub-activities that have been conducted, is provided in the following sections.

3.1.2 Evaluation Team

The Airport evaluation sub-project team was as follows:

- Mike Loghides (DSA/AOP): Airport evaluation sub-project manager. Has overall respon-sibility for the sub-project.

- Bruno Desart (DSA/AOP): Airport operations expert. Main EUROCONTROL projectteam member and responsible for interfacing to airport authorities as and when necessary for project needs.

- Don Hughes (DSA/AMN): Airport evaluation sub-project coordinator. Responsible forproject progress, planning and report production.

- Michael Haklitch (Crown Consulting, Inc.): Airport operations and TAAM simulationexpert.

- Jean-Luc Janszen (EEC): Airport simulation expert. Responsible for conducting theSIMMOD study of Brussels airport for comparison with the TAAM results.

Support has been provided by the Preston Group, especially with regard to TAAM hardware/software installation, set up and training.

Before commencement of the study, only Michael Haklitch had previous experience ofundertaking airport studies using TAAM. A two week introductory training course wasgiven to the rest of the project team before work on the study proper was started. Thiscourse gave an overview of TAAM functionality and features and provided a lead-in to project activities.

The actual TAAM modelling work has been conducted by Bruno Desart and MickeyHaklitch, supported by Don Hughes for airspace related activities (TMA, SID’s, STAR’s).



3.2 BASELINE SIMULATION

The purpose of the baseline simulation is to validate to what degree TAAM is able to provide a realistic model of airport operations, as they exist today. This can be done in twoways:

1. To model a predefined operational day and compare the results with statistics andrecords made available by the airport.

2. To demonstrate the model to staff from BIAC and Belgocontrol (controllers, supervisorsand airport officials) and gain their opinion of whether or not their normal operations arebeing correctly modelled.

Both of these methods were used for the Airport evaluation.

3.2.1 Collect and Compile Baseline Airport Operations Data

The baseline simulation was constructed using 17 September 1999 as the model opera-tional day. This was the busiest day at the airport during 1999, and was the first day in theairport’s history that more than 1000 movements were handled.

Baseline data was collected as follows:

Data. . . . . . . . . . . . . . . . . Source. . . . . . . . . . . . Input

Airport Layout. . . . . . . . . . AIP + BIAC. . . . . . . . . digitisedTaxiways . . . . . . . . . . . . . AIP . . . . . . . . . . . . . . . GTOOLRunways . . . . . . . . . . . . . BIAC . . . . . . . . . . . . . GTOOLGates . . . . . . . . . . . . . . . . BIAC . . . . . . . . . . . . . GTOOLRunway usage rules . . . . . Belgocontrol . . . . . . . . IDISTaxiway usage rules . . . . . BIAC & Belgocontrol . . IDISGate/parking usage rules . BIAC . . . . . . . . . . . . . IDISBase traffic sample . . . . . . CFMU. . . . . . . . . . . . . converterFlight linking . . . . . . . . . . . BIAC . . . . . . . . . . . . . converterGate allocation . . . . . . . . . BIAC . . . . . . . . . . . . . converterAircraft performance data . TAAM . . . . . . . . . . . . . n/aSID’s . . . . . . . . . . . . . . . . AIP . . . . . . . . . . . . . . . IDISSTAR’s . . . . . . . . . . . . . . . AIP . . . . . . . . . . . . . . . IDISTMA definition . . . . . . . . . AIP/CANAC . . . . . . . . GTOOLHolding positions . . . . . . . CANAC

Comments on the data preparation process are as follows.

3.2.1.1 Digitizing Airport Layout

Airport maps produced from AIP’s were used to digitize the airport layout, including theshapes for runways, taxiways and major buildings (refer to Appendix 1). Digitizing the airport layout required one full day of work. Due to confusion as to actual runway thresholds, orientation and length, the runways were then rebuilt to ensure that they were correctly located.

In addition, AutoCAD files were provided by the Airport Authorities. However, since theairport layout was more or less complete by the time these files were received, and giventhe restricted time available, it was decided not to use them. It may be the case that someof the problems that were encountered when creating the airport layout could have beenavoided if an AutoCAD converter had been integrated in TAAM.



3.2.1.2 Modifying and Enhancing Airport Layout (GTOOL)

GTOOL was used to adjust the location, orientation and lengths of the runways, as wellas to clean up some of the vertices. It was also used to enter taxiway centerlines, apronsand gate connections.

All vertices other than the four that define the base polygon must be deleted before it canbe reclassified as “Runway”. By not doing this procedure, some failure of GTOOL was experienced.

Drawing gates with GTOOL has not been found straightforward. About 2 hours were required to enter 25 gates and connections without validation. A greater experience withGTOOL would have probably shortened this duration. An alternative for gate input was toscan gate co-ordinates (from AIP’s), convert them into text format and then convert theminto .pol format. This has saved considerable time and effort, although the connection between gates and taxiway centrelines must still be performed manually.

Once the basic layout data had been input, a visit was arranged to Brussels Airport thatincluded airport parking control, the tower, the airport surface and the associated ATCCenter (CANAC). This allowed the existing layout to be validated and further layout detailsto be identified and included in the scenario.

The process of digitizing, modifying, checking, enhancing and validating the airport layoutrequired a total of about 7 man-days, in comparison with the 3.5 man-days planned in Ref 1.We believe that with experience and with the provision of external data preparation tools(for example, extraction of timetable and ATC environment data from a database and/orconverters for AutoCad data and AIP’s) this effort can be considerably reduced.

Although it is out of control of TPG, it should also be mentioned that GTOOL is based onOpenGL and SUN has been very slow to fix known bugs in OpenGL. This main one of themain reasons why TPG decided to port TAAM to Linux. The initial version should be available in April 2000.

To conclude, the GTOOL pre-processing facility is relatively powerful and user-friendly.However, some specific improvements could still improve its power and reduce effortspent in data preparation.

3.2.1.3 Importing Data

A) Traffic Schedule Data

Since SID’s and STAR’s were not available for 1998 data, it was decided to use one of thebusiest days in 1999 as a traffic sample.

The timetable was created using 2 different sources of information:

! Scheduled traffic was provided by the CFMU. The traffic sample, on 17 September1999, included 495 departures and 499 arrivals;

! The 17 September 1999 traffic sample was provided by the Airport ManagementSystem (AMS). The airport operated some 1035 flights on that day; the 40 flights (i.e. less than 4%) not present in the CFMU sample are probably state flights (police,military, …).

Linked flights are two movements including an arrival, turnaround and departure with thesame aircraft. Identifying linked flights was actually the most difficult task in timetable validation. Information related to apron control is unfortunately not available in CFMU.With the help of the airport parking control service, the AMS sample also includes somelinked flights and other information that is required to simulate turnarounds and gate allocation.



TAAM recognises four different types of links that can be specified in timetables: registration number, gate-based, call-sign +/- 1 and built-for-the-purpose links. In thiscase, information related to registration number was not reliable (for instance, some linked flights with the same registration number had two different aircraft series at arrivaland departure) and gate allocation was not available in the timetable. Linked flights were therefore identified using the information provided by AMS and by creating artificial links.

Table 1 shows the optimal information for timetable generation:

- - - - - - - - - - - - - - - - - Available1. Callsign "2. Registration number3. Market segment Not for Cargo4. Gate allocated +/- 50%5. Origin-Destination "6. On/off-block times "

Table 1: Required Information for TAAM time-table generation

Comparing the two traffic samples allowed allocation of gates to about 50% of flights. Thegates for the remaining 50% were automatically allocated by TAAM.

Consistency checks for airports, waypoints and routes were successfully executed byTAAM, through the IDIS described in Section 3.2.1.4.B.

B) Aircraft classification, Aircraft type and Market Segment Definition

Two types of data are considered in TAAM: dynamic data are related to a specific projectwhile static data are not project-specific and can be fixed and used for different projects.Aircraft classification and aircraft types are part of the TAAM static data.

Market segments enable the classification of traffic, sometimes for gate allocation purposes, but also for simulation analyses. Appendix 2 shows the market segment classification identified in the scope of this evaluation.

Cargo flights represented 8.8% of traffic at the airport in 1998 and 9.5% in 1997. As no information in the traffic sample was available to identify cargo and BA flights, it was assumed that all DHL flights were cargo only. This represented 62 flights in the traffic sample, i.e. 6.2%. No means were identified to provide a better assignment than thisassumption.

C) Aircraft Performance Data

The aircraft performance data used by TAAM has been created and maintained by TPGand TAAM users over the years. Validation of this data has been considered to be outside the scope of the evaluation exercise. Nevertheless, it has been demonstrated inthe past that using a single definition of aircraft performance does not provide the mostaccurate result. Two different sets of aircraft performance data are usually required: onebased on manufacturer data and a second one that is operational and reflects how aircraftoperators operate their aircraft. While technical aircraft performance data allows measurement of the basic capacity of the ATM system to some degree, use of operational aircraft performance data enables the assessment of sustained capacitybased on specific practices defined by the performance data.



At the 10th ETTSG Meeting, 30 and 31 March 2000, it was mentioned that TPG proposedsome modification of their aircraft performance data file in order provide greater flexibility(refer to Ref.6 ).

It was also mentioned that Boeing data could be available1; nevertheless, TPG has notsucceeded in obtaining Airbus data.

D) Operational Rules

Rules are one of the most powerful and useful features of TAAM. They enable actual operational practices and traffic paths to be replicated in an extremely precise manner.The design of the rulebase may extend from reflecting complex runway dependencies totaking into account non-standard runway usage, gate and apron usage, taxiway usage,SID and STAR allocation, and re-routing.

Runway rules permit spacing requirements and runway functionality to be met. In thescope of this evaluation, runway rules were used to reflect three main operational practices at Brussels airport:

! To allocate aircraft to specific runways to allow less departure delay;

! To instruct aircraft to utilise specific runway turn-off taxiways, which reflects currenttower operations;

! To balance departure queues at the departure end of the runway.

Taxiway rules were used to restrict or ensure that ground movement follows accepted patterns so that the departure sequence is correct.

Concerning gate/apron allocation, rules were used:! To allocate certain aircraft market segments to the appropriate ramp areas;

! To assign cargo, business and military aircraft to appropriate aprons;

! To optimise ramp parking by assigning heavy jets to specific gates.

Arrival and Departure sequencing rules were used to tailor airport demand to provide asatisfactory reproduction of inbound and outbound aircraft rates. Sequencing rules werealso defined in order to adjust arrival spacing during heavy periods of departure traffic toassure minimum departure delay.

The rules that have been defined for the Brussels airport study, along with the associatedinput parameters, have been validated in conjunction with the Airport Authorities and ATSproviders. The overall opinion is that they appear to reflect operational practices to a satisfactory degree.

TAAM’s rule mechanisms are based on two logical structures:

if <condition> ➜ do <action>

and

if <condition> ➜ do not <action>

Inconsistencies were detected in the application of these rules to the input data. Furtherinvestigation revealed that in general the following priority order should be adhered towhen rules are defined:

! if <condition> do not <action>

! input data conditions

! if <condition> do <action>


1 - Due to the fact that TPG is a wholly-owned subsidiary of Boeing.


Inside the same rulebase, rules must also be ordered in priority order. Five different rulebases can be defined: gate, runway, sequencing, taxiway and SID/STAR. It was decided not to investigate potential conflicts between these different rulebases, since thescope of each is well delimited.

The rule mechanism is very powerful and one of the major features of TAAM. However, itcould be improved even further, with the addition of other logical constructs that wouldincrease its flexibility. Two specific examples are:

if <condition> ➜ then <action> ➜ else <action>

or

select case <value> : <action> case else <action>.

One disadvantage of the rulebase is run-time performance. The main issue appears to bethat rules are interpreted at run-time, which means that the performance quickly degradesas additional rules are introduced into the simulation.

E) Sector Data

AIP’s were the primary source for sector data, and were introduced using IDIS. This is described in Section 3.2.1.4.B .

3.2.1.4 TAAM Facilities for Data Entry and Validation

The approach to data entry and validation that has been taken with TAAM is to provide asmuch flexibility for the user as possible. All data is held in ordinary text files with simple,easy to understand formats. The user may edit these files directly, make use of syntax-directed TAAM facilities (IDIS, GTOOL etc), or even create their own pre- and post-processing tools.

This approach has the advantage of being straightforward and instinctive, and allowsmaximum flexibility in the preparation of data. It has the potential disadvantage of allowingerrors to be easily introduced into the data by inexperienced users, since they are notbound to use the syntax-directed approach to creating and modifying data that guaranteesits validity. However, with some discipline, it is possible to avoid major problems.

A) Project Data

A TAAM simulation is run in the context of a project. A project is the definition of a singlesimulation study; it includes all of the data that will be used as input to the study. TAAMdistinguishes between project specific and non-project specific data:

! Data such as airport, waypoint, route, flight timetable and geographical area definitions are generally static, and therefore TAAM considers that they may beuseable across multiple projects. It is therefore possible to include a single data file

in more than one project;

! Data that is more dynamic – project parameters, airport operations or conflict resolution strategy, for example – is project specific. The data is defined directly in thecontext of a given project.



A project is defined by a single text file containing all information relevant to the project,mainly a list of the other files (both project and non-project specific) that have been loaded (included) in the project. TAAM data is organised in a hierarchical directory structure, with project files merely forming another branch in the hierarchy:

/data /map . . . . . . . . geographical data files (maps, sector boundaries etc)/wpt. . . . . . . . . waypoint files/apt . . . . . . . . . airport data files (airport location + airport specific files)/rts . . . . . . . . . route files/dat . . . . . . . . . general data files (e.g. aircraft types + performance)/acf . . . . . . . . . flight time-table files (traffic sample)/conf . . . . . . . . conflict detection and resolution data files/sectors. . . . . . sector and terrain parameter files/projects . . . . . project files

A TAAM user may create or import many different data files under each category. Theseare stored and maintained irrespective of the projects that they are being used in. Theprocess of creating a new project includes identifying the files that already exist that areto be included in the new project.

The advantage to this approach is that static data may be defined once and then reusedin multiple projects. However, the user must be very careful when modifying these files,since any change introduced will apply to all projects that have included the file. This isespecially important to remember when using IDIS. IDIS is invoked in the context of a particular project, which is somewhat misleading as the file being modified through IDISmay have been loaded by other projects. The user must understand whether the changeis a generic one or only for the purposes of the current project, since in the latter case anew copy of the file must be taken and loaded.

Comparing different projects in TAAM involves sequential comparisons in time, and notparallel comparison. In order to make traceability easier between different projects and toavoid the problems mentioned above, a project parallel comparison facility (PPCF) wouldbe a useful additional tool. This would report the characteristics of the compared projectsside-by-side, enabling the user to identify both the common aspects of two different projects and, even more importantly, what are the differences. The comparison would bemade not only at the static/dynamic data level, but also in more depth such as, for instance, at the rules level by reporting if they are active or not.

B) The Interactive Data Input System (IDIS)

As stated previously, TAAM data is held in text files that may be edited externally, usingstandard text editors. In addition, IDIS provides interactive, syntax directed facilities forpreparing and modifying certain types of scenario data – in particular, airports, waypoints,routes, timetable data, and individual airport data.

IDIS is invoked in the context of a project. When editing a given type of data, the user ispresented with a display showing the available files (i.e. the contents of the /data/xxxdirectory) in one of two columns – those that have been loaded or not loaded for the project. Options are provided to load and unload files (for some data types, only one filemay be currently loaded). One potential point of confusion here is that a file may be edi-ted even when it is not loaded into the project. In this case, the edit has no impact on thecurrent project, only those projects that have the file loaded.

Some IDIS functions may be invoked from the main simulation window instead of directlythrough the IDIS interface. These mainly relate to dynamic (project-specific) data. In thesecases the user is given the choice of applying the change (in memory; use for currentsimulation run only) or saving it (the underlying data file is changed permanently).



This is a very useful feature for testing new ideas or concepts without affecting the project baseline.

There are two edit options for any data type. A simple text editor may be invoked, whichdisplays the contents of the data file exactly as it is stored and applies no syntax or semanticchecking. This is exactly the same as editing the file externally from IDIS. For an expe-rienced user, familiar with TAAM data formats, it is a very useful facility. There may be certain situations where a rule enforced by TAAM syntax/semantic checking must be overridden; direct editing is the means of doing this.

The second option is to display a full, syntax directed editing window for the data. Thesewindows completely abstract the underlying text file format; each data field is named andwindowing facilities are used to assist the user in entering values (e.g. drop-down lists,combo boxes, radio buttons). One issue with this feature is that the syntax checking cannot be disabled – in some cases, it would be preferable for the user to have availablethe display features that these windows provide without the restrictions imposed by thechecking.

One particular area where the semantic checking could be improved is linked flights. Itwas noted that linked flights with same registration number but different aircraft series forarrival and departure were not detected.

In general, the IDIS interface is very clear and easy to use. The editing windows are welldesigned and conform to the look and feel specified by X-windows/Motif design standards.They provide a clear abstraction for the underlying file format. It would perhaps be betterif the editing of non-project specific files was a separate function, outside of the context ofa specific project. The difference between project related and generic editing would thenbe more obvious.

C) IDIS Graphics

When IDIS is invoked, the user has the choice of also invoking an accompanying graphi-cal display. This display allows airports, airport layouts, waypoints, routes, and map details(including sector definitions) to be presented to the user graphically. Normal graphicaldisplay features such as zoom in/out, pan, refresh etc are provided.

Each type of data may be selectively displayed. As well, it is possible to select a graphical element and open a window that provides the full details of the element (e.g. fora waypoint - name, latitude, longitude etc). The graphical display is synchronised with theIDIS syntax directed data editing functions, such that any changes applied to the data areimmediately reflected on the graphical display.

The graphical display is extremely useful for the user during data preparation, in somecases vital, especially with regard to the design of elements such as routes, SID’s andSTAR’s. Quite often AIP’s and other publications provide pictorial information as well astextual, and it is a valuable aid to the data preparation process if the editor can representthis. Obvious errors can be identified very quickly.

As mentioned before, the only potential confusion is that loaded and non-loaded files mayboth be displayed in exactly the same manner. It is possible to display graphically data thathas not been loaded into the project, mixed in with other data that has been loaded. Itwould be better if this was clearly distinguished.



D) Individual Airport Data

IDIS functions related to individual airport data may be invoked from the main menu orfrom within the main simulation window. There are six different types of data that may beedited – airport usage, runway preferences, weather, SIDs, STARs, and airport layouts.To edit layouts, GTOOL is invoked; specific editing windows are provided for the othertypes of data.

Airport usage data is a powerful tool for configuring an airport scenario to model actual airport operations to a relatively high degree of accuracy. Parameters for the use of runways, taxiways, gates and aprons, SID’s and STAR’s may all be specified. In addition,there are parameters for sequencing, ground movement, departure separation, flowcontrol, runway selection, and dry or wet weather conditions.

The SID and STAR designers within TAAM are extremely powerful. SID’s and STAR’s areconstructed by specifying a series of instructions for the aircraft – e.g. for SID’s, instructions that specify the path of the aircraft from the runway to the last fix on the SID.The user may create, insert, modify and delete instructions. Adding new instructions is a syntax directed procedure, with each instruction being specified using terminology typically found in standard AIP publications. For example,

! Intercept track 999 To/From XYZ VOR

! At 9999 Ft turn L/R/A intercept track 999 To/From XYZ VOR

Many different instruction options are provided by the SID / STAR designers. Theseoptions model AIP terminology very closely, and where an exact mapping is not availableit is normally not difficult to create a TAAM equivalent. Furthermore, using the graphicaldisplay in conjunction with the designer allows the user to check their work visually andmake sure that the instructions they have entered result in a sensible path. For example,it may be syntactically correct for a flight flying a SID to turn back toward the airport, butwhen viewed by the user graphically it becomes immediately apparent that an incorrectinstruction has been specified. The graphical display includes features such as a measu-ring tool (measure the distance between two points in space) that assist this process.

One minor problem that has been observed is that in some cases two consecutive instruc-tions may conflict at a very low level of detail, causing a very small “interruption” in theflight path.

In general, the user relies heavily on the graphical display to validate SID’s and STAR’s.In the above cases, the resolution levels that would normally be set would not show theinterruption – the user would observe a straight line or a smooth transition. The interrup-tion is only visible when the display is zoomed in to a high level of detail.

A certain amount of practice is necessary to be able to use the SID and STAR designerseffectively. However, once familiar with the tool (especially the way in which particulartypes of AIP instructions are implemented), the user may input, test and refine SID’s andSTAR’s rapidly and efficiently, and (especially when combined with SID/STAR selectionrules) gain a relatively high degree of realism in airport operations.

E) Validation by Airport Operations Experts

Once the airport layout and the imported data were cross-checked and validated usingIDIS facilities, they were presented to ATC controllers (from tower and parking control)during the model calibration and validation process. They stated that the model represented a satisfactory picture of tower/gate procedures. The preliminary resultsshown to the tower personnel were adequate to conclude that the model can be calibrated to an acceptable degree of accuracy.



SID’s and STAR’s designed with IDIS should be validated by ATS providers and againstactual flight paths, by comparing the simulation results against radar data. Due to the limited timeframe and the lack of available radar data, this comparison did not take place.Nevertheless, this cross-checking exercise is highly recommended for future studies.

3.2.2 Perform Baseline Model Runs

3.2.2.1 Simulation Run Performance

Powerful CPU’s and very fast buses are available nowadays at a quite reasonable priceand, therefore, processing speed becomes less and less a critical performance factor.Nevertheless, since simulations may sometimes be huge, especially if airport systems areconsidered, the simulation run performance has been taken into consideration for the evaluation.

With the input set described in Section 3.2.1, i.e. some 1000 flights in a 24 hour-period,several runs showed that about 10 minutes are required per run with graphics enabled.The step used during these runs was 6 seconds, and the simulation speed rate2 variedbetween 27 at peak times up to a maximum of about 5000. CPU and disk writing timeswere not measured separately; in terms of volume, some 392 MB of data was written tothe local disk during these 10 minutes.

A multi-run of 20 successive runs for the same scenario took 2 hours without graphics, i.e.6 minutes per run with the same amount of data transferred to disk. In multi-run mode, themaximum simulation speed reached almost 9000. When global flight data recording wasdisabled, the size of information provided was reduced to some 6 MB and the time required to run 10 successive simulations was 42 minutes, i.e. 4 minutes per run.

Some techniques can be used to make simulation runs faster, such as:

! Maximum increase of the time step (6 seconds);

! Maximum zoom in a “black” graphic zone of no interest : according to TPG, thisshould reduce simulation time by 50%. For the Brussels airport study, a reduction of40% was experienced;

! Disable airborne conflict detection and resolution when possible (specific to groundmovement study);

! Disable ground movement when possible (specific to airspace study);

! Reducing the use of airport usage rules, although this recommendation might resultin loss of flexibility and may be unrealistic for detailed airport studies.

A description of these and other techniques used to reduce simulation time can be foundin Ref. 4.


2 - The simulation speed rate is the current rate with respect to real time. For instance, a value x greater than 1.0 means that the simulation is x timesfaster than real time.


3.2.2.2 Graphical Simulation Run Facility

TAAM provides 2D and 3D graphics for observing the progress of a simulation as it exe-cutes. This facility is actually useful for user understanding of the simulation. It helps indebugging and calibrating the model as well as showing the results to customers.

The display is relatively accurate and is characterised by its high clarity. The added valueprovided by this display is a major advantage of the tool, even if, as stated previously, ithas a negative impact on simulation run time.

A feature that would be extremely effective, but that is not currently available, would be asimulation run re-player. There are no facilities available to review past events, which is amajor disadvantage during the process of calibrating scenarios with stakeholders, especially ATC controllers. Such a feature would be even more effective if it was a stand-alone product, with no dependencies on the core TAAM software, and if it could execute in a PC/Windows environment. This would allow TAAM scenarios to be transportable (could be replayed on a laptop), which would facilitate co-ordination with airport authorities, ATC controllers and other stakeholders.

It should be noted that NATS have developed a tool to provide this facility, called ReView.In addition, TPG have stated that they are planning to provide a replay tool in the nearfuture.



3.2.2.3 Raw Output Data Description

Four different report files can be generated during and/or after simulation:

! The report file;

! A flight summary file;

! A flight history file;

! The global flight data recording file.

For each time period, typically one hour, the report file provides information about theflights simulated, including (for airport studies):

! Fuel burn;

! Cost;

! Airport delays, split into gate, taxi and runway/sequencing;

! Movements on and delay for each apron and taxiway segment;

! Airport movement (considered as runway occupancy times by TAAM);

! Runway data (take-off time and arrival rwy occupancy time).

A brief description of the TAAM concepts used in output files is given in Appendix 4.

In addition, the report file provides statistics for every time period, such as the number offlights rejected, terminated before departure, normally completed, and terminated duringarrival, plus the average number of active flights.

The Flight Summary file is a summary of the report file and can be directly imported intoa spreadsheet. For each flight, it includes information on:

! Movement time and delay: actual ground time, actual airborne time, scheduled timeas in timetable and calculated in simulation, total delay;

! Departure: departure airport, rwy, first fix and ETD;

! Arrival: destination airport and rwy, last fix and ETA;

! Cruising altitude.

It should be mentioned that the description in the Reference Manual (Ref.3, pp96-97) isnot always clear and/or does not always reflect what is reported in the Flight Summary file.

For instance, according to Ref.3, Scheduled Time per Simulation is the “Total of taxi timeon departure; line-up; take-off run; plus airborne time including that on SID; En-route andSTAR; landing run; plus taxi time on arrival. No delays, unimpeded movement.” whileScheduled Time per Timetable (FPL) is “(ETA minus ETD) as in timetable when read intoTAAM.” However, in the original timetable the value of ETD was found to be unknown forflights arriving at Brussels airport, and the value of ETA was unknown for flights departingfrom Brussels airport. To compensate for this problem, a check was made with IDIS andvalues calculated by TAAM were substituted. In the Flight Summary Report, Time per SIMseems to be scheduled time in timetable after the IDIS check, while the origin of the valuementioned in the Time per Timetable (FPL) remains unclear.



It appears that the column heading “Time per SIM” and “Time per FPL” should be inter-changed. It appears also that “Time per SIM” calculation has been performed while TAAMwas running in a single airport mode. The flight history file records all significant events foreach flight as it proceeds from the departure gate to the arrival gate. The informationrecorded includes callsign, aircraft type, current status (at gate for departure, taxiing, en-route,…), heading, ground speed, current altitude, position (latitude + longitude),climb/descent rate, and location.

Global Flight Data Recording allows extraction of information on all movements identifiedin the simulation at a given simulation time step.

In conclusion, it can be stated that although there is more information that could usefullybe recorded by TAAM (e.g. to get more realistic runway occupancy time measures), theoutput currently available represents a huge amount of useful information that can beextracted.

3.2.2.4 Evaluation of the Report Presentation Facility (RPF)

The Report Presentation Facility (RPF) is the post-processor provided with TAAM. TheRPF extracts information from the raw output files described above and provides somepre-defined airport-related reports:

! Movement counts distribution;

! Number of speed and/or holding actions taken for aircraft landing;

! Total delay distribution;

! Dissection delays;

! Total Delay per taxi segment;

! Individual TWY delays and usage;

! Traffic counts per runway based on various groupings;


In Timetab le before IDIS Check

SAB859 B733 1 EBBR_LEBL_2 330 17,16:00 ? 0 0 S L79

SAB599 B733 2 EBBR_EGLL 18 0 17,6:30 ? 0 0 S L23

SAB437 BA46 1 EBBR_EDDH 110 17,16:35 ? 0 0 S L139

In Timetab le after IDIS Check

SAB859 B733 1 EBBR_LEBL_2 330 17,16:00 17,17:35 0 0 S L79

SAB599 B733 2 EBBR_EGLL 18 0 17,06:30 17,07:09 0 0 S L23

SAB437 BA46 1 EBBR_EDDH 110 17,16:35 17,17:35 0 0 S L139

Flight No Gate Delay Ground

DEP

Airborne

Time

Ground

ARR

Total Time Time per

SIM

Time per

FPL

Actual-

Scheduled

In TAAM flight summary file *,sum

SAB859 01:24:14 00:10:28 01:35:18 00:00:00 01:49:22 01:3 5:00 00:23:49 01:25:33

SAB599 01:10:56 00:08:34 00:37:17 00:00:00 01:34:13 00:3 9:00 00:21:44 01:12:29

SAB437 01:05:42 00:10:39 00:58:54 00:00:00 01:33:02 01:0 0:00 00:25:40 01:07:22

In DFS Reporter Flight Time Summary

SAB859 01:24:14 00:10:28 01:35:18 00:00:00 01:49:22 01:3 5:00 00:23:49 01:25:33

SAB599 01:10:56 00:08:34 00:37:17 00:00:00 01:34:13 00:3 9:00 00:21:44 01:12:29

SAB437 01:05:42 00:10:39 00:58:54 00:00:00 01:33:02 01:0 0:00 00:25:40 01:07:22

17:35 – 16:00 = 01:35


! Inter-movement gaps;

! Take-off delays;

! System delay;

! Costs (fuel, non-fuel and total with possible accumulations).

When required, reports can be edited to provide different presentation formats (histogram,graph, table) and statistics may be grouped by market segment, aircraft category, aircraftclassification and mode of operations (arrival, departure and mixed).

The RPF is useful. However, the reports that it presents tend to be simple and do not allowfor more complex analyses or presentations of the data. Most TAAM users require a moresophisticated reporting facility, and some have even gone as far as developing their ownTAAM reporter. The most widely used of these is DFS Reporter, developed and maintai-ned by the DFS and available for download at the DFS’s specialist TAAM website(www.taam.de).

3.2.3 Simulation Post-Processing Analyses

This Section includes the results of the simulation post-processing for the baseline. TheTAAM RPF, the DFS reporter and an in-house developed facility have been used to extractrequired information from the raw outputs provided by the simulation. The following indicators will be considered:

Indicator . . . . . . . . . . . . . . . . . . . . . . Valid for …. . Desegregation

1. Runway Flow Rates . . . . . . . . . . . . Arr. & Dep. . . Per Runway2. Runway Occupancy Times . . . . . . . Arr. & Dep. . . Per Runway; Per Aircraft Class3. Average Ground Time . . . . . . . . . . . Arr. & Dep4. Average Ground Delay . . . . . . . . . . Arr. & Dep

4.1. Average Taxiway Delay . . . . . . . . . Arr. & Dep4.2. Average Sequencing Delay . . . . . . Arrivals4.3. Average Stand-off Delay . . . . . . . . Arrivals4.4. Average Gate Delay . . . . . . . . . . . Departures4.5. Average Departure Queue Delay. . . Departures

Table 2 : Indicators used for TAAM Airport Evaluation

A complete definition of these indicators is reported in Appendix 4.

3.2.3.1 Baseline Results vs CFMU Data

Although important to take into account, sensitivity and accuracy analyses on traffic samples from different sources was not a priority in the scope of a tool evaluation. Forexample, CFMU data are readily available and expected to be relatively accurate as theyrepresent already regulated flow management. On the other hand, when airports recordaircraft movements, this constitutes a source of data that should be even closer to reality(since it represents actual, as opposed to planned, movements), as long as the data recording is complete and consistent. This usually requires some specialist effort from theairport authorities to collect the data and for analysts to check accuracy and consistency.For studies related to specific airports, the latter alternative is preferred if the requiredmovement data can be made available. For this study, however, CFMU data was used asthe source for the traffic sample.



Some specific issues have been taken into account while processing the CFMU data toproduce the traffic sample:

1. In TAAM, departure airport movement starts at the beginning of line-up until lift-off.However, in the traffic sample provided by the CFMU, the Estimated Time of Departure(ETD) is the off-block time. A value of 20 minutes is used by the CFMU between off-block and line-up times, to reflect the average taxi time for Brussels Airport. In thescope of this evaluation, this 20 minutes value has been accepted.

2. The time over the last point of the 4D profile calculated by the CFMU was used as arrival time.

Some discrepancies can exist for departures due to the use of the default value of 20minutes for taxi time on one side (CFMU) and the calculated taxi times on the other side(TAAM).

Using complete CFMU profiles (from origin airport or oceanic entry point to destination airport or oceanic exit point) might also bring some fluctuation in runway flows. The reasons are both relative and absolute. First, the 1000 flights simulated do not have thesame impact as 25,000 flights would in the ECAC area every day. Therefore, unrealisticairspace traffic might bias the results for arrivals. Second, the difference between theTAAM methodology for conflict detection/resolution and the way CFMU regulates trafficmight also cause discrepancies.

In order to avoid these problems, the traffic sample was reduced to entry/exit point to/fromthe airport in the scope of this exercise only.

Figure 1 shows a relatively good correlation between demand and simulated runway flows.


CFMU Demand vs TAAM Results Brussels Airport - 17 Sept 99

-70-60-50-40-30-20-10

0102030405060708090

0:0

0- 1

:00

1:0

0- 2

:00

2:0

0- 3

:00

3:0

0- 4

:00

4:0

0- 5

:00

5:0

0- 6

:00

6:0

0- 7

:00

7:0

0- 8

:00

8:0

0- 9

:00

9:0

0-10

:00

10:0

0-11

:00

11:0

0-12

:00

12:0

0-13

:00

13:0

0-14

:00

14:0

0-15

:00

15:0

0-16

:00

16:0

0-17

:00

17:0

0-18

:00

18:0

0-19

:00

19:0

0-20

:00

20:0

0-21

:00

21:0

0-22

:00

22:0

0-23

:00

23:0

0- 0

:00

Ho

url

y R

WY

Flo

w R

ates

TAAMFlowRate CFMU Demand CFMU Demand -10% CFMU Demand +10%

TAAMArr CFMU Arr. Demand CFMU Arr. Demand -10% CFMU Arr. Demand +10%

TAAMDep CFMU Dep. Demand CFMU Dep. Demand -10% CFMU Dep. Demand +10%

Figure 1: CFMU demand vs TAAM results

3.2.3.2 Simulated vs Measured Runway Occupancy Times

In an exercise performed in May and June 99 at BRU airport, runway occupancy timeswas measured for some 520 flights. The values provided by TAAM are compared withthese measures in Table 3 and Table 4 here below.

As far as arrival runway occupancy times (AROT) are concerned, TAAM seems to be relatively optimistic. Some observations can be made, as follows:

1. In TAAM, arrival runway occupancy time is defined as the elapsed time between touch-down and the moment the aircraft starts turning off the runway, without regard toa safety distance (usually 30 m from the runway centerline)3. On the other hand, the collected values were relative to the time elapsed between threshold crossing and thetime when the aircraft tail is off the runway. So there is some terminology discrepancy.

2. TAAM ROTs are based on pure technical aircraft performance and it is assumed thatTAAM uses the maximum deceleration rate available without regard of level of serviceand airline strategy. The collected values, by comparison, should reflect more realisticoperational performance.

3. The major difference between AROT for widebody jets on 25R can be justified by thefact that the 103 seconds are related to cargo flights. These flights have to run on thecomplete runway length before turning off to the cargo apron.

Departure Runway Occupancy Time (DROT) is even more sensitive than AROT, especially with regard to capacity in segregated mode operations when departure sequencing is optimised. Compared to AROT values, TAAM seems to be relatively morepessimistic in terms of DROT.

In TAAM, DROT is defined as the time between beginning of take-off and rotation. TheDROT collection performed in May-June 99 was based on two different concepts:

! The take-off time (TOT) is the time elapsed between the time when the departure isfully lined up or when take-off clearance is given, whichever is the later, and when themain wheels leave the ground;

! The line-up time (LUT) is the time elapsed between the time when a departure reaches the stop bar or receives unconditional line-up clearance, whichever is thelater, and when the aircraft is fully lined up.



3 - It has been observed during this evaluation, and as well with studies conducted by ETTSG members, that AROT appears not to be measured by TAAMas stated in the reference manual. However, as it is not possible to examine TAAM code to check the calculations used for ROT values, it has beendecided for the purposes of this study to assume the reference manual is correct.

47,4 6,6 24 103 8 48 6 24 65 24

43,8 7,8 74 68 58 43,8 8,4 290 59 140

36 1,2 8 57 31 36,6 7,2 25 51 87

41,4 2,4 11 58 3 40,8 10,8 41 59 1

49,8 0 1 34,2 22,8 2

WidebodyJets

NarrowbodyJets

Light Jest

Turboprops

PistonEngined

Average Std. Dev. SampleSize Average Sample

Size Average Std. Dev. SampleSize Average Sample

Size

TAAM

25R 25L

Measured TAAM Measured

Table 3: Arrival Runway Occupancy Time Evaluation

During peak times where multiple line-ups are in use, TAAM DROT should match measured take-off time.

It can be observed:

1. Relatively important discrepancies can be observed between the values coming fromthe simulation (TAAM DROT) and collected TOT’s.

2. Usually, when no multiple line-up is operated, line-up time (and possibly pilot reactionto ATC clearances) should be considered as part of DROT. In TAAM, line-up time isincluded in runway departure delay. However, when measuring runway departuredelay, we did not succeed in identifying delays caused by line-up only and not by othercauses such as airborne separation or waiting for next arrival.

Table 4: Departure Runway Occupancy Time Evaluation

To conclude, there is a strong need for more measurement points. TAAM should recordsome primitive events (e.g. touch-down time, or time at some safety distance on runwayexit) that are required for AROT measurement. It should also record additional events forDROT, such as time of ATC clearance, stop bar crossing, pilot reaction time, full line-uptime and time over runway fence.

Another major issue is the lack of terminology standardisation over Europe, which meansthat there is no fixed definition of ROT that may be applied to simulator development.Nevertheless, two facts should be mentioned. First, the EUROCONTROL AirportOperations Team (AOT) is in the process of approving some commonly agreed definitionsfor ROT at the European level. Second, flexibility of a simulation tool should not be lostwhile adding new events. It should be possible for the end-user to tune his/her own ROTconcept by aggregation of some elapsed times between proposed events.

3.2.3.3 Connecting Flights

Although hub operations are not reflected in ICAO flight plans, one possible and requiredimprovement for TAAM is to be able to adjust the departure time of any connecting flightdepending on the arrival time of a major (long-haul) flight, with a maximum value for waiting long-haul flight time. This would reflect hub operations much more realistically.This debate is taking place at ETTSG and some improvements have been suggested toTPG in this way.



70,8 9,6 38 48 12 33 9 65 5

56,4 8,4 363 44 8 29 12 60 106

46,2 4,2 35 43 8 24 10 57 71

45,6 4,2 56

39,6 8,4 3

WidebodyJets

NarrowbodyJets

Light Jest

Turboprops

PistonEngined

Avg. Std.Dev

SampleSize

Avg.TOT

Std.Dev.

Avg.LUT

Std. Dev.LUT

Avg.ROT

SampleSize

TAAM Measured


3.2.3.4 Baseline Results vs Airport Experts’ Judgement

It is normal that a model will not produce an exact reflection of the actual traffic flow duringa simulated period. Day-to-day airport operations are subject to a vast number of influences, all of which can affect the traffic flow in some way, and which are impossibleto simulate to the same level of detail. There are random factors inherent in the modelling process that have been taken into account in order to reflect day-to-day fluctuations.

However, it is possible for experts familiar with the airport to judge whether or not theactions taken by the model in response to particular events or scenarios make sense.

The results of the TAAM Airport evaluation have not been presented yet to Brussels AirportAuthorities. Nevertheless, some results were presented to the ATS providers for calibration purposes, and these experts agreed that the model was responding to particular events or scenarios in a manner that reflected day-to-day fluctuations in airport operations.



3.3 SENSITIVITY TESTS

This Section reports on tests conducted by modifying TAAM simulation parameters andobserving the effect on TAAM results. The first sensitivity test aimed at evaluating outputstability while performing multiple runs of the same baseline. The second sensitivity testexamined the effect when the level of traffic is increased significantly.

3.3.1 TAAM Stability

In a simulation, it is usually necessary to randomise some parameters in order to reflectday-to-day fluctuations. TAAM facilitates simulated fluctuations based on a Gaussian normal distribution with values beyond, where is the median value and the standard devia-tion. The following factors can be randomised in TAAM:

! Estimated time of departure lateness (ETD): altered when the timetable is read (notduring run-time);

! Aircraft performance characteristics: take-off mass, cruising altitude, rate ofclimb/descent, cruising/climbing/descent IAS/Mach, fuel consumption, take-off acceleration, airborne speed, touch-down speed and landing deceleration;

! Touch-down point: set as a percentage of the standard touch-down point distance(300 m) from the runway threshold.

These randomisation parameters are set per aircraft class, and not per aircraft type. Thedefault values for the randomisation parameters were used in the scope of this exercise.

Multiple runs can easily be undertaken with TAAM. As stated in Section 3.2.2.1, it tookabout 2 hours to run 20 successive simulations, i.e. about 6 minutes per run.

In this stability analyses, 8 different runs of the baseline were analysed. The hourly runway flow rates and average ground times of these different runs are shown in Fig.2 andFig.3. The different runs provided very similar results, except for one run in which some congestion on one taxiway segment occurred.


RWY Hourly Flow Rate

-65-55-45-35-25-15-55

152535455565758595

0:0

0- 1

:00

1:0

0- 2

:00

2:0

0- 3

:00

3:0

0- 4

:00

4:0

0- 5

:00

5:0

0- 6

:00

6:0

0- 7

:00

7:0

0- 8

:00

8:0

0- 9

:00

9:0

0-10

:00

10:0

0-11

:00

11:0

0-12

:00

12:0

0-13

:00

13:0

0-14

:00

14:0

0-15

:00

15:0

0-16

:00

16:0

0-17

:00

17:0

0-18

:00

18:0

0-19

:00

19:0

0-20

:00

20:0

0-21

:00

21:0

0-22

:00

22:0

0-23

:00

23:0

0- 0

:00

Mo

vem

ents

/ho

ur

Baseline Total Run 1 Total Run 2 Total Run 3 Total Run 4 Total Run 5 Total Run 6 Total Run 7 Total Run 8

Arr Baseline Arr Run 1 Arr Run 2 Arr Run 3 Arr Run 4 Arr Run 5 Arr Run 6 Arr Run 7 Arr Run 8

Dep Baseline Dep Run 1 Dep Run 2 Dep Run 3 Dep Run 4 Dep Run 5 Dep Run 6 Dep Run 7 Dep Run 8

Figure 2: RWY Hourly Flow Rate


As shown in Table 5, a maximum of 5,6 movements of deviation (7%) is observed in hourlyrates during significant periods (between 5 am and 10 pm). This deviation can occasionallyincrease up to 19% for arrivals and 11% for departures.

When considering the whole day, the standard deviation is averaged to 6% for total movements and departures, and to 7% for arrivals.


Average Ground Times

-15

-10

-5

5

0

10

0:0

0- 1

:00

1:0

0- 2

:00

2:0

0- 3

:00

3:0

0- 4

:00

4:0

0- 5

:00

5:0

0- 6

:00

6:0

0- 7

:00

7:0

0- 8

:00

8:0

0- 9

:00

9:0

0-10

:00

10:0

0-11

:00

11:0

0-12

:00

12:0

0-13

:00

13:0

0-14

:00

14:0

0-15

:00

15:0

0-16

:00

16:0

0-17

:00

17:0

0-18

:00

18:0

0-19

:00

19:0

0-20

:00

20:0

0-21

:00

21:0

0-22

:00

22:0

0-23

:00

23:0

0- 0

:00

Ave

rag

e G

rou

nd

Tim

es (

min

)

Arr Baseline Arr Run 1 Arr Run 2 Arr Run 3 Arr Run 4 Arr Run 5 Arr Run 7 Arr Run 8 Dep Baseline

Dep Run 1 Dep Run 2 Dep Run 3 Dep Run 4 Dep Run 5 Dep Run 6 Dep Run 7 Dep Run 8

Figure 3: Stability Sensibility Analysis

Table 5: Statistical Analysis on Runway Flow Rates


In Table 6, the hourly averages and standard deviations are reported for the ground timeindicator. When considering significant periods (between 5 am and 10 pm), the maximumdeviation for hourly inbound ground times is 46 seconds (14%) per arrival. For outboundground times, the maximum deviation observed is 90 seconds (13%) per departure.

Table 6: Statistical Analysis on Average Ground Travel Times

Analyses of delay dissection and ground delays also demonstrated that the stability of thesimulator is quite acceptable.

3.3.2 Traffic Increase

This second sensitivity analysis consisted in increasing the traffic in order to reflect significant congestion at the airport and model’s reaction to this situation.

As well as an increase/decrease in daily traffic volume, traffic forecasting usually produces new traffic patterns. Many different techniques exist for forecasting future levelsof traffic, very often specific to a given airport or airport system.

It has been out of the scope of this study to agree on a forecast methodology with the stakeholders of the airport under consideration. The results provided in this section shouldonly be used to illustrate the traffic forecast feasibility with TAAM and its response tocongested situations.

IDIS provides a traffic cloning facility that enables the user to select some part of the traffic and increase it by a given percentage (i.e. increase traffic on route x during time period y by z%). Cloning uses the even random distribution and therefore smoothes out


#


the traffic peaks (this can nevertheless be avoided by cloning traffic portions on a one-by-one basis). The rest of the scenario may remain unchanged; simple cloning is allthat is required to run a relatively basic traffic forecast study. 4D profiles are automaticallycalculated by the model.

As future traffic patterns are unknown for Brussels Airport, the traffic was increased by apercentage related to the forecasted yearly traffic for 20154 (i.e. 50%) unrelated to specific routes and uniformly in time. The operational rules were unchanged.

During execution of the simulation, it was noted that even with a 50% traffic increase, theincrease in required run time is relatively insignificant.

Although the results are very much dependant upon the forecast methodology and the forecast traffic pattern, classical trends can be observed, as shown in the following figures.


The maximum departure flow rate is 59 movements per hour between 8 am and 9 am, incomparison with the 52 movements in the baseline for the same time period. However, thedifference in departure demand rises steeply during the next two hours (98 departures between 9 and 11 am in comparison with 50 departures in the baseline for the same period).

For arrivals, use of two independent parallel runways means that demand is better accommodated, although some arrivals are kept holding during departure peaks. This is reflected in the delays incurred.

Another major effect of the traffic increase with unchanged operational rules is the distribution of delays and the amount of delay assigned to individual flights. In the baseline,76% of flights are delayed5, of which 20% are delayed by more than 10 minutes. However,with the cloned traffic sample, almost all flights are delayed, and 29% of these incur a delaybetween 10 minutes and 3 hours!



-65-55-45-35-25-15-55

152535455565758595

00:0

0 -

01:0

0

01:0

0 -

02:0

0

02:0

0 -

03:0

0

03:0

0 -

04:0

0

04:0

0 -

05:0

0

05:0

0 -

06:0

0

06:0

0 -

07:0

0

07:0

0 -

08:0

0

08:0

0 -

09:0

0

09:0

0 -

10:0

0

10:0

0 -

11:0

0

11:0

0 -

12:0

0

12:0

0 -

13:0

0

13:0

0 -

14:0

0

14:0

0 -

15:0

0

15:0

0 -

16:0

0

16:0

0 -

17:0

0

17:0

0 -

18:0

0

18:0

0 -

19:0

0

19:0

0 -

20:0

0

20:0

0 -

21:0

0

21:0

0 -

22:0

0

22:0

0 -

23:0

0

23:0

0 -

00:0

0

Mo

vem

ents

/ho

ur

Total Total Cloned Traffic Arr. Arr. Cloned Traffic Dep. Dep. Cloned Traffic

4 - The total traffic amount was 300,000 movements in 98. 450,000 movements per year are forecast by 2015.5 - Note that delayed flights that overlap two hourly periods are counted twice in TAAM.


To conclude, the development of a more sophisticated traffic cloning facility is recommen-ded for TAAM. Although the methodologies that might be made available to clone trafficcould be the subject of strong debates amongst stakeholders – and should be solved atthe European level – such a facility should be provided in TAAM either by improving thecurrent cloning mechanism or through rules such as, for instance,

Increase criteria-based portions of traffic by x% with no more than y movements per hour and no more than z movements in any 10-minute period.

where criteria-based portions of traffic can be include routes, runways, gates, taxiways,time, market segment, traffic mix etc.


Average Ground Delay

0

50

100

150

200

250

300

0:0

0- 1

:00

1:0

0- 2

:00

2:0

0- 3

:00

3:0

0- 4

:00

4:0

0- 5

:00

5:0

0- 6

:00

6:0

0- 7

:00

7:0

0- 8

:00

8:0

0- 9

:00

9:0

0-10

:00

10:0

0-11

:00

11:0

0-12

:00

12:0

0-13

:00

13:0

0-14

:00

14:0

0-15

:00

15:0

0-16

:00

16:0

0-17

:00

17:0

0-18

:00

18:0

0-19

:00

19:0

0-20

:00

20:0

0-21

:00

21:0

0-22

:00

22:0

0-23

:00

23:0

0- 0

:00

Cloned Traffic Departures Baseline Departures Cloned traffic Arrivals Baseline Arrivals

Delay Dissection

0

50

100

150

200

250

300

350

400

450

500

550

600

650

700

]0,1

0[

[10,

20[

[20,

30[

[30,

40[

[40,

50[

[50,

60[

[60,

70[

[70,

80[

[80,

90[

[90,

100[

[100

,110

[

[110

,120

[

[120

,130

[

[130

,140

[

[140

,150

[

[150

,160

[

[160

,170

[

[170

,180

[

Minutes of Delay

# D

elay

ed M

ove

men

ts

Cloned Traffic Baseline

Figure 5: Average Ground Delay

Figure 6: Delay Dissection


3.4 AIRPORT MANAGEMENT IMPROVEMENT TESTS

This section documents the scenarios that have been used to evaluate the ability of TAAMto analyse physical, procedural and technological improvements proposed for the airportunder consideration.

Some of the improvements described in this section might not be realistic for Brussels airport, but have been analysed in the scope of the TAAM evaluation study. The results provided in this section are indicative only.

3.4.1 Runway Selection Strategy and Use of an Additional Existing Runway for Departures

In this scenario, both runways 25R and 20 were used for departures. TAAM provideseffective features to customise runway selection strategy. For instance, for independentparallel runways, the runway selection strategy panel has the following form (configurationused for this exercise):

1st selection criteria (default): runway left if closest waypoint is to the left; runway right ifclosest waypoint is to the right.

2nd selection criteria : choose runway with shorter queue or distance or lighter wind if:! Queue length > 10;

! Crosswind > 20 kts;

! Downwind > 5 Kts;

! Distance from gate to runway > 5000.

Error Handling: if no suitable runway, use runway closest to suitable.

In TAAM, existing runways can be closed to traffic or opened for arrival and/or departurewithout any modification to other inputs (e.g. routes or traffic sample). In this sensitivityanalysis, runway 20 was open for departures with a rule that specifies that a departure on20 must be airborne before an arriving aircraft on 25L reaches the runway capture distance limit.

Some of the results are reported in Figure 7. As the demand did not change, flow rates forthe runway system are similar to those in the baseline. TAAM accurately modelled theimpact that a modification of runway-use configuration could have on a taxiway systemthat is not optimised for that new or temporary configuration. Although the percentage ofaircraft delayed strongly decreased with the use of the new runway (from 73% to 61% foraircraft delayed up to 10 minutes), 24% of the delayed flights have a delay of more than90 minutes due to taxiway bottlenecks. TAAM also accurately modelled the considerableincrease in arrival ground delay that is caused by arrivals on 25L crossing runway 20. Theanalysis of total delay per taxiway segment showed clearly the congestion that resulted attaxiway segment areas

! From North for the baseline (near 25R entry points)

! To areas adjacent to runway 20 (25L exits C2 and C4, segments crossing runway 20to 25R entry point P3).

This change is relatively easy to model with TAAM and does no require much effort. Thecomplete process of data change (operational modifications), run and post-processinganalyses required about half a man day of effort. This is considered very reasonable, evenif it is likely that several loops of the same process would take place in a real airport study,after intermediate reviews by airport authorities and ATS providers.







-60-50-40-30-20-10

01020304050607080

00:00-

01:00

02:00-

03:00

04:00-

05:00

06:00-

07:00

08:00-

09:00

10:00-

11:00

12:00-

13:00

14:00-

15:00

16:00-

17:00

18:00-

19:00

20:00-

21:00

22:00-

23:00

Total Baseline Total With Dep 20 Arr Baseline Arr With Dep 20

Dep Baseline Dep With Dep 20 Dep 20 With Dep 20 Dep 25R With Dep 20

Delay Dissection

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

]0,10[ [10,20[ [20,30[ [30,40[ [40,50[ [50,60[ [60,70[ [70,80[ [80,90 [

Minutes of Delay

Del

ayed

Mo

vem

ents

(%

)

Dep20 Baseline


3.4.2 New Taxiway and Departure on 25L

In this scenario, a new taxiway was built along the complete length of runway 25L (theGtool graphical design feature of TAAM was used to modify the layout). In addition, runway-use configuration was changed and runway 25L was opened for departures.

As reported in Figure 9, some trends similar to those described in Section 3.4.1 could beobserved from the results. As the demand did not change, flow rates are similar to thebaseline. The percentage of delayed flights decreased from 73% to 56% while the average ground times are also similar to the baseline. However, TAAM was able to highlight that using such configuration would also require appropriate optimisation of thetaxiway system. In contrast to the baseline, 5 taxiway segments have more than 30 minutes total delay during the day, which is considered excessive.

As with other sensitivity analyses, the complete process of data change (infrastructure andoperational modifications), run and post-processing analyses required about half a manday of additional effort.




-60-50-40-30-20-10

01020304050607080

00:00-

01:00

02:00-

03:00

04:00-

05:00

06:00-

07:00

08:00-

09:00

10:00-

11:00

12:00-

13:00

14:00-

15:00

16:00-

17:00

18:00-

19:00

20:00-

21:00

22:00-

23:00

Total Baseline Total FullTwy+Dep25L

Arr Baseline Arr FullTwy+Dep25L

Dep Baseline Dep FullTwy+Dep25L



Delay Dissection

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

]0,10[ [10,20[ [20,30[ [30,40[ [40,50[ [50,60[ [60,70[ [70,80[ [80,90[

Minutes of Delay

De

lay

ed

Mo

ve

me

nts

(%

)

FullTwy+Dep25L Baseline

Average Ground Times

0

5

10

15

20

0:00-1:00

2:00-3:00

4:00-5:00

6:00-7:00

8:00-9:00

10:00-11:00

12:00-13:00

14:00-15:00

16:00-17:00

18:00-19:00

20:00-21:00

22:00-23:00

FullTwy+Dep25L - Departures Baseline Avg Gnd Dep FullTwy+Dep25L - Arrivals Baseline Avg Gnd Arr


Figure 11: Average Ground Times


3.4.3 Runway Extension Analysis

To evaluate a physical improvement at the airport, runway 25L was extended by 1200 m.Runway 20 was open for departures while runway 25L was open for arrivals only. The difference is that with the additional runway length runways 20 and 25L may be operatedindependently from each other.

As the purpose of this analysis was simply to evaluate whether or not TAAM could effectively model a runway extension and how much effort was required to implement thechange, related data was not modified. Since the demand was similar to the baseline, flowrates did not change, although an increase in the runway system capacity up to 120 move-ments per day could be expected from such an improvement6. The percentage of delayedflights decreased as well. As for the previous sensitivity analyses, the taxiway systemrepresented a bottleneck during some peak periods.

As with the other exercises, approximately half a man day of effort was required to prepare and conduct the exercise.

3.4.4 Additional Parking Positions

Gtool was used to create 20 additional parking positions on the current military apron.Rules were then used to transfer the traffic for a single airline to this apron.

As departure capacity is the major constraint at Brussels Airport, this scenario is relativelyunrealistic. Most arrivals land on 25L and have to move to and cross 25R before parkingon the military apron. The results accurately reflected this situation by showing a relativelystrong increase of the ground travel time and delay as well as a reduction in capacity on25R.

This exercise also required half a man day of effort to be prepared and conducted. It wasconsidered an important point that parking stands could be added to the simulation easilyand relatively quickly.

3.4.5 Environmental Procedures – TAAM-INM Integration Evaluation

The input file for the Integrated Noise Model (INM) was generated as an output of TAAM(including the 4D profiles required for INM) and was transferred to EEC for processing.EEC did not process this specific file concerning Brussels Airport, but reported a successful transfer of a similar TAAM output file into INM that was performed in the scopeof the TAAM Airspace Evaluation.

As far as TAAM-INM integration is concerned, one of the major issues is the extent towhich consistency has been checked between the TAAM aircraft performance data andthe INM Noise-Power-Distance (NPD) curves. Current aircraft performance data used byTAAM is technical. Therefore, maximum engine power setting is assumed for simulations,which represents only one curve for each NPD diagram. This consistency validation didnot take place in the scope of the Brussels airport study.


6 - In the scope of a real airport capacity study, new traffic pattern should be discussed with the Airport Authorities. Because of limited timeframe, this wasout of scope of this evaluation.


3.4.6 Some Future Concepts

Advanced Surface Movement Guidance and Control System (A-SMGCS) andArrival/Departure Management Systems (AMAN/DMAN) are two future concepts whichwere attempted to simulate in order to evaluate the flexibility offered by TAAM to cope withnew requirements. This exercise was also an opportunity to evaluate TPG’s level andspeed of response to difficult technical questions from a TAAM user.

It is strongly believed that A-SMGCS cannot be simulated with the current version ofTAAM. Although the model enables the simulation of aircraft ground movements in detail,it is not able to simulate small vehicles and their interaction with aircraft traffic on theground.

Through the airport usage file and rules, it is possible to change and customise arrival anddeparture sequencing strategies. The effect of AMAN/DMAN systems (for instance,COMPASS in Germany or MAESTRO in France) was not simulated with TAAM in thescope of this study.

A request was sent to TPG concerning the possibility to simulate these two concepts. Noreply or request for additional information has been received from TPG.

3.5. SIMMOD-TASIME vs TAAM

3.5.1. Introduction

This exercise aims at identifying the pros and cons of one model with regard to the otherone. Advantages and disadvantages of each model are analysed from the point of view ofmodel logic and functionality’s, as well as of effort to be spent to run a simulation with bothmodels.

Conceptual discrepancies have been identified between the two models. However, thiscomparison has not been focused on microscopic analysis, i.e. at the level of events generated by each model.

Because of limited timeframe, it has been out of scope of this exercise to run a calibratedstudy for BRU airport with SIMMOD. The results provided in this comparison are indicativeonly.

3.5.2. Brief Description of SIMMOD

In SIMMOD, the complete air and ground system is represented by a network of points andconnecting segments along which the aircraft 'navigate'. Along with other point qualities,an altitude is associated to each point. This altitude is usually derived from free profiles butcan be modified to represent, for example, height restrictions, SID’s, STAR’s, etc.

The simulation module is the core of the SIMMOD system. The module traces the "steps"through time and space of each aircraft defined in the traffic sample from one point to thenext along its route. Potential violations of any of the modelled separation requirementsbetween two or more aircraft moving towards a given point are detected and then resolved by adjusting their arrival times at the point. Depending on the importance of thisadjustment, the controller action deemed to be causing it is interpreted as either trackadjustment, speed control, holding or re-routeing of aircraft. Such specific occurrences asovertaking in the air, shuffling aircraft in the departure queue, as well as many other ATCprocedures and actions either on the aerodrome, in the approach/departure environmentor in en-route Airspace can be simulated by careful selection of the input parameters.


#


SIMMOD was designed in a very MS-DOS looking-like fashion. In order to get benefit ofa more up-to-date human-machine interface, a beta version of TASIME was used inconjunction with SIMMOD during this evaluation. TASIME is a new interface for SIMMOD,developed by the EEC, that aims at reducing and facilitate the data preparation processand displaying the simulation runs in a more user-friendly way.

3.5.3. Simulation Outputs comparison

The results provided by SIMMOD reporter were compared with the results provided byboth the TAAM RPF and the DFS Reporter. The comparison was based on the followingindicators, both for arrivals and departures:

! Hourly runway flow rate;

! Total ground travel time;

! Average ground travel time;

! Total ground delay;

! Average ground delay.

Table 7 includes the definition of each of these concepts and shows the difference between the concepts used by the two models.



Table 7: SIMMOD-TASIME vs TAAM – Conceptual comparison

In addition to these conceptual discrepancies, it is also to be mentioned that the aircraftperformance file was kept specific to each model. Differences in aircraft performancecould therefore cause some deviations in the results.


Arrivals

! Runway Flow

! Ground Travel Time

! Ground Travel Flow

! Average Ground Travel Time

! Ground Delay

! Ground Delay Flow

! Average Ground Delay

! Runway Flow

! Ground Travel Time

! Ground Travel Flow

! Average Ground Travel Time

! Ground Delay

! Ground Delay Flow

! Average Ground Delay

Sum of taxi time, any delays whiletaxiing and stand-off delays if arrival gate was not available atone (Ref.3, p96). This also inclu-des landing run.

Number of arriving aircraft onground during the considered period of time

Ground Travel Time averaged onRunway Flow

Total delay caused by:$ Approaching flow control$ Taxiing delay$ Stand-off delay

Counter triggered off by one of theevents that can cause grounddelay:$ Flow ETA (for sequenced delay)$ Start of taxiing delay$ Waiting for a gate

Ground Delay averaged onGround Delay Flow

Sum of taxi time on departure, anydelays while taxiing, and delays inline-up queue, plus take-off runtime (Ref.3, p96). Does not includeGate Delay.

Number of departing aircraft onground during the considered period of time

Ground Travel Time averaged onGround Travel Flow

Sum of gate delay, taxiway delayand runway delay

Counter triggered off by one of theevents that can cause grounddelay (i.e. modification of ETD)

Ground Delay averaged onGround Delay Flow

Counter incremented each time an arrival touches down the runway

Time spent on the ground from run-way exit to gate, including taxi timeonly

None

Ground Travel Time averaged onGround Travel Flow

Delay on the ground in excess ofthe arrival ground travel time(taxiing delay only)

None

Ground Delay averaged on RunwayFlow

Counter incremented each time a departure starts take-off run

Time spent on the ground from gateto runway entry, including taxi timeonly.

None

Ground Travel Time averaged onRunway Flow

Delay on ground in excess ofdeparture ground travel time, including departure queue delay

None

Ground Delay averaged on RunwayFlow

Departures

Indicator SIMMOD-TASIME TAAM


As far as runway flow rates are concerned, arrival flows are relatively similar, as shown inFigure 13. However, some deviation between the two models can happen for departures.TAAM seems to accommodate departures much faster than SIMMOD. Most of the time,excess in TAAM during one period is usually reflected in the next period in SIMMOD. Forinstance, a difference of 10 departures can be observed in TAAM between 8 and 9 amwith regards to SIMMOD’s results. However, this difference is opposite between 9 and 10 am with 9 additional departures in SIMMOD.


ARRIVAL AND DEPARTURE FLOW

0

2

10

33

40

23

16

27

32

20

16

3637

25

31

23

19

16 15

4

14

11

7

14

30

18

15

42

37

24

35

29

10

28

33

37

39

18

16

22

0

4 33

11

39

24

16

33

27

18 18

35

37

30

28

22

18 17

15

4

8

17

4

16

27

19

31

52

28

22

13

38

28

13

24

30

47

37

15

17

3

1

33

27

0

10

20

30

40

50

60

Time Period

FL

OW

ARRIVAL Rwy FLOW Simmod DEPARTURE Rwy FLOW Simmod ARRIVAL Rwy FLOW Taam DEPARTURE Rwy FLOW Taam

0-1

1-2

2-3

3-4

4-5

5-6

6-7

7-8

8-9

9-10

10-1

1

11-1

2

12-1

3

13-1

4

14-1

5

15-1

6

16-1

7

17-1

8

18-1

9

19-2

0

20-2

1

21-2

2

22-2

3

23-2

41

1

-1

1

6

-5

-2

2

-1

5

-3

-1

-1

1

-6

6

-3

2

-3

1

16

10

-9

-5

-11

3

-1

3

-4 -3

10

-2

-3

1 1

-1

-15

-10

-5

0

5

10

15

20

0-1

1-2

2-3

3-4

4-5

5-6

6-7

7-8

8-9

9-10

10-1

1

11-1

2

12-1

3

13-1

4

14-1

5

15-1

6

16-1

7

17-1

8

18-1

9

19-2

0

20-2

1

21-2

2

22-2

3

23-2

4

Time Period

Nb

of

Flig

hts

TAM

M V

s S

imm

od

ARR FLOW DEP FLOW

ARRIVAL AND DEPARTURE FLOW COMPARISONTAAM vs SIMMOD

Figure 12: Arrival and Departure Flow

Figure 13: Arrival and Departure Flow Comparison


Runways are automatically allocated in TAAM, not in SIMMOD. Differences in runway flowrates can happen when too many arrivals are manually allocated to 25R in SIMMOD. Thiswas confirmed by the runway allocation analysis. This has the effect to increase departureground delay (up to 42 minutes average).

Appendix 8 shows other results provided by the two models:

Comparing ground delays and ground travel times would be dangerous as the conceptsand the way these concepts are measured are quite different. For instance,

! Unlike SIMMOD, ground travel times in TAAM includes landing and take-off run;

! Ground travel time includes ground delay in TAAM, not in SIMMOD;

! Approaching flow control are imputed to ground delay in TAAM as it is caused byground constraint;

! Averages concerning ground delay and ground time are based on runway flow inSIMMOD. However, this assumption can yield to some delay/ground time imputed tosome flights which have not been delayed or which were not on the ground during theconsidered period of time.

To conclude, TAAM and SIMMOD are two completely different models, both from theconceptual and the design points of view, and direct comparison has proved difficult.Similar traffic samples were used in this comparison; nevertheless, aircraft performancewas specific to each model. A full comparison would require an event-based and logarith-mic comparison, what was out of scope of this evaluation.

3.5.4 Technical comparison

Criteria SIMMOD-TASIME TAAM

! User-friendliness Actual version: good Very good

Will be improved.

! Semantic Check/validation Good except for linked flights. Very good,

except for linked flights.

! Syntactic Check/validation Good. Very good,

except for linked flights.

! Trajectory Predictor Not included; must be specified Included; 4-D profiles

in 4-D profile file are calculated

! Gate Allocation Dynamic or manual. Dynamic

! RWY Allocation Manual. Dynamic

! Conceptual Architecture ! Traffic sample ! Waypoints

for flight data ! Waypoints/Navaids ! Routes

! Routes build manually ! Traffic sample

(one route per profile).

Table 8 : SIMMOD-TASIME vs TAAM – Technical comparison

It is to be noted that SIMMOD was designed as a "quick look" simulation tool. For instance,SIMMOD does enable conflict resolution during a simulation by changing an aircraft's level.



3.5.5 Effort consumption

Effort and time required to run a simulation is difficult to be assessed as it depends verymuch upon many different factors, including amongst others, the airport simulated, itslayout and operational complexities, the user’s expertise and the clients' requirements.Nevertheless, in order to give a rough estimate, effort and time have been assessed forthis specific exercise with both SIMMOD-TASIME and TAAM.

70 to 80 man-days were required to run the baseline scenario with TAAM, including TMA,while 60 man-days represent the effort spent with SIMMOD-TASIME by EEC experts forthe same exercise, with limited departure and arrival procedures.

Fifty (50) days is the generic assessment planned for a baseline scenario by TPG in Ref 1.

The rationale of any airport study is usually not only to assess capacity of a baseline scenario, but also to look for capacity improvements (or delay reduction) through assess-ment of alternatives and/or sensitivity gravitating around this baseline. For any additionalbaseline scenario including turn-arounds (e.g. change the runway-use configuration),SIMMOD-TASIME requires 30 md while 2 to 4 md is only necessary with TAAM. A minorsensitivity analysis has been estimated at 5 md with SIMMOD-TASIME and only half a mdwith TAAM.



4. EN-ROUTE & TMA PART

4.1 DESCRIPTION OF THE EN-ROUTE/TMA SUB-PROJECT

4.1.1 Introduction

The TMA/en-route project was conducted at the EEC. It took place from October 1999 tomarch 2000 and was identified in the work program as task SIM-S-E1 TAAM. The SIM service is managed at the EEC and receives the simulation request from the member states and other clients.

All details relating to the En-route/TMA sub-project are available in Ref 8

4.1.2 Criteria

The criteria of assessment addressed 2 main subjects:

! Technical capabilities of the tool;

! Opinion of the operational experts on the conviviality and usability of the systembased on their simulation expertise.

4.1.3 Typical simulation request

A typical request of airspace fast-time simulation contains generally the following elements:

! Several levels of traffic to simulate;

! Several airspace organisations to test;

! Impact of various levels of equipment used by the controllers on their workload;

! Military requirements.

4.1.4 Typical Simulation results

The results of a simulation project relate mainly to the following items:

4.1.4.1 Number of flights per sector

! Aircraft movement counts (hourly, or every 10, 15, 30 min) in each sector;

! Peak and average number of aircraft in each sector;

! Average time aircraft spent in a sector;

! Clipped and skipped flights, i.e. flights entering a sector and either ignored (clipped)by this sector or not controlled (skipped) by this sector. In case of a skipped sector,some ATC tasks have to be registered for the skipped sector;

! Aircraft flight times from take-off to touchdown;

! Calculation of ATC sector capacities.

4.1.4.2 Sector working times

! Routine tasks attached to each flight (First call, last call…);

! Flight data management tasks;

! Number of co-ordination actions of specific types;



! Civil/military co-ordinations and more generally co-ordinations between simulatedunits (sectors, centres) and between simulated and non-simulated units (e.g. militaryunits or local airports);

! Radar tasks attached to conflicts and monitoring.

4.1.4.3 Controller workload

! Calculation of the workload per sector and per working position.

4.1.4.4 Analysis of conflicts

! Distribution of the conflicts over the simulated area;

! Conflict resolution mechanisms in CVSM and RVSM environment (level change,radar vectoring, …).

4.1.4.5 Penalties on the flights (such as delays)

! Average delay per departing aircraft and delay per arriving aircraft;

! Overall shape of the delay graph plotted over the simulation period;

! Simulation of en-route holding (when a terminal stack is full).

4.1.4.6 Capacities

! Maximum number of aircraft which may enter in a sector per hour.

4.1.5 Simulated projects

In order to extract these results, various projects have been set up and run for the eva-luation of the en-route TMA part. They are described in the following chart:

Figure14: Project chart



4.1.5.1 Base organisation

Two projects were part of the base organisation.

A) F24 project

The aim of the base organisation was to simulate with TAAM the same data as those usedfor the F24 simulation project run with RAMS at the Experimental Centre in 1998. Themain objective of this base organisation was to compare globally the results obtained withthe 2 simulators.

The data used were recovered from what was given by ANS of the Czech Republic andwas the following:

! A 1124 flight actual traffic sample;

! Five en-route sectors (general level split set at FL325);

! Two approach sectors;

! Route network defined by the flight paths followed by aircraft in the traffic sample.

Figure 15: Sector maps

B) Reference project

In order to conduct the further steps of the evaluation in a more efficient way, with moreunderstandable data, a reference project was set up. The data used for this project wasextracted from the F24 project (traffic from 10h00 to 11h00, 34 flights). The reference project was used as a basis to build the various projects described below.


WSU

NEU

BAY

BERVA

MIKOVASTUT

BNO

DBV

DRN

HDO

HLV

HOLAN

LEG

NER

KADNO ETATU

ODNEM

BIRMO

OKF

BODAL

OKG

KILNU

MAREM

OKL

OKX

RAK RASIM

RDG

CERNO

KOLAD

KESOR

SLCSTO

TBV

VESOX

VLM

VOZ

WGM

ZAB

PADKA

CZECH Republic AirspaceEn route Sectors / Upper airspace

LKKV TMA

LKPR TMA

LKCSTMA

TMA SE

LKCV TMA

LKPD TMA

APP-NORTH

APP-SOUTHBAY

BERVA

MIKOVASTUT

BNO

DBV

DRN

HDO

HLV

HOLAN

LEG

MDF

NER

ODNEM

BIRMO

OKF

BODAL

OKG

KILNU

MAREM

OKL

OKX

RAK RASIM

RDG

CERNO

KOLAD

KESOR

SLSTO

TBV

VESOX

VLM

VOZ

WGM

ZAB

PADKA

CZECH Republic Airspace TMA sectors

DIR 0,85 / APP. NORTH 85,145

DIR 0,85 / APP. SOUTH 85,145

WL

NL

SEL

BERVA

MIKOVASTUT

BNO

DBV

DRN

HDO

HLV

HOLAN

LEG

MDF

NER

KADNO ETATU

ODNEM

BIRMO

OKF

BODAL

OKG

KILNU

MAREM

OKL

OKX

RAK RASIM

RDG

CERNO

KOLAD

KESOR

SLCSTO

TBV

VESOX

VLM

VOZ

WGM

ZAB

PADKA

CZECH Republic AirspaceEn- route sectors / Lower airspace


4.1.6 The CTL (Control) project

The objective of this project was to address the capabilities of TAAM to simulate variousgeneric ATC issues listed below:

! Sector clips and skips: flights being for a short time in a control sector with variousworkload model;

! Conflict detection/resolution mechanisms;

! Working methods: special workload modelling according to the simulated equipment;

! Regulation points: special conflict detection/resolution rules for a sector A deliveringtraffic into sector B, along 2 routes, separated in sector A but conflicting in sector B;

! Opposite Direction Levels (ODL): all flight levels are available in a particular directionfor a specified route, irrespective of existing rules;

! Traffic cloning: increase the volume of the traffic sample to represent future amountof traffic;

! Airspace classes: feasibility of simulating the various airspace classes with appropriate rules for IFR and VFR flights;

The traffic sample used for the CTL project was the one established for the reference project. Total 34 flights.

4.1.7 The TMA project

This project was designed in order to evaluate the TAAM capabilities to model TMAfeatures. These features are listed below:

! Holding stacks management;

! Runway management;

! Sequencing at the runway;

! Conflicts in TMA;

! Airport operations;

! Gate to gate capabilities: simulate in the same simulation exercise 2 airports with traffic between them. Analyse the impact on the traffic of restrictions between the airports or in one of the 2 airports;

! Dual runway operations at Praha airport: modification of runways in use at Praha airport for landing traffic;

The traffic sample used for the TMA project was the one established for the Referenceproject. Additional traffic was included to reach a total of 106 flights.

4.1.8 The R&D project

4.1.8.1 Introduction

The idea behind this project was to evaluate the flexibility offered by the tool in view of newconcepts to simulate. This depends, inter alia, on the functioning of the loop between theusers, the TAAM steering group, and the team in charge of the software.



Another aspect covered was to identify the possibilities of extending the scope of the cur-rent fast-time simulations run at the EEC to other domains. This was not initially part of theproject management plan but has been added after the beginning of the evaluation.

4.1.8.2 Contents

The following exercises were contained in the R & D project:

! Multi Sector Planning: responsibility for an additional controller to balance the trafficbetween a set of adjacent sectors according to the predicted tactical controller workload in the given sectors;

! Economical: cost estimates for supplying capacity, costs of delays, costs of optimi-sation of capacity increase for an ATCC. Analysis and estimation of complexity fortypical ATCC’s;

! ATFM: capabilities of the tool to simulate flow management aspects;

! Capacity: capabilities of the tool to calculate sector capacities;

! Safety: capabilities of the tool to provide the elements needed for safety metrics;

! Environmental: possibilities of using the tool for environmental studies;

! FMS: identify behaviour of FMS equipped aircraft.

4.1.9 The military project

The military project was designed to evaluate the TAAM capabilities to simulate militaryrequirements. These requirements were either coming from the specifications received forthe F24 project or from the EUROCONTROL Military Unit (EMEU) in Headquarters. A fulldescription of EMEU requirements for the future is available in Ref 8. The main specifica-tions from F24 covered the following generic military requirements:

! Implementation of military zones;! Modification of civil routes in order to avoid (geographically or vertically) military

areas;! Particular co-ordinations with military units;! Implementation of military traffic;! Conflict resolutions between civil and military traffic.

4.2 RUNNING A PROJECT USING TAAM

4.2.1 Introduction

One of the first things to do when starting a simulation project is to gather, to analyse andto prepare the data to be put in the simulation system. It is of major importance to verifythat the input data contain the necessary and valid elements to reach the objectives of thesimulation.

The analysis of the input data is part of the project but not fully of the simulation. It is gene-rally done using external tools such as Microsoft Excel, allowing statistical assessments.Additional elements to verify can only be obtained with initial runs of the data using thesimulator. A good example of verification is the correct sector sequence for the flights tovalidate the airspace versus traffic.



4.2.2 Data preparation


The data preparation is an element common to all simulation projects. The commentsgiven below apply to all projects run during the operational evaluation. The IDIS moduleof TAAM is dedicated to the preparation of the simulation data.

4.2.2.2 Traffic samples (F24 CTL TMA R & D and Military projects)

The data used came from the RAMS simulation of the Czech Republic (EEC task F24).These data were tabulated in Excel and had to be converted into the TAAM format. Thehelp of other TAAM users has been very useful and efficient for this task. Nevertheless,some additional internal effort was required to finalise the conversion work. As for anyother fast-time simulator, there is a need of a software expert for the modification and thedevelopment of the appropriate filters.

In the TMA project, flights have been added manually to the traffic sample in order to havethe appropriate flows of traffic between Dresden and Praha airports. These flights havebeen either generated with Excel and then converted to TAAM using the existing filter, ordirectly generated with TAAM. The same procedure was applied for the military traffic.

In the ATFM project where the number of flights in the traffic sample was significant (25000flights per day, then 52000 flights), the data has been taken from the CFMU recordingsavailable at the EEC (data from 03/09/1999). The conversion to the TAAM format hasbeen done using appropriate filters developed at the EEC. A difficulty concerning the timesgiven in the traffic had to be overcome.

One major element of the traffic sample is the route which is followed by the aircraft. Inorganisational simulations, this route is modified from one scenario to another accordingto the route network simulated. The modification of the data for the traffic in terms of routes can be done internally to TAAM using the route editor. This is a convenient facility.

No particular remark has to be made about the aircraft performances. The need of havingsame data for real and fast-time simulations is neither better nor worse accomplished thanwith another simulator. The data contain all the needed elements.

Some facilities to analyse the traffic which is input in the system are not contained inTAAM, this has to be done outside of the simulator using programs which are developedeither by other TAAM users or by the simulation team. As an example, visualisation of theroute network according to the traffic density.

The following chart shows how traffic samples were used in the various projects.



Figure 16: Traffic sample usage

4.2.2.3 Flight level restrictions

The levels of the flights is an important data in fast-time simulations. The levels are generally imposed by the traffic sample provided by the client or by special procedurespublished by Air Traffic Control authorities.

Difficulties were encountered while trying to reflect in the TAAM data some elements whichwere compulsory for aircraft such as flight level requested, time over particular entrypoints. A data integrity mechanism on these level modifications should be available and isnecessary.

Flight level requested: the TAAM system often modifies the flight profiles according to theperformance tables which are integrated in the system. This is a major constraint whenthe flight profiles have to be set at a particular determined level.

Restricted flight levels: a regular constraint while having to simulate an airspace is to oblige the flights to be at particular levels over particular points. The reasons for these restrictions come often from agreements between ATC authorities. Difficulties have beenencountered for these implementations and solutions provided by other TAAM users(lengthen SID’s or/and STAR’s) were proposed. This could be feasible but not very correctsince procedures which did not exist had to be defined to make the model work.

A better control of the mechanisms of flight level allocation/imposition should be available.

4.2.2.4 Entry times

TAAM considers the entry times as ETD’s from the airports whereas the RAMS data consi-ders times over the first simulated point. Some time was spent to adjust the entry times.This can be a problem for passing from one model to another but not for a new simulationwhere the requested data has to be correctly specified. The content of the data requestedto make the study depends on the tool used to make the simulation.


07 08 09 10 1411 12 13 171615 1918

DC PR PR DC Airport usage

Twy managt

RWY cadence

Gate occ time

RWY31

TMA

07 08 09 10 1411 12 13 171615 1918

REF

07 08 09 10 1411 12 13 171615 1918

CLIP (no strip)

SKIP (strip)

CTLNo strip

OLDI

No planner R/T

ODL

Regulation point

07 08 09 10 1411 12 13 171615 1918

Zone 1 Geog

Zone 2 Vertical

Axis: Mil skip Civil

Mil change profile

MIL

07 08 09 10 1411 12 13 171615 1918

R & D F 2 4 T R A F F I C

TRAFFIC SAMPLE USAGE

F 2 4 T R A F F I C


4.2.2.5 Airspace design

GTOOL is integrated in TAAM and is a module to design the airspace and the various procedures to be simulated (SID’s, STAR’s…). It is used as well for airport layout. A digi-tizer is also available. The import of external files is also possible.

As with every tool of this nature, an expertise in its use is needed to judge its efficiencyand capabilities. The evaluation team encountered big difficulties in the beginning due tosoftware which was not correctly set up, especially during the first training session. Anyobject necessary to the simulation project can be defined using GTOOL. Compared withexisting RAMS facilities, the use of GTOOL seemed difficult but this remark is mainlybased on the fact that unnecessary time was spent on the manipulation of this TAAMmodule. Experienced GTOOL users have become accustomed to the tool and are able touse it to good advantage.

4.2.2.6 Airspace operations

The definition of the usage of the airspace can be made either by modifying the data orthrough a rule mechanism which is incorporated in TAAM. The rule interface is easy to usefor operational experts as a lot of options are predefined. The rules can be used at variouslevels and can be implemented for almost all the elements where the user wants to reflectparticular operations. This is a very powerful system which requires careful use, sincerules not stringently applied may lead to contradictory situations. The syntax of the rulesis not intuitive and there is no control mechanism.

4.2.2.7 Software aspects

The organisation of the files in TAAM is done through a project file manager. This allowsthe selection of the particular files required for the project. This manager needs to be usedcarefully and allowed the simulation team to use the specific file they wanted. All the filesrelating to the projects were available and no mechanism of protection is implemented toprevent a user to modify a file which does not belong to one of their projects.

It was identified during the evaluation that a dedicated software expert has to be part ofthe simulation team.

4.2.2.8 Conclusion data preparation

IDIS is the module integrated in TAAM for the preparation of the data. The preparation ofthe projects with IDIS is feasible. Nevertheless, a lot of users have developed their ownpre-processing facilities for the data. These developments are generally available for theother users.

The preparation of the data for the evaluation was the first ever TAAM simulation done atthe EEC. In consequence, some of the difficulties encountered resulted from the learningprocess.

There is a significant restriction in the data preparation with TAAM. The data that the userwants to simulate may be automatically modified by TAAM according to its own criteria.The modification of some flight levels is the most worrying one due to its impact on thesector sequence that these modifications can generate. A very thorough data validation isrequired to ensure any unnecessary modifications are corrected.

The preparation of the data is always a lengthy process and the appraisal of the convi-viality of the process depends on the expertise of the user along with his knowledge of thesystem used.

A general remark about the preparation of the data with TAAM is that the data validation



with TAAM can be achieved in a very different way than the one done so far with fast-timesimulations at the EEC. TAAM is equipped with a very efficient and powerful graphical sys-tem which can be used extensively in many aspects, and particularly for the data valida-tion. When working with air traffic controllers, this can be a fastidious process if the datais validated using standard facilities (listings, etc…). TAAM’s combination of internal rulesand graphics is a real advantage when working with a population accustomed to workingwith radar screens. TAAM offers the possibility of presenting snapshots for given situa-tions. This can be used for the validation of the data.

The TAAM community is composed of plenty of users who have developed their own toolsto analyse the input data. These tools can generally be used by other TAAM users but maynecessitate modifications to be applied to specific local needs.

A software support is strongly recommended for the file management and the support tothe operational usage.

Another aspect of the preparation of the data with TAAM is that there is a need for co-ordi-nation between the projects if several are run. There are restrictions attached to the useof TAAM modules, for example IDIS for data preparation. In case of using a single TAAMlicence, only one user at a time can use a module.

4.2.3 Simulation


Once the data has been prepared, it is used in the simulation module to navigate the flightsin the modelled airspace. This process is reiterated several times to tune parameters sothey reflect correctly the behaviour of the actors. Therefore, the simulation module is usedfor both reflecting a new scenario and to validate the base line. Two main features werepart of the simulation: conflict detection and conflict resolution. The quality of the resultsis very dependant on the correct application of the conflict detection mechanism and to alesser degree conflict resolution.

4.2.3.2 Conflict detection

The conflict detection is performed in TAAM at many levels. In the air, the conflict detec-tion is done using a ghost aircraft flying on the same flight path x minutes ahead of the“actual” aircraft. When the distance between 2 ghost aircraft is less than the parametersdefined for the sector, a conflict between the aircraft is detected. The important factor isthat the conflict is detected, the subsequent resolution may or may not take place.

The conflict detection, in the reality of ATC, is subject to variable set of conditions whichmay depend on several variables specific to the type of sector, the nature of the trafficetc… It is therefore very difficult to implement a system coping with all the particular situations. The conflict detection implemented in TAAM works efficiently and has givencorrect results for the items analysed during the EEC evaluation. Nevertheless it has to benoted that the main parameter for conflict detection in TAAM is the look ahead distancewhich is unique for all the sectors. This could lead to limitations if different parameter thanhorizontal or vertical distances were to be used for the conflict detection in different sectors of the same simulation project.

The conflict detection is done at many levels including before leaving the gate, along taxiways, prior entering the runway. This gives a global analysis of the situation (e.g. holding on the ground…).



4.2.3.3 Conflict resolution

Once the conflicts have been detected, the user may ask for conflict resolution. Conflictresolution allows the recalculation of the flight profiles and generate better accuracy forflight profiles.

The modification of the flight path due to the conflict resolution is really important whenthis modification may introduce a change in the sector sequence for a flight. When themodification relates only to the trajectory of the flight inside the initial sector, it is more theworkload attached to the path modification which is important to record than the trajectoryitself. Indeed, trajectory modifications are highly dependant on factors difficult to replicate(human factors, meteorological conditions, …) and a conflict resolution which seems correct to one controller may not seem correct to another.

As in any fast-time simulator the resolution of the conflicts with TAAM is sometimes notrealistic. Experienced European TAAM users recommend and do not use the conflict resolution for their simulations, especially when working with air traffic controllers who areoften concerned by a proper mechanism to reflect the reality of their work.

The resolution of the conflict works well when the situation is simple. When the situationis complex, the resolution is one of the most difficult things to model and this makes therules very hard to set up. Nevertheless, there are rules integrated in TAAM to solve theconflicts which are found by the system.

4.2.3.4 Speed of the system

The speed of the system is directly related to the type of hardware on which the simula-tor is installed. For the evaluation, Sun ultra spark 5 workstations were used using SolarisCDE version 1.3. The simulations have run with good performances, even the projectcontaining 50000 flights with 900 sectors (4 hours and 50 minutes).

Multiple run: TAAM offers the possibility of running several runs of the same data with randomization to generate more statistically reliable results.

4.2.4 Analysis and results

4.2.4.1 General results

TAAM contains an integrated module (Report Presentation Facility) for the generation ofthe reports of the simulation. During the operational evaluation, the Preston group recom-mended the team to use as well the DFS reporter analysis tool.

A) Number of flights

The number of flights per sector is a standard result of a fast-time simulation. The accu-racy of this result is particularly important since the number of flights is the basic factor fora lot of calculations, such as all the routine tasks performed by the controllers, capacitycounts, thresholds...

Numerous verifications have taken place during the evaluation and the results obtainedare correct, provided the data were correctly implemented and validated.

B) Sector working times

Existing EUROCONTROL modelling tools are event driven and produce data on sectorworking times. The sector working time represents the total amount of time which isnecessary for handling the traffic of a particular sector in the simulated conditions. To com-pute this value, it is necessary to have a mechanism identifying and measuring the tasksperformed by the controllers of the simulated sector.



The working time is not computed in TAAM. TAAM has other means than time to calcula-te the workload.

C) Controller workload

The workload features which are implemented in the RPF relate to the entire simulatedairspace. The workload calculation is based on conflict severity, traffic situation and co-ordinations. This is made without identification of any centre/sector, except for the co-ordinations. As recommended, the workload for the evaluation has been generatedusing the DFS reporter which contains more functionality’s particularly for conflict description.

The setting of the DFS workload variables is done using sliders and is convivial.Nevertheless, the modelling does not reflect the actual actions of the controllers (tasksversus execution times). It is set for the whole sector disregarding the number of workingpositions. A planning controller is not yet implemented.

D) Analysis of conflicts

The DFS reporter can display the conflicts recorded over the simulated area or for a specific sector. Conflicts are sorted according to the aircraft attitude and the number ofconflicts reported.

E) Penalties on the flights

Delays are stored during the simulation run. The vertical penalties are recorded but notdirectly available without additional post-processing.

F) Capacities

Capacity is determined in TAAM using the maximum number of aircraft that a sector canhandle at any time. This does not correspond to the European definition of sector capacitywhich is a number of entering flights in a sector over a time period. Nevertheless, the TAAMcapacity can be used with the rules to model particular airspace conditions.

4.2.4.2 CTL Project particularities

The CTL project contained particularities which are analysed below:

! Sector clips and skips reflect short flight times in sectors with particular control conditions. This is not directly feasible with TAAM but can be done with appropriatedevelopments to process the output files;

! Regulation points: special conflict detection/resolution rules for a sector A deliveringtraffic to sector B along 2 routes. This facility is not part of the tool. Some workaroundis possible using the capacity implemented in TAAM but there are questions on howto implement the rules;

! Traffic cloning: traffic cloning is used to increase the traffic simulated to future levels.A facility exists but is not powerful enough. The cloning should be done externally;

! Airspace classes: TAAM can simulate VFR and IFR traffic with a switch for conflictdetection. The airspace classes (A, B, C, D, E, G) are not identified in the simulator;

! Dynamic resectorisation: TAAM allows the modification of the sectorisation during therun of any exercise.



4.2.4.3 TMA project particularities

! Holding stacks: the stacks are used to absorb delays for traffic inbound to airports. Aholding stack freezes all the airspace allocated with a particular conflict detectionmechanism. The management inside the stacks is flexible and a partial pattern is possible for realistic simulation of the holding flights.

! Runway management: a large number of parameters allow the simulation of very realistic runway management. These parameters encompass crossing, relationship,occupancy for simulated runways. The behaviour of aircraft using the runway is partof the default settings of TAAM and is linked to aircraft characteristics.

! Sequencing at the runway: the sequencing for arriving aircraft at a runway is determined using parameters which allow a realistic modelling. The sequencing, asin reality, has flexibility until a defined distance from the runway where the sequenceof traffic will be fully established. A nice facility is the “trombone approaches” allowingthe vectoring of aircraft to the runway in a given volume of airspace without holding.

! Conflicts in TMA: the conflict detection in the TMA uses the same characteristics asfor en-route. The separation for wake turbulence purposes is taken as a prime constraint. The mechanism for level allocation in stacks does not systematically givethe most appropriate result but the reflection of the reality is very hard to achieve.

! Airport operations: for the part which has been done at the EEC, the airport operations seem to work properly but have not been evaluated in detail.

! Gate to gate approach: two airports (Dresden and Praha) were fully simulated including aprons and gates. Traffic has been added between these 2 airports to makea busy city pair. A capacity constraint (maximum number of aircraft instantaneously inthe sector) has been modelled in one of the in between en-route sectors. Excesscapacity was not allowed and aircraft were delayed at their gate at the departing airport. The appropriate result has been obtained. Similar results have been obtainedwith a reduction of the landing rate at the arriving airport.

! Dual runway operations: for a part of the simulated period, a second runway at Prahawas opened for arrivals. The whole airport was managed properly after the appro-priate setting of parameters and rules. Change of runway in use at an airport can alsobe made during the run of any simulation exercise.

4.2.4.4 R&D project particularities

The R & D project retained the Multi Sector Planning which is part of improvements to ATCin the next future. The concept of MSP does not exist in TAAM and wasn’t developedduring the time frame of the evaluation.

Basic specifications were given to TPG at the beginning of the evaluation. A discussiontook place on how R & D aspects could be covered in any future development. A sampleenhancement task was sent back by TPG based on the MSP. It illustrates typical proce-dures to be applied for future developments. They can be categorised into 5 categories:

! An enhancement is already included in the TAAM development schedule and EUROCONTROL is prepared to wait till it is implemented in due time;

! An enhancement is already included in the TAAM development schedule but EUROCONTROL wishes to expedite its implementation;.

! An enhancement is not included in the TAAM development schedule; TPG is prepared to add it to the development plan but set the implementation time accordingto its own priorities, and EUROCONTROL is prepared to wait till that time;

! An enhancement is not included in the TAAM development schedule; EUROCONTROL



wishes to expedite its implementation for a fee, and TPG is prepared to do that;

! An enhancement proposed by EUROCONTROL is deemed unfeasible for implemen-tation in TAAM by TPG, e.g. due to very high cost of implementation, large-scale effortrequired, and limited business benefits.

The MSP proposal is the following, italic font is extracted from the Sample TAAM enhan-cement task written by TPG. The full description is given in Ref 8.

The proposed MSP functions can be simulated in TAAM and their implementation, whilenot exactly trivial, appears to be technically feasible.

Quote for the Requirements Specification & Test Case development

The estimated effort for the MSP Requirements Specification and Test Case Developmentis as follows:

VP Air Traffic Systems 4 days 6000 €TAAM Project Manager 4 days 4800 €Softw.Eng. / Snr. Softw.Eng. 30 days 21000 €Total 31800 €

Tentative Estimates for the Entire Project

We (TPG) estimate that the total effort required for the implementation of the Multi-SectorPlanning functionality, including Project Plan, Acceptance Criteria, Design,Implementation, Testing and Delivery, would be in the order of 5 (five) man-months.

The estimated total cost for the above would be in the order of 90000 €.

The above does not include the costs listed in “Quote for the Requirements Specification& Test Case development” Section. With those costs added, the total cost for the entireproject would be in the order of 122000 €, plus any applicable travel expenses.

4.2.4.5 Military project particularities

Military areas and routes can be simulated with TAAM while applying to the GAT flights theappropriate routes and levels to avoid the activated areas.

Co-ordination with military units; the impact of appropriate standard co-ordination can begenerated using the DFS reporter or the TAAM RPF.

Military traffic: military traffic has been manually added. Aircraft performances had to bemodified accordingly.

Conflicts: the simulation of the military flights under military control within a civil sectorcould not be properly modelled. It was not possible to resolve the military element of acivil/military conflict.

Future military requirements: the necessary data will have to be developed for moderncombat aircraft performances. The dynamic sized areas for military activities could be doneusing the dynamic re-sectorisation. The need to simulate OAT with special handling wouldrequire further development. The requested output information does not exist. The gene-rated data could be used for the development of an appropriate post-processing facility.

4.2.4.6 Other projects

Economics: data used for economic aspects were identified. They offer a perspective onthe relationship between, aircraft number and attitude, conflict and sector pierce, for



airspace complexity analysis. They relate to type of aircraft in each ACC for cost estimateof delays. The data exist in TAAM output files but would have to be processed to be usedfor economic studies. No practical example was achieved due to time constraints.

ATFM: during the evaluation a traffic sample similar to those used for ATFM studies (24hCFMU traffic) has been simulated. It contained 26700 flights and more than 900 elementary control sectors. This was simulated in a 2h30 time period (no conflict check).For testing purposes, the traffic was cloned to 45390 flights and run in 4h50. Specific sectors have been analysed and the results (number of aircraft per sector) have beensatisfactorily compared to those obtained with AMOC, a tool generally used for ATFM studies. The results obtained for 6 selected sectors are available in Ref 8. The notion oftraffic volume, which is the basis for ATFM restriction implementation, does not exist inTAAM. This notion might be approached using integrated functions (in-trail).

Capacities: this project was aimed at using TAAM for assessing sector capacities (number of entering flights in a sector per one hour). No single agreed official method isavailable for capacity calculation. No function is currently available in TAAM. If based onworkload, this could be developed using workload computation with the setting of appro-priate threshold(s).

Safety: a short trial using the TAAM model-based simulator was carried out at the EUROCONTROL Experimental Centre, Brétigny. The purpose of the trial was to determinewhether the quantities needed for the safety metrics could reasonably be obtained and theproposed process for using simulations to evaluate the metrics was reasonably practical.The full requirement from Safety Experts is available in Ref 8.

The volume and detail of data recorded by the TAAM Simulator indicates that data neces-sary for analysis related to safety should be available. Processing for safety analysis ishowever not developed.

Environment: a successful transfer of TAAM outputs to the Integrated Noise Model wasmade. The data necessary to position the aircraft in a 4 D profile are stored in the TAAMoutput files. The following chart has been produced using TAAM results. Other resultsobtained are available in Ref 8.

Figure 17: Noise Footprint


B73S - DepartureNoise Footprint (SEL)

70 dBA

75 dBA

80 dBA

85 dBA

90 dBA

5 nm i


4.3 RAMS and TAAM

4.3.1 Introduction

One main objective of the operational evaluation was to compare the results found withTAAM to those obtained using RAMS. The PMP considered the comparison in the following domains:

! Number of flights per sector;

! Sector working times;

! Controller workload.

This document retains the results for 2 selected sectors (upper and lower). The results forthe 5 other sectors of F24 project are available in Ref 8.

4.3.2 Number of flights per sector

The behaviour of a flight may be different in the 2 simulators. RAMS is able to identify theflights which stay in a sector for a short time, less than one minute in the F24 project.These flights are the clip flights shown at the top of the histograms. This facility does notexist with TAAM results. If needed it could be developed based on the output files content.

The differences between TAAM and RAMS results come mainly from the different aircraftperformances which are used in the two models. The aircraft performances generate different flight profiles. For instance, the Berlin in-bounds transiting through the upperCzech airspace penetrate NEU sector only with RAMS and NEU and NL sector with TAAMbecause they start descent earlier with TAAM. The same phenomena applies for otherflight routes and this explains the differences between the results found with the 2 models.

The following charts show the number of aircraft per sector obtained with the 2 models for2 sectors.

As explained above,there are limited diffe-rences for the numberof flights per hour for theWSU sector (upper en-route sector).


Sector WSU

number of flights

26 2724 23

28 28

34 33

29 29

24 23

28 27

33 3432 32

27 2628 28

33 32

14 15

8 9

2

22

11

1

2

2

0

5

10

15

20

25

30

35

40

0700

-080

0

0800

-090

0

0900

-100

0

1000

-110

0

1100

-120

0

1200

-130

0

1300

-140

0

1400

-150

0

1500

-160

0

1600

-170

0

1700

-180

0

1800

-190

0

1900

-200

0

2000

-210

0

Nu

mb

er o

f fl

igh

ts

TAAM

RAMS clip

RAMS

Figure 18: WSU sector number of flights


The chart shows the num-ber of aircraft in the NLsector (lower en-routesector). There are diffe-rences between the 2models which relatemainly to the high num-ber of clipped flights inRAMS. The flight profi-les obtained for arrivingtraffic to Praha do notmatch due to aircraftperformances.

The examples show one upper and one lower en-route sector. The other sectors can beseen in Ref 8.

4.3.3 Sector working times

4.3.3.1 Working time modelling

RAMS allows the calculation of the working times using the ATC tasks defined in consul-tation with the simulation team and national experts. These tasks are expressed in number of seconds to execute each ATC task. For instance, the first R/T call (radio com-munication) of an aircraft entering a sector was established at 10 seconds for the radarcontroller, including the answer. This action in TAAM is not identified but is reflected in theworkload calculation formula as part of a global “movement workload”.

The working times in RAMS are dispatched into 5 categories: flight data management, R/Ttasks, conflict search, co-ordinations, and radar tasks. They are expressed in seconds. InRAMS, the working times can be calculated for the global sector or for each of the working positions. In the evaluation, the sector value has been used.

With TAAM, the workload calculation can be made using the TAAM reporter “RPF” or theDFS reporter. The evaluation, as recommended by TPG, has used the DFS reporter whichis more detailed and precise. The factors considered by the DFS reporter to achieve theworkload calculation are: movement workload (WL1), level change (WL4), co-ordinations(WL3) and conflicts (WL2). Parameters are attached to each factor to calibrate its influence.The working time as such does not exist .The workload assessment can be done only atthe level of the sector. The result of the workload calculation using the DFS reporter isgiven in points.

Considering the above, the following section compares the distribution of the analysedfactors of TAAM to the pseudo equivalent categories of RAMS for WSU and NL sectors.

4.3.3.2 RAMS TAAM workload distribution

The pie charts show the distribution of the sector working times according to the 5 cate-gories for RAMS and to the 4 factors for TAAM. The percentage for each slice is shownon the side. These charts DO NOT REPRESENT at all THE LEVEL OF THE WORKLOAD whichwill be analysed later.


Sector NLnumber of flights

12

17 1719

1415 15

1821

25

13 14 14 13 13

1614 14

18 1715

14 1416

11 12

5 6

23

3

3

9

22 5

1

83

1

1

1

0

5

10

15

20

25

30

0700

-0800

0800

-0900

0900

-1000

1000

-1100

1100

-1200

1200

-1300

1300

-1400

1400

-1500

1500

-1600

1600

-1700

1700

-1800

1800

-1900

1900

-2000

2000

-2100

Nu

mb

er o

f flig

hts

TAAM

RAMS clip

RAMS

Figure 19: NL sector number of flights


The colour coding has been selected to indicate the common characteristics betweenRAMS categories and TAAM factors. The main element for TAAM is the movement workload which takes into account the repetitive actions undertaken by the controllers foreach flight in the sector. The altitude clearance workload is also part of these routine tasks.In RAMS, the routine tasks are divided between the R/T communications, the conflictsearch, and the flight data management categories. In addition to RAMS, TAAM takes intoaccount the time spent by the flights in the sector as a parameter for the movement workload.

Two categories are shown as being common between the 2 models:

! The conflict workload of TAAM and the radar workload of RAMS. The only differenceis that in the RAMS simulation, some radar monitoring tasks were recorded routinelyas part of the radar work. This is one explanation for the higher percentage found withRAMS;

! Co-ordinations in RAMS and TAAM. They were not modeled the same way. It was


Sector WSU Workload distribution

TAAM

4%13%

3%

80%

Conflict Workload

Coordination Workload

Alt Clearance Workload

Movement Workload

Sector NLWorkload distribution

TAAM

7%

12%

2%

79%

Conflict Workload

Coordination Workload

Alt Clearance Workload

Movement Workload

Sector WSU Workload distribution

RAMS

18%

8%

36%

17%

21%

Radar

Coordination

R/T communication

Conflict Search

Flight data management

Sector NLWorkload distribution

RAMS

19%

11%

38%

16%

16%

Radar

Coordination

R/T communication

Conflict Search

Flight data management

Figure 20: WSU sector workload distribution

Figure 21: NL sector workload distribution

possible to differentiate all the particularities of the co-ordinations for each sector withRAMS. With TAAM, a single modelling of the co-ordinations had to be applied foreach simulated sectors pair, with a limitation to the total number of variables.

During the evaluation, it was identified that other actions than those identified by the DFSreporter are recorded and stored in the output files of TAAM. Their use is not yet develo-ped but may allow more accurate modelling of the controller workload. These actions donot apply solely to the ATC but also to other events attached to the flights. This could allowa wider range of measurements.

4.3.4 Controller workload


In RAMS the controller workload is generally expressed as the percentage of recordedwork during the selected period (30 minutes working time recorded in one hour period is50% workload). With TAAM, the workload is expressed as a number of points for eachsector. The workload in RAMS is calculated for each working position (planner, tactical, +).In TAAM the sector is considered as a whole. For comprehensive comparisons, the workload analysis was made on the total sector values.

Before doing a comparison between the times of RAMS and the points of TAAM, a relativecalibration had to be made. It used one conflict free traffic sample, with solely routine workload related to the number of flights per sector. This determined the point where theresults given by the 2 models are identical. The scale for comparison indicates that oneminute for RAMS working time corresponds to 2 points in TAAM using the DFS reporter.

Overlaid hourly workload curves are shown, followed by a regression line along with thecorrelation coefficient R2.

4.3.4.2 Global workload comparison

The results for the workload comparisons are presented for WSU and NL sectors.

Figure 22 shows the compa-rison of workload for WSUsector between RAMS andTAAM. The levels found arevery similar and the relativevariations are coherent.



Sector WSUGlobal Workload comparison

0102030405060708090

0700

-080

0

0800

-090

0

0900

-100

0

1000

-110

0

1100

-120

0

1200

-130

0

1300

-140

0

1400

-150

0

1500

-160

0

1600

-170

0

1700

-180

0

1800

-190

0

1900

-200

0

2000

-210

0

RA

MS

0

20406080100120140160

180

TAA

M

RAMS

TAAM

Figure 22: WSU sector global workload comparison


The regression line shown inFigure 23 indicates the relations-hip between the workload valuesfound with TAAM versus RAMS.

Figure 24 shows the workloadfound for NL sector with TAAMand RAMS. The values forRAMS are lower than for TAAM.The workload values matchlinearly the number of flights persector. The clipped flights gene-rate no workload in RAMS. Allthe flights in TAAM generate wor-kload and thus contribute to aslightly higher value.

Despite the variance in workloadshown in Figure 25, the trends ofthe 2 models are similar and givea R

2factor of 0.899.

4.3.5 Summary of RAMS TAAM compared results

The results found with the 2 models are in general coherent.

The main differences for the number of aircraft per sector result from the aircraft perfor-mances which are not identical in the 2 models and to the different process of handlingflights remaining for a short time in a sector.


Sector NLGlobal Workload comparison

0102030405060708090

0700

-080

0

0800

-090

0

0900

-100

0

1000

-110

0

1100

-120

0

1200

-130

0

1300

-140

0

1400

-150

0

1500

-160

0

1600

-170

0

1700

-180

0

1800

-190

0

1900

-200

0

2000

-210

0

RA

MS

020406080100120140160180

TA

AM

RAMS

TAAM

Sector NLWorkload comparison

R 2 = 0,899

0

10

20

30

40

50

60

70

0 5 10 15 20 25 30

TAAM

Polynomial (TAAM)

Figure 24: NL sector global workload comparison

Figure 25: NL sector workload comparison

Sector WSU Workload comparison

R2 = 0,6059

0

10

2030

4050

60

7080

90

0 5 10 15 20 25 30 35 40 45

TAAM

Polynomial (TAAM)

Figure 23: WSU sector workload comparison


The sector working times are not directly comparable. RAMS offers a flexible and detailedanalysis with user-customisation of ATC tasks categories. TAAM does not support the working time as an object. Some elements in TAAM are adjustable but a customisedapproach to working time categories is not available.

The controller workload found with the 2 models has been found to be coherent.Nevertheless, differences were found for the approach sectors. They were not simulatedexactly the same way with the 2 models. In addition, TAAM has a more consistent model-ling around the runways, covering the air and the ground.

RAMS offers the capability of measuring the workload on various ATC actors for one sector.



5. GENERAL CONCLUSIONS

5.1 AIRPORT PART

Data preparation is relatively easy for a fast-time simulator with the pre-processing toolsprovided by TAAM. IDIS and GTOOL are syntax and semantic-directed facilities that makethe pre-processing flexible, straightforward and instinctive. The editing windows are welldesigned and conform to the look and feel specified by X-windows/Motif design standards.

The graphical displayed that is synchronised with the IDIS editing facility makes the process of data preparation easier. This provides a very useful visual assistance to pre-processing.

Airport usage is a powerful feature for configuring an airport scenario to model actual airport operations to a relatively high degree of accuracy.

TAAM would benefit from the following improvements to its pre-processing facilities:

! The integration of an AutoCAD converter to TAAM to improve the layout digitizing process;

! Better identification of linked flights and their related semantic checking;

! Better protection of static files that could be used in other projects. A project compa-rison facility could reduce unwanted side effects on projects that are caused by themodification of shared static files.

Aircraft performance data are considered as static in TAAM. Despite the collection andreview of performance over several years by TPG and TAAM Users, operational data spe-cific to local and/or airline practices is not available.

TAAM has demonstrated a significant capability to simulate an airport and the vicinity, ina manner that can be very close to reality. TAAM’s rules mechanism is one of the mostpowerful and useful features of the kernel. They enable actual operational practices andtraffic paths to be replicated in an extremely precise manner.

This relative accuracy was measured through different sensitivity analyses and was alsorecognised by ATC Controllers to whom the baseline was presented.

The possibility to invoke IDIS functions from the main simulation windows makes the system very flexible and is very useful for testing new ideas/concepts in run-time withoutaffecting the project baseline.

The 2D/3D graphical display is a powerful facility in debugging and calibrating assistance.The availability of a stand-alone simulation re-player could provide a more adequate facility for presentations to airport stakeholders.

Although there is more information that could usefully be recorded by TAAM (e.g. to getmore realistic runway occupancy time measures), the output currently available is com-prehensive. A significant amount of useful information can be extracted, either through theReport Presentation Facility or by a direct access to the output files.

This evaluation also showed that performing a baseline study and calibrating it requiressignificant effort. Nevertheless, when the baseline is calibrated, additional sensitivity analyses can be performed with relatively small additional effort.

Following calibration of this baseline scenario, several sensitivity analyses were carriedout and several airport physical, procedural and technical improvements were analysed:

! The correlation between demand and simulated runway flows is acceptable. Whencomparing simulated and measured runway occupancy times, TAAM seems to berelatively optimistic for arrivals and pessimistic for departures;

! Multiple runs of the baseline scenario demonstrated that the stability of the simulator



is quite acceptable. Although the impact of traffic increase depends very much on theforecasted traffic pattern, the TAAM reaction to traffic increases was predictable, i.e.exponential increase of delays spread on longer periods. The development of a moresophisticated traffic cloning facility through rules is seen as a potential improvement;

! Changing runway selection strategy and use of an additional existing runway for ope-rations has been demonstrated to require little additional effort after the baseline hasbeen calibrated. Without the associated optimisation of the taxiway system, the com-plete process of data change, run and post-processing analyses required about halfa man day of effort. The same trend was observed for the design of a new runway,taxiway segment and new parking positions.

TAAM and SIMMOD are two completely different models, both from the conceptual andthe design points of view, and direct comparison has proved difficult. The effort and timerequired to run a simulation depends very much on the type of airport under considerationand the model used. Nevertheless, the use of SIMMOD has shown it requires relativelyless effort for the creation and analysis of a baseline scenario. However, TAAM requiressignificantly less effort for sensitivity analyses and the addition of changes or improve-ments to the baseline. This is important as much of the value of any study comes from theiterative process of the analysis of change.

5.2 EN ROUTE & TMA PART

TAAM has demonstrate a lot of capabilities, simulating the flights in a single modellingenvironment from the beginning to the end. The en-route functions offer a general level ofresults which are comprehensive. The tools integrated for the preparation of the data andthe analysis of the results have been found efficient. However, auxiliary tools developedoutside of TAAM are strongly recommended to complete a study. The results provided bythe DFS reporter (used during the evaluation) are significant but cannot be extended locally to satisfy specific needs since the source code is not available.

The simulation module of TAAM is very powerful and has simulated a CFMU traffic sample enhanced by 100% (45390 flights over 24h). The behaviour of the flights is realistic particularly within the airspace around the airports.

The overall workload obtained has been found coherent. However, the detailed breakdown of workload is not as comprehensive as that provided by existing tools usedby EUROCONTROL. Developments in post-processing tools in this area are necessary ifthe requirements of simulations remain orientated towards detailed ATC analysis. Forinstance the sector capacity calculation based on workload is not implemented in TAAM.However the TAAM tool benefits from a wide community of users sharing their experience and most of their developments is offered for use to other users. This has beensuccessfully experienced during the evaluation.

During the evaluation, it has been identified that TAAM has the potential to address a verywide domain for modelling. Safety, economics, environment and military experts havebeen contacted to discuss the potential use of the tool for their current and future needs.A TAAM simulation generates the majority of the necessary output data. The tools to post-process these data require further development.

The main missing element in TAAM is the sector capacity item, according to the currentEuropean norm (number of aircraft per sector per time slot). This would be a restriction forworking on combined ATC/ATFM studies where delays attached to sector capacity varia-tions is one main issue.



The time required to make a full simulation with TAAM compared to other models was notprecisely determined during the evaluation. The amount of data to generate and results toanalyse is always important for doing a fast-time simulation. It depends mainly on the size,level of accuracy and scope of the project. The operational evaluation team has not iden-tified major differences between models for the overall duration of a study. Both RAMSand TAAM offer facilities to access and use external data, provided software support anddatabase access are available.

The support offered by TPG during the evaluation has been globally efficient. Some difficulties occurred at the beginning during the initial training, which was inadequately prepared by TPG.

One of the major tasks for the EUROCONTROL agency is to deal with R & D aspects.These often need specific developments. Priority development will incur additional costs.One enhancement task sample has been presented but not evaluated.

Software experts were part of the evaluation project team. However, the TAAM softwareevaluation was not in the scope of the operational evaluation. The feasibility of potentialmodifications or developments identified has been confirmed by TPG but not assessed.

Finally, if TAAM was to be used in the agency, the evaluation team would recommend toaddress two main issues: one relating to the necessity of a consolidated software support/development resource within the TAAM team, the other being the appropriatehuman resource management of this team in view of the number of TAAM licences.



APPENDIX 1 - AIRPORT LAYOUTS – AIP MAPS



APPENDIX 2 - AIRCRAFT CLASSIFICATION AND AIRCRAFT CATEGORISATION

In the scope of this evaluation, some data collected for a previous study on BrusselsNational Airport were re-used. In this Section, comparison and matching are made between this source of data and the related static data in TAAM.

As shown in Table 9, the aircraft classification used in this previous study on BRU Airportis based on the wake turbulence classification (defined in PANS-RAC 4444,Paragraph16.1.1), the number of engines and the maximum take-off weight. C aircraftrepresented some 87% of demand at BRU airport in 1998. The aircraft within this classmight have different performance and use different exit taxiways. Therefore, this class wassplit into C1 and C2, depending on approach speed and arrival runway occupancy time7.

Aircraft Mix Wake Turbulence # Engines MTOW (Kg)

A Light Single £ 7,000

B Light Multiple £ 7,000

C1 Medium Multiple 7,000 < ... < 136,000

C2 Medium Multiple 7,000 < ... < 136,000

D Heavy Multiple ≥ 136,000

Table 9 : Aircraft Classification

Aircraft Category Criteria (MTOW, tonnes)

0 Heavy-Plus (747 only) ≥ 300

1 Heavy 136 £ … < 300

2 Medium 20 £ … < 136

3 Medium-Light 7 < … < 20

4 Light £ 7

Table 10 : Aircraft Category in TAAM

Classes A, B in previous BRU study fit TAAM category 4 while class D match categories0 and 1. Classes C1 and C2 can respectively be related to TAAM Categories 3 and 2without to much inaccuracy as far as aircraft performance is concerned.

In the following table, figures in black are used in ECAC. Figures in red and between brackets are used in the original version of TAAM wake_turb.data file. A value (0) is substituted by the minimum radar separation.


Aircraft Mix Wake Turbulence # Engines MTOW (Kg)

Aircraft Category Criteria (MTOW, tonnes)

7 - IClass C1 mainly includes BA46, DH8C,F50, F70, GLF5, H25B, JS41, SF34, SW4 while Class C2 includes A320s, B727, B737s, C130, CARJ, E120, E145, LJ35, MD80, MD90, SB20, T154. B757s were considered as Heavy (D) for wake turbulence purpose when leading and Medium (C2) when trailing.


Table 11 : Wake Turbulence separations Minima - Comparison

Some re-adjustment on wake turbulence had to be made further to this comparison.

It is to be mentioned that TAAM also uses another aircraft classification - not to be confusedwith their aircraft categorisation - ranged from 1 to 5, as shown in Table App2.4. This classi-fication is used, amongst other things, by the report presentation facility (RPF).

Aircraft Class Crit

1 Widebody jets

2 Narrowbody jets

3 Light jets

4 Turboprops

5 Piston-engined aircraft

Table 12 : Aircraft Classification in TAAM

APPENDIX 3 - MARKET SEGMENT CLASSIFICATION

Austria, Belgium, France, Germany, Italy, Luxembourg, Portugal, Spain and TheNetherlands are included in the EU Schengen area while Denmark, Finland, Greece,Ireland, Sweden and United Kingdom are non Schengen.


EU Schengen1

EU Non-Schengen2

Non Eu3

Scheduled

EU Schengen4

EU Non-Schengen5

Non Eu6

Non Scheduled Cargo7

Business AviationGeneral Aviation

8

Military9

Others0

Aircraft Class Criteria

Leading

TAAM Categorisation 4 4 3 2 0,1

Trailing A 4 3 (0) 3 (0) 5 (0) 5 (4) 6 (5)

C1 3 3 (0) 3 (0) 3 (0) 3 (0) 5

D 0, 1 3 (0) 3 (0) 3 (0) 3 (0) 4

WT Class. Criteria (Ton) <7 <7 7< <25 25<<136 >136

Classification used in A B C1 C2 Dprevious BRU study

B 4 3 (0) 3 (0) 5 (0) 5 (4) 6 (5)

C2 2 3 (0) 3 (0) 5 (0) 3 (0) 5


APPENDIX 4 - TAAM CONCEPTS


*.rep

*.rep

*.rep

*.rep

*.rep

*.rep

*.rep

*.sum

*.sum

*.sum

*.sum

*.sum

*.sum

Stand-off Delay

Gate Delay

Taxiway Delay

Runway Delay (TAAMterminology forDeparture Queue Delay)

Total Gate Delay

Airport Movement

Runway Movement

Actual Ground Time

Actual Airborne time

Actual Total time

Scheduled T’table Time

Scheduled Sim Time

Delay

Difference between the time theaircraft arrives at the stand-off posi-tion while waiting for a free gateand the time the aircraft leaves thestand-off position

Difference between ETD and thetime when the aircraft startsmoving

Period between the time when theaircraft stops either as No. 1 in theline-up position or behind anotheraircraft already in line-up queueand the time when the aircraftbegins line-up for take-off (i.e.begins turning onto the runway)

Time between beginning of line-up(i.e. entering RWY holding zone)and lift-off (rotation)

Time between beginning of take-offand lift-off (rotation)

Sum of:! taxi time for departure! taxiing delay! delays in line-up queue! take-off run time

Difference between thetime the aircraft arrives atthe stand-off position whilewaiting for a free gate andthe time the aircraft leavesthe stand-off position

Period between the time when aircraft stops while taxiing and thetime when aircraft resumes taxiing.Line-up time is excluded

Total delay due to:! in-trail separations (inc. delay at the start waypoint when the

aircraft departs from a waypoint)! flow control! delayed pushback due to traffic in apron area! arrival sequencing and flow control at destination airport! gate delays caused by runway congestion! late arrival of next linked flight! limitation of number of aircraft in line-up queue

Time between Touchdownand clearance of RWY hol-ding zone

Time between Touchdownand aircraft starts turningoff the RWY

Sum of:! landing roll time! taxi time! taxiing delay! stand-off delay

Time between lift-off till touchdown, inc. time on SID and STAR

Sum of Actual Ground Time and Actual Airborne Time

ETA - ETD as in timetable

Sum of taxi time on departure, line-up, take-off run, airborne, landingrun, taxi time on arrival, for unimpeded movement (without delay)

Actual Total Time minus Scheduled Sim time

In … Concept Arrival Departure


APPENDIX 5 - SOME ADDITIONAL INFORMATION ABOUT SIMMOD

App. 5.1 - Input requirements

The SIMMOD input is constructed in a number of files. The validity and correctness of theinput data is crucial for the accuracy and realism of the simulation. The SIMMOD filesconstructed will contain detailed information regarding:

! Geographical boundaries of Airspace and restrictions;

! Geographical boundaries of sectors and restrictions (capacities);

! Points data and restrictions (separation standards);

! Route data and restrictions (separation standards);

! Airfield data and restrictions (aircraft size limitations);

! Aircraft data and restrictions (wake turbulence);

! Scheduling of events (list of flights), and

! Weather considerations (reduced visibility operations).

App. 5.2 – Output

Output data is produced in a report format which may also be converted into charts andgraphs. The data available from SIMMOD includes:

! Airfields:

$ Runway utilisation;$ Ground delays at gates, holding points or during taxiing;$ Average times for completing ground movements.

! Sectors:

$ Total number of aircraft that crossed the sectors within a specified time period;$ Maximum number of aircraft in each sector's area of responsibility at any one time

within a specified time period;$ Average flight times for the sectors;$ A workload index for the sectors, and$ Number of aircraft in level flight, climbing or descending for each sector within a

specified time period.! Points:

$ Rate of traffic flow over points;$ Number of aircraft climbing, descending or in level flight at a point;$ Number of potential conflicts that will require ATC intervention.

! Routes:

$ Average flight times on each route, and$ Number of aircraft on each route.



App.5.3 - Simulation Animation

In addition to the output data, the SIMMOD post-processor module produces an animatedhigh resolution colour display of the simulation. All aircraft can be displayed during all stagesof flight, or ground movement, following procedures defined in the input data.

During the animation run various items can be analysed:

! Evolution of a traffic situation and traffic flow;

! A visual check of the simulation's realism;

! Verification that procedures defined for the model do not violate the defined separationspecifications, and

! Areas of scheduling congestion can be located.

APPENDIX 6 - REQUIREMENTS, BUGS AND PROPOSED IMPROVEMENTSIn addition to the list of bugs/improvements already reported by EUROCONTROL/EEC.

App. 6.1 - EUROCONTROL Requirements

1. Some problems of compatibility were reported at ETTSG/10 between TAAM Plus andTAAM 2.9, specially about the way of reporting delays. It is obvious that compatibilityassurance between the successive TAAM versions should be a major requirement, spe-cially if EUROCONTROL performs successive simulations based on already-validatedinputs from past experience.

2. Because SUN is reluctant to changes to OpenGL, and because of a wish to be able torun TAAM on standard PCs and laptops, the TPG’s preference is to go to LINUX in the future. Potential EUROCONTROL’s TAAM users should therefore be LINUX-equipped.

3. Standardised terminology approved by AOT, concerning ROT and Airside Capacity definitions should be provided by TAAM, specially if TAAM is used to implement specific regulation (e.g. requirements to apply 2.5 NM).

App. 6.2 - Identified Bugs

1. Some difficulties were encountered when drawing Runways with Gtool. All vertices otherthan the four that define the base polygon must be deleted before it can be reclassifiedas “Runway”; in some cases when this was not done, file crashes were experienced. Ifthe layout had not been saved, all changes were lost and it was necessary to start againfrom the beginning.

2. While using the multi-run functionality offered by TAAM, simulation is crashing for unknown reason. NLR also experienced the same fact.

3. Using meta keys (CAPS LOCK, NUM LOCK, SHIFT LOCK) blocks any action withGTOOL.

4. Concerning linked flights, some inconsistencies could not be identified through IDIS. Forinstance, linked flights with same registration number but different aircraft series for arrival and departure were not detected. Linked flights is a field where semantic checking could be improved.

App. 6.3 – Proposed Improvements

1. It is to be regretted that a tool such as TAAM does not include a simulation run re-player. Indeed, there is no way to come back on any past event, what could be a major



disadvantage while reviewing and calibrating scenarios with any stakeholders, speciallyATC controllers. In addition, in order that this calibration with and presentation to stake-holders be as efficient as possible, this TAAM Simulation Re-player should be a standalone product, easy to load on a laptop, without being dependent on any other TAAMmodules.

2. Although the rule mechanism is already very powerful in its current state, the only thingthat could be regrettable is the lack of some if <condition> then <action> else <action>rules, or Select case <value> : <action> case else <action> rules. It would be veryincomprehensible that TPG would not add this asset to one of the best TAAM’s features.

3. The aircraft performance data file used by TAAM has been created and maintained byTPG and TAAM users years after years. These data have not been validated in the scopeof this evaluation exercise. Nevertheless, the concept of having only one aircraft perfor-mance data has already shown in the past to be relatively inefficient. Two different set ofaircraft performance data are usually required: one including manufacturers’ data and asecond one that is operational and reflects how aircraft operators operate their aircraft.While the technical aircraft performance data enables to extract some ultimate capacity of the ATM system, the operational aircraft performance dataenables the assessment of sustained capacity based on specific practices of the perfor-mance.

At the 10th ETTSG Meeting, 30 and 31 March 2000, it was mentioned that TPG proposedsome modification of their aircraft performance data file in order to provide greater flexibility

It was also mentioned that Boeing data could be available8; nevertheless, TPG did not succeed in getting Airbus data, what EUROCONTROL proposed to investigate based ontheir good relationship with Airbus if the Agency decides to use TAAM. This initiative wasquite supported by the TAAM users, including DFS, and TPG.

4. More and more, stand-off positions are used not only for arrivals but also for departures, especially when gates represent a constraining factor limiting capacity (e.g.Schiphol airport use departure stand-off’s to free gates for arrivals). In opposite to long-term parking positions, stand-off positions are used for short periods of time while waitingfor take-off clearance, or to avoid too long departure queues.

5. Mimicking air traffic flow management would enable to assess ATFM delays andCFMU operations.

6. Improvement of RPF is required, although it is understandable that, as many TAAMusers developed their own reporter, TPG could be reluctant to change report files, whatwould oblige all these users to change their own post-processors.

7. Comparing different projects in TAAM involves sequential comparisons in time, and notparallel comparison. In order to make traceability easier between different projects and toavoid changing dynamic files that could interfere on other project, the development of aproject parallel comparison facility (PPCF) should be highly recommended. Whilereporting the characteristics of the compared projects side-by-side, the objectives ofPPCF are twofold : first it would enable to identify what is common to two different pro-jects but, second and still more interesting in ‘what-if’ analyses, it would enable to high-light what is different between these two projects. The comparison would be made notonly at the static/dynamic data level, but also in more depth such as, for instance, at therules level by reporting if they are active or not.

8. Although useful and required, it is sometimes to be regrettable that IDIS syntax/semanticchecking cannot not be switched off. Indeed, although this facility is required for most studies, end-users could sometimes like IDIS not to intervene when they judge source datavalid.


8 - it is to be reminded that TPG is owned by Boeing.


APPENDIX 7 - ARRIVAL RUNWAY OCCUPANCY TIMES

APPENDIX 8 – SIMMOD-TASIME VS TAAM – RESULTS


Average AROTTAAM Results vs Measures

0

10

20

30

40

50

60

70

80

90

100

110

Widebody Jets Narrowbody Jets Light Jets Turboprops Piston Engined

TAAM Avg 25R Measured Avg 25R TAAM Avg 25L Measured Avg 25L

ARRIVALS: Hourly Cumulated Ground Travel Time (Min)

0,00

20,4014,94

10,18

52,40

156,75

167,31

187,20

129,49

81,12

132,03

163,84

104,40

92,00

189,36182,41

144,72

122,75

169,26

122,36

95,38

75,6870,95

36,12

3,23

30,40

15,27

20,98

51,85

168,80

179,22

201,17

106,35

81,92

163,35

114,08

93,6295,12

176,62179,02

121,97

161,85

146,43

121,75

120,37

96,47

74,83

43,55

0,00

50,00

100,00

150,00

200,00

250,00

0-1

1-2

2-3

3-4

4-5

5-6

6-7

7-8

8-9

9-10

10-1

1

11-1

2

12-1

3

13-1

4

14-1

5

15-1

6

16-1

7

17-1

8

18-1

9

19-2

0

20-2

1

21-2

2

22-2

3

23-2

4

Time Period

Trav

el T

ime

(Min

)

GND Travel Simmod GND Travel Taam

Figure 27: SIMMOD / TAAM Ground Travel Time

Figure 26: Average AROT - TAAM Results vs Measures



DEPARTURES: Hourly Cumulated Ground Travel Time (Min)

23,40

86,24

67,87

39,41

53,90

138,90

90,72

73,95

207,90

191,29

133,38 127,92

165,55

138,91

54,80

137,48

172,92

178,71

201,63

103,32

76,64

26,8215,70 7,85

51,40

197,17

101,33

64,87

160,13

278,83

133,33

385,48

483,48

225,45 238,75

109,13

385,10

204,55

141,92

287,65

281,20

422,33

340,00

147,48150,27

9,33

17,95

0,000,00

100,00

200,00

300,00

400,00

500,00

600,00

0-1

1-2

2-3

3-4

4-5

5-6

6-7

7-8

8-9

9-10

10-1

1

11-1

2

12-1

3

13-1

4

14-1

5

15-1

6

16-1

7

17-1

8

18-1

9

19-2

0

20-2

1

21-2

2

22-2

3

23-2

4

Time Period

Trav

el T

ime

(Min

)


ARRIVALS: Hourly Average Ground Travel Time (Min)

0,00

5,10

4,98

5,09 5,24

4,75

5,07

4,68

5,63

5,074,89

5,12 5,22

5,75

5,26

4,93

5,36

4,91

5,46

5,325,02

4,734,73

5,16

3,23

7,60

5,09

6,99

4,71

5,12

5,43

5,16

4,43

5,124,95

4,23

5,20

5,28

5,05

4,844,52

5,40

5,23

5,53

6,69

5,67

4,99

5,44

0,00

1,00

2,00

3,00

4,00

5,00

6,00

7,00

8,00

0-1

1-2

2-3

3-4

4-5

5-6

6-7

7-8

8-9

9-10

10-1

1

11-1

2

12-1

3

13-1

4

14-1

5

15-1

6

16-1

7

17-1

8

18-1

9

19-2

0

20-2

1

21-2

2

22-2

3

23-2

4

Time Period

Trav

el T

ime

(Min

)


Figure 28: SIMMOD / TAAM Cumulated Ground Travel Time

Figure 29: SIMMOD / TAAM Average Ground Travel Time


Figure 30: Departures Hourly Average Ground Travel Time

Figure 31: Arrivals Hourly Average Ground Travel Time


DEPARTURES: Hourly Average Ground Travel Time (Min)

5,85 6,16 6,175,63

3,854,63

5,04

4,93 4,95

5,17

4,94

5,33

4,73 4,79

5,48

4,91

5,24

4,83

5,175,74

4,79

13,41

7,85

7,85

12,85

24,65

5,96

16,22

10,0110,33

7,02

12,43

9,30

8,05

10,85

8,39

10,13

7,31

10,92

11,99

9,37 8,99 9,199,83

8,84

3,11

17,95

0,00

0,00

5,00

10,00

15,00

20,00

25,00

30,00

0-1

1-2

2-3

3-4

4-5

5-6

6-7

7-8

8-9

9-10

10-1

1

11-1

2

12-1

3

13-1

4

14-1

5

15-1

6

16-1

7

17-1

8

18-1

9

19-2

0

20-2

1

21-2

2

22-2

3

23-2

4

Time Period

Trav

el T

ime

(Min

)


ARRIVALS: Hourly Average Ground Delay Time (Min)

, 00 ,0 0 0 ,0 0 0, 00 0, 04 0 ,0 3 0 ,0 5 0, 02 , 15 0 ,0 6 0 ,0 3 0, 05 , 04 0 ,0 0 0 ,0 0 0, 02 ,0 0 0 ,1 0 0 ,0 2 0, 01 ,0 0 0 ,0 1 0 ,0 0 0, 00, 000 ,4 3

0 ,0 0 0, 00 ,2 3

1 2, 90

18 ,4 5

8, 98

, 36

1 ,2 0

0 ,0 8

6, 51

,5 8

6 ,3 6

2 ,6 4

8 ,5 8

1 7, 42

7 ,7 6

4, 7 7

0, 48

,6 51 ,1 4

1, 02

0, 00

0 ,0 0

2 ,0 0

4 ,0 0

6 ,0 0

8 ,0 0

10 ,0 0

12 ,0 0

14 ,0 0

16 ,0 0

18 ,0 0

20 ,0 0

0-1

1-2 2-3

3-4

4-5

5-6

6-7

7-8

8-9

9-10

10-1

1

11-1

2

12-1

3

13-1

4

14-1

5

15-1

6

16-1

7

17-1

8

18-1

9

19-2

0

20-2

1

21-2

2

22-2

3

23-2

4

Time Period

Del

ay (

Min

)

Total GND Delay SIMMOD Total GND Delay TAAM


Figure 32: TAAM Departures - Hourly Average Ground Travel Time

Figure 33: SIMMOD Departures - Hourly Average Ground Travel Time


TAAM DEPARTURES: Hourly Average Ground day Time (Min)

0,00

2,00

4,00

6,00

8,00

10,00

12,00

14,00

16,00

18,00

20,00

0-1

1-2

2-3

3-4

4-5

5-6

6-7

7-8

8-9

9-10

10-1

1

11-1

2

12-1

3

13-1

4

14-1

5

15-1

6

16-1

7

17-1

8

18-1

9

19-2

0

20-2

1

21-2

2

22-2

3

23-2

4

Time Period

Del

ay (

Min

)

GATE Delay Taam TAXI Delay Taam DEPARTURE QUEUE Delay Taam

SIMMOD DEPARTURES: Hourly Average Ground day Time (Min)

0,00

5,00

10,00

15,00

20,00

25,00

30,00

35,00

40,00

45,00

0-1

1-2

2-3

3-4

4-5

5-6

6-7

7-8

8-9

9-10

10-1

1

11-1

2

12-1

3

13-1

4

14-1

5

15-1

6

16-1

7

17-1

8

18-1

9

19-2

0

20-2

1

21-2

2

22-2

3

23-2

4

Time Period

Del

ay (

Min

)

GATE Delay Simmod TAXI Delay Simmod DEPARTURE QUEUE Delay Simmod


APPENDIX 9

Comments from TPG on TAAM Evaluation report

General

The evaluation conducted by the two EUROCONTROL teams was thorough and fair, andthat is reflected in the evaluation reports. The reports contain valuable remarks and sug-gestions as to TAAM enhancement and we intend to take them on board.

We do have some comments to the evaluation reports and are suggesting minor correc-tions, as presented below.

AIRPORT SUB.PROJECT

Paragraph 3.2.1.3.D- Operational Rules

It is correct that since TAAM Rules use interpreted language and are not compiled, theirevaluation is slower (but the user gets remarkable flexibility). However, during the execu-tion most time is spent in TAAM binary code and only occasionally does it “dip” into theinterpreted rulebase code. Consequently, the effect of slower interpreted code on thewhole of TAAM simulation is mild.

Paragraph 3.2.2.2- Graphical Simulation Run Facility

Since the report was written, TPG has released TAAM Plus Version 1.1 which has two newreplay features:

! AAM Viewer – a fast 3D playback tool that includes cockpit view, aircraft tracking, theoption for OpenGL graphics and more;

! he ability for the user to record what is taking place on the simulation screen directlyinto a Windows AVI file (“record” button on SIM main panel).

Paragraph3.2.2.4- Evaluation of the Report Presentation Facility (RPF)

TAAM RPF was meant to be a simpler tool but on the other hand it produces a reasonably full set of reports instantly – no preparatory work whatsoever is required. Formore comprehensive reports, users have indeed developed some excellent tools, and thisreflects the spirit of TAAM community and the fact that TAAM input and output file formatsare published.

TPG has now taken over the maintenance and further development of the DFS Reporter.

Paragraph 3.2.3.2- Simulated vs Measured Runway Occupancy Times

It is correct that, absent any rules, TAAM deceleration distances are based purely on theaircraft performance. However, the user can specify a desired randomized spread for runway exits, in percentages, and thus create a more realistic runway occupancy time.

Overall, there clearly are differences in ROT definition in TAAM and in Eurocontrol terms– more time is probably needed to reconcile these terms so that meaningful comparisonscan be made.



Paragraph 3.2.3.3- Connecting Flights

A very good suggestion.

Paragraph 3.3.2- Traffic increase

A more sophisticated cloning facility for TAAM does in fact exist – Embry-RiddleAeronautical University (ERAU) in the U.S. has developed a tool that takes hub characte-ristics into account. The tool is available to the TAAM user community via ERAU or TPGwebsite.

However, additional Europe-specific features could also be added, as suggested in thereport.

Paragraph 3.4.6- Some Future concepts

These future concepts were discussed to some extent during the advanced TAAM trainingcourse in Brussels and prior to TAAM evaluation effort, with a number of Eurocontrol staffmembers.

A-SMGCS simulation in the current TAAM version is indeed questionable, although withsome effort, it is possible to create limited simulation of ground vehicles. This feature isplanned for a future TAAM version (but not in the short term).

Many, but not all, effects of AMAN/DMAN systems can be simulated in TAAM via itsRulebase. More discussions on the subject would be needed so that TPG can betterunderstand what effects need to be simulated and how.

Paragraph 3.5.5- Effort consumption

When comparing SIMMOD baseline preparation to the same process with TAAM, onemust remember that TAAM requires more data because it is a more detailed and morerealistic model than SIMMOD. For example, no time was allocated in SIMMOD case forrulebase setup because rules don’t exist in that model.

When all activities of the study preparation are taken into account (baseline and alternati-ves), the time-to-completion differences become striking. For example, in the UnitedStates, TPG is aware of two ongoing airport studies where TAAM and SIMMOD were usedin parallel. In both cases, SIMMOD model preparation started well before TAAM; in bothcases the TAAM studies (baseline and alternatives) were completed in about 9-12 weeks,whereas the respective SIMMOD studies still have not reached “baseline validated” stage– more than 8 months since start.

In fact, we understand that the effort quoted for the Brussels baseline preparation by aEurocontrol Bretigny SIMMOD group did not include validation by the airport controllers,whereas in TAAM case, validation – even if somewhat limited – has been done. We arecertain that should a full validation be performed on the draft SIMMOD model, the actualbaseline preparation time will jump to many months and will be in line with the industryexperience.

Finally, it should be noted that while the Eurocontrol Brussels team has had substantialexperience with SIMMOD, this was their first TAAM study and so understandably, it tooksomewhat longer to complete.



Paragraph 3.6- Conclusions and recommendations

We generally agree with the conclusions and recommendations presented. Three comments:

! Baseline calibration effort for the Brussels Airport appears to be somewhat limited, inthat only one metric – departure/arrival movement rates – could be obtained from realoperation.

! It is our experience that TAAM can be calibrated to quite high precision on this andother metrics – numerous study reports confirming this are available.

! Whether TAAM is pessimistic or optimistic about any category of aircraft, dependsentirely on the user’s settings, and it is possible to shift the balance of runway delaysfrom departures to arrivals.

Paragraph 3.6- last section

As mentioned in the comment to Section 3.5.5 above, our knowledge of the effort requi-red for SIMMOD vs. TAAM baseline creation and validation is contrary to that stated in thereport. SIMMOD baseline validation usually takes much longer than the same process inTAAM.

On the other hand, we fully agree with the statement that alternative scenario evaluationis much faster in TAAM than in SIMMOD and that it is key to the simulation team produc-tivity.

Appendix 6.1- EUROCONTROL requirements

1. The latest TAAM Plus version, 1.1, contains a number of improvements over the oldTAAM 2.9 version, and as such, they result in a somewhat different aircraft behavior.This naturally means some variance in the output. We consider this normal but theusers need to be aware of this and may need to re-establish their TAAM baselines.

2. TPG will for the time being continue to support both SUN and Linux.

3. The terminology does indeed need to be synchronized.

Appendix 6.2- Identified Bugs

1. These crashes have been fixed in TAAM Plus 1.0.2 and 1.1.

2. This is not really a bug – NUM LOCK, for example, suppresses the normal use of arrowkeys. The users simply need to be aware of this effect.

3. Agreed.

Appendix 6.3- Proposed Improvements

1. As mentioned earlier in this response, we have now introduced TAAM Viewer and alsoWindows AVI file recording (“TAAM Movies”), so the concerns voiced in this paragraph of the report have been addressed.

2. Indeed. In TAAM Development Plan, numerous enhancements of the Rulebase mecha-nism are listed.

3. Our proposed approach is to have one aircraft performance data file that provides the“nominal” (per-manufacturer) performance and also the min-max envelopes, and thento add another layer describing operational and airline-specific nuances. The proposalto this effect was submitted by TPG to the Worldwide TAAM User Group and has effec-tively been accepted by the user community.



4. It is possible to simulate stand-off positions for departures using the “stop and wait”rules in TAAM, but only to a limited degree. This functionality needs to be expanded.

5. Many flow management concepts can already be simulated by TAAM: Flow Control foran airport, Traffic Flow Metering through fixes or route segments, Sector Capacity,Dynamic Sectorization. At the same time, more features need to be introduced intoTAAM, for example Departure Slot simulation. The Slot feature is listed in TAAMDevelopment Plan as a relatively high priority item.

6. Since TPG has taken over the DFS Reporter maintenance and development, it is likely that this tool will receive more new features. We are not yet sure if it would beworth while to perform any more work on RPF.

7 A very interesting thought. Perhaps this kind of comparisons can be made in a database like Oracle once TAAM reports are imported there via the DFS Reporter.

EN ROUTE & TMA PART

Paragraph 4.2.2.3- Flight Level Restrictions

Some steps are already being made for better flight level restriction control. They includethe FLAS implementation, and in the longer term, adoption of the ICAO flight plan standard (or at least parts thereof that are relevant to TAAM simulation).

Paragraph 4.2.2.6- Airspace operations

Rulebase logic checking is a scheduled improvement listed in the TAAM DevelopmentPlan.

Paragraph 4.2.2.8- Conclusion data preparation

Very valuable remarks.

Paragraph 4.2.3.2- Conflict detection

Rather, look-ahead distance is the same for all sectors.

Paragraph 4.2.4.1.F- Capacities

As a result of discussions with the EEC team and with other European users, the Europeandefinition of sector capacity (as acceptance rate) will be adopted in TAAM as an option. Itis scheduled for implementation in TAAM Plus 1.2 which is the next major release.

Paragraph 4.2.4.4- R&D project particularities

Regarding the costs of implementation of major new features, it should be noted that if afeature is required by a number of users, these costs can be spread among them. Also,new features are continually introduced into TAAM in due course of maintenance andupdates funded by the users’ annual fees. Additional costs discussed in this section wouldonly be required for fast-track, unique features.

Paragraph 4.2.4.6- Other projects

For the ATFM and Capacities projects, the new European sector capacity definition (planned for the next major TAAM Plus release, 1.1) will mean that these features can besimulated in TAAM better.



Paragraph 4.3.4.2- Global workload comparison

It is good to see that, despite a very different approach to Sector Workload assessment,both RAMS and TAAM show a similar trend with high degree of correlation.

Paragraph 4.4- Conclusions

Regarding Sector Capacity, see comment to Section 4.2.4.1

Overall, we appreciate and agree with the conclusions made.



TRADUCTION EN LANGUE FRANÇAISE

RÉSUMÉ

Dans le cadre de la modélisation des aéroports et de l’espace aérien, l’agence EUROCONTROL a effectué une évaluation opérationnelle de l’outil de simulation entemps accéléré TAAM (Total Airspace and Airport Modelling), simulateur développé par lePreston Group. Cette évaluation s’est déroulée entre Octobre 1999 et Mai 2000.

L’objectif général de ce projet était d’évaluer les capacités opérationnelles offertes parTAAM, pour remplir les besoins d’EUROCONTROL en matière de modélisation des aéroports et de l’espace aérien.

Deux équipes d’évaluation étaient affectées à ce projet du Centre expérimental, une àBruxelles pour la partie aéroport, et une autre à Brétigny pour la partie contrôle en routeet en TMA. Le projet commença en octobre 1999 par une session de formation de 10 joursassurée par le Preston Group pour familiariser les personnes membres de l’équipe d’évaluation à l’utilisation de TAAM. Ensuite les 2 équipes ont travaillé sur leurs projetsrespectifs pour construire les scénarios à utiliser durant l’évaluation. Une session de formation approfondie a eu lieu en Février 2000 à Bruxelles pour montrer des fonctionsavancés de TAAM aux personnes impliquées dans l’évaluation.

L’équipe en charge du sous-projet aéroports a choisi de faire l’évaluation en simulant l’aéroport de Bruxelles pour le compte de "Brussels airport authorithy" (BIAC- BrusselsInternational Airport Company). L’équipe de Brétigny en charge de la partie en route / TMArefit un exercice d’une simulation en temps accéléré qui avait été faite en 1998 pour laRépublique Tchèque avec RAMS. Pour les deux sous-projets, d’autres exercices ont étéajoutés de façon à avoir une vue plus complète sur les possibilités offertes par TAAM etsur son utilisation éventuelle pour des tâches de type R & D.

Les équipes d’EUROCONTROL étaient assistées par des experts TAAM contractés par lePreston Group à une société externe. Cette assistance dura jusque la fin du projet pourla partie aéroports tandis qu’elle était arrêtée en décembre 1999 pour la partie en route /TMA faite à Brétigny.

Un contrat, prenant en compte les spécifications retenues dans le Project ManagementPlan a été signé entre EUROCONTROL et le Preston Group le 21 septembre 1999.



1. INTRODUCTION

Une évaluation de l’outil de simulation en temps accéléré TAAM (Total Airspace andAirport Modeller) a été conduite au sein de l’agence EUROCONTROL.

L’évaluation était divisée en deux sous-projets :

! Sous-projet en route / TMA conduit au centre expérimental;

! Sous-projet aéroport conduit à EUROCONTROL Bruxelles;

Une premier session de formation s’est déroulée au CEE en octobre 1999 et une sessionde formation approfondie a eu lieu en février 2000 à Haren.

Ce document contient une vue d’ensemble et les résultats principaux de cette évaluation.Les conclusions et recommandations sont contenues dans ce document. Cependant,pour plus de détails sur des aspects particuliers, il est recommandé de se référer au " TAAM operational evalutation process Document ", parties 1 (ref 5) et partie 2. (ref 8).

Le projet TAAM évaluation a commencé juste après la mise en service de la version TAAMPlus par le Preston Group. Deux versions consécutives de TAAM (TAAM V1.0S et TAAMV1.0.1S) ont été utilisées pendant l’évaluation. Quatre licences ont été fournies par lePreston Group. Deux étaient utilisées pour la partie aéroports et deux pour la partie enroute / TMA.

2. OBJECTIFS

L’objectif général était de faire une évaluation opérationnelle des possibilités de TAAMpour remplir les besoins d’EUROCONTROL en matière de simulation des aéroports et deproblèmes liés à l’ATM pour le contrôle en route et en TMA.

Un des objectifs spécifiques était de comparer les possibilités offertes par TAAM à cellesdes outils actuellement utilisés à EUROCONTROL, et d’explorer les possibilités en matiè-re de R & D.

Les outils comparatifs utilisés actuellement sont SIMMOD pour les simulations aéroportset RAMS pour les simulations d’espace en route ou en TMA.

L’évaluation de l’architecture et du code ne faisaient pas partie des objectifs de ce projet.



3. CONCLUSIONS

3.1 PARTIE AEROPORT

La préparation des données avec les outils fournis avec TAAM est aisée. IDIS et GTOOLoffrent des possibilités souples, directes et facilement utilisables pour la vérification de lasyntaxe et des données. Les fenêtres d’édition sont bien dessinées et conformes auxstandards spécifiés dans X-Windows/Motif.

Le graphisme, synchronisé avec les fonctions d’édition de IDIS rendent le processus depréparation des données plus facile. C’est une aide visuelle très utile pour leur prépara-tion en amont de la simulation.

La fonction “airport usage” est très performante pour construire un scénario d’aéroportreflétant d’une façon précise les opérations réelles.

TAAM pourrait bénéficier des améliorations suivantes pour la préparation des données :

! Intégration d’un filtre de Autocad vers TAAM pour améliorer le processus de digitali-sation de la plate-forme aéroportuaire.

! Meilleure identification des vols en escale avec une vérification de la logique de leurséléments.

! Meilleure protection des fichiers statiques qui pourraient être utilisés dans d’autresprojets. Une fonction de vérification des projets pourrait réduire les risques induits parune modification de fichiers statiques partagés entre plusieurs projets.

Les performances avions sont considérées comme étant un élément statique dans TAAM.Malgré les données et la vérification des performances depuis plusieurs années par TPGet d’autres utilisateurs de TAAM, des données opérationnelles de compagnies aériennesne sont pas disponibles.

TAAM a démontré sa possibilité de simuler un aéroport et son voisinage d’une façon pro-che de la réalité. Le mécanisme des règles de TAAM est une des fonctions les plus per-formantes et utiles du système. Elles permettent de répliquer d’une manière très préciseles mouvements des avions ainsi que les pratiques opérationnelles.

Cette précision a pu être mesurée au travers des différents test de sensibilité et a aussiété reconnue par des contrôleurs aériens à qui l’organisation de référence a été présen-tée.

La possibilité d’appeler IDIS depuis le panneau principal de simulation rend le systèmetrès souple et très facile à utiliser pour tester de nouveaux concepts ou idées au cours del’exercice de simulation sans affecter la simulation de référence elle-même.

La présentation 2D/3D est efficace pour débugger et calibrer la simulation. La présenced’une fonction de revisualisation indépendante du simulateur serait utile pour la présen-tation à des participants de simulations aéroports.

Bien que davantage d’informations utiles pourraient être enregistrées par TAAM (parexemple avoir des enregistrements de temps d’occupation de piste plus réalistes), lesrésultats fournis sont complets. Un nombre important d’informations peut être extrait, soiten utilisant la fonction intégrée de génération de rapports, soit dans les fichiers de sortiedu simulateur.

Cette évaluation a aussi montré que faire une organisation de référence et sa validationdemandent une quantité de travail non négligeable. Néanmoins, une fois l’organisation deréférence faite et validée, des exercices supplémentaires peuvent être exécutés avec uneffort additionnel relativement peu important.



Après le calibrage de l’organisation de référence, des tests de sensibilité et d’améliorationtechniques de l’aéroport ont été conduits :

! La corrélation entre la demande et les flux écoulés sur la piste est bonne. Si on com-pare les résultats simulés avec les mesures faites pour les temps d’occupation despistes, on trouve que TAAM est relativement optimiste pour les arrivées et relative-ment pessimiste pour les départs.

! Des simulations refaites plusieurs fois ont montré que la stabilité du simulateur esttrès acceptable. Bien que l’impact de l’augmentation de trafic dépende beaucoup dela prévision sur les différents flux, les résultats de TAAM pour des augmentations detrafic sont prévisibles à savoir des augmentations exponentielles des délais, répartissur des périodes plus longues. Le développement d’une fonction plus performanted’augmentation du trafic peut être considéré comme une amélioration souhaitable dusystème.

! Il a été montré que peu d’effort doit être ajouté à l’organisation de référence poursimuler un changement de stratégie pour l’allocation des pistes et l’utilisation de pis-tes supplémentaires existantes. Sans l’optimisation associée des cheminements deroulage, l’opération entière de modification des données et d’analyse des résultats ademandé une demie journée de travail. La même observation a été faite pour le des-sin d’une nouvelle piste, de nouveaux taxiways, et de nouvelles positions de parkingpour les avions.

TAAM et SIMMOD sont des outils de simulation complètement différents, tant d’un pointde vue conceptuel que du point de vue de leur structure, et une comparaison directe s’a-vère difficile. L’effort et le temps demandés pour faire une simulation dépend beaucoup dutype d’aéroport simulé et du modèle utilisé. Cependant, il a été trouvé qu’avec SIMMODle temps pour faire et analyser l’organisation de référence est relativement plus court. Parcontre TAAM demande moins d’efforts pour la réalisation de tests de sensibilité, de modi-fications ou d’alternatives à l’organisation de référence. Ce point est important dans lamesure où la force d’une étude repose sur l’analyse des changements effectués selon unprocessus itératif.

3.2 PARTIE EN ROUTE & TMA

TAAM a montré beaucoup de possibilités, simulant les vols dans un environnementunique de leur début jusqu'à leur fin. Les fonctions en route donnent un ensemble derésultats complets et satisfaisants. Les outils intégrés pour la préparation des données etl’analyse des résultats ont été trouvés efficaces. Cependant, des outils auxiliaires déve-loppés en dehors de TAAM sont fortement recommandés pour faire une étude. Les résul-tats donnés par le DFS reporter (utilisé pendant l’évaluation) sont intéressants mais nepeuvent pas être adaptés à une demande spécifique de l’équipe de la simulation car lecode source n’est pas fourni.

Le module " simulation " de TAAM est très performant et a permis de simuler un échan-tillon de trafic de la CFMU augmenté de 100% (45390 vols en 24h). Le comportement desvols est réaliste particulièrement autour des aéroports.

La charge de travail totale obtenue a été trouvée logique et cohérente. Cependant, larépartition de la charge n’est pas aussi claire et détaillée que celle fournie par les outilsde simulation existants utilisés par EUROCONTROL. Des développements d’outils d’analyse dans ce domaine seraient nécessaires si les demandes de simulation restentorientées vers des analyses ATC détaillées. Par exemple, le calcul de la capacité basé surla charge de travail n’est pas disponible dans TAAM. Toutefois, l’outil TAAM bénéficied’une large communauté d’utilisateurs partageant leur expérience et la plupart de leursdéveloppements avec les autres utilisateurs. Cela a été expérimenté avec succès



pendant l’évaluation opérationnelle.

Pendant l’évaluation, il a été constaté que TAAM a le potentiel pour couvrir un très largedomaine de modélisation. Des experts dans les domaines de la sécurité, de l’économie,de l’environnement, et des aspects militaires ont été contactés pour apprécier l’usagepotentiel de TAAM pour leurs besoins actuels et futurs. Une simulation TAAM génère laplupart des évènements requis. Les outils pour leur transformation en résultats exploita-bles demandent un effort de développement.

Le point essentiel manquant dans TAAM est la capacité des secteurs, selon la normeeuropéenne (nombre maximum d’avions par période de temps). Cet élément manquantserait un point important dans le cadre de simulations combinées ATC/ATFM où des varia-tions de capacités des secteurs constituent un élément majeur à prendre en compte dansl’analyse des résultats.

Le temps demandé pour faire une simulation complète avec TAAM, comparativementavec d’autre modèles, n’a pas été déterminé précisément pendant l’évaluation. Le tempsnécessaire pour générer les données et les résultats est toujours important pour unesimulation en temps accéléré. Il dépend principalement de la taille, du niveau de précisionrecherché, et de l’objectif du projet de simulation. L’équipe de l’évaluation opérationnellen’a pas identifié de différences majeures entre les modèles pour la durée totale d’uneétude. RAMS et TAAM offrent tous les deux des facilités pour accéder à des donnéesextérieures, à condition toutefois que les bases de données et qu’un support softwaresoient disponibles.

Le support offert par TPG pendant l’évaluation a été globalement correct. Quelques difficultés ont eu lieu au début de la période de formation initiale, à cause d’une prépara-tion insuffisante de la session de la part de TPG.

Une des tâches majeures de l’agence EUROCONTROL est de traiter des aspects liés àla " Recherche et Développement ". Ceci implique souvent des besoins spécifiques. Desdéveloppements prioritaires vont induire des coûts additionnels. Un exemple de dévelop-pement de nouvelle fonctionnalité a eu lieu pendant l’évaluation mais sa réalisation pratique n’a pas pu être effectuée.

Des experts software faisaient partie de l’équipe de l’évaluation. Cependant, l’évaluationdu code de TAAM ne faisait pas partie de ce projet. La faisabilité de modifications oudéveloppements éventuels a été confirmée par TPG mais pas réellement essayée.

Enfin, si TAAM devait être utilisé dans l’agence, l’équipe de l’évaluation recommanderaitfortement de considérer 2 aspects essentiels : prévoir une ressource software suffisantepour le support/développement au sein de l’équipe TAAM et prévoir une gestion appro-priée de l’équipe effectuant les simulations au vu du nombre et de l’utilisation des licences TAAM disponibles.


022 TAAM Operational Evaluation

Documents

Transcript of 022 TAAM Operational Evaluation