Panel

borderColor	black
borderStyle	dashed

Excerpt

This section describes the use cases related the eFPL usage by ANSPs.

Table of Contents

maxLevel	1
absoluteUrl	true
type	flat
separator	pipe

Warning

title	Status

WORK IN PROGRESS OUTDATED - content should not be used

Panel

title	Full table of contents

Table of Contents

absoluteUrl	true

Format

Use cases are documented using this format.

Name	Name of the UC, used for mnemonic and readability purposes.
Description	Brief description of the use case
Trigger Event	What causes the use case to occur?
Affected stakeholders	(AU, ANSP, NM etc…)
Assumptions	Assumptions of certain actions, conditions and systems in place
Preconditions	Requirements that must be in place prior to the use case
Use Case Steps	Description of the essential steps of the use case procedure
Postconditions	Requirements that must be in place following the use case
Benefits	Non exhaustive list of benefits expected from the use case

Overview

Data Category	Data Item	UC IdentifiersName
Content of the distributed eFPL		UC IdentifiersName
Flight Identification	GUFI	Use cases (ANSPs)Use cases (ANSPs)of GUFI for FF-ICE Message Association FF-ICE Message Received with Unknown GUFI
Flight Identification	Aircraft Identification
Flight Status	Operator Flight Plan Version	Use cases (ANSPs) Use cases (ANSPs)Management of Operator Flight Plan Version Display of the Operator Flight Plan Version to the ATCO
	Revalidation Status
	Revalidation Status Explanation
Flight Characteristics	Flight Rules
	Type of Flight
	Special Handling
	Flight Plan Originator
	Remarks
	Operator
	Equipment and Capabilities
	Supplementary Information Source
	Required Runway Visual Range
Aircraft Characteristics	Total number of aircraft
	Registration
	Aircraft Address
	SELCAL Code
	Mode A Code
	Number and type of aircraft
	Wake Turbulence Category
	Aircraft Approach Category
Departure/Destination Data	Departure Aerodrome
	Destination Aerodrome
	Estimated Off-Block Time
	Departure Airport Slot Identification
	Destination Airport Slot Identification
	Departure Runway
	Destination Runway
Alternates	Alternate Destination Aerodrome(s)
	Alternate Take-Off Aerodrome(s)
	Alternate En-Route Aerodrome(s)
Desired Route/Trajectory		ANSP Use of AU Filed Desired Route/Trajectory
Agreed Route/Trajectory		Use cases (ANSPs) of eFPL Trajectory Instead of RFL Profiles Use of (Expanded) Route Start Points for Trajectory Computation
Route/Traj. Group	Aircraft Take-off Mass	Use cases (ANSPs) Use cases (ANSPs)Display of the Aircraft Take-off Mass to the ATCO
	Requested Cruising Speed
	Requested Cruising Level
	Total Estimated Elapsed Time
	General Flight Constraint
Route/Traj. Element
	Along Route Distance
	Route Element Start PointUse cases (ANSPs)
	Route to Next Element
	Modified Route Indicator
	Route Truncation Indicator
	Requested Change
	Route/Trajectory Constraints
	Trajectory Point
	Geo Position
	Time
	Level
	Predicted Airspeed
	Predicted Ground Speed
	Wind Vector
	Assumed Altimeter Setting
	Temperature
	Trajectory Point Property	Use of Route/Trajectory Data for ToD/ToC
	Planned Delay
	Weight at Point	Mass per Point
Route/Traj. Aircraft Performance	Performance Profile Use cases (ANSPs)	Processing of the Performance Profile for Trajectory Computation Aircraft Performance Data for Flight Monitoring Aircraft Performance Data for Traffic Complexity Tool Aircraft Performance Data for MTCD Aircraft Performance Data for Sector Sequence
Route/Traj. Aircraft Performance	Speed Schedule Use cases (ANSPs)	Aircraft Take-off Mass & Speed Schedule for Trajectory Computation
Route to Revised Destination	Revised Destination
Route to Revised Destination	Route String to Revised Destination
Dangerous Goods	Dangerous Goods Information
AIRAC	AIRAC Reference
Supplementary Information	Fuel Endurance
	Persons on Board
	Emergency Radio
	Survival Capability
	Life Jacket Characteristics
	Aircraft Colour and Markings
	Pilot in Command
	Dinghies
	Remarks
