EUROCONTROL EXPERIMENTAL CENTRE · EUROCONTROL Experimental Centre Centre de Bois des Bordes ... pre-tactical phase of the ATFCM ... LIST OF FIGURES Figure 1: ICO opening scheme optimisation

EUROPEAN ORGANISATION FOR THE SAFETY OF AIR NAVIGATION

EUROCONTROL

EUROCONTROL EXPERIMENTAL CENTRE

IMPROVED CONFIGURATION OPTIMISER ICO METHODOLOGY

TO USE A DECISION SUPPORT TOOL

EEC Note No. 10/05

Project NCD-F-FM

Issued: June 2005

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

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

REPORT DOCUMENTATION PAGE

Reference: EEC Note No. 10/05

Security Classification: Unclassified

Originator: NCD Network Capacity and Demand management Research Area

Originator (Corporate Author) Name/Location: EUROCONTROL Experimental Centre Centre de Bois des Bordes B.P.15 F - 91222 Brétigny-sur-Orge Cedex FRANCE Telephone: +33 (0)1 69 88 75 00

Sponsor:

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

TITLE: IMPROVED CONFIGURATION OPTIMISER

METHODOLOGY TO USE A DECISION SUPPORT TOOL

Authors C.Verlhac (EURODECISION) S.Manchon (EEC)

Date 06/2005

Pages viii + 49

Figures 15

Tables 0

Annexes 7

References 6

Project NCD-F-FM

Task No. Sponsor

Period 2004

Distribution Statement: (a) Controlled by: (b) Special Limitations (if any): None (c) Copy to NTIS: NO

Descriptors (keywords): ACC opening scheme, ACC configuration optimisation, ATFCM, ATFM, COSAAC, ETFMS, PREDICT, TACT.

Abstract:

This study aims at defining a methodology and a model to optimise ACC opening schemes during the pre-tactical phase of the ATFCM process. The method comes with the definition of a decision support tool that was also an issue of the study.

Improved Configuration Optimiser ICO Methodology to Use a Decision Support Tool EUROCONTROL

Project NCD-F-FM - EEC Note No. 10/05 v

TABLE OF CONTENTS

LIST OF ANNEXES........................................................................................................... VI

LIST OF FIGURES ............................................................................................................ VI

ABBREVIATIONS AND ACRONYMS.............................................................................. VII

REFERENCES ................................................................................................................ VIII

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

2. OPENING SCHEME MANAGEMENT TODAY .............................................................1 2.1. PREPARATION AT D-2 ................................................................................................. 1 2.2. PREPARATION AT D-1 ................................................................................................. 2 2.3. OPERATIONAL CONSTRAINTS ................................................................................... 3

3. OPENING SCHEME MANAGEMENT TOMORROW - METHODOLOGY TO USE A DECISION SUPPORT TOOL........................................................................................4 3.1. INTRODUCTION............................................................................................................ 4 3.2. ABOUT THE GLOBAL APPROACH .............................................................................. 4 3.3. PRE-TACTICAL RE-ROUTINGS AND OPENING SCHEMES OPTIMISATION:

OVERLAPPING PROCESSES ...................................................................................... 5 3.4. OPTIMISATION: AN ACC BY ACC PROCESS ............................................................. 5 3.5. PROCESS DESCRIPTION AT THE ACC LEVEL.......................................................... 6

4. IMPROVED CONFIGURATION OPTIMISATION (ICO) REQUIREMENTS..................8 4.1. FOREWORDS................................................................................................................ 8 4.2. IMPLEMENTING A HEURISTIC-BASED MODEL ......................................................... 8

4.2.1. Multi-Criterion Evaluation: Definition .................................................................8 4.2.2. Multi-criterion evaluation: mechanism .............................................................10 4.2.3. Additional Operational Features ......................................................................12

4.3. ICO INPUT DATA......................................................................................................... 13 4.4. ICO PARAMETERS ..................................................................................................... 13 4.5. CREATING A MAX-OPENING SCHEME..................................................................... 14 4.6. OPENING SCHEME EDITION..................................................................................... 17 4.7. HANDLING ASSOCIATION BETWEEN TRAFFIC VOLUMES AND SECTORS......... 17 4.8. EDITING THE OPENING SCHEME BACKBONE AND HANDLING TRAFFIC

VOLUME ...................................................................................................................... 18 4.9. TRYING A CONFIGURATION ..................................................................................... 20 4.10. OPTIMISING THE OPENING SCHEME ...................................................................... 22 4.11. ASSESSING THE EFFICIENCY OF OPTIMISED OPENING SCHEMES ................... 22 4.12. COMPARING TWO DIFFERENT OPTIMAL OPENING SCHEMES FOR THE

SAME ACC................................................................................................................... 24 4.13. COMPARING EFFICIENCIES OF AN OPTIMISED OPENING SCHEME AND OF

THE RELATED PLANNED OPENING SCHEME......................................................... 24 4.14. MINIMAL OPENING SCHEME..................................................................................... 25 4.15. NEXT BEST OPENING SCHEME................................................................................ 26

EUROCONTROL Improved Configuration Optimiser ICO Methodology to Use a Decision Support Tool

vi Project NCD-F-FM - EEC Note No. 10/05

LIST OF ANNEXES ANNEX A - Review of the most recent models and tools ............................................................. 29 ANNEX B - Heuristic versus optimal model (ICO v1.3)................................................................. 37 ANNEX C - Prototyping: ICO parameters ..................................................................................... 41 ANNEX D - Prototyping: opening scheme backbone format......................................................... 43 ANNEX E - Prototyping: Flight counts........................................................................................... 44 ANNEX F - Prototyping: Capacity values...................................................................................... 46 ANNEX G - Prototyping: optimal opening scheme format............................................................. 48

LIST OF FIGURES Figure 1: ICO opening scheme optimisation process .................................................................... 7 Figure 2: input data, constraints, and characteristics of a heuristic-based model ....................... 13 Figure 3: Opening scheme editor HMI......................................................................................... 15 Figure 4: Delay generated by the most penalising sectors/TV .................................................... 15 Figure 5: Traffic demand before (pink bars) and after (yellow bars) slot allocation ..................... 16 Figure 6: Opening scheme edition window.................................................................................. 17 Figure 7: Opening scheme backbone editor................................................................................ 18 Figure 8: Setting superspeed capacities ..................................................................................... 19 Figure 9: Setting a constraint in the backbone ............................................................................ 20 Figure 10: Trying a configuration................................................................................................... 21 Figure 11: Optimal opening scheme.............................................................................................. 22 Figure 12: Delay generated by sector/TV and other slot allocation results ................................... 23 Figure 13: Periods when delay has been generated by LECBLRD1............................................. 23 Figure 14: Slot allocation HMI ....................................................................................................... 24 Figure 15: Planned opening scheme converted into an optimal opening scheme ........................ 25


Project NCD-F-FM - EEC Note No. 10/05 vii

ABBREVIATIONS AND ACRONYMS

Abbreviation De-Code ACC Air Control Centre

ARN ATS Route Network

ATC Air Traffic Control

ATFCM Air Traffic Flow & Capacity Management

ATFM Air Traffic Flow Management

ATM Air Traffic Management

ATS Air Traffic Services

CASA Computer Assisted Slot Allocation

CFMU Central Flow Management Unit

COSAAC Common Simulator to Assess ATFCM Concepts

ECAC European Civil Aviation Conference

ETFMS Enhanced Tactical Flow Management System


viii Project NCD-F-FM - EEC Note No. 10/05

REFERENCES [1] “Optimisation of Air Traffic Control sector configurations using tree search methods and

genetic algorithms” D. Gianazza and J.M. Alliot – LOG and CENA.

[2] “Decision Support For Sector Grouping: Final Report - Lisbon ACC optimisation” L. Rocha – “An Optimisation Approach to Support the Grouping and Scheduling of Air Traffic Control Sectors” A. P. Barbosa-Povoa, P. Leal de Matos and L. Rocha – IST Lisbon.

[3] “Optimisation of opening schemes” C. Verlhac and S. Manchon – Eurodecision and Eurocontrol.

[4] “OPTICON” (Optimise configuration) – CFMU.

[5] Air Traffic Flow & Capacity Management Evolution Plan for the ECAC States.

[6] FMD manual - Pretactical procedure (19 June 2002).


Project NCD-F-FM - EEC Note No. 10/05 1

1. INTRODUCTION

This study aims at defining a methodology and a model to optimise opening schemes during the pre-tactical phase of the ATFCM process. The main issue is to adapt capacity to demand by assigning the ATC manpower through the notion of ACC configuration.

Research area “Network Capacity & Demand management” (NCD) carried out this study in accordance with the lines of actions that are expressed in the ATFCM evolution plan to foster collaborative decision making between ATFCM actors.

Another issue of this study is to define a decision support tool that could be implemented in a future release of the ETFMS system.

2. OPENING SCHEME MANAGEMENT TODAY

At the pre-tactical level, opening scheme management consists in optimising the configuration of one ACC according to a maximum number of working positions that can be manned during a given time period.

Today, this is a “local-to-the-ACC”-based process. This should be done at the level of several ACCs in order to achieve the best compromise at a network level i.e. to guarantee continuity in capacity along main traffic flows.

