Interoperability Between Different Flight Data Exchange Systems

  • Home 2019 Interoperability Between Diffe....

Interoperability Between Different Flight Data Exchange Systems

58TH ANNUAL CONFERENCE, Conchal, Costa Rica, 20-24 May 2019

Agenda Item: B.5.7 – WP No. 91

Interoperability Between Different Flight Data Exchange Systems

Presented by TOC

Summary

The implementation of Automated Flight Data Exchange has a high impact on minimizing errors in the coordination cycle between adjacent ATC centres. There are currently three automated data exchange standards in use; PAN ICD AIDC, NAM ICD and OLDI. The ICAO Global Air Navigation Plan aims to implement Globally Interoperable Systems and Data in the future.

Introduction

1.1 While European, North American, Asia and Pacific ICAO regions have clearly defined the specifications requirements regarding exchange of flight data information using standard interfaces, other regions have problems with their systems interfaces interoperability due to a lack of standardisation of data exchange. Currently, several international specifications exist for the flight data exchange between FIRs, namely NAM ICD, APAC ICD and OLDI. However, all of them are incompatible with each other as they have different procedures and different sets of messages.

1.2. An ICAO harmonization process has been ongoing for years, and has resulted in the number of automated flight data exchange standards being reduced from five to three over the years.

1.3 This paper aims to highlight the problem of flight data exchange interoperability issues between different flight data exchange systems and standards, causing possible safety, capacity and coordination issues. A summary on the history of automated data exchange can be found in Appendix A of the paper.

Discussion

2.1 Need of automated co-operation

2.1 Over the years, verbal flight information coordination has shifted to automated flight data exchange. However, in many regions the automated date exchange between neighbouring ATS centres is not possible for various reasons. To maintain an orderly, efficient and safe flow of traffic, it is essential to have verified and exact data about each and every flight. Some of the operational benefits to automated flight data exchange include a reduction in coordination failures and human errors and a reduction in telephone calls.

2.1.1 In 2014 TOC presented WP91 (Communication between ATS Units) at the IFATCA Annual Conference. The IFATCA policy that was adopted emphasizes the importance of communication and data exchange between ATC centres.

2.1.2 Ground-to-ground communication is as important as air-to-ground communication

2.1.2 Several studies have shown the safety benefits of the implementation of automated data exchange.

2.1.2.1  Since the Reduced Vertical Separation Minimum (RVSM) implementation, the Caribbean and South American Monitoring Agency (CARSAMMA) and the Scrutiny Working Group (GTE) have analyzed Large Heigth Division (LHD) events. They have performed Collision Risk Model (CRM) assessments with the objective of measuring the Target Level of Safety (TLS) compliance as established in ICAO Doc 9574 on a 300 m (1 000 ft) Vertical Separation Minimum between FL 290 and FL 410. Between 2010 and 2015, a gradual increase in the LHD events was experienced; from 687 in 2010 to 1,225 in 2015. CRM evaluation data shows that, despite this rise, the results are still below the TLS established (5 x 10-9 fatal accidents per flight hour).

2.1.2.2  It has been determined that 94% of LHD events in the CAR/SAM Regions are produced by mistakes in the coordination cycle between Air Traffic Control (ATC) adjacent centers. Several initiatives to improve coordination between centers have resulted in a reduction in events. A reduction of 11.18% is obtained, with a total of 1,088 LHDs during 2016, in comparison to 1,225 LHDs in 2015.

2.1.2.3  Data shows that the FIRs that have implemented AIDC have reduced the amount of LHD events by more than 95%. This is for example the case in Cuba and COCESNA (Costa Rica, Honduras, Guatemala, El Salvador, Nicaragua, Belize), who have automatic coordination since 2015 and have not have an LHD since. Cuba and the Miami ACC, also have not experiences LHD events between their FIRs after the implementation. Between COCESNA and Merida, one (1) LHD occurred since the implementation of AIDC.

2.2 Current Situation: three prevalent automated data-interchange standards

2.2.1  The three most prevalent applications used to provide automated data interchange between ATM systems are:

  • ATS (air traffic services) inter-facility data communications (AIDC), documented in the ICAO “Pan Regional (NAT and APAC) Interface Control Document for ATS Interfacility Data Communications” (PAN AIDC ICD) (2013);
  • On-line data interchange (OLDI) as described in EUROCONTROL “Specification for On-Line Data Interchange” (2010);
  • The common interface processing protocols detailed in the “North American Common Coordination Interface Control Document” (NAM ICD).

