ABCD Tool Prototype Definition

Transcription

1 Aircraft Based Concept Developments ABCD Tool Prototype Definition SPECIFICATIONS This document presents a synthesis of information aiming to support discussions concerning Aircraft Based Concept Developments. It does not represent the position of EUROCONTROL Agency. 1

2 DOCUMENT CHANGE RECORD The following table records the complete history of the successive editions of the present document. EDITION DATE DESCRIPTION OF EVOLUTION MODIFICATIONS 0.1 October 15 th 2008 First Draft 0.2 December 19 th 2008 Second draft Feedback from ALG 2

3 SUMMARY This deliverable (D4), presents the results for Work Package 4 ABCD tool prototype definition, as part of the ABCD project. The purpose of this Work Package is to refine the description of the ABCD concept and to define the specifications of the ABCD tool at airline level in order to develop a prototype in Work Package 5. The ABCD concept, which is based on the linkage of the individual flight plans executed by the same aircraft, aims at using the flight planning and flight progress information available for a given flight in order to detect as soon as possible potential reactionary delay for the subsequent flights. The envisaged ABCD tool will be installed as a complementary system to the existing flight management system of the airline; providing the Airline Operations Centre (AOC) with assistance to flight planning through an aid to the management of DLA messages. The ABCD tool will not interact directly with the CFMU: any interchange of information will be uniquely done with the airline systems and the user, without interfering with the normal operations of the airline. As input, ABCD will be provided, via the airline flight management system of the AOC, with the set of messages exchanged between the airline and the CFMU, and also with additional data such as the minimum turn-around times and the aircraft registration numbers. As output, ABCD will provide the AOC with information that allows the user to decide when to send a new DLA message and with the optimum EOBT proposal. The ABCD operational services were defined according to 5 levels, which provide the airline with flexibility to choose the required service for each situation: - Level 0 allows the user to monitor reactionary delays; - Levels 1 and 2 detect reactionary delays and propose flight updates (new EOBT), taking into account or not stability criteria; - Levels 3 and 4 provide automated DLA management: preparation and proposal of DLA messages, with the option of sending messages directly to the CFMU. A set of functional requirements has been defined to provide the user with those services: user interface requirements; airline system requirements; requirements internal to the ABCD system. They are the minimum specifications required to allow the prototyping of a generic ABCD tool. Additionally non-functional requirement are proposed to define a possible lay-out for the HMI needed between the user and the tool. However the HMI design depends on the preferences and needs of each airline hence does not have to be detailed at the generic level. 3

4 TABLE OF CONTENTS 1 INTRODUCTION BRIEF OVERVIEW OF ABCD PAST ACHIEVEMENTS PURPOSE AND SCOPE OF THE DOCUMENT DOCUMENT STRUCTURE ABCD CONCEPT ABCD AT A GLANCE ABCD Concept From the concept to the tool implementation ABCD tool at airline level STAKEHOLDERS Airlines ATFCM Service Providers (CFMU) ANSPs ATS Providers (incl. Airport Towers) Airport Ground handlers Passengers ABCD ENVIRONMENT HUMAN ACTORS Airline Operations Centre Staff SYSTEM ACTORS Flight Management System CFMU Systems MESSAGES & DATA Types of messages managed by ABCD Elementary data associated to messages Current operational context associated ated to messages Messages description Other data managed by ABCD ABCD REQUIREMENTS FOREWORD REQUIREMENTS RELATED TO HUMAN ACTORS Operational Services Functional requirements Non functional requirements uirements REQUIREMENTS RELATED TO SYSTEM ACTORS Principles and preconditions Functional requirements REQUIREMENTS INTERNAL TO ABCD Functional requirements nts Non-Functional requirements

5 LIST OF TABLES Table 1: Messages potentially handled by ABCD (depending on current airline message interchange) Table 2: ABCD database layout Table 3: Data to extract from the messages to update the database Table 4: Requirements list Table 5: Matrix of dependencies (next page) LIST OF FIGURES Figure 1; ETFMS functions Figure 2: The ABCD environment Figure 3: Example of a possible configuration of the display

6 GLOSSARY A/C ACK ADEP ADES ADEXP AFTN ANSP AO AOC ARCID ARCTYP ARN ARO ARR ATFCM ATFM ATC ATM ATS ATSU CASA CDM CFMU CHG CNL CTOT DEP DLA ELDT ENV EOBT EPOBT ETFMS FMP FPL FUM GAT IFPS IFR IRAB MVT OPSD Aircraft Acknowledgement message Aerodrome of Departure Aerodrome of Destination ATS Data Exchange Presentation Aeronautical Fixed Telecommunication Network Air Navigation Service Provider Aircraft Operator Airline Operation Centre Aircraft Identification Aircraft type ATS Route Network Air Traffic Service Reporting Office Arrival Message Air Traffic Flow and Capacity Management Air Traffic Flow Management Air traffic Control Air Traffic Management Air Traffic services Air Traffic services Unit Computer Assisted Slot Allocation (CFMU) Collaborative Decision Making Central Flow Management Unit Change Message Cancellation message Calculated Take-off Time Departure Message Delay Message Estimated Landing Time Environment (system) Estimated Off-Block Time Earliest Possible Off-Block Time Enhanced Tactical Flow Management System Flow Management Position (ACC) Filed Flight Plan Flight Update Message General Air Traffic Initial Flight Plan Processing System Instrument flight rules Innovative Research Advisory Board Movements Operational Division (of CFMU) 6