Other European Items	Route Text
	Ifps Identifier
	Stay Information
	AO What-If ReRoute Indicator
	Replacement Flight Plan Indicator

ANSP System Use Cases (WORK IN PROGRESS)

Expand

(1)    The use cases presented in this section focus on enabling the use and consumption of FF-ICE/R1 information and data by ANSPs as mandated by CP1.
(2)    Nominal and non-nominal use cases are documented.
(3)    Nominal use cases refer to cases where the system behaves as expected and no exceptions occur.
(4)    Non-nominal use cases refer to cases that fall outside the expected or typical usage. They represent an atypical or exceptional use of the system, often involving error conditions, exceptions, or unusual user interactions.
(5)    This is a non-exhaustive list of use cases and may be expanded by individual ANSPs as they require.

Anchor

	ANSP Use Case 1
	ANSP Use Case 1

(DRAFT) ANSP Use Case 1: Use of GUFI for FF-ICE Message Association

Name	Use Case 1: Use of GUFI for FF-ICE Message Association
Description	Use of GUFI (Global Unique Flight Identifier) for FF-ICE messages association
Trigger Event	An FF-ICE publication message is received by the ANSP B2B user application
Affected stakeholders	AUs ANSPs (FDPS) NM
Assumptions	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.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic.
Use Case Steps	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.
Postconditions	1. Successful association of subsequent messages with retained flight plan data.
Benefits	1. Efficient association of FF-ICE message and eFPL data accuracy.

Anchor

	ANSP Use Case 2
	ANSP Use Case 2

(DRAFT) ANSP Use Case 2: Management of Operator Flight Plan Version

Name	Use Case 2: Management of Operator Flight Plan Version
Description	During predeparture, multiple stakeholders, including the pilot, may have different flight plan versions. Ensuring uniformity among all parties is vital. This use case focuses on validating the operator flight plan version.
Trigger Event	A distributed eFPL is received by the ANSP.
Affected stakeholders	AUs ANSPs (FDPS) NM
Assumptions	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.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. The Operator Flight Plan Version is provided by the AU in the filed eFPL 3. The Operator Flight Plan Version provided in the filed eFPL is shared by NM in the distributed eFPL.
Use Case Steps	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.
Postconditions	1. Stakeholders using the same flight plan version.
Benefits	1. Enhanced Data Accuracy: The ANSP system ensures that only the most recent and up-to-date flight plan data is used for air traffic management. This process enhances the accuracy of flight plan information, reducing the likelihood of outdated or conflicting data being integrated into the system. As a result, air traffic management decisions are based on the latest information, contributing to safer and more efficient operations.

Anchor

	ANSP Use Case 3
	ANSP Use Case 3

(DRAFT) ANSP Use Case 3: Display of the Operator Flight Plan Version to the ATCO

Name	Use Case 3: Display of the Operator Flight Plan Version to the ATCO
Description	Display of the operator flight plan version to the ATCO to mitigate the hazard of flight crew and ATCOs working with different versions of the flight plan.
Trigger Event	Flight crew and ATCOs using different operator flight plan versions potentially resulting in inconsistency between route/trajectory in the FMS and FDPS.
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	-
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. The operator flight plan version is provided by the AU in the filed eFPL 3. The operator flight plan version provided in the filed eFPL is shared by NM in the distributed eFPL.
Use Case Steps	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.
Postconditions	1. Inconsistency between flight plan versions used by flight crews and ATCO identified.
Benefits	1. Ability of the ATCO to check/confirm that they have the latest version of the operator flight plan.

Anchor

	ANSP Use Case 4
	ANSP Use Case 4

(DRAFT) ANSP Use Case 4: Processing of the Performance Profile for Trajectory Computation