2.2.2  To a different degree, these protocols all support the notification, coordination and the transfer of control functions between ATSUs. The message sets used by each of the processing protocols exhibit some commonality. However, there are differences in the messages used in the communication interaction for message acceptance and in the exchange format and acceptance philosophy. These differences can make automated data exchange impossible, even though both centres have a form of automation in place.

2.2.2.1 Many systems nowadays will allow interface protocols to be tailored to a particular interface. System providers constructing their interface capabilities must take into account the need for scalable requirements and flexibility, as adjacent FIRs will have different ATC systems. AIDC, NAM, and OLDI support the notification, coordination, and the transfer of communications and control functions to different degrees between ATSUs.

2.2.3  The utility of which protocol is best for a particular interface is dependent on the targeted interface environment, surveillance or non-surveillance, and existing or planned adjacent FIR protocols and system capabilities.

2.2.4  PAN AIDC ICD

2.2.4.1 ICAO issued the Pan Regional (NAT and APAC) Interface Control Document (PAN ICD) for ATS Interfacility Data Communications (AIDC) as the result of the progressive evolution of the Asia/Pacific. Both the North Atlantic and the Asia/Pacific Regions had published an Interface Control document, providing guidance on a regional basis. However, in recognition of the need to provide globally harmonized guidance for AIDC, the PAN ICD First Edition, merging the APAC and NAT guidance material, was adopted in September 2014.

2.2.4.2  AIDC has been implemented by many ANSPs worldwide, but it is not seen in offshore and continental areas, nor has it been adopted in Europe. There are different versions in use. ANSPs opt for subsets of messages in line with their operational needs and sign bilateral LOAs accordingly. Basic coordination messages (notification and initial coordination) have been widely implemented. Transfer messages are often combined with estimate (EST) usage in implementation and may be complemented locally with custom messages and fields (radar hand- offs, etc.) in transition areas. Bilateral LOAs should address the subset of messages used and their associated procedures. The messages are conveyed over automated message handling system (AMHS)/internet protocol (IP) or AFTN.

2.2.4.3  The AIDC functionality described in the PAN AIDC ICD provides guidance for messaging and coordination in non-surveillance environments, as is used in oceanic operations. Supplemental capabilities such as automatic dependent surveillance-contract (ADS-C) and controller-pilot data link communications (CPDLC) provide the needed communication and position information needed in many oceanic non-surveillance areas.

2.2.5 OLDI

2.2.5.1  The OLDI system of automated coordination is used by EUROCONTROL ACCs. This specification defines the system requirements to support OLDI and the usage and content of OLDI messages. There are a large number of OLDI message sets defined across the range of functions. The number of these message sets used on an interface is by bilateral agreement between OLDI partners.

2.2.5.2  OLDI messages are exchanged between ATC units to provide for the exchange of coordination details and transfer of control information. Coordination is achieved against predefined coordination points (COP). The basic information consists of the aircraft identification, COP, time, flight level and SSR code. Additional information supported by the message set can be exchanged by agreement.

2.2.5.3  All EUROCONTROL ACCs now have OLDI connections with their adjacent partners, including many centres on the EUROCONTROL area boundary, such as in North Africa. OLDI is also used for internal communication between FIRs or units. The message set has been extended to cover CPDLC and network flow messages.

ATC units use OLDI for the purpose of achieving:

  • The notification of flights
  • The coordination required prior to the transfer of flights from one unit to the next
  • The co-ordination between civil and military ATC
  • Situational awareness
  • The transfer of communication of such flights
  • Support to air-ground data link
  • Coordination between ACCs and oceanic control centres.

2.2.5.4  OLDI and AIDC have very similar message sets for most messages. However, there are some differences between the two protocols. OLDI has a larger message set but does not have an equivalent of the AIDC track definition message (TDM) since Europe relies on the initial flight plan processing system (IFPS), and OLDI has messages for both Future Air Navigation Systems (FANS 1/A) and Aeronautical Telecommunications Network (ATN B1) functions.

2.2.5.5  Despite the OLDI specification, issues can arise where one of the systems on a boundary cannot fully meet the requirement. This can result in problems of valid data being overwritten with incorrect data. This issue is addressed by an interoperability test for all changes. It is planned that the Single European Sky ATM Research (SESAR) systems being deployed will be able to exchange flight objects, which will move transfer of control beyond OLDI. This has the potential to support more flexible boundaries in the knowledge that all parties have the same view of the flight information.

2.2.6 NAM ICD

2.2.6.1  The NAM ICD is mainly used in North-American domestic operations and domestic/oceanic transition areas; often, cross-border operations do not fit neatly into one or the other category.

