COMMISSION IMPLEMENTING REGULATION (EU) 2021/116

2.2.2021 | EN | Official Journal of the European Union | L 36/10 ---|---|---|--- * * * COMMISSION IMPLEMENTING REGULATION (EU) 2021/116 of 1 February 2021 on the establishment of the Common Project One supporting the implementation of the European Air Traffic Management Master Plan provided for in Regulation (EC) No 550/2004 of the European Parliament and of the Council, amending Commission Implementing Regulation (EU) No 409/2013 and repealing Commission Implementing Regulation (EU) No 716/2014 (Text with EEA relevance) THE EUROPEAN COMMISSION, Having regard to the Treaty on the Functioning of the European Union, Having regard to Regulation (EC) No 550/2004 of the European Parliament and of the Council of 10 March 2004 on the provision of air navigation services in the single European sky (the service provision Regulation) (1), and in particular Article 15a thereof, Whereas: (1) | The Single European Sky (‘SES’) aims at modernising the European air traffic management (‘ATM’) by improving its safety and efficiency. It contributes to the reduction of greenhouse gas emissions. The Single European Sky Air Traffic Management Research and Development (‘SESAR’) project constitutes the technological pillar of the SES. ---|--- (2) | Modernisation should be steered to achieving the European ATM Master plan’s vision of a digital European sky. ---|--- (3) | Effective ATM modernisation requires the timely implementation of innovative ATM functionalities. Those functionalities should be based on technologies that increase the levels of automation, cyber-secure data sharing, and connectivity in ATM. Those technologies should also increase the levels of virtualisation of the European ATM infrastructure and air traffic service provision in all types of airspace. ---|--- (4) | Commission Implementing Regulation (EU) No 409/2013 (2) establishes a framework for SESAR deployment setting out the requirements for the content of common projects, for their setup, adoption, implementation and monitoring. ---|--- (5) | Common projects should only include ATM functionalities that are ready for implementation, that require synchronised implementation and that contribute significantly to achieving Union-wide performance targets. ---|--- (6) | Common projects are implemented through projects coordinated by the deployment manager in accordance with the deployment programme. ---|--- (7) | The Pilot Common Project established by Commission Implementing Regulation (EU) No 716/2014 (3) was a pilot initiative to implement ATM functionalities based on SESAR solutions in a coordinated and synchronised manner and served as a testbed for the governance and incentive mechanisms of the SESAR deployment framework established in Implementing Regulation (EU) No 409/2013. ---|--- (8) | A review carried out in accordance with Article 6 of Implementing Regulation (EU) No 716/2014 concluded that the Pilot Common Project achieved positive operational changes in the European ATM. However, the variable level of maturity for implementation of ATM functionalities and its impact on the synchronisation of their implementation reduced the effectiveness of the Pilot Common Project. ---|--- (9) | The results of the review support the closing of the pilot phase of common projects and the evolution of the Pilot Common Project into a more focused and mature common project. The review has confirmed that all functionalities carried over from the Pilot Common Project to the Common Project One have obtained the technical readiness for implementation. ---|--- (10) | Common projects aim at implementing interoperable ATM functionalities in a synchronised manner. Synchronised implementation of common projects is instrumental to achieve timely network-wide performance benefits, namely by multiple stakeholders from several Member States synchronising and coordinating investments, work plans, procurement and training activities. ---|--- (11) | The content of Common Project One should take account of contributions gathered from the deployment manager, the SESAR Joint Undertaking, ATM stakeholders and a cost-benefit analysis. ---|--- (12) | The Common Project One should continue to mandate the implementation of the six Pilot Common Project ATM functionalities albeit with an updated focus, based on the criteria of contributing to achieving essential operational changes in the European ATM Masterplan, maturity and the need for synchronised implementation. ---|--- (13) | The sub-functionalities to be included in the present act should be confined to those that can be implemented by 31 December 2027. ---|--- (14) | Implementing Regulation (EU) No 716/2014 has been incorporated into the Agreement on the European Economic Area (4) as well as into the Agreement between the European Community and the Swiss Confederation on Air Transport (5), with the effect of including the Oslo Gardermoen, Zürich Kloten and Geneva airports into its scope insofar as ATM functionalities 1, 2, 4 and 5 are concerned. To achieve the full network benefits, it would be desirable that those airports equally implement Common Project One, in the context of the relevant agreements. ---|--- (15) | Extended arrival management, integration of arrival manager and departure manager in high density terminal manoeuvring areas is expected to improve the accuracy of the approach trajectory and facilitate air traffic sequencing at an earlier stage. Implementation of ATM sub-functionality performance based navigation (PBN) is regulated under Commission Implementing Regulation (EU) 2018/1048 (6) and accordingly should no longer be covered by the common project. ---|--- (16) | Airport integration and throughput should facilitate the provision of approach and aerodrome control services by improving runway safety and throughput, enhancing taxi integration and safety and reducing hazardous situations on the runway. ---|--- (17) | Combined operation of flexible airspace management and free route airspace is expected to enable airspace users to fly as closely as possible to their preferred trajectory without being constrained by fixed airspace structures or fixed route networks. The implementation of the flexible airspace management under this regulation should happen in conjunction with Commission Regulation (EC) No 2150/2005 on the Flexible Use of Airspace (7). ---|--- (18) | Network collaborative management should improve the performance of the European ATM network, notably by increasing the airspace capacity and flight efficiency through exchange, modification and management of trajectory information. ---|--- (19) | System wide information management should enable the development, implementation and evolution of services for information exchange through standards, infrastructure and governance enabling the management of information and its exchange between operational stakeholders via interoperable services. ---|--- (20) | Initial trajectory information sharing is expected to allow the aircraft downlink of trajectory information, its distribution on the ground and its improved use by the ground air traffic control (‘ATC’) systems and Network Manager Systems with fewer tactical interventions and improved de-confliction situation. ---|--- (21) | The Pilot Common Project review highlighted the need to improve or clarify provisions of Implementing Regulation (EU) No 409/2013, to increase the effectiveness of common projects and facilitate their implementation. ---|--- (22) | Some ATM functionalities or sub-functionalities that are essential components for a common project may not be ready for implementation at the time of entry into force of this Regulation. To ensure consistency of common projects and maintain momentum to finalise the industrialisation processes, those functionalities should be included in the common project with industrialisation and implementation target dates. If the industrialisation processes are not successfully finalised by the industrialisation target date, those functionalities should be withdrawn from the common project and considered for future ones. ---|--- (23) | The content of common projects is developed with the contribution of air navigation service providers, airport operators, airspace users and the manufacturing industry participating in the SESAR Joint Undertaking, in the deployment manager and in their respective consultation groups. Those consultative mechanisms and the public consultation performed by the Commission provide an appropriate assurance of stakeholders’ endorsement of common projects. Therefore, it is no longer necessary to set up an additional group of representatives of airspace users. ---|--- (24) | Common projects represent mandatory investments by all ATM stakeholders. Air navigation service providers and the Network Manager are subject to the Union-wide performance scheme in accordance with Commission Implementing Regulation (EU) 2019/317 (8) aiming to achieve the Union-wide performance targets. Those investments should be included in the Member States’ performance plans and in the Network Performance Plan. ---|--- (25) | In the light of the ongoing COVID-19 pandemic, the Commission should continue following the air traffic developments and monitor the implementation of the regulation with a view of taking action as appropriate. ---|--- (26) | For the sake of clarity and to indicate the closure of the pilot phase of the first common project, it is appropriate to repeal Implementing Regulation (EU) No 716/2014. ---|--- (27) | The measures provided for in this Regulation are in accordance with the opinion of the Single Sky Committee, ---|--- HAS ADOPTED THIS REGULATION: Article 1 Establishment of the Common Project One The Common Project One (‘CP1’) is established to support the implementation of the European Air Traffic Management (‘ATM’) Master Plan. Article 2 Definitions For the purposes of this Regulation, the definitions set out in Article 2 of Implementing Regulation (EU) No 409/2013 shall apply. The following definitions shall also apply: (1) | ‘airport – collaborative decision making’ or ‘A-CDM’ means a process by which decisions related to air traffic flow and capacity management (‘ATFCM’) at airports are made on the basis of interaction between operational stakeholders and other actors involved in ATFCM and which aims at reducing delays, improving the predictability of events, optimising the utilisation of resources and reducing environmental impacts. ---|--- (2) | ‘airport operations plan’ or ‘AOP’ means a single, common and collaboratively agreed rolling plan available to all relevant operational stakeholders which provides a common situational awareness for optimised processes; ---|--- (3) | ‘network operations plan’ or ‘NOP’ means a plan, including its supporting tools, developed by the Network Manager in coordination with the operational stakeholders to organise its operational activities in the short and medium term in accordance with the guiding principles of the network strategic plan and which includes, for the European route network design-specific part of the network operations plan, the European route network improvement plan; ---|--- (4) | ‘to operate an ATM functionality’ means putting in service the ATM functionality in question which is fully used in daily operations; ---|--- (5) | ‘AF 1’ or ‘extended arrival management and integrated arrival management (‘AMAN’)/departure management (‘DMAN’) in the high-density terminal manoeuvring areas’ means an ATM functionality that improves the precision of the approach trajectory and facilitates air traffic sequencing at an earlier stage and the optimum utilisation of runways, integrating the AMAN and DMAN sequences, by deploying specific ATM solutions.; ---|--- (6) | ‘AF 2’or ‘airport integration and throughput’ means an ATM functionality that facilitates the provision of approach and aerodrome control services by improving runway safety and throughput, enhancing taxi integration and safety and reducing hazardous situations on the runway; ---|--- (7) | ‘AF 3’ or ‘flexible airspace management and free route airspace’ means an ATM functionality that combines the operation of flexible airspace management and free route and enables airspace users to fly as closely as possible to their preferred trajectory without being constrained by fixed airspace structures or fixed route networks. It allows operations that require segregation to take place safely and flexibly and with minimum impact on other airspace users; ---|--- (8) | ‘AF 4’ or ‘network collaborative management’ means an ATM functionality that improves the European ATM network performance, notably capacity and flight efficiency, through exchange, modification and management of trajectory information. AF 4 contributes to the implementation of a collaborative network for planning and decision-making, which enables the implementation of flight- and flow-centric operations; ---|--- (9) | ‘AF 5’ or ‘system wide information management (SWIM)’ means an ATM functionality that consists of standards and infrastructure enabling the development, implementation and evolution of services for information exchange between operational stakeholders via interoperable services which are built on SWIM standards and are delivered through an internet protocol; ---|--- (10) | ‘AF 6’ or ‘initial trajectory information sharing’ or ‘i4D’ means an ATM functionality that improves the use of target times and trajectory information, including where available the use of on-board 4D trajectory data by the ground ATC system and Network Manager systems, implying fewer tactical interventions and improved de-confliction situation. ---|--- Article 3 ATM functionalities and their deployment 1\. The CP1 shall comprise the following ATM functionalities: (a) | extended arrival management and integrated AMAN/DMAN in the high-density terminal manoeuvring areas; ---|--- (b) | airport integration and throughput; ---|--- (c) | flexible airspace management and free route airspace; ---|--- (d) | network collaborative management; ---|--- (e) | system wide information management; ---|--- (f) | initial trajectory information sharing. ---|--- 2\. The operational stakeholders identified in the Annex to this Regulation shall implement the ATM functionalities referred to in paragraph 1 and implement the associated operational procedures in accordance with the Annex to this Regulation. The military operational stakeholders shall deploy those ATM functionalities only to the extent necessary to comply with the fourth and fifth subparagraphs of point 3.2 of Annex VIII to Regulation (EU) 2018/1139 of the European Parliament and of the Council (9). Article 4 Amendments to Implementing Regulation (EU) No 409/2013 Implementing Regulation (EU) No 409/2013 is amended as follows: (1) | Article 2 is amended as follows: | (a) | points (1), (2) and (3) are replaced by the following: | ‘(1) | ”SESAR Joint Undertaking” means the body established under Council Regulation (EC) No 219/2007 (*1), or its successor, entrusted with the task of managing and coordinating the development phase of the SESAR project; ---|--- (2) | “charging scheme” means the scheme established by Commission Implementing Regulation (EU) 2019/317 (*2); ---|--- (3) | “ATM functionality” means a group of ATM interoperable operational functions or services related to trajectory, airspace and surface management or to information sharing within the en-route, terminal, airport or network operating environments; ---|--- (*1) Council Regulation (EC) No 219/2007 of 27 February 2007 on the establishment of a Joint Undertaking to develop the new generation European air traffic management system (SESAR) (OJ L 64, 2.3.2007, p. 1)." (*2) Commission Implementing Regulation (EU) 2019/317 of 11 February 2019 laying down a performance and charging scheme in the single European sky and repealing Implementing Regulations (EU) No 390/2013 and (EU) No 391/2013 (OJ L 56, 25.2.2019, p. 1).’;" (b) | the following points (3a) and (3b) are inserted: | ‘(3a) | ”ATM sub-functionality” means an integral part of an ATM functionality consisting of an operational function or service, contributing to the overall scope of the functionality; ---|--- (3b) | “SESAR solution” means an output of the SESAR development phase, introducing new or improved standardised and interoperable technologies and harmonised operational procedures supporting the implementation of the European ATM Master plan;’; ---|--- (c) | the following point (4a) is inserted: | ‘(4a) | “synchronised implementation” means an implementation of ATM functionalities in a synchronised way over a defined geographical area, which includes at least two Member States within the EATMN, or between air and ground operational stakeholders based on a common planning that includes implementation target dates and the relevant transitional measures for progressive deployment and involving multiple operational stakeholders;’; ---|--- (d) | point (6) is replaced by the following: | ‘(6) | “implementation” means, in reference to ATM functionalities, the procurement, installation, testing, training and putting into service of equipment and systems, including associated operational procedures, carried out by operational stakeholders;’; ---|--- (e) | the following points (6a) and (6b) are inserted: | ‘(6a) | “implementation target date” means a date by when the implementation of the ATM functionality or sub-functionality is to be completed; ---|--- (6b) | “industrialisation target date” means a date by when the standards and specifications are to be available for the ATM functionality or sub-functionality to enable its implementation;’; ---|--- (f) | points (8), (9) and (10) are replaced by the following: | ‘(8) | “performance scheme” means a scheme established by Implementing Regulation (EU) 2019/317; ---|--- (9) | “European Union-wide performance targets” means the targets referred to in Article 9 of Implementing Regulation (EU) 2019/317; ---|--- (10) | “operational stakeholders” means the Network Manager and civil and military: airspace users, air navigation service providers, airport operators;’; ---|--- (g) | the following point (11) is added: | ‘(11) | “SESAR project” means an innovation cycle providing the Union with a high performing, standardised and interoperable air traffic management system, which comprises the SESAR definition, development and deployment phases.’; ---|--- (2) | Article 4 is replaced by the following: ‘Article 4 Purpose and content 1\. Common projects shall identify the ATM functionalities and their sub-functionalities. Those functionalities and sub-functionalities shall be based on SESAR solutions addressing the essential operational changes defined in the European ATM Master Plan, shall be ready for implementation and shall require synchronised implementation. Readiness for implementation shall be assessed, inter alia, based on the results of validation carried out during the development phase, the status of industrialisation and an assessment of interoperability, as well as in relation to the International Civil Aviation Organization (‘ICAO’) Global Air Navigation Plan and relevant ICAO material. 2\. Common projects shall set out for each ATM functionality and sub-functionality the following characteristics: | (a) | essential operational changes they contribute to; ---|--- (b) | the operational and technical scope; ---|--- (c) | the geographical scope; ---|--- (d) | the operation stakeholders that are required to implement them; ---|--- (e) | the synchronisation requirements; ---|--- (f) | the implementation target dates; ---|--- (g) | the interdependencies with other functionalities or sub-functionalities. ---|--- 3\. By way of derogation from paragraph 1, common projects may also include ATM functionalities or sub-functionalities that are not ready for implementation but that constitute an essential component of the common project concerned and provided that their industrialisation is deemed to be finalised within three years from the adoption of the concerned common project. For that purpose, an industrialisation target date for those ATM functionalities or sub-functionalities shall also be defined in the common project. 4\. At the expiry of the industrialisation target date, the Commission, with the support of the European Union Aviation Safety Agency, shall verify that the ATM functionalities or sub-functionalities referred to in paragraph 3 have been standardised and that they are ready for implementation. Where they are found not to be ready for implementation, they shall be withdrawn from the common project regulation. 5\. The deployment manager, the SESAR Joint Undertaking, the European standardisation organisations, Eurocae and the relevant manufacturing industry shall cooperate under the coordination of the European Union Aviation Safety Agency to ensure that the industrialisation target date is met. 6\. Common projects shall also: (a) | be consistent with and contribute to the European Union-wide performance targets; ---|--- (b) | demonstrate a positive business case for the EATMN, based on cost-benefit analysis, and identify any potential local or regional negative impact for any specific category of operational stakeholders; ---|--- (c) | take account of the relevant deployment elements specified in the Network Strategy Plan and the Network Operations Plan of the Network Manager; ---|--- (d) | demonstrate an improved environmental performance.’; ---|--- (3) | Article 5 is amended as follows: | (a) | paragraph 2 is replaced by the following: | ‘2. | The Commission shall be assisted by the Network Manager, the European Union Aviation Safety Agency, the Performance Review Body within their respective roles and competencies, and by the SESAR Joint undertaking, Eurocontrol, the European standardisation organisations, Eurocae and the deployment manager. Those bodies shall involve the operational stakeholders and manufacturing industry.’; ---|--- (b) | the following paragraph 2a is inserted: | ‘2a. | The European Union Aviation Safety Agency, upon the request by the Commission shall provide an opinion on the technical readiness for deployment of the ATM functionalities, and their sub-functionalities, proposed for a common project.’; ---|--- (c) | paragraph 3 is replaced by the following: | ‘3. | The Commission shall consult the stakeholders in accordance with Articles 6 and 10 of Regulation (EC) No 549/2004 including through the European Defence Agency, within its remit to facilitate the coordination of military views, and the consultative group of experts on the social dimension of the single European sky on its proposals for common projects. The Commission shall verify that proposals for common projects are endorsed by the airspace users and the ground operational stakeholders that are required to implement a specific common project.’; ---|--- (d) | paragraph 4 is deleted; ---|--- (e) | the following paragraph 7 is added: | ‘7. | Member States and the Network Manager shall include the investments related to the implementation of common projects in the performance plans and the Network performance plan.’; ---|--- (4) | Article 8 is amended as follows: | (a) | in paragraph 2, point (g) is replaced by the following: | ‘(g) | establishing coordination with the European Union Aviation Safety Agency and with the European standardisation organisations to facilitate industrialisation and promote interoperability of ATM functionalities and sub-functionalities;’; ---|--- (b) | Paragraph 4 is amended as follows: | (i) | point (c) is replaced by the following: | ‘(c) | the European Union Aviation Safety Agency, to ensure that safety, interoperability and environmental requirements and standards of the common projects are established in accordance with Regulation (EU) 2018/1139 of the European Parliament and of the Council (*3) and its implementing rules, and with the European Plan for Aviation Safety established in accordance with Article 6 thereof; ---|--- (*3) Regulation (EU) 2018/1139 of the European Parliament and of the Council of 4 July 2018 on common rules in the field of civil aviation and establishing a European Union Aviation Safety Agency, and amending Regulations (EC) No 2111/2005, (EC) No 1008/2008, (EU) No 996/2010, (EU) No 376/2014 and Directives 2014/30/EU and 2014/53/EU of the European Parliament and of the Council, and repealing Regulations (EC) No 552/2004 and (EC) No 216/2008 of the European Parliament and of the Council and Council Regulation (EEC) No 3922/91 (OJ L 212, 22.8.2018, p. 1).’;" (ii) | point (e) is replaced by the following: | ‘(e) | the European standardisation organisations and Eurocae, to facilitate and monitor industrial standardisation processes and the use of the resulting standards.’; ---|--- (5) | Article 9(2) is amended as follows: | (a) | point (j) is replaced by the following: | ‘(j) | ensuring appropriate coordination with National Supervisory Authorities;’; ---|--- (b) | the following point (k) is added: | ‘(k) | ensuring appropriate coordination with the European Union Aviation Safety Agency.’; ---|--- (6) | Article 11 is replaced by the following: ‘Article 11 Purpose and content 1\. The deployment programme shall provide a comprehensive and structured work plan of all activities necessary to implement technologies, procedures and best practices required to implement common projects. The deployment programme shall specify the technological enablers for implementing the common projects. 2\. The deployment programme shall define how the implementation of common projects shall be synchronised within the EATMN, taking into account local operational requirements and constraints. 3\. The deployment programme shall constitute the references for all operational stakeholders required to implement common projects and for the management and implementation levels. The operational stakeholders shall provide the deployment manager with relevant information concerning the implementation of deployment programme. The deployment programme shall be part of the framework partnership agreement and, as such, all the beneficiaries shall commit to implement it.’. ---|--- Article 5 Repeal Regulation (EU) No 716/2014 is repealed. Article 6 Entry into force This Regulation shall enter into force on the twentieth day following that of its publication in the Official Journal of the European Union. This Regulation shall be binding in its entirety and directly applicable in all Member States. Done at Brussels, 1 February 2021. For the Commission The President Ursula VON DER LEYEN * * * (1) OJ L 96, 31.3.2004, p. 10. (2) Commission Implementing Regulation (EU) No 409/2013 of 3 May 2013 on the definition of common projects, the establishment of governance and the identification of incentives supporting the implementation of the European Air Traffic Management Master Plan (OJ L 123, 4.5.2013, p. 1). (3) Commission Implementation Regulation (EU) No 716/2014 of 27 June 2014 on the establishment of the Pilot Common Project supporting the implementation of the European Air Traffic Management Master Plan (OJ L 190, 28.6.2014, p. 19). (4) Agreement on the European Economic Area (OJ L 1, 3.1.1994, p. 3). (5) Agreement between the European Community and the Swiss Confederation on Air Transport (OJ L 114, 30.4.2002, p. 73). (6) Commission Implementing Regulation (EU) 2018/1048 of 18 July 2018 laying down airspace usage requirements and operating procedures concerning performance-based navigation (OJ L 189, 26.7.2018, p. 3). (7) Commission Regulation (EC) No 2150/2005 of 23 December 2005 laying down common rules for the flexible use of airspace (OJ L 342, 24.12.2005, p. 20). (8) Commission Implementing Regulation (EU) 2019/317 of 11 February 2019 laying down a performance and charging scheme in the single European sky and repealing Implementing Regulations (EU) No 390/2013 and (EU) No 391/2013 (OJ L 56, 25.2.2019, p. 1). (9) Regulation (EU) 2018/1139 of the European Parliament and of the Council of 4 July 2018 on common rules in the field of civil aviation and establishing a European Union Aviation Safety Agency, and amending Regulations (EC) No 2111/2005, (EC) No 1008/2008, (EU) No 996/2010, (EU) No 376/2014 and Directives 2014/30/EU and 2014/53/EU of the European Parliament and of the Council, and repealing Regulations (EC) No 552/2004 and (EC) No 216/2008 of the European Parliament and of the Council and Council Regulation (EEC) No 3922/91 (OJ L 212, 22.8.2018, p. 1). * * * ANNEX 1\. AF 1: EXTENDED ARRIVAL MANAGEMENT AND INTEGRATED ARRIVAL MANAGEMENT/DEPARTURE MANAGEMENT IN THE HIGH-DENSITY TERMINAL MANOEUVRING AREAS 1.1. Operational and technical scope 1.1.1. ATM sub-functionality on arrival management extended to en-route airspace General Arrival management (AMAN) extended to en-route airspace (‘extended AMAN’) contributes to the ‘Airport and TMA performance’ essential operational change (EOC). It extends the AMAN horizon to a minimum of 180 nautical miles from the arrival airport. Traffic sequencing/metering must be conducted in en-route before top-of-descent in order to improve predictability and to smoothen the flow of traffic. System requirements (a) | Extended AMAN systems must provide arrival sequence time information and associated advisories into en-route ATC systems to a minimum of 180 nautical miles from the arrival airport as well as into ATC systems of airports impacted by the extended AMAN horizon, unless a shorter distance is recommended in the deployment programme. ---|--- (b) | Existing data exchange technology may be used until SWIM is available. ---|--- 1.1.2. ATM sub-functionality on AMAN/DMAN Integration General AMAN/DMAN integration contributes to the ‘Airport and TMA performance’ EOC. Departure management (DMAN) calculates the optimum pre-departure sequence based on information provided by the airport, the airline and ATC. Similarly, AMAN calculates the optimum arrival flow to the airport. Integration of runway sequence, respecting AMAN and DMAN constraints, allows for optimum utilisation of runways. Where such integration interferes with the 180 nautical miles requirement for extended AMAN, the system is tuned to allow as large horizon as possible. System requirements (a) | The amalgamation of departure and arrival flows is carried out by integrating existing AMAN and DMAN functions where runways are operated in mixed mode; ---|--- (b) | AMAN and DMAN systems must be able to share data to be included in their planning algorithms calculating arrival and departure flows. ---|--- 1.2. Geographical Scope 1.2.1. Airports required to operate the arrival management extended to en- route airspace The following airports are required to operate the AMAN: (a) | Adolfo Suarez Madrid-Barajas; ---|--- (b) | Amsterdam Schiphol; ---|--- (c) | Barcelona El Prat; ---|--- (d) | Berlin Brandenburg Airport; ---|--- (e) | Brussels National; ---|--- (f) | Copenhagen Kastrup; ---|--- (g) | Dublin; ---|--- (h) | Düsseldorf International; ---|--- (i) | Frankfurt International; ---|--- (j) | Milan-Malpensa; ---|--- (k) | Munich Franz Josef Strauss; ---|--- (l) | Nice Cote d’Azur; ---|--- (m) | Palma De Mallorca Son Sant Joan; ---|--- (n) | Paris-CDG; ---|--- (o) | Paris-Orly; ---|--- (p) | Rome-Fiumicino; ---|--- (q) | Stockholm-Arlanda; ---|--- (r) | Vienna Schwechat; ---|--- AMAN must be implemented in the associated en-route sectors. 1.2.2. Airports required to operate the AMAN/DMAN integration The AMAN/DMAN integration applies to airports that have single runway or dependent runways, which may operate in mixed-mode or have departure runway linked with dependency to an arrival runway. AMAN/DMAN integration must be operated at the following airports as well as the associated approach and en- route sectors: (a) | Berlin Brandenburg Airport; ---|--- (b) | Düsseldorf International; ---|--- (c) | Milan-Malpensa; ---|--- (d) | Nice Côte d’Azur; ---|--- (e) | Paris-CDG. ---|--- 1.3. Stakeholders required to implement the functionality and the implementation target dates (a) | ATS providers and the Network Manager must ensure that ATS units providing ATC services within the terminal airspace of the airports referred to in point 1.2 and the associated en-route sectors operate extended AMAN by the implementation target date of 31 December 2024. ---|--- (b) | ATS providers must ensure that ATS units providing ATC services within the terminal airspace of the airports referred to in point 1.2 and the associated approach sectors operate integrated AMAN/DMAN by the implementation target date of 31 December 2027. ---|--- (c) | Air traffic control (‘ATC’) services in the terminal manoeuvring areas (‘TMAs’) implementing extended AMAN operations must coordinate with air traffic services (‘ATS’) units responsible for adjacent en-route sectors as well as ATS units responsible for inbound traffic originating from airports covered by the extended AMAN horizon. ---|--- 1.4. Need for synchronisation The airports listed in point 1.2 constitute a critical mass of operational stakeholders for achieving the network performance gains expected from extended AMAN and integration of AMAN/DMAN functionalites. Those benefits will materialise sooner if those airports and all other involved operational stakeholders can operate that functionality simultaneously. That requires synchronising and coordinating the implemlentation of extended AMAN and AMAN/DMAN itegration, including the related investments, according to an agreed timeline that must be defined in the deployment programme to avoid implementation gaps in the geographical scope. Synchronisation is also needed to ensure that all the concerned stakeholders have the necessary infrastruture to exchange trajectory information (i4D profile) and for ensuring constraints compliance at metering points. 1.5. The expected environmental improvements This functionality is focused on management and reduction of delays at more fuel-efficient altitudes in en-route phase of flight and on absorbing delays on the ground at the impacted airports. Extended AMAN enables optimum flight trajectories and vertical profiles that improve thrust level requirements. That results in operations at lower noise and avoiding step climbs over populated areas close to the airfield. AF1 functionality also provides the opportunity for creation of flight paths over less-noise sensitive areas, enabling optimum profile drag with reduced aerodynamic noise. The full implementation of AF1 will improve the handling of delays and absorption strategies and will reduce low level holdings in TMA, thereby reducing noise emissions and improving air quality at and around airports. The integration of arrivals and departures on mixed-mode runways and the mitigation of demand and capacity imbalances are accomplished by the creation of suitable departure gaps in the arrival sequence. Airports receive benefits of enhanced stand allocation and passenger handling and better management of ground fleet (vehicles) saving fuel and reducing (ground fleet) noise at and around airfield, reducing CO2 and other suspended particle pollutants. Airlines gain directly on reduced operational cost by saving fuel and enhanced CO2 savings while absorbing delay at the stand or earlier delay-absorption at higher, more fuel-efficient altitudes during arrivals. 1.6. Interdependencies with other ATM functionalities AF1 has interdependencies with: — | electronic flight strips (‘EFS’) and DMAN set out in AF2; ---|--- — | network collaborative management to coordinate reconciled target times for improved ATFCM and arrival sequencing, set out in AF 4; ---|--- — | SWIM services set out in AF5, where SWIM is available. ---|--- 2\. AF 2: AIRPORT INTEGRATION AND THROUGHPUT AF 2 contributes to the ‘Airport and TMA performance’ EOC. The main objective of AF2 is to limit the constraints put on air traffic at airports without jeopardizing traffic growth, safety, or environment. AF2 focuses on optimising the usage of airport infrastructure to ensure safe and environmentally friendly throughput of air traffic. It also focuses on the exchange of updated operational information and data with all stakeholders involved in the turnaround of air traffic. 2.1. Operational and technical scope 2.1.1. ATM sub-functionality on Departure Management Synchronised with Pre- departure sequencing General Departure management (‘DMAN’) synchronised with pre-departure sequencing is a means to improve departure flows at one or more airports by calculating the target take off time (‘TTOT’) and target start approval time (‘TSAT’) for each flight, taking multiple constraints and preferences into account. DMAN consists of metering the departure flow to a runway by managing off- block-times (via start-up-times) which take account of the available runway capacity. DMAN synchronised with pre-departure sequencing reduces taxi times, increases air traffic flow management-slot (‘ATFM-Slot’) adherence and predictability of departure times. DMAN aims at maximising traffic flow on the runway by setting up a sequence with optimised separations. Operational stakeholders working according to the principles of airport collaborative decision making (‘A-CDM’) must jointly establish pre-departure sequences, taking into account agreed principles to be applied for specific reasons, such as runway holding time, slot adherence, departure routes, airspace user preferences, night curfew, evacuation of stand/gate for arriving aircraft, adverse weather conditions including de-icing, actual taxi/runway capacity and current constraints. System requirements (a) | DMAN and systems supporting A-CDM must be integrated and must support optimised pre-departure sequencing with appropriate information/data for airspace users (target off block time (‘TOBT’)) and airport stakeholders concerned (contextual data feeding). ---|--- (b) | DMAN systems must elaborate and calculate a collaborative sequencing and provide both TSAT and TTOT. TSAT and TTOT must take into account variable taxi times and must be updated according to the actual aircraft take-off. ---|--- (c) | DMAN systems must provide the air traffic controller with the list of TSAT and TTOT for the aircraft metering. ---|--- (d) | An electronic clearance input (‘ECI’) system such as the EFS, must be implemented, allowing the air traffic controller to input all clearances given to aircraft or vehicles into the ATC system. The system must have appropriate interfaces with A-SMGCS and airport safety nets, allowing the integration of the instructions given by the air traffic controller with other data such as flight plan, surveillance, routing, published routes, gate allocation and procedures. ---|--- 2.1.2. ATM sub-functionality on airport operations plan General The airport operations plan (‘AOP’) is a rolling plan that interacts with services, systems and stakeholders gathering information from several systems. The AOP must provide all the information that is relevant for the network to the network operations plan (‘NOP’) in real time. The AOP supports landside and airside operations at airports with an increased scope of data sharing between the airport and Network Manager building on the available A-CDM supporting systems. The AOP must support the following four operational services by improving the overall operational efficiency and increasing resilience of the airport and of the network to disruptions such as adverse weather conditions, closure of a runway and security alerts: (a) | steer airport performance service; ---|--- (b) | monitor airport performance service; ---|--- (c) | manage airport performance service; ---|--- (d) | perform post-operations analysis service. ---|--- The AOP is instantiated at the beginning of each airport slot coordination season and continuously updated during the medium-term planning phase, the short-term planning phase and the execution phase. The seasonal AOPs are stored to be used in post-operations analysis. AOP consists of the initial AOP (iAOP) and extended AOP: (a) | the iAOP comprises the basic elements to exchange the data elements with the NOP and paves the way to extended AOP; ---|--- (b) | the extended AOP comprises the AOP management tool, airport performance monitoring, assessment, management support and post-operations, in accordance with a full AOP/NOP integration. ---|--- System requirements To support the iAOP implementation, the following elements must be taken into account: (a) | A-CDM; ---|--- (b) | MET-data; ---|--- (c) | AOP management tool containing the rolling plan of the airport operations and capabilities (airside) for short-term time frame; ---|--- (d) | the AOP must be connected to the NOP via SWIM service(s), when available, and must make all the network-relevant data available to the network. ---|--- To support the extended AOP implementation, the following elements must be taken into account: (a) | AOP management tools containing the rolling plan of the airport operations and capabilities (landside and airside) for each time frame (from medium term to post-ops); ---|--- (b) | airport performance monitoring system to monitor performance against the goals; ---|--- (c) | airport performance assessment and management support system to assess the severity of the deviations from the plan detected by the monitoring of airport performance service and their impact on the airport processes and on the airport performance; ---|--- (d) | airport post-operations analysis tool to develop standard and ad-hoc post-ops analysis reports. ---|--- 2.1.3. ATM sub-functionality on airport safety nets General Airport safety nets consist of: — | the airport safety support service, which contributes to airside operations as a safety improvement enabling air traffic controllers to prevent hazards and incidents resulting from air traffic controller, flight crew or vehicle driver operational errors or deviations. Such service depends on the surveillance service being in operation; ---|--- — | the detection and alerting of conflicting ATC clearances to aircraft and deviation of vehicles and aircraft from their instructions, procedures or routing that may potentially put the vehicles and aircraft at risk of a collision. ---|--- The scope of this sub-functionality includes the runway and airfield surface movement area. ATC support tools at the aerodrome are a vital part of the airport safety nets and must provide the detection of conflicting ATC clearances (‘CATC’), the conformance monitoring of alerts for controllers (‘CMAC’) and the runway monitoring and conflict alerting (‘RMCA’). Those three functions are performed by the ATC system on the basis of the knowledge of data including the clearances given to aircraft and vehicles by the air traffic controller, the assigned runway and holding point. The air traffic controller enters clearances given to aircraft or vehicles into the ATC system using a digital system, such as the EFS or stripless systems. The list of clerances to be entered into the ATC system must be described in the deployment programme. Airport safety nets must alert air traffic controllers when aircraft and vehicles deviate from ATC instructions, procedures or route. The air traffic controller instructions must be integrated with published rules and procedures, and other available data such as flight plan, surveillance and routing. The integration of that data allows the system to monitor the information and alert the air traffic controller when inconsistencies are detected. Any local limitations to the introduction of the airport safety support service must be indicated in the deployment programme. The RMCA function acts as a short-term alerting tool, whereas the CATC and CMAC act as predictive tools that aim at preventing situations where an RMCA alert may be triggered. System requirements (a) | Airport safety nets must integrate advanced surface movement guidance & control system (‘A-SMGCS’) surveillance data and air traffic controller clearances related to the manoeuvring area. Airport conformance monitoring must integrate A-SMGCS surveillance data and when available surface movement routing and air traffic controller routing clearances. ---|--- (b) | A-SMGCS must include a function to generate and distribute the appropriate alerts. Such alerts are meant to supplement, not replace, the existing RMCA. ---|--- (c) | All relevant working positions must host warnings and alerts with an appropriate human-machine interface including support for cancelling an alert. ---|--- (d) | Electronic clearance input (‘ECI’) means such as, but not limited to, electronic flight strips (EFS), must integrate the instructions given by the air traffic controllers with other data such as flight plan, surveillance, routing when available, published rules and procedures. ---|--- 2.2. Geographical Scope 2.2.1. Airports required to operate the departure management synchronised with pre-departure sequencing and airport safety nets Departure management synchronised with pre-departure sequencing and airport safety nets must be operated in the following airports: (a) | Adolfo Suárez Madrid-Barajas; ---|--- (b) | Amsterdam Schiphol; ---|--- (c) | Barcelona El Prat; ---|--- (d) | Berlin Brandenburg Airport; ---|--- (e) | Brussels National; ---|--- (f) | Copenhagen Kastrup; ---|--- (g) | Dublin; ---|--- (h) | Düsseldorf International; ---|--- (i) | Frankfurt International; ---|--- (j) | Milan-Malpensa; ---|--- (k) | Munich Franz Josef Strauss; ---|--- (l) | Nice Cote d’Azur; ---|--- (m) | Palma De Mallorca Son Sant Joan; ---|--- (n) | Paris-CDG; ---|--- (o) | Paris-Orly; ---|--- (p) | Rome-Fiumicino; ---|--- (q) | Stockholm-Arlanda; ---|--- (r) | Vienna Schwechat. ---|--- 2.2.2 Airports which must operate the iAOP: (a) | Adolfo-Suarez Madrid-Barajas; ---|--- (b) | Amsterdam Schiphol; ---|--- (c) | Barcelona El Prat; ---|--- (d) | Berlin Brandenburg Airport; ---|--- (e) | Brussels National; ---|--- (f) | Copenhagen Kastrup; ---|--- (g) | Dublin; ---|--- (h) | Düsseldorf International; ---|--- (i) | Frankfurt International; ---|--- (j) | Milan-Malpensa; ---|--- (k) | Munich Franz Josef Strauss; ---|--- (l) | Nice Cote d’Azur; ---|--- (m) | Palma De Mallorca Son Sant Joan; ---|--- (n) | Paris-CDG; ---|--- (o) | Paris-Orly; ---|--- (p) | Rome-Fiumicino; ---|--- (q) | Stockholm-Arlanda; ---|--- (r) | Vienna Schwechat; ---|--- 2.2.3. Airports which must operate the AOP The following airports are required to operate the AOP: (a) | Adolfo-Suarez Madrid-Barajas; ---|--- (b) | Amsterdam Schiphol; ---|--- (c) | Athens Eleftherios Venizelos; ---|--- (d) | Barcelona El Prat; ---|--- (e) | Berlin Brandenburg Airport; ---|--- (f) | Brussels National; ---|--- (g) | Copenhagen Kastrup; ---|--- (h) | Dublin Airport; ---|--- (i) | Düsseldorf International; ---|--- (j) | Frankfurt International; ---|--- (k) | Hamburg; ---|--- (l) | Helsinki Vantaa; ---|--- (m) | Humberto Delgado – Lisbon Airport; ---|--- (n) | Lyon Saint-Exupéry; ---|--- (o) | Malaga Costa Del Sol; ---|--- (p) | Milan-Linate; ---|--- (q) | Milan-Malpensa; ---|--- (r) | Munich Franz Josef Strauss; ---|--- (s) | Nice Cote d’Azur; ---|--- (t) | Palma De Mallorca Son Sant Joan; ---|--- (u) | Paris-CDG; ---|--- (v) | Paris-Orly; ---|--- (w) | Prague; ---|--- (x) | Rome-Fiumicino; ---|--- (y) | Stockholm-Arlanda; ---|--- (z) | Stuttgart; ---|--- (aa) | Vienna Schwechat; ---|--- (bb) | Warsaw Chopin. ---|--- 2.3. Stakeholders required to implement the functionality and implementation target dates ATS providers and airport operators providing services at the airports referred to in point 2.2 must operate: — | departure management synchronised with pre-departure sequencing by the implementation target date of 31 December 2022;