Name	Use Case 4: Processing of the Performance Profile for Trajectory Computation
Description	Use of the aircraft performance climb and descent profile for trajectory computation.
Trigger Event	A distributed eFPL containing a performance profile is received by the ANSP.
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	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.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. The performance profile is provided by the AU in the filed eFPL 3. The performance profile provided in the filed eFPL is shared by NM in the distributed eFPL 4. The performance profile provided in the distributed eFPL is received by the ANSP
Use Case Steps	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.
Postconditions	1. After receiving the performance profile, the system will have data comprising a climb profile and a descent profile. Each profile is represented as a sequence of profile points, with each point containing information about distance, time duration, flight level or altitude, and optionally the true airspeed. 2. Following the reception of the climb and descent profiles, a comparison is made with the relevant departure and arrival segments of the FDPS local trajectory. This comparison assumes ideal conditions, including zero-wind, standard atmosphere, and no constraints. 3. As a result of this comparison, the system will identify any deviations or disparities between the received performance profile and the ideal trajectory and correction factors in terms of distance, time, flight level, and speed may be determined. 4. As a consequence of the comparison in step 2, the system will have calculated correction factors in terms of distance, time, flight level, and speed. These correction factors are now available for use by the FDPS during the trajectory computation. 5. The system is ready to apply correction factors to the trajectory computation as necessary. The FDPS is equipped with correction data that can be utilized to adjust the planned trajectory for more accurate flight performance.
Benefits	1. Utilising more precise flight performance data than the current BADA, offers significant advantages. This improved data becomes invaluable when a flight deviates from its original planned path due to in-flight events, as it equips ANSPs with specific performance information for trajectory prediction and computation.

Anchor

	ANSP Use Case 5
	ANSP Use Case 5

(DRAFT) ANSP Use Case 5: Aircraft Performance Data for Flight Monitoring

Name	Use Case 5: Aircraft Performance Data for Flight Monitoring
Description	This use case describes how the enhanced aircraft performance data included in the eFPL improve the computation of the flight profile allowing the FDP to timely and accurately detect possible restricted area infringements.
Trigger Event	Distributed eFPLs containing aircraft performance data are received by the NM (IFPS) and distributed to ANSPs. The ANSP FDPS detects a possible infringement of a restricted area.
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	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.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. The performance data is provided by the AU in the filed eFPL 3. The performance data provided in the filed eFPL is shared by NM in the distributed eFPL 4. The performance data provided in the distributed eFPL is received by the ANSP
Use Case Steps	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).
Postconditions	1. Possible infringements of restricted areas are detected more accurately and avoided
Benefits	1. Enhanced decision making and proactive air traffic management: Timely detection of possible restricted area infringements enables ATCOs to intervene promptly, reducing the possibility and frequency of such violations.

Anchor

	ANSP Use Case 6
	ANSP Use Case 6

(DRAFT) ANSP Use Case 6: Aircraft Performance Data for Traffic Complexity Tool

Name	Use Case 6: Aircraft Performance Data for Traffic Complexity Tool
Description	This use case describes how the enhanced aircraft performance data included in the eFPL improves the computation of the traffic load for each sector of an ATS Unit, improving situational awareness regarding traffic complexity and facilitating proactive air traffic management.
Trigger Event	A distributed eFPL is received by the ATSU.
Affected stakeholders	ANSPs (FDPS and traffic complexity tool) NM
Assumptions	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.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. A valid eFPL with an agreed trajectory is received by IFPS and shared with affected ATSUs.
Use Case Steps	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.
Postconditions	1. Traffic peaks are displayed more accurately to the traffic manager.
Benefits	1. Accurate trajectory of the eFPL before take-off is available for local traffic flow and complexity tools, and the ATM actors (FMP/Supervisor) will then have a better view on the traffic situation and its complexity and will be able to take more informed and efficient decisions.

Anchor

	ANSP Use Case 7
	ANSP Use Case 7

(DRAFT) ANSP Use Case 7: Aircraft Performance Data for MTCD