2.2.6.2  The NAM ICD has automated radar handoff message definitions within the document as a goal of cross-border interoperability evolution. The NAM protocol provides the advantage of extensibility to handoff and point-out functionality, enhancing a positive controlled radar environment.

2.2.6.3  The interface protocol set can provide a contiguous automation infrastructure for ATS within and between adjacent FIRs. The ICD for data communications between ATSUs in the Caribbean and South American regions was modelled from the NAM ICD and originally developed for operational interfaces with the U.S., Canada and Mexico.

2.2.6.3.1The NAM ICD has since been adopted by interfaces between KZMA and MUHF; and between Mexico’s Merida ACC and MUFH. The extension of the common NAM protocol has recently been expanded within the North American, Caribbean and Central American (NACC) Region to include interfaces between MUFH and Central America’s Corporación Centroamericana de Servicios de Navegación Aérea (COCESNA); and between Merida ACC and COCESNA. Several other ANSPs are planning automated data exchange using compatible protocols, which will allow interface connectivity without requiring additional software development. If a new interface requires additional capability development from an existing interface user, the possibility of a seamless upgrade is lessened.

2.2.7 Mixed Environments

2.2.7.1  OLDI has been in operational use for more than twenty years in Europe and for more than four years in the United Arab Emirates. In August 2017, the ICAO Middle East (MID) office, published its regional MID Air Navigational Plan, which contains the following requirement:

2.20 The Inter-Centre Communication (ICC), consisting of ATS Inter-facility Data Communication (AIDC) application and the Online Data Interchange (OLDI) application, should be used for automated exchange of flight data between ATS units to enhance the overall safety of the ATM operation and increase airspace capacity.

(ICAO MID Air Navigation Plan (Doc 9708), MID eANP Volume II, August 2017)

ICAO MID requires states to use both EUROCONTROL OLDI interface and AIDC. Which ICD of AIDC should be used is not specified.

2.2.7.2  The Unites States employ two broad categories of automated data exchange between ATC facilities: internal and external. Many ATM systems, including those in the U.S., use an internal protocol which may be used exclusively between ACCs/sectors within the same ANSP.

2.2.7.2.1  Use of an external protocol is necessary to communicate with a neighbouring FIR or ANSP. The U.S. has used the National Airspace System internal interface protocol between enroute systems and between enroute and terminal systems with fully integrated data exchange including handoff and point-out capabilities. Some North American systems, such as Mexico’s Topsky and the U.S.’ advanced technologies and oceanic procedures (ATOP) system, are able to interface externally with two different adjacent FIRs using different interface protocols such as AIDC and NAM ICD. The implementation of the Oakland (KZOA) ATOP – Vancouver ACC (CZVR) interface is an example of the use of the NAM for interface and cost efficiency.

2.2.7.2.2  In 2015, the U.S. and Canada implemented a NAM interface between the KZOA ATOP and the CZVR Canadian Automated Air Traffic System (CAATS) in a domestic – oceanic transition between the two countries. The implementation was cost-efficient since both had NAM ICD software in their systems for different interfaces, and any other protocol would have come with development, testing and training costs and implementation complexities. A similar interface is being considered for implementation on the North Atlantic boundary between the U.S. New York ACC (KZNY) ATOP and the Canadian Moncton ACC CAATS using the same NAM ICD protocol.

2.2.7.2.3  In 2010, MUFH and KZMA agreed to pursue the NAM interface between the facilities using the multiple U.S. – Mexico interfaces as a model for the Cuba effort. Cuba internally developed the software in accordance with the NAM ICD and was committed to the effort and providing technical proficiency. The interface was implemented in December 2011. By virtue of making the proper planning decisions in the KZMA – MUFH interface, Mexico and Cuba were able to extend their interface efforts by implementing a similar interface between Merida – MUFH only one month later. This was a significant accomplishment for the NACC Region, and one that continues to have increasing benefits. The extension of the NAM interface in 2015 to include COCESNA (Honduras) to MUFH and COCESNA to Mexico’s Merida ACC was assisted by the lessons learned and subject matter knowledge from the implementation of the MUFH – KZMA interface.

2.2.7.2.4  Adjacent airspace with manual surveillance-to-surveillance operations prompted the use of a regionally compatible protocol and the NAM ICD effectively supported that choice. The selected NAM protocol message sets were a scalable solution, allowing the incremental implementation of capabilities and message sets. Additionally, the U.S. had the expertise to assist in the implementation of a NAM ICD based interface, which was already operational with multiple interfaces between the U.S., Canada, and Mexico.

