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).