civil air navigation services organisation
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
Acknowledgements This publication was produced by the Flight Information Region Boundary Crossing Task Force of CANSO’s Operations Standing Committee. CANSO would like to thank Jorge Chades, Federal Aviation Administration, Ajay Joshi, Airports Authority of India; Rick Hunter and Dirk Taylor, Airservices Australia; Kapri Kupper, CANSO; Dan Eaves and Vincent McMenamy, Federal Aviation Administration; Carole Stewart, NAV CANADA; Craig Roberts, Thales; and Ashley Lalman, Trinidad and Tobago Civil Aviation Authority. We also acknowledge the valuable contributions by other CANSO Members and Embry Riddle Aeronautical University.
Š Copyright CANSO 2016 All rights reserved. No part of this publication may be reproduced, or transmitted in any form, without the prior permission of CANSO. This paper is for information purposes only. While every effort has been made to ensure the quality and accuracy of information in this publication, it is made available without any warranty of any kind. canso.org
Published June 2016
Contents
3
Acknowledgements_______________________________________________________________________page 2 Executive Summary______________________________________________________________________ page 4 Introduction______________________________________________________________________________page 5 1 Safety and Efficiency Benefits from Automated Data Exchange___________________________page 6
1.1 Steps Involved in Manual Coordination ________________________________________________ page 7
2 Relationship to ICAO ASBU Framework _________________________________________________ page 10 3 Implementation Opportunities _________________________________________________________page 12
3.1 Increasing Safety through Accurate Flight Plan Information _______________________________ page 12
3.2 Changing the ATS in the FIR Boundary Area ____________________________________________ page 12
3.3 Making Changes to the Flight Data Processing System __________________________________ page 12
4 Interface Options and Considerations ___________________________________________________ page 13 4.1 Overview _________________________________________________________________________page 13 4.1.1 AIDC Automation Benefits ______________________________________________________ page 14 4.2 Automated Interface and Protocols ___________________________________________________ page 14 4.2.1 AIDC __________________________________________________________________________ page 14
4.2.1.1 AIDC in Airservices Australia’s Airspace __________________________________________ page 16
4.2.2 OLDI ________________________________________________________________________ page 17 4.2.3 NAM-ICD ___________________________________________________________________ page 18 4.3 Mixed Environments _______________________________________________________________page 19 4.4 Considerations ____________________________________________________________________page 20 4.5 CPDLC and ADS-C Operations ______________________________________________________page 21 5 Implementation Planning _______________________________________________________________ page 24 5.1 Interface/System Implementation Planning ____________________________________________ page 24 5.2 Stakeholders ______________________________________________________________________page 25 5.3 Gap Analysis ______________________________________________________________________page 26 5.4 Task Analysis ______________________________________________________________________page 26 5.5 System Requirements ______________________________________________________________page 27 5.6 Standards _________________________________________________________________________ page 28 5.7 Assessing Possible Solutions _________________________________________________________ page 29 5.8 Implementation Lessons Learned ____________________________________________________page 30 5.9 Adaptability _______________________________________________________________________ page 31 6 Related Considerations ________________________________________________________________ page 33 6.1 Safety Management_________________________________________________________________ page 33 6.1.1 Recommended Action Plan ______________________________________________________ page 33 6.2 Contingency Procedures ____________________________________________________________ page 34 6.3 Opportunities for ATS Enhancements _________________________________________________ page 34 6.4 Inter-Unit Agreements ______________________________________________________________ page 34 7 Conclusions and Recommendations _____________________________________________________ page 36 References ______________________________________________________________________________page 37 Appendices ________________________________________________________________________________ page 38 Acronyms ________________________________________________________________________________ page 52
4
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
Executive Summary CANSO Member ANSPs identified that safety and efficiency in crossing flight information region (FIR) boundaries are hindered by disparities in separation standards; procedures in filing flight-plans; air traffic flow management (ATFM) measures; pilot-to-controller and controllerto-controller communication capabilities; incompatibilities between adjacent automation platforms; and inconsistent airspace structures. This CANSO Automation Interface Between Flight Information Regions: Best Practice Guide for ANSPs recommends establishing best practices that will provide a basic framework for achieving a technically and procedurally interoperable system as it relates to airspace users transitioning between FIRs. This Guide will assist individual ANSPs to collaborate with neighbouring ANSPs and stakeholders to identify where non-compatible automation platforms exist, enhance existing cross boundary interfaces, and support interoperability and complementary implementations. The automated exchange of flight data contributes to safe and efficient FIR boundary crossing operations. This Guide will help ANSPs facilitate the reduction or elimination of factors that contribute to operational inefficiencies such as read-back / hear-back errors, missed coordination and flight progress updates. It will significantly reduce the amount of manual coordination required by ATCOs for aircraft to cross FIR boundaries seamlessly. Automated data exchange is integral to achieving all of the benefits foreseen in the ICAO ASBU FICE (Flight and Flow Information for a Collaborative Environment) Modules. The recommendations are aligned with and complement guidance material provided by ICAO. Creating and instituting seamless FIR boundary crossings is an important task with
critical implications for both safety and efficiency. ANSPs that coordinate flight data manually should consider concurrently implementing automated data exchange (ADE) with neighbouring ANSPs to achieve the benefits derived from automated cross boundary air traffic operations. As ANSPs gain experience, they should share knowledge and lessons learned to move toward a safer, technologically and procedurally interoperable ATM system that delivers a truly seamless airspace.
5
Introduction The Civil Air Navigation Services Organisation (CANSO) vision is to transform air traffic management (ATM) performance globally by creating seamless airspace worldwide. A key objective of this vision is the harmonisation of airspace to enable seamless navigation across the globe. The purpose of this CANSO Guide, as well as the Guide to Seamless Airspace (2013), and the Best Practice Guide to Crossing Flight Information Region Boundaries (2015), is to assist air navigation service providers (ANSP) deliver services seamlessly across flight information region (FIR) boundaries. CANSO has identified that efficiency in crossing FIR boundaries is currently impacted by disparities in: separation standards, procedures in filing flight-plans, air traffic flow management (ATFM) measures, pilot-to-controller and controllerto-controller communication capabilities, lack of automated connectivity between adjacent ANSP facilities, and inconsistent airspace configurations and designations. This Guide addresses disparities and, in some instances, the lack of automated connectivity between adjacent ANSPs. It provides best practices that address the negative impacts resulting from air traffic controllers (ATCO) having to manually coordinate aircraft boundary estimates, flight levels, and other pertinent flight plan data verbally (via landline) to adjacent air traffic services units (ATSU). Verbal coordination increases workload levels for both the initiating and receiving ATSUs, since ATCOS must manually record the transmitted data on flight progress strips, and/or make computer entries to update flight plan processing systems. This manual coordination introduces risk as it can lead to disparities in information. Additionally, the steps that ATCOs must take for each flight decreases the amount of time available to the ATCO for scanning surveillance displays, issuing clearances and advisories, and ensuring that potential traffic conflicts are resolved.
The Guide is intended to help ANSPs facilitate the reduction, or elimination, of factors that contribute to operational inefficiencies, and the loss of required separation standards as aircraft cross FIR boundaries. The Guide focuses on improving the coordination of flight plan data across FIR boundaries by establishing best practices that will help ANSPs use automated methods. It covers the benefits and the relationship of this process to the International Civil Aviation Organization (ICAO) Aviation System Block Upgrades (ASBU) framework. It also outlines opportunities for interfacing, modifying, or enhancing existing automation systems in an effort to improve the automated exchange of flight plan data between neighbouring ATSUs. The document provides examples of varying interface options, and associated benefits derived, such as those implemented successfully in Europe, North America, and Asia Pacific. Additionally, it covers guidance and recommendations on implementation planning and related considerations, which will help ANSPs identify the necessary steps for successful automation interface, and develop a suitable action plan to achieve it. This Guide is intended to complement guidance material that is provided by ICAO, the International Air Transport Association (IATA), and Airports Council International (ACI).
6
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
1 Safety and Efficiency Benefits from Automated Data Exchange When ANSPs assessed the results from successful implementation of automation systems that interface with adjacent ATSUs, it was clear, from feedback by ATCOs, that the benefits gained were significant. Transitioning from manual coordination to automated data exchange significantly enhances safety and efficiency. The benefits are summarised in Table 1 below. The three most prevalent applications used to provide ADE 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 as described in EUROCONTROL Specification for On-Line Data Interchange (OLDI) (2010); and the common interface processing protocols detailed in the North American (NAM) Common Coordination Interface Control Document (ICD). The three applications; AIDC, OLDI and NAM, all utilise the flight data exchange model described in ICAO Document 4444, Procedures for Air Navigation Services: Air Traffic Management, (PANS-ATM) which is defined as three phases (see page 13 for further details): —— Notification —— Coordination —— Transfer of Control
Improved capacity
Reduced ATCO workload and increased data integrity supports reduced separation. This translates directly to cross sector or boundary capacity flow increases.
Increased efficiency
The reduced separation can also be used to more frequently offer aircraft flight levels closer to the flight optimum; in certain cases, this also translates into reduced en-route holding.
Improved global interoperability
The use of standardised interfaces reduces the cost of development, allows ATCOs to apply the same procedures at the boundaries of all participating centres and border crossing becomes more transparent to flights.
Enhanced safety
Greater accuracy of flight plan information enhances the ATCO’s ability to tactically plan for and properly control the flight.
Improved Cost Benefit
Increase of throughput at ATSU boundary and reduced ATCO workload will outweigh the cost of FDPS software changes. The business case is dependent on the environment.
Table 1. AIDC Summary of Benefits Table: ICAO Document 9750 Global Air Navigation Plan 2013-2028
7
Figure 1. Flight data exchange between ATSUs using AIDC.
The automated exchange of flight data facilitates quick and accurate exchange of information and delivers safety and efficiency benefits for ANSPs and aircraft operators. The major benefits are: —— Reduced workload for ATCOs —— Reduction of read-back and hear-back errors due manual coordination —— Reduction of gross navigational errors and large height deviations which may have occurred due to ATCO-to-ATCO coordination errors —— Facilitation of operational initiatives such as user preferred routes (UPR) and dynamic airborne reroute procedure (DARP). Automated data exchange is no longer only a desirable feature but is now becoming a necessity where the separation minima between flights are reduced and flight paths are becoming more flexible and user-centric. The seamless transition of flights across FIR boundaries with reduced lateral and longitudinal separation and flight paths like flex tracks, UPRs, DARPs require quick and accurate exchange of data across FIR boundaries. This is best achieved through automated exchange of flight data rather than manual coordination because: —— Coordination can be achieved in fewer
steps and is almost instantaneous —— There is more consistency and certainty in automated data exchange —— Automated data exchange may allow the system to perform handoffs electronically, thus eliminating the need to coordinate handoffs manually 1.1
Steps Involved in Manual Coordination In an en route environment, sectors may be staffed by up to three separate positions. The nomenclature for these positions varies by region/ ATSU, but for the purposes of this guidance, they will be referred to as executive controller, planning controller, and coordinator. —— The executive controller handles air to ground communications, provides weather information, gives traffic advisories, and issues clearances to flights. The executive controller requires a high level of situational awareness of flight path, flight levels, sector saturation, and flight time estimates —— The planning controller monitors the frequency and, in coordination with the executive controller, plans for profiles of the flights at the transfer of control point (TCP)
8
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
—— The coordinator performs intra-facility and inter-facility coordination. In the case of manual coordination, when data such as the estimated time and flight level at the TCP have been confirmed by the executive and planning controller, the coordinator takes necessary steps to coordinate this data with other ATCOs via voice. The coordinator at the receiving end manually inputs the flight data
Manual Coordination
(not necessarily directly) into the ATM automations system. The majority of tasks in ADE applications are performed by the ATM systems. In contrast, manual coordination requires human input at every step. The steps required in manual coordination take more time than that of ADE. Figure 2 contrasts the differences between manual and ADE:
Automated Data Exchange
Figure 2. Illustrates an example of steps utilised by ATCOs to effect successful manual coordination and in contrast, the steps initiated to effect successful automated exchange.
9
The chances of errors are thus less in automated flight data exchange and the integrity of data is higher. The list of possible errors in each case is given below. Other than reducing errors and thus improving safety, the ADE applications like OLDI and AIDC also help improve efficiency through quicker coordination. The data exchange is nearly instantaneous as the messages are exchanged through aeronautical fixed telecommunications network (AFTN) based on message priority. Whereas, in manual coordination, the process requires much more time due to factors such as engaged telephone lines, ATCOs being busy with other tasks, typing or writing of data etc.
Moreover, in ADE processes the originating ATM system can effect coordination with multiple receiving systems simultaneously. Applications like AIDC and OLDI relieve the coordinators of the work intensive manual tasks and leave only some ancillary tasks for the coordinators to perform; thus reducing the requirement of human resources. If a FIR with four sectors required four coordinators, through automation, this might be reduced one to two coordinator positions. When quicker and more accurate automated data is exchanged, ATCOs are able to increase situational awareness, reduce workload, and thus ensure a safer and more efficient operation.
Possible Errors in Manual Coordination
Possible Errors in ADE
Wrong update in the system at transmitting end
Wrong update in the system
Flight plan error
Flight plan error
Error in reading/transmitting the data
N/A
Error in receiving/hearing the data
N/A
Error in noting down the data
N/A
Wrong update in the system at receiving end
N/A
Table 2. Potential errors associated with manual and automated coordination.
10
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
2 Relationship to ICAO ASBU Framework ICAO has provided the industry with a capabilities and readiness perspective and planning framework. The ASBU framework is comprised of modules, which have been arranged by availability dates; Block 0 ASBU Modules are capabilities available today while Block 1 represents capabilities that are projected to be ready by 2018. Block 2 capabilities are projected to be available in 2023 and Block 3 capabilities in 2028. The ASBU planning framework supports coordinated planning and development of technology, associated procedures to make use of the technology, and the regulatory requirements for standardisation, certification, approvals and authorisations. The ASBU framework is described in the Global Air Navigation Plan (GANP, ICAO Doc 9750). The main focus of the ASBU framework is on seamlessness and interoperability and coordinated implementation of improvements to the aviation system by States, regions, ANSPs and aircraft operators. The aviation system improvements addressed by the ASBU framework are organised into four Performance
Thread
general performance improvement areas (PIAs): PIA 1 Airport Operations PIA 2 Globally Interoperable Systems and Data PIA 3 Optimum Capacity and Flexible Flights PIA 4 Efficient Flight Paths Each PIA includes a number of threads, each of which represents a specific type of improvement as it transitions through the capabilities available in each Block. There are 21 threads in total, and each ASBU module is categorised according to its applicable thread and the block during which it will be available. Automated flight data exchange is referenced in threads in PIA 2 and PIA 4. Additionally, accurate and efficient handling of flight data is necessary to achieve the maximum benefits in most of the threads that make up PIA 3. The following chart details the correlation between automation of ANSPs’ flight data processing and exchanges and achieving the aviation system improvements that make up the ASBU framework.
Module(s)
Improvement
Relation to Automation of ANSP Flight Data Processing and Exchanges
Area PIA 2: Globally
Flight and Flow
B0-FICE: Increased Interoperability, Efficiency and
All FICE Modules involve automated
Interoperable
Information for
Capacity through Ground-Ground Integration
flight data exchange
Systems and Data
a Collaborative
B1-FICE: Increased Interoperability, Efficiency and
� Through Globally
Environment (FF
Capacity though FF ICE, Step 1 application before
Interoperable
ICE)
Departure
System Wide
B2-FICE: Improved Coordination through Multi-
Information
centre Ground-Ground Integration (FF ICE, Step 1
Management
and Flight Object, SWIM) B3-FICE: Improved Operational Performance through the Introduction of Full FF ICE System-Wide
B1-SWIM: Performance Improvement through
ANSP participation in, and benefits
Information
the application of SWIM
from, SWIM applications is not possible
Management
B2-SWIM: Enabling Airborne Participation in
without automation of flight data
(SWIM)
Collaborative ATM through SWIM
exchange processes. If ANSPs are not able to participate in SWIM the benefits to other stakeholders (i.e. airport operators, aircraft operators, adjacent ANSPs) will be reduced.
11
Performance
Thread
Module(s)
Improvement
Relation to Automation of ANSP Flight Data Processing and Exchanges
Area PIA 3: Optimum
Network
B0-NOPS: Improved Flow Performance through
ANSP participation in, and benefits
Capacity and
Operations
Planning based on a Network Wide view
from, a network-wide view will be less
Flexible Flights –
B1-NOPS: Enhanced Flow Performance through
possible without automation of flight
Through Global
Network Operational Planning
data exchange.
Collaborative ATM
B2-NOPS: Increased user involvement in the dynamic utilization of the Network
If ANSPs are not able to fully participate
B3-NOPS: Traffic Complexity Management
in network operations the benefits to other stakeholders (i.e. airport operators, aircraft operators, adjacent ANSPs) will be reduced.
PIA 4: Efficient
Continuous
B0-CCO: Improved Flexibility and Efficiency in
Automated processing of flight data
Flight Path
Climb
Departure Profiles - Continuous Climb Operations
enhances the ability for ANSPs to
– Through
Operations
(CCO)
extract aircraft capabilities from the
Trajectory‐based
flight plan to facilitate performance-
Operations
based operations. Automated flight data exchanges ensure that complete flight data, including all aircraft capabilities, are provided to subsequent ANSPs. Continuous
B0-CDO: Improved Flexibility and Efficiency in
Descent
Descent Profiles (CDO)
If an ANSP does not forward all flight
Operations
B1-CDO: Improved Flexibility and Efficiency in
data to downstream ANSPs that support
Descent Profiles (CDOs) using VNAV
performance-based operations, they
B2-CDO: Improved Flexibility and Efficiency in
and aircraft operators may not benefit
Continuous Descent Profiles (CDOs) Using VNAV,
from their investments in supporting
required speed and time at arrival
technology and avionics.
Trajectory-Based
B0-TBO: Improved Safety and Efficiency through
Operations
the initial application of Data Link En-Route B1-TBO: Improved Traffic Synchronization and Initial Trajectory-Based Operation B3-TBO: Full 4D Trajectory-based Operations
Table 3. Relationship between automation data exchange and the ASBU framework.
12
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
3 Implementation Opportunities There are many circumstances that create opportunities to implement, modify, or enhance ADE between neighbouring ANSPs. Examples of the circumstances include changing the ATS being provided in the FIR boundary area and replacing or modifying a flight data processing system. Safety concerns can drive the change to an existing system. 3.1 Increase Safety through Accurate Flight Plan Information: The actual, or potential, root causes of operational errors should be identified as the result of an ANSP’s safety management system (SMS). A record of potential hazards provides an opportunity to develop mitigations to the specific issues being encountered during the exchange of flight data between ANSPs. Such information can identify safety benefits that could be realised by automating flight data exchanges. It can also aid in identifying areas where existing automation needs to be enhanced. SMS data often contributes to efficiency assessments, delineating the time and resources required to identify and correct errors, or to prevent errors from occurring when there are known weaknesses in the data exchange processes. ANSPs need to be aware that data exchange issues, or practices, at one interface may affect subsequent interfaces. Awareness of how this may affect other ANSPs and/or interfaces needs to be maintained throughout the change process. To ensure the implementations remains on track, each change should be benchmarked against the safety case and the mitigations contained within it. 3.2
Changing the ATS in the FIR Boundary Area When the services provided to flights within an airspace volume are being changed, ANSPs will often begin making operational use of flight data that previously was not relevant. One example is
the introduction of performance-based operations that necessitates the knowledge of a flight’s performance-based navigation (PBN) status and specific equipage. In such cases, ANSPs may need to change the methods used to exchange data to ensure that the required data is being provided correctly and at the required time. They may also need to implement new processes to ensure that updates to a flight’s equipage status, as indicated in the flight plan, are passed on. ATS changes may also require changes to the flight data that should be exchanged. For example, if ATS surveillance services are being introduced, the ANSPs would need to exchange more precise estimate data, including updates, to enable automated handoffs or identification of the flight by the receiving ANSP. 3.3 Making Changes to the Flight Data Processing System The most obvious opportunity to implement or enhance the automation of ADE occurs when changes are being made to the flight data processing system (FDPS) itself. It is at this time that all factors need to be considered to determine which direction the ANSP may take for the system change (e.g. field a new system, upgrade current system, change current system parameters, etc.). This is a critical step in the evolution of an ANSP’s flight data processing/exchange lifecycle. It is here that the safety, business, and operation benefits cases are developed. This is the time that coordination with other ANSPs begins to take place to determine interface requirements and the development of new Letters of Agreement (LOA) practices and contents.
13
4 Interface Options and Considerations Overview In pursuing the goal of seamless automation, safety and efficiency interests extend beyond the borders of our airspace and systems. Traffic flows and transition between oceanic, en route and terminal airspace are factors that should be included as system and capability selection factors. This Guide is one source of information to aid in the analysis of individual ANSP situations and temper decisions with those lessons already learned locally and internationally to formulate an ‘executable’ interface strategy for successful implementation of automated data exchange (ADE).
coordination of boundary-crossing conditions, and transfer of control.”
4.1
Increasing traffic between FIRs drives the need to improve the efficiency and accuracy of information being exchanged between ATSUs. Developing a harmonised process, and defining protocols for exchanging cross-border data between multiple States, territories, and / or international organisations within, and across, regions is critical to achieving efficiency through automation. The following information is provided to show the type of current, and near term, ADE initiatives that either have, or are expected to, evolve into successful interfaces. An automated communications and data interchange infrastructure significantly reduces the need for verbal coordination from ATSUs. AIDC, or similar automation, provides the means to harmonise ADE between ATSUs providing ATS in adjacent FIRs controlled by different ANSPs. As stated in ICAO Document (Doc) 9464, Manual of Air Traffic Services Data Link Applications, (paragraph 8.2): “The AIDC application exchanges information between ATSUs in support of critical air traffic control (ATC) functions, including notification of flights approaching an FIR boundary,
Support for bilateral solutions and stakeholder collaboration is essential to ensure automation compatibility is maintained as interface systems evolve. Solutions must provide extensible system compatibility across all airspace boundaries. An interface consists of a defined set of messages, which describe consistent transfer conditions using electronic means across ATSU boundaries. The interface requires the implementation of the AIDC message set in the flight data processing systems of all the involved ATSUs, and the establishment of LOAs between these units, which establishes the appropriate parameters. Our collective ability to effectively integrate new technologies reduces the time required for ATCO tasks rather than simply increasing the number of tasks required of them. A communications and data interchange infrastructure significantly reduces the need for verbal coordination between ATSUs delivering more efficient and safer air traffic services. ICAO Doc 9464 Manual of Air Traffic Services Data Link Applications (paragraph 8.3) defines the following: “AIDC defines messages which are related to three phases of coordination as perceived by an ATSU: —— Notify Phase, in which the aircraft trajectory and any changes may be conveyed to an ATSU from the current ATSU prior to coordination; —— Coordinate phase, in which the aircraft trajectory is coordinated between two or more ATSUs when the flight approaches a common boundary; and —— Transfer phase, in which communications and executive control authority is transferred from one ATSU to another.” When flights that are being provided with air traffic services are transferred from one ATSU to the next via automation, safety is enhanced. It
14
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
is standard procedure to coordinate and transfer control of each flight prior, at, or adjacent to, the FIR boundary as appropriate to the defined procedures. The impetus to change automation requirements stems from the increasing traffic levels transiting between FIRs, and many regions upgrading automation systems. ATS AIDC and North American (NAM) Common Coordination Interface Control Document (ICD), provide the protocol by which ADE messages can be exchanged and harmonised between ATSUs and ANSPs. 4.1.1 AIDC Automation Benefits Our customers’ safety and efficiency interests extend beyond the borders of individual airspace systems. Operational efficiencies and improved services gained through automation should be contiguous to the extent possible, as aircraft travel across FIR boundaries into other regions. These efficiencies and improved services include a reduced workload for ATCOs, and a reduction of the potential for read-back/hear-back errors and controller-to-controller coordination errors (including language barrier issues) experienced during manual coordination. The ADE may allow the system to perform handoffs electronically, thus eliminating the need to coordinate handoffs manually. Future benefits may include automated handling of complex routing and PBN capabilities imbedded in current flight data profiles. Integration of automation with PBN initiatives and emerging PBN technologies requires planning and collaboration with adjacent ANSPs. As aircraft operators invest in new aircraft technology, they expect compatibility with the systems and procedures used by ANSPs. Ideally, users would prefer to use the same technology to garner safety and efficiency gains across contiguous ANSPs and ensure continuity of service. Standardisation of communication, navigation and surveillance (CNS)/ATM technologies and
procedures is critical to cross-border, regional, and multi-regional interoperability. Such technical and operational compatibility can take many forms, depending on the target technology or procedure. 4.2
Automated Interface and Protocols Cross-border automation between FIRs has three different processing protocols; AIDC, OLDI, and the protocol defined in the NAM ICD. It can be confusing when the protocols that support primarily surveillance-based environments, such as OLDI and the NAM ICD, are also grouped along with the AIDC protocol within the AIDC category. These protocols all support the notification, coordination and the transfer of control functions to different degrees 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. The utility of which protocol is best for a particular interface is dependent on the targeted interface environment, surveillance or nonsurveillance, and existing or planned adjacent FIR protocols and system capabilities.
4.2.1 AIDC 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; for example, the North Atlantic and Asia Pacific regions have developed the PAN AIDC ICD. 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. Some of the operational benefits to AIDC include a reduction in coordination failures and human errors, and a reduction in telephone calls, allowing flight
Source: Federal Aviation Administration
15
Figure 3. U.S. International Interfaces data operators the time to prioritise work. 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. The AIDC functionality described in the PAN AIDC ICD provides guidance for messaging
in non-surveillance environments, coordination and system non-surveillance functionality as is used in oceanic operations. Supplemental capabilities such as automatic dependent surveillancecontract (ADS-C) and controller-pilot data link communications (CPDLC) provide the needed communication and position information needed in many oceanic non-surveillance areas.
United States Flight Information Region Boundary Crossings Neighboring FIR
CY 2012
CY 2013
CY 2014
CY 2015
Canada FIRs
2,489,122
2,513,329
2,556,999
2,409,602
Mexico FIRs
390,280
402,499
413,821
407,738
Habana
230,212
233,922
241,641
242,794
Japan
125,961
130,515
133,490
131,709
Nassau CTA
120,814
113,279
117,088
114,903
Santo Domingo
88,751
92,715
101,822
97,591
Piarco
79,640
81,027
85,000
81,667
Santa Maria
72,281
73,459
76,726
75,750
Port Au Prince
46,090
47,978
49,886
45,792
Russia FIRs
39,665
39,894
40,365
41,409
Maiquetia
11,948
13,536
13,338
13,082
Port Moresby
10,721
10,672
10,770
10,204
Auckland Oceanic
6,463
7,250
7,580
7,936
Curacao
6,054
5,941
6,519
6,848
Manila
5,794
5,565
6,184
6,550
Nadi
2,703
2,941
3,104
2,839
Tahiti
2,984
2,571
2,791
2,630
Nauru
552
609
618
711
Ujung Pandang
255
224
235
219
Grand Total
3,609,476
3,664,647
3,750,889
3,699,974
Table 4. Reflects the number of U.S. boundary crossings per annum.
16
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
4.2.1.1 AIDC in Airservices Australia’s Airspace Implementation. Airservices Australia has implemented AIDC messaging in both the Brisbane and Melbourne FIRs. Although the Brisbane and Melbourne FIRs use an identical platform, the systems are semi-standalone and AIDC messaging is used to maintain flight plans and effect coordination. AIDC exchanges are also made to/from: —— Mauritius —— Johannesburg Oceanic —— Ujung Padang —— Nadi —— Oakland —— Auckland Oceanic The South Pacific region has seen widespread implementation of AIDC for cross FIR coordination whereas the Indian Ocean region has seen only sporadic implementation. AirNav Indonesia, which has already established AIDC in its Ujung Padang FIR, plans to implement AIDC in its Jakarta FIR in the near future. Airservices Australia, Airport and Aviation Services (Sri Lanka), and Maldives Airports Company have undertaken some preliminary testing across their shared FIR boundaries, which highlighted the importance of the involvement of technical staff during testing and implementation. As part of the implementation, a mechanism for real-time feedback should be established to diagnose and resolve technical problems, as well as confirm successful message transmission and reception. Inter-FIR messaging. Airservices Australia’s Thales Eurocat X platform integrates oceanic, continental en route and approach cells within a FIR; therefore, no AIDC messaging is required between units within the Melbourne FIR, or within the Brisbane FIR. Airservices Australia uses only a subset of the complete AIDC v3.0 message set in the Indian Ocean region. This message subset allows for limited use of AIDC – it updates the subsequent FIR on changes to flight plan information including cleared route, level and secondary surveillance radar (SSR) code, while automated handoffs
are made possible across some boundaries. Any changes to information occurring after the EST message is sent necessitates manual voice coordination over fixed communication lines. Because of display limitations (some sectors in the Indian Ocean region are so large that they often cannot be displayed on a single ATCO air situation display), voice coordination is used across some boundaries as a supplementary ‘heads-up’ to the receiving sector. This voice coordination is cross-checked against the AIDC messaging received to ensure accurate transfer of information. In the South Pacific region, a more advanced message set has been implemented. These messages allow for limited negotiation between units for changes after the coordination parameter and where denser traffic has necessitated smaller sectors that may be more easily displayed on an air situation display, truly voiceless coordination and non-radar handoffs have been implemented. Within Airservices Australia. A similar message set is used between the Brisbane and Melbourne FIRs, which permits voiceless coordination and radar/non-radar handoffs between the two FIRs. Airservices Australia has based all automated messaging on the PAN AIDC ICD; however, some ICD message elements are not supported. When an aircraft’s clearance includes an element that is not supported (such as weather deviations off track), manual voice coordination over fixed communication lines is effected to ensure that the receiving FIR has all the details. Protecting against coordination errors. Airservices Australia has implemented AIDC as a way of protecting against errors in the exchange of flight plan information – either by entirely removing the reliance on humans interpreting data (implementing a voiceless coordination environment) or by using the flight information sent in AIDC messaging as a base on which to crosscheck voice coordinated flight information.
Source: Airservices Australia
17
Figure 4. AIDC use in Airservices Australia’s airspace.
4.2.2 OLDI The system of automated coordination used by EUROCONTROL area control centres (ACCs) is OLDI. The use of automation is not mandated but where automation is agreed upon, it must be as defined in the EUROCONTROL OLDI specification. This defines the system requirements required 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. 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. All EUROCONTROL ACCs now have OLDI connections with their adjacent partners, including many on the EUROCONTROL boundary such as 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.
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. 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.
18
Automation Interface Between Flight Information Regions
Source: NATS
Best Practice Guide for ANSPs
Figure 5. Depiction of the extent of OLDI rollout.
4.2.3 NAM-ICD In North America the NAM ICD is mostly used in domestic operations and domestic/oceanic transition areas; often, cross-border operations do not fit neatly into one or the other category. Many systems today will allow interface protocols to be tailored to a particular interface: NAM or AIDC. 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. Full AIDC capability also supports extended equipment capabilities in time and distance based operations where different separation minima are being used in adjacent airspace. The NAM ICD has automated radar handoff messaging definitions within the document as a goal of cross-border interoperability evolution. OLDI is used extensively in the European region and NAM messaging is used throughout North America. The NAM protocol provides the advantage of extensibility to handoff and point-out functionality, enhancing a positive controlled radar environment. Compatibility management between existing and or emerging international automation systems
is essential to optimise capabilities and meet stakeholder needs. For example, the centralised geographic position of the United States (U.S.) requires interface collaboration to ensure that compatibility is maintained with ANSPs with U.S. boundaries, and with those wanting to implement new interfaces or enhance existing interfaces. Interfaces with the Dominican Republic, Bahamas, and an upgrade to NAM with Cuba are examples of active projects that are being worked to provide the benefits associated with ADE. The U.S. and NAM ICD Member States have realised automation gains that provide significant safety and efficiency benefits. A recent example of extending automation capability in the North American region is the Miami Air Route Traffic Control Center (KZMA) 2011 automation interface with the Cuba’s Havana ACC (MUFH). It has been estimated that a 50 percent reduction in workload for ATCOs working the border sectors at KZMA has been achieved with the operational implementation of NAM ICD Class 1 ADE. In most NAM environments, radar is the operational norm and non-radar the exception; in many traditional AIDC interfaces non-radar or non-surveillance is more the norm and radar/surveillance is the exception.
Source: Federal Aviation Administration
19
Figure 6. Canada – U.S. Operational NAM ICD Interfaces These interface protocol sets 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 modeled from the NAM ICD and originally developed for operational interfaces with the U.S., Canada and Mexico. The 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. 4.3 Mixed Environments The U.S. employs two broad categories of ADE 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. 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 en route systems and between en route 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. 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 costefficient since both had NAM ICD software in their systems for different interfaces, and any other protocol would have come with development,
20
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
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. 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. Adjacent airspace with manual surveillanceto-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. 4.4 Considerations Seeking to ensure continuous safety improvement, and air navigation modernisation, ICAO has developed the ASBU framework as a strategic
systems-based approach to planning and implementation. The ICAO Global Air Navigation Plan (GANP) Doc 9750 ICAO states that the ASBU framework “defines a programmatic and flexible global systems engineering approach allowing all States to advance their Air Navigation capacities based on their specific operational requirements”. The Module B0-FICE outlines improvements in coordination between ATSUs by using AIDC. EUROCONTROL uses OLDI to satisfy AIDC requirements. The AIDC and the OLDI are integrated protocols to coordinate flight data between ATSUs to satisfy the basic coordination of flight notification, coordination and transfer of control. Additional options like pre-departure coordination, civil-military coordination and airground data link for forwarding log-on parameters are available in the OLDI. OLDI has been in operational use for more than twenty years in Europe and for more than four years in the United Arab Emirates. During the ICAO Middle East (MID) Region ATN-IPS WG5 meeting, Cairo, Egypt 11-13 March 2013, it was noted that the majority of States in the MID region have either implemented OLDI or are planning to implement OLDI. Therefore, the meeting agreed that OLDI implementation should be considered and accepted as a regional variation of AIDC implementation as was the case in the European region. The MID Region ATN-IPS WG5 meeting further agreed that if both AIDC and OLDI are implemented, then it will be a bilateral issue and some States that are interfacing with adjacent regions may be required to support and implement dual capabilities (AIDC and OLDI). A further consideration is the quality of flight data and its impact on ADE. Capabilities need to address flight data and how it works with resident automation systems as well as adjacent facility automation. Ensuring the quality of data involves understanding how flight data systems interact with the ADE system and how the message may
21
be modified or changed by the involved systems. Differences must be corrected, accommodated, or mitigated to minimise the instances of rejection to an error queue and maximise system acceptance of the flight data. Acknowledging the differences in how systems process data is imperative to proper flight processing. The quality of filed flight plans is an issue to be aware of when implementing new interfaces or updating existing interfaces. This issue highlights a quality control problem that already existed within the manual system but is now apparent because automation demands greater adherence to standards and is less tolerant in processing incorrect data and data with errors. Flight plans received before the interface was automated were processed manually. Now they are received by automated systems, which are less forgiving of errors in format and data integrity. Many errors in filed flight plans, which have been absorbed for years within a manual system, become problematic in the automated system when filed information is not in accordance with defined ICAO guidelines. Additionally, multiple flight plans received for the same flight must be manually filtered to ensure the correct data is being forwarded by the computer system to subsequent receiving facilities. Conflicting information between flight plans filed at the departure airports and those filed by the airlines are often seen. KZMA has been dealing with this type of flight plan issue for years, but it is new to the MUFH automation, which has to deal with conflicting data and resolve any flight plan errors. Any solution must include quality control initiatives for filers and filing services to ensure the transmitted data conforms to the provisions detailed in the PANS-ATM ICAO Doc 4444. Additionally, a collaborative solution to reduce the number of errors in flight plan filing and instances of multiple flight plans for the same flight must be agreed by involved stakeholders, including the ANSP, ICAO, IATA, the filers, and automated system
users. The solution will not be easy but the result will be a better product for the automated systems, which will enhance safety and efficiency and support a seamless worldwide flying environment. 4.5
CPDLC and ADS-C Operations This section deals primarily with the FANS 1/A data link system. The ATN B1 system currently in use in Europe has the automated connection capability and does not use ADS-C. Aircraft Logon and Flight Plan Correlation To ensure the accuracy of the flight plan correlation process, all responses to an aircraft logon should be automated, such as the sending of a CPDLC connection request message (CR1) in response to the logon, and the establishment of ADS-C contracts. To avoid rejection, or failed connections, an aircraft’s logon should only occur within the period when the associated flight plan is in the correct automation state to receive a logon. For data link-equipped aircraft entering the FIR from non-data link airspace, ANSPs should publish in Aeronautical Information Publication (AIP), or other local documentation, the time period prior to the boundary crossing in which a manual logon will be accepted. For example, “aircraft entering the […] FIR should not logon earlier than 30 minutes prior to the FIR boundary estimate”. The correlation of the logon with the aircraft’s flight plan should also be automated, and should be based on both the aircraft’s call sign and registration, as a minimum. Transfer of CPDLC Connection To ensure that data link related transfers occur consistently, and at agreed transfer points, all facets of the transfer process across FIR boundaries should be automated. The first message to be sent in the transfer process is the next data authority message (NDA).
22
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
The purpose of the NDA is to notify the aircraft’s system of the four-character ICAO address of the next ATSU to send a CPDLC connection request to the aircraft. If the aircraft receives a connection request message from a different ICAO address, or if the aircraft receives a connection request before it has first received the NDA message (even if the sender is the correct ATSU), then the connection request will be rejected. The NDA should be sent at a time prior to the FIR boundary crossing that is sufficient to allow the connection process with the next ATSU to be completed prior to the boundary crossing point. Following the NDA, the ATS facilities notification (AFN) contact advisory message (FN_ CAD) is sent to the aircraft to instruct the avionics to logon to the next ATSU. Sending this message is commonly referred to as address forwarding. Due to the automatic response to the logon from the next unit, there should be sufficient interval between the automatic sending of the NDA and the FN_CAD (at least 60 seconds) to ensure that the aircraft receives the NDA message prior to the connection request message from the next unit. The ATSU with the active CPDLC connection (known as the current data authority, or CDA) should endeavour to close all CPDLC dialogues before the transfer point. The end service message is sent at the transfer point, which is typically prior to the boundary crossing, so that the CPDLC connection is active with the next unit prior to the aircraft crossing the boundary. On receiving the end service message, the aircraft will disconnect from the current unit and any open message dialogues will be discarded. Many ANSPs have linked the automated sending of the end service message to the AIDC transfer of control message / acceptance of control message (TOC/AOC) message exchange. The TOC is sent to the next unit to initiate the transfer. The end service message is then sent
Figure 7. Current FANS 1/A FIR transfer process Source: Thales Australia
Figure 8. Data link transfer completion incorporating AIDC (TOC/AOC). Source: Thales Australia
automatically to the aircraft by the transferring system when the AOC is returned by the receiving unit. The linkage to the AIDC process ensures that the communications capability remains with the controlling authority until the receiving unit has accepted the transfer of control. AIDC Version 3.0 has further improved the automation of the FANS 1/A CPDLC connection
23
transfer process. Currently in the FANS 1/A data link system, the receiving ground system is only notified that its CPDLC connection with the transferring aircraft has been activated on receipt of a downlink message from the aircraft. AIDC V 3.0 provides a ground-to-ground exchange of new messages that allow the transferring unit to directly notify the receiving unit when the previous connection has been terminated. The new messages have replaced the existing address forwarding and logon process. Rather than sending the FN_CAD message to the aircraft after the NDA message, the AIDC FANS application notification message (FAN) that contains the aircraft’s logon information is forwarded to the next unit. The next unit’s system then uses this information to correlate the aircraft with the flight plan. On flight plan correlation, a connection request message is sent directly to the aircraft to initiate the inactive CPDLC connection. The ADS-C requests are generally sent at the same time. Use of the FAN message negates the requirement for the aircraft to perform a logon to the next unit, which removes the possibility of an airborne logon failure due to lost or undelivered messages in the network, improving the efficiency of the transfer. When the transferring unit receives confirmation that the active CPDLC connection has been terminated following the sending of the end service message, the AIDC FANS completion notification (FCN) is sent to the receiving unit to notify it that the previous connection has been terminated and that the receiving unit now has the CDA status. This process replaces the additional requirement for a CPDLC position report message to be sent by the flight crew on crossing the FIR boundary, which is currently used by many ANSPs to confirm that the CPDLC connection with the aircraft is active. The FCN message replaces this procedural requirement, which is often missed by flight crew and leads to the receiving ATCO manually sending an uplink request for the missed report.
Figure 9. New FIR transfer process using AIDC V.3 (FAN Message). Source: Thales Australia
Figure 10. AIDC V.3 Notification of current data authority status (FCN Message). Source: Thales Australia
In addition to removing the need for additional, redundant CPDLC messages from the system, the FCN message provides the receiving ATCO with positive confirmation of the active status of the CPDLC connection should immediate communications intervention be required in nonvery high frequency (VHF) voice airspace.
24
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
5 Implementation Planning 5.1
Interface/System Implementation Planning When planning an interface with the adjacent FIR, a full set of messages may not be needed to achieve ADE. Scalable interfaces, which can support incremental levels of capabilities using a reduced set of interface messages, provide for tremendous implementation flexibility and benefits, and helps to keep ATC and technical training at a manageable level. The training required for a full interface implementation can be overwhelming. Conversely, an incremental approach to implementation can allow for manageable, incremental training. Additionally, the incremental approach provides the opportunity to learn the system and make informed decisions on enhancements or system modifications based on operational need. This is especially beneficial when an ANSP is implementing a new system, which employs newer technology and capabilities. Both NAM ICD and AIDC have been used in reduced message set implementations. Improper interface selection during the interface planning phase can cause issues which may prevent an interface from being implemented. Strategic planning for the demands of handling the issues which will occur during implementation is a must for successful transition. Defining the ANSP’s requirements must be an interactive process that begins with a task analysis that articulates each task the stakeholder must accomplish. Identifying and eliminating the large deficiencies which exist prior to putting the interface in the operational environment is necessary to a successful implementation. While the operational environment might seem like the best test bed for a new interface, it is the worst place to discover the issues as impacts are magnified. When analysing available lessons learned for the proposed interface, the operational
environment should always be examined in formulating the strategy for the project. Refer to Appendix B for an example implementation checklist. The following factors are among those that should be considered: —— A determination of which system protocols are already being used in bordering FIRs and how they are being used. Understanding the protocols that adjacent systems are capable of supporting can yield future benefits. —— It is important that decisions to implement automation are realistic and achievable. For example, if a significant systems investment is required by a potential interface partner in support of a unique adjacent interface, the effort may never happen. —— In order to provide the most effective automation between FIRs, operational environment matching with the proper automation protocol is needed to successfully field an interface. —— Relationships between airspace volumes to be served by ATC systems and the interfaces to be implemented must be analysed. Surveillance to surveillance, non-surveillance to non-surveillance or surveillance to non-surveillance should be examined when planning an interface. The CANSO Best Practice Guide to Crossing Flight Information Region Boundaries speaks to the complexities of surveillance to nonsurveillance boundaries. Some examples within that best practice guide include the KZOA ATOP and CZVR CAATS in a domestic – oceanic transition area. That interface is now operational and offers some lessons learned. —— System needs, coupled with current and new system capabilities and or limitations, should also be factored into
25
the interface protocol decision. In a mixed environment of radar and nonradar the NAM ICD protocol can be used effectively. Additionally, partnering with an adjacent facility that already has operational interfaces using the same protocol can also lead to a successful, timely implementation. In the absence of FIR – FIR interface experience, regional expertise may be an option. Creating the planning team The make-up of the planning team may consist of many of the stakeholders identified in 5.1 as well as the project team. This team needs to: —— Agree the system to be implemented —— Determine the training and implementation requirements —— Initiate safety management system activities —— Develop training (classroom, computerbased, simulated, operational) —— Draft procedures to be included in interunit agreements —— Conduct a post implementation review —— Ensure that a mechanism is in place to log implementation lessons learned. 5.2 Stakeholders The benefits of collaboration between aviation industry members have received increasing attention and therefore, it is important that ANSPs identify and consult with all stakeholders so that their requirements are addressed early in the implementation planning process. The affected stakeholders will depend on the local operational and regulatory environment in which the ANSP operates, but they may be categorised into internal and external entities. Internal entities may include: —— The ANSP’s ATCOs, air traffic control assistants and flight data officers —— Air traffic control supervisors
—— Automation technicians —— Adjacent ‘same ANSP’ ACC, approach units, towers and flight information services —— Network managers, capacity/operations managers and aerodrome/flow managers —— Aeronautical information service officers. External entities may include: —— Airspace users (pilots, flight dispatchers and airline operations centres) —— Airport operators —— ICAO regional offices, State civil aviation authorities and other government agencies —— Adjacent ACCs, ANSPs, approach units, towers and flight information services —— Meteorology providers —— Search and rescue authorities —— Military Ensuring that the needs of stakeholders are adequately addressed during the design and implementation stages supports system interoperability, avoids divergent or incompatible development between systems, and may identify opportunities to reuse or adapt existing tools and documentation. This may help avoid potentially costly and time-consuming post-implementation modifications to address unforeseen stakeholder requirements. A number of stakeholders are represented or assisted by professional and industry bodies that provide their members with guidance for their participation in the implementation of new ATM automation systems and procedures. Consultation with these professional and industry bodies prior to beginning the implementation activities may be a useful way in which the ANSP can obtain stakeholder ‘buy-in’ to develop cross-organisational partnerships that can share information regarding working practices and system limitations. This will aid in identifying the
26
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
impact of system implementation on stakeholders in sufficient time to make necessary design changes before they cause constraints, operational risk, or increased cost. 5.3
Gap Analysis An ANSP may undertake a gap analysis to investigate the differences between current capabilities and desired capabilities of the ATM system. The nature of the gap analysis will depend on the rationale for the implementation of the ATM system. Current capability versus current requirements: When an ANSP faces increasing levels of flight data or where there are concerns due to the number of operational errors or precursor events related to flight data processing, it may be appropriate to conduct a gap analysis of the current ATM system capability versus the current requirements of the ATM system. Such a snapshot analysis may be used by an ANSP facing unforeseen and immediate challenges that require a rapid short-term response.
5.4
Task Analysis The implementation of a new ATM system will very likely see changes to the way in which operational staff undertake their work (or their ‘method of working’); however, the significance of the change will depend on a number of factors including: —— The operational environment (en route, approach or tower) —— The nature of the existing ATM system —— The nature of the new ATM system and —— Coincident changes to the airways system e.g. changes to air routes, air space sectorisation, PBN implementation, or changes by neighbouring ANSPs or airspace users
Current capability versus planned requirements: Where one or both ANSPs at an interface are planning to change the ATS being provided in the FIR boundary area or where one or both ANSPs are making changes to their flight data processing system.
In order to determine exactly how the method of working of operational staff will be altered by the implementation of a new ATM system, the current method of working should be defined. This may be achieved by observing operational staff as they work with questioning used to clarify uncertainties and gain insight into human factor considerations. Such observation is beneficial to both the ANSP and the operational staff; indeed, the policy of the International Federation of Air Traffic Controllers’ Associations (IFATCA) is that operational ATCOs should be involved throughout the ATM system implementation process.1
Current capability versus future requirements: This analysis considers the future growth in air traffic as well as the changing demands of airspace users and should be undertaken in most cases so that the ATM system may operate to its intended life. It may be possible to provide for potential future requirements during an implementation or enhancement, thereby reducing future costs. These types of requirements are best identified in consultation with stakeholders, as part of a collaborative multistate or regional planning process.
With an understanding and comparison of the current versus anticipated ATCO method of working, training needs can then be identified. The training needs of each user group should be identified whenever there is a significant change to systems or procedures as a part of the ANSP’s change management activities. The ICAO Safety Management Manual (SMM) Doc 9859 describes the importance of change management as a part of a broader safety management system (see Chapter 6 of this document for further information on safety management including CANSO’s contribution); civil
1
IFATCA Technical and Professional Manual 2014
27
aviation authorities may impose additional change management requirements on the ANSP to those in the ICAO SMM. Moving from a purely strip-based ATM system to a computer-based system may represent a significant change to ATCOs’ method of working, while for ANSPs that have already made the transition to a computer-based ACC, the transition from electronic strips to a strip-less system may represent a lesser change. Reducing the size of the change from the existing system to the new system may reduce the training requirement; rather than moving from a paper strip-based system to a fully stripless system, an ANSP may elect to implement electronic strips, which allows ATCOs to continue to use their well-practised method of working as they become more accustomed to operating in an electronic environment. An ANSP moving between electronic systems may, in consultation with the users and the vendor, implement a colour scheme in the new ATM system that is identical to the existing scheme. It is important to note that while the training of ATCOs and other operational staff in new methods of working may consume significant resources, the training requirements should be viewed in the context of the projected safety, capacity, and efficiency gains that will be facilitated by a new or altered system. As stated above, the design and delivery of training for system users is an important component of the change management process. Proper training can ensure that operational staff use the ATM system to its full potential and allow the ANSP to realise the safety, capacity and/or efficiency gains that justify its investment. 5.5
System Requirements Defining the requirements of a new or altered system is a critical step in the
implementation of a new or altered system that ensures that the requirements of both internal and external entities are met. System requirements must be defined in sufficient detail to ensure that systems engineers, who may not be experienced operational ATCOs, are able to provide a system that is fit for purpose, which will minimise the reworking of the system and therefore keep the development and implementation costs down. Guidance for AIDC system requirements is given in ICAO Doc 9864 Manual of ATS DataLink Operations. AIDC systems should attain requirements for availability, integrity, reliability and continuity. ICAO Doc 9864 specifies the following recommended values: —— Availability is the ability of the system to perform the functions for which it was intended, it is a percentage of the time the system is available with reference to the planned available time. The recommended value for availability is 99.996 percent —— Integrity refers to the probability that a correct message or part of a message is deemed to be erroneous. The acceptable value is 10–7 —— Reliability of the AIDC system is the probability that the system will deliver messages without errors, this should be 99.9 percent —— Continuity is the probability of the system failing over a given period. AIDC systems must display a continuity of 99.9 percent AIDC systems must possess a level of robustness that will ensure messages are delivered accurately to the correct ATSU and in the sequence in which they were sent; systems must recognise a hierarchical structure for priority messages and deliver accordingly. Each message must possess a unique identification with the associated response message containing the message identification of
28
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
the referenced message. Responsible personnel must be alerted within a fixed parameter when messages are rejected, not acknowledged or not received. System design must meet requirements for failures, facilitate a recovery process that is able to identify messages that are not acknowledged, maintain the integrity of message identification numbers and also there must be access to historical data Correctly and thoroughly defining system requirements along the guidelines as suggested above is critical, however sometimes when a single ANSP is looking to replace its system, it considers the requirements to be internal, so very little coordination takes place with other stakeholders, especially adjacent ANSPs. The reasons for this lack of coordination may be many and varied, but to ensure harmonisation, systems requirements must be compatible. Defining the ANSP’s requirements must be an interactive process that begins with the task analysis. The task analysis will articulate each task that the stakeholder must accomplish to complete its work. The task analysis will derive the knowledge, data or alerts associated with each task, the system behaviours that support them, and the human machine interface that facilitates accomplishing the tasks as safely and effectively as possible. In defining its own system requirements, an ANSP must consider the existing systems with which it will interact including those internal to the ANSP. Such systems include: —— Existing internal ATM systems (an adjoining FIR managed by the same ANSP) —— ATM systems operated by another ANSP —— Notice to Airmen (NOTAM) and meteorology providers —— Systems of airports, airspace users and other agencies which may receive or input data
While ATM systems continue to evolve, even the most modern ATM system does not function in isolation, and the movement of traffic across FIR boundaries may be significantly affected by the degree to which the ATM systems are able to communicate. The most advanced ATM system available will provide little support to ATCOs if there is no system communication across the FIR boundary to neighbouring ANSPs and they must instead manually coordinate all traffic using potentially unreliable telephone connections. In order to facilitate system communication between systems, ANSPs should establish technical working relationships with their neighbouring ANSPs that facilitate the sharing of technical information relating to their operational systems. In addition to technical working relationships, higher-level relationships across FIR boundaries can foster a shared cross-ANSP understanding regarding future developments. By understanding the existing and future systems of their neighbours, an ANSP can include the need for backwards or forwards compatibility in its requirements definition. An example of the need for such forward and backward compatibility is seen in AIDC, which exists in a number of iterations across the world. An ANSP may identify the latest version of AIDC in its requirements definition; however, if the ATM systems used in surrounding FIRs are of an earlier version or if surrounding FIRs do not use AIDC, but instead use a different system and do not plan to move to AIDC in the future, then the benefits of incorporating the latest version will be significantly limited. 5.6 Standards As described in Chapter 2, the ICAO GANP presents a framework for harmonising avionics capabilities and the required ATM systems including automation; the ICAO ASBU framework provides a path for the global improvement and
29
harmonisation of ATM. ANSPs may use the ASBU framework to plan the future operability of their ATM systems. The CANSO booklet Introduction to the Aviation System Block Upgrade (ASBU) Modules provides ANSPs with an overview of the framework and the required integrated implementation processes of business case and needs and dependency analysis, which must be performed to select and implement the ASBU modules that best meet the operational needs of individual ANSPs. The Global Operational Data Link Document (GOLD) has been adopted in the Asia Pacific, North Atlantic, European, South American, and African-Indian Ocean regions and is being developed for global application by ICAO. The GOLD combines the various regional standards to provide a globally harmonised standard for data link that addresses ATS data link service provision, operator readiness, and ATCO and flight crew procedures for the implementation of FANS 1/A and ATN B1 technologies. ICAO has urged all states to implement routes and airport procedures in accordance with the ICAO PBN criteria2; therefore, it is highly desirable that new ATM systems facilitate PBN operations by airspace users. The ICAO PBN Manual (ICAO Doc 9613) and the CANSO PBN Best Practice Guide for ANSPs provide ANSPs with guidance on the implementation of PBN, while most states have published PBN Implementation Plans that provide local perspective. The ICAO Global Aviation Safety Plan 20142016 (ICAO Doc 10004), although not directly addressing ATM automation systems, details safety performance enablers, which have been identified as enabling the objectives of the global aviation safety plan (GASP). The GASP safety performance enablers of standardisation, collaboration, resources and safety information exchange provide useful signposts to direct an ANSP’s efforts when
planning and implementing changes to ATM automation systems. Where an ANSP makes long-term changes to its ATM system, it is important that provision is made for future changes to the ATM environment. SWIM – an integral part of the ICAO GANP – is a component of a number of ASBU modules. The ICAO Manual on System Wide Information Management (ICAO Doc 10039), which is under development at the time of this Guide’s publication – will provide an overview of the SWIM concept as well as an interoperability framework. The ICAO Manual on Air Traffic Management System Requirements (ICAO Doc 9882) and the ICAO Manual on Global Performance of the Air Navigation System (ICAO Doc 9883) provide ANSPs with an understanding of the delivery mechanisms for the ATM system envisaged in ICAO’s long-term ATM operational concept. In addition to global documents, some ICAO regional offices have produced documents that define the regional strategic ATM plan and therefore the industry standards that the ATM system should support. An example of regional documentation is the ICAO Asia/ Pacific Seamless ATM Plan 2013.3 The document defines the communication, navigation and surveillance standards that the Asia Pacific region will implement across the region up to 2018. By referring to such regional documentation during the planning phase, an ANSP may hope to better align the development of its ATM systems with its neighbours. 5.7
Assessing Possible Solutions Historically, the systems used by aircraft to navigate and communicate with ATC retained significant commonality and VHF radios, VHF omni-directional radio range (VOR) navigation aids and the AFTN have achieved near universal use by airspace users and ANSPs. The development of modern systems for navigation
2
ICAO 36th Assembly, 2007, Resolution 36/23
3
http://www.icao.int/APAC/Documents/edocs/Asia%20Pacific%20Seamless%20ATM%20Plan%20V1.0.pdf
30
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
and communication saw the beginning of diversification, as multiple systems were developed to achieve similar outcomes such as improved navigation, communication and surveillance. It is imperative that ANSPs consider the implications of the communication, navigation and surveillance technology that they implement on system and ATCO interaction with neighbouring FIRs if they are to minimise the difficulties that can occur when flights cross FIR boundaries. 5.8
Implementation Lessons Learned Airservices Australia, the FAA, Airports Authority of India, NAV CANADA, and other ANSPs have had recent successes in implementing automation systems that interface with neighbouring ATSUs. The success didn’t come without pitfalls. In this section, the lessons learned in the implementation process, such as communication latency, performance and AIDC message success rate, phased implementation, and non-operational testing will be discussed. Automation Interface Testing (offline): Testing is one of the most critical phases of the implementation process. It is in this phase where the latency of communications can be determined, and the success of logical accept messages can be measured. It should also be possible to determine the performance of the network (i.e., by the measurement of round trip times for AIDC message exchanges). To ensure that there is minimal or no interruption to the provision of ATS services, where possible all automation interface testing should be conducted on a non-operational platform, e.g. a test facility that replicates the operational platform. The test facility should be equipped with a discrete AFTN address and communications link so that coordination messages may be sent to and from the platform without interfering with operational systems and flight data.
Automation Interface Testing (online): Having demonstrated satisfactory integrity and reliability on non-operational platforms, ANSPs may progress to testing automation interfaces on operational platforms using non-operational flight plan data. This should occur during low traffic periods and should be monitored closely to ensure that the testing does not affect the provision of air traffic services. Other Testing Issues: A number of difficulties can arise when testing the automation interface between large neighbouring FIRs. Time differences can make finding the best time for testing difficult e.g. there are eight hours between local time in Johannesburg and Melbourne, which share an oceanic FIR boundary. In addition to time difficulties, communication difficulties can occur because unlike operational coordination lines, which are generally of high quality, technicians may communicate using a private automated branch exchange telephone switching system (PABX), which can be subject to interruption or be of low quality. Ensuring Flight Plan Accuracy: Where certain messages have caused system or flight data discrepancies, it is desirable for an automation interface to have the capability of blocking those messages before they are incorporated into the ATM automation system. For example, to allow ATM automation systems to correctly process a flight plan, route truncation is often required, which may cause issues in subsequent FIRs if not processed correctly. An ANSP can benefit from the ability to block troublesome messages based on parameters such as originator, recipient and message type. Cyclic Redundancy Check (CRC): Ensure that the CRC being used by the AIDC application is correct. AIDC messaging uses the CRC-CCITT algorithm, which has a number of variations; the correct variation for AIDC use is XModem.
31
If an AIDC message contains the incorrect CRC, the receiving ATSU should respond with a Logical Rejection Message (LRM). There have been instances of AIDC applications that have used the incorrect CRC algorithm, which results in AIDC messaging not being interoperable with other ATS Units. Optional Data Field (ODF) While it is referred to as “optional”, AIDC messaging actually requires the ODF to be included in AIDC messages. ODF information is used to track AIDC messages to allow Application responses such as Logical Acknowledgement Message (LAM) and LRM, as well as Acceptance (ACP) and Rejection (REJ) messages to be linked to the original AIDC message. AIDC applications that do not include ODF information will result in AIDC messaging not being interoperable with other ATSUs. Field Size The maximum sizes of ICAO flight plan fields (typically Field 15 and 18) are not specified. These flight plan fields are included in some AIDC messages and different software vendors support varying maximum field sizes. For example, if an ATSU supporting 250 characters in Field 18 sends this data in an AIDC message to an ATSU that only supports 200 characters, the receiving ATSU should respond with a LRM. This can result in interoperability issues between adjoining ATS Units. If such a limitation is identified, procedures should be developed so that if information from Field 18 needs to be deleted by the ATSU that supports the larger Field 18, the information to be deleted is agreed between the two ATSUs. Correct data syntax Ensure that the AIDC application checks
the syntax of data in AIDC messages before the message is transmitted. During AIDC testing, occurrences of SSR codes containing an “8”, and other similar instances of invalid data have been observed. Receipt of an AIDC message containing invalid data should be responded to with a LRM by the receiving ATSU. 5.9 Adaptability The air transport industry has been subjected to an increasing rate of change as market forces drive improvements in technology and methods of working. The ICAO GANP and regional ATM plans are an attempt to set a path for improvement in the provision of ATM; however, some recent developments in ATM such as the increased prevalence of heavy unmanned free balloons and space-based automatic dependent surveillance – broadcast (ADS-B) were not foreseen by the authors of such strategic plans. These changes to the air transport industry demonstrate the importance of an ATM system’s ability to constantly evolve, not only by introducing expected changes to the industry as scheduled in the ASBU framework and the ICAO GANP but also by managing the introduction of ‘disruptive technology’ that may not have necessarily been forecast by ICAO or other users. In addition to the large changes across the industry, smaller changes can occur frequently and it is imperative that the ATM system can accommodate these changes. Small and localised changes may include changes to: —— Availability of aviation weather products such as meteorological aviation reports (METAR), terminal aerodrome forecasts (TAFs), and significant meteorological information (SIGMET) information —— Availability of NOTAM —— Availability of navigation aids and voice
32
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
communications; —— ATS routes, standard instrument departures (SIDs) and standard instrument arrivals (STARs) —— Aerodromes such as new or removed runways, new designators or changed service levels. In order to facilitate the integration of these smaller changes into the ATM system, ANSPs should ensure that they occur in line with the aeronautical information regulation and control (AIRAC) cycle. Where these changes are initiated by external agencies (e.g., the renaming of an airport), the ANSP may need to liaise with the external agency to ensure that it occurs on an AIRAC date. A change that occurs off-cycle may not be able to be accommodated by an automation system designed to process changes on AIRAC dates alone. However, more flexible systems that are capable of dynamically modifying aeronautical data would be able to accept these rare off-cycle changes driven by an external agency. Striving to future-proof a large and complicated electronic system is not a simple proposition; however, there are a number of strategies that exist for ensuring that the system can integrate changes to the system. One method is ensuring that the ATM system features sufficient ability to customise, including the use of variable system parameters where possible. Variable system parameters build flexibility into the system and improve the ability of the system to respond to changes in the industry. Airservices Australia made use of variable system parameters in response to the change to aircraft tracking in oceanic areas: the variable system parameter that corresponded to the default ADS-C reporting rate was amended by local staff trained in the manipulation of system data to increase the fidelity of aircraft tracking.
The ANSP should establish procedures for implementing minor changes such as this change – through properly trained local staff or an agreement with the supplier of the ATM system for technical maintenance visits. Larger changes to the ATM environment may have significant implications for the ATM system. An example of a completed large change is the 2012 implementation of the updated flight plan provisions detailed in Amendment 1 to the 15th Edition of the PANS-ATM, ICAO Doc 4444 . The implementation of space-based ADS-B is an example of a forthcoming larger change. Larger changes, which may present a significant challenge to the ANSP, often have long lead-in times that permit the ANSP to recruit assistance from other ANSPs and/or suppliers to integrate the changes in their ATM system.
33
6 Related Considerations 6.1
Safety Management Annex 11 to the International Convention on Civil Aviation - Air Traffic Services specifies that 1. “Any significant safety-related change to the ATS system, including the implementation of a reduced separation minimum or a new procedure, shall only be effected after a safety assessment has demonstrated that an acceptable level of safety will be met and users have been consulted. 2. When appropriate, the responsible authority shall ensure that adequate provision is made for postimplementation monitoring to verify that the defined level of safety continues to be met. 3. When, due to the nature of the change, the acceptable level of safety cannot be expressed in quantitative terms, the safety assessment may rely on operational judgement.� Under most regulatory regimes, ANSPs will be required to complete appropriate safety assessments before implementing a change as significant as introducing a new ATM automation system or upgrading the existing system for automated data exchange. CANSO provides guidance for ANSPs conducting such assessments in the CANSO Standard: Common Safety Methods on Risk Evaluation and Assessment for ANSPs. ICAO also provides guidance relevant to collecting safety data and assessing risk in the Safety Management Manual (SMM) (Doc 9859). The best practices for safety management elaborated in these two documents are recommended for all times. For ADE, special emphasis may be placed on involving all the stakeholders from various fields like ATM, CNS, airspace planners, flight operators, telecommunications and ATM system specialists.
As automated data exchange across FIR boundaries is essential for the safe, seamless, and efficient flow of traffic across FIR boundaries on both sides of the boundary, it is strongly recommended to conduct joint safety assessments involving stakeholders from both FIRs. 6.1.1
Recommended Action Plan ANSPs should prepare a detailed system description of the proposed change, in the operational environment in which the change is being implemented. ANSPs should conduct a qualitative safety assessment (as opposed to a quantitative assessment, which may not be feasible due to the absence of statistical data) of the change, in the presence of stakeholders. The safety assessment should identify hazards and their consequences; express the consequences in terms of probability and severity (risks); and classify the risks as unacceptable, tolerable or acceptable. Processes that have unacceptable risks should not be permitted to exist in the system. Processes containing risks that come under the tolerable category may be allowed to reside in the system; however, the risks should be mitigated to an acceptable level (as low as reasonably practicable) within the constraints of the resources availability. ANSPs should record the risks, their assessment and the mitigation plan in a hazard log, which should be reviewed periodically. Processes having unacceptable risks should be permitted only after subsequent reviews have indicated that the risks have been mitigated to tolerable or acceptable levels. As mentioned above under 6.1, it is strongly recommended to conduct a joint safety assessment session involving stakeholders from both the FIRs. Such joint exercises could include the sharing of hazard log (HAZLOG) and mitigation plans and agreeing an acceptable mitigation strategy, or a
34
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
full-scale joint safety assessment where the physical presence of the stakeholders from both sides is required. ANSPs should conduct extensive trials before the complete transition to automatic data exchange. A post-implementation review of the change should be conducted after the trials and before the new procedures are implemented. 6.2
Contingency Procedures Failures that result in the automation interface becoming unserviceable will affect the efficiency and accuracy in which flight plan data is exchanged across FIR boundaries. In some cases, only limited messages will be able to be exchanged, and in extreme failures, the exchange of data will cease to exist completely. Effective management of contingencies for such failures begins with a harmonised framework during the system implementation process. It is essential that ANSPs consider including procedures in their bilateral LOAs that will ensure a safe and orderly transition to contingency procedures. The following recommended steps will help ensure success in contingency situations: —— Specifying clear and concise procedures in bilateral LOAs to be followed during specific failures, such as reverting to manual coordination and utilising alternative methods to transfer flight plan data. —— Ensure that the automation system is implemented with interoperable infrastructure and associated compatible procedures that would facilitate compatible exchange of messages —— Develop recurring training to help ATCOs maintain proficiency in reverting to complete manual operation Automation systems should incorporate key features that will alert ATCOs when there are degradations or failures. For example, the use of prompts on display screens that will alert ATCOs
when there is an automation link failure. A performance management system (PMS) should be developed that will aid in quality monitoring of system infrastructure and alert ATCOs when there is increased probability of degradation. Appendix C provides a sample checklist that identifies areas that should be monitored as part of the automation PMS to better manage contingencies. 6.3 Opportunities for ATS Enhancements If the flight data processing capability is being enhanced, it may be the right time to take advantage of new capabilities to support improved or new ATS. ANSPs already using AIDC should consider upgrading to the current version to take advantage of the additional capability that further enhances the safety and efficiencies of data link-related transfers across FIR boundaries. However, to ensure that all users are able to utilise the benefits, the upgrade path needs to be considered on a regional basis. Having one ANSP with the updated version interfacing with older versions operating in neighbouring FIRs does not provide any tangible benefit from the new functions and enhanced capability. As neighbouring ANSPs install compatible automation systems, an opportunity exists to implement Modules within the ICAO ABSU framework on a regional basis. The benefits of pursuing this implementation are discussed in Chapter 2 of this Guide. 6.4 Inter-unit Agreements To ensure system compatibility, ATSUs should consider establishing bilateral agreements for testing, implementing, and modifying automated systems. These agreements should specify the requirements and limitations of the two systems. Definitions of supported messages and
35
their parameters for transmission, unsupported messages, and contingency procedures should also be included in these agreements. The relationship of system messages to existing voice coordination must also be considered (i.e., does messaging partially replace or only supplement voice coordination). An effective way of ensuring this through existing LOAs or MOUs between ATSUs is a separate and supplemental LOA/MOU that specifies these procedures; an example is provided in Appendix D. Another method is to amend the section on coordination procedures to include automated messaging, and/or adding an appendix that specifies automated data exchange procedures; an example of an added appendix is available in Appendices E and F.
36
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
7 Conclusions and Recommendations Automated exchanges of flight data contribute to safety and efficiency through the elimination of read-back / hear-back errors, reduction of ATCO workload, reduction of missed (forgotten) coordination and updates and reduction in the time required to complete coordination. The benefits of increased flexibility from user-centred operations depend on efficient, reliable and timely flight data coordination. Automated data exchange is integral to achieving all the benefits foreseen in the ICAO ASBU FICE Modules. This capability will enhance the benefits possible through the improvements defined in most of the SWIM Modules and all of the NOPS Modules. Many of the benefits foreseen for operators in the CCO, CDO and TBO Modules will be enhanced if related flight data exchanges are accurate and timely. Automated data exchange supports CPDLC and ADS-C by ensuring accurate flight data is available at the ANSP when aircraft attempt to logon and by supporting automated data link connection transfer processes. We recommend that ANSPs consider: —— Whether implementing or improving automated flight data exchange could mitigate or eliminate coordination errors —— Concurrently implementing or improving ADE to enhance the benefits possible from improving ATS services at or near FIR boundaries —— Timing the implementation of, or improvements to ADE to complement, or further benefit from changes to other ATM systems, including those of neighbouring ANSPs —— Keeping neighbouring ANSPs informed
on its automation plans to support interoperability and complementary implementations —— Future requirements when planning new or improved automation, so as to minimise incremental costs to accommodate evolution of services. Consultation with all stakeholders, including airspace users and neighbouring ANSPs is essential in this regard —— When determining AIDC system requirements, ANSPs should consult with interface ATSUs to ensure interoperability at the design/ procurement phase and to encourage adherence to global standards and best practices.
37
References Civil Air Navigation Services Organisation (2015). Guide to Seamless Airspace (2013), and the Best Practice Guide to Crossing Flight Information Region Boundaries canso.org/best-practice-guide-crossing-flight-information-region-boundaries International Civil Aviation Organization (2006), Interface Control Document For Data Communications Between ATS Units In The Caribbean And South American Regions (CAR/SAM ICD) icao.int/NACC/Documents/eDOCS/ATM/CARSAMICDEnglish.pdf International Civil Aviation Organization (2013), Global Air Navigation Plan (Doc 9750), icao.int/publications/documents/9750_4ed_en.pdf International Civil Aviation Organization (2013), Safety Management Manual (SMM) icao.int/safety/SafetyManagement/Documents/Doc.9859.3rd%20Edition.alltext.en.pdf International Civil Aviation Organization, Pan Regional (NAT and APAC) Interface Control Document for ATS Interfacility Data Communications (PAN AIDC ICD) http://www.icao.int/EURNAT/EUR%20and%20NAT%20Documents/NAT%20Documents/PAN%20AIDC%20 ICD/PAN%20AIDC%20ICD%20(EN)%20-%20Edition%201.1,%20Amd%201.1.pdf International Civil Aviation Organization, PANS ATM, (Doc 4444), Fifteenth Edition, 2007 International Civil Aviation Organization, North American Interface Control Document VOLUME 1: Area Control Center (ACC) to ACC (2012). icao.int/NACC/Documents/eDOCS/CNS/NAM%20ICD%20Ver%20D%2020%20Jan%202012.pdf International Civil Aviation Organization (2013), Aviation System Block Upgrades the Framework for Global Harmonization. http://www.icao.int/sustainability/Documents/ASBU.en.Mar.%202013.pdf International Civil Aviation Organization (1999). Manual of Air Traffic Services Data Link Applications (Doc 9494), First Edition International Civil Aviation Organization, Global Operational Data Link Document (2013) http://icao.int/APAC/Documents/edocs/GOLD_2Edition.pdf/Documents/edocs/GOLD_2Edition.pdf International Civil Aviation Organization (2007), Asia/Pacific Regional Interface Control Document (ICD) for ATS Interfacility Data Communications (AIDC), Version 3.0.
38
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
Appendix A Identified FIR Boundary Crossing Discrepancies The following topics have been identified by the Crossing FIR Boundaries (FIRBX) Task Force for inclusion in future versions of this document: Technical and Equipment Issues: —— Automation disconnect: —— Platform incompatibility —— Interface protocol —— FIR weather sharing with adjacent ANSPs —— ANSP communication transfers: voice and data link Operational Issues: —— State regulations/requirement versus ANSP operational needs —— Incompatible procedures: Requirement of ANSPs do not coincide —— Strategic and tactical ATFM: —— Lack of regional implementation —— Lack of coordinating ATFM restrictions with adjacent ANSPs —— Incompatible ATFMs —— Language proficiency/deficiencies: Efficient coordination —— Global separation standards: —— Longitudinal: —— Time based (standardise the minima) —— Application of reduced longitudinal dependent upon aircraft equipage (ADS-C, CPDLC) —— Incompatible airspace design: —— Stratum of adjacent FIR produces less optimum procedures and service given: —— May cause increased (less optimal) rate of climb or descent for aircraft departing/arriving airports that are in close proximity to a FIR boundary —— Bilateral and multilateral boundary location requires additional coordination:
—— Need to involve several ANSPs for “point-out” coordination —— Potential of aircraft leaving and reentering FIRs over short time periods may lead to ineffective coordination. —— Political issues that impact operation Procedural Issues: —— Metric versus Imperial: Temperature (Fahrenheit versus Celsius), Longitudinal (miles versus kilometres), altitude (feet versus metres) etc. —— Sharing of situational awareness (weather, temporary flight restrictions, ATFMs, etc.) —— Altimeter setting: QNE (height above sea level at standard setting) versus QNH (height above sea level) —— Transition altitude: Flight level and altitude —— RVSM to non-RVSM coordination —— Coordination Procedures: Manual versus Automated —— Pilot/Aircraft Certification and Capability —— Appropriately entered in filed flight plan (FPL) —— ANSP: Appropriately preserved in current flight plan (CPL) —— Pilot/controller human error issues: —— Read-back/hear-back errors —— Manual coordination —— Uplink and Downlink Messages, computer inputs, etc.
Appendix B Implementation Checklist Activity #
Activity/Task Description
1.0
Assigned
Due Date
General Implementation Survey
1.x
Construct overview briefing
1.x
Identify operational impacts / changes
1.xx
Identify facility(ies) areas/ sectors involved
1.x
Identify known issues
1.xx
Duplicate/error flight plans
1.x
Construct requirements matrix
1.x
Construct fallback /recovery plan
1.x
Interfacing facility impacts
1.x
Plan recurring meetings with cross-border partners
1.x
Plan action item tracking list
1.x
Identify system metrics
1.x
Define project milestones
1.x
Identify key personnel for site implementation. ATC, labour, automation, data specialists
1.x
Identify existing /required telecommunications
1.x
Identify limitations/impacts of other projects or installations
1.x
Coordinate project /facility / inter facility contacts
1.x
Review/coordinate site unique implementation documents
1.x
Schedule/timeline/coordination
1.x
Review LOAs existing/changes
1.x
Formulate traffic scenarios that duplicate existing traffic flows and walkthrough how automaton should handle the situations
1.x
Develop a procedure to capture/document problems or lessons learned —— Non-operations/automation —— Operations
1.x
Coordinate test support needs —— Site automation —— Communication POCs
2.0
Software Adaptation
Complete
Comments
40
Activity #
Activity/Task Description
Assigned
2.x
Airspace/routes/fixes/ coordination points/ special use
2.x
Message class/type being used
2.x
Messages/times/errors/triggers
2.x
Systems field differences between sites
2.x
Error to each type message
2.x
Common errors from lessons learned and how the system reacts to those issues
2.x
Identify any System Settings and or Configurations Needed to Enable/Disable Processing
2.x
Interrelationship between Flight Data system and ATC system
2.x
Automation Lessons Learned
3.0
Training
3.x
Coordinate facility training
3.x
Coordinate facility technical operations familiarisation
3.x
Complete training course refresher if necessary
3.x
Site training
3.x
Complete interface specific training and identify needed training updates
3.x
Develop site unique operations familiarisation
3.x
Conduct ops familiarisation briefing
3.x
Integrate lessons learned into cumulative site package
3.x
Flight data specialist briefing
4.0 4.x
Testing Define fallback plan/system recovery plan
4.x 4.x.x
Non Operational Testing - Offline Configurations which need testing: Test facility A to test facility B Test facility A to test facility C
4.x.x
Due Date
Define non-operations offline testing —— Can test configuration be isolated from operational system? —— Can telecommunications test line and operational line be shared without impact?
Complete
Comments
41
Activity # 4.x.x
Activity/Task Description
Assigned
Due Date
Test preparation —— Adaptation parameters: time/ distance/display —— Prepare test procedures —— Construct test scenarios that duplicate actual traffic —— Determine/use system ability to capture test results —— Identify test coordinator and personnel —— Develop a procedure to capture potential automation and ops issues/problems —— Determine nature of an anomaly —— Does system have error queue —— Impacts of failed messages —— Keep issue log
4.x.x
Setup Test Specifics —— Facility scheduling —— Start time —— Duration —— CPL scenario exchange/review —— Confirm implementation POCs
4.x.x
Conduct Non-Operations Offline Testing
4.x.x
Document Test Results —— Data reduction —— Data analysis Test review
4.x 4.x.x
Non Operational Testing Test preparation —— Adaptation parameters: time / distance/display —— Prepare test procedures —— Construct test scenarios that duplicate actual traffic —— Determine/use system ability to capture test results —— Identify test coordinator and personnel develop a procedure to capture potential automation and operations issues/problems —— Determine nature of an anomaly —— Does system have error queue —— Impacts of failed messages —— Keep issue log
Complete
Comments
42
Activity # 4.x.x
Activity/Task Description
Assigned
Due Date
Setup test specifics —— Facility scheduling —— Start time —— Duration —— CPL scenario exchange/ review Confirm implementation POCs
4.x.x
Conduct non-operations testing
4.x.x
Document test results —— Data reduction —— Data analysis Test review
4.x.x
Non-operational tests —— Test #1 tested functionality —— Test #2 tested functionality —— Test #3 tested functionality
4.x 4.x.x
Operational Live Testing Test preparation —— Tailor operations test plan for facility —— Identify test coordinator and personnel (cadre), —— Coordinate test effort (pretest meeting) —— Subject matter experts —— Site X —— Site Y —— Tailor test procedure to capture problems and lessons learned —— Complete/review adaptation —— Prepare test procedures —— Develop familiarisation —— Conduct familiarisation —— Review fallback procedures
4.x.x
—— Setup Test Specifics —— Start time/stop time —— Duration —— Review test procedures —— Verify contacts —— Identify sectors/ personnel —— Document Test Results
4.x.x
Pre-Test Meeting Coordinate test
Complete
Comments
43
Appendix C Automation Performance Management Checklist Items to monitor Agreed prioritisation of communication systems —— AIDC —— ATS direct speech circuits —— Public telephone system —— Relay —— Other available means System to monitor flight plan quality Standardisation of parameter for “Time Out Period” and “Time Out Alarm” Availability of direct speech circuits Capture AIDC failures during TUSAE training Access to historical AIDC messages Agreements for coordinating flights departing aerodromes with less than thirty minutes flying time from the FIR boundary System to monitor the following elements of the AIDC data link with the associated standards: Availability 99.996 Integrity 10–7 Reliability 99.9 Continuity 99.9
Status
44
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
Message
Decode
Appendix D
ABI
Advance boundary information
Example ASIOACG Letter of Agreement Coordination and Communication
AOC
Assumption of control
CPL
Current plan
DLA
Delay
EST
Estimate
LAM
Logical acknowledgement message
LRM
Logical rejection message
MAC
Coordination cancellation
TOC
Transfer of control
1. AIDC 1.1. AIDC Coordination – [FIR 1] / [FIR 2] ATS Inter Facility Data Communications (AIDC) is the primary means of coordination between [FIR 1] and [FIR 2]. 1.2. Defined AIDC messages The following AIDC messages are defined for use between [FIR 1] and [FIR 2]. The format of AIDC messages is in accordance with the current ICAO Asia/Pacific Regional Interface Control Document (ICD) for ATS Inter Facility Data Communications (AIDC) Version 3.04. Optional formats containing Mach Number Technique, Off Track Deviations and Block levels have not been implemented. Voice coordination shall be conducted for aircraft operating under these circumstances. 1.3.
AIDC Coordination Procedures
1.3.1. Successful Coordination Successful initial coordination via AIDC occurs on receipt of an ACP message in response to an EST message. 1.3.2. Transfer Control Transfer of Control occurs on receipt of an ACP message in response to a TOC message. 1.3.3. AIDC Outage Each ATS unit shall advise the other of any known equipment outage that affects AIDC. 1.3.4. Specific Controller Actions Controllers shall: —— not assume jurisdiction of flights for which an 4
http://www.icao.int/APAC/Documents/edocs/icd_aidc_ver3.pdf
Table 1 - Defined AIDC messages AIDC hand-off is expected —— accept the proposed hand-off without undue delay 1.4. Verbal Coordination When verbal coordination is completed for a flight the voice coordination will take precedence over other coordination for that flight. Any further change to such coordination shall be effected through verbal means only. The following is provided as a summary of occasions when verbal coordination is required: —— In the event of an AIDC outage —— Aircraft operating under any of the following conditions: —— Weather deviations —— Offset track —— Block level —— Occurrence of any condition which results in change of aircraft profile (e.g. DCT routing, level or time at COP), once EST message has been sent —— Verbal Coordination shall be used if the aircraft is unable to reach the coordinated level 15 minutes prior to the TCP or is deviated from its track —— On receipt of an AIDC messaging alert for a particular flight —— Coordination regarding aircraft operating or suspected to be under unlawful interference, radio communication failure or emergency;
45
—— Whenever there is any doubt with regard to the final coordination conditions or any other circumstances that warrant verbal communication. 1.5.
Table 2 and Table 3 detail the AIDC parameters and messages to be used between [FIR 1] and [FIR 2].
AIDC message parameters [FIR 1] / [FIR 2]
FIR
AIDC Address
[FIR 1]
[FIR 1 AIDC Address]
[FIR 2]
[FIR 1 AIDC Address] Table 2 - AIDC Addresses
Message ABI
Parameter (VSP)
Notes
5-60 minutes prior to COP (Note: An updated ABI will not be sent once an EST has been sent)
EST
40 minutes prior to COP
CPL
Manually by when required
ACP
Sends automatic ACP on receipt of EST or PAC
ABI is sent automatically and is transparent to ATCO. ABI automatically updates flight plan. [FIR 1]: EST is required for track generation. [FIR 1]: If ACP not received within four minutes the sending ATCO is alerted. [FIR 2]: If ACP is not received within five minutes the sending ATCO is alerted.
TOC
Sent automatically five minutes prior to boundary
AOC
Sent automatically on ATCO acceptance of a TOC
MAC
As per ICD
LRM
As per ICD. ATCO alerted on receipt
LAM
As per ICD. ATCO alerted on non-receipt Table 3 - Message Parameters
Communication (Air – Ground – Air) Primary system FANS1/A datalink communications will be used as the primary means of communications. HF will be used for aircraft not FANS1/A equipped.
—— The AIDC hand-off is unsuccessful or —— Outstanding CPDLC messages exist at the time of receipt of the AOC preventing the automatic End Service message from being transmitted.
2.2.
2.2.2. CPDLC Transfer Twenty-two minutes prior to the TCP the handing over FIR sends the Next Data Authority [next FIR designator] followed by address forwarding. Approximately five minutes prior to the
2. 2.1.
Datalink Procedures
2.2.1. Manual End Service ATCOs shall ensure that a CPDLC uplink message 161 – END SERVICE is manually sent to an outbound flight in the event that:
46
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
boundary the handing over FIR shall instruct the aircraft via CPDLC to MONITOR [“next FIR”] [frequency]. Upon receipt of downlink response, the handing over FIR shall send uplink message 161 – END SERVICE. If the address forwarding is unsuccessful the handing over FIR shall follow the procedures outlined below: —— Approximately five minutes prior to the TCP the handing over FIR will instruct the aircraft via CPDLC to: —— Manually disconnect from [FIR 1 code] then Logon to [FIR 2 code] —— MONITOR [“next FIR”] [frequency] 2.3. Address forwarding and next data authority [FIR 1] / [FIR 2] shall send automatic Next Data Authority (NDA) and Address Forwarding (CAD) for data link aircraft as per Table 4 - Datalink Parameters. 2.4.
Responsibility for SAR alerting services Irrespective of the aircraft’s position with regard to the FIR boundary, the CDA (Current Data Authority) will be responsible for SAR alerting services with respect to that particular flight.
FIR
Next Data Authority (NDA) and Address Forwarding (CAD)
[FIR 1]
Auto NDA sent 22 minutes prior to the FIR boundary Auto CAD sent 20 minutes prior to the FIR boundary
[FIR 2]
Auto NDA sent 22 minutes prior to the FIR boundary Auto CAD sent 20 minutes prior to the FIR boundary Table 4 - Datalink Parameters
47
Appendix E:
e. KZMA and MUFH may agree to modify the parameters listed in a) and c) as necessary to enhance the automation system.
Example of an Addendum to Existing LOA Automated Data Exchange (ADE) 1. PURPOSE: Establishes procedures for the automated data exchange of active flight plan information between Miami Center (KZMA) and Havana Center (MUFH). Subsequent sub-sections will introduce abbreviations, definitions and operational procedures to be used by respective facilities. 2. OPERATIONAL PROCEDURES FOR ADE IS DESCRIBED IN THIS SECTION. These procedures will evolve as subsequent phases are introduced. This Attachment may be deleted and absorbed into the main body of the Letter of Agreement when the final phase is implemented and with mutual agreement. 3. ABBREVIATIONS: ADE: Automated data exchange CFL: Coordinated flight level CPL: Active flight plan FPL: Proposed flight plan LAM: Logical acknowledgement message UTM: Unsuccessful transmission message LRM: Logical reject message 4. PROCEDURES: 4.1. ADE is the primary method of exchanging flight data information between KZMA and MUFH. 4.2. Coordination. 4.2.1. The parameter times for the interface are as follows: a. Not less than 15 minutes - MUFH CPL send time (prior to boundary). b. 60 seconds - MUFH LAM time-out (time to wait for LAM from KZMA). c. Not less than 13 minutes - KZMA CPL send time (prior to boundary) d. 60 seconds - KZMA LAM time-out (time to wait for LAM from MUFH).
4.2.2. The transferring facility must ensure that CPLs are verified with the receiving facility for all UTMs. 4.2.3. MUFH will indicate “NO FPL IN MUFH” in the remarks field of the CPL when a FPL is not received by MUFH. 5.
FLIGHT LEVEL COORDINATION 5.1. Aircraft will be assigned flight levels in accordance with paragraph 6.2 in this Letter of Agreement without CFL update. 5.1.1. All Miami Terminal arrivals over TADPO must be at FL360 or below. 5.1.2. Departures overflying TANIA must be at FL280 or below. 6. SCHEDULED AND NON-SCHEDULED OUTAGES 6.1. When ADE is disabled the primary method of exchanging FPL messages will be the MEVA dial line in accordance with paragraph 12.2. 6.2. The MUFH and KZMA operational managers must mutually agree when to effect and or re-establish a transition to/from the MEVA dial line and ADE. 6.3. KZMA and MUFH will coordinate, in advance or as soon as practical, all scheduled and non-scheduled outages which impact ADE.
48
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
Appendix F Addendum to Existing LOA between ATSU1 and ATSU2 ACCS The implementation of AIDC between ATSU1 and ATSU2 ACCs has been finalized. The existing Letter of Agreement between these two ACCs requires to be amended. Following addendum to the existing Letter of Agreement between ATSU1 and ATSU2 has been drafted for approval. 1.
Exchange of estimates (Paragraph XX may be replaced / renumbered as below) 1.1. Estimates/Coordination Messages (Revisions) in case of AIDC The AIDC procedures for movement and control of ATS messages shall apply as follow: 1.1.1. The format of AIDC messages are as defined by the Asia/Pacific Regional AIDC Interface Control Document (ICD) Version 2 and as amended from time to time, unless described otherwise in this LOA. 1.1.2. A successful coordination via AIDC will be assumed to occur on receipt of an ACP message in response to CDN after EST message. 1.1.3. Voice coordination is not required when AIDC messaging has been successful. 1.1.4. Due any reason for a particular flight or for other reasons as whole, if AIDC messaging is not to be carried out and voice coordination has been accomplished. 1.1.5. Different occasions/matters which are not included in the current version of AIDC messaging but requiring voice coordination is given in paragraph XXXX. 1.1.6.
Acceptance of a CDN message is
approval of the flight’s profile and requires no voice coordination. 1.1.7. If there is any doubt with final coordination data, voice coordination shall be used for confirmation. 1.1.8. Receipt of a MAC message shall not be interpreted as cancellation of flight plan as it indicates that all previous notifications and coordination are no longer relevant to receiving unit for that flight. Voice coordination must be conducted by the transferring unit to confirm the status of the flight. 1.1.9. Each facility shall advise the other facility of any known equipment outage that affects AIDC. In the event of AIDC outage, voice coordination procedures will apply. 1.1.10. Transfer of control points (TCPs) will be same as defined in para XXX of the existing LOA. Units shall send any revised estimates through AIDC that vary by 3 minutes or more. 1.1.11. Means of communication for coordination between adjacent units shall be in the following order of priority: a. AIDC Messages (with mutual coordination) b. ATS direct speech circuits c. Telephone System 1.1.12. Voice communication on existing hot lines will be carried out as given below: d. In the event of an AIDC outage, or; e. Aircraft operating in any of the following conditions: 1. Block level clearance 2. Time constraints 3. Weather deviations 4. Off track due traffic 5. Application of Mach number technique
49
6. When an ACP has not received 7. On receipt of a MAC message 8. In case of any doubt regarding final coordination 9. In case of emergency to an aircraft 10. To resolve queries regarding civil or 1.1.13.
military clearance 11. To pass information of VVIP movements. 12. For coordination while releasing traffic in climbing or descending phase
AIDC MEASSAGES PARAMETERS:
Messages
Parameter
Notes
ABI
ATSU1: Sends ABI 60 minutes prior to boundary.
ATSU1 and ATSU2: ABI is sent automatically and is transparent to the ATCO. Updated ABI’s will be sent
ATSU2: Sends ABI 50 minutes prior to boundary on routes
automatically if there is any change to profile. ABI
AXXX / BXXX and 40 minutes on CXXX
automatically updates the receiving unit’s flight data record.
EST
ATSU1: Sends EST messages 30 minutes prior to boundary.
ATSU1 and ATSU2: EST is sent automatically and updates the receiving unit. EST messages changed the
ATSU2: Sends EST messages 45 minutes prior to boundary
profile “CORG”.
on routes AXXX / BXXX and 30 minutes on CXXX CDN
ATSU1 and ATSU2: CDN messages are sent by either the
ATSU1 and ATSU2: If the ATSU1 ACC does not like the
transferring or receiving facility to propose a change once
current clearance and (boundary crossing conditions), in
the coordination process has been completed, i.e., EST sent
negotiation process is carried out using CDN.
and ACP received. CDNs must contain all applicable profile restrictions e.g. waypoint, estimate and level. The use of CDN does not support profiles on weather deviations, speed assignment, block altitudes etc., to which verbal coordination is required. PAC
ACP
ATSU1 and ATSU2: PAC messages will normally be sent
ATSU1 and ATSU2: Will respond to a PAC message with
when the time criteria from the departure point to the
an REJ/ACP. PAC messages shall be verbally verified
boundary is less than that stipulated in the FPL.
with receiving facility.
ATSU1 and ATSU2: ACP messages are in reply to an EST/
ATSU1 and ATSU2: The negotiation process is
CDN message if conditions specified in EST/CDN are
terminated when the accepting ATSU signals its
acceptable to ATCO.
acceptance of the coordination condition using an ACP message. If the ACP is not received within three minutes, the ATCO should repeat the process once again.
TOC
ATSU1 and ATSU2: Transfer of Control
ATSU1 and ATSU2: A TOC is sent after coordination occurs but before the boundary is crossed to the accepting ATSU. The TOC informs the accepting ATSU that it now has controlled authority of the aircraft.
AOC
ATSU1 and ATSU2: Assumption of Control
ATSU1 and ATSU2: The accepting ATSU is now the controlling ATSU
MAC
ATSU1 and ATSU2: MAC messages are sent when a change
ATSU1 and ATSU2: Receipt of a MAC message must not
to the route makes the other facility no longer the “next”
be interpreted as meaning that the flight plan has been
responsible unit.
cancelled. Voice coordination must be conducted by the transferring ATCO to confirm the status of the flight.
REJ
ATSU1 and ATSU2: REJ messages are sent in reply to a CDN
ATSU1 and ATSU2: REJ messages are sent only as a
message when the requested change is unacceptable.
response to a CDN message.
50
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
NOTE: In case of outage/failure of AIDC contingency procedures as given in paragraph 1.3.2 and 1.3.3, the measures in paragraphs 6.3 and 6.4 will be implemented:
estimates are through AIDC as mentioned in paragraph 1.1. In case of AIDC failure, the procedure given in paragraph 1.2.1 will be implemented.
1.2. Estimates/Coordination messages (Revisions) in case of AIDC Failure 1.2.1. The estimate message (EST) shall be transmitted in sufficient time to permit receipt by the relevant ACC normally no later than 30 minutes prior to the time the flight is estimated to pass over the transfer of control point. The EST message shall contain information in the format mentioned in paragraph 21.3.3
6.3.2. Estimates (EST) messages shall be sent, using the appropriate “Voice circuit: (Land Line or HF Radio), for all flights crossing the transfer of control point in sufficient time to permit receipt by the accepting ATC unit not less than 30 minutes but not earlier than one hour before the estimated time for the aircraft to be over the transfer of control point. The message shall be transmitted to aircraft in accordance with the phraseology specified in Doc.4444 ATM/507 chapter 12 paragraph 3.5.
1.2.2. Revision to the estimate at the transfer of control point shall be passed to the receiving ATC unit if the revised estimate time different by three minutes or more. 1.2.3. In the event that communication with the aircraft is not established with five minutes after the estimated time over the transfer of control point, the receiving ATC unit shall notify the transferring ATC unit of this fact. 1.3. Message Contents 1.3.1. Coordination messages exchange between the ATS units shall contain the following data in the order listed: a. Aircraft identification including SSR code. b. Type of aircraft. c. Departure aerodrome. d. Estimated time/level over the transfer of control point. e. True air speed/Mach number assigned if any restriction apply. f. Destination aerodrome g. RVSM status h. Any other information as required. 6.3. Estimates 6.3.1. The primary means of exchanging
6.3.3. Estimates messages shall include the transponder code assigned by the transferring ACC. 6.3.4. If the point of departure of an aircraft is not at a sufficient distance from the common FIR boundary to permit transmission of the estimate 30 minutes before the aircraft estimates TCP, the transferring unit shall forward the flight data to be accepting unit prior to departure of aircraft. 6.4. Revisions 6.4.1. The primary means of exchange of revision are through AIDC as mentioned in paragraph 1.1. 6.4.2. Whenever there will be a variation of three minutes or more from the estimated time that was originally passed or when a change of the cleared level and/or crossing condition is planned “Revision and other “Coordination: (CDN) messages shall normally be sent using the appropriate “Voice Circuit” (land Line or HF radio), as soon as practicable. 6.4.3.
The transferring ATS unit shall send
51
“Revision” and other “coordination” messages to the accepting ATS units at least 20 minutes prior to the aircraft estimated time over the transfer of control point. 6.4.4. In case of non-availability of the ATS “Voice Circuit” between the ATS units concerned the transferring ATS units shall send the relevant data to the accepting ATS unit via the AFTN. 6.4.5. “Estimates”, “Revisions” and other “coordination” messages when sent the AFTN require an “acknowledgment” from the acceptance ATS units in the form of an “acceptance” (ACP) message, to be sent to the transferring ATS units 6.4.6. After coordination of the transfer of control conditions, the resulting ATC Clearance shall not be changed by the transferring ATS unit unless prior agreement has been affected between the ATS units concerned. 6.4.7. The use of communication system for coordination between adjacent ATS units shall be the following order of priority: —— Direct speech circuit —— IDD Telephone —— AFTN 6.4.8. In case of flights departing from aerodromes where, due to their proximity to the transfer control point [refer sub section 2.2.1 Note b] application of the procedures set out in paragraph 6.4.6 above would not be possible after departure, coordination between the transfer of ATS units and the accepting ATS units shall be effected prior to the issuance of accepting clearance to the aircraft concerned. (See ICAO DOC 4444, ATM/501 chapter 10 paragraph 10.4.2.1) 6.4.9. In case of primary circuit failure, each unit shall endeavour to utilise any other
available means of communication including ISD telephone 6.4.10. Provided that continuous voice communication is available, the transmission DEP/ EST/CHG messages by AFTN shall not be required. 10.
Authorised Signature
52
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
Acronyms 4D
Four dimensional
AAI
Airports Authority of India
ABI
Advance boundary information (message)
ACC
Area control centre
ACI
Airports Council International
ACP
Acceptance (message)
ADE
Automated data exchange
ADS-B
Automatic dependent surveillance-broadcast
ADS-C
Automatic dependent surveillance-contract
AFN
Air traffic services facilities notification
AFTN
Aeronautical fixed telecommunication network
AIDC
ATS inter-facility data communication
AIP
Aeronautical information publication
AIRAC
Aeronautical information regulation and control
AMHS
Automatic message handling system
ANSP
Air navigation service provider
AOC
Acceptance of control (message)
APAC
Asia and Pacific
ARTCC
Air Route Traffic Control Center
ASBU
Aviation System Block Upgrades
ATC
Air traffic control
ATCO
Air traffic control officer
ATFM
Air traffic flow management
ATM
Air traffic management
ATN B1
Aeronautical Telecommunication Network Baseline 1 (data link) applications)
ATOP
Advanced Technologies and Oceanic Procedures (system)
ATS
Air traffic service
ATSU
Air traffic service unit
B0
Block 0 (up to 2018)
B1
Block 1 (2018 to2023)
B2
Block 2 (2023 to 2028)
B3
Block 3 (2028 and onwards)
CAATS
Canadian Automated Air Traffic System
CANSO
Civil Air Navigation Services Organisation
CCO
Continuous climb operations
CDA
Current data authority
CDN
Coordination (message)
CDO
Continuous descent operations
CNS
Communication, navigation and surveillance
COCESNA
Corporación Centroamericana de Servicios de Navegación Aérea
COP
Coordination point
CPDLC
Controller-pilot data link communication
53
CPL
Current flight plan
CR1
Connection request (message)
CRC
Cyclic redundancy check
CZVR
Vancouver ACC
DARP
Dynamic airborne reroute procedure
EST
Estimate (message)
EUR
European
FAA
United States Federal Aviation Administration
FAN
Future air navigation system application notification (message)
FANS 1/A
Future Air Navigation System (data link applications)
FCN
Future air navigation system completion notification (message)
FDPS
Flight data processing system
FF-ICE (FICE)
Flight and Flow Information for a Collaborative Environment
FIR
Flight information region
FIRBX
CANSO FIR Boundary Crossings Task Force
FN_CAD
Air traffic services facilities notification contact advisory (message)
FPL
Filed flight plan
GANP
Global Air Navigation Plan (ICAO Doc 9750)
GASP
ICAO Global Aviation Safety Plan 2014-2016
GOLD
Global Operational Data Link Document
HMI
Human-machine interface
IATA
International Air Transport Association
ICAO
International Civil Aviation Organization
ICD
Interface control document
IFATCA
International Federation of Air Traffic Controllers’ Associations
IFPS
Initial flight plan processing system
IP
Internet Protocol
KZMA
Miami Air Route Traffic Control Center
KZNY
New York Air Route Traffic Control Center
KZOA
Oakland Air Route Traffic Control Center
LAM
Logical acknowledgment message
LOA
Letter of agreement
LRM
Logical rejection message
MAC
Coordination cancellation (message)
METAR
Meteorological aviation report
MID
Middle East
MUFH
Havana area control centre
NACC
North American, Central American and Caribbean
NAM
North American
NAM ICD
North American Interface Control Document
NAT
North Atlantic
NDA
Next data authority
NOPS
Network operations
54
Automation Interface Between Flight Information Regions Best Practice Guide for ANSPs
NOTAM
Notice to Airmen
ODF
Optional data field
OLDI
Online data interchange
PAC
Pre-activation (message)
PAN AIDC ICE
Pan Regional (NAT and APAC) Interface Control Document for ATS
PANS ATM
Procedures for Air Navigation Services - Air Traffic Management
PBN
Performance-based navigation
PIA
Performance improvement area
REJ
Rejection (message)
SAM
South American
SESAR
Single European Sky ATM Research
SID
Standard instrument departure
SIGMET
Significant Meteorological Information
SMM
Safety Management Manual (ICAO Doc 9859)
SMS
Safety management system
SSR
Secondary surveillance radar
STAR
Standard instrument arrival
SWIM
System-wide Information Management
TAF
Terminal aerodrome forecast
TBO
Trajectory-based operations
TCP
Transfer of control point
TDM
Track definition message
TOC
Transfer of control (message)
U.S.
United States
UPR
User preferred route
VHF
Very high frequency
VOR
VHF omni-directional radio range
VSP
Variable system parameter
ZAK
Oakland ATOP sector
CANSO Members CANSO – the Civil Air Navigation Services Organisation – is the global voice of air traffic management (ATM) worldwide. CANSO Members support over 85% of world air traffic. Members share information and develop new policies, with the ultimate aim of improving air navigation services (ANS) on the ground and in the air. CANSO represents its Members’ views to a wide range of aviation stakeholders, including the International Civil Aviation Organization, where it has official Observer status. CANSO has an extensive network of Associate Members drawn from across the aviation industry. For more information on joining CANSO, visit canso.org/join-canso
civil air navigation services organisation
Full Members - 87 — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Aeronautical Radio of Thailand (AEROTHAI) Aeroportos de Moçambique Air Navigation and Weather Services, CAA (ANWS) Air Navigation Services of the Czech Republic (ANS Czech Republic) AirNav Indonesia Air Traffic & Navigation Services (ATNS) Airports and Aviation Services Limited (AASL) Airports Authority of India (AAI) Airports Fiji Limited Airservices Australia Airways New Zealand Albcontrol Austro Control Avinor AS AZANS Azerbaijan Belgocontrol Bulgarian Air Traffic Services Authority (BULATSA) CAA Uganda Cambodia Air Traffic Services Co., Ltd. (CATS) Civil Aviation Authority of Bangladesh (CAAB) Civil Aviation Authority of Botswana Civil Aviation Authority of Mongolia Civil Aviation Authority of Nepal (CAAN) Civil Aviation Authority of Singapore (CAAS) Civil Aviation Authority of the Philippines Civil Aviation Regulatory Commission (CARC) COCESNA Croatia Control Ltd DCA Myanmar Department of Airspace Control (DECEA) Department of Civil Aviation, Republic of Cyprus DFS Deutsche Flugsicherung GmbH (DFS) Dirección General de Control de Tránsito Aéreo (DGCTA) DSNA France Dubai Air Navigation Services (DANS) Dutch Caribbean Air Navigation Service Provider (DC-ANSP) ENAV S.p.A: Società Nazionale per l’Assistenza al Volo ENAIRE Estonian Air Navigation Services (EANS) Federal Aviation Administration (FAA) Finavia Corporation General Authority of Civil Aviation (GACA) Ghana Civil Aviation Authority (GCAA) HungaroControl Pte. Ltd. Co. Instituto Dominicano de Aviacion Civil (IDAC) Israel Airports Authority (IAA) Irish Aviation Authority (IAA) ISAVIA Ltd Japan Air Navigation Service (JANS) Kazaeronavigatsia Kenya Civil Aviation Authority (KCAA) Latvijas Gaisa Satiksme (LGS)
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Letové prevádzkové Služby Slovenskej Republiky, Štátny Podnik Luchtverkeersleiding Nederland (LVNL) Luxembourg ANA Maldives Airports Company Limited (MACL) Malta Air Traffic Services (MATS) National Airports Corporation Ltd. National Air Navigation Services Company (NANSC) NATS UK NAV CANADA NAV Portugal Naviair Nigerian Airspace Management Agency (NAMA) Office National de LÁviation Civile (OFNAC) Office National Des Aéroports (ONDA) ORO NAVIGACIJA, Lithuania PIA “Adem Jashari” - Air Control J.S.C. PNG Air Services Limited (PNGASL) Polish Air Navigation Services Agency (PANSA) Public Authority for Civil Aviation - Oman (PACA) ROMATSA Sakaeronavigatsia Ltd SENEAM Serbia and Montenegro Air Traffic Services Agency (SMATSA) Serco skyguide Slovenia Control State Airports Authority & ANSP (DHMI) Sudan Air Navigation Services Department Swaziland Civil Aviation Authority Tanzania Civil Aviation Authority Trinidad and Tobago CAA The LFV Group Ukrainian Air Traffic Service Enterprise (UkSATSE) U.S. DoD Policy Board on Federal Aviation Viet Nam Air Traffic Management Corporation (VATM)
Gold Associate Members - 11 — — — — — — — — — — —
Airbus ProSky Anhui Sun Create Electronics Co., Ltd. Boeing FREQUENTIS AG GroupEAD Europe S.L. Harris Corporation Inmarsat Plc Lockheed Martin Raytheon Finmeccanica Thales
Silver Associate Members - 66 — — — —
42 Solutions B.V. Adacel Inc. Aeronav Inc. Aireon
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Air Traffic Control Association (ATCA) ALES a.s. Association Group of Industrial Companies “TIRA” Corporation ATAC ATCA – Japan ATECH Negócios em Tecnologia S/A Aveillant Aviation Advocacy Sarl Aviation Data Communication Corp (ADCC) Avibit Data Processing GmbH Avitech GmbH Bayanat Engineering Group Brüel & Kjaer EMS CGH Technologies, Inc. Comsoft GmbH CSSI, Inc. Airbus Defence and Space EIZO Technologies GmbH European Satellite Services Provider (ESSP SAS) Emirates ENAC Entry Point North Era Corporation Esterline Etihad Airways Guntermann & Drunck GmbH Helios Honeywell International Inc. / Aerospace IDS – Ingegneria Dei Sistemi S.p.A. Indra Navia AS Indra Sistemas INECO Integra A/S Intelcan Technosystems Inc. International Aero Navigation Systems Concern, JSC Jeppesen JMA Solutions Jotron AS Kongsberg Defence & Aerospace AS LAIC Aktiengesellschaft LEMZ R&P Corporation Lufthansa Systems FlightNav AG MDA Systems Ltd. Metron Aviation Micro Nav Ltd The MITRE Corporation – CAASD MovingDot NEC Corporation NLR Northrop Grumman NTT Data Corporation Rockwell Collins, Inc. Rohde & Schwarz GmbH & Co. KG Saab AB Saab Sensis Corporation Saudi Arabian Airlines SENASA SITA Snowflake Software Ltd STR-SpeechTech Ltd. Tetra Tech AMT Think Research Limited
Membership list correct as of 6 June 2016. For the most up-to-date list and organisation profiles go to canso.org/canso-members