2.3 Differences between AIDC and OLDI

2.3.1 In total, there are 57 possible messages in AIDC and OLDI systems. As mentioned before, there are differences between these messages.

6 out of 57 messages are common to AIDC and OLDI.

37 out of 57 are specific to OLDI, while 14 are specific to AIDC. However, in the specific subset of these 51 specific messages, some functional equivalences exist.

2.3.2 The OLDI ROC (Request Oceanic Clearance) and OCM (Oceanic Clearance Message) are used between oceanic and continental centres. Other OLDI coordination messages are refining the negotiation process, these messages are rarely implemented. The OLDI Transfer of Communications messages (COF, ROF) allow radar hand-offs and bring immediate benefits on safety and workload reduction.

2.3.3

OLDI includes a subset of messages for dialogue between civil and military units.

2.3.4

In AIDC a TDM message used to disseminate track information. Latitude/longitude waypoints or named enroute points allow for User Preferred Routes. There is no equivalent of the AIDC TDM message in OLDI, as the Initial FPL Processing System (IFPS) operated by Eurocontrol distributes initial flight plans as part of the Network function in Europe.

2.3.5

OLDI includes a subset of messages for directing flight coordination information towards third party organizations, such as the provision of Flight information to a military control centre. There are no AIDC messages standardized for flight coordination information towards third party organizations.

2.3.6

A few of the complementary messages are OLDI specific. The COD (SSR code assigned cannot be retained), SCO/SKIP (skip communication/ skipping the accepting sector in the TOC process), PNT (to particularize a flight between ATSUs) and AMA (conveying the target time at the Coordination Point to maintain sequence) are examples for which no equivalent can be found in AIDC.

2.3.7 From this analysis it can be concluded that OLDI has specified many more specific messages, mainly due to radar operation needs and a more refined negotiation process.

2.4 Implementation

2.4.1 ICAO Doc 4444 contains seven so-called ‘regional air navigation agreements’ urging for the implementation of automated coordination. An example:

8.1.6 States should, on the basis of regional air navigation agreements, provide for the automated exchange of coordination data relevant to aircraft being provided with ATS surveillance services, and establish automated coordination procedures.

(ICAO PANS-ATM Doc 4444 16th Edition)

2.4.1.1  These ‘regional air navigation agreements’ mentioned in the example can be found in the ICAO SUPPS (the Regional Supplementary Procedures, DOC 7030).

The ICAO Regional Supplementary Procedures (SUPPS) form the procedural part of the Air Navigation Plans developed by Regional Air Navigation (RAN) Meetings to meet those needs of specific areas which are not covered in the worldwide provisions. They complement the statement of requirements for facilities and services contained in the Air Navigation Plan publications. Procedures of worldwide applicability are included either in the Annexes to the Convention on International Civil Aviation as Standards or Recommended Practices, or in the Procedures for Air Navigation Services (PANS).

(ICAO DOC 7030 Regional Supplementary Procedures, 5th edition, 2008)

2.4.1.2  The Regional Supplementary Procedures specify additional agreements and needs of specific areas, which are not covered in the worldwide provisions. Focussing on Computer-assisted ATS coordination (e.g. automated flight data exchange), it can be concluded that only the European region has the requirement that a computer-assisted coordination process shall be introduced to eliminate the need for verbal communication when so agreed between adjacent ATC units. However, the ICAO SUPPS are only the procedural part of the Regional Air Navigation Plans.

Africa-Indian Ocean (AFI) Regional Supplementary Procedures, Chapter 6. Air Traffic Services, 6.11 ATS Coordination, 6.12.4 Computer-assisted coordination

Nil.

Caribbean (CAR) Regional Supplementary Procedures, Chapter 6. Air Traffic Services, 6.11 ATS Coordination, 6.12.4 Computer-assisted coordination

Nil.

European (EUR) Regional Supplementary Procedures, Chapter 6. Air Traffic Services, 6.11 ATS Coordination, 6.12.4 Computer-assisted coordination, 6.12.4.1 General
6.12.4.1.1 When so agreed between adjacent ATC units, a computer-assisted coordination

process shall be introduced to eliminate the need for verbal coordination of boundary estimates and to reduce the amount of manual data input into ATC computers.

Middle East/Asia (MID/ASIA) Regional Supplementary Procedures, Chapter 6. Air Traffic Services, 6.11 ATS Coordination, 6.12.4 Computer-assisted coordination

Nil.