We contacted Mr Julio Teijeira, head of Barcelona FMP. He explained that manpower was quite stable according to the day of the week. Configurations of the ACC are defined 3 days in advance. They are modified as requested during the tactical phase with a time horizon of 1 to 2 hours, tactical monitoring being essentially done with the RCA. No co-ordination with neighbouring ACCs is managed except on Wednesdays and on Fridays in the context of the Iberian Axis (Southwest axis teleconference).

The description of the pre-tactical process given hereafter is essentially based on the description made by Mr Philippe Deregnaucourt, head of FMP REIMS.

Basically, REIMS FMP performs the pre-tactical phase in two steps: If D is the day of operation, step one begins at D-2 and the next one at D-1. The opening scheme prepared at D-2 is a draft opening scheme. It is updated during D-1.

2.1. PREPARATION AT D-2

Two days before the day of operation, the FMP prepares a draft opening scheme. The number of control positions to be manned is computed following the manpower constraints. This is a “local-to-the-ACC”-based process. Time period 6h30-21h30 is carefully examined in order to know very precisely the maximum number of working positions that can be manned.

The French COURAGE tool is used to build the draft opening scheme. The FMP loads the opening scheme and the actual traffic demand of the same day of the previous week (D-7 is the “reference day”).

The traffic samples available in COURAGE (FMP version) are the initial traffic demand and the actual traffic. The initial traffic demand is not touched by pre-tactical re-routing scenarios while the final traffic demand and the actual traffic are. The actual traffic also includes the impact of regulation measures and of all operational disturbances.


2 Project NCD-F-FM - EEC Note No. 10/05

In fact, Reims FMP would rather prepare their regulation plan on the basis of the final traffic demand i.e. the traffic demand that is the final input to the slot allocation process. Unfortunately, this traffic model was not available to the FMP in 2003 when we started this study.

The draft opening scheme is not entirely built since the FMP analyses only the congestion problems for the morning of the day of operation. Propagation of operational disturbances being different from one day to another, the flow manager carries out traffic flow and capacity monitoring during the tactical phase.

The opening scheme is modified to take into account the manpower constraints. If a configuration causes an overload, then another configuration can be chosen. But, depending on the traffic model that is used, it might require taking into account the regulation set of the reference day. Those regulations are checked and, if necessary, modified or deleted. If one regulation is still justified (congestion problem over a given area) then it is kept. Otherwise, the regulation rate can be modified (modification of traffic volume capacity) or deleted if it is no longer required.

REIMS FMP makes the difference between ATFM sector and ATC sector. The capacity defined for an ATFM sector does not reflect the complexity of the sector in terms of ATC. Using traffic volumes is a good strategy. For example, if the lower part of a sector contains evolving traffic then, defining a global capacity for this sector is not the right strategy. A traffic volume that reflects that particularity has to be defined and a capacity value calculated. For example, LFEEUHXH is the ATC collapsed sector that is generally protected by LFEUHL4. LFEUHL4 captures traffic through LFEUHXH between FL195 and FL275. This also means that according to traffic complexity, several TFVs can be defined and regulations applied simultaneously in order to protect only one sector or collapsed sector. For example, LFEPON4 and LFEPTV4 refer to LFEEURUY collapsed sector. They can be applied together to protect Paris.

The FMP daily monitoring report that contains the requested regulations and the ACC opening scheme is generated.

The FMP also sends the opening scheme in terms of traffic volumes, thus a requested regulation plan, to the CFMU.

Then, by receiving those requests from all the FMPs, FMD can declare the planned regulations in the PREDICT system. PREDICT is a particular release of the TACT system dedicated to pre-tactical activities. It uses the same ENV database than the TACT system, thus inherits all updates on real-time.

2.2. PREPARATION AT D-1

As expressed in the FMD manual, to facilitate the collaborative decision making process, the FMPs assist the FMD with checking the sector configurations, activation time periods and capacities as displayed in PREDICT on day D-1.

FMPs in co-ordination with FMD also check relevance of the planned regulation measures, hence modify them if necessary. From 12h30 UTC to 13h30 UTC, every FMP can evaluate the impact of the regulation measures set by other ACCs. At this stage the local expert can adjust the traffic volumes capacities according to the network effect between regulations. Some regulations can even be deleted. This verification is done by using the PREDICT tool.

At 14h00 UTC, the Airspace Use Plan (AUP) being available to the FMP, the military activity can be taken into account. Some sector capacities can accordingly be reviewed. The regulation measures can be modified. In case of a modification, the FMP has to resume co-ordination with NMC.



In the same way as for the draft opening scheme, the updated opening scheme is built only for the morning.

At the end, the updated opening scheme is sent to the CFMU.

The operational drifts are handled during the ATFM tactical phase. The ACC ATC supervisor and the FMP tactical flow manager monitor the traffic flows. When necessary they modify the configuration with a time horizon of –3h down to –1h30. From the CFMU point of view, the monitoring is done by the Tactical Network Co-ordinator (TNC).

2.3. OPERATIONAL CONSTRAINTS

• NMC experts carry out a first investigation of re-routing and flight level capping scenarios at 9h00 UTC. NMC in co-ordination with each FMP negotiate these solutions to major capacity problems by 12h00/12h30 UTC in order to finalise the ATFM regulation plan around 14h30 UTC.

• For Reims ACC, the minimal duration of a configuration is 1h30 during the daytime and 30 min during the evening.

• The graphical user interface that will be designed as an aid to the NMC for optimising the opening scheme should display a global view of the studied area in order to enhance co-ordination between FMPs.



3. OPENING SCHEME MANAGEMENT TOMORROW - METHODOLOGY TO USE A DECISION SUPPORT TOOL

3.1. INTRODUCTION

The methodology described in the following lines is based on the collaboration process between ATFCM actors: FMD/NMC and FMPs. It requires a decision support tool. Today’s way of working would not be fundamentally changed. The model we designed deals with local optimisation of opening scheme. The tool could be used at the level of one ACC. It would also be used at CFMU central echelon in order to make compatible and to make complementary one to each other the opening schemes of a set of ACCs. We call this set the “Area Of Interest” (AOI). The AOIs are likely to be the areas of investigation of the Northwest and of the Southwest axis teleconferences, or sub-sets of them.

The Graphical User Interface (GUI) we present helps in taking into account local requirements expressed by ACCs. Different scenarios can be tested and compared one to each other.

The method can be divided in four steps, each of them being described in the next paragraphs:

1. Defining the AOI.

2. Pre-processing the global traffic demand by applying re-routing scenarios and by defining the opening scheme backbones.

3. Optimising the opening schemes one by one.

4. Performing final global assessment.

We call opening scheme backbone the set of constraints that are defined by the flow manager. Each constraint can be seen as a vertebra. For example, if the Flow Manager knows by experience that during one time period, due to particularities in traffic flows, a particular traffic volume (TV) inevitably has to be applied, he would positioned this constraint or vertebra. The optimisation process will take into account this backbone to generate an optimal opening scheme.

Vertebras can be:

• Structurally congested sectors, collapsed sectors (CS), or TV. • Maximum control positions that can be manned during a time interval. • Constraint to guarantee capacity continuity within the ACC or between several ACC,

possibly resulting from the application of re-routing scenario or else. • Any other local constraint required by one ACC.

3.2. ABOUT THE GLOBAL APPROACH

Optimisation models studied within the ICO project showed that it is very difficult to optimise ACC opening schemes taking into account the network effect during the optimisation process itself. This kind of macroscopic slot allocation procedure could only be modelled as a non-linear model (see paragraph A.3). The solution is not optimal and computing takes several minutes. Moreover, the network effect depends on known traffic flows and airspace structure. Those often change according to identified ATFCM problems. This means that coupling constraints between sectors and collapsed sectors would have to be redefined each time a modification of the airspace structure occurs.



For this reason, we decided that the NMC specialist in close co-operation with local flow managers would define coupling constraints between sectors, in order to guarantee capacity along traffic flows. Nevertheless, this approach has been studied in [3], model 3. Network effect could also be handled by performing such a pre-processing as described in [1].

3.3. PRE-TACTICAL RE-ROUTINGS AND OPENING SCHEMES OPTIMISATION: OVERLAPPING PROCESSES

If D is the day of operation, the final traffic demand of D-7 generally used during the pre-tactical phase (from D-2 to D-1) is “corrupted” at least by the re-routings and by the flight level cappings that were applied during D-7. Hence, we suggest building a clean traffic demand of reference by applying counter re-routings. This action is optional in case the re-routings of the day of reference are kept.

Traffic growth factors can also be applied in order to increase or decrease traffic flows according to special events.

The flow manager can as well tweak the traffic demand of reference by substituting traffic patterns such as the NAT eastbound traffic to the traffic demand of reference.

Applying flight level capping or/and re-routing can alleviate some of the choke points. Thus, those re-routings can be translated as input constraints to the opening scheme optimiser: it would not seem relevant collapsing a busy sector that is off-loaded by a re-routing. On the same way, one sector can be on-loaded when applying a re-routing and might require being handled individually, too.

All those input constraints have to be applied during opening scheme optimisation.

Hence, the output of this process of defining re-routings, flight level cappings, constraints to guarantee capacity along traffic flows, is a partially regulated traffic demand (according to the re-routing and flight level capping scenarios) and the backbones of the opening schemes of the ACCs of the AOI.

The local flow manager and the network manager can freely modify the backbone of an opening scheme.

After this, the optimisation of the opening schemes of the ACCs of the AOI will be performed.

3.4. OPTIMISATION: AN ACC BY ACC PROCESS