7 REA RPL SAM SLC SRM TACOT TTLEET TIS TOT TRS TTM Ready Message Repetitive Flight Plan Slot Allocation Message Slot Requirement Cancellation Message Slot Revision Message TACT Automated Command Tool Total Estimated Elapsed Time Time to Insert into the Sequence Time-Over Target Time to Remove from the Sequence Minimum Turn-Around Time 7

8 REFERENCES [1] ABCD: Aircraft Based Concept Developments - Work Packages n 1 and n 2 [2] IRAB Evaluation of CARE projects 2007 [3] IFPS Users Manual, Edition 12.3, November 2008 [4] ATFCM Users Manual, Edition 12.0, September 2007 [5] CFMU Flight Progress Messages, Edition 1.5, January 2008 [6] EUROCONTROL Standard Document for Data Exchange Presentation (ADEXP), Edition 2.1, December

9 1 INTRODUCTION 1.1 Brief overview of ABCD The Aircraft Based Concept Developments (ABCD) project proposes to improve flight predictability by linking individual flight plans using the same aircraft for a given day through the aircraft registration information. As an aid to flight plan management, the ABCD tool implemented with an airline should: - provide the airline with a better picture of aircraft operations on a daily basis, - help the airline to detect reactionary delays and to notify them to the CFMU as early as possible by proposing a new EOBT. The purpose of ABCD is twofold: on the one hand at a local level to decrease the total delay of the airline (ATFM and reactionary delay) using an ABCD tool, and on the other hand at a global level to optimize the use of the available ATC capacity. 1.2 Past achievements In 2007, ADV Systems and ALG carried out together the description of the ABCD concept and identified its potential benefits [1]. They stressed the following points: Qualitative (interviews and analyzed examples) and quantitative analyses showed that the ABCD implementation could improve the traffic predictability and bring tangible benefits to ATM stakeholders (airlines, CFMU, airports). The interviews have established that the implementation of ABCD would provide low-cost and regional airlines with an efficient tool to recalculate automatically new EOBT for subsequent flights, using the same aircraft as an initial delayed flight, once the delay on the initial flight has been detected and found to be propagated throughout the subsequent flights. Those airlines therefore consider that ABCD would facilitate and optimise the management of delays and thus stated their interest in the ABCD concept implementation. However, it has to be acknowledged that the ABCD concept implementation should not be imposed to all aircraft operators as some of them, in particular major airlines, have already in operation some tools whose scopes encompass the ABCD functions and go far beyond the ABCD project objectives. Moreover, in the case of major disruptions, those airlines have the ability and the resources to swap aircraft for a given flight incurring too much 9

10 delay. Thus, they are reluctant to use an ABCD tool when they have their own ABCD-like tool. At the end of this first phase, it was decided to carry on the study in order to undertake a precise analysis of the benefits brought by ABCD and to move on to the tool development. The second phase of the ABCD project which started at the beginning of 2008 and which is planned to end in early 2009 is structured as a set of seven work packages that develop, simulate and validate the ABCD concept. This study revolves around two themes: - the first one, which includes WP3, 4, 5, 6 and 7, focuses on ABCD development: It aims first to assess, through a Cost Benefit Analysis, the economic viability of the ABCD tool when implemented by an airline (typically a low-cost or regional airline). In the same way, the technical implementation of an ABCD concept requires to specify how this concept would technically fit with existing ATM systems and especially the airline systems. In particular, the way information and data from existing systems could be used in order to implement this concept, will be analyzed and a concrete implementation model will be proposed. The study shall therefore produce some functional and operational specifications which will help to produce and develop an ABCD prototype PC based tool. - the second axis, WP8 and WP9, focuses on the impact of the delay message anticipation on unused ATFM slots. It was indeed stressed that the overall proportion of missed ATFM slots is not negligible. And because the lack of anticipation was identified as a possible cause for unused ATFM slots, and because an ABCD-like tool could improve the anticipation of its users, a missed slot analysis was recommended in addition to the development of ABCD [2]. The goal is to demonstrate that improving delay message anticipation is beneficial to everybody, airspace users, as well as network management. In that sense, it would point to the virtues induced at central level by the local use of a distributed system like ABCD. The set of Work Packages is presented below: WP3: Cost Benefits Analysis. WP4: ABCD tool prototype definition. WP5: ABCD tool prototype development. WP6: Tool upgrade at CFMU level. WP7: Final ABCD Report. WP8: Simulation definition for the unused ATFM slots study. WP9: Simulation results analysis for the unused ATFM slots study. 10