Name	Use Case 7: Aircraft Performance Data for MTCD
Description	This use case describes how the enhanced aircraft performance data included in the eFPL improves the computation of the forecasted trajectory of the aircraft, possibly reducing the number of false warnings.
Trigger Event	Distributed eFPLs containing aircraft performance data are received by the NM (IFPS) and distributed to ANSPs.
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	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.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. The performance data is provided by the AU in the filed eFPL 3. The performance data provided in the filed eFPL is shared by NM in the distributed eFPL 4. The performance data provided in the distributed eFPL is received by the ANSP
Use Case Steps	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.
Postconditions	1. MTCD alerts are displayed more accurately to ATCOs.
Benefits	1. Reduced number of false MTCD warnings, thus decreasing conflict solving times and reducing ATCO’s

workload.

Anchor

	ANSP Use Case 8
	ANSP Use Case 8

(DRAFT) ANSP Use Case 8: Aircraft Performance Data for Sector Sequence

Name	Use Case 8: Aircraft Performance Data for Sector Sequence
Description	This use describes how the enhanced aircraft performance data included in the eFPL improves the computation of the flight profile, thus providing an accurate sector sequence.
Trigger Event	Distributed eFPLs containing aircraft performance data are received by the NM (IFPS) and distributed to involved ANSPs.
Affected stakeholders	ANSPs NM
Assumptions	Distributed eFPL may be “area of interest” only.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. The performance data is provided by the AU in the filed eFPL 3. The performance data provided in the filed eFPL is shared by NM in the distributed eFPL 4. The performance data provided in the distributed eFPL is received by the ANSP
Use Case Steps	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.
Postconditions	1. Traffic is distributed to sectors more accurately.
Benefits	1. Proactive Air Traffic Management: Reduced number of “intruder” flights leading to improved situational awareness for the ATCO.

Anchor

	ANSP Use Case 9
	ANSP Use Case 9

(DRAFT) ANSP Use Case 9: Aircraft Take-off Mass & Speed Schedule for Trajectory Computation

Name	Use Case 9: Aircraft Take-off Mass & Speed Schedule for Trajectory Computation
Description	This use describes how the enhanced aircraft performance data included in the eFPL improves the computation of the flight profile, thus providing an accurate sector sequence.
Trigger Event	A distributed eFPL containing take-off mass, speed schedule and an aircraft type is received by the ATSU.
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	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.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. The take-off mass, speed schedule and the aircraft type are provided by the AU in the filed eFPL. 3. The take-off mass, speed schedule and the aircraft type in the filed eFPL are shared by NM in the distributed eFPL. 4. The provided speed schedule needs to be presented in the same form as the default reference parameters from BADA.
Use Case Steps	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.
Postconditions	1. The initially predicted trajectory (before entry into the FIR) and subsequent updates of the trajectory (with coordination data and/or position reports) will benefit from the more accurate initial take-off mass and speed schedule contained in the eFPL. 2. The improved trajectory prediction will give a more realistic view on the conduct of the flight within the FIR (and beyond), especially for departing flights. This will help to improve potential conflict detection and coordination processes.
Benefits	1. Earlier and more efficient conflict detection. 2. Less false alarms related to conflict detection. 3. Improved predictability for sector-sector and ATSU-ATSU coordination.

Anchor

	ANSP Use Case 10
	ANSP Use Case 10

(DRAFT) ANSP Use Case 10: Display of the Aircraft Take-off Mass to the ATCO

Name	Use Case 10: Display of the Aircraft Take-off Mass to the ATCO
Description	Display of the aircraft take off mass to the ATCO providing an improved “mental picture” of the expected climb performance of the aircraft.
Trigger Event	A distributed eFPL containing take-off mass and an aircraft type is received by the ATSU.
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	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.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. The take-off mass and the aircraft type are provided by the AU in the filed eFPL. 3. The take-off mass and the aircraft type in the filed eFPL are shared by NM in the distributed eFPL.
Use Case Steps	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.
Postconditions	1. Both planner and executive ATCOs have a better mental picture of the climb profile and the manoeuvring capabilities of the a/c. With this more accurate information the resolution of potential conflicts and the initiation of coordination can be achieved earlier and more efficiently.
Benefits	1. Reduced R/T required to ascertain the climb performance of aircraft. 2. Earlier and more efficient coordination depending on the specifics of the climb profile.

