1. The initial distribution of the eFPL includes the GUFI, and that all relevant systems and stakeholders involved in air traffic management will retain and manage this information. This implies that the GUFI is reliably available as part of the initial flight data.
2. For all other cases where the trigger for the publication message is not the first distribution of the eFPL (e.g., flight plan updates, cancellations, or changes in filing status after NM re-evaluation), the GUFI is used to correctly associate the received FF-ICE publication message with the corresponding flight. This assumes that the GUFI remains consistent and serves as a reliable link between different updates or changes in the flight plan and the associated FF-ICE data.
3. In the event of an unknown GUFI, the use case assumes that there is a mechanism in place for obtaining the latest eFPL agreed upon by NM (including the GUFI) using the flight data request service as explained in the use case related to unknown GUFI.

1. When the trigger for the publication message is the first distribution of the eFPL agreed by NM, the GUFI is stored together with the rest of the associated flight data.
2. For all the other cases, for instance when the trigger for the publication message is a flight plan update, a flight plan cancellation or a change of filing status following a flight plan re-evaluation by NM, the GUFI is used to associate the received FF-ICE message to the correct flight.
3. In the case of an unknown GUFI, the latest eFPL agreed by NM (and the GUFI) will be obtained through the use of the Flight Data Request service.

1. Affected stakeholders have access to and utilise the same flight plan version to ensure safe and coordinated operations.
2. Processes are in place for assessing the validity of the operator flight plan version.

1. Upon receipt of the eFPL, the ANSP system checks that the value of the Operator Flight Plan Version is equal to or greater than that of the previous eFPL received for the same flight and discards the received eFPL if this check fails.
2. If the validation check for the Operator Flight Plan Version is successful, the ANSP system proceeds with the data integration and processing, considering the received eFPL as valid and usable for air traffic management purposes.

-

1. The Operator Flight Plan Version is displayed on request to the ATCO when there is discrepancy between route in the FMS and ground system.

1. It is assumed that the performance profile received is accurate and reliable, and that the climb and descent profiles are correctly represented in terms of distance, time, flight level or altitude, and optional true airspeed.
2. The comparison of climb and descent profiles with the FDPS local trajectory assumes ideal conditions, including zero-wind, a standard atmosphere, and the absence of any constraints or deviations caused by external factors such as weather.
3. The use case assumes that the performance profile is received and processed in near real-time, allowing for timely adjustments to the flight trajectory.
4. It is assumed that correction factors can be determined and applied as needed by the FDPS for trajectory computation.
5. The use case assumes that there are no aircraft-specific issues or limitations that would prevent the application of correction factors, and that the flight can be adjusted accordingly.
6. The use case assumes that there are no unexpected events or emergencies that would require deviations from the planned trajectory beyond what is accounted for in the correction factors.

1. A performance profile is received. It is composed of a climb profile and a descent profile, both expressed as a sequence of profile points each containing distance, time duration, flight level or altitude, and optionally the true airspeed.
2. Upon receipt, the climb and descent profiles are compared with the relevant departure and arrival portions of the FDPS local trajectory assuming zero-wind, standard atmosphere and no constraint.
3. This comparison produces correction factors (in distance, time, level, speed...) that can be subsequently applied by the FDPS during the trajectory computation, as appropriate.

1. Restricted areas are dynamically activated.
2. The trajectory computed by the IFPS does not result in a possible infringement of a restricted area due to the timing of activation (tactical activation after coordination).
3. The eFPL is not rejected by the IFPS and is distributed to the concerned ANSPs.

1. Based on the aircraft performance data provided in the eFPLs, the FDPS computes a flight profile which is more accurate (than the one computed using generic aircraft performance data), especially during climb and descent phases due to the enhanced climb and descent profiles available in the eFPL.
2. Consequently, the FDPS is able to correctly detect that the calculated profile will result in an infringement of a restricted area, a capability not achievable using generic aircraft performance data.
3. This could prompt in a timely Area Proximity Warning (APW).