11 Results of Work Package 3 have been recently presented in the deliverable D3, and the following conclusions were drawn: The total ATFM delay incurred by the airline would be lower if delays were notified earlier than today; There is increased value to earn when the level of traffic is high, because 1) more flights are regulated and are in a position to benefit from the use of ABCD and 2) more flights suffer from long ATFM delays, which are more sensitive to the anticipation parameter; The relationship between ATFM delay reduction and anticipation for one airline is nonlinear mainly because air transport is stochastic by essence and the slot allocation mechanism depends on a wide range of external parameters. As ATFM delays cannot be easily predicted, benefits cannot be accurately assessed: two cases were therefore analysed, including a worst-case assuming minimal gains, in order to be as conservative as possible in the Cost Benefit Analysis; In all cases, benefits outstrip costs over the product lifecycle, even in the most adverse situation due to 1) small amount of investment costs: ABCD is straightforward to develop, implement and operate and is a standalone product designed to have the minimum impact on the current environment and 2) ABCD yields substantial benefits because of the cumulative daily delay reduction effect over the year resulting from a continuous use of the tool. Therefore it can be stated with a strong degree of confidence that an ABCD tool is worth the investment. The unused ATFM slots study (WP8 and WP9) was carried out in parallel with the Cost Benefit Analysis, and the results were presented in the deliverables D8 and D9. TACOT simulations have particularly demonstrated the following points: Improving anticipation of the notification of delay messages by airlines could provide at central level (CFMU) reductions of 20% on the number of lost slots, reduction on the total daily ATFM delay up to 30% and decreases on the number of delayed flights by 15%. The recommendations drawn from the Analysis of Unused ATFM Slots ( the sooner, the better ) were therefore validated: the earlier the notification of delay messages to the CFMU, the lower the number of unused ATFM slots, the lower the overall ATFM delay, the better use of available ATM capacity while maintaining the same level of overloads. 11

12 1.3 Purpose and scope of the document The present deliverable (D4) is the result of WP4, intended to refine the description of the ABCD concept and to specify it, building on last year s achievements and taking into account the recommendations from IRAB. The specifications of the concept aim to drive the development of a prototype (WP5) that will pave the way for a local implementation of the concept at the level of a regional or low-cost airline. The objectives of the present document are as follows: Recall the essence of the concept, the stakeholders interested in it and how they could benefit from it; Scope the future system as well as its possible implementation from an airline perspective and define the environment interacting with the system: human actors, various systems, information flows etc.; Define the elementary services provided by the system; Define the requirements that the system will have to fulfil in order to provide these elementary services. 1.4 Document structure ABCD first deliverables [1], released in 2007, defined the principles of ABCD. The present deliverable (D4) intends to push further the concept definition. The document is structured in three parts: Section 2 presents the ABCD tool, from the concept to the tool implementation at airline level, and explains how ABCD could benefit the different ATM stakeholders. Section 3 describes the environment of the ABCD tool at airline level, focusing on the human actors and systems interfacing with ABCD, and then on the current messages and data that will be managed by ABCD. Section 4 specifies the ABCD concept, providing requirements that will pave the way for an ABCD prototype development. 12

13 2 ABCD CONCEPT 2.1 ABCD at a glance ABCD Concept The ABCD concept, which is based on the linkage of individual flight plans executed by a same aircraft, aims at using the flight planning and flight progress information available for a given flight in order to detect as soon as possible potential reactionary delay on the subsequent flights. More precisely, the concept relies on data known by the airlines themselves such as the aircraft schedule and the minimum turn-around time for each aircraft at each airport, as well as on the various messages exchanged between airlines and the CFMU. ABCD uses those data to monitor the propagation of a reactionary delay all along a given aircraft journey and check if the flights can comply or not with their current EOBT and possibly their ATFM slot. When a conflict with the current flight schedule is detected, ABCD proposes an update of the EOBT. The objectives underlying the concept are manifold: 1. Improve flight predictability and provide a better picture of operations in real time. 2. Better anticipate reactionary delays, since they can be detected earlier on the basis of the information available for the previous flight, and consequently: 3. Decrease the ATFM delay and optimize the efficiency of the ATFM slot allocation process, which enables to: 4. Lessen the delay propagation on the subsequent flights, i.e. reduce reactionary delays, and therefore better control the knock-on effects due to an initial delay From the concept to the tool implementation The ABCD concept can be implemented through several strategies: Centralised implementa i mplementation tion by the CFMU: The FPL linkage would be centralised within the CFMU database, which would be provided by airlines with aircraft allocation schedule, as well as minimum turnaround times. By processing those data, the CFMU would be able to update the downstream flight plans and to propose new EOBTs to airlines when delays would have been detected. The main advantage of this solution lies in the fact that the information is gathered in a unique central point. However, this strategy is constraining for the CFMU since 13

14 it would be necessary to modify its database management and processes. Furthermore, this solution raises juridical issues between CFMU and airlines (liability for EOBT changes, etc.) which could not be resolved in the scope of the present project. NOT RETAINED IN THE CURRENT SPECIFICATIONS Local implementation i by airlines: In that case, the linkage of flight plans would be performed in the airlines operations centres. Each airline would be proposed an ABCD tool that would monitor the delay propagation and calculate a new EOBT if the initial one is not reachable because of the occurrence of delays. Airlines would then communicate to the CFMU the new requested EOBTs through DLA messages. This second strategy, which appears as the most appropriate and simple solution to implement the ABCD concept, was the one retained to define the tool, given the juridical and practical complications induced by the centralised implementation. Furthermore, the requirements, albeit generic, are based on the premise that lowcost or regional airlines would be the main users of the tool since they already showed interest in the concept. RETAINED IN THE CURRENT SPECIFICATIONS ABCD tool at airline level The ABCD concept implementation therefore implies the design of an ABCD tool at local level, i.e. a tool that is hosted by airlines (especially low-cost and regional airlines) in the Airline Operations Centre. The ABCD tool is basically a support system to flight plan management aimed to assist the user (i.e. the aircraft operator in charge of flight planning) in the management of DLA messages. As an aid to decision-making, ABCD proposes to the user a new EOBT when the current EOBT of a flight can not be respected. Therefore, ABCD provides the user with information enabling him to make a decision on whether to notify delay messages or not to the CFMU. The tool can be regarded as a complementary system to the existing flight management system of the airline. ABCD will be used on the day of operation to reconcile flight planning and ongoing operations, through updated EOBT proposals. Thus from a one-flight perspective, it will be mostly used during the tactical/operational phase, from the time the flight plan is received and acknowledged by the CFMU till the time the flight is airborne. It will also be used during the active phase of the flight, to update the next flight plan on the aircraft schedule. Like any information management system, ABCD will: 14