Anchor

	ANSP Use Case 11
	ANSP Use Case 11

(DRAFT) ANSP Use Case 11: Mass per Point

Name	Use Case 11: Mass per Point
Description	This use case details the use of mass per trajectory point in the FDPS.
Trigger Event	A distributed eFPL containing aircraft mass per point is received by the ATSU.
Affected stakeholders	ANSPs (FDPS) AUs NM
Assumptions	1. That eFPL submissions are accurate and timely, containing correct aircraft mass data at various points during the flight.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic. 2. The aircraft mass per specific point is provided by the AU in the filed eFPL. 3. The aircraft mass per specific point in the filed eFPL are shared by NM in the distributed eFPL.
Use Case Steps	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
Postconditions	1. Aircraft mass on the route points is used for to enhance operations
Benefits	1. The FDP is able to use a more precise performance information for each point to calculate an optimised route. 2. The emergency trajectories can benefit of updated performance data. 3. An optimised route enhancing the fuel efficiency and reduction of emissions

Anchor

	ANSP Use Case 12
	ANSP Use Case 12

(DRAFT) ANSP Use Case 12: FF-ICE Message Received with Unknown GUFI

Name	Use Case 12: FF-ICE Message Received with Unknown GUFI
Description	GUFIs are unique identifiers assigned to each flight, allowing ANSPs to track and manage aircraft effectively. However, sometimes ANSPs encounter FF-ICE messages that contain unknown GUFIs. This needs to be handled accordingly in a harmonised manner by all ANSPs.
Trigger Event	FF-ICE message received containing a GUFI that is unknown to the ANSP.
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	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.
Preconditions	1. Publication of FF-ICE messages from NM to message subscribers. Stakeholders’ user application subscribes to a topic and receives asynchronous messages published on that topic.
Use Case Steps	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.
Postconditions	1. Flight data associated to correct flight plan
Benefits	1. Using existing association techniques like IFPLID, ARCID, ADEP, ADES/EOBT in the case of an unknown GUFIs allows ANSPs to quickly and accurately identify and associate the FF-ICE message with a specific aircraft. This is crucial for tracking, managing, and ensuring the safety of the flight within the airspace. It provides a workaround when GUFIs are not immediately recognizable and ensures that the correct flight data is linked to the aircraft. 2. These techniques and services enhance the efficiency and accuracy of air traffic management. The ability to quickly identify and obtain the latest flight plan data for an aircraft, even with an unknown GUFI, streamlines decision-making processes and minimizes the chances of errors or misunderstandings.

Anchor

	ANSP Use Case 13
	ANSP Use Case 13

(DRAFT) ANSP Use Case 13: Use of eFPL Trajectory Instead of RFL Profiles

Name	Use Case 13: Use of eFPL Trajectory Instead of RFL Profiles
Description	The 4D trajectory data provided in an eFPL meaning that RFL profiles are no longer required.
Trigger Event	A 4D trajectory is received as part of an eFPL.
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	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.
Preconditions	-
Use Case Steps	1. Agreed trajectory used by ANSP FDPS.
Postconditions	1. Agreed trajectory received and used by ANSP FDPS with no requirement for “RFL profile”.
Benefits	1. Agreed trajectory more aligned with airspace user requirements. 2. ANSPs using the agreed trajectory from an eFPL resulting in more efficient flights and use of airspace.

Anchor

	ANSP Use Case 14
	ANSP Use Case 14

(DRAFT) ANSP Use Case 14: Use of (Expanded) Route Start Points for Trajectory Computation