---|--- — | iAOP by the implementation target date of 31 December 2023; ---|--- — | AOP (initial and extended) by the implementation target date of 31 December 2027; ---|--- — | airport safety nets by the implementation target date of 31 December 2025. ---|--- The landside and airside airport operators stakeholders listed below must make changes within their own sphere of operations and must use and share the AOP as the principal source of information for airport operations: (a) | airport operators; ---|--- (b) | aircraft operators; ---|--- (c) | ground handlers; ---|--- (d) | de-icing companies; ---|--- (e) | air navigation service providers (‘ANSP’); ---|--- (f) | network operations; ---|--- (g) | MET service providers; ---|--- (h) | support services (police, customs and immigration, etc.). ---|--- 2.4. Need for synchronisation The targeted airports and stakeholders referred to in point 2.3 must synchronise the implementation of the relevant AF2 sub-functionalities according to the deployment programme to ensure the timely harmonisation of operational procedures linked to AMAN/DMAN and airport safety nets so that air traffic controllers use the same approach at all concerned airports and thus crews would follow the same instructions. 2.5. The expected environmental improvements AF2 will contribute to improving the quality of air by optimising air traffic patterns on ground and in the air, increasing predictability, reducing fuel consumption and noise emissions related to the trajectories of flights for the populations and communities neighbouring the airports listed in the point 2.2. 2.6. Interdependencies with other ATM functionalities AF2 has interdependencies with: (a) | extended AMAN and AMAN/DMAN integration set out in AF1; ---|--- (b) | AOP/NOP integration set out in AF4; ---|--- (c) | SWIM set out in AF5. ---|--- 3\. AF 3: FLEXIBLE AIRSPACE MANAGEMENT AND FREE ROUTE AIRSPACE 3.1. Operational and Technical Scope 3.1.1. ATM sub-functionality: Airspace management and advanced flexible use of airspace General Airspace management and advanced flexible use of airspace contributes to achieving the ‘Fully dynamic and optimised airspace’ EOC. Increased performance of ATM requires that changes in airspace status are constantly shared with all concerned ATM actors, in particular the Network Manager, the ANSPs and the airspace users (flight operations centre/wing operations centre (‘FOC/WOC’)). Airspace management (‘ASM’) and advanced flexible use of airspace (‘A-FUA’) aim at providing the most efficient airspace organisation and management in response to airspace user’s needs. ASM with A-FUA provides a solution for dynamically managing airspace users’ demands in various operating environments. ASM procedures and processes facilitate free route airspace operations without reference to a fixed-route network where airspace is managed dynamically, by variable profile area (‘VPA’), temporary restricted area (‘TRA’) or temporary segregated area (‘TSA’). ASM based on predefined airspace configurations satisfies ATM network performance expectations while balancing operational stakeholders demand with available capacity. Data-sharing must be enhanced by the availability of pre-defined airspace structures in support of a more dynamic ASM and free route airspace (‘FRA’) implementation. ASM with air traffic flow and capacity management (‘ATFCM’) supports predefined airspace configurations and scenarios, providing an efficient dynamic organisation of airspace, including sector configurations, to cope with both civil and military airspace users’ requests. ASM solutions must support all airspace users and be based on forecast demand received from the local air traffic flow and capacity management (‘ATFCM’) function in relation with Airspace Management Cells (AMC’s) and the Network Manager. The system must support cross-border activities resulting in shared use of volume of airspace regardless of national boundaries. Enhancements to the NOP must be achieved through a cooperative decision-making process between all involved operational stakeholders. System requirements (a) | The ASM support systems must support the fixed and conditional route networks, FRA and flexible sector configurations and must be able to respond to changing demands for airspace. ---|--- (b) | The ASM system must support cross-border activities resulting in shared use of volume of airspace regardless of national boundaries. ---|--- (c) | Airspace status information, including airspace reservations, must be accessible via the Network Manager systems – using available SWIM services as set out in point 5.1.3 – that must contain up-to-date and projected airspace configurations to allow airspace users to file and modify their flight plans based on timely and accurate information. ---|--- (d) | The ATC systems must support flexible configuration of sectors in order to optimise their dimensions and operating hours in accordance with the demands of the NOP. ---|--- (e) | The Network Manager systems must: | — | allow a continuous assessment of the impact that changing airspace configurations have on the network; ---|--- — | be modified to reflect the changes in the definition of airspace and routes in order for the routes, flight-progress and associated information to be available to ATC systems. ---|--- (f) | ATC systems must correctly depict the activation and de-activation of configurable airspace reservations. ---|--- (g) | The ASM, ATFCM and ATC systems must be interoperable allowing the provision of air navigation services based on a common understanding of the airspace and traffic environment. ---|--- (h) | The ATC systems must be modified to enable AF3 to the extent necessary to comply with the fourth and fifth paragraph of point 3.2 of Annex VIII to Regulation (EU) 2018/1139. ---|--- (i) | Centralised aeronautical information services (‘AIS’) systems, such as the European AIS Database (‘EAD’), must provide environment data for European FRA and for flexible airspace structures to all involved operational stakeholders in a timely manner – with the exception of ad hoc structures due to short-term requests/reservations – enabling planning based on accurate information relevant to the time of the planned operations. The information must be made available using available SWIM services set out in point 5.1.3. ---|--- (j) | AIS systems must be able to use the data provided by EAD and to upload of changing local data. ---|--- (k) | Operational stakeholders must be able to interface with the Network Manager systems in accordance with AF4. Interfaces must be set out to allow updated real-time airspace data to be sent to operational stakeholder systems and allow those stakeholders to communicate information in an accurate and timely manner. These systems must be modified to enable such interfaces using the available SWIM services set out in point 5.1.3. ---|--- (l) | ASM and A-FUA must be supported by the Network Manager as set out in AF4 and, where available, using SWIM as set out in AF5. ---|--- (m) | Data exchange between stakeholders mandated to deploy the flexible airspace management and FRA set out in AF3 must be implemented using SWIM services as set out in AF5, where SWIM is available. The concerned systems must be able to provide or use SWIM services. Existing data exchange technology may be used until SWIM is available. ---|--- (n) | ATC systems must receive and process updated flight data coming from an aircraft’s automatic dependent surveillance-contract extended projected profile (‘ADS-C EPP’) by data link functionality as set out in AF6, where available. ---|--- 3.1.2. ATM sub-functionality on free route airspace General Free route airspace (‘FRA’) contributes to the ‘Fully dynamic and optimised airspace’ EOC. It is a specified airspace within which airspace users may freely plan a route between defined entry and exit points. Subject to airspace availability, airspace users must have the possibility to choose a route via intermediate, published or unpublished, waypoints without reference to the ATS route network. Within that airspace, flights remain subject to air traffic control. FRA connectivity with TMAs must be ensured by one of the following options: — | lowering FRA vertical limit to the TMAs upper vertical boundaries; ---|--- — | linking appropriate arrival/departures points; ---|--- — | defining FRA connecting routes; ---|--- — | extending the existing standard arrival and departure routes; ---|--- — | connecting with the underlying fixed ATS routes via set of waypoints reflecting the typical climbing/descending profiles. ---|--- FRA implementation is carried out in two phases as follows: — | initial FRA: with time and structure constraints; ---|--- — | final FRA: constant free route implementation with cross-border dimension and connectivity to TMAs. ---|--- To facilitate implementation before its target date referred to in point 3.3, initial FRA may be implemented in a limited way during defined periods or on a structurally limited basis. Initial FRA implementation in portions of airspace reduced vertically or laterally, or both, is considered only as an intermediate step to achieve the full and consistent implementation of FRA. The final objective is the deployment of final FRA in the entire airspace under the responsibility of the Member States involved at least above flight level 305, with no time limit and no reduction on capacity and cross-border FRA between neighboring states, irrespective of national/Flight Information Region (‘FIR’) boundaries. System requirements (a) | Network Manager systems must support FRA, ASM and A-FUA with appropriate functions such as the following: | — | flight plan processing; ---|--- — | IFPS routing proposals; ---|--- — | dynamic re-routing; ---|--- — | ATFCM planning and execution; ---|--- — | calculation and management of traffic loads; ---|--- — | management of ASM airspace volumes. ---|--- (b) | ATC systems must support FRA, ASM and A-FUA implementations. The concerned operational stakeholders must choose the appropriate tool/function to achieve this objective based on their operational environment. ---|--- (c) | Supporting functions/tools may include any of the following: | — | support to the operating environments to manage and display trajectories in FRA environment on the controller working position and the human-machine interface (‘HMI’); ---|--- — | flight data processing system (‘FDPS’) supporting national, cross-border FRA operations and FRA connectivity with TMAs; ---|--- — | ATC/ASM/ATFCM interoperability; ---|--- — | dynamic change of a volume of airspace from a fixed route network to FRA; ---|--- — | conflict alert, detection and resolution tools, such as conflict detection tools (‘CDT’) including medium-term conflict detection (‘MTCD’) and/or tactical controller tool (‘TCT’), conformance monitoring (‘MONA’), and area proximity warning (‘APW’) for dynamic airspace volumes/sectors; ---|--- — | trajectory prediction supported by an automated conflict detection tool adapted to operate in FRA; ---|--- — | for cross-border FRA, the ATC systems supporting the exchange of flight intent data, such as through OLDI message. ---|--- (d) | Airspace users’ systems must support flight planning to ensure the safe and efficient utilisation of ASM, AFUA and FRA including the partial implementation and intermediate steps deployed before the target date. ---|--- (e) | The specific measures that are required for final FRA implementation, as in the case of very highly complex areas, must be specified in the deployment programme. ---|--- (f) | Data exchange between stakeholders mandated to deploy the flexible airspace management and FRA set out in AF3 must be implemented using available SWIM services as set out in AF5. The concerned systems must be able to provide or use SWIM services. Existing data exchange technology may be used until SWIM is available. ---|--- (g) | FRA must be supported by the Network Manager as set out in AF4 and, where available, using SWIM as set out in AF5. ---|--- 3.2. Geographical Scope ASM and A-FUA must be provided and operated in the Single European Sky airspace as defined in Article 3(33) of Regulation (EU) 2018/1139. FRA must be provided and operated in the entire Single European Sky airspace at least above flight level 305. 3.3. Stakeholders required to implement the functionality and implementation target dates The Network Manager and operational stakeholders must operate: — | ASM and A-FUA by the implementation target date of 31 December 2022; ---|--- — | initial FRA by the implementation target date of 31 December 2022; ---|--- — | final FRA, including cross-border FRA with at least one neighbouring state and FRA connectivity with TMAs, by the implementation target date of 31 December 2025. ---|--- 3.4. Need for synchronisation Civil and military ANSPs, airspace users and the Network Manager must synchronise the implementation of system and procedural changes necessary for ASM and FRA according to the deployment programme. These sub-functionalities can only be effective if they are activated simultaneously, requiring that air and ground systems are equipped within a common timeframe. Without synchronisation, the network may present gaps that would prevent the airspace users from seamlessly flying preferred and more efficient routes. Any local limitations to the implementation of A FUA below FL 305 must be indicated in the deployment programme. 3.5. The expected environmental improvements FRA enables airspace users to fly as closely as possible to their preferred trajectory without being constrained by fixed airspace structures or fixed route networks. This results also in lower fuel burn and less CO2 emissions. The Common Project One provisions to extend FRA beyond the national boundaries with the cross border elements and ensuring connectivity with TMA will enable more efficient flight paths considering the cross-border elements and ensuring further routing efficency and maximising fuel and CO2 emissions savings. The cross-border FRA enhances the environmental benefits through even shorter routes and provides more airspace options when determining the user-preferred trajectory. FRA connectivity with TMA is intended to ensure gate-to-gate optimum flight path with further reductions of CO2 emissions. Those FRA enhancements will allow the airlines to take better advantage of meteorological conditions or to adapt to network disruptions. 3.6. Interdependencies with other ATM functionalities ASM, A-FUA and FRA have interdependencies with AF4, AF5 and AF6. 4\. AF 4: NETWORK COLLABORATIVE MANAGEMENT AF4 contributes to the ‘ATM interconnected network’ EOC. It focuses on exchanging updated flight and flow information and optimising the usage of this information. This exchange is carried out in the EATMN. The aim is to optimise the application of flow measures and complexity indicators and to minimise the constraint put on the 4D trajectories of the flights. 4.1. Operational and Technical Scope 4.1.1. ATM sub-functionality on enhanced short term ATFCM measures General ATFCM is coordinated at network level by the Network Manager and at local level by the flow management position to support hot-spot detection, execution of short-term ATFCM measures (STAM), network assessment and continuous monitoring of network activity. STAM is established requiring coordination between air traffic control, airport, airspace users and the Network Manager. Tactical capacity management must implement STAM using cooperative decision- making to manage flow before flights enter a sector and it must ensure a close and efficient coordination between ATC and the network management function. System requirements (a) | The Network Manager systems must implement the STAM functionalities and must support the coordination of the implementation of STAM measures, including network impact assessment capabilities. ---|--- (b) | ANSPs and airspace users must use the STAM application provided by the Network Manager or deploy local tools that must interact with the Network Manager’s STAM functionalities using the available SWIM services as set out in AF5. ---|--- 4.1.2. ATM sub-functionality: Collaborative NOP General The collaborative NOP is the continuous data exchanges between the Network Manager and operational stakeholders’ systems to cover the entire trajectory lifecycle and to reflect priorities as required by the Network Manager to ensure the optimisation of the network functioning. The implementation of a collaborative NOP focuses on the availability of shared operational planning and real-time data. In particular, target times (‘TT’) management will be part of collaborative NOP and TT is applied to selected flights for ATFCM purposes to manage ATFCM also at the point of congestion rather than only at departure. During the flight planning phase, the Network Manager must calculate a TT for a flight to enter into a location where time-based ATFCM measures are applied. The available airport configuration constraints and information on weather/airspace must be integrated into the NOP. The Network Manager must provide TT to airspace users’ flight operations centres together with the corresponding departure slot. Airspace users must inform their crews of any calculated slot and corresponding TT. System requirements (a) | In order to update the NOP and to obtain new information from the NOP, the relevant automated ground systems of operational stakeholders must be adapted to interface with network management systems. ---|--- (b) | Airspace users must inform their crews of any calculated slot and corresponding TT. ---|--- c) | In airports, iAOP systems must interface directly with Network Manager systems related to NOP systems to implement a collaborative NOP. ---|--- (d) | The Network Manager must grant the operational stakeholders access to the NOP data that they need through the applications provided by the Network Manager using a pre-defined HMI. ---|--- (e) | Network Manager systems must: | — | support target time sharing with operational stakeholders; ---|--- — | be able to adjust calculated take-off times (‘CTOT’) based on refined and agreed TTs; ---|--- — | handle arrival planning information and departure planning information from the iAOP. ---|--- (f) | At the destination airport, where arrival congestion is addressed by TTs, target times on arrivals (‘TTAs’) must be generated by the iAOP for subsequent refinement in the context of collaborative NOP. ---|--- 4.1.3. ATM sub-functionality on automated support for traffic complexity Assessment General Planned trajectory information, network information and recorded analytical data from past operations are used for predicting traffic complexity and potential overload situations, allowing mitigation strategies to be applied at local and network levels. FF-ICE (1) flight plan data (FF-ICE Release 1/Filing and trial services) must be used to enhance the quality of the planned trajectory information, thus enhancing flight planning and complexity assessments. An existing STAM phase 1 implementation facilitates the operational integration of that ATM functionality into the existing systems. System requirements (a) | Network Manager systems must: | — | deal with flexible airspace structures and route configuration allowing the management of traffic loads and complexity in a collaborative manner at the flow management position and at network level; ---|--- — | be able to provide FF-ICE Release 1 filing services; ---|--- — | support the scenario management for ATFCM planning activities in order to optimise the network capacity. ---|--- (b) | The flight data processing systems must interface with the NOP. ---|--- (c) | The information provided through route availability document (‘RAD’) and profile tuning restriction (PTR) must be harmonised through the collaborative decision making (CDM) process of the European route network design and ATFM functions of the Network Manager so that flight planning system providers are able to generate a flight plan routing that will be accepted with the most efficient trajectory. ---|--- (d) | Airspace users’ and ANSP’s systems must support the exchange of FF-ICE Release 1 filing services, once available as set out in AF 5.1.6. ---|--- (e) | ASM/ATFCM tools must be able to manage different airspace availability and sector capacity – including A-FUA as set out in AF3, RAD adaptation and STAM. ---|--- 4.1.4. ATM sub-functionality: AOP/NOP integration General In the collaborative NOP, only AOPs for the biggest airports are concerned with limited data sharing. To further enhance the integration, the number of airports and the number of data elements to be exchanged must be increased. The Network Manager must implement an increased integration of NOP and AOP relevant information (for example, TTAs) resulting from a cooperative decision-making process (referred to in Article 2(9) of the Commission Implementing Regulation (EU) 2019/123 (2). The AOP must provide, in real time, the NOP with data that is appropriate and relevant to inform actions by the Network Manager to adjust capacity in the network where required. Such data must be mutually agreed by the Network Manager and the airport. For airports with AOP, the Network Manager must share the arrival demand with the AOP and establish a collaborative decision-making process at local ATFM level to allow amendments to the TTAs based on the AOP. System requirements (a) | AOP systems must interface directly with the NOP systems. ---|--- (b) | Network Manager systems must interface directly with the AOPs. ---|--- (c) | The downlinked trajectory information set out in AF6, where available, must be processed by Network Manager systems related to NOP to support target time over (‘TTO’) or TTA, or both, to enhance the trajectory. ---|--- 4.2. Geographical Scope (a) | Network collaborative management must be implemented in the EATMN. ---|--- (b) | Collaborative NOP must be implemented in the airports listed in point 2.2.2. ---|--- (c) | NOP/AOP integration must be implemented by the airports listed in the point 2.2.3. ---|--- 4.3. Stakeholders required to implement the functionality and implementation target dates The Network Manager: (a) | must implement an increased integration of NOP and iAOP information resulting from a cooperative decision-making process as defined in Article 2(9) of Implementing Regulation (EU) 2019/123. ---|--- (b) | must share the arrival demand with the iAOP in the airports where it is available and establish a collaborative decision-making process at local air traffic slot management (‘ATFM’) level to allow amendments to the target times on arrival (‘TTA’) based on the iAOP. ---|--- (c) | is required to support stakeholders mandated to deploy the network collaborative management set out in AF4 with the choice of a pre-defined online access, wherever possible, or connect their own applications using system-to-system data exchange. ---|--- The operational stakeholders and the Network Manager must operate: (a) | enhanced short term ATFCM measures and automated support for traffic complexity assessment by the implementation target date of 31 December 2022. ---|--- (b) | collaborative NOP by the implementation target date of 31 December 2023. ---|--- (c) | AOP/NOP integration by the implementation target date of 31 December 2027. ---|--- 4.4. Need for synchronisation The synchronisation of the implementation of the network collaborative management functionality is necessary to ensure that the relevant stakeholders’ systems can efficiently and seamlessly exchange NOP data throughout the network in order to have the same level of accuracy and improve the network usage. The deployment programme will establish how synchronisation will be implemented avoiding implementation gaps or significant delays from individual stakeholders. 4.5. The expected environmental improvements The full implementation of AF4 will optimise the application of flow measures and will identify a common way to alleviate the network constrains limiting both the delays and the mandatory re-routings, hence preserving the full fuel optimisation made by the airspace users. 4.6. Interdependencies with other ATM functionalities AF4 has interdependencies with extended AMAN set out in AF1, AOP set out in AF2, flexible ASM and FRA set out in AF3 and SWIM set out in AF5. 5\. AF 5: SYSTEM WIDE INFORMATION MANAGEMENT System wide information management (‘SWIM’) contributes to the infrastructure component of the ‘ATM interconnected network’ EOC. SWIM infrastructure and services facilitate the exchange of ATM information between stakeholders that is necessary for all the other ATM functionalities. 5.1. Operational and technical scope 5.1.1. ATM sub-functionality on Common infrastructure components General The common infrastructure components are: — | the registry, which must be used for publishing information about services, including service definitions that describe those aspects of a service that should be common among all implementations, such as standardised service specifications and implementation descriptions for providers; ---|--- — | a common public key infrastructure (PKI), which is used in signing, emitting and maintaining certificates and revocation lists used in inter-stakeholder communication for operational purposes. ---|--- 5.1.2. ATM sub-functionality on SWIM yellow profile technical infrastructure and specifications General The SWIM yellow profile technical infrastructure is a ground distribution mechanism, facilitating communication between European ATM stakeholders in a distributed environment. The information services must be managed in a harmonised way and require that the information conveyed and the technical infrastructure be interoperable. The SWIM yellow profile technical infrastructure fulfils that communication and interoperability goal by being modular and providing different implementation options based on the web services stack of standards, including commitments to lower layer protocols, taking into account a wide range of needs for information exchanges in a approprieately secured way. The SWIM yellow profile technical infrastructure can run over any IP based network, such as public internet or new pan-European network services (PENS), based on the stakeholders’ needs. SWIM yellow profile technical infrastructure must be used for ATM data exchange for all other ATM functionalities. System requirements Stakeholders must ensure that all SWIM yellow profile technical infrastructure services can make use of the common PKI when it becomes operational in order to achieve the cyber security objectives appropriate for the service or services. 5.1.3. ATM sub-functionality on Aeronautical information exchange General Operational stakeholders must implement the following services that support the exchange of the aeronautical information using the SWIM yellow profile technical infrastructure as described in the deployment programme: (a) | notification of the activation of an airspace reservation/restriction (‘ARES’); ---|--- (b) | notification of the de-activation of an ARES; ---|--- (c) | pre-notification of the activation of an ARES; ---|--- (d) | notification of the release of an ARES; ---|--- (e) | aeronautical information feature on request; filtering possible by feature type, name and an advanced filter with spatial, temporal and logical operators; ---|--- (f) | query ARES information; ---|--- (g) | digital aerodrome charts; ---|--- (h) | ASM level 1; ---|--- (i) | airspace use plans (AUP, UUP) – ASM level 2 and 3; ---|--- (j) | digital NOTAM. ---|--- System requirements (a) | All the services listed in point 5.1.3 must comply with applicable SWIM specifications. ---|--- (b) | ATM systems operated by stakeholders referred to in point 5.3 must have the capacity to use the aeronautical information exchange services including digital NOTAM. ---|--- (c) | AIS systems operated by the stakeholders referred to in point 5.3 must have the capacity to provide digital NOTAM in accordance with the Eurocontrol specification for improving the pre-flight information bulletins (PIB) services for the airports referred to in point 5.3. ---|--- 5.1.4. ATM sub-functionality on Meteorological information exchange General Operational stakeholders must implement services that support the exchange of the following meteorological information using the SWIM yellow profiles described in the deployment programme: (a) | volcanic ash concentration; ---|--- (b) | meteorological information supporting aerodrome processes or aids involving the relevant MET information, translation processes to derive constraints for weather and convert such information in an ATM impact, where the system capability mainly targets a ‘time to decision’ horizon between 20 minutes and 7 days; ---|--- (c) | meteorological information supporting en-route/approach ATC process or aids involving the relevant MET information, translation processes to derive constraints for weather and convert such information in an ATM impact where the system capability mainly targets a ‘time to decision’ horizon between 20 minutes and 7 days; ---|--- (d) | meteorological information supporting network information management process or aids involving the relevant MET information, translation processes to derive constraints for weather and convert such information in an ATM impact, where the system capability mainly targets a ‘time to decision’ horizon between 20 minutes and 7 days and is implemented at a network level. ---|--- System requirements (a) | The implementation of the services referred to in point 5.1.4 must comply with applicable SWIM specifications. ---|--- (b) | ATM systems operated by stakeholders referred to in point 5.3 must have the capacity to use the MET information exchange services. ---|--- 5.1.5. ATM sub-functionality on Cooperative network information exchange General Operational stakeholders must implement services which support the exchange of the following cooperative network information using the SWIM yellow profile as specified in the deployment programme: (a) | maximum airport capacity based on current and near-term weather conditions; ---|--- (b) | synchronisation of network operations plan and all airport operations plans; ---|--- (c) | traffic regulations; ---|--- (d) | slots; ---|--- (e) | short term ATFCM measures; ---|--- (f) | ATFCM congestion points; ---|--- (g) | restrictions; ---|--- (h) | airspace structure, availability and utilisation; ---|--- (i) | network and en-route/approach operation plans. ---|--- System requirements (a) | The implementation of the services referred to in point 5.1.5 must comply with applicable SWIM specifications. ---|--- (b) | The Network Manager must support all operational stakeholders in exchanging data electronically for cooperative network management activities. ---|--- 5.1.6. ATM sub-functionality on flight information exchange (Yellow profile) General Operational stakeholders must implement services that support the exchange of flight information using the SWIM yellow profile, as specified in the deployment programme: (a) | related to FF-ICE Release 1 Services: | — | flight plan and routes generation and validation; ---|--- — | flight plans, 4D trajectory, flight performance data, flight status; ---|--- — | flights lists and detailed flight data; ---|--- (b) | related to flight update departure information; ---|--- (c) | flight update messages (‘FUM’) (Network Manager Business to Business (B2B) service). ---|--- System requirements (a) | The implementation of the services referred to in point 5.1.6 must comply with applicable SWIM specifications. ---|--- (b) | ATM systems operated by stakeholders referred to in point 5.3 must enable the use of the flight information exchange services. ---|--- 5.2. Geographical Scope SWIM services must be deployed in the EATMN. 5.3. Stakeholders required to implement the functionality and implementation target dates (a) | All the aeronautical information, flight information and cooperative network data exchanges must be implemented by all European area control centres, by the airports referred to in point 1.2, aeronautical information service provider and by the Network Manager; ---|--- (b) | Meteorological information exchange must be implemented by all European area control centres, by the airports referred to in point 1.2, by the Network Manager and by MET providers. ---|--- The common infrastructure components referred to in point 5.1.1 must be provided and operated by the above mentioned operational stakeholders by the implementation target date of 31 December 2024. They must must provide and operate SWIM sub-functionalities referred to in points 5.1.2 to 5.1.6 by the implementation target date of 31 December 2025. In deploying the SWIM functionality, Member States must ensure that civil or military cooperation is run to the extent required by point 3.2 of Annex VIII to Regulation (EU) 2018/1139. 5.4. Need for synchronisation The timely network-wide implementation of SWIM infrastructure and the activation of the relevant services are essential pre-requisites for most of common project one ATM functionalities. The relevant stakholders must synchronise their implementation plans and efforts according to the deployment programme that must aim to achieving the same level of equipage and improve the network usage. 5.5. The expected environmental improvements SWIM contributes to the overall environmental objectives of the other AFs by enabling interoperability and more efficient exchange of information between all ATM operational environments (en-route, airports, TMA, Network Manager). 5.6. Interdependencies with other ATM functionalities SWIM services enable the other ATM functionalities referred to in AF1, AF2, AF3 and AF4. 6\. AF 6: INITIAL TRAJECTORY INFORMATION SHARING 6.1. Operational and Technical Scope 6.1.1. ATM sub-functionality on initial air-ground trajectory information sharing General Initial air-ground trajectory information sharing contributes to the ‘Trajectory-based operations’ EOC. Air-ground trajectory exchange improves trajectory information. The preliminary steps for the deployment of initial trajectory information sharing consists of downlinking the extended projected profile (‘EPP’) data from the aircraft to the ATC systems and processing that data by those systems. System requirements (a) | Aircraft must be equipped with the capability to automatically down-link trajectory information using ADS-C EPP as part of the ATS B2 services. The trajectory data automatically down-linked from the airborne system must update the ATM system in accordance with the terms of the contract. ---|--- (b) | Data link communications ground systems must support ADS-C (downlink of aircraft trajectory using EPP) as part of the ATS B2 services while keeping compatibility with controller – pilot data link communications (‘CPDLC’) services as required by Commission Regulation (EC) No 29/2009 (3), including provision of service to flights equipped only with the Aeronautical Telecommunication Network Baseline 1 (‘ATN-B1’). ---|--- (c) | All ATS providers referred to in point 6.3 and the related ATC systems must be able to receive and process trajectory information from equipped aircraft. ---|--- (d) | The ATC systems must enable controllers to display the route of the downlinked trajectory. ---|--- (e) | The ATC systems must provide a warning to controllers in case of a discrepancy between the downlinked aircraft trajectory and the ground system trajectory elaborated using the filed flight plan route. ---|--- 6.1.2. ATM sub-functionality on Network Manager trajectory information enhancement General Network manager trajectory information enhancement contributes to the ‘Trajectory-based operations’ EOC. Trajectory information is enhanced by the use of air-ground trajectory exchange. A processing of such information by the Network Manager systems constitutes a further step for the deployment of initial trajectory information sharing. System requirements The Network Manager systems must use elements of the downlinked trajectories to enhance their information of trajectories flown by aircrafts. 6.1.3. ATM sub-functionality on initial trajectory information sharing ground distribution General Initial trajectory information sharing ground distribution contributes to the ‘Trajectory-based operations’ EOC. Trajectory information data coming from airborne systems is distributed on the ground in order to minimise the air- ground data transmissions and to ensure that all air traffic service units (‘ATSU’) involved in the flight management work with the same data. The trajectory data must be processed and displayed to the controllers in a harmonised way as set out in point 6.1.1. System requirements (a) | Ground systems must ensure that trajectory data downlinked from the aircraft is distributed between ATS units and between ATS units and the Network Manager systems. ---|--- (b) | The data link capability referred to in Regulation (EC) No 29/2009 is an essential prerequisite for the AF6. ---|--- (c) | A reliable, fast and efficient air/ground communication infrastructure must support initial trajectory information sharing. ---|--- 6.2. Geographical Scope Initial trajectory information sharing must be deployed in all ATS units providing air traffic services within the airspace for which the Member States are responsible in the ICAO EUR region. 6.3. Stakeholders required to implement the functionality and industrialisation and implementation target date (a) | ATS providers and the Network Manager must ensure that they enable initial trajectory information sharing above flight level 285 by the implementation target date of 31 December 2027. ---|--- (b) | Point 6.1.1 applies to all flights operating as general air traffic in accordance with instrument flight rules within the airspace above flight level 285 within the Single European Sky airspace as defined in Article 3(33) of Regulation (EU) 2018/1139. Aircraft operators must ensure that aircraft operating flights with an individual certificate of airworthiness first issued on or after 31 December 2027 are equipped with ADS-C EPP as part of ATS B2 capability, in accordance with the applicable standards in order to downlink aircraft trajectory. ---|--- (c) | The industrialisation target date for points 6.1.1, 6.1.2 and 6.1.3 of this Annex is 31 December 2023, pursuant to Article 4 of Implementing Regulation (EU) No 409/2013. ---|--- 6.4. Need for synchronisation All ANSPs, the Network Manager and airspace users must synchronise the implementation of the targeted system and service delivery set out in AF6 in accordance with the deployment programme to ensure network-wide enhancement of an interoperable air-ground communication infrastructure and improve the network usage of the functionality. Synchronised planning, including airspace users’ avionics roadmaps, will avoid implementation gaps and significant delays for individual stakeholders. 6.5. The expected environmental improvements Sharing airborne flight trajectory amongst stakeholders allows the airspace users to safely fly the most efficient trajectory. This will lead to increased fuel efficiency, reduced CO2 and noise emissions. The trajectory information sharing will enable further service development that will further reduce the negative environmental impact of aircraft activity. 6.6. Interdependencies with other ATM functionalities AF6 has interdependencies with airspace management and advanced flexible use of airspace referred to in AF3. * * * (1) Flight & Flow Information for a Collaborative Environment (FF-ICE). ICAO DOC 9965 2012 & ICAO DOC 9854 2005 (2) Commission Implementing Regulation (EU) 2019/123 of 24 January 2019 laying down detailed rules for the implementation of air traffic management (ATM) network functions and repealing Commission Regulation (EU) No 677/2011 (OJ L 28, 31.1.2019, p. 1). (3) Commission Regulation (EC) No 29/2009 of 16 January 2009 laying down requirements on data link services for the single European sky (OJ L 13, 17.1.2009, p. 3). * * *