15 1. Receive information The ABCD tool interfaces with the airline s existing systems (ABCD input), which provides ABCD with the messages exchanged between the airline and the CFMU, possibly third parties like aerodromes. Those messages are particularly useful to monitor the update of a flight plan and its execution. Other inputs of ABCD consist of the aircraft schedule, the aerodrome taxi-times and the minimum turn-around times. 2. Process information ABCD manages information thanks to an internal database which describes the linkage of flight plans. When a new message is received, ABCD extracts the relevant information from this message and correlates it to a flight in order to update the database. The system automatically checks if the subsequent flights are impacted or not by a possible delay of a flight, and if they can comply with their current EOBT and possibly their ATFM slot. 3. Provide information The ABCD tool interfaces with the operator in charge of the DLA message management and provides him with information that allows him to make a decision on whether to send delay messages (DLA) with the relevant contents (new EOBT proposal). This information is extracted from the database. 2.2 Stakeholders Even if the tool will be implemented at airline level, many ATM stakeholders in addition to the airlines may take advantage of the ABCD local implementation. The present section therefore intends to provide an overview of the various stakeholders potentially impacted by ABCD, and shows to what extent each one could benefit from the concept Airlines As private for-profit companies, airlines strive to satisfy their business objectives and optimize their operations by determining the optimum flight departure and arrival times as well as flights routes and levels. Therefore, a prerequisite to any airline operations consists in convenient take-off, landing and over-flight rights. This accounts for the importance given by airlines to slot allocation procedures. 15

16 Different kinds of airlines (flag carriers, low cost, charters) may have different priorities but in general, the ability to operate to published schedules punctually and efficiently is essential. These schedules involve a myriad of connecting and interdependent flights and events. The resources (aircraft and flight-crew) used for a particular flight form part of a continuous inter-connected process in which delay can have a serious and growing effect on subsequent flights. Most airlines place importance on punctuality since it directly contributes to the image of the company and can be a selection criterion for the passengers. Therefore airlines endeavour to decrease their delay. How will ABCD impact this stakeholder? The ABCD client airline, as the direct user of the tool, is the prime stakeholder in the concept. As ABCD enables optimizing the use of the available capacity, the delay incurred by the airline will be reduced. Moreover, as ABCD helps to control reactionary delays, improving the predictability of aircraft operations, it should contribute to: - A gain in ATFM delay due to a better anticipation of DLA messages. - A reduction in reactionary delay resulting from a lower ATFM delay incurred by the previous flight. - The reduction of strategic delay, which is the long-term effect of lower tactical delay, i.e. increased aircraft utilization. ABCD will therefore impact the cost effectiveness of airlines operations ATFCM Service Providers (CFMU) In this study, ATFCM providers encompass CFMU along with FMPs. ATFCM main objective is to contribute a safe, orderly and expeditious flow of air traffic by ensuring that ATC capacity is used optimally, and that the traffic volume is compatible with the capacities declared by the appropriate ATS authority. How will ABCD impact this stakeholder? ABCD would indirectly provide the CFMU with a better view of the traffic, and therefore improve traffic predictability. Indeed, with the implementation of the ABCD system, the slot allocation list could be updated earlier than with the current system. It should consequently impact on the capacity by decreasing the number of lost slots (i.e. slots that are allocated to an aircraft and that are eventually not used by this one, or by another one, while they could have been), which will result in less delay. ABCD will therefore impact on the predictability and efficiency of network operations. 16

17 2.2.3 ANSPs ATS Providers (incl. Airport Towers) ATC s main goals are to prevent collisions between aircraft and to expedite and maintain orderly flow of air traffic while maximizing the use of available capacity. How will ABCD impact this stakeholder? ATC will benefit at both local and network level. ABCD will provide a better picture of future traffic flows, improving its management through a better anticipation of the future ATFM regulations, and better slot management (reduction of unused ATFM slots). In the long term Air Traffic Control Centres will improve the balance between their resource allocation and their capacity regarding the traffic demand as a consequence of the increased confidence in the predictability of traffic flows. ABCD could therefore impact on the predictability of ATC operations Airport Ground handlers Airport encompasses the different partners at the airport responsible for the management of the airlines turn around activities (i.e. ground handlers). Each airline has agents (airlines staff or other staff ground handlers to which the tasks are subcontracted), at the airport responsible for the disembarkation and boarding of the passengers, baggage handling, refuelling, safety checks on aircraft, etc. These agents strive to manage their activities and to comply as much as possible with the scheduled flights program, the one sold to the clients. Punctuality is objective n 1 of the agents. In case of delays, the procedures to manage the delays could be different depending on the strategy of the airlines, but most of them share a common objective: come back to the scheduled flights program. This could imply flights cancel or aircraft s permutation strategies, if a delay implies a risk of significant propagation. How will ABCD impact this stakeholder? Ground Handler will be able to improve the use of their resources, saving costs and providing an improved level of service; Airport Operator will be able to improve service provision to their customers through better resource allocation as they could be informed a long time in advance of the future potential disruption in terms of flight plan schedule consistency. This applies both at the tactical level, through stability in gate/stand allocation, as well as at the strategic level, as better use of infrastructures supports greater passenger throughput. Airports should also be able to provide better information to their customers. Overall, the airport quality of service should be enhanced. 17