North America (NAM) Regional Supplementary Procedures, Chapter 6. Air Traffic Services, 6.11 ATS Coordination, 6.12.4 Computer-assisted coordination

Nil.

North Atlantic (NAT) Regional Supplementary Procedures, Chapter 6. Air Traffic Services, 6.11 ATS Coordination, 6.12.4 Computer-assisted coordination

Nil.

Pacific (PAC) Regional Supplementary Procedures, Chapter 6. Air Traffic Services, 6.11 ATS Coordination, 6.12.4 Computer-assisted coordination

Nil.

South American (SAM) Regional Supplementary Procedures, Chapter 6. Air Traffic Services, 6.11 ATS Coordination, 6.12.4 Computer-assisted coordination

Nil.

(ICAO Doc 7030 “Regional Supplementary Procedures” 5th Edition of 2008)

2.4.2 The Regional Air Navigational Plans represent the bridge between, on one hand, the global provisions in the ICAO SARPs and the Global Air Navigation Plan (GANP) (Doc 9750), and on the other hand the States’ air navigation plans and implementation status.

2.4.2.1 In August 2017, the ICAO Middle East (MID) office published its regional MID Air Navigational Plan. The plan contained the requirement that AIDC and OLDI should be used for automated exchange of flight data between ATS units.

2.20 The Inter-Centre Communication (ICC), consisting of ATS Inter-facility Data Communication (AIDC) application and the Online Data Interchange (OLDI) application, should be used for automated exchange of flight data between ATS units to enhance the overall safety of the ATM operation and increase airspace capacity.

(ICAO MID Air Navigation Plan (Doc 9708), MID eANP Volume II, August 2017)

Since then the requirement was also used for EUR, NAT, APAC and the CAR/SAM Regional Air Navigational Plans. ICAO Western and Central African office (WACAF) as well as Eastern and Southern African (ESAF) office have nothing published regarding AIDC.

2.5 The future of data exchange

2.5.1 The ICAO Global Air Navigation Plan (GANP, DOC 9750) aims to implement Globally Interoperable Systems and Data in the future. In the Global Air Navigation Plan, the implementation of the concept of FF-Ice is laid out. In 2015, TOC presented WP86 (FF-ICE) and WP85 (SWIM – Technical and Legal Issues) at the annual conference. More specific information on these concepts can be found in these papers, which can be derived from the IFATCA website conference archive.

2.5.1.1  The ICAO FF-ICE Manual (Doc 9965) describes the following impact on coordination messages:

5.4 IMPACT ON OTHER ATS MESSAGES

5.4.3 Coordination messages will be impacted by changes to the information format, exchange mechanisms, and the flight information process. The Global ATM Operational Concept and associated requirements indicate the need for shared common information. The process by which this information is shared will replace the current coordination messages.

 

2.5.1.2  The ICAO Manual on FF-ICE, also includes information for sharing trajectory based operations within the SWIM concept. According to this manual, the “Globally Interoperable Systems and Data” could be achievable via Pan-Regional Interface or so-called SWIM adaptors.

2.5.1.3  In order to implement this, ICAO proposes the Flight Information Exchange Model (FIXM) as new global standard candidate for flight data exchange. FIXM is a data interchange format for sharing information about flights throughout their lifecycle. It is part of a technological family of independent, harmonized and interoperable information exchange models designed to cover the information needs of air traffic management.

2.5.1.3.1FIXM will consist of a core model and a set of extensions to the core model. Extensions may be defined by particular communities for particular needs. The core model will be restricted to those pieces of flight data that can be globally harmonised. FIXM Operational Data Description (FIXM ODD) defines the concepts of the flight data elements expected to be exchanged using the FIXM standard. It is found that current version 4.1 of FIXM have only ICAO “EST” coordination message replacements, which is far away from any of 3 prevailing coordination standards which FIXM aims to replace by 2030. The current FIXM version does not fulfil ICAO Doc 9694 “Manual of Air Traffic Services Data Link Applications” regarding ATS Interfacility Data Communication.

Conclusions

3.1  Studies have shown that the implementation on Automated Flight Data Exchange has a high impact on minimizing errors in the coordination cycle between adjacent ATC centres.

3.2  Three types of automated data exchange standards are currently used; PAN ICD AIDC, NAM ICD and OLDI. It is region depended which system, or a combination of which systems is being used.

3.3  Regional ICAO offices require states to use both the EUROCONTROL OLDI interface and AIDC. The ICAO Western and Central African office (WACAF) as well as Eastern and Southern African (ESAF) office has nothing published regarding AIDC.