1. It is assumed that the enhanced aircraft performance data included in the eFPL is accurate and reliable. Inaccurate or unreliable data could lead to incorrect computations and unreliable traffic load assessments.
2. The use case assumes that eFPL is consistently available and accessible for all flights within the ATSU AoR.
3. It is assumed that all relevant AUs comply with the standards and protocols for providing and updating eFPL data.
4. The use case assumes that the improved computation of traffic load from eFPL data leads to enhanced situational awareness. This assumption implies that the data is effectively integrated into the traffic management system.
5. It is assumed that the eFPL data is complete and contains all necessary information to calculate traffic load accurately. Missing or incomplete data could affect the accuracy of the computation.
6. The use case assumes that the enhanced situational awareness leads to proactive air traffic management. This assumes that the ATS Unit has the capacity and procedures in place to act on the improved traffic complexity information.
7. The use case assumes that the technical infrastructure, including hardware and software systems, required to process and analyse the eFPL data, is in place and functioning correctly.

1. Upon reception of an eFPL at the ATSU, the local traffic flow and complexity tool will make use of the contained data to update (and improve) its traffic flow and complexity forecast for the local airspace.
2. Based on the aircraft performance data provided in the eFPLs, the traffic complexity tool computes flight profiles which are more accurate (than the one computed using generic aircraft performance data), thus correctly computing the traffic load for each sector and providing the traffic manager with solid situational awareness regarding traffic complexity (occupancy count and other metrics).
3. The FMP and/or supervisor will make use of this improved forecast in order to make more informed decisions on sector configurations, sector allocations and/or flow measures.

1. It is assumed that the enhanced aircraft performance data included in the eFPL is accurate, reliable, and up to date. Inaccurate or outdated data may lead to incorrect trajectory computations and ineffective reduction of false warnings.
2. The use case assumes that the eFPL is consistently available for all relevant flights. The eFPL data must be accessible and complete for this purpose.
3. It is assumed that all relevant AUs adhere to the standards and protocols for providing and updating the eFPL data.
4. The use case assumes that the eFPL data can be effectively integrated into the MTCD tool. This integration should be seamless and not hinder the existing operational flow.
5. It is assumed that the MTCD is capable of accurately utilizing the enhanced data to compute more precise forecasted trajectories. The computation system should not introduce errors.
6. The use case assumes that the enhanced data is updated and processed in a timely manner, allowing for real-time or near-real-time trajectory forecasting. Delays in data processing may impact the effectiveness of reducing false warnings.
7. It is assumed that the technical infrastructure, including software and hardware systems, required for processing and analysing eFPL data and conducting trajectory computations, is in place and functioning correctly.

1. Based on the aircraft performance data provided in the eFPLs, the MTCD feature can forecast a more accurate vertical profile for the flight.
2. This can possibly allow for a finer tuning of the MTCD algorithm’s uncertainty parameters, thus reducing the number of unwanted warnings.

Distributed eFPL may be “area of interest” only.

1. Based on the aircraft performance data provided in the eFPLs, the FDPS computes the flight profile, leading to an accurate sector sequence.
2. Number of “intruder” flights (traffic that is not planned to cross a sector, but enters nonetheless) would thus decrease, providing the ATCO with an improved situational awareness.

1. The individual take-off mass and speed schedule received within the eFPL for each flight is more accurate than that received from BADA. Therefore, the computed trajectory of the flight will be an improved model of the true flight profile, especially the climb part of the trajectory.
2. That the eFPL is consistently available for all relevant flights and can be reliably transmitted to the FDPS.
3. That AUs adhere to the standards and protocols for providing and updating eFPL data, including take-off mass and speed schedule information.
4. The FDPS checks whether the received take-off mass and speed schedule values fall within the permissible interval defined by the aircraft type's minimum and maximum parameters. It is assumed that these limits are appropriate for the specific aircraft and that deviations from these limits could potentially affect the flight.
5. The FDPS is assumed to be capable of dynamically replacing its default parameter for take-off mass and speed schedule with the values received from the eFPL. This assumes that the FDPS has the necessary flexibility and capability to adapt to the new data.
6. The FDPS will use the received take-off mass and speed schedule for its initial trajectory computation. It is assumed that this initial computation is an important step in the flight planning process and will be conducted accurately.
7. That the technical infrastructure, including software and hardware systems, required for processing and analysing eFPL data and conducting trajectory computations, is in place and functioning correctly.