Name	Use Case 14: Use of (Expanded) Route start points for trajectory computation
Description	Upon receipt of the eFPL, the sequence of route element start points from the eFPL is used as follows by the FPDS: Option 1: the FPDS no longer computes an expanded route from the route text, and uses instead the sequence of route element start points from the eFPL "as is"; Option 2: the FDPS still computes an expanded route from the route text, and then compares this computed expanded route with the expanded route from the distributed eFPL. The outcome of this comparison is then used by the FPDS to enhance the computed expanded route. For instance, expanded route points present in the eFPL but missing in the computed expanded route are added to the computed expanded route.
Trigger Event	A distributed eFPL containing an agreed route/trajectory with an expanded route is received by the ANSP.
Affected stakeholders	ANSPs (FDPS & ATFCM system) NM
Assumptions	1. The eFPL is the primary and authoritative source for the flight route/trajectory.
Preconditions	1. the NM publication service is consumed by the ANSP 2. An expanded route is provided by the AU in the filed eFPL (package 2B) 3. An expanded route and the route text are provided by NM in the distributed eFPL
Use Case Steps	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.
Postconditions	1. The FPDS has successfully received and processed the eFPL, and a route/trajectory has been established for the planned flight, considering any additional information provided in the eFPL.
Benefits	1. The eFPL is used to enhance and improve the computed expanded route, taking into account any additional route points or details provided in the eFPL

Anchor

	ANSP Use Case 15
	ANSP Use Case 15

(DRAFT) ANSP Use Case 15: ANSP Use of AU Filed Desired Route/Trajectory

Name	Use Case 15: ANSP Use of AU Filed Desired Route/Trajectory
Description	The ATM system receives and processes eFPL submissions, extracting the filed desired route/trajectory. The desired route/trajectory is available for display to the local Flow managers and the ATCOs included in the sector-sequence for the flight. Based on the tactical situation, and taking into account the desired route/trajectory, the ATCO assesses whether constraints set in agreed trajectory and being inside the centre’s AoR can be removed (bringing the flown trajectory closer to the desired trajectory). The ATCO -as needed- will initiate the necessary coordination with other internal sectors or the next ATSU (receiving ATSU), and/or flow managers. Flow managers will coordinate with the downstream flow managers/NM as needed (depends on impact). If the constraint can be removed, clearances are issued based on the trajectory with this constraint removed.
Trigger Event	None specific.
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	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.
Preconditions	None specific.
Use Case Steps	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.
Postconditions	1. The flown trajectory deviates from the initially received agreed trajectory and is closer to the desired trajectory.
Benefits	1. As the flown trajectory is closer to the desired (unconstrained) trajectory, the service to the AU is deemed improved.

Note: The sharing and use of filed desired route/trajectories is not listed as a requirement in the draft Confluence website.

Anchor

	ANSP Use Case 16
	ANSP Use Case 16

(DRAFT) ANSP Use Case 16: Use of Route/Trajectory Data for ToD/ToC

Name	Use Case 16: Use of Route/Trajectory Data for ToD/ToC
Description	ANSP use of ToD/TOC route/trajectory data
Trigger Event	An agreed route/trajectory received by the ANSPs containing ToD and ToC
Affected stakeholders	ANSPs (FDPS) NM
Assumptions	1. The agreed route/trajectory provided to ANSPs will contain ToD and ToC defined in terms of level, time, position and along route distance
Preconditions	1. The position of ToD and ToC points and other TCP-V points can be defined in terms of longitude/latitude.
Use Case Steps	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.
Postconditions	1. ANSP FDPS uses the actual ToD/ToC points from the agreed route/trajectory
Benefits	1. Accurate provision and use of ToD and ToC points.

Expand

title	Work Area / Old content

Use of eFPL for Visualisation

General Description

Several items of the eFPL can be displayed to various actors in an ACC for enhancing their situational awareness and satisfying additional information needs.

Use of the eFPL data as an analysis tool – for learning purposes and training
Visualisation of eFPL data as a Fall back mechanism, should the system encounter failure
Visualisation of eFPL data enabling to perform ATC even when radar contact has been lost (Lack of contact with AU, procedural separation mechanisms)

Relevant eFPL content

These items include:

Agreed 4D Trajectory
Unconstrained Trajectory

Note
To be clarified: is this the desired trajectory captured in the filed eFPL, or the performance profile, which a zero-wind, standard atmosphere profile reflective of the flight capabilities and desired parameters.

Trajectory Change Points (TCP)
FPL2012 Field 15

Actors