3.4  The ICAO Global Air Navigation Plan (GANP, DOC 9750) aims to implement Globally Interoperable Systems and Data in the future, proposing the Flight Information Exchange Model (FIXM) as new global standard candidate for flight data exchange.

Recommendation

It is recommended that this paper be accepted as information material.

References

ICAO PANS-RAC Doc. 4444 3rd Edition Amendment No. 2 ICAO PANS-RAC Doc. 4444 4th Edition
ICAO PANS-RAC Doc. 4444 9th Edition
ICAO PANS-RAC Doc 4444 12th Edition
ICAO PANS-RAC Doc 4444 13th Edition
ICAO PANS-ATM Doc 4444 15th Edition
ICAO Doc 7030 “Regional Supplementary Procedures”, Fifth Edition, 2008
ICAO Doc 9574, Manual on a 300 m (1 000 ft) Vertical Separation Minimum Between FL 290 and FL 410 Inclusive, First Edition 2010.
ICAO Doc 9694 “Manual of Air Traffic Services Data Link Applications” 1st Edition, 1999
ICAO Doc 9708 MID Air Navigation Plan, MID eANP Volume II, August 2017
ICAO Doc 9750 2016 -2030 Global Air Navigation Plan, Fifth Edition, 2016
ICAO Doc 9937, Operating Procedures and Practices for Regional Monitoring Agencies in Relation to the Use of a 300 m (1 000 ft) Vertical Separation Minimum Between FL 290 and FL 410 Inclusive, Third Edition 2012.
ICAO Doc 9965 Manual on Flight and Flow Information for a Collaborative Environment (FF- ICE), First Edition, 2012
ICAO Doc 10039 Manual on System Wide Information Management (Swim) Concept, Interim Advance Edition, 2015
ICAO Annex 11 “Air Traffic Services”. 14th Edition, July 2016
ICAO FF-ICE leaflet
RASG-PA ESC/29 Meeting, ICAO NACC Regional Office, Mexico City, Mexico, 29 November 2017
Fourth North American, Central American and Caribbean Working Group Meeting (NACC/WG/4), Ottawa, Canada, 24 to 28 March 2014
Fifth North American, Central American and Caribbean Working Group Meeting (NACC/WG/5), Port of Spain, Trinidad and Tobago, 22-26 May 2017
ICAO Asia and Pacific Regions (APAC) Air Navigation Plan, APAC eANP Volume II, August 2018
ICAO Pan Regional (NAT and APAC) Interface Control Document (PAN ICD) for ATS Interfacility Data Communications (AIDC), Version 1.0, September 2014
North American (NAM) Common Coordination Interface Control Document (ICD), NAS –IC – 21009205, Revision E, 15 April 2016
EUROCONTROL Specification for On-Line Data Interchange (OLDI), Edition 4.2, 16 December 2010
FIXM Operational Data Description (FIXM ODD) version 4.1, December 15, 2017, Airservices Australia, DSNA, EUROCONTROL, GCAA UAE, IATA, International Coordinating Council of Aerospace Industries Associations, JCAB, NATS Limited, NAV CANADA, SESAR Joint Undertaking & US FAA

ATTACHMENT 1 – Interoperability between different Flight Data Exchange Systems – History of automated coordination

It is a standard procedure that the passage of each flight across the boundary of the areas of responsibility of two units is coordinated between them before transfer and that the flight is transferred when it is at or before the said boundary. Where coordination is carried out by telephone, the passing of data of individual flights as part of the coordination process is a major support task at ATC units. Automated data exchange has been being evolved since mid 20th century, and developments are still ongoing.

ICAO developments of flight plan data automation

On 3 November 1948 ICAO approved PANS-RAC Doc.4444 3rd Edition Amendment 2, which includes six ATC Messages standards:

  • Flight Plan Message;
    Delay Message;
    Cancellation Message; Departure Message;
    Arrival Message;
    Transfer of Control message.

An interesting fact is that a Transfer of Control message had to be used for transferring calculated estimates, using the CTL abbreviation to identify the type of message.

(ICAO PANS-RAC DOC 4444 3rd Edition Amendment No. 2)

In 1951, ICAO changed the Transfer of Control message type identification to TFR. The CTL identification was from then on used for Other air traffic services messages.

(ICAO PANS-RAC Doc. 4444 4th Edition)

In 1968, the 9th Edition of Doc 4444 has been published by ICAO. The transfer of control messages were revoked and a new message types were introduced as Flight Plan Amendment and Coordination messages (Chapter VIII):

  • Boundary Estimate (EST) messages;
  • Acceptance (ACP) messages;
  • Co-ordination (CDN) messages