The opening schemes will be optimised with ICO. The resolution principle is based on a heuristic (presented in paragraph 4.2). The heuristic takes into account the partially regulated traffic demand (re-routing scenarios, traffic patterns…), the constraints expressed by the flow manager, and the ATC manpower.

ICO aims at filling optimally the gaps of the backbone opening schemes. Of course, the more gaps, the more efficient and useful the optimisation process will be.

Optimisation is performed at the level of the ACC. Nevertheless, a global approach is performed by the mean of the different constraints that can be set before optimisation, as presented in paragraph 3.3.



Parameters such as the minimal duration of a configuration during a time interval, and the period of optimisation are defined. Optimisation could be limited to a time interval (morning, afternoon, H24, any other time interval).

Figure 1 describes the ICO optimisation process.

3.5. PROCESS DESCRIPTION AT THE ACC LEVEL

Relevant opening scheme can only be built if both the traffic demand and the available configurations, including capacity values and traffic volume descriptions, are of a good quality.

Building a realistic traffic demand: The traffic models that are available in CFMU systems are the final traffic demand (FTFM), the final traffic demand after slot allocation (RTFM), and the actual traffic (CTFM). The traffic model that is the most appropriate to the pre-tactical activity is the FTFM model. But, the FTFM of reference (usually D-7 if D is the day of operation) has been modified by re-routings applied during day D-7. Some of these re-routings might be applied during the D-day but probably not all of them. For this reason, we suggest to perform counter-re-routings to re-assign on standard routes a part of the final traffic demand according to the exceptional events that have been recorded during D-7.

Defining the backbone: One interesting assessment would be to point out the structural problems of the airspace. This would consist in building a “maximum” opening scheme: All sectors of every ACC would be opened and protected by the usual traffic volumes. Then, a slot allocation would be performed. This would point out the most penalising sectors. Those would have to be controlled individually or grouped together with a non-busy sector (see paragraph 4.5 Creating a MAX-opening scheme).

The backbone of the opening scheme is based on these structurally congested sectors, collapsed sectors, and traffic volumes, but also on some constraints that the flow manager could express such as the maximum control positions that can be manned during one time interval, or any other local constraint.

Constraints to guarantee capacity continuity within the ACC or between ACCs can also be added. Those could result from the application of one re-routing scenario.

After this, ICO optimisation can be carried out. A slot allocation would follow this optimisation in order to highlight the most penalising constraints. Some of those could be additional constraints to optimise the opening scheme or replace constraints that were defined. The mock-up we implemented makes the optimisation of three opening schemes takes completed in less than 2 min and a slot allocation to evaluate the efficiency of the optimal opening schemes performed in a few seconds. In order to make it efficient, we consider that this collaborative activity between ACCs, AOs, and FMD requires designing a quick and co-operative tool the ATFCM expert can use in a what-if mode.


Pre-tactical scenarios

Clean traffic demand

Final traffic demand

Parameters (min duration of a

config…)

Locally defined opening schemes

Rerouted traffic

Opening scheme backbones

Optimised opening schemes

Re-routing scenarios FL cappings

Define opening scheme backbone

ICO

Apply counter re-routings

TV capacities

Configuration

COMMON DATA

Constraints of capacity continuity

Airspace

Figure 1: ICO opening scheme optimisation process




4. IMPROVED CONFIGURATION OPTIMISATION (ICO) REQUIREMENTS

4.1. FOREWORDS

The ICO tool could be integrated into any pre-tactical system that enables the user to analyse traffic flows, to apply re-routing, and to perform a slot allocation.

NMC specialists being familiar with the COSAAC tool, and the prototyping of Graphical User Interface (GUI) being quite easy according to the technology used in COSAAC development, it has been decided to implement a mock-up of the ICO GUI in this environment. This will speed up validation of the requirements.

After evaluation, both the requirements of the GUI and of the heuristic will be published for future use in the CFMU’s PREDICT/OPTICON software.

4.2. IMPLEMENTING A HEURISTIC-BASED MODEL

Four methods of optimisation of opening schemes have been studied. They are presented in ANNEX A - Review of the most recent models and tools. The objective of this section is to define a heuristic to solve the problem.

A heuristic being based on the user expertise, it generally gives output the specialist can understand thus validate quite easily. Moreover, taking into account many operational constraints may result in unnecessary too complex optimal model.

4.2.1. Multi-Criterion Evaluation: Definition

The main objective of the multi-criterion evaluation is to give the user a great variety of possibilities in the way of optimising the opening scheme of a centre. The criteria are:

− Overload (minimization). − Weighted overload (minimization). − Continuity (maximization). − Number of working positions (minimization). − Number of overloaded airspace entity (minimization or maximization).

Overload: This is the total number of flights exceeding the monitoring capacity on all the sector/CS of a centre.

Example

Configuration 2_0 is composed of 2 airspace entities AS1 and AS2. Assuming the capacity and flight count values on a given time step are those given in the following table, the overload for configuration 2_0 is 3. In addition, if the weight of the overload is 10 then the overload cost is 30 = 3 * 10.

Capacity Flight Count OverloadAS1 10 13 3AS2 8 4

2_0 3

0



Weighted overload: This is another version of the overload penalization taking into account the rate of the overload (underload/overload). The user can define many categories of weights according to this rate. For instance, that criterion allows the user to give priority to the configuration that generates the most underload.

Example with 3 categories of weighted overload

Overload rate 90%-100% 100%-110% 110%-130%Weight 1 10 100

Configuration 3_0 is composed of 3 airspace entities AS1, AS2 and AS3. Assuming the capacity and flight count values on a given time step are those given in the following table, the weighted overload cost for configuration 3_0 is 318 = -2 * 1 + 10 * 2 + 100 * 3.

Capacity Flight Count Overload Overload rateAS1 20 18 -2 90.00%AS2 22 24 2 109.09%AS3 12 15 3 125.00%

3_0 318

Continuity ratio

The continuity ratio is computed following the number of airspace entities in common between 2 configurations at different time steps. It is used to keep as long as possible the same configuration at a given number of control positions and favour the configurations with same control positions when the manpower is changing.

The ratio is included between 0 and 1; the value of 1 corresponds to the evaluation of the configuration which is the same as the previous one (same configuration at the previous time step). The continuity ratio is not a penalty like the others criteria that is why its weight is negative in the evaluation function.

Example

Assuming the configuration 2_0 is composed of {AS1, AS2} and the configuration 3_0 is composed of {AS1, AS3, AS4}, AS1 is the single airspace entity in common between both configurations.

Then, the continuity ratio between 2 different time steps and both configurations is 0,5 = 1/2 if configuration 2_0 was chosen at the previous time step (1: number of airspace entities in common and 2 = total number of airspace entities of the previous configuration). The continuity cost in the objective function is 0,5 * 10 = 5 if the weight of this criterion is 10.

0,33 = 1/3 if configuration 3_0 was chosen at the previous time step.

Number of working positions.



This criterion is used to minimise the manpower required to monitor the ACC (computation of the minimal opening scheme).

Example

Manpower available 3

Configurations Number of control position2_0 23_0 3

Assuming the number of control position needed at a given time step is 3 and the weight for the number of control position is 10, the configuration 2_0 which requires less manpower has a cost of 20 whereas configuration 3_0 has a cost of 30.

Number of overloaded airspace entities

This criterion is used to minimise the number of airspace entities that are overloaded for the ACC.

Example

Configuration 3_0 is composed of 3 airspace entities AS1, AS2, and AS3. Assuming the capacity and flight count values on a given time step are those given in the following table, the number of overloaded airspace entities is 2.

If the weight associated to this criterion is a positive value such as 10 then the impact is to concentrate the overload on a small number of airspace entities. Else, if the weight is a negative value such as –10, the impact is to dispatch the overload on many airspace entities.

Capacity Flight Count Overload Number overloaded AS

AS1 20 18 -2 0AS2 22 24 2 1AS3 12 15 3 1

3_0 2

Total cost

The total cost of configuration on a given time step is:

Total cost = OverloadCost + WeightedOverloadCost – ContinuityCost + NumberOfWorkingPositionCost + NumberOfOverloadedEntityCost

4.2.2. Multi-criterion evaluation: mechanism

All the criteria of the evaluation function are independent and can be combined in order to obtain different results for the optimisation. Each criterion has a weight associated to it, which allows fine-tuning of the optimisation process. Compensatory or lexicographical weights can be used:

• A compensatory weight means that criteria can have the same evaluation cost. For instance, the overload cost on a given airspace entity and a given time step can be equivalent to the cost of keeping the continuity of configuration between 2 different time steps.



• Otherwise, weights can be lexicographical which means that each criterion has a cost corresponding to its level of importance: a scale of weights is defined so that the heaviest weight is used for the most important criterion and the smallest weight is used for the least important. In this case, criteria can never have the same evaluation cost.

Example

Assumptions:

• the number of available control positions is 4 and 3 configurations {4_0, 4_1, 4_2} can be selected,

• the configuration 4_0 was chosen on the previous time step:

configurations 4_0 and 4_1 have 1 airspace in common, configurations 4_0 and 4_2 have no airspace in common, only the overload criterion and the continuity criterion are taken into account

(positive weights).

Lexicographical weights: the smallest overload value (one) has a cost of 10 and the highest value of the continuity ratio has a cost of 1 then continuity criterion can never compensate overload criterion.

Overload Weighted overload Continuity ratio Nb working positions Nb overloaded ASWeight 10 1