Flight Data Assistant
Flow Manager
Supervisor
Coordination Controller
Executive Controller

Use of eFPL for Flow Management (Traffic Complexity Tools)

General Description

The information of the eFPL can be used in Flow- and Complexity Tools in order to improve the quality of the respective forecasts and the related planning for sector configurations and staff allocation.

Info

Quote from ICAO FF-ICE Guidance Material, Section “Implementation Strategy”
By taking the first step of accepting FF-ICE flight plans through the filing service, ASPs would gain access to more detailed trajectory information. This would be useful for strategic traffic flow management purposes, at the same time allowing ASPs to explore/develop other capabilities made possible by the additional trajectory information. ASPs will be able to gain experience in using the trajectory information and hence better build up their system capabilities for information processing, ……

Relevant eFPL content

Take-off Mass ( Would be used in EFD)
Performance data: performance profile, speed schedule ( Would be used in EFD)
Agreed 4D Trajectory
Trajectory Change Points (TCP)
FPL2012 Field 15

Actors

Flow Manager
Supervisor

Use of eFPL data in Core ATC system (FDPS)

General Description

The information of the eFPL can be used in various components of the core ATS-System, where flight plan information is used and needed. The mainly affected component would be the Flight Data Processing System (FDPS), but also other components could benefit directly or indirectly from eFPL information, e.g. Arrival Management Systems and Conflict Detection Tools

Relevant eFPL content

Take-off Mass:
- Displaying the take-off mass to the ATCO with an indication whether this is considered heavy for such A/C type could give an indication on whether some ROCD can be made or not, without the ATCO having to ask, thus saving frequency time.
  - As an example, A320 is categorised as ”medium” but could be an actual ”heavy”
- as input to the local trajectory computation
Performance data:
- Performance profile
- Speed schedule
Agreed 4D Trajectory
Trajectory Change Points (TCP)
- In today's operations, ANSP systems commonly ignore, or make assumptions on, level constraints and “clip them out”. This operationally leads to (1) clearances instructed by the ATCO (e.g. instructs FL350, while the clipped out level was FL300) and (2) sometimes intruders to our next partner. Especially if we know levels because of regulations, situation (2) would no longer occur. The information about the reason why a level constraint is present in the trajectory (for instance, PTR or regulation) will help avoid (2)
FPL2012 Field 15

Actors

Supervisor
Coordination Controller
Executive Controller

Use of the distributed eFPL by an ANSP

The data contained in the eFPL can be used by an ANSP in different ways:

ATC related

Several items of an eFPL can be displayed to various actors in an ACC (Flight Data Assistant, Flow Manager, Supervisor, Coordination Controller, Executive Controller) for enhancing their situational awareness and satisfying additional information needs. For instance:
- Use of the eFPL data as an analysis tool – for learning purposes and training
- Visualisation of eFPL data as a Fall back mechanism, should the system encounter failure
- Visualisation of eFPL data enabling to perform ATC even when radar contact has been lost (Lack of contact with AU, procedural separation mechanisms)
The eFPL can be used in various components of the core ATS-System, where flight plan information is used and needed. The mainly affected component would be the Flight Data Processing System (FDPS), but also other components could benefit directly or indirectly from eFPL information, e.g. Arrival Management Systems and Conflict Detection Tools.

ATFM related

The information of the eFPL can be used in Flow- and Complexity Tools in order to improve the quality of the respective forecasts and the related planning for sector configurations and staff allocation, as acknowledged in the ICAO FF-ICE Implementation Guidance Manual, Section “Implementation Strategy”
- By taking the first step of accepting FF-ICE flight plans through the filing service, ASPs would gain access to more detailed trajectory information. This would be useful for strategic traffic flow management purposes, at the same time allowing ASPs to explore/develop other capabilities made possible by the additional trajectory information. ASPs will be able to gain experience in using the trajectory information and hence better build up their system capabilities for information processing, …

The following table provides

Business UCs

Improve flight information presented to the ATCO

Name	Improve flight information presented to the ATCO
Actors	Operational: ATCO Systems: FDPS, NM Publication Service
Preconditions	the NM Publication Service is consumed by the ANSP
Trigger	A distributed eFPL is received by the ANSP.
Description
related eFPL content UCs	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 ...