These messages are still valid.

Boundary estimate (EST) messages

3.2.3.5.1 Where the step-by-step mode of operation (see 3.2.2.2.1) is not used, and flight plan information is provided to successive ATS units by an FPL message, a boundary estimate message shall be transmitted from each transferring air traffic services unit. Each such message is to be transmitted in sufficient time to permit the air traffic services unit concerned to receive the information at least thirty (30) minutes before the time at which the aircraft is estimated to pass the boundary point or other agreed point at which it comes under the control of such unit, unless another period of time has been agreed between the units concerned. This procedure shall apply whether or not the ATS unit responsible for origination of the message has assumed control of, or established contact with, the aircraft by the time the transmission is to be effected.

Acceptance (ACP) messages

3.2.3.7.1 When the data contained in a CPL message or a CHG message are found to be acceptable to the accepting air traffic control unit, such unit shall transmit an acceptance message to the originator of the message received unless special arrangements have been made in accordance with Part VII, 3.2.5.

Co-ordination (CDN) messages

3.2.3.8.1 When an accepting air traffic control unit wishes to propose a change to any of the data contained in a flight plan message or a CHG message which has been received, such unit shall transmit a co-ordination message to the originator of the message received. Normally, however, when a change is proposed with respect to a CHG message, use shall be made of direct-speech communications to be followed, if applicable, by a new CHG message from the transferring to the accepting unit.

3.2.6.1.1 The following messages are prescribed for use as necessary to effect transfer of control between air traffic control units:

(a) modification (CHG) messages;
(b) co-ordination (CDN) messages;
(c) acceptance (ACP) messages;
(d) non-radar transfer of control (TNR) messages; (e) radar transfer of control (TRA) messages;
(f) radar blip identification (RBI) messages;
(g) assumption of control (AOC) messages;
(h) request radar blip identification (RAR) messages.

3.2.6.1.2 When automatic ATC data-processing equipment is not used for message interchanges between air traffic control units, an appropriate selection of the messages given in 3.2.6.1.1 shall be transmitted.

3.2.6.1.3 When automatic data-processing equipment is used for message interchanges between ATC units, all transfer. of control messages listed in 3.2.6.1.1 shall be transmitted, as applicable.

(ICAO PANS-RAC Doc 4444 9th Edition)

The “Guidance Material on the Application of Automation In ATC” was included in this edition of DOC4443, discussing Radar Data and Flight Plan Data automation systems as well as proposing “The marriage of the two systems” into one, pushing for automated data exchange.

It was 16 years later before ICAO defined messages which are to be exchanged by computers only. In June 1984 ICAO defined Logical acknowledgment (LAM) messages in the 12th edition of DOC 4444:

4.2.3.6 Logical acknowledgment (LAM) messages.

4.2.3.6.1 An LAM message shall be used only between ATC computers.

4.2.3.6.2 An ATC computer shall transmit an LAM message in response to a CPL or EST or other appropriate message which is received and processed up to the point where the operational content will be received by the appropriate controller.

4.2.3.6.3 The transferring centre shall set an appropriate reaction time parameter when the CPL or EST message is transmitted. If the LAM message is not received within the parameter time, an operational warning shall be initiated and reversion to telephone and manual mode shall ensue.

 

In the 13th edition of DOC4444, which was published by ICAO in 1998, more data interchange usage was defined.

In 1999, the ICAO Doc 9694 “Manual of Air Traffic Services Data Link Applications” has been published for the first time. This manual contained guidance material concerning the operational use of so-called AIDC messages.

Air traffic services interfacility data communication (AIDC). A data link application that provides the capability to exchange data between air traffic service units during the notification, coordination and transfer of aircraft between flight information regions.

(AIDC definition, ICAO Doc 9694)

In June 2007, ICAO published the 15th edition of DOC 4444. Chapter 11 of this version describes definitions and procedures for ATS interfacility data communications (AIDC) coordination between ATS centers. Appendix 6 described the meaning and use of the AIDC messages.

11.4.2.5 AIDC MESSAGES (APPENDIX 6 REFERS) 11.4.2.5.1 AIDC messages comprise:

— Notify messages (11.4.2.5.3)
— Coordinate Initial messages (11.4.2.5.4)
— Coordinate Negotiate messages (11.4.2.5.5)
— Coordinate Accept messages (11.4.2.5.6)
— Coordinate Reject messages (11.4.2.5.7)