Configuration Values Overload Weighted overload Continuity ratio Nb working positions Nb overloaded AS Total4_0 3 1 294_1 2 0.25 19.754_2 2 0 20

Configuration 4_0 has an overload of 3 flights, and a continuity ratio of 1 (= 4/4 * 1):

• total cost = 30 – 1 = 29

Configuration 4_1 has an overload of 2 flights, and a continuity ratio of 0.25 (= 1/4 * 1):

• total cost = 20 – 0.25 = 19.75

Configuration 4_2 has an overload of 2 flights, and a continuity ratio of 0 (no airspace in common):

• total cost = 20 – 0 = 20

The configuration 4_1 will be selected because it minimises the total cost.

Compensatory weights: an overload value of 2 has a cost of 2 which is equivalent of the continuity cost when 2 configurations are the same on different time steps.

Overload Weighted overload Continuity ratio Nb working positions Nb overloaded ASWeight 1 2

Configuration Values Overload Weighted overload Continuity ratio Nb working positions Nb overloaded AS Total4_0 3 1 14_1 2 0.25 1.54_2 2 0 2

The configuration 4_0 will be selected because it minimises the total cost.



4.2.3. Additional Operational Features

The following types of constraints are taken into account:

• Manpower constraint: depending on the time period of the day, the maximum number of working positions for the configuration cannot be discarded.

• Minimal duration of a configuration: depending on the time period of the day, a configuration has a minimal duration.

• Some configurations, airspace entities or traffic volumes can be imposed for a given time period with a specific capacity value.

• Some configurations, airspace entities or traffic volumes can be excluded for a given time period.

The computation time should be small enough in order to use the tool in a what-if mode. This seems a fair way to implement collaborative decision-making (we set the calculation time to a maximum of 2 min on average for a set of 3 ACCs).

The construction of new configurations is not an issue of the tool: it depends on operational and/or technical constraints. Hence, the use of pre-defined ACC configurations is more realistic.

In the same way, the airspace entities (including traffic volumes) that are considered are only those defined by the ACC during the strategic ATFCM phase.

Flight counts are used to compare traffic demand to capacity in order to minimise overloads. We selected 30-minute counts by default. Taking into account a tolerance margin on those counts seems to be more efficient than working with flight plans. Moreover, the combinatorial complexity of the model becomes very high when using flight plans: the problem would be very similar to a slot allocation process. It seems more efficient to stay at a macroscopic level.

Traffic volumes are characterised by one or several capacity values and a reference location that can be a beacon, an airport, a sector, or a set of those elements. The uncertainty on the declared capacity values will be addressed by applying a tolerance margin on the flight counts.

The manpower constraint will be the one declared by the ACC to the CFMU (registered opening scheme).

Optimisation will be carried out during a given period that could be a whole day or a few hours in relation to the moment when it is performed.



Figure 2: Input data, constraints, and characteristics of a heuristic-based model

4.3. ICO INPUT DATA

• Airspace design (sectorisation, beacons, airports, ARN…). • ACC configurations. • Sectors and traffic volume capacities (without military activity). • 3 traffic demand models: final (FTFM), regulated (RTFM), and current (CTFM). • Registered opening schemes. • Pre-tactical re-routing scenarios.

ACC configurations, planned opening schemes, and traffic volume and sector capacities are extracted from the ETFMS ENV, every day for the next 7 days. Nevertheless, the user can manually modify any capacity value. In the current version of the prototype, new user capacity values are not recorded.

4.4. ICO PARAMETERS

The user can parameterise the tool by giving the time step and the frequency of configuration changes:

• Both counts and capacities are considered on the basis of the time step. By default, the time step is set to 30 min.

• Depending on the ACC, the frequency of configuration change can vary depending on time. By default, the minimal duration of a configuration is set to 1 hour all day long. Variable frequency can be defined statistically and recorded in the user parameters.

• Parameters are recorded in a text file. A new window of parameters will be created if necessary to handle those parameters.

• Minimise resources (number of working positions) or not. • Maximal number of N-best opening schemes to search for.



Go to ANNEX C - to get a detailed list of parameters.

As examples, two possible Areas of Interest are given: one based on the ACCs that attend the North-West teleconference; the other one consists of the ACCs that attend the South-West teleconference. But, smaller AOIs can be defined. Local optimisation based on a single ACC can also be carried out.

If optimisation is required for several ACCs at the same time, the model does not require global optimisation (see 3.4 Optimisation: an ACC by ACC process). Optimisation is performed ACC by ACC.

4.5. CREATING A MAX-OPENING SCHEME

A MAX-opening scheme is an opening scheme with the maximum number of control positions manned H24.

Using a MAX-opening scheme would help in analysing the structural problems of the AOI. This will help in highlighting the most busy airspace elements, that should be, at this stage, elementary sectors.

This activity is more a “local-to-the-ACC” activity than a central one.

Building a MAX-opening scheme is not mandatory but it could help in evaluating very quickly the most penalising sectors, collapsed sectors, and TV. Thus, it would help in highlighting the airspace volumes that would be worth being handled individually or grouped with other non-busy airspace elements.

The flow manager can define the MAX-elementary configuration using a graphical window like the one shown in Figure 3. After this, he/she will define the MAX-opening scheme by applying the MAX-elementary configuration H24 as shown hereafter:



Figure 3: Opening scheme editor HMI

Highlighting the most penalising airspace elements will be performed running the delay allocation process with the MAX-opening schemes of the AOI. The contribution of each sector to the total delay generated could be displayed as represented on Figure 4.

Figure 4: Delay generated by the most penalising sectors/TV



The load graph of Figure 5 also shows when LECBLRD generates delay, thus when it should be degrouped (between 13h00 and 19h30 in the example).

Figure 5: Traffic demand before (pink bars) and after (yellow bars) slot allocation

Constraints passed to ICO can also be based on the implementation of a pre-tactical re-routing following the mechanism of off-loaded/on-loaded sectors: one on-loaded sector might need being handled individually. This can be the case for an on-loaded sector as a result of the additional flights. Other constraints of capacity continuity along traffic flows through neighbouring ACCs can be applied too. Those constraints are already addressed today during teleconferences with AOs, FMPs, and FMD.



4.6. OPENING SCHEME EDITION

The flow manager can create/modify the opening scheme planned by an ACC by using an appropriate window like the one shown on Figure 6.

List of knownconfigurations

List of knownnumber ofworkingpositions

Switch: Convertssectors/CS in TV ifpossible according toassociation rules (seeparagraph 4.7) or doesnot.

Edition window

Opening scheme

Figure 6: Opening scheme edition window

4.7. HANDLING ASSOCIATION BETWEEN TRAFFIC VOLUMES AND SECTORS

ICO applies the following rules during optimisation in order to treat TFVs instead of sectors:

(Rule 1) Any constraint imposed by the user (sector protected by sector or by a particular TFV and capacity) cannot be discarded. If no solution can be found according to user requirements, ICO returns an error.

(Rule 2) If a sector is protected by no TFV then the sector and declared capacity of the sector is taken into account by ICO.

(Rule 3) If for one sector only one TFV is defined, this TFV and associated capacity are kept.

(Rule 4) If for one sector, many TFV are defined then the one which has the biggest capacity value is kept.

(Rule 5) If rules 1 to 4 fail, then the entire sector is protected according to its declared capacity.

If some of the rules do not correspond to the operational constraint, the user will be able to save the association between a sector or a collapsed sector and a traffic volume. Related capacities can be also modified and recorded.



These rules can also be superseded by user-defined capacities, according to day of the week (weekday, Weekend), or according to Military activity scenario. The Flow Manager can impose a sector be protected by a particular TV with a particular capacity.

4.8. EDITING THE OPENING SCHEME BACKBONE AND HANDLING TRAFFIC VOLUME

The opening scheme backbone is initially based on the opening scheme that has been planned by the ACC. Filed opening schemes are extracted from the PREDICT ENV.

The user has to load those filed opening schemes for the ACCs of the AOI so that manpower and the corresponding period of availability are known by ICO.

By default ICO considers those variables as input constraints. Nevertheless, the flow manager can modify both the number of working positions and time intervals.

To do this, the flow manager will use a GUI like the one presented on Figure 7.

The flow manager can add input constraints regarding capacity continuity, and/or specific traffic volume application (ES/CS/TV can be specifically declared as “mandatory” or can be excluded), and/or a temporary capacity value. But, the number of constraints has to be as small as possible so that the problem remains sufficiently combinatorial in order to keep the optimisation process efficient.

Select ACC by ACC

Click to add in selected ACCs Opening scheme backbone based

on the planned opening scheme

Click to define supersed capacities

Figure 7: Opening scheme backbone editor

The user can select in the main Opening scheme window the time period he wants to focus on simply by clicking on it with the left button of the mouse. Then, Select makes the time period appearing on the right part of the window called Displayed slot. In this editing window, the user can modify the time period, and/or the number of working positions.