Support ATCO in non-nominal situations

Name	Support ATCO in non-nominal situations
Actors	Operational: ATCO Systems: FDPS, NM Publication Service
Preconditions	the NM Publication Service is consumed by the ANSP
Trigger	A distributed eFPL is received by the ANSP.
Description
related eFPL content UCs	Use of GUFI for Ffice Publication Messages correlation Display of the Agreed Route/Trajectory to the ATCO when radar contact has been lost ...

Version	Old Version 58	New Version Current
Changes made by	LEPORI Hubert	LEPORI Hubert
Saved on	2023 Nov 07	2024 Apr 24

Versions Compared

Key

Format

Overview

ANSP System Use Cases (WORK IN PROGRESS)

(DRAFT) ANSP Use Case 1: Use of GUFI for FF-ICE Message Association

(DRAFT) ANSP Use Case 2: Management of Operator Flight Plan Version

(DRAFT) ANSP Use Case 3: Display of the Operator Flight Plan Version to the ATCO

(DRAFT) ANSP Use Case 4: Processing of the Performance Profile for Trajectory Computation

(DRAFT) ANSP Use Case 5: Aircraft Performance Data for Flight Monitoring

(DRAFT) ANSP Use Case 6: Aircraft Performance Data for Traffic Complexity Tool

(DRAFT) ANSP Use Case 7: Aircraft Performance Data for MTCD

(DRAFT) ANSP Use Case 8: Aircraft Performance Data for Sector Sequence

(DRAFT) ANSP Use Case 9: Aircraft Take-off Mass & Speed Schedule for Trajectory Computation

(DRAFT) ANSP Use Case 10: Display of the Aircraft Take-off Mass to the ATCO

(DRAFT) ANSP Use Case 11: Mass per Point

(DRAFT) ANSP Use Case 12: FF-ICE Message Received with Unknown GUFI

(DRAFT) ANSP Use Case 13: Use of eFPL Trajectory Instead of RFL Profiles

(DRAFT) ANSP Use Case 14: Use of (Expanded) Route Start Points for Trajectory Computation

(DRAFT) ANSP Use Case 15: ANSP Use of AU Filed Desired Route/Trajectory

(DRAFT) ANSP Use Case 16: Use of Route/Trajectory Data for ToD/ToC

Page Comparison

Versions Compared

Key

Format

Overview

ANSP System Use Cases (WORK IN PROGRESS)

(DRAFT) ANSP Use Case 1: Use of GUFI for FF-ICE Message Association

(DRAFT) ANSP Use Case 2: Management of Operator Flight Plan Version

(DRAFT) ANSP Use Case 3: Display of the Operator Flight Plan Version to the ATCO

(DRAFT) ANSP Use Case 4: Processing of the Performance Profile for Trajectory Computation

(DRAFT) ANSP Use Case 5: Aircraft Performance Data for Flight Monitoring

(DRAFT) ANSP Use Case 6: Aircraft Performance Data for Traffic Complexity Tool

(DRAFT) ANSP Use Case 7: Aircraft Performance Data for MTCD

(DRAFT) ANSP Use Case 8: Aircraft Performance Data for Sector Sequence

(DRAFT) ANSP Use Case 9: Aircraft Take-off Mass & Speed Schedule for Trajectory Computation

(DRAFT) ANSP Use Case 10: Display of the Aircraft Take-off Mass to the ATCO

(DRAFT) ANSP Use Case 11: Mass per Point

(DRAFT) ANSP Use Case 12: FF-ICE Message Received with Unknown GUFI

(DRAFT) ANSP Use Case 13: Use of eFPL Trajectory Instead of RFL Profiles

(DRAFT) ANSP Use Case 14: Use of (Expanded) Route Start Points for Trajectory Computation

(DRAFT) ANSP Use Case 15: ANSP Use of AU Filed Desired Route/Trajectory

(DRAFT) ANSP Use Case 16: Use of Route/Trajectory Data for ToD/ToC