— Coordinate Cancel messages (11.4.2.5.8)
— Coordinate Update messages (11.4.2.5.9)
— Coordinate Standby messages (11.4.2.5.10)
— Transfer Initiate messages (11.4.2.5.11)
— Transfer Conditions Proposal messages (11.4.2.5.12)
— Transfer Conditions Accept messages (11.4.2.5.13)
— Transfer Communication Request messages (11.4.2.5.14)
— Transfer Communication messages (11.4.2.5.15)

— Transfer Communication Assume messages (11.4.2.5.16)
— Transfer Control messages (11.4.2.5.17)

— Transfer Control Assume messages (11.4.2.5.18)
— General Point messages (11.4.2.5.19)
— General Executive Data messages (11.4.2.5.20)
— Free Text Emergency messages (11.4.1.4)
— Free Text General messages (11.4.2.5.21)
— Application Accept messages (11.4.2.5.22)
— Application Reject messages (11.4.2.5.23).

11.4.2.5.2 The requirements with regard to the selection of AIDC messages and the associated procedures should be established on the basis of regional air navigation agreements in order to facilitate the harmonization of ATS in adjacent airspaces.

Note.— While the implementation of AIDC messages is intended to automate the ATC coordination process and minimize the requirement for voice coordination, it is not a complete replacement for voice, especially when a flight is in close proximity to the boundary with an adjoining unit.

 

Automated data exchange world wide

Europe

The operational use of connections between Flight Data Processing Systems (FDPSs) at ACCs for the purpose of replacing verbal estimates – referred to as On-Line Data Interchange (OLDI) – began within Europe in the early nineteen eighties. Common rules and message formats were elaborated and agreed by the agencies concerned and were incorporated in Edition 1 of the EUROCONTROL first released On-Line Data Interchange (OLDI) standard (Eurocontrol Specification for OLDI Edition 4.2, December 1992)

Electronic coordination using a limited number of OLDI messages for notification, coordination and transfer of flights became mandatory in EU with effect from 31 DEC 2012, after a European Commission Implementing Rule.

North Atlantic

North Atlantic region had developed its own ICD (NAT Doc 002); the North Atlantic Common Coordination Interface Control Document, with the latest version (v1.2.8) dating from December 2010.
Soon after, this document evolved into the Pan Regional Interface Control Document (PAN ICD) for ATS Interfacility Data Communications (AIDC), which is the harmonized version of the NAT and APAC ICDs.

Asia/Pacific

The ASIA/PAC Air Navigation Planning and Implementation Regional Group (APANPIRG), at its fifth meeting in 1994, undertook the task of developing the interfacility message exchanges needed to support automation in the regions. In September 2002, the decision was made to reconvene the AIDC Task Force to review and update the ASIA/PAC AIDC Interface Control Document (ICD). The last version of the Asia/Pacific Regional ICD for AIDC was adopted in September 2007. Soon after, it evolved to the Pan Regional Interface Control Document (PAN ICD) for ATS Interfacility Data Communications (AIDC), which is the harmonized version of the NAT and APAC ICDs.

North and South America

Within the North American Aviation Trilateral agreement (NAAT), Canada, Mexico, and the United States agreed to cooperate on development of a seamless interface between automation systems. They are focusing on the automated exchange of ICAO flight data and the achieve of cross-border automation. As a result, the first North American Common Coordination Interface Control Document (NAM ICD) was approved in March 2002, whose current valid version is Revision E, dated April 15, 2016.

An Interface Control Document for Data Communications Between ATS Units in The Caribbean and South American Regions” (CAR/SAM ICD) was published by ICAO CAR/SAM office in the 13 November 2006.

In October 2011, the FAA at Miami ARTCC (KZMA) and the Instituto de Aeronáutica Civil de Cuba (IACC) Havana ACC successfully implemented an automation interface between the two air traffic control facilities, modeled after the U.S.-Mexico Class 1 cross border interface. In March 2012, building on the foundation of automated data exchange between Miami and Havana, SENEAM and the IACC implemented a NAM interface between Merida and Havana. The interfaces extended the automation compatibility of the North American region well into the Caribbean and the Gulf of Mexico and also laid the foundation for eventual interconnection between adjacent member states automation systems.

It was decided that the NAM ICD be adopted as the preferred ICD in the Caribean region, not precluding the use of other ICDs under circumstances favorable to the latter. Dominican Republic and COCESNA are implementing AIDC using the NAM ICD.

Last Update: October 2, 2020  

November 10, 2019   1992   Jean-Francois Lepage    2019    

Comments are closed.


  • Search Knowledgebase