The European Organisation for Civil Aviation Equipment
L’Organisation Européenne pour l’Equipement de l’Aviation Civile
Airport-CDM
Interface Specification
Version 0.99
ED-145
Month Year
102 rue Etienne Dolet
92240 MALAKOFF, France
Web Site : www.eurocae.org
Tel : 33 1 40 92 79 30
Fax : 33 1 46 55 62 65
Email : eurocae@eurocae.net
Airport-CDM
Interface Specification
Version 0.99
Date
Issue Changed Items/Chapters
Comment
2 Oct 2006
0.1
First sketch of document - all
All new
New introduction
29 Jan 2007
0.2
21 Mar 2007
0.3
2.3.1. and 2.3.8
More on milestone 1, included milestone 8
27 Aug 2007
0.4
Section 2.3
All milestones included in structured description
5 Oct 2007
0.5
Chapter 5
Tidied up document throughout
alignment to interfaces matrix
New chapter 2
New milestones approach
and
bean
Edits made during WG69 meeting 15
3 Dec 2007
0.6
All
Chapter 1 simplified and aligned to ED-141
Chapter 3 aligned to Interfaces matrix and
duplicate data/messages deleted
21 Jan 2008
0.7
All
Rework of all chapters and restructure based on
interfaces not milestones. Added data model
chapter.
20th Feb 2008
0.8
All
Updates discussed at January meeting
19 March 2008 0.96
All
Updates discussed at March meeting
8 April 2008
All
Final details. Consistency with ED-141 and ED146.
0.99
ED-145
Month Year
102 rue Etienne Dolet
92240 MALAKOFF, France
Web Site : www.eurocae.org
Tel : 33 1 40 92 79 30
Fax : 33 1 46 55 62 65
Email : eurocae@eurocae.net
3
FOREWORD
1.
The document ED-145 Airport-CDM Interface Specification was prepared by
EUROCAE Working Group 69 and was accepted by the Council of EUROCAE
on “Month Year”.
2.
EUROCAE is an international non-profit making organisation. Membership is
open to manufacturers and users in Europe of equipment for aeronautics, trade
associations, national civil aviation administrations and non-European
organisations. Its work programme is principally directed to the preparation of
performance specifications and guidance documents for civil aviation
equipment, for adoption and use at European and world-wide levels.
3.
The findings of EUROCAE are resolved after discussion among its members
and, where appropriate, in collaboration with RTCA Inc, Washington D.C. USA
and/or the Society of Automotive Engineers (SAE), Warrendale, PA, USA
through their appropriate committee.
4.
The document represents “CDM Interface Specification - EUROCAE Standard
for Airport-CDM-Interface”.
5.
EUROCAE performance specifications are recommendations only. EUROCAE
is not an official body of the European governments; its recommendations are
valid statements of official policy only when adopted by a particular government
or conference of governments.
6.
Copies of this document may be obtained from:
EUROCAE
102 rue Etienne Dolet
92240 MALAKOFF
France
Tel: 33 1 40 92 79 30
Fax: 33 1 46 55 62 65
Email: eurocae@eurocae.net
Web Site: www.eurocae.org
V0.99
© EUROCAE, 2008
PAGE 3 OF 39
4
TABLE OF CONTENTS
CHAPTER 1
Introduction .............................................................................................................................5
1.1 Introduction ............................................................................................................................................ 5
1.2 Airport CDM Documents ........................................................................................................................ 5
1.3 Purpose and Scope ............................................................................................................................... 6
1.4 Terminology ........................................................................................................................................... 8
1.5 Glossary of defined terms ...................................................................................................................... 8
1.6 Abbreviations ......................................................................................................................................... 8
1.7 Applicable Documents ........................................................................................................................... 8
1.8 Reference Documents ........................................................................................................................... 9
CHAPTER 2
Data exchange with Logical elements ..................................................................................10
2.1 Introduction .......................................................................................................................................... 10
2.2 General Interface Requirements ......................................................................................................... 11
CHAPTER 3
Data Model ...........................................................................................................................12
3.1 Introduction .......................................................................................................................................... 12
3.2 General Requirements on Data Transmission .................................................................................... 13
3.3 Requirements on Compound TYPE: Event_Time ............................................................................... 14
3.4 Requirements on Compound TYPE: Event_Date ............................................................................... 17
3.5 Requirements on Compound TYPE: Event_Duration ......................................................................... 18
3.6 Requirements on Compound TYPE: Airport_Resource ...................................................................... 19
3.7 Requirements on Compound TYPE: Alert ........................................................................................... 20
3.8 Requirements on Compound TYPE: Other_Flight_Information .......................................................... 22
3.9 Requirements on Compound TYPE: CFMU_Message ....................................................................... 25
Annex A Example of Data Exchange between Logical Elements and the Airport-CDM System ....................26
Annex B Airport CDM Definitions .....................................................................................................................28
Annex C List of Acronyms ................................................................................................................................31
Annex D SuB group participants ......................................................................................................................38
List of Figures
Figure 1: Airport-CDM Documents ..................................................................................................................... 6
Figure 2: Logical Elements ................................................................................................................................. 7
List of Tables
Table 1: Milestones .......................................................................................................................................... 11
Table 2: Event_Time Data Items ...................................................................................................................... 14
Table 3: Event_Date Data Items ...................................................................................................................... 17
Table 4: Event_Duration Data Items ................................................................................................................ 18
Table 5: Airport_Resource Data Items ............................................................................................................. 19
Table 6: Alert Data Items .................................................................................................................................. 20
Table 7: Other_Flight_Inofrmation Data Items ................................................................................................. 22
Table 8: CFMU_Message Data Items .............................................................................................................. 25
Table 9: Data Exchange Example .................................................................................................................... 27
V0.99
© EUROCAE, 2008
PAGE 4 OF 39
5
CHAPTER 1
INTRODUCTION
1.1
INTRODUCTION
Airport Collaborative Decision Making (CDM) is an important enabler of Air Traffic
Management (ATM) capacity and efficiency. The concept of Airport CDM does not
imply any particular system or architecture. Rather, it is an approach to using
aeronautical data, based on sharing data between all Partners, ensuring a common
view of the ATM and airport environment on all levels. Airport CDM also addresses the
need for operational decisions to be made collaboratively thus providing a substantial
contribution to maximising capacity and efficiency.
Although Airport CDM is applicable to all phases of flight, the Airport CDM concept has
seen its first prototypes and trials at airports and this document is therefore dedicated
to Airport CDM. An Airport CDM Task Force was created under the EATM Airport
Throughput Business Division (APT) of EUROCONTROL, and documents created by
this Task Force have contributed significantly to the development of this document.
Airport Collaborative Decision Making is about improving the way operational Partners
at airports and the European ATM network work together at an operational level.
Airport CDM allows an Airport CDM Partner to make the right decisions in collaboration
with other Airport CDM Partners, knowing their preferences and constraints and the
actual and predicted situation. The decision making by the Airport CDM Partners is
totally dependent upon the sharing of accurate and timely information and upon
adapted Airport CDM procedures, mechanisms and tools.
While the implementation of the Airport CDM concept requires first and foremost a
change in culture regarding the way that data is used and decisions are made, it
nevertheless requires that the Airport CDM Partners 1 possess certain capabilities or
systems that enable them to share data and make and implement decisions
collaboratively.
The EUROCONTROL: Airport CDM Implementation Manual [doc ref. [3]] points out
that…”To enable the operational use of Airport CDM, Partners’ existing systems will
have to be adapted at least to a level where they can seamlessly communicate with
each other”.
1.2
AIRPORT CDM DOCUMENTS
Much of the key development work in the Airport CDM field has been conducted by
EUROCONTROL and in particular the EUROCONTROL Airport CDM Task Force. This
document therefore builds upon the key outputs of the Task Force, namely the
EUROCONTROL: Airport CDM Operational Concept Document [doc ref. [1]], the
EUROCONTROL: Airport CDM Functional Requirements Document [doc ref. [2]] and
the EUROCONTROL: Airport CDM Implementation Manual [doc ref. [3]], to derive this
set of EUROCAE standards (comprising this document, ED-145 and ED-146).
The principle input to this work is the EUROCONTROL: Airport CDM Functional
Requirements Document [doc ref. [2]], which has continued to develop in parallel with
this document, the former identifying functionalities and the latter identifying technical
means of achieving these functionalities.
1
V0.99
For terms definition please refer to section Ошибка! Источник ссылки не найден. Ошибка!
Источник ссылки не найден.. Airport CDM Partner is defined in Appendix A.
© EUROCAE, 2008
PAGE 5 OF 39
6
The first document of the EUROCAE Airport CDM set is the Minimum Specifications
for Airport CDM systems (ED-141).
The second document of the EUROCAE Airport CDM set is the Airport CDM Interface
Specification (ED-145). It describes the minimum requirements on the data exchanged
with an Airport CDM system.
The final document of the EUROCAE Airport CDM set is the Test and Validation
Document (ED-146) that provides a basis from which an Airport CDM implementer
can develop testing specifications to ensure his/her installation is compliant with ED141 and ED-145.
The relationship between the relevant documents described above is captured in the
figure below.
EUROCONTROL
Documents
EUROCAE
Documents
Operational Concept
Document
System Requirements
Document (ED-141)
Functional
Requirements
Document
Interface Definition
Document (ED-145)
Implementation
Manual
Test and Validation
Document (ED-146)
FIGURE 1: AIRPORT-CDM DOCUMENTS
1.3
PURPOSE, SCOPE, APPLICABILITY
This document sets minimum requirements on the data exchanged between an Airport
CDM system, which is regarded hereon as a single system, and the logical elements
that provide information to the system. These logical elements are denoted by the
figure below.
V0.99
© EUROCAE, 2008
PAGE 6 OF 39
7
Aircraft
Operations
Airport
Operations
ATFCM
Airport
CDM
Ground
Handling
ATC
De-icing
Operations
FIGURE 2: LOGICAL ELEMENTS
The intended audience includes developers of generic Airport-CDM systems (industry)
and developers of specific implementations for Airport-CDM at airports: designers,
installers, manufacturers, service providers, and users. This document assumes
knowledge of Airport CDM.
This document describes the minimum requirements on the exchanged data to
provide the basis for interoperability and compatibility between different
implementations of Airport CDM systems.
Wherever possible this document supports freedom of design and therefore only sets
requirements where considered necessary for reasons of interoperability. For example
interfaces between elements within the Airport-CDM system itself and who has the
responsibility for sending the data are considered beyond the scope of this document
as they may differ from one implementation to another whilst still enabling the
overarching requirement that logical elements be able to connect to the Airport-CDM
system in a consistent manner.
It is expected that this document will be used as a basis for developing a more
detailed interface design specification (such as an interface control document) that
can be applied at a local level for a specific implementation.
Chapter 1, this chapter, presents an overview of Airport CDM, the document set
relating to the subject and the purpose and scope of this document. The remainder of
this chapter is dedicated to the terminology, terms, conventions, and references used.
Chapter 2, data exchange with logical elements, introduces the logical elements to the
Airport-CDM system and introduces the milestones approach. The chapter concludes
with the identification of interfaces per partner and milestone.
Chapter 3, data model, describes the interfaces by name and their format. For this, a
generic description method is used, that is compliant with the existing data exchange
presentation ADEXP [6] but can also easily be transformed to XML.
Annex A contains a matrix with all Airport-CDM Data Items referenced to its type, the
recommended sender, and the CDM milestone where the data item could occur.
Requirements in this document are denoted by a unique number and preceded by
“IR.” to represent the fact that they are Interface Requirements. The following section
denotes the strength of each requirement used.
V0.99
© EUROCAE, 2008
PAGE 7 OF 39
8
1.4
TERMINOLOGY
When used in this document, the following words have the meaning specified
hereunder:
Shall – Denotes a mandatory requirement that must be met in order to comply with
this standard.
Should – means that this requirement constitutes good practice and is therefore
recommended but is not necessary for compliance with this standard.
Note – Denotes explanatory text that supports the requirement to which it belongs but
is not part of the requirement.
Abbreviations – Abbreviations and acronyms used in this document have the
meaning specified in the glossary of defined terms in section 1.5.
Annex – Annexes contain text supporting this document but are not considered to be
part of the requirements necessary to claim compliance with it.
Figures and Diagrams – Figures and diagrams in this document are used to illustrate
a concept and/or relationships and data flows. In NO case do they imply a particular
architecture or implementation solution.
1.5
GLOSSARY OF DEFINED TERMS
1.5.1
Airport CDM Definitions
Please refer to 0.
1.5.2
General Definitions
For general definitions, please refer to EATM glossary of terms
http://www.eurocontrol.int/eatm/gallery/content/public/library/terms.pdf).
1.6
ABBREVIATIONS
1.6.1
Airport CDM Abbreviations
(See
Please refer to 0.
1.6.2
General Abbreviations
For general abbreviations, please refer to EATM glossary of acronyms and
abbreviations
(See
http://www.eurocontrol.int/eatm/gallery/content/public/library/acronyms.pdf).
1.7
APPLICABLE DOCUMENTS
[1]
EUROCONTROL: Airport CDM Operational Concept Document, Final Edition, October
2005.
[2]
EUROCONTROL: Airport CDM Functional Requirements Document, Final Edition ,
October 2005 – Note: A new version will be available by the time this document is
released.
[3]
EUROCONTROL: Airport CDM Implementation Manual – Note: A new version will be
available by the time this document is released.
V0.99
© EUROCAE, 2008
PAGE 8 OF 39
9
1.8
REFERENCE DOCUMENTS
[4]
EUROCONTROL: CFMU Flight Progress Messages V1.5, 31 Jan 2008, Hans Koolen,
Ref.: URB/USD/MSG_INTF. (Note that this document is being updated on a regular
basis)
[5]
DPI summary document, V1.2, CFMU, June 2006.
[6]
EUROCONTROL, ATS Data Exchange Presentation (ADEXP), Edition 3.1
[7]
Safety Assessment of Airport Collaborative Decision Making (Airport-CDM), V1.2,
December 2006
[8]
EUROCONTROL Experimental Centre, Munich AIRPORT CDM, EEC Note No. 03/06,
February 2006
[9]
ICAO DOC7910 - ICAO Location Indicator
[10]
ICAO DOC8585 - ICAO Designator for Aircraft Operation Agencies and Aeronautical Authorities
and Services
[11]
ICAO DOC8643 - ICAO Aircraft Type Designator
V0.99
© EUROCAE, 2008
PAGE 9 OF 39
10
CHAPTER 2
DATA EXCHANGE WITH LOGICAL ELEMENTS
2.1
INTRODUCTION
This chapter describes the external interfaces of the Airport-CDM system i.e. between
the Airport-CDM system and the six logical elements. Internal interfaces are not
considered further as it should be a design decision for each implementation. The
reason for standardising the external interfaces is to enable the logical elements to
connect to any airport CDM system without having to tailor their communications links
to each implementation.
As this document is specifying only the minimum requirements for Airport-CDM
interfaces, no specific implementation is assumed and it is therefore not appropriate to
standardise from which logical element data should be provided because each airport
is different and it will be a local decision which logical element is best placed to
provide information.
The format and requirements on how the information is exchanged can be found in
chapter 3, whilst this chapter primarily deals with who the Airport-CDM system must
connect to and what, if any, requirements apply to that interface connection. This
chapter therefore sets few requirements.
Annex A does however provide and example of data exchange including the
recommended sender and receivers of data.
2.1.1
Milestones
Airport CDM commonly considers a flight in terms of a series of sequential events that
mark key ‘Milestones’ in the aircraft turnaround process. Specifically the Milestones:

Facilitate an improvement in the awareness of all airport partners.

Trigger updates of downstream information.

Help identify potential delays of the aircraft, triggering re-planning.

Enable collaborative decisions to be made.
This Airport-CDM document, as with the rest of the Airport-CDM document set (see
section 1.2), reflects 16 milestones in the Airport-CDM process, which are presented
in the table below.
Other Milestones may be added according to particular needs and local
circumstances, however the remainder of this document assumes a 16 stage process.
V0.99
© EUROCAE, 2008
PAGE 10 OF 39
11
NUMBER
MILESTONE
MST1
ATC Flight Plan Activation
MST2
EOBT-2 hr
MST3
Take off from outstation
MST4
Local Radar Update
MST5
Final approach
MST6
Landing
MST7
In-block
MST8
Ground handling starts
MST9
TOBT update prior to TSAT issue
MST10
TSAT Issue
MST11
Boarding starts
MST12
Aircraft ready
MST13
Start up request
MST14
Start up approved
MST15
Off-block
MST16
Take Off
TABLE 1: MILESTONES
2.2
GENERAL INTERFACE REQUIREMENTS
[ED145-01]
The appropriate logical element from/to which data is received/sent shall be
determined locally.
[ED145-02]
The Airport-CDM system shall be able to communicate with the Aircraft Operations
logical element.
[ED145-03]
The Airport-CDM system shall be able to communicate with the Airport Operation
logical element.
[ED145-04]
The Airport-CDM system shall be able to communicate with the Ground Handling
logical element.
[ED145-05]
The Airport-CDM system shall be able to communicate with the De-icing Operations
logical element.
[ED145-06]
The Airport-CDM system shall be able to communicate with the ATC logical element.
[ED145-07]
element.
The Airport-CDM system shall be able to communicate with the ATFCM logical
V0.99
© EUROCAE, 2008
PAGE 11 OF 39
12
CHAPTER 3
DATA MODEL
3.1
INTRODUCTION
This chapter describes the detailed data exchange model for the minimum set of Data
Items required by the Airport-CDM system.
3.1.1
Terms and notation used in this chapter
Data Items: The term ‘Data Item’ has been used in this document to refer to any one
of the broad range of variables that are set by or provided to the Airport-CDM system.
Examples of Data Items are Aircraft Type, Aircraft Registration, and any schedule
time.
Data Item Identifier (DataID): Each Data Item has a Data Item IDentifier (DataID)
which is required to maintain consistency amongst each implementation in which a
Data Item is implemented. This identifier is a short abbreviation, consistent with
ADEXP where applicable, to enable quick identification of a Data Item that can be
recognised at any Airport-CDM implementation.
3.1.2
Data description
Data Items are constructed of compound types which themselves consist of primitive
types. For example the compound type ‘time’ may be constructed of the primitive
types ‘hours’ and ‘minutes’. This chapter therefore specifies the construction of each
required Data Item, in terms of compound and primitive types, and is categorised into
sub-sections for which the compound types are similar.
The description of each compound type specifies the requirements for the
identification, format, and quality of service when transmitting or receiving Data Items
of that compound type.
Primitive types are the most granular means of specifying information exchange in this
document and form the basis of all Data Items in this data exchange model. Primitive
types are specified in the first instance of the compound type in which they appear. In
the example above, the primitive types ‘hours’ and ‘minutes’ would be specified further
as integers of 2 significant figures and bounded to the values 00-23 and 00-59
respectively.
The compound types explain how the primitive types combine to form useful Data
Items in the Airport-CDM system. For example the target take-off time includes the
compound type ‘time’ which is made up of the ‘hours’ and ‘minutes’ primitive types.
This chapter also specifies which elements of the Data Items are required - denoted
by bold, square brackets, and which elements are recommended - denoted by curly
brackets.
The intention of the specified format is to allow implementers as much design freedom
as possible whilst supporting a consistency in data transfer between logical elements
and Airport-CDM systems. Where applicable, the format is consistent with ADEXP.
V0.99
© EUROCAE, 2008
PAGE 12 OF 39
13
3.2
GENERAL REQUIREMENTS ON DATA TRANSMISSION
For each instance of Data Item transmission between logical elements and the AirportCDM system there are some requirements that apply unilaterally. These are specified
below:
[ED145-08]
Each transmission shall include a unique identification of the flight to which it relates.
Note: For requirements relating to the Data Items used to uniquely identify a flight
please see section 3.8.
[ED145-09]
The Airport-CDM system shall be able to communicate with external Airport-CDM
logical elements in ICAO format.
Note: Data exchange with the CFMU (FUM/DPI) will take place only in ICAO format.
[ED145-10]
The Airport-CDM system shall be able to communicate with Airport-CDM logical
elements in IATA format, where preferred over ICAO terminology, by those logical elements.
[ED145-11]
It shall be possible to identify the originators and modifiers of any Data Item that is
transmitted to or from the Airport-CDM system.
V0.99
© EUROCAE, 2008
PAGE 13 OF 39
14
3.3
REQUIREMENTS ON COMPOUND TYPE: EVENT_TIME
3.3.1
Data Item Identifiers
[ED145-12]
Each Data Item of the type Event_Time shall be identified by the corresponding
DataID from the table below.
[ED145-13]
The primitive type ‘DataID’ shall be formatted as follows:
DataID: String, alphanumeric characters
Data Item
DataID
Actual Commencement of De-icing Time
ACZT
Actual End of De-icing Time
AEZT
Actual Final Approach Time
AFAT
Actual Ground Handling Time
AGHT
Actual In Block Time
AIBT
Actual Landing Time
ALDT
Actual Off Block Time
AOBT
Actual Ready for De-icing Time
ARZR
Actual Start Boarding Time
ASBT
Actual Start up Approval Time
ASAT
Actual Start up Request Time
ASRT
Actual Take Off Time
ATOT
Aircraft Operator Target Take-Off Time2
ATTOT
Aircraft Ready Time
ARDT
Anticipated Actual Take Off
Time 2
AATOT
Calculated Take Off Time
CTOT
Estimated Commencement of De-icing Time
ECZT
Estimated End of De-icing Time
EEZT
Estimated In Block Time
EIBT
Estimated Landing Time
ELDT
Estimated Off Block Time
EOBT
Estimated Ready for De-icing Time
ERZT
Estimated Take Off Time
ETOT
Schedule Off Block Time
SOBT
Scheduled In Block Time
SIBT
Target Off Block Time
TOBT
Target Start Up Approval Time
TSAT
Target Take Off Time
TTOT
TABLE 2: EVENT_TIME DATA ITEMS
2
V0.99
This Data Item is not provided in CDM documentation, only CFMU documentation and is due to be
replaced in the future for consistency
© EUROCAE, 2008
PAGE 14 OF 39
15
3.3.2
Format
[ED145-14]
With the exception of ELDT, each Data Item of the type Event_Time shall be
formatted to include the primitive types shown in the bold square brackets [ ] below
[ED145-15]
With the exception of ELDT, each Data Item of the type Event_Time should be
formatted to include the primitive types shown in the curly brackets { } below
Event_Time (not ELDT): [DataID]{Date}[Time]
Date: [Year][Month][Day]
Time: [Hours][Minutes]{Seconds}
Note: If date is included then Year, Day and Month must all be included
Note: The selected elements of the Event_Time Data Item that are implemented can
therefore be characterised by the length of the data item (excluding DataId) eg. 4
characters would be just Hours and Minutes whereas 12 characters would be Years,
Month, Day, Hours, Minutes and Seconds.
[ED145-16]
The primitive type ‘Year’ shall be formatted as follows:
Year: Integer, bounded 00-99
[ED145-17]
The primitive type ‘Month’ shall be formatted as follows:
Month: Integer, bounded 01-12
[ED145-18]
The primitive type ‘Day’ shall be formatted as follows:
Day: Integer, bounded 01-31
[ED145-19]
The primitive type ‘Hours’ shall be formatted as follows:
Hours: Integer, bounded 00-23
[ED145-20]
The primitive type ‘Minutes’ shall be formatted as follows:
Minutes: Integer, bounded 00-59
[ED145-21]
The primitive type ‘Seconds’ shall be formatted as follows:
Seconds: Integer, bounded 00-59
[ED145-22]
The ELDT Data Item shall be formatted to include the primitive types shown in the
bold square brackets [ ] below
Event_Time (ELDT): [Data Item Identifier][Date][Time]
Data Item Identifier: [DataID]
Date: [Year][Month][Day]
Time: [Hours][Minutes][Seconds]
Note: ELDT may be sent as part of the FUM message specified in 3.9
Note: Please see [ED145-16] to [ED145-21] for the primitive types identified here.
3.3.3
Quality of Service
[ED145-23]
The ALDT Data Item shall be sent no later than 1 minute after the aircraft touch down.
[ED145-24]
The AGHT Data Item shall be sent no later than 1 minute of it being provided.
[ED145-25]
The TSAT Data Item shall be sent no later than 1 minute after the aircraft is queued
into the tactical pre departure sequence.
[ED145-26]
V0.99
The ASBT Data Item shall be sent no later than 1 minute after the start of boarding.
© EUROCAE, 2008
PAGE 15 OF 39
16
[ED145-27]
The ARDT Data Item shall be sent no later than 1 minute after the aircraft is ready.
[ED145-28]
requested.
The ASRT Data Item shall be sent no later than 1 minute after the start up has been
[ED145-29]
for start up.
The ASAT Data Item shall be sent no later than 1 minute after the aircraft is cleared
Note: If implementing DCL, IR 27-29 may not apply.
V0.99
© EUROCAE, 2008
PAGE 16 OF 39
17
3.4
REQUIREMENTS ON COMPOUND TYPE: EVENT_DATE
3.4.1
Data Item Identifiers
[ED145-30]
Each Data Item of the type Event_Date shall be identified by the corresponding
DataID from the table below.
Note: See [ED145-13] for the primitive type DataID.
Data Item
DataID
Estimated Off Block Date
EOBD
TABLE 3: EVENT_DATE DATA ITEMS
3.4.2
Format
[ED145-31]
Each Data Item of the type Event_Date shall be formatted to include the primitive
types shown in the bold square brackets [ ] below
Event_Time: [DataID][Date]
Date: [Year][Month][Day]
Note: Please see [ED145-16] to [ED145-18] for the primitive types identified here.
3.4.3
Quality of Service
No minimum quality of service requirements have been identified.
V0.99
© EUROCAE, 2008
PAGE 17 OF 39
18
3.5
REQUIREMENTS ON COMPOUND TYPE: EVENT_DURATION
3.5.1
Data Item Identifiers
[ED145-32]
Each Data Item of the type Duration shall be identified by the corresponding DataID
from the table below.
Note: See [ED145-13] for the primitive type DataID.
Data Item
DataID
Estimated De-icing Time
EDIT
Estimated Elapse Time
EET
Estimated Turn Round Time
ETTT
Estimated Taxi In Time
EXIT
Minimum Turn Round Time
MTTT
Estimated Taxi Out Time
EXOT
Note: This is called “TAXITIME” in DPI messages
TABLE 4: EVENT_DURATION DATA ITEMS
3.5.2
Format
[ED145-33]
Each Data Item of the type Duration shall be formatted to include the elements shown
by the bold square brackets [ ] below
[ED145-34]
Each Data Item of the type Duration should be formatted to include the elements
shown by the curly brackets { } below
Event_Duration: [DataID][Duration]
Duration: [Hours][Minutes]{Seconds}
Note: Please see [ED145-19] to [ED145-21] for the primitive types identified here.
3.5.3
Quality of Service
No minimum quality of service requirements have been identified.
V0.99
© EUROCAE, 2008
PAGE 18 OF 39
19
3.6
REQUIREMENTS ON COMPOUND TYPE: AIRPORT_RESOURCE
3.6.1
Data Item Identifiers
[ED145-35]
Each Data Item of the type Airport_Resource shall be identified by the corresponding
DataID from the table below.
Note: See [ED145-13] for the primitive type DataID.
Data Item
DataID
Gate
GATE
Arrival parking position
PKA
Departure parking position
PKDEP
Runway to Be Used for Take Off
RWYDEP
Runway to Be Used for Landing
RWYARR
TABLE 5: AIRPORT_RESOURCE DATA ITEMS
3.6.2
Format
[ED145-36]
The format of the Gate Data Item shall be as follows:
Airport_Resource (Gate): [DataID][Gate]
[ED145-37]
The primitive type ‘Gate’ shall be formatted as follows:
Gate: alphanumeric, maximum length 6
[ED145-38]
The format of the Arrival parking position and Departure parking position Data Item
shall be as follows:
Airport_Resource (... parking position): [DataID][ParkPosition]
[ED145-39]
The primitive type ‘ParkPosition’ shall be formatted as follows:
ParkPosition: alphanumeric, maximum length 3
Note It is proposed to ADEXP to extent the maximum length to 6 alphanumeric
characters.
Note. PKA is the reserved, not yet allocated parking position.
[ED145-40]
The format of the Runway to be Used for Take Off and Runway to be Used for
Landing Data Items shall be as follows:
Airport_Resource (Runway to be used for …): [DataID][Runway]
Runway: [Bearing]{Orientation}
[ED145-41]
The primitive type ‘Bearing’ shall be formatted as follows:
Bearing: Integer, bounded 00-36
[ED145-42]
The primitive type ‘Orientation’ shall be formatted as follows:
Orientation: String, LL/L/C/R/RR
3.6.3
Quality of Service
No minimum quality of service requirements have been identified.
V0.99
© EUROCAE, 2008
PAGE 19 OF 39
20
3.7
REQUIREMENTS ON COMPOUND TYPE: ALERT
3.7.1
Data Item Identifiers
[ED145-43]
Each Data Item of the type Alert should be identified by the corresponding DataID
from the table below.
Note: Alerts are still subject to change and therefore this
recommendations rather than mandatory requirements.
table
provides
Note: See [ED145-13] for the primitive type DataID.
Note: CFMU Error Messages are continuing to develop and be added to the CDM
documentation as the CFMU document [4] matures.
Data Item
DataID
No Airport Slot Available, or Slot already correlated
CDM01
SOBT vs. EOBT discrepancy
CMD02
Aircraft Type / Registration discrepancy
CDM03
Flight ID discrepancy
CDM04
Destination discrepancy
CDM05
Non-Airborne Alert
CDM06
EIBT + MTTT discrepancy with EOBT
CDM07
EOBT Compliance Alert
CDM08
CTOT Revision Alert
CDM09
Boarding Not Started
CDM10
Flight removed from pre departure sequence
CDM11
TSAT passed
CDM12
TABLE 6: ALERT DATA ITEMS
3.7.2
Format
[ED145-44]
Each Data Item of the type Alert shall be formatted to include the elements shown by
the bold square brackets [ ] below
[ED145-45]
Each Data Item of the type Alert should be formatted to include the elements shown
by the curly brackets { } below
Alert: [DataID][InconsistencyDetection][ActionToTake][Consequences]
[ED145-46]
The primitive type ‘InconsistencyDetection’ shall be formatted as follows:
InconsistencyDetection: String
Example:
ATC Flight Plan EOBT is not consistent with airport slot SOBT.
[ED145-47]
The primitive type ‘ActionToTake’ shall be formatted as follows:
ActionToTake: String
Example:
Immediate update of airport slot or ATC flight plan EOBT needed.
V0.99
© EUROCAE, 2008
PAGE 20 OF 39
21
[ED145-48]
The primitive type ‘Consequences’ shall be formatted as follows:
Consequences: String
Example:
The Airport CDM process will be suspended until reception of your rectification.
3.7.3
Quality of Service
[ED145-49]
The values of the time parameters, including detection and response times, for all
Data Items of the type Alert shall be agreed locally.
V0.99
© EUROCAE, 2008
PAGE 21 OF 39
22
3.8
REQUIREMENTS ON COMPOUND TYPE: OTHER_FLIGHT_INFORMATION
3.8.1
Data Item Identifiers
This section describes Data Items that do not belong in the previous categories of
time, duration, alert etc. It includes data that used to help identify a flight, which is a
necessary task in all data transmissions in the CDM system (see [ED145-08]). There
are 3 ways in which a flight may be identified:

Using the initial flight plan identifier (IFPLID)

Using ICAO key fields (departure airport, destination airport, estimated off block
time and date, aircraft identification)

Using IATA key fields (departure airport, destination airport, estimated off block
time and date, flight number)
[ED145-50]
Each Data Item of the type Other_Flight_Information shall be identified by a Data Item
Identifier as specified in the table below.
Note: See [ED145-13] for the primitive type DataID.
Data Item
DataID
Airport of Departure (ICAO)
ADEP
Airport of Destination (ICAO)
ADES
Airport of Departure (IATA)
DEP
Airport of Destination (IATA)
DEST
Aircraft Identification (ICAO)
ARCID
Flight Number (IATA)
FLTNO
Aircraft Registration
REG
Aircraft Type (ICAO)
ARCTYP
Aircraft Code (IATA)
ARCCOD
IFPLID
IFPLID
Standard Instrument Departure
SID
TABLE 7: OTHER_FLIGHT_INOFRMATION DATA ITEMS
3.8.2
Format
[ED145-51]
To identify a flight by the IFPLID, the items shown by the bold square brackets [ ]
below shall be included
Other_Flight_Information (IFPLID): [DataID][IFPLID]
[ED145-52]
The primitive type ‘IFPLID’ shall be formatted as follows:
IFPLID: 2 characters followed by 8 digits
[ED145-53]
To identify a flight by the ICAO keyfields, the items shown by the bold square brackets
[ ] below shall be included (in addition to EOBD and EOBT)
Other_Flight_Information (ICAO keyfields):
[DataID(ADEP)][ICAOaerodrome][DataID(ADES)][ICAOaerodrome][Aircraftid]
[ED145-54]
V0.99
The primitive type ‘ICAOaerodrome’ shall be formatted as follows:
© EUROCAE, 2008
PAGE 22 OF 39
23
ICAOaerodrome: 4 letter ICAO designation.
[ED145-55]
The primitive type ‘Aircraftid’ shall be formatted as follows:
Aircraftid: 3 letter ICAO company designator of the airline operator followed by the 4
character alphanumeric flight identifier.
or
Aircraftid: Registration
[ED145-56]
To identify a flight by the IATA keyfields, the items shown by the bold square brackets
[ ] below shall be included (in addition to EOBD and EOBT)
Other_Flight_Information (IATA keyfields):
[DataID(DEP)][IATAaerodrome][DataID(DEST)][IATAaerodrome][FlightNumber]
[ED145-57]
The primitive type ‘IATAaerodrome’ shall be formatted as follows:
IATAaerodrome: String, IATA designation.
[ED145-58]
The primitive type ‘FlightNumber’ shall be formatted as follows:
FlightNumber: 2 letter IATA company designator of the airline operator followed by the
5 character alphanumeric flight identifier.
[ED145-59]
The Aircraft Registration Data Item shall be formatted to include the items shown by
the bold square brackets [ ] below
Other_Flight_Information (Aircraft Registration): [DataID][Registration]
[ED145-60]
The primitive type ‘Registration’ shall be formatted as follows:
Registration: String, maximum length 7 characters.
[ED145-61]
The Aircraft Type Data Item shall be formatted to include the items shown by the bold
square brackets [ ] below
Other_Flight_Information (Aircraft Type): [DataID][ICAOaircrafttype]
[ED145-62]
The primitive type ‘ICAOaircrafttype’ shall be formatted as follows:
ICAOaircrafttype: String ICAO designator, 3 or 4 characters.
[ED145-63]
The Aircraft Code Data item shall be formatted to include the items shown by the bold
square brackets [ ] below
Other_Flight_Information (Aircraft Code): [DataID][IATAaircraftcode]
[ED145-64]
The primitive type ‘IATAaircraftcode’ shall be formatted as follows:
IATAaircraftcode: String IATA designator, 3 characters.
[ED145-65]
The SID Data Item shall be formatted to include the items shown by the bold square
brackets [ ] below
Other_Flight_Information (SID): [DataID][SID]
[ED145-66]
The primitive type ‘SID’ shall be formatted as follows:
SID: 2-5 characters, followed by one digit, followed by one character.
V0.99
© EUROCAE, 2008
PAGE 23 OF 39
24
3.8.3
Quality of Service
No minimum quality of service requirements have been identified.
V0.99
© EUROCAE, 2008
PAGE 24 OF 39
25
3.9
REQUIREMENTS ON COMPOUND TYPE: CFMU_MESSAGE
3.9.1
Data Item Identifiers
[ED145-67]
table below.
Each Data Item of the type CFMU_Message shall be identified by the DataID from the
Note: DPI messages are not distinguished by the title as they are distinguished by their
message content. They are therefore denoted by the single DataID TitleDPI..
Note: See [ED145-13] for the primitive type DataID.
Note: CFMU Messages are continuing to develop and be added to the CDM
documentation as the CFMU document [4] matures.
Data Item
DataID
Flight Update Message
FUM
ATC Departure Planning Information Message
TITLE DPI
Cancel Departure Planning Information Message
TITLE DPI
Early Departure Planning Information Message
TITLE DPI
Target Departure Planning Information Message
TITLE DPI
DPI Error Message
TITLE ERR
Slot Allocation Message
SAM
Slot Revision Message
SRM
Flight Suspension Message
FLS
Desuspension Message
DES
DPI Status
DPISTATUS
TABLE 8: CFMU_MESSAGE DATA ITEMS
3.9.2
Format
[ED145-68]
The format of the Data Items of type CFMU_Message shall be as specified in the
CFMU documents [4] and [5].
3.9.3
Quality of Service
[ED145-69]
The E-DPI shall be sent no earlier than 3 hours before EOBT is sent and only if
Milestone 1 is completed.
[ED145-70]
The A-DPI shall be sent immediately after receiving the AOBT or in the case of
remote holding at a defined time prior to TTOT.
[ED145-71]
The T-DPI shall be sent no earlier than 2 hours before EOBT is sent.
[ED145-72]
The C-DPI shall be sent in case the TTOT is no longer known (eg. TOBT deletion).
V0.99
© EUROCAE, 2008
PAGE 25 OF 39
26
ANNEX A
EXAMPLE OF DATA EXCHANGE BETWEEN
LOGICAL ELEMENTS AND THE AIRPORT-CDM SYSTEM
A.1
INTRODUCTION
This appendix describes an example of the data exchange between the logical
elements and the Airport-CDM System. As discussed in CHAPTER 2 the ownership
and responsibility for sending/receiving data will be a local implementation decision
and therefore only the data itself can be standardised (see CHAPTER 3).
A.2
V0.99
Data Exchange
Data Item
Type
Recommended Sender
Aircraft Type / Registration discrepancy
Alert
A-CDM
Boarding Not Started
Alert
A-CDM, Airport
CTOT Revision Alert
Alert
A-CDM
Destination discrepancy
Alert
A-CDM
EIBT + MTTT discrepancy with EOBT
Alert
A-CDM
EOBT Compliance Alert
Alert
A-CDM
Flight ID discrepancy
Alert
A-CDM
Flight removed from pre departure
sequence
Alert
A-CDM
No Airport Slot Available, or Slot already
correlated
Alert
A-CDM
Non-Airborne Alert
Alert
A-CDM
SOBT vs. EOBT discrepancy
Alert
A-CDM
TSAT passed
Alert
A-CDM
A-DPI
CFMU_Message
A-CDM
C-DPI
CFMU_Message
A-CDM
E-DPI
CFMU_Message
A-CDM
FUM
CFMU_Message
ATFCM
T-DPI
CFMU_Message
A-CDM
EOBD
Event_Date
all
EDIT
Event_Duration
De-icing Operations
EET
Event_Duration
AO
ETTT
Event_Duration
A-CDM
EXIT
Event_Duration
A-CDM
EXOT
Event_Duration
A-CDM
MTTT
Event_Duration
AO
Actual Final Approach Time
Event_Time
ATC, Airport
ACZT
Event_Time
De-icing Operations
AEZT
Event_Time
De-icing Operations
AGHT
Event_Time
Ground Handling
AIBT
Event_Time
Airport
ALDT
Event_Time
ATC, Airport
© EUROCAE, 2008
PAGE 26 OF 39
27
AOBT
Event_Time
Airport
ARDT
Event_Time
AO, Ground Handling
ARZT
Event_Time
De-icing Operations
ASAT
Event_Time
ATC
ASBT
Event_Time
AO, Airport
ASRT
Event_Time
ATC
ATOT
Event_Time
ATC
CTOT
Event_Time
ATFMC
ECZT
Event_Time
De-icing Operations
EEZT
Event_Time
De-icing Operations
EIBT
Event_Time
AO
ELDT
Event_Time
ATC, ATFMC, Airport
EOBT
Event_Time
AO
ERZT
Event_Time
De-icing Operations
ETOT
Event_Time
A-CDM
SIBT
Event_Time
AO
SOBT
Event_Time
AO
TOBT
Event_Time
AO
TSAT
Event_Time
De-icing Operations, ACDM
TTOT
Event_Time
A-CDM
ADEP
Other_Flight_Information
AO
ADES
Other_Flight_Information
AO
Aircraft Identification
Other_Flight_Information
AO
Aircraft Registration
Other_Flight_Information
AO
Aircraft Type
Other_Flight_Information
AO
Commercial Fight Number
Other_Flight_Information
AO
Runway to Be Used for Landing
Other_Flight_Information
ATC
Runway to Be Used for Take Off
Other_Flight_Information
ATC
TABLE 9: DATA EXCHANGE EXAMPLE
V0.99
© EUROCAE, 2008
PAGE 27 OF 39
28
AIRPORT CDM DEFINITIONS
Definitions described below are consistent with those from the EUROCONTROL:
Airport CDM Functional Requirements Document [2].
Airport Collaborative Decision Making (CDM) is a concept which aims at
improving Air Traffic Flow and Capacity Management (ATFCM) at airports
by reducing delays, improving the predictability of events and optimising the
utilisation of resources.
Implementation of Airport CDM allows each Airport CDM Partner to
optimise their decisions in collaboration with other Airport CDM Partners,
knowing their preferences and constraints and the actual and predicted
situation.
Airport Collaborative
Decision Making (Airport
CDM)
Airport CDM Information
Sharing Concept Element
(ACIS)
The decision making by the Airport CDM Partners is facilitated by the
sharing of accurate and timely information and by adapted procedures,
mechanisms and tools.
The Airport CDM concept is divided in the following Elements:

Airport CDM Information Sharing

CDM Turn-round Process – Milestones Approach

Variable Taxi Time Calculation

Collaborative Management of Flight Updates

Collaborative Pre-departure Sequence

CDM in Adverse Conditions

Advanced CDM
The Airport CDM Information Sharing Element defines the sharing of
accurate and timely information between the Airport CDM Partners in order
to achieve common situational awareness and to improve traffic
predictability.
The Airport CDM Information Sharing Platform (ACISP), together with
defined procedures agreed by the partners, is the means used to reach
these aims.
The Airport CDM Information Sharing is the core Airport CDM Element and
the foundation for the other Airport CDM Elements.
Airport CDM Information
Sharing Platform (ACISP)
The Airport CDM Information Sharing Platform (ACISP) is a generic term
used to describe the means at a CDM AIRPORT of providing Airport CDM
Information Sharing between the Airport CDM Partners.
The ACISP can comprise of systems, tools and user interfaces.
V0.99
© EUROCAE, 2008
PAGE 28 OF 39
29
An Airport CDM Partner is a stakeholder of a CDM AIRPORT, who
participates in the CDM process.
The main Airport CDM Partners are:
Airport CDM Partner







Alarm
CDM AIRPORT
The Airport Operator
Aircraft Operators
Ground Handlers
De-icing companies
The Air Navigation Service Provider (ATC)
The CFMU
Support services (Police, Customs and Immigration etc)
A system generated alert to the CDM Partners of an irregularity and which
normally requires one or more CDM Partners to make a manual
intervention to resolve the irregularity.
An airport status that is considered when the Airport CDM Information
Sharing, Turn-round process (Milestones Approach), and Variable Taxi
Time Calculation Elements are applied at the airport.
The Collaborative Management of Flight Updates Element consists of
exchanging Flight Update Messages (FUM) and Departure Planning
Information (DPI) messages between the CFMU and a CDM AIRPORT to
provide estimates for arriving flights to CDM Airports and improve the
ATFM slot management process for departing flights.
Collaborative Management
of Flight Updates Concept
Element (COFU)
The aim is to improve the coordination between Air Traffic Flow and
Capacity Management (ATFCM) and airport operations at a CDM
AIRPORT.
The Airport CDM Information Sharing, CDM Turn-round Process
(Milestones Approach) and Variable Taxi Time Calculation Elements need
to be applied at the CDM AIRPORT to implement the Collaborative
Management of Flight Updates.
Collaborative Predeparture
Sequence Concept
Element (CPSQ)
The Collaborative Predeparture sequence is the order that aircraft are
planned to depart from their stands (push off blocks) taking into account
partners’ preferences. It should not be confused with the pre-take off order
where ATC organise aircraft at the holding point of a runway.
The aim is to enhance flexibility, increase punctuality and improve slotadherence, allowing the airport partners to express their preferences.
At least the Airport CDM Information Sharing and the CDM Turn-round
Process (Milestones Approach) Elements need to be applied at the CDM
AIRPORT to implement the Collaborative Predeparture Sequence.
The CDM in Adverse Conditions Element consists of a collaborative
management of the capacity of a CDM AIRPORT during periods of a
predicted or unpredicted reduction of capacity.
CDM in Adverse
Conditions Concept
Element (CDAC)
The aim is to achieve a common situational awareness for the Airport CDM
Partners, including better information for the passengers, in anticipation of
a disruption and expeditious recovery after the disruption.
At least the Airport CDM Information Sharing [Concept Element /
Application] needs to be applied at the CDM AIRPORT to implement the
CDM in Adverse Conditions.
CDM Turn-round Process
Concept Element (CTRP)
V0.99
The CDM Turn-round Process Element (Milestones Approach) describes
the progress of a flight from the initial planning to the take off from a CDM
AIRPORT by defining Milestones to enable close monitoring of significant
events.
© EUROCAE, 2008
PAGE 29 OF 39
30
The aim is to achieve a common situational awareness and to predict the
forthcoming events for each flight.
The CDM Turn-round Process combined with the Airport CDM Information
Sharing Element is the foundation for the other Airport CDM Elements.
Event
An Event is a distinct occurrence in the planning or operations of a flight
that a person or system perceives and responds to in a specific way.
Ground Handling
The Ground Handling covers a complex series of processes that are
required to separate an aircraft from its load (passengers, baggage, cargo
and mail) on arrival and combine it with its load prior to departure. [Source:
www.iata.org]
Ground Handling Agent /
Ground Handler
A Ground Handling Agent or Ground Handler is the company or person(s)
that perform Ground Handling.
A significant event that occurs during the planning or progress of a flight.
Milestone
Variable Taxi Time
Variable Taxi Time
Calculation Concept
Element (VTTC)
A successfully completed Milestone will trigger the decision making process
for downstream events and influence both the further progress of the flight
and the accuracy with which the progress can be predicted.
Variable Taxi Time is the duration of time that an aircraft spends taxiing
between its parking stand and the runway or vice versa. It includes some
time spent on the runway when lining up and vacating.
The Variable Taxi Time Calculation Element consists of calculating and
distributing to the Airport CDM Partners accurate estimates of taxi-in and
taxi-out times to improve the estimates of in-block and take off times. The
complexity of the calculation may vary according to the needs and
constraints at the CDM AIRPORT.
The aim is to improve the traffic predictability.
At least the Airport CDM Information Sharing Element needs to be applied
at the CDM AIRPORT to implement the Variable Taxi Time Calculation.
V0.99
© EUROCAE, 2008
PAGE 30 OF 39
31
LIST OF ACRONYMS
Acronyms described in the first table are those from the EUROCONTROL: Airport
CDM Functional Requirements Document [2]. In the second table, the list of additional
abbreviations for ED-145 is given.
(The green lines refer to Times definitions)
Acronym
a/c
ACARS
Meaning
Definition
Aircraft
Aircraft
Communications
Addressing and Reporting System
ACC
Area Control Centre
ACIS
Airport CDM Information Sharing
ACISP
Airport CDM Information Sharing
Platform
ACH
ATC ATC
Message
flight
plan
Change
ACK
Acknowledgement message
ACZT
Actual Commencement of De-icing The time when de-icing operations on an aircraft
Time
starts
ADEP
Aerodrome of Departure
ADES
Aerodrome of Destination
ATS Data Exchange Presentation
ADEXP provides a format for use primarily in on-line,
computer to computer message exchange. ADEXP
is a format, not a protocol.
ADIT
Actual De-icing Time
AEZT – ACZT
A-DPI
ATC-Departure
Information message
AEZT
Actual End of De-icing Time
AFTN
Aeronautical
Telecommunication Network
AGHT
Actual Ground Handling Start Time
(self explaining)
AIBT
Actual In-Block Time
The time that an aircraft arrives in blocks.
(Equivalent to Airline/Handler ATA –Actual Time of
Arrival, ACARS = IN).
ALDT
Actual Landing Time
The time that an aircraft lands on a runway.
(Equivalent to ATC ATA –Actual Time of Arrival =
landing, ACARS=ON).
AMAN
Arrival Manager
ANSP
Air Navigation Service Provider
ADEXP
AO
V0.99
Aircraft Operator
Planning DPI message sent at AOBT by the CDM AIRPORT
to the CFMU (ETFMS) notifying the TTOT
The time when de-icing operations on an aircraft end
Fixed
Aircraft Operator - A person, organization or
enterprise engaged in or offering to engage in an
aircraft operation.
© EUROCAE, 2008
PAGE 31 OF 39
32
Acronym
Meaning
Definition
(ICAO Doc 4444, Chapter 1)
AOBT
Time the aircraft pushes back / vacates the parking
position. (Equivalent to Airline / Handlers ATD –
Actual Time of Departure & ACARS=OUT)
Actual Off-Block Time
AOC
Airline Operational (Control) Centre
APR
Airport Operations Programme
ARDT
When the aircraft is ready for pushback or taxi
immediately after clearance delivery (all doors are
closed and the pushback tractor – ordered by the
handling agent – is in position)
Actual Ready Time
ARR
Arrival
ARZT
Actual Ready for De-icing Time
The time when the aircraft is ready to be de-iced
ASAT
Actual Start- Up Approval Time
Time that an aircraft receives its Start up approval.
ASBT
Actual Start Boarding Time
(self explaining)
A-SMGCS
ASRT
ATC
ATFCM
Advanced
Surface
Movement
Guidance and Control System
Actual Start-Up Request Time
(self explaining)
Air Traffic Control
Air Traffic Flow
Management
and
Air Traffic Flow and Capacity Management
(AFTCM). ATFM extended to the optimisation of
traffic patterns and capacity management. Through
managing the balance of Capacity and Demand the
Capacity aim of ATFCM is to enable flight punctuality and
efficiency according to the available resources with
the emphasis on optimising the network capacity
through collaborative decision making process.
(CFMU Handbook – ATFCM Operating Procedures
for FMP 1.0)
ATFM
Air Traffic Flow Management
Air Traffic Flow Management (ATFM) - A service
established with the objective of contributing to a
safe, orderly and expeditious flow of air traffic by
ensuring that air traffic control capacity is utilised to
the maximum extent possible, and that the traffic
volume is compatible with the capacities declared by
the appropriate air traffic services authority.
(ICAO Annex 11, Chapter 1)
ATM
Air Traffic Management
ATOT
Actual Take Off Time
ATS
The time that an aircraft takes off from the runway.
(Equivalent to ATC ATD–Actual Time of Departure,
ACARS = OFF).
Air Traffic Services
ATSP
Air Traffic Service Provider
ATTT
Actual Turn-round Time
AOBT - AIBT
AXIT
Actual Taxi-In Time
AIBT - ALDT
AXOT
Actual Taxi-Out Time
ATOT - AOBT
CBA
Cost-Benefit Analysis
CDAC
V0.99
CDM in Adverse Conditions
© EUROCAE, 2008
PAGE 32 OF 39
33
Acronym
Meaning
Definition
CDB
Central Data Base
CDM
Collaborative Decision Making
CDM
AIRPORT
C-DPI
CFMU
An airport is considered as a CDM AIRPORT when
the Airport CDM Information Sharing, Turn-round
process (Milestones Approach) and Variable Taxi
Time Calculation Elements are applied at the Airport
CDM Airport
Cancel - Departure
Information message
Planning This message informs the CFMU that previously
sent DPI is no longer valid.
Central Flow Management Unit
Central Flow Management Unit (CFMU), Brussels
- A Central Management Unit operated by
EUROCONTROL.
(ICAO Doc 7754, Volume I, Part V.III, paragraph 3)
CHG
Modification Message
CNL
ATC
flight
Message
plan
Cancellation
COFU
Collaborative Management of Flight
Updates
CPDS
Collaborative
Sequence
CTOT
Pre-Departure
Calculated Take Off Time (CFMU)
A time calculated and issued by the appropriate
central management unit, as a result of tactical slot
allocation, at which a flight is expected to become
airborne.
(ICAO Doc 7030/4 - EUR, Table 7)
CTRP
CDM Turn-Round Process
DCS
Departure Control System
DEP
Departure
DES
De-suspension message
DGS
Docking Guidance System
DLA
Delay message
DMAN
DPI
Departure Manager
Departure
message
Planning
Information
(Message, see A-DPI, C-DPI, E-DPI,T-DPI)
ECZT
Estimated Commencement of De- The estimated time when de-icing operations on an
icing Time
aircraft are expected to start
EDIT
Estimated De-icing Time
E-DPI
Early
Departure
Information message
EET
Estimated Elapsed Time
The estimated time required to proceed from one
significant point to another (ICAO)
EEZT
Estimated End of De-icing Time
The estimated time when de-icing operations on an
aircraft are expected to end
EIBT
Estimated In-Block Time
The estimated time that an aircraft will arrive in
blocks. (Equivalent to Airline/Handler ETA –
Estimated Time of Arrival).
V0.99
EEZT – ECZT
First DPI message is sent from -3 hrs and before the
Planning T-DPI message by the CDM AIRPORT to the CFMU
(ETFMS) notifying the ETOT. Also first DPI sent
after ATC flight plan Cancellation.
© EUROCAE, 2008
PAGE 33 OF 39
34
Acronym
Meaning
Definition
ELDT
Estimated Landing Time
The estimated time that an aircraft will touchdown on
the runway. (Equivalent to ATC ETA –Estimated
Time of Arrival = landing).
EOBT
Estimated Off-Block Time
The estimated time at which the aircraft will
commence movement associated with departure
(ICAO).
ERZT
Estimated Ready for De-icing Time
The estimated time when the aircraft is expected to
be ready for de-icing operations
ETFMS
ETO
Enhanced
Tactical
Management System
Flow
Estimated Time Over
ETOT
Estimated Take Off Time
The estimated take off time taking into account the
EOBT plus EXOT.
ETTT
Estimated Turn-round Time
The time estimated by the AO/GH on the day of
operation to turn-round a flight taking into account
the operational constraints
EXIT
Estimated Taxi-In Time
The estimated time between landing and in-block
EXOT
Estimated Taxi-Out Time
The estimated time between off-block and take off
FG
FIDS
Functional Group
Flight Information Display System
FIR
Flight Information Region
FLS
Flight Suspension message
FMP
Flow Management Position
FPL
Filed ATC flight plan
FRD
Functional Requirements Document
FSA
First System Activation
FUM
Flight Update Message
GAT
General Air Traffic
GH
Ground Handler
HMI
Human-Machine Interface
ICAO
IFPS
International
Organization
Civil
(ICAO)
A FUM is sent from the CFMU to a CDM AIRPORT
providing an ELDT, ETO and Flight Level at the last
point of route.
Aviation
Integrated Initial ATC flight plan Processing
System (IFPS) - A system of the CFMU designed to
rationalise the reception, initial processing and
Integrated Initial ATC flight plan distribution of IFR/GAT ATC flight plan data related
Processing System
to IFR flight within the area covered by the
participating States.
(ICAO Doc 7030/4 - EUR, paragraph 3.1.1 new)
V0.99
IFR
Instrument Flight Rules
KPI
Key Performance Indicator
LoA
Letter of Agreement
LVP
Low Visibility Procedures
© EUROCAE, 2008
PAGE 34 OF 39
35
Acronym
Meaning
Definition
MoU
Memorandum of Understanding
MST
Milestone
MTTT
Minimum Turn-round Time
MVT
Movement message
OAT
Operational Air Traffic
OCD
Operational Concept Document
PAX
Passengers
PMP
Project Management Plan
REA
Ready message
REJ
Rejection message
RFP
Replacement ATC flight plan
RPL
Repetitive ATC flight plan
RWY
Runway
SAM
Slot Allocation Message
SIBT
Scheduled In-Block Time
The minimum turn-round time agreed with an
AO/GH for a specified flight or aircraft type.
The time that an aircraft is scheduled to arrive at its
parking position.
SID
Standard Instrument Departure
SIT1
CFMU Slot Issue Time
SITA
Société
Internationale
de
Télécommunications Aéronautiques
SLA
Service Level Agreement
SLC
Slot Cancellation message
SOBT
Scheduled Off-Block Time
SRM
Slot Revision Message
SSR
Secondary Surveillance Radar
The time when the CFMU issues the SAM (Slot
Allocation Message). This is normally two hours
before EOBT.
The time that an aircraft is scheduled to depart from
its parking position.
STAR
Standard Arrival Route
STTT
Scheduled Turn-round Time
TBD
To Be Defined
T-DPI
Target
Departure
Information message
TOBT
TSAT
V0.99
Planning
SOBT - SIBT
This DPI message is sent from –2 hrs up to AOBT
by the CDM AIRPORT to the CFMU (ETFMS)
notifying the Target Take Off Time
Target Off-Block Time
The time that an aircraft operator / handling agent
estimates that an aircraft will be ready, all doors
closed, boarding bridge removed, push back vehicle
available, ready to start up / push back immediately
upon reception of clearance from the TWR .
Target Start-Up Approval Time
The time provided by ATC taking into account
TOBT, CTOT and/or the traffic situation that an
aircraft can expect to receive start up / push back
approval (when start up and push back are issued
© EUROCAE, 2008
PAGE 35 OF 39
36
Acronym
Meaning
Definition
together).
TTOT
Target Take Off Time
TWR
Aerodrome Control Tower
TWY
Taxiway
UI
VFR
The Target Take Off Time taking into account the
TOBT / TSAT / plus the EXOT.
User Interface
Visual Flight Rules
VTTC
Variable Taxi Time Calculation
WBS
Work Breakdown Structure
WP
Work Package
List of abbreviations for ED-145
Acronym
AATOT
AFAT
APT
ATTOT
C
DATAID
Meaning
Definition
Anticipated Actual Take Off Time
Actual Final Approach Time
EATM Airport Throughput Business
Division
Aircraft Operator Target Take Off
CFMU term
Time
Centre
Data Item Identifier
DEP
Departure Airport
DEST
Destination Airport
EATM
European Air Traffic Management
(programme)
EOBD
Estimated Off Block Date
IATA
International
Association
ID
IFPL
IFPLID
Initial Flight Plan
Initial Flight Plan Identifier
L
Left
LL
Left Left
R
Right
RTCA
Transport
Identifier
Interface Requirement
RR
V0.99
Air
IR
REG
CFMU term
Registration (number)
Right Right
Radio Technical Commission for
Aeronautics
SEA
Society of Automotive Engineers
XML
Extensible Markup Language
© EUROCAE, 2008
PAGE 36 OF 39
37
V0.99
© EUROCAE, 2008
PAGE 37 OF 39
38
SUB GROUP PARTICIPANTS
Segun ALAYANDE
BAA
Gilbert AMATO
EUROCAE
Emile-Henry BALLAND
Rainer BECKER
Jens-Dietrich BEHNE
INFORM GmbH
T-SYSTEM
Cesare BERNABEI
EUROPEAN COMISSION
Joseph BERNDES
FREQUENTIS
David BOOTH
EUROCONTROL
David BOWEN
EUROCAE
Francesco BRIOTTI
SELEX-SI
RobertChristopher BROWN
SELEX-SI
Simon BROWN
Alessandro CARROZZO
NATS
SELEX-SI
Francis CASAUX
DSNA
Randall DE GARIS
EUROCONTROL
Rafaele DE LUCA
SELEX-SI
Milen DENTCHEV
EUROCONTROL
Bruno DESART
EUROCONTROL
Stefaan DHAENENS
BELGOCONTROL
Isabelle DHONNEUR
NEOSYS
Manuala DISTLER
Alejandro EGIDO
FRAPORT
AENA
Velissarios ELEFTHERIOU
Peter ERIKSEN
AVIATION SOLUTIONS
EUROCONTROL
Marco FANTAUZZI
EUROCONTROL
Lionel FARA
AIR FRANCE
Eduardo GONI
AENA
Joe HANBURY
James HANSON
Len HEARNDEN
ARINC
HELIOS
EUROCONTROL
Henk HESSELINK
NLR
Dave HOGG
EUROCONTROL
Gero HOPPE
INFORM GmbH
Richard HOUDEBERT
THALES ATM
Anthony INARD
EUROCONTROL
David ISAAC
EUROCONTROL
Philippe JASSELIN
V0.99
THALES ATM
AIR TRAFFIC ALLIANCE
Keith JONES
SELEX-SI
Peter KANZLER
MUNICH AIRPORT
© EUROCAE, 2008
PAGE 38 OF 39
39
Elisabeth LAGIOS
EUROCONTROL
Christian LEFEBVRE
EUROCAE
Thomas LEONHARDT
Benjamin LEVY
SENSIS Corporation
Bob LEWIS
SELEX-SI
Jean-Luc MARTIN
Andre MERLING
Maria-Christina MEYER
SOFREAVIA
METRON AVIATION
EUROCONTROL
Olivier MONGENIE
Benjamin MORENO
Georges MYKONIATIS
Mar NAJAR
SOFREAVIA
INDRA
NEOSYS
AENA
Erwan PAGE
SDER
Stephane PAUL
THALES ATM
Saverio PASCULLI
Jean-Louis RAOUL
SELEX-SI
NEOMETSYS
Ken REID
EUROCONTROL
Laurent RENOU
SOFREAVIA
Patrick ROCCIA
C&S
Gonzalo RODRIGUEZ
INDRA
Mark H. RUNNELS
SENSIS Corporation
Dave SARGRAD
Erik SINZ
SENSIS
DFS
Gunnar SPIES
DLR
Giovanni TESI
GALILEO AVIONICA
Peter TOMLINSON
NATS
Terry THOMPSON
NEOMETSYS
Peter TRIMMEL
AUSTROCONTROL
Gerhard WAGNER
AUSTROCONTROL
Nathalie WALTENBERG
DFS
Janet WILLS
V0.99
FRAPORT
NATS
© EUROCAE, 2008
PAGE 39 OF 39