18 ABCD would improve the parking slot allocation process at the airports and would enable a better management of this process. ABCD could therefore impact on the predictability and efficiency of airport operations Passengers The passengers may be impacted by the flight planning process, even if they do know neither its existence nor its mechanism. This process creates indeed ATFM delays, and therefore contributes to degrade the airline punctuality. Owing to a weighty delay, passengers may complain to the company and demand a compensation for the delay. Even worse, the delay could impair the passenger s view on the airline and make him decide to change operator. How will ABCD impact this stakeholder? With the use of ABCD, customer satisfaction will increase as the hassle created by 1/ delays and 2/ the lack of information will be reduced (through 1/ lower ATFM delays 2/ the improved predictability of operations at the departure/destination airport). 18

19 3 ABCD ENVIRONMENT This section aims at depicting the environment in which ABCD will be implemented, and more precisely at presenting the human actors, the systems interfacing with the ABCD tool, as well as the operational data handled by the ABCD tool. 3.1 Human Actors First are described the human actors currently involved in the flight planning processes that will potentially interface with the ABCD tool Airline Operations Centre Staff The Airline Operations Centre (AOC) is basically the company s operational focal point for coordination and control of flights programme. Activities such as aircraft assignment, schedule, flight planning, ATFM slot management and flight tracking are usually performed in any AOC. However, the importance given to each activity depends on the size and type of company (major/ low-cost). For instance, flight tracking may be reduced to the monitoring of the aircraft actual take-off times. Furthermore, the number of people in charge of those tasks may completely differ from an airline to another one: in major airlines there are units specific to each activity, whereas in smaller companies only one or two persons can be responsible for several tasks. ABCD as an aid to decision-making for flight plan update will provide information to the person(s) managing flight plans, who usually notifies delays, cancels flights, etc. This or these person(s) will be designated by AOC staff in the rest of the document. What is their role regarding ABCD? The AOC staff is the system user. The incumbent staff will directly interface with ABCD. On the one hand, ABCD will warn the user and display the relevant information when a delay is detected. On the other hand, ABCD will warn the user in case of missing data in the airline database (in particular data related to the minimum turn-around time, taxi-time and to the aircraft schedule). 19

20 3.2 System actors This section describes the systems that interface with ABCD (directly or indirectly) Flight Management System The AOC system responsible for the messages exchange with the CFMU is designated by Flight Management system as it can be very different from an airline operator to another one, especially between major airlines and low-cost carriers. Since ABCD will interest mainly budget or regional airlines, the intended system corresponds to the ones of these types of airlines. Low-cost, budget, no-frills airlines have generally a very light Flight Management System. As an example: - Ryanair notifies delays to the CFMU as soon as possible, using only DEP messages sent by the departure airport. - Euro Air uses the MVT message sent by the handling company to the airport to track its flights. They wait till EOBT+10 before sending DLA message. What is its role regarding ABCD? This system will act on the one hand as message transmitter ter for ABCD, and on the other hand as data provider (in particular ABCD will be provided with the aircraft allocation schedule, taxi-time and the minimum turn-around time stored in the airline system database). Therefore, the airline s current system will only play a role of proxy vis-à-vis ABCD: it will forward to the tool all the messages it has already received from third parties or exchanged internally, and will also provide data contained in its own database CFMU Systems The role of the EUROCONTROL Central Flow Management Unit (CFMU) is to ensure safety and efficiency of all flights by facilitating the management of the network. The Central Flow Management Unit primarily provides three operational services: - Airspace Data Management; 20