He can also select one opening strategy according to the number of working positions available by clicking in the top-right list (column called 1 solution near column Potential, in this example). Instead of applying an opening strategy which makes the optimisation process useless, he can simply select which TV should be apply due to application of a pre-tactical re-routing or else. In the following example, LECBLEV has been selected first in the list of all the sectors and collapsed sectors of Barcelona ACC (left column in the Displayed slot window. Then, all the traffic volumes that are known to protect this sector appear by clicking in the default capacity figure (right column, same window). In this example, LEC2LEV1 has been chosen and set as a constraint. The * shows that the user has decided that the collapsed sector LECBLEV1 would be protected by applying the TV LEC2LEV1 (as it is defined in the ETFMS ENV Database) with a capacity of 38 aircraft per hour. The user can also change the capacity value of an airspace entity. In case of manual modification, the new capacity value is written in yellow.

Sectors and collapsed sectors are associated automatically with a TV if one exists. Nevertheless, the user can define several capacity values or/and TV that may explicitly protect a sector. This is shown in Figure 8. At the level of the edition window, these capacities are highlighted.

Figure 8: Setting superspeed capacities

The superseding capacities values are written in grey in the configuration editor window.



Figure 9: Setting a constraint in the backbone

In case of a capacity during military activity, the new capacity value is written in green.

A backbone can be saved with a user-preferred extension. The planned opening scheme can be edited and saved as a backbone too. The same mechanism can be applied to an optimal opening scheme.

4.9. TRYING A CONFIGURATION

The flow manager can try a configuration, i.e. compared demand to capacity according to this configuration by selecting the configuration and then by right-clicking in the configuration name. The following window will appear (see Figure 10).

Each cell of the table contains for a 30-min time period, the traffic demand on the left (number of aircraft to get through the ES/CS/TV), and the capacity (hourly capacity divided by 2) on the right.

Several windows such as this one can be displayed in order to compare different configurations.



Figure 10: Trying a configuration

Automatic generation of a synthetic table that would contain the number of overloaded ES/CS/TV and the cumulative overload could be given as well (see Figure 10). This option has not been evaluated.

For example, when 6 working positions are available between t1 and t2, 6_2 is the best ACC configuration: 4 sectors are overloaded for a cumulative overload of 12 aircraft. Configuration 6_4 is the second best choice with the same total overload but spread on a smaller number of sectors. The order of the list depends on the related parameter value (largest/smallest number of overloaded sectors).



4.10. OPTIMISING THE OPENING SCHEME

Once the backbone has been defined, the flow manager can perform the opening scheme optimisation simply by clicking on the ICO push-button (see Figure 11).

Figure 11: Optimal opening scheme

An optimal opening scheme can be saved with a user-preferred extension. This allows comparing two optimal opening schemes based on different backbones thus ATFCM scenarios.

4.11. ASSESSING THE EFFICIENCY OF OPTIMISED OPENING SCHEMES

In order to assess the efficiency of the optimal opening schemes of the ACCs that have been selected, a CASA slot allocation is performed automatically once the optimised opening scheme has been created. It is based on all the opening schemes thus taking into account the network effect.

Flow managers need knowing which capacity constraints generated delay, the number of flights delayed, and the total delay generated. This helps in checking for example if pre-tactical re-routings and configurations are compatible.

A macroscopic representation of this could be the following one (generated automatically after allocation, but that can be generated on request if necessary):



Figure 12: Delay generated by sector/TV and other slot allocation results

Click on one bar to get the number of flights that have been treated, the number of flights that have been delayed, the delay generated, and other information such as average delay, max delay…

Also click on the bar to know when the delay has been generated in order to modify the opening scheme backbone and try a new optimisation.

Figure 13: Periods when delay has been generated by LECBLRD1

In this example, most of the delay has been generated after 14:00 until 19:30.

A GUI like the following one could be also used if the user wanted to re-performed the allocation after having applied a rerouteing for example:



Figure 14: Slot allocation HMI

Click on Allocate to perform the slot allocation based on all the opening schemes thus taking into account the network effect.

4.12. COMPARING TWO DIFFERENT OPTIMAL OPENING SCHEMES FOR THE SAME ACC

The flow manager may want to compare two different optimal opening schemes based on two different ACC opening strategies. This will be done easily by building two different backbones. Clicking on Save Backbone can save any backbone.

In the same way, at the end of any ICO optimisation, the resulting optimised opening scheme can be saved by clicking on Save Optimised.

Assessing the efficiency of any optimal opening scheme is presented in 4.11 Assessing the efficiency of optimised opening schemes. Hence, comparison of total delays, of delay distributions by TV… can be performed.

4.13. COMPARING EFFICIENCIES OF AN OPTIMISED OPENING SCHEME AND OF THE RELATED PLANNED OPENING SCHEME

A planned opening scheme (the one that has been declared by the ACC to the CFMU) can be evaluated. This could be done automatically by applying the set of rules to handle association between sectors/CS and TVs (see paragraph 4.7).



Figure 15: Planned opening scheme converted into an optimal opening scheme

This mechanism allows direct and objective comparison between the optimised opening scheme and the planned one.

The following ICO edition window shows LECBACC planned opening scheme converted in traffic volume opening scheme. If a sector/CS has no declared capacity, which means that a capacity value is known only for the corresponding TV, then it is written in red.

In this case, the ACC planned opening scheme is seen as an optimised opening scheme. A slot allocation can be performed for direct comparison with the optimal solution.

4.14. MINIMAL OPENING SCHEME

Instead of using the declared resources, it will be possible to minimise this number provided that no overload is created.

The minimal opening scheme corresponds to the opening scheme causing the minimal overload with the smallest number of working positions. It can be obtained by activating the both criteria overload and number of working positions, with a greater weight for the overload criterion, because priority is given to overload minimisation.

This could be a default user-defined behaviour parameter. Otherwise, minimise resource could be triggered by right-clicking on the ICO button. Two options would appear: One default for optimisation on the basis of the declared resources i.e. the declared number of working positions. Or, minimise WP to allow minimising the number of working positions.

As an output, ICO would highlight by changing from yellow to green the cell that contains the name of the configuration (see Figure 15).



4.15. NEXT BEST OPENING SCHEME

ICO will generate a maximum of a user-defined number of possible opening schemes.

All those could be displayed on sequence by clicking on a next/previous button (not implemented in the demonstrator).

The efficiency of each opening scheme has to be evaluated through the slot allocation process in order to take the network effect into account.

A next best opening scheme is constructed by imposing the selection of a different ACC configuration when saturation of at least one ES/CS/TV is detected. The ICO constraint that privileges continuity in configuration shall guarantee that ICO will not go back to the initial best configuration. The current PREDICT system does not address this issue since PREDICT focuses on one 60-minute slice. In this case, a ranking mechanism like the one presented in paragraph 4.9 Trying a configuration, Figure 10, can be used to sort out configurations according to cumulative overload.

In the current version of COSAAC, the next best opening schemes are generated as separate opening schemes that can be easily loaded and evaluated via the Load Optimised button (see Figure 15).



ANNEXES



Page intentionally left blank



ANNEX A - REVIEW OF THE MOST RECENT MODELS AND TOOLS

A.1 “OPTIMISATION OF AIR TRAFFIC CONTROL SECTOR CONFIGURATIONS USING TREE SEARCH METHODS AND GENETIC ALGORITHMS” D. Gianazza and J.M. Alliot

A.1.1 Description

In this paper, the optimisation of one opening scheme takes into account the traffic overloads as traffic under-loads, the maximum number of control positions and a set of configurations which is not limited to the ACC’s configurations (pre-defined). Indeed, the construction of new configurations is allowed and submitted to constraints:

• one configuration must cover the whole ACC’s airspace, • it must be a partition of this airspace in a given number of control positions.

The sectors and group of sectors are given.

The optimisation is done for a given time step. A period is optimised by running the optimisation in successive time subdivisions (or time steps) of this period.

A tolerance around the capacity value is taken into account. The objective function is a multi-criterion objective which penalisations are given by decreasing order of value:

• Overloads and under-loads that are out of the tolerance limits (strongest penalisation). • Overloads and under-loads that are included in the tolerance limits. • Number of control positions.

For one ACC, the number of possible configurations depends on the number of sectors and collapsed sectors. Potentially, this number ranges between a few hundreds and half a million. Hence, 2 types of algorithm have been tested: the first one is based on a tree-search algorithm. The second one applies genetic algorithm techniques. All of them are based on one methodology of construction of a configuration (described in page 3).

Tree-search algorithms

• Enumeration: exploration of all the configurations which can be built at this time step and selection of the best one according to its cost (objective function described above).

• Branch and bound: the exploration stops in a given branch when at a given node the cost of the node is worst than the best cost found until this node.

• A*: same exploration as the branch and bound algorithm but with a different searching criterion.

Genetic algorithm: stochastic search of the best configuration according to its cost.

A.1.2 Input data

• Sectors and groups of sectors definitions. • Capacities declared by ACC’s (not depending on the configuration), upper and lower

tolerances. Study period• and time step.

• The traffic demand: final traffic demand or regulated demand (with all elementary sectors opened) - counts of flights per time step. The registered opening scheme or max• imum number of control positions during the period of study.



A.1.3 Tests Assumptions

• One day studied (21/05/1999).

• 2 strategies:

a. Final traffic demand and no constraint on the maximum number of control positions.

b. Regulated traffic demand (with all elementary sectors opened) and constraint on the maximum number of control positions.

A.1.4 Output

a. Final traffic demand and no constraint on the maximum number of control positions.

The tree-search algorithms are optimal according to the solution given by the basic algorithm, the fastest being the branch and bound algorithm. The enumerative algorithm could not give any results for some ACCs such as AIX and BORDEAUX because of their high combinatorial complexity.

For these ACCs, the genetic algorithm – for which time computation is long compared to the tree-search ones - gives near-optimal results. Indeed, the number of control positions of the configurations can be higher than the configurations chosen by the deterministic algorithms.

b. Regulated traffic demand (with all elementary sectors opened) and constraint on the maximum number of control positions.

In order to improve the results given by the genetic algorithm (in terms of number of control positions used) a constraint on the maximum number of control positions has been implemented in the model. Moreover some overloads were detected for some ACCs (such as BORDEAUX). To handle this the traffic demand is regulated according to a slot allocation process run over the ACC with all elementary sectors opened; then, the optimisation of the configurations does not give anymore overloads.

A.1.5 Conclusion

This approach of the opening scheme optimisation allows the construction of new configurations, which could be an interesting issue if its construction were not dependent on operational/technical feasibility constraints.

Even if the branch and bound algorithm is fast, it is limited by the combinatorial complexity (set of sectors and group of sectors) of the ACCs. The genetic algorithm could be a better algorithm if used in the context described in the strategy b).