1. An eFPL containing a take-off mass and speed schedule is received by the ATS system and is relayed to the FDPS for processing.
2. The FDPS checks if the value of the received take-off mass and speed schedule are contained in the interval between minimum and maximum take-off-mass and speed schedule parameters for the aircraft type.
3. If this is the case, then the FDPS replaces its default parameter for the take-off mass and/or speed schedule (e.g. the static adapted BADA parameter) with the take-off mass and /or speed schedule received within the eFPL and will use these for its initial trajectory computation.

1. The individual take-off mass received within the eFPL for each flight is more accurate than that received from BADA.
2. That eFPL data, including the take-off mass, is consistently available for relevant flights and can be reliably transmitted to ANSPs.
3. That AUs adhere to the standards and protocols for providing eFPL data, including take-off mass information.
4. The ANSP FDPS checks whether the received take-off mass value falls within the permissible interval defined by the aircraft type's minimum and maximum parameters. This assumes that these limits are appropriate for the specific aircraft type and that deviations from these limits could potentially affect the flight.
5. That the ANSP system is capable of displaying the take-off mass to the ATCO in a suitable and easily interpretable form. This assumes that the ATCO's HMI can accommodate this information, whether in a flight label, electronic flight strip, or a separate pop-up window.
6. The display includes a quantitative indication of whether the aircraft's take-off mass is heavier or lighter compared to the default reference (e.g., BADA) take-off mass used in internal trajectory prediction. This assumes that the system can effectively calculate and present this comparison.
7. That the indication of take-off mass provides value to the ATCO by helping them assess and build a mental picture of the climb profile of the flight. It further assumes that ATCOs can use this information to evaluate possible rates of climb and assess potential impacts on conflicts and coordination with adjacent sectors.

1. A take-off mass and a type of aircraft are received in the eFPL.
2. The ANSP FDPS checks if the value of the received take-off mass is contained in the interval between minimum and maximum take-off-mass parameter for the aircraft type.
3. When this is the case and when assuming the flight, the take-off mass is displayed to the ATCO in a suitable form (depending on the ATCO HMI, e.g. in the flight label or in an electronic flight strip or a separate pop-up window) with a quantitative indication whether the a/c take-off-mass is heavier or lighter for this aircraft type compared to the default reference (e.g. BADA) take-off mass used in the internal trajectory prediction.
4. Optionally the display of the take-off mass could only be triggered if the difference to the default reference (e.g. BADA) take-off mass exceeds a certain threshold (e.g. 5%, 10%).
5. The indication of the take-off mass can help the ATCO to better assess and build a mental picture of the climb profile of the flight. The ATCO can use this information to directly evaluate whether some rate of climb can or cannot be achieved by the aircraft, and to earlier infer possible impacts on conflicts and coordination with adjacent sectors. Both, planner and executive ATCO can use this information.
6. In case the take-off mass is used for trajectory prediction in the FDPS, the use case still might make sense for flights with an extremely low or high take-off mass (e.g. > 10% deviation from the default reference (e.g. BADA) take-off mass). Only in these cases it should be displayed to the relevant ATCO.

1. That eFPL submissions are accurate and timely, containing correct aircraft mass data at various points during the flight.

1. The ATM system receives and processes eFPL submissions, extracting the aircraft mass per point data.
2. The ATM system considers the aircraft's mass when determining altitude changes, speed adjustments, and spacing between aircraft.
3. This optimization not only improves fuel efficiency but also enhances safety by reducing the likelihood of conflicts or disruptions due to unexpected changes in mass.
4. By factoring in aircraft mass data, the ATM system can make real-time decisions about airspace utilization, including sector capacity and traffic flow management.
5. In the event of an emergency or diversion, the system can use aircraft mass information to calculate optimal routes for safe landings, taking into account the aircraft's changing weight

1. ANSPs assume that GUFIs, as unique identifiers, are consistently accurate and reliable. They rely on the assumption that GUFIs are not duplicated, reused, or altered in a way that could lead to confusion or errors in air traffic management. This assumption is critical for maintaining the overall safety and effectiveness of the system.

1. In the case of an unknown GUFI, existing association techniques (IFPLID, ARCID, ADEP, ADES/EOBT) may be used.
2. The latest eFPL agreed by NM may be obtained using the Flight Data Request service.

RFL is used for RAD purposes and refers to the actual requested cruising level as specified in the FPL2012 item 15 point where the transition from the previous RFL to the new RFL is commenced.

1. Agreed trajectory used by ANSP FDPS.

1. The eFPL is the primary and authoritative source for the flight route/trajectory.

Option 1: The FPDS no longer computes an expanded route from the route text and uses the sequence of route element start points from the eFPL "as is."
1. The FPDS receives an eFPL from IFPS.
2. Extract the sequence of route element start points from the eFPL.
3. Instead of computing an expanded route from the route text, the FPDS uses the extracted sequence of route element start points directly as the flight route.

Option 2: The FPDS still computes an expanded route from the route text, compares it with the eFPL route, and enhances the computed route based on the comparison.
1. The FPDS receives an eFPL from IFPS.
2. Extract the sequence of route element start points from the eFPL.
3. Compute an initial expanded route from the route text of the eFPL.
4. Compare the initial expanded route with the route derived from the eFPL's route element start points.
5. Identify discrepancies between the two routes, such as missing or additional route points.
6. Enhance the initial computed route using information from the eFPL. This may involve adding route points present in the eFPL but missing in the computed route.

1. That the filed desired route/trajectory is provided to ANSPs.
2. The ATM system has the capability to accurately extract and provide the desired route/trajectory from the submitted eFPLs and is displayed and used by ATCOs and flow managers.

1. The ANSP receives eFPL submissions from IFPS.
2. It processes these submissions to extract the desired route/trajectory information.
3. The extracted desired trajectory is made available for display to local flow managers and ATCOs.
4. ATCOs assess the tactical situation, taking into account the desired trajectory and current operational conditions.
5. They evaluate whether constraints set in the agreed trajectory can be removed to bring the flown trajectory closer to the desired trajectory.

1. The agreed route/trajectory provided to ANSPs will contain ToD and ToC defined in terms of level, time, position and along route distance

1. The ANSP receives eFPL submissions from IFPS containing the agreed route/trajectory.
2. The ANSP uses the ToD and ToC points as defined in the agreed route/trajectory.

Operational: ATCO

Systems: FDPS, NM Publication Service

• the NM Publication Service is consumed by the ANSP

Use of GUFI for Ffice Publication Messages correlation

Checking the validity of the Operator Flight Plan Version
Display of the Operator Flight Plan Version to the ATCO

Processing of the Aircraft Take-off Mass for trajectory computation by the FDPS
Display of the Aircraft Take-off Mass to the ATCO

Use of the (Expanded) Route Element Start Points for trajectory computation by the FDPS 

Processing of the Performance Profile for trajectory computation by the FDPS 

Processing of the Speed Schedule for trajectory computation by the FDPS 

...

Operational: ATCO

Systems: FDPS, NM Publication Service

• the NM Publication Service is consumed by the ANSP

Use of GUFI for Ffice Publication Messages correlation

Display of the Agreed Route/Trajectory to the ATCO when radar contact has been lost

...