21 - Flight Plan Processing Service, provided by the Integrated Initial Flight Plan Processing System (IFPS); - Air Traffic Flow and Capacity Management (ATFCM), whose tool is the CFMU Enhanced Tactical Flow Management System (ETFMS) IFPS and ETFMS are described below since they exchange messages with the airline, and therefore play indirectly a role in ABCD implementation. IFPS - Integrated Initial Flight Plan Processing System The IFPS provides a centralized flight plan processing and distribution service for all IFR GAT flights within the CFMU area. This system ensures that accurate and consistent flight plan data are available to all concerned ATSUs and the centralized ATFCM function. Description of IFPS: Flight plans (repetitive or singly filed) and associated messages are received by the IFPS. These messages are checked against a substantial number of static syntactical and semantic requirements, and the dynamic airspace infrastructure. When necessary, flight plan messages are submitted for manual processing by IFPS operators. Flight plan message originators are advised of the status of their messages via operational reply messages. Processed flight plan messages are subsequently distributed to the concerned ATS units and to ETFMS. ETFMS - CFMU Enhanced Tactical Flow Management System The main tool for ATFCM is ETFMS, a system used by the OPSD and FMPs for Tactical operations. ETFMS receives data from IFPS, ATC, airline, CDM Airports and the ENV Systems. Its main missions are the Slot allocation and aircraft rerouting. Description of ETFMS: The Tactical system (ETFMS) contains flight data for the following forty-eight hours. Initially, it is fed with RPL for that period and later with Flight Plan Messages in order to present the best picture of air traffic demand. This data is later updated by ATC information on the actual flight situation or any change to the initial flight plan (e.g. new route). The tools for exploiting this data allow examination of the anticipated air traffic demand for the following day. Aircraft Operators (AOs) and Flow Management Positions (FMPs) can access the database via a terminal. 21

22 The ETFMS System has the following sub-functions (Figure 1): a) Environment Data Capture and Processing All the basic elements of the ATC environment such as airports, routes, sectors, capacities are known to the ETFMS and sometimes dynamic updates (e.g. runway configuration). b) Flight Data Capture Merging of long-term data provided by RPL and up-to-date information provided by IFPS or by CDM Airports. c) Profile Calculation For each flight a 4D profile is calculated, taking into account the above 2 sets of information. d) Load Calculation At any point, aerodrome, set of aerodromes, airspace volume or traffic volume. This is expressed as a number of flights per unit of time (usually one hour) entering an airspace volume, overflying a point, departing from/arriving at an aerodrome/set of aerodromes or part of a traffic volume or of one of its flows. e) Rerouting Certain facilities exist in the ETFMS (system to simulate the consequences for the ATFCM/ATC system of rerouting individual flights or groups of flights. The impact on loads in affected areas is consequently re-calculated. f) Human Machine Interface For the display and input of information used or generated by flow managers, ATC controllers, Aircraft Operators and pilots, i.e. an important part of the ETFMS system concerns the input and display of the various data previously mentioned (flight data loads at sectors, overload warnings, etc., ). This also includes command displays, by means of which the flow manager activates the ATFCM measures (e.g. CASA - restrictions and rerouting) and monitoring facilities. g) The Exchange of Messages This is an important part of the ETFMS system involving complex address selection and message routing mechanisms. h) The Computer Assisted Slot Allocation (CASA) The algorithm is at the very heart of the interaction between the ETFMS system and ATC. Traffic volumes to come under CASA control are activated by the flow manager. This means that he defines a traffic volume, start time, end time and many other parameters. ETFMS then extracts all flights which are concerned by this activation, in other words those flying at that location (within that flight level slice) 22

23 during that restricted period and passes them onto the "CASA algorithm" for departure time calculation. Figure 1; ETFMS functions The CASA System is largely automatic and centralised, and functions from an Aircraft Operator s point of view in passive mode. In other words, the act of filing a flight plan effectively constitutes a request for a slot. FMPs and CFMU agree on those locations where ATFCM Measures are necessary. As a consequence the CFMU activates regulations within ETFMS including the start and the end times, the description of the location, the entering flow rate and some other parameters. The system extracts all the flights entering for the specified airspace and sequences them in the order they would have arrived at the airspace in the absence of any restriction. On this basis, the Take-Off Time (TOT) for the flight is calculated. It is this information, Calculated Take-Off Time (CTOT), which is transmitted to the Aircraft Operator concerned and to the control tower at the aerodrome of departure. In addition to this fundamental process, a number of other mechanisms will act to compensate for factors such as late received flight plans and modifications thereto. What is their role regarding ABCD CD? ABCD and the CFMU will not interface directly, but to some extent indirectly through the airline s other systems. On the one hand, some messages sent by the IFPS (ACK) and the ETFMS (SAM, SRM ) will be used by ABCD. On the other 23

24 hand, in case of delay, the EOBT calculated by ABCD will be notified to the CFMU through the airline operation centre. 3.3 Messages & Data In the previous sections, the different actors (human and system) interfacing with ABCD were described. Those actors, especially the airline flight plan management system, will transmit ABCD messages containing elementary data necessary to the tool. The present section therefore focuses on the different messages and associated data that ABCD will have to handle, and also presents the current operational context associated to the use of those messages. The other data used by ABCD but not conveyed via messages are also described in the last part of the section Types of messages managed by ABCD There are basically three kinds of messages that ABCD will have to manage. Those messages are exchanged between the airline, the CFMU and possibly third parties: - Flight Planning messages (FPL, RPL, ACK,, DLA, CHG, CNL, REA): to file or update a flight plan and have the initial flight plan validated by IFPS; - ATFM messages (SAM, SRM,, SLC): to notify the ATFM measures a flight is subject to (if any) and update them whenever necessary; - Flight Progress messages (DEP, ARR, FUM): to update the interested parties on the progress of an active flight Elementary data associated to messages Those messages exchanged by the airline with the CFMU and third parties contain a certain number of elementary data, which will feed the database handled by ABCD: Flight ARCID: Identification of a flight. This data is composed of 3 letters which characterize the airline (ICAO designator), plus at most 4 figures. ARCTYP: ICAO designator for the aircraft type EOBT (Estimated Off-Block Time): Estimated time at which an aircraft starts to move from its parking stand. This information is related with departure. 24