In both cases (tree-search or genetic algorithm), the network effect is not really handled directly with strategy b) but opening all elementary sectors, allocating and regulating the ACC on this basis arises its structural problems. Moreover, this is a way to propagate the overloads correctly in time and space.

The results described in this article are only based on one-day traffic sample, which is not satisfactory, the algorithm robustness having to be tested too. It could be interesting to define a 30-min time step instead of the 60 min one.



roups of sectors. in.

elementary sectors and 2 per time step for groups

• umber of control positions. po itions.

A.2 “DECISION SUPPORT FOR SECTOR GROUPING: FINAL REPORT - LISBON ACC OPTIMISATION” L. ROCHA – “AN OPTIMISATION APPROACH TO SUPPORT THE GROUPING AND SCHEDULING OF AIR TRAFFIC CONTROL SECTORS” A. P. Barbosa-Povoa, P. Leal de Matos and L. Rocha

A.2.1 Description

Those papers describe a decision support tool for the construction of opening schemes.

The model is a linear program based on a Sectors Flights Network (SFN) model. It is based on the description of flight plans. An estimated departure time and one airspace profile (sequence of sectors) characterise each flight. Then, different routes involving the different groups of sectors are associated to each flight. The model simulates the slot allocation process in relation to the maximum workload value for a controller. The workload is basically the maximum number of strips the controller can manage at a time. It also optimises the choice of the configurations taking into account the constraints of compatibility between sectors, groups of sectors and the maximum number of control positions. It minimises flight delay and penalises the choice of elementary sectors in favour of groups of sectors. The model does not focalise on one time step particularly, a whole period can be optimised.

The combinatorial complexity becoming too high when optimising a whole day; one solution consists in running a succession of optimisations on small periods.

A.2.2 Input data

• Sectors and groups of sectors definitions. • The instantaneous capacity value (based on the number of strips a controller can handle

at the same time). • Period of investigation and time step. • The final traffic demand: flight plans. • The registered opening scheme or the maximum number of control positions during the

period of study.

A.2.3 Tests assumptions: 2 days studied

14/04/2000, 1187 flights over the whole day. • Lisbon ACC. • Sectors and 4 groups of sectors. • Study period: 2h. • Time step: 5min. • A capacity value of 12 per time step for each sector and group of sectors. • Maximum number of control positions.

From 0 to 7h and 22h to 24h: 3 control positions. From 7 to 22h: 6 control positions. 6, about 100 flights per period. 25/04/199

• Bordeaux ACC. • 4 sectors and 2 g• Study period: 2h and time step: 5m• A capacity value of 3 per time step for

of sectors. Maximum nFrom 0 to 7h and 19h to 24h: 2 control sFrom 7 to 19h: 3 control positions.



A.2.4 Output

The model gives optimal solutions in less than 5 minutes for most of the periods; the chosen configurations are composed of elementary sectors while the traffic is dense and composed of groups of sectors else which seems to be a good behaviour. The delay reduction is really important in relation to the delay generated by the slot allocation process on the registered opening scheme.

A.2.5 Conclusion

The model is close to the operational activity; the use of the instantaneous capacity value takes into account the real maximum workload of the ATC, which is a better illustration of the ATC activity than the hourly capacity. Instantaneous capacity seems more adapted to the tactical ATFM phase. Hourly capacity is more a pre-tactical dimension. Any optimisation according to the instantaneous workload would be too much dependent on input data variations, which has to be avoided during the ATFM pre-tactical phase. The flight initial trajectory could be taken as a variable defined with pre-tactical re-routings.

This model should have been tested on a bigger airspace including more sectors and groups of sectors. It could also be interesting to test it on more days (with dense traffic loads) in order to evaluate its robustness to the traffic variation and to the available number of control positions variation. The model allows changing every 5 minutes the opened configuration, in an operational context this could not be feasible. Indeed, co-ordination time between controllers has to be taken into account while changing a configuration; the minimal duration for a configuration is at least 15 min from an operational point of view, and of 30 minutes when statistically computed (average duration).

It could be interesting to optimise a whole day with sliding periods in order to take into account the delay cumulated in a previous period.

This approach is not limited to one ACC. An optimisation could be worked out on different ACCs. This would require that the combinatorial complexity would be reduced by not taking into account the whole airspace of each ACC.

This model is solved with CPLEX library.

A.3 “OPTIMISATION OF OPENING SCHEMES” C. Verlhac and S. Manchon

A.3.1 Description

In this paper, a description of three models is given. Two of them are based on a local approach (ACC by ACC optimisation) and one is based on a global approach (multi-ACC optimisation):

• The first model (M1) is simple. It minimises the traffic overloads.

• The second model (M2) spreads these overloads to the next time steps. It locally minimises delays.

• The third model (M3) adds a constraint linking the airspace entities1 between them: the overloads are spread on next slots in time and space. These links between entities are statistically computed according to the final traffic load. This model simulates a kind of macroscopic slot allocation process.

1 airspace entity : sector or group of sectors characterized by a capacity value at a given moment (instantaneous or hourly capacity).



Those models can take into account some constraints on the frequency of configurations changes that can be managed on given time periods (for description of patterns, see paragraph A.6). They take into account the maximum number of control positions over the whole day.

A.3.3 Input data

• Sectors and groups of sectors definitions. • Configurations definitions. • Capacities declared by ACCs. • Study period and time step. • Final traffic demand. • Registered opening scheme, maximum number of control positions during the period of

study.

A.3.3 Test

• 27 traffic samples. • French airspace (7 ACCs) and Zurich, Geneva, Aix, Barcelona airspaces. • 2 benchmarks taking into account a frequency of configuration change of:

− 30 min time step (HH: a single period all over the day, with a minimal duration of 30 min whatever the pattern),

− defined periodically (STAT: during night duty none or few changes, during daytime few changes and during come on/off duties full changes).

A.3.4 Output

Local approach

For both first and second models, the solution can easily be proven optimal using standard MIP procedure included in the CPLEX library.

Comparison M1/M2: the model (M1) gives good results (gain around 30% on total delay) whatever the traffic day and the parameterisation; moreover the computing time is very efficient (less than 40 s). Nevertheless, the model M2 is more effective when the combinatorial complexity is low.

M3: like model M2, M3 provides good solutions even if it is a global oriented approach resolution model. However, the CPU time is long.

Comparison (HH)/(STAT): (HH) parameterisation is more flexible than (STAT) that is why it generally gives better results. However, (HH) parameterisation generates more layouts changes, particularly between 8h and 15h UTC, but at a frequency which is of the same magnitude than what can be observed today when traffic demand grows in the morning or declines at the end of the day. If necessary, the rhythm of layout changes can be satisfied applying the (STAT) parameterisation.

Global approach

The local approach analysis of the model’s behaviour is still true for the global approach: the model M1 gives good results for a small CPU time. Models M2 and M3 are also effective, but the calculation time can go up to 18 min for 6 ACCs. The third model is not optimal and especially long due to the resolution algorithm. Model M3 is not more efficient than the other ones for most of traffic days.



A.3.3 Conclusion

Model M1 is simple, quick and very efficient. But, due to the network effect, the set of restrictions that are derived from the different opening schemes would still need being handled by the CFMU for harmonisation. The model with patterns has the advantage of keeping close to operational activity. It is true that one can parameter the frequency of layout changes and the optimisation period in the models. The model is solved with the CPLEX library.

A.4 OPTICON (OPTIMISE CONFIGURATION)

A.4.1 Description

OPTICON is a module of the PREDICT system used during the pre-tactical phase of the ATFCM process. OPTICON computes the configurations that generates the less overloads for a given ACC and for a given time period. This period is subdivided in time steps. For each time step, the OPTICON computation process consists in sorting out the configurations by increasing order of overloads generated. If many configurations generate the same overload, the second criterion is the number of control positions (by increasing order too). The computation of overloads takes into account a tolerance for flight counts and also the overload generated in a previous time step.

OPTICON uses the traffic demand or the regulated traffic demand as an input data. The network effect is handled by using the regulated traffic demand. Indeed, that means OPTICON will take into account the flow restriction measures defined on this ACC and on other ACCs. But the optimisation process is local to one ACC.

A.4.2 Input data

• Sectors and group of sectors definitions. • Configurations definitions. • Study period and time step. • Traffic volumes capacities. • The traffic demand regulated or not (counts of flights per time step) per traffic volume.

A.4.3 Parameters

• Force a configuration at a given moment. • Give a preference for a configuration with such a minimal and/or a maximum number of

control positions. • Give a tolerance for the flights counts. This parameter enables the user to take into

account the operational disturbances that make the flights counts distorted.

A.4.4 Tests

Not communicated.



A.4.5 Conclusion

OPTICON solves the problem of choosing the best configurations for one ACC using a heuristic based on simple principles (selection of the configuration that minimises the overloads and the number of control positions opened). It takes into account traffic volumes based on reference locations that are sectors and group of sectors. Moreover, the OPTICON tool involves the user: he/she can force a configuration and change the traffic load according to him/her knowledge of the situation when running the optimisation.

The network effect is not handled directly but by using the regulated traffic demand.

In order to evaluate the performance of this heuristic in term of computation time, robustness and quality of the solution, some tests will have to be done on several heavy traffic loads and several ACCs.

A.5 SUMMARY: COMPARISON OF THE 4 MODELS

LOG/CENA IST EEC OPTICONACC databaseAirspace design: sectors and group of sectorsConfigurations constructed constructed

5 MN

Capacities instantaneous traffic volumesRegistered opening schemeTraffic demandPredictedRegulatedParametersConfiguration forcing mechanismNumber of control positions forcing mechanismTolerance for traffic demandFrequency of configuration change

Time step 1 H 30 MN variableFlight counts flight plans

AlgorithmTree search

Genetic LinearLinear

Quadratic HeuristicSolver None Cplex Cplex None






ANNEX B - HEURISTIC VERSUS OPTIMAL MODEL (ICO V1.3)

B.1 INPUT DATA

• ACCs considered: Aix-East (LFMACCE), Aix-West (LFMACCW), Barcelona (LECBACC), Bordeaux (LFBBACC), Brest (LFRRACC), Geneva (LSAGACC), Paris-East (LFFACCE), Paris-West (LFFACCW), Reims (LFEEACC), Zurich (LSAZACC).

• Sets of layouts and capacities of airspace entities (updated every cycle of 28 days; 2 cycles of data: 2001/05/17, 2001/06/14).

• Variation in the number of control positions.

• 27 heavy traffic samples.

B.2 PARAMETERS

The minimal duration of a configuration has been set to:

• half an hour (every 30-minute operational configuration changes can be observed during growing and falling traffic),

• one hour, • 2 hours.

The reference opening schemes can be:

• empty backbones, • registered opening schemes also known as Reference opening schemes i.e. those that

have been filed by the ACCs. The configurations read in the registered opening scheme are created if they do not exist in the ACC configurations database.

In both cases, no configuration or airspace entity has been forced, only the manpower is forced.

Objective function:

• penalisation of the overload of the configurations, • multi-criterion: penalisation of the overload of the configuration + penalisation of the

overload of each airspace entity weighted according to the size of the overload (100%-110%-130 %) + favour the largest collapsed sectors.

B.3 TESTING

These tests have been completed on a Pentium 3 PC under Linux.

For each day, ACC opening scheme optimisations are performed on sequence. The quality of the optimised opening schemes has been assessed in terms of total ground delay generated by each ACC. On that purpose, the ISACASA module developed by the Eurocontrol Experimental Centre has been used in order to simulate a CFMU slot allocation process. This module is connected to the COSAAC simulation platform.

Moreover, a first slot allocation has been worked out on the basis of the actual registered opening schemes.



Eight different sequences of optimisation have been done:

• Over the French airspace (7 ACCs): LFMACCE, LFMACCW, LFFACCE, LFFACCW, LFBBACC, LFRRACC, LFEEACC taking into account the initial traffic demand of the 27 traffic days.

- Heuristic without report of overload, based on the registered opening scheme and taking into account the overload/multi-criterion function as objective function.

- Heuristic without report of overload, based on the backbone opening scheme. The overload/multi-criterion function is the objective function.

- Linear program without report of overload taken into account (see [3] – M1) and minimising both the overload and the number of configurations changes.

• Over the CEAC area (6 ACCs): LFMACCE, LFMACCW, LFEEACC, LSAGACC, LSAZACC, LECBACC taking into account the actual final traffic demand of the 27 traffic days.

- Heuristic with/without report of overload, based on the registered opening scheme, and with the overload/multi-criterion function as the objective function.

- Heuristic with/without report of overload, based on the backbone opening scheme, and taking into account the overload/multi-criterion function as objective function.

- Linear program without report of overload (see [3] – M1), and minimising both the overload and the number of configurations changes.

- Linear program with report of overload taken into account (see [3] – M2), and minimising both the overload duration and the number of configurations changes.



B.4 COMPUTATIONAL RESULTS

The profit in p.c. for one ACC, is the variation of the delay generated by a slot allocation process respectively applied to the reference scheme and to the optimised opening scheme for this ACC. In consequence, this represents a local profit.

Results for the French airspace30 60 120

ReferenceAverage profit (%) -29.34 -23.97 -17.23Average number of configurations 9.93 16.44 13.33 10.94

ReferenceAverage profit (%) -29.50 -21.79 -13.99Average number of configurations 9.93 15.86 13.07 11.17

ReferenceAverage profit (%) -27.26 -26.57 -Average number of configurations 9.93 10.95 10.95 -

Minimal duration of a configuration (min)

Registered (no report)

Backbone (no report)

Linear program M1 (no report)

Results for the ECAC area30 60 120

ReferenceAverage profit (%) - -35.13 -35.88 -33.42Average number of configurations 11.23 14.03 12.33 12.27


ReferenceAverage profit (%) - -37.19 -37.19 -Average number of configurations 11.23 11.45 11.45 -



ReferenceAverage profit (%) - -29.51 -29.51 -Average number of configurations 11.23 10.96 10.96 -

Linear program M2 (with report)

Registered with report

Backbone with report


Linear program M1 (no report)





Comparison between a minimal duration of a configuration of 30, 60, and 120 min

The heuristic gives good results (around 30% of gain) when parameterised with a minimal duration of a configuration of 30 min but the number of configurations changes is important compared to the opening scheme of reference. The 60-min parameterisation seems to be more relevant.

Comparison between the optimisation based on registered and backbone opening schemes

As expected the optimisation based on the registered opening schemes gives better results than the backbone opening schemes. Indeed, the configurations from the registered opening schemes are created even if they are not identified in the ACC configurations database.

Comparison with an optimal solution

The results in term of average profit (%) are comparable (gap of 2%) between the heuristic and the linear program of optimisation M1 even if their objective is not the same.

Comparison between no report/report taken into account

The heuristic can take into account the report of overload in order to simulate a kind of macroscopic regulation process (network effect, propagation of overload) but does not give better results.

Comparison between the minimisation of overload and the minimisation of a multi-criterion objective

Results for the ECAC area

ReferenceAverage overload 215.8Average number of configurations 10.5




Reference

Average overload 215.8Average number of configurations 10.5

60

M1 (min overload + nb config)

170.911.7




173.311.0

168.815.6

171.512.9

168.517.8

171.1

Multi-criterion / Registered

Multi-criterion / Backbone

168.517.9

171.114.0

14.0

30

168.815.6

171.512.9



ANNEX C - PROTOTYPING: ICO PARAMETERS

Two parameters files are needed to run ICO. The first file, called “parameters” file contains general information. The second file, called “optimParam” file contains all the parameters used for the optimization.

The parameters file contains the following information:

• the name and location of the input data files, • the list of ACCs to optimize, • the validity duration for flight count data, • the choice to generate or not the trace files, • the period of study, • a list of time periods with a minimal configuration duration for each, • the format of the results file (display the traffic volume name if used, or always display the

airspace entity name).

Here is an example of a commented parameters file:

#Parameters file for the “Optimization of opening schemes” tool DEV/ARCH_local NOEXTENSION #directoryCA and extensionCA DEV/DATA/strategies_new #directoryStrat DEV/DATA/capacities #directoryCapa cosaac_util/alsecs #directoryFlight Optimisation/data/liens #not used anymore Optimisation/data #not used anymore Optimisation/debug # directoryDebug Optimisation/results #not used anymore cosaac_util/ARCH NOEXTENSION #not used anymore and extensionBB 20000907 #dateCA 20000901 #dateStrat 20000915 #datePln 20000913 #dateBB CEAC #name of study area FTFM #traffic type (ITFM, FTFM, RTFM or CTFM) 30 #1/2h validity duration for flight count data 1 #generation of trace files (0 else) CEAC 2 LECBACC LECMACN #the list of ACCs to optimise FRANCE 0 #not used anymore 0 1440 #beginning of the study period end of the study period 1 #number of periods 0 1440 60 #a period with a minimal duration for a configuration of 60 minutes on it 0 #result type: 0 = Airspace, 1 = Traffic volume

The optimisation parameters file contains the following information:

• the choice to use the gasel files or not, • the name of the test, • the list of overload categories, • for each criterion, if it is activated or not, and its weight, • the choice to generate or not the scenario file.



Here is an example of a commented optimisation parameters file:

1 // flag set to 1 if the gasel files are used testName // the name of the test 1 // set to 1 if the criteria "minimise overload" is used, 0 otherwise 1 // weight used in the objective function for the criteria "minimise overload" 1 // set to 1 if the criteria "minimise the overload by category" is used, 0 otherwise 0 // set to 1 if the criteria "minimise the nb of AS entities overloaded" is used, 0 otherwise 0 // weight used in the objective function for the criteria "minimise the nb of AS entities overloaded" 1 // set to 1 if the criteria "minimise the difference with the previous configuration" is used, 0 otherwise 10 // weight used in the objective function for the criteria "minimise the difference with the previous configuration" 0 // set to 1 if the criteria "minimise the number of control position" is used, 0 otherwise 0 // weight used in the objective function for the criteria "minimise the number of control position" 4 // nb of overload category 0 100 0 // minBound maxBound Coef for the category 1 100 110 1 // minBound maxBound Coef for the category 2 110 130 10 // minBound maxBound Coef for the category 3 130 infinite 100 // minBound MaxBound Coef for the category 4 (the max bound, here infinite, isn't read ) 0 // set to 1 to generate scenario file, 0 otherwise 1 // maximum number of generated solutions



ANNEX D - PROTOTYPING: OPENING SCHEME BACKBONE FORMAT

The opening scheme backbone will have the same file format as the registered opening scheme. Referring to the methodology to use ICO, the opening scheme backbone could be modified following the results given by the optimisation; because ICO is a what-if tool the background of the different steps (backbone edition, optimisation edition) will be kept. The name of the opening schemes will take into account the background:

• COUR-date.iteration.LECBACC.sch.bb for the backbone number iteration where iteration corresponds to the number of optimisations ran from the beginning of the study.

Each line begins with a specific code: 00 Comment 01 Version 02 AIRAC cycle date 03 Flight plan date 04 Number of configurations of the opening scheme 05 Name – Abbreviation of the ACC 06 Type of the opening scheme 10 Name of the configuration – Time step of beginning – Time step of ending - Number of control positions – Number of sectors and collapsed sectors included in this configuration. 11 ??? – Name of the sector or collapsed sector – Capacity – number of sectors – name of each sector 12 0 0

The opening scheme backbone only contains the configurations or the sector/collapsed sectors forced or excluded by the user.

The number of configurations in the backbone corresponds to the number of configurations forced in addition to the number of sector/collapsed sectors forced outside configurations.

Example: LECBACC backbone definition:

2_0 is a configuration forced from 12H00 to 13H00 − LECBCEN is a collapsed sector and LECBECO is a traffic volume (“TV_”) forced from 14H30 to

15H00 − LECBCE1 is a sector excluded (“-“) from 14H30 to 15H00

00 schéma d'ouverture du centre LECBACC pour la journée du vendredi 18-05-2001. 01 Version V2.0 02 18-05-2001 03 17-05-2001 04 2 05 LECBACC LECBACC 06 BACKBONE 10 2_0 720 780 2 2 11 ??? LECBE 30 6 LECBCE1 LECBCE2 LECBENOR LECBESUR LECBMEDN LECBMEDS 11 ??? LECBW 31 7 LECBLEV1 LECBLEV2 LECBLRDN LECBLRDS LECBWA1 LECBWA2 LECBWA3 12 0 0 10 XXX 870 900 2 3 11 ??? LECBCEN 35 2 LECBCE1 LECBCE2 11 ??? TV_LECBECO 33 0 11 ??? –LECBCE1 20 0 12 0 0

In this case, LECBCEN and LECBEM are 2 collapsed sectors forced outside a configuration that is why the name of the configuration is a default name set to “XXX”.






ANNEX E - PROTOTYPING: FLIGHT COUNTS

The optimisation process requires flight counts files that can be generated with COSAAC. The counts have to be done over all the sectors, group of sectors and traffic volumes which belong to the ACCs studied. The counts are given per time step of half an hour (depending on the type-step defined in the parametres file (see ANNEXE C – Prototyping ICO parameters).

File sample: Superposition standard pour le centre LECBACC Trafic LAST DEMAND du 18-05-2001 Schema DEPOSE du 18-05-2001 Taux de croissance du trafic : 0% GEO hour

00H00 00H30 01H00 01H30 02H00 02H30 03H00 03H30 04H00 04H30 05H00 05H30 06H00 06H30 07H00 07H30 08H00 08H30 09H00 09H30 10H00 10H30 11H00 11H30 12H00 12H30 13H00 13H30 14H00 14H30 15H00 15H30 16H00 16H30 17H00 17H30 18H00 18H30 19H00 19H30 20H00 20H30 21H00 21H30 22H00 22H30 23H00 23H30

LECBBALSE 0/0 0/0 2/0 3/0 3/0 0/0 0/0 0/0 1/0 3/0 1/0 3/0 4/0 7/0 4/0 9/0 5/0 5/0 5/0 6/0 6/0 3/0 8/0 6/0 11/0 6/0 8/0 8/0 8/0 4/0 5/0 2/0 7/0 3/0 7/0 4/0 8/0 6/0 3/0 1/0 3/0 2/0 4/0 3/0 2/0 1/0 0/0 0/0 LECBCE1 0/0 1/0 0/0 1/0 2/0 0/0 4/0 1/0 2/0 1/0 4/0 3/0 8/0 13/0 6/0 12/0 13/0 7/0 13/0 8/0 9/0 15/0 8/0 6/0 6/0 8/0 9/0 9/0 9/0 13/0 13/0 9/0 10/0 9/0 9/0 5/0 7/0 2/0 9/0 8/0 5/0 9/0 5/0 3/0 2/0 6/0 5/0 4/0 LECBCE2 3/0 2/0 2/0 1/0 2/0 1/0 1/0 2/0 1/0 3/0 8/0 10/0 9/0 13/0 6/0 12/0 12/0 13/0 16/0 8/0 18/0 14/0 7/0 21/0 10/0 12/0 20/0 9/0 11/0 11/0 17/0 11/0 8/0 9/0 9/0 18/0 8/0 12/0 11/0 15/0 11/0 5/0 3/0 1/0 0/0 2/0 0/0 0/0

The first 5 lines are comments. Then, for each sector and group of sectors the number of flights par half an hour is given: AirspaceName numberFlight/capacityValue






ANNEX F - PROTOTYPING: CAPACITY VALUES

The hourly capacity values are registered in capa.ACC files. However, because ICO is using traffic volumes capacity values, a file containing all the capacity values should be used. Capacities are extracted from the PREDICT ENV DB. The following GASEL file will be used:

05/09/2002;LEBL2NW;00:00;23:59;999;999;AS;G;B 05/09/2002;LEBL3NE;00:00;23:59;999;999;AS;G;B 05/09/2002;LEBL3NW;00:00;23:59;999;999;AS;G;B 05/09/2002;LEBZ;00:00;23:59;2;0;AD;G;B 05/09/2002;LECBACC;00:00;23:59;23;999;AS;G;B 05/09/2002;LECBALSE;00:00;23:59;43;999;TV;G;B 05/09/2002;LECBBALSE;00:00;23:59;999;999;AS;G;B

Each line contains:

05/09/2002 = the date LECBALSE = the name of the object treated (airspace, traffic volume...) 00:00;23:59 = the period of definition of the capacity, time of beginning and time of ending 43 = capacity value 999 = TV = type of object (AS = airspace, TV = traffic volume...) G = B = type of database of extraction






ANNEX G - PROTOTYPING: OPTIMAL OPENING SCHEME FORMAT

As an output of the optimisation process, opening schemes are generated. These opening schemes will be located in the results directory and will have .ico as extension.

A sample of such a file is given hereafter. The format of the file is similar to the backbone format (see ANNEXE D – Prototyping/ opening scheme backbone format):

00 Schema d'ouverture du centre de LECBACC pour la journee du 20031128 01 Version V2.0 02 20031128 03 20031127 04 8 05 LECBACC LECBACC 06 DEPOSE 10 3_3 0 330 3 3 11 ??? TV_LECBE 34 12 LECBCE1H LECBCE1L LECBCE2H LECBCE2L LECBENORH LECBENORL LECBESURH LECBESURL LECBMEDNH LECBMEDNL LECBMEDSH LECBMEDSL 11 ??? TV_LECBLRD1 46 0 11 ??? TV_LECBWAL 34 6 LECBLEV1H LECBLEV1L LECBLEV2 LECBWA1 LECBWA2 LECBWA3 12 0 0 3_3 10 8_0 330 450 8 8 11 ??? TV_LECBCENB 22 0 11 ??? TV_LECBECO 22 4 LECBENORH LECBENORL LECBESURH LECBESURL 11 ??? TV_LECBLEV4 34 0 11 ??? TV_LECBLRD1 46 0 11 ??? TV_LECBMED2 44 0 11 ??? TV_LECBWA1 36 0 11 ??? TV_LECBWA2B 42 0 11 ??? TV_LECBWA3 36 0 12 0 0 8_0 10 8_1 450 1170 8 8 … 12 0 0 8_1 10 6_7 1170 1210 6 6 … 12 0 0 6_7 10 4_0 1210 1320 4 4 … 12 0 0 4_0 10 3_3 1320 1440 3 3 11 ??? TV_LECBE 34 12 LECBCE1H LECBCE1L LECBCE2H LECBCE2L LECBENORH LECBENORL LECBESURH LECBESURL LECBMEDNH LECBMEDNL LECBMEDSH LECBMEDSL 11 ??? TV_LECBLRD1 46 0 11 ??? TV_LECBWAL 34 6 LECBLEV1H LECBLEV1L LECBLEV2 LECBWA1 LECBWA2 LECBWA3 12 0 0 3_3

Documents

EUROCONTROL EXPERIMENTAL CENTRE · EUROCONTROL Experimental Centre Centre de Bois des Bordes ... pre-tactical phase of the ATFCM ... LIST OF FIGURES Figure 1: ICO opening scheme optimisation