25 ADEP (Aerodrome of Departure): ICAO designator for the aerodrome of departure ADES (Aerodrome of Destination): ICAO designator for aerodrome of destination CTOT (Calculated Take-Off Time): Time at which an aircraft is allowed to take-off in case of the issuance of a regulation. This information is sent to an airline via a SAM (or SRM) at the earliest two hours before EOBT. airline/atc are responsible for complying with it. TTLEET (Total Estimated Elapsed Time): Estimated duration of a flight ELDT (Estimated Landing Time): Estimated time at which an aircraft is supposed to land. This information is contained in the FUM messages whose purpose is to provide interested parties (mainly the ADES, possibly the airline) with an estimated landing time Current operational context associated to messages Each type of messages can be correlated to a number of operational events that will trigger the update of the ABCD database: Flight Planning messages Event n 1: RPL submission (EOBT-20h): The flight RPL, if it exists, is automatically converted into a FPL. Why is it a milestone for ABCD? The flight becomes visible to ABCD. Event n 2: FPL submission (Before EOBT-3h): The flight FPL is sent by the airline to the CFMU (if there is no RPL associated to the flight). Why is it a milestone for ABCD? The flight becomes visible to ABCD. Event n 3: FPL validation (ACK( message sent after an FPL): The FPL is accepted by the CFMU. Why is it a milestone for ABCD? The flight is inserted into the ABCD database. 25

26 Event n 4: EOBT update (After ( an FPL): The EOBT can be updated thanks to DLA or CHG messages (to notify a delay), or else thanks to REA (when a regulated flight is ready to leave before its CTOT). Why is it a milestone for ABCD? The ABCD database takes into account any change in the EOBT in order to check if it impacts or not on the following flights. Event n 5: Flight cancellation (After an FPL): A flight plan can be cancelled thanks to a CNL message. Why is it a milestone for ABCD? The flight is removed from the ABCD database. ATFM messages Event n 6: Slot allocation SAM (EOBT-2h): From that time on, a flight is allocated a slot as soon as it is regulated by ATFM measures Why is it a milestone for ABCD? The CTOT, when it exists, is taken into account by the tool to check that the aircraft can make its slot. Event n 7: Slot revision SRM (between EOBT-2h and CTOT min (TRS; TIS) 1 taxi-time time): The ATFM slot may be changed at any time: it can be as well improved as downgraded. Why is it a milestone for ABCD? If the slot improvement is significant, it may happen that an aircraft is no longer in a position to comply with it (due to the reactionary delay predicted by ABCD), whereas it could adhere to it before revision. Slot revisions are therefore constantly monitored by the tool. Event n 8: Slot frozen (CTOT- min (TRS; TIS) taxi-time time): From that time on, the slot of the flight is frozen and cannot be changed anymore (neither improved, nor downgraded). Why is it a milestone for ABCD? At that time, the predictions made by ABCD regarding the potential reactionary delay of the following flight will become more accurate and more stable. Therefore an EOBT proposed by the tool is more likely to remain valid. The timeliness and trustworthiness of the proposals submitted by the tool are important for the sake of 1 Cf. definition of TRS and TIS in section

27 users acceptability. They are taken into account in the specifications, when defining the preconditions triggering EOBT proposals. Flight Progress messages Event n 7: Flight execution (From( take-off off): From that time on, the flight, regulated or not, is active in ETFMS, which then receives (and sends) flight progress messages to monitor the flight execution. Why is it a milestone for ABCD? The planning phase is over. Nevertheless the monitoring task will remain active until flight termination and flight progress messages received by the CFMU (e.g. FUM) or by third parties (e.g. DEP) will be used by the tool to make a better prediction for the reactionary delay of the following flight. Event n 8: Flight termination (ARR message). The flight is over. Why is it a milestone for ABCD? The flight will be removed from the ABCD database Messages description Table 1 summarizes the set of messages that could be managed by ABCD and provides for each one: the type of message, the sender, the recipient, the event triggering the message, the message purpose, the information that will be extracted by ABCD, its impact on the ABCD database, and miscellaneous comments. More information may be found in [3] for flight planning messages, [4] for ATFM messages and [5] for flight progress messages. Detailed information about the format (ADEXP format) and the message structure are annexed to the document (cf. Annex 1) 27

28 Title Type of message Sent by Sent to Triggering event Role Extracted Information Impact on ABCD database Miscellaneous FPL Flight planning airline CFMU Submit a Flight Plan to the CFMU A/C ARCID, TTLEET, EOBT Followed by ACK man or REJ ACK RPL DLA CHG Flight planning Flight planning Flight planning Flight planning CFMU airline Validation of a FPL by the CFMU Acceptance of a Flight Plan A/C ARCID airline CFMU airline airline CFMU CFMU A flight will not be able to meet its previous EOBT A flight wants to change its flight path Submit Flight plans for a series of flights which have identical features Notify a delay to the CFMU Notify any change compared to the flight plan Not directly managed by ABCD A/C ARCID, EOBT A/C ARCID, EOBT, TTLEET Insertion of the flight in database Change the EOBT Change the EOBT The airlines should wait for it before sending any other messages Converted into FPL 20 hours before EOBT - New EOBT > Previous EOBT - New EOBT > msg timestamp - New EOBT no more than 20 hours in the future. CNL Flight planning airline CFMU Cancel a flight Remove a flight REA Flight planning airline via ATC CFMU Notify to the CFMU that a regulated flight is ready to leave A/C ARCID, timestamp Change the EOBT Is not directly sent by the airline, which has to ask local ATC SAM ATFM CFMU airline Assign a slot to a regulated aircraft A/C ARCID, CTOT Change the CTOT airline gets a slot at the earliest 2 hours before EOBT SRM ATFM CFMU airline The slot of an aircraft has been improved by more than 5 minutes Assign a slot to a regulated aircraft A/C ARCID, NEWCTOT Change the CTOT SLC ATFM CFMU airline Change of regulation parameters, When a slot is missed, After a CNL (cancelled reg) Slot no longer subject to ATFM measures A/C ARCID Remove the CTOT FLS ATFM CFMU airline Often after a SMM (Slot Missed Message) Suspend a flight till DLA/CHG A/C ARCID CTOT/EOBT = +infinite? FUM Flight progress CFMU ADES, (Airlines) - Modification of ELDT > 5 min - Change of the flight status Give an estimation of the landing time ELDT Change the ELDT Is sent at the earliest 3 hours before landing time DEP Flight progress ADEP CFMU Take-off Activates the flight plan TO time Change the ELDT May not be used by ABCD (sent to the CFMU) ARR Flight progress ADES CFMU On landing Allows the flight plan to be closed Landing time Change the ELDT May not be used by ABCD (sent to the CFMU) Table 1: : Messages potentially handled by ABCD (depending on current airline message interchange) 28

29 3.3.5 Other data managed by ABCD ABCD will also rely on two other information types which are not part of the standard messages, but nevertheless valuable for ABCD database update. Those data are described below: ARN (Aircraft Registration Number): Unique alphanumeric string that identifies an aircraft This data will be used to link flight plans together. Taxi Time: Average time an aircraft is supposed to taxi from its parking stand to the runway. This information is contained in the CFMU environment database which defines a standard value for each airport, ranging from 0 to 20min. Taxi times are part of ATFM messages such as SAM or SRM but are not part of Flight Planning Messages such as FPL. This is why taxi times are regarded as other data. TTM (Minimum Turn Around Time) (for a given airport and a given type of aircraft): Minimal time needed by the aircraft to complete turn-around operations at the airport. It includes activities such as refuelling, baggage handling, boarding and deplaning of passengers, etc. The TTM is a time window between the in-block time of a flight N-1 and the off-block time of a flight N. Depending on the aircraft type, the TTM may vary from 20 minutes (case of narrowbodies) to up to one hour and a half (case of widebodies). For example, when the aircraft is of the Heavy type (e.g. Boeing 747), the airlines have to define a TTM of more than one hour. This data will be used to calculate the minimum time at which an aircraft is able to leave its block. TRS (Time to Remove from the Sequence) and TIS (Time to Insert into the Sequence): Those parameters can be defined for each aerodrome, with a default value of 5min for the TRS and 10min for the TIS. They are used by the CFMU as timeout values to freeze the slot allocation for an a/c close to depart, hence prevent a late change of CTOT and achieve stability. The Time to Remove from the Sequence (TRS) prevents a change to a later CTOT when the flight is already in the departure sequence. 29

30 The Time to Insert into the Sequence (TIS) prevents an improvement into an already organised departure sequence. Those data will be used as criteria of stability in the ABCD system in order to provide to the user with accurate information. Figure 2 gives the general view of the ABCD environment: AIRLINE ABCD Assistance in DLA management Provision of messages and data AOC Staff Monitoring of flight Planning & Execution Flight Management System CFMU : - IFPS - ETFMS Message Exchange Figure 2: : The ABCD environment 30

31 4 ABCD REQUIREMENTS 4.1 Foreword This section addresses the requirements of the ABCD tool at three different levels: - Requirements linked to the human actors; - Requirements linked to the system actors; - Requirements internal to the ABCD tool. Requirements are of three types: - Operational services, defining the services that ABCD shall provide to the user; - Functional requirements, defining what ABCD shall do in order to provide those services. They define the functions and sub-functions that shall be implemented in order to achieve the goals of the operational services; - Non-functional requirements, defining how ABCD should fulfil the functional requirements. Each requirement is assigned an identifier which consists of a designator providing information on the type and features of the requirement, plus a reference number. The designator is a string made of the following abbreviations: - Fn refers to a functional requirement - Non_Fn refers to a Non-Functional requirement - User_If refers to a requirement related to the User Interface - Syst_If refers to a requirement related to the System Interface - Int refers to an internal requirement - Trig refers to a requirement triggered by an event (e.g. another requirement) - Cont to refer to a requirement continuously performed by ABCD Some requirements are dependent upon others (for instance a function may be triggered by or trigger another function). The dependencies related to each requirement are identified after the requirement definition. A list of functional/non-functional requirements as well as a matrix of dependencies may be found in annex Requirements related to Human Actors Operational Services ABCD can be regarded as a basic decision-making support system aiming at the optimization of flight planning management. This system: Accesses all the flight planning and flight progress information available to the airline; Processes the relevant information; 31