Annex 1 - Flight Data Processing System

BUSINESS UNIT ATMAS UNCLASSIFIED E184-01-04449SAD

Issue A-DraftDate: 09/05/06

ANNEX 1

FPPS AND LFDPS

FUNCTIONAL DESCRIPTION

This ANNEX contains a total of 106 pages

E184-01-04449SAD_A-Draft UNCLASSIFIED



LIST OF ABBREVIATIONS

ABBR. DESCRIPTION

ACC Area Control Centre

ADS Automatic Dependent Surveillance

AFTN Aeronautic Fixed Telecommunication Network

AoI Area of Interest

AoR Area of Responsibility

ARO Airport Reporting Offices

ATC Air Traffic Control

ATFM Air Traffic Flow Management

ATM Air Traffic Management

ATS Air Traffic Services

ATSU ATS Unit

AWP Auxiliary Working Position

CFL Cleared Flight Level

CFMU Central Flow Management Unit

CWP Control Working Position

EATCHIP European ATC Harmonisation and Integration Program

ETO Estimated Time Over

FDPS Flight Data Processing System

FIR Flight Information Region

FMS Flight Management System

GAT General Air Traffic

HMI Human Machine Interface

ICAO International Civil Aviation Organisation

IFPS Initial Flight Plan System

IFR Instrument Flight Rules

LAN Local Area Network

LoA Letter of Agreement

MTCD Medium term Conflict Detection

NDB Non Directional Beacon

OAT Operational Air Traffic

OLDI On-Line Data Interchange

RNAV Area Navigation




SFPL System Flight Plan

SID Standard Initial Departure

SSR Secondary Surveillance Radar

STAR Standard Arrival

SYSCO System Supported Co-Ordination

TOC Top Of Climb

TOD Top Of Descent

TSA Temporary Segregated Area

VFR Visual Flight Rules

VOR VHF Omni-directional Radio Range

VSP Variable System Parameter

WAN Wide Area Network

WP Working position




Table Of Contents

1. SCOPE ............................................................................................................................................ 8

2. REFERENCE DOCUMENTS ..................................................................................................... 10

3. FDP SYSTEM CONTEXT DESCRIPTION .............................................................................. 12

4. NODE ROLES AND OPERATIONAL STATES ....................................................................... 18

4.1 NODE ROLES..............................................................................................................................184.2 OPERATIONAL STATES...............................................................................................................195. SYSTEM FLIGHT PLAN REFERENCE MODEL ................................................................... 24

5.1 SYSTEM FLIGHT PLAN DEFINITION...........................................................................................245.2 SYSTEM FLIGHT PLAN STATES MODEL......................................................................................285.2.1 INACTIVE-READY-TO-BE-SENT TRANSITION...............................................................................285.2.2 READY-TO-BE-SENT-SENT TRANSITION......................................................................................285.2.3 TERMINATED STATUS FOR FPPS.................................................................................................285.2.4 INACTIVE – PENDING TRANSITION.............................................................................................295.2.5 PENDING – ACTIVE TRANSITION................................................................................................295.2.6 INACTIVE-ACTIVE TRANSITION..................................................................................................295.2.7 SFPL STATE TRANSITION FROM ACTIVE TO LIVE...................................................................295.2.8 SFPL STATE TRANSITION FROM LIVE TO TERMINED.............................................................295.2.9 UNDO ORDERS..........................................................................................................................305.2.10 SFPL STORAGE.......................................................................................................................305.2.11 VFR FLIGHTS HANDLING........................................................................................................306. CORE FUNCTIONS DESCRIPTION ........................................................................................ 33

6.1 ENVIRONMENTAL DATA PROCESSING........................................................................................336.1.1 GENERAL..................................................................................................................................336.1.2 STATIC DATA............................................................................................................................346.1.2.1 Airspace Data Handling..........................................................................................................346.1.2.2 Aircraft Data..........................................................................................................................406.1.2.3 Pool of SSR Codes.................................................................................................................406.1.3 DYNAMIC DATA........................................................................................................................416.2 MESSAGE HANDLING..................................................................................................................426.2.1 GENERAL..................................................................................................................................426.2.2 ATS MESSAGES RECEPTION.....................................................................................................456.2.3 MANUALLY TRIGGERED GENERATION OF MESSAGES...............................................................466.2.3.1 Transmission of Free-text Messages.......................................................................................466.2.3.2 Messages Addressing.............................................................................................................466.2.4 MET / AIS MESSAGES RECEPTION.............................................................................................476.2.5 ATFM MESSAGES HANDLING....................................................................................................476.2.5.1 Slot Allocation Message (SAM) Handling..............................................................................486.2.5.2 Slot Revision Message (SRM) Handling................................................................................496.2.5.3 Slot Cancellation Message (SLC) Handling............................................................................496.2.5.4 Flight Suspension Message (FLS) Handling...........................................................................50




6.2.5.5 De-Suspension Message (DES) Handling...............................................................................516.2.5.6 First System Activation (FSA) Message Transmission............................................................526.2.6 CO-ORDINATION MESSAGES EXCHANGE....................................................................................536.3 INITIAL FLIGHT DATA HANDLING.............................................................................................556.3.1 GENERAL..................................................................................................................................556.3.2 SFPL CREATION.......................................................................................................................576.3.2.1 Creation of a SFPL by Manual Input......................................................................................586.3.2.2 Creation of SFPL by Message Reception................................................................................586.3.2.3 Creation of SFPL by Repetitive Flight Plan Database.............................................................596.3.3 DETERMINATION OF THE ESTIMATED TAKE OFF TIME (ETOT).................................................616.3.4 INITIAL SFPL DATA MODIFICATIONS........................................................................................616.3.4.1 Modifications upon reception of an ATS message..................................................................616.3.4.2 Manual modifications.............................................................................................................626.4 FLIGHT PROGRESS DATA HANDLING.........................................................................................636.4.1 GENERAL..................................................................................................................................636.4.2 SFPL DATA UPDATE UPON SYSTEM CALCULATIONS................................................................656.4.3 MANUAL SFPL DATA UPDATE.................................................................................................666.5 TRAJECTORY PREDICTION.........................................................................................................676.5.1 GENERAL..................................................................................................................................676.5.2 DATA SOURCES.........................................................................................................................686.5.3 ROUTE ANALYSIS AND EXTRACTION.........................................................................................696.5.4 4D PROFILE CALCULATION.......................................................................................................706.5.5 SUSPENSION OF TRAJECTORY PREDICTION CALCULATION........................................................736.5.6 UPPER WIND DATA....................................................................................................................736.6 SFPL DATA DISTRIBUTION.......................................................................................................746.6.1 FPPS TO LFDPS SYSTEM FLIGHT PLAN DISTRIBUTION.............................................................746.6.2 FLIGHT PLAN DATA DISTRIBUTION FROM LFDPS TO USERS......................................................746.7 SSR CODES MANAGEMENT AND ASSIGNMENT..........................................................................756.7.1 GENERAL..................................................................................................................................756.7.2 SSR CODES MANAGEMENT.......................................................................................................756.7.2.1 ORCAM Rules ADAPTATION.............................................................................................766.7.2.2 PSSR CODES ASSIGNMENT TO FLIGHTS.......................................................................786.7.2.3 ASSR CODES ASSIGNMENT TO DEPARTING FLIGHTS................................................786.7.2.4 ASSR CODES ASSIGNMENT TO ENTERING FLIGHTS...................................................786.7.2.5 SSR CODE DE-ASSIGNMENT AND ELIGIBILITY FOR RE-USE.....................................796.8 FPL/TRACK CORRELATION.......................................................................................................806.9 FLIGHT LEVEL CO-ORDINATION.................................................................................................816.9.1 GENERAL..................................................................................................................................816.9.2 OLDI COORDINATION...............................................................................................................856.9.2.1 Co-ordination Points Definition..............................................................................................876.9.2.1.1 COP Configuration..............................................................................................................876.9.2.2 The Filter...............................................................................................................................876.9.2.3 Notification Messages............................................................................................................886.9.2.3.1 Advance Boundary Information Message (ABI)...................................................................886.9.2.3.2 Preliminary Activate Message (PAC)..................................................................................886.9.2.4 PRE-DEPARTURE CO-ORDINATION MESSAGES...........................................................896.9.2.4.1 Clearance Request Message (CRQ).....................................................................................89




6.9.2.4.2 Clearance Response Message (CRP)....................................................................................896.9.2.5 COMPLEMENTARY MESSAGES......................................................................................896.9.2.5.1 SSR Code Assignment Message (COD)...............................................................................906.9.2.6 Coordination Messages..........................................................................................................906.9.2.6.1 Activate Message (ACT).....................................................................................................906.9.2.6.2 Referred Activate Proposal (RAP).......................................................................................916.9.2.6.3 Revision Message (REV)....................................................................................................916.9.2.6.4 Referred Revision Proposal (RRV)......................................................................................916.9.2.6.5 Accept message (ACP)........................................................................................................926.9.2.6.6 Reject message (RJC)..........................................................................................................926.9.2.6.7 Coordination message (CDN)..............................................................................................926.9.2.7 Acknowledgement MessageS.................................................................................................926.9.2.7.1 Logical Acknowledgement Message (LAM)........................................................................926.9.2.7.2 Stand-by Message (SBY)....................................................................................................936.9.2.8 Transfer of communications messages....................................................................................936.9.2.8.1 Transfer Initiation Message (TIM).......................................................................................936.9.2.8.2 Supplementary Data Message (SDM)..................................................................................936.9.2.8.3 Hand-Over Proposal Message (HOP)..................................................................................936.9.2.8.4 Request on Frequency Message (ROF)................................................................................946.9.2.8.5 Change of Frequency Message (COF)..................................................................................946.9.2.8.6 Manual Assumption of Communications Message (MAS)...................................................946.9.2.9 Message for the Abrogation of Co-ordination (MAC).............................................................956.9.2.10 Ground – GROUND SITUATIONAL Awareness.................................................................956.9.2.11 Information Message (INF)..................................................................................................956.9.3 EST ORDER..............................................................................................................................956.10 SUPERVISION.............................................................................................................................976.10.1 GENERAL................................................................................................................................976.10.2 NODE ROLES SWITCH.............................................................................................................976.10.3 ACCESS RIGHTS......................................................................................................................976.10.4 LOG & BACK UP FUNCTIONALITY...........................................................................................976.10.5 LINES CONFIGURATION...........................................................................................................986.10.6 SSR SLOTS ASSIGNMENT........................................................................................................986.10.7 MANAGEMENT OF SECTOR ASSIGNMENT................................................................................986.11 INTEGRITY AND SECURITY.......................................................................................................996.11.1 SFPL DATABASE ALIGNMENT................................................................................................996.11.2 DATA INTEGRITY....................................................................................................................996.11.3 ELIGIBILITY.............................................................................................................................997. ADDED FUNCTIONS DESCRIPTION .................................................................................... 100

7.1 CONFORMANCE MONITORING FUNCTION................................................................................1007.1.1 GENERAL................................................................................................................................1007.1.2 DEVIATIONS DETECTION.........................................................................................................1007.1.3 AUTOMATIC REPORT ON FIX...................................................................................................1027.1.4 ALERT GENERATION AND TRAJECTORY RE-CALCULATION.....................................................1027.2 GAT/OAT AND IFR/VFR MULTIPLE SWITCHES......................................................................1037.2.1 ROUTE ANALYSIS....................................................................................................................1037.2.2 DISTRIBUTION.........................................................................................................................103




7.2.2.1 IFR Flight Data Distribution.................................................................................................1037.2.2.2 VFR Flight Data Distribution...............................................................................................1047.2.2.3 “Y” and “Z” Flight Data Distribution...................................................................................1057.2.3 MANUAL ORDERS AND STRIP PRINTING FOR CIVIL-MILITARY FLIGHTS....................................1057.2.4 AFP Message..........................................................................................................................106




1. SCOPE

The Local Flight Data Processing System (LFDPS) and the Flight Plan Pre-Processing System (FPPS) are dual server systems based on an open architecture which provides the processing of flight plan data and other related information to support air traffic controllers during the planning and progress phases of flights, in accordance with the referenced ICAO PANS-RAC 4444 rules. They are both supplied with two processing units in Master/Stand-by configuration, in order to ensure the continuity of service in case of single fault of the processor. The scope of the present section is to describe the functions of LFDPS and FPPS. It is arranged according to the following structure: Chapter 2 – Reference Documents, where the documents referenced in this section are listed; Chapter 3 – FDP System Context Description; where the FDP system context diagram is

introduced; Chapter 4 – Node Roles and Operational States; where the node Master/Stand-by roles and the

system operational states are outlined; Chapter 5 – System Flight Plan Reference Model, where the System Flight Plan (SFPL) and its

states are defined; Chapter 6 – Core Functions Description, where the FDPS core functions are delineated; Chapter 7 – Added Functions Description, where the FDPS added functions are delineated;

The following core functions have been introduced to represent the services provided by the FDP System:1. Environmental Data Processing

The FDP System has a database where all environment data (both geographic and aircraft performance data) are stored. This information constitutes the scenario for the progress of all the other services.

2. Message HandlingThe Message Handling function deals with the exchange of messages with units external to the system. It permits to automatically receive, store, process, extract, deliver for displaying and transmit in real-time ATS messages, MET/AIS messages, ATFM messages and notification and co-ordination messages.

3. Initial Flight Data HandlingThe Initial Flight Data Handling (IFDH) function is concerned with the creation and the early modifications of a SFPL, before it is turns to the “active” state.

4. Flight Progress Data HandlingThe Flight Progress Data Handling (FPDH) function is concerned with the modifications of SFPL’s data after its transition to the “active” state and until its termination.

5. Trajectory PredictionThe aim of the Trajectory Prediction function is to predict the full trajectory that a flight will follow within the boundaries of the Controlled Airspace. This trajectory is used to determine the list of geographic sectors to be crossed and to detect the events associated to the SFPL life cycle.

6. DistributionThe Distribution function is concerned with the delivery of the SFPL data to appropriate AWP operators and to the other defined receivers (CWPs, etc.) due to the occurrence of significant events.




7. SSR Codes Management and AssignmentThe purpose of the SSR Codes Management and Assignment function is to handle SSR codes in accordance with ICAO Originating Region Code Assignment Method (ORCAM).

8. SFPL/Track CorrelationThe objective of the SFPL/Track Correlation function is to logically associate surveillance data representing a track with a SFPL.

9. Co-ordinationThe Co-ordination function allows ground-ground co-ordination by the implementation of an OLDI (On Line Data Interchange) facility between ATS units.

10. SupervisionThe operations relevant to the configuration and to the assignment of the access rights to the operators are handled by the technical supervisor by means of the FDP Supervision service.

11. Integrity and SecurityThe database correctness and the eligibility of the sources accessing the FDP System are always granted by the Integrity and Security service.

Furthermore, the following added function is introduced to complete the set of services provided by the FDPS:12. Conformance Monitoring Function

The FDPS performs the Conformance Monitoring Function, in order to provide other FDP functions and operators with information regarding whether the actual progress of flights matches the expected.

13. IFR/VFR and GAT/OAT multiple switchesThe FDPS performs the route extraction and distribution taking into account the IFR/VFR and GAT/OAT switches contained in the SFPL Field 15; furthermore FDPS sends AFP message according to predefined rules relevant to multiple switches.

14. MULTITREADHINGThe FDP capacity is improved using the multithreading software architecture.




2. REFERENCE DOCUMENTS

1. ICAO RAC - Rules of the Air and Air Traffic Services. (Doc 4444)13th edition, 1996;

2. Operational Requirements for Flight Data and Distribution Core Functions (Area Control)Edition Draft 3.4OPR-ET1.ST03.1000-ORD-01-00Working Draft - October 1996

3. Eurocontrol Standard for On-Line Data Interchange (OLDI)Edition 2.3DPS.ET1.ST06-STD-02-00Released Issue - December 2000

4. Eurocontrol Standard Document for Flight Data ExchangeInterface Control DocumentPart 1: Point-to-Point and Limited Networking CircuitsCOM.ET1.ST12.DEL-XX-01Proposed Issue: April 30th, 1997

5. Eurocontrol Standard Document for ATS Data Exchange Presentation (ADEXP)Edition 2.0DPS-ET1-ST09-STD-01-01Released Issue: June, 1998

6. Eurocontrol Guide to ATFM message ExchangeEdition 6.0DPS-ET1-ST09-STD-01-01March, 1998

7. Eurocontrol Operational Requirements for EATCHIP Phase III ATM Added FunctionsVolume 1 – Monitoring AidsOP1.ET1.ST04.DEL01.02.1Released Issue: May 14th, 1999

8. ROMATSA-Operational Requirements for Flight Plan Pre-Processing System (FPPS)- Edition 2.0- 27/11/98

9. ROMATSA -Modernization project of Romanian ATM system- ROM.OPR.PROJ.ATM-Edition2.0- 27/11/98.

10. ROMATSA-AMS- Minute of Meeting (MoM-TM02) -Roma 4th October 2000 – 6th October 2000.




11. ROMATSA- AMS- Minute of Meeting (MoM-TM03)- Roma 27th November – 6th December 2000.

12. ROMATSA- AMS- Minute of Meeting – CWP, FDP and FPPS UM and SAT doc- Bucharest 13rd-15th December 2001.

13. ROMATSA- AMS- Minute of Meeting - After SAT on CWP, LFDP, FPPS installed in Bucharest, Arad and Constanta - Bucharest 28th February 2002.

14. ROMATSA- AMS- Minute of Meeting – Phase 1 residual requirements clarification - Bucharest 12 th

July 2002.

15. ROMATSA- AMS- Minute of Meeting - After SAT on CWP, LFDP, FPPS installed in Bucharest, Arad and Constanta - Bucharest 9th August 2002.

16. Minute of Meeting – 18 September 2002 Held in Bucharest to clarify the open points relevant to Minute of Meeting – 9 August 2002 After Site Acceptance Tests performed on LFDP, FPPS, CWP Installed in Bucharest, Arad and Constanta.

17. AMS- Interface Control Document for FPPS ROMATSA Gateway Interfacing-E184-01-2064ICD_B – 21/10/02.

18. AMS- Interface Control Document for FPPS/AFTN Interfacing-E184-01-2063ICD_B – 21/10/02.

19. AMS- Interface Control Document for LFDPS/AFTN Interfacing-E184-01-2065ICD_B – 21/10/02.

20. AMS- Interface Control Document for LFDPS/OLDI Interfacing-E184-01-2067ICD_A – 11/10/02.

21. SELEX-SI – E184-01-3029SSS_D – 29/09/05.

22. CFMU Flight Progress Messages ed.1.1 – 31/10/2003.

23. IFPS and RPL dictionary of messages ed. 1.5 Oct. 2004.

24. CFMU 9 Release Notes ed.2




3. FDP SYSTEM CONTEXT DESCRIPTION

Table 3-1,3-2 and Figure 3-1 and 3-2 summarise the LFDPS and FPPS operational context, describing the information exchanged with the other ATC sub-systems, the aeronautical authorities and with the adjacent ATCUs.

The FDP architecture to be realised for the Romanian ATM Modernisation Project is mainly composed of a centralised Flight Data Pre-processing System (FPPS) located in Bucharest and three clustered “local” FDPs (LFDPs) to be implemented respectively in Bucharest, Arad and Constanta ATCUs. In accordance with a national FDP philosophy, the LFDPs are connected with the FPPS via a TCP/IP based Romanian FDP Network by which the bi-directional FPPS-LFDPs data flow is supported.

The FPPS is responsible for receiving, storing, processing, displaying, archiving all the RPLs (manually input or via magnetic supports) and the ATS messages (transmitted via AFTN) relevant to the Romanian ATCUs. Before inserting the received ATS messages into the flight plan data base, semantic and syntactic checks according to ICAO PANS -RAC 4444 rules are performed by the FPPS. In particular, if the checked message is correct, it will be automatically stored, pre-processed and finally delivered to the concerned LFDPs. Otherwise, it is queued in a proper “incorrect ATS message queue” in order to be manually corrected by dedicated operators before distributing. The same validation procedure is strictly carried out on the route data fields, checking if the established airway direction constraints are definitely respected.

By analysing route data contained in both RPLs and received ATS messages, the FPPS is able to compute route extraction/trajectory prediction and consequently to recognize all the ATCUs interested by the pre-processed SFPL distribution which is realized a VSP time either before EOBT (departing flight) or ETI (inbound flight). In case of already distributed SFPL, if proper updates are received, the FPPS is responsible for the SFPL re-distribution to the concerned ATCUs. In particular, when FPPS receives an ATS message referring to an existing SFPL, it shall select the relevant SFPL from the data base using the fields: Departure Aerodrome, Destination Aerodrome, Flight Identification and, for FPL type, Flight Date and Time. If this selection results in more than one SFPL, the received ATS message shall be inserted into the wrong ATS message queue to be then validated.

Even though the main way of operating foresees the only FFPS to manage ATS messages, the LFDPs are allowed to create short flight plans (e.g. in case of FPPS failure) which have to be manually validated by the FPPS operators before final insertion.

The MET/AIS messages are received by both FPPS and LFDPSs through a serial asynchronous AFTN line. LFDPs are also responsible for ATFM messages management.

Each LFDPS server is configured to receive and manage a serial asynchronous (9600 b/s) AWOS line coming from ROMATSA local meteorological system in order to extract the QNH value. However, this capability will not be used in the QNH handling implemented for the Certification Phase.




Inter-ATCUs coordination is completely under LFDPs responsibility, carried out according to the standard OLDI rules. All the external and internall OLDI links (with foreign FIRs and Romanian FIRs respectively) are supported by X.25 and TCP/IP lines (based on standards FDE part 1 and part-2, FMTP) selecting the corresponding transmission protocol to use, depending on the communication modality adopted. ABI, ACT, RAP, RRV, CDN, ACP, RJC, REV, MAC, PAC, OLDI messages, TKF and EST orders handled by LFDPs generate OLDI INF messages to be transmitted to FPPS first and then to the ROMATSA Gateway sub-system upon a dedicated request. ROMATSA Gateway shall send the received OLDI INF message to Military Authority for confirmation. This confirmation is represented by an AFTN type EST message to FPPS that shall communicate to the interested LFDPSs the SFPL Military approval.

The FPPS is provided with a wrong OLDI messages queue where OLDI messages with inconsistencies received from LFDPSs will be stored and managed by eligible operators.

The LFDPs are in charge of the flight plan progressing and therefore of the SFPL status management. As soon as the terminated status is reached, the terminated SFPL is sent to FPPS and from FPPS to ROMATSA Gateway which is responsible for the terminated flight plan distribution to the statistics and billing system.




TABLE 3-1 - FPPS GENERAL CONTEXT DIAGRAM.

System DATA

METEO/AIS Units In: MET/AIS messages exchanged via AFTN.

ATS Units In-Out: ATS messages, free text messages.

CFMU/IFPS In-Out: ATS messagesLFDP In: Short flight plans, terminated flight plans, OLDI INF messages, locally

inserted flight plans.

Out: Validated and Pre-processed SFPLs, validated OLDI messages, updated SFPLs.

ROMATSA GWY In: Request for single flight, request for multiple flights, request for multiple OLDI, request for re-transmission.

Out: terminated flight plans, OLDI INF messages, active FPLs.FPPS Technical Supervisor

In-Out: configuration data

FPPS positions In: environmental data, aircraft performance, corrected and validated pre-processed SFPLs, meteo data management, orders.

Out: incorrect ATS messages, short flight plans from LFDPs, warnings, archived data.

In/Out: configuration data, FPLs management.




TABLE 3-2 - LFDPS GENERAL CONTEXT DIAGRAM.

System DATA

FPPS Out: Short flight plans, terminated flight plans, OLDI INF messages, locally inserted flight plans.

In: Validated and Pre-processed SFPLs, validated OLDI messages, updated SFPLs.

METEO/AIS Units In: MET/AIS messages exchanged via AFTN.Romanian Local meteo system

In: QNH Information.Out: QNH correction, Transition Level.

CFMU/IFPS In-Out: ATS messagesCFMU/TACT In-Out: ATFM messagesForeign ATS Units In-Out: Notification and Co-ordination messages according to Eurocontrol

Standard for OLDI (X.25 connection and FMTP TCP/IP connection).Romanian ATS Units

In-Out: Notification and Co-ordination messages according to Eurocontrol Standard for OLDI (FMTP TCP/IP connection).

Radar Data Processing System

In: Information about aircraft position (system radar tracks).

Safety Nets Out: FPL data.CWP In: SFPL data, PLN/EXE orders, co-ordination data.

Out: SFPL data, co-ordination data, environmental data, ATC sectors frequencies management, warnings.

CMS In: Supervisor OrdersOut: Diagnostics

LFDP Technical Supervisor

In-Out: Configuration data

FDE Position In: environmental data, aircraft performance, orders, meteo data managementOut: archived data, warningsIn/Out: configuration data, FPLs management, coordination management




FIG. 3-1 - GENERAL FPPS CONTEXT DIAGRAM.




FIG. 3-2 - GENERAL LFDP CONTEXT DIAGRAM.




4. NODE ROLES AND OPERATIONAL STATES

4.1 NODE ROLES

Both the FPPS and the LFDPS are provided in a redundant (master / stand-by) configuration. Each server (in the following indicated as “node”) can assume one of the following roles: Master

The node assumes this role when it is properly running supporting the master properties and the partner node is available.

Stand-byThe node assumes this role when it is properly running but the partner node is in charge of the master properties.

Master_AloneThe node assumes this role when it is properly running and the partner node is unavailable.

Each time a node assumes the Master role, it is possible to force from the Technical Supervisor the LFDPS and FPPS functions either in the “Idle” operational state or in the “Operative” operational state, by, as described in paragraph 4.2.

Transition from Master to Stand-byThe Master node automatically switches from Master to Stand-by role, in case it does not respond to a control routine (automatically performed by NSV CSCI).LFDPS and FPPS allow to manually force the node role transition from Master to Stand-by issuing the node role switch order from the Technical Supervisor Console.In addition, the LFDPS allows to force the node role transition from Master to Stand-by issuing the node role switch order from the CMS.

Transition from Master to Master_AloneThe Master node automatically switches from Master to Master_Alone upon the unavailability of the partner node.LFDPS and FPPS allow to manually force the node role transition from Master to Master_Alone only after the switching off of the Stand-by node.

Transition from Stand-by to MasterLFDPS and FPPS allow to manually force the node role transition from Stand-by to Master issuing the node role switch order from the Technical Supervisor Console.In addition, the LFDPS allows to force the node role transition from Stand-by to Master issuing the node role switch order from the CMS..

Transition from Stand-by to Master_AloneThe Stand-by node automatically switches from Stand-by to Master_Alone upon the unavailability of the partner node with the role of Master.LFDPS and FPPS allow to manually force the node role transition from Stand-by to Master_Alone only after the switching off of the partner node with the role of Master.




Transition from Master_Alone to MasterThe Master node automatically switches from Master_Alone to Master upon the availability of the partner node (if it was not formerly available), which assumes the Stand-by role.LFDPS and FPPS do not allow to manually force the node role transition from Master_Alone to Master.

Transition from Master_Alone to Stand-byLFDPS and FPPS do not allow the Master_Alone to Stand-by role switching.

The role switching neither affects the operations nor compromise the data integrity.Furthermore, the role switch does not change the operational state, i.e. if the Master node is “Operative” when the conditions for the node switch occur, the formerly Stand-by node will assume the Master_Alone role and, still, the “Operative” state.

4.2 OPERATIONAL STATES

When either the Master or the Master_Alone role is taken by one of the nodes the LFDPS/FPPS is composed of, one of the following operational states can be gained:

Idle Wake-Up Operative

The operational states are associated to the whole system. Thus, if both the nodes are available, the Master assumes one of the above states. The same state will be assumed by the Stand-by partner (that becomes Master after the node switch) when a transition occurs. One of the listed states is assumed also by the Master_Alone if the other node is not available.The operational states that can be assumed by the nodes of the system are summarised in the following table, where the term “Not Available” is used for both the “Fault” and the “Off” node:

LFDPS/FPPS Node A

LFDPS/FPPS Node B

Idle Not Available Wake up Not AvailableOperative Not AvailableIdle IdleWake up Wake upOperative OperativeNot Available IdleNot Available Wake upNot Available Operative




The operational states transition model is described in figure 4.2–1 where an additional block is indicated to explicitly show the fault condition which is not to be confused with an operational state. The first operational state reached when the Master or the Master_Alone node becomes available (i.e. at Power On of both nodes or of only one node if the partner is not available) is the one get by the system before the previous Power Off, since the LFDPS/FPPS retains (in its memory) the last operational state. It can be either “Idle” or “Operative” since the “Wake up” state is a transition state assumed by the system when it turns from “Idle” to “Operative”.

FIG. 4.2-1- LFDPS/FPPS OPERATIONAL STATES.IdleThe Idle state can be defined as the operational state where the configuration of the FPPS and LFDPS can be performed. When the Idle state is assumed by the system, the functions provided with the above purpose are enabled. On the other hand, a subset of the complete collection of the provided functions is disabled.

This includes for the FPPS:

RPLs wake up; SFPL and related data distribution; reception of information from external systems (e.g. ATS messages, LFDP manually inserted FPLs

etc.)




For the LFDP:

Flight progress functions availability except SFPL / System Track Correlation which is available both in the “Idle” and in the “Operative” state and Set Up of SSR Codes which is available only in the “Idle” state;

reception of information from external systems (e.g. MET/AIS messages, ATFM messages OLDI messages)

In the following, the available actions are described for each “class” of the positions that interact with the FPPS and LFDPS.

From the FPPS and LFDPS Technical Supervisor Consoles the configuration of the system can be performed by means of the following operations:

management of the access rights (FPPS and LFDPS Technical Supervisor Consoles) management of the Variable System Parameters (VSPs) (FPPS and LFDPS Technical Supervisor

Consoles); set up of all the external connections (window sizes, protocol, serial port, port configuration, etc.)

(FPPS and LFDPS Technical Supervisor Consoles); set up of the pool of SSR codes (LFDPS Technical Supervisor Console).

Furthermore it is possible from the FPPS and from the LFDPS Technical Supervisor Consoles to trigger the state transition to “Operative”.

On the FDEs the following capabilities (if available for the profile connected to the FPPS and to the LFDPS with its own access rights) are disabled: Inactive SFPL management (FPPS and LFDPS AWPs); SFPL progress management (LFDPS AWPs) RPL management (FPPS and LFDPS AWPs).

The remaining actions can be performed according to the different operator access rights.In the “Idle” state, the FPPS and LFDPS FDEs are also allowed to perform environment data management if a suitable profile owning the requested access rights has been created.

On the CWPs, even if it is not addressed by the LFDPS, the following operations are available for ATC purposes:

Radar presentation (full availability); Flight Plan Handling (insertion, deletion, updating of "reduced" flight plans, where "reduced" means

without Route Analysis and Trajectory Determination). The update process with the inserted data will be performed in the “Wake up” state at the system transition from “Idle” to “Operative”;

SSR assignment/releasing (manual); Flight Plan/Radar tracks correlation (full availability); Lists Handling (full availability, excluding the lists that need trajectory data to be present).




Wake UpWake Up state is a transitory state, which LFDPS and FPPS must pass through, to transit from Idle to Operative.In this state LFDPS starts all its time events and re-aligns its databases with the system distributed database (managed by XCD – the CSCI dedicated to the Common Database management).For the databases alignment, the following actions take place:

1. LFDPS asks ACD to send the configuration as well as all the existing flight plans (if any) which have been inserted or updated when it was “Idle” or “Not Available”.

2. ACD replies to the LFDPS alignment request by sending the configuration messages, all the flight plans contained in its data base and the dialogue start data. In this way the following information are provided:a. the association between the logical suites that have been foreseen in the system and the physical

displays on which they are allocated. With this message, LFDPS becomes aware of the general distribution of the control sectors on the physical displays.

b. for each display that is configured in the system, the allocated logical suite, when it is operative, or the logical suite that has absorbed it. In this way, the LFDPS is made aware of the sectorisation that is actually adopted in the system. The LFDPS uses this information for data distribution to the CWPs.

c. the flight plans that are memorised in the distributed database managed by ACD, if any. The LFDPS performs a process to “validate” the received data thus assuring congruence in the shared data.

d. information about the selected LAN from which the LFDPS must take the radar data, and the DARD/MRT working modality.

3. Once ACD has finished the alignment, the LFDPS sends messages to complete the databases alignment and the configuration messages for the management of the flight plans to the ACD. These messages contain the information about the used environment data.

Furthermore, in this state the alignment between the LFDPS and the FPPS databases is performed.

Operative The Operative State is the state in which the LFDPS and FPPS offer the full service to planning and executive controllers.The system normally remains in this state, exception made for those periods in which the LFDPS/FPPS needs to be configured..

In the “Operative state”, from the LFDPS/FPPS Technical Supervisor Console the configuration of the system cannot be performed but it is possible to trigger the state transition to “Idle”.On the LFDP/FPPS FDEs all the actions can be performed according to the different operator access rights, apart from geographical sectors definition (if a suitable profile owning the requested access rights has been created) which can be performed only in the “Idle” state.On the CWPs, the complete set of operation related to the LFDPS/FPPS are now available. When LFDPS/FPPS is in operative mode it is possible to change all the environment parameters and data and apply all of them on line by means of a dedicated button in FDE status bar: the button is called “reload geography” and it is available under proper access rights when some change in geography has been performed from that FDE position. Once the modification is applied the button becomes again unsensitive.




Operational states transitionsIt is allowed to manually change the operational state from Idle to Operative and vice versa from the LFDPS/FPPS Technical Supervisor Console.The Wake-up state cannot be get manually, but only upon the transition from Idle to Operative when the LFDP system re-aligns its databases with the system distributed databases managed by the ACD CSCI.




5. SYSTEM FLIGHT PLAN REFERENCE MODEL

The system flight plan model described in this chapter is applicable both to the Local FDP System (LFDPS) and to the Flight Data Pre-Processing System (FPPS). The differences between the LFDPS Flight Plan Model and the FPPS one are described below.

5.1 SYSTEM FLIGHT PLAN DEFINITION

The System Flight Plan (SFPL) is the internal representation of the flight plan which supports the real time control of the flight and stores the flight intentions of an aircraft during its flight progress.The information contained in the FPL are listed in the following Table 5.1-1.A SFPL is univocally defined within the LFDPS/FPPS by means of the following fields: Flight Identification; Departure Aerodrome; Destination Aerodrome; Estimated Off Block Time; Date of Flight; Entry Point (only considered within the FPPS).

Each operation performed by the LDPS as a result of an event (automatic or manual) and relevant to the SFPL is reflected in the content of one or more of the listed items.




TABLE 5.1-1 – SFPL CONTENT (1 of 3).

SFPL DATA ITEM DESCRIPTION

Callsign Flight Identifier

Flight rules and type The rules under which the flight will proceed (IFR , VFR or mixed) and type of flight (Scheduled Air Service, Non Scheduled Air Transport Operation, General Aviation, Military and Other).

Number of aircraft The number of aircraft making up the flight (usually 1).

Type of aircraft The aircraft type

WTC Wake Turbulence Category associated to the aircraft type

Departure Aerodrome The airport from which the flight is departing

EOBT Estimated Off Block Time

Equipment Radio communication, navigation and approach aid equipment.

Cruise Speed The speed at which the flight will proceed when at cruising altitude.

Requested Flight Level The flight level the flight wishes to cruise at.






Route The route of flight between the departure and destination aerodromes.

Destination Aerodrome The airport of first intended landing.

Estimated Elapsed Time Estimated flight time from take-off to landing

Alternate Airport(s) The airport to which the flight may divert.

Other Information Defined according to the rules exposed for the FPL field 18 in ICAO PANS –RAC 4444.

Remarks Plain language indicating any useful remarks.

Date of Flight The date the flight is expected to depart.

SSR Code The SSR code that has been assigned to the flight.

Aircraft Performance Data The rates of climb, descent and other aircraft type related data.

Taxi Time The default value for Taxi Time

SFPL route The extracted route the flight is expected to fly within the considered FIR. It is expressed as a sequence of 2D points calculated from the original FPL route. Details for this item are given in paragraph 6.5

Expected Trajectory The set of 4 dimensional points that describe the expected profile of the flight. Details for this item are given in paragraph 6.5






Crossed Sector List A list of the sectors expected to be crossed by the flight.

Parking Bay (PKB) The expected parking bay for the arriving flights.

SFPL state The current state of the SFPL.

Flight Category The category of flight, i.e. Inbound, Outbound, Overfly, Domestic and Local.

System Track The system number of the correlated radar track. It allows the acquisition of the actual position of the flight.

Co-ordination State The state of Co-ordination after the transmission/reception of OLDI messages (e.g. ACT transmitted – LAM received)

Additional Information Additional data such as: Fuel Endurance Persons on Board Emergency Radio Survival Equipment Jackets and Dinghies Aircraft colour and markings Pilot in command




5.2 SYSTEM FLIGHT PLAN STATES MODEL

During its life-cycle, the system flight plan goes through a number of states, each of which has its own characteristics.

The states managed by the FPPS are: Inactive, Ready to be sent, Sent and Terminated (ref. to 5.2.15.2.3).

The states managed by the LFDPS are Inactive, Pending, Active, Live and Terminated.

The description of the transitions from Inactive to Terminated states managed by the LFDPS is given in table 5.2-1. The “flight state transitions”, illustrated in Figure 5.2-1 by means of a states transition diagram, are summarised in the following. Figures 5.2-2 and 5.2-3 give a further explanation of the SFPL states by means of a typical state evolution diagram related to a time axis and of a summary diagram of the control actions performed in each state. The description provided in the present paragraph can be applied to all SFPLs relevant to IFR flights. Details relevant to VFR flights are given in a separated paragraph.

5.2.1 INACTIVE-READY-TO-BE-SENT TRANSITION

The Inactive / Ready to be Sent transition is performed by FPPS a “pre-activation” time (VSP1) before EOBT (departing flights) or ETI (inbound flights).

5.2.2 READY-TO-BE-SENT-SENT TRANSITION

The Ready to be Sent/Sent transition is performed by FPPS a VSP2 time before EOBT (departing flights) or ETI (inbound flights).

5.2.3 TERMINATED STATUS FOR FPPS

When a “locally” (i.e.by a LFDP) terminated SFPL is received by FPPS, the FPPS shall archive the SFPL collecting the trajectory data section with any other local terminated SFPL not yet “FPPS Terminated” having the same Flight Identification. In case of re-routing of FPPS original flight plan, the “primary key” (Flight Identification, Departure Aerodrome, EOBT, Destination Aerodrome, Flight Date) shall be updated with the data of the last local flight plan.

After “archiving”, the FPPS shall attempt to terminate the SFPL checking whether the last reported point belongs to the last flown ATCU (boundary point or a runway threshold). In case a flight is re-routed (see above explained cases) by one or more ATCU, the termination shall be performed VSP time after the computed termination time.

Any “FPPS terminated” flight plans shall be transmitted to ROMATSA Gateway.

The FPPS shall envisage a periodic process to detect the SFPL termination. The above process shall terminate the locally terminated SFPL a VSP time after the termination time.




5.2.4 INACTIVE – PENDING TRANSITION

For inbound flights (i.e. overflights and arrivals), the “inactive” to “pending” transition is performed as soon as an ABI or PAC message is received.For departing flights (i.e.outbound flights, domestic and local departures) the “inactive” to “pending” transition is manually performed from the FDE positions (associated to the TMA/TWR sector(s) managing the flight) by using the Wake-up Departing order.

5.2.5 PENDING – ACTIVE TRANSITION

For inbound flights (i.e. overflights and arrivals), the “pending” to “active” transition is performed as soon as an ACT message is received. If the OLDI connection is not available, the above mentioned transition is forced by the EST order reception.For departing flights, the “pending” to “active” transition is manually performed by means of either the DCL or the DCR order.For departing flights, if the aircraft associated to the FPL does not take-off within a time slot (VSP) centered on the ETD, the FPL status shall be switched back to “pending”.For departing flights, if the clearance order is not performed within [ETD, ETD-T’], where T’ is the Pre-Activation time, the FPL status is automatically switched to “active”.

5.2.6 INACTIVE-ACTIVE TRANSITION

The “inactive” to “active” transition is foreseen only for inbound flights, according to the “pending” to “active” transition rules.

5.2.7 SFPL STATE TRANSITION FROM ACTIVE TO LIVE

The LFDPS changes the state of the SFPL from ACTIVE to LIVE in one of the following cases: Automatic report on the first internal fix (inbound-overfly flights) or after Take Off detection (local-

domestic-outbound flights) when correlation between SFPL/System Track exists. Manual input of a position report on the first internal fix (inbound-overfly flights) or of a Take Off

report (local-domestic-outbound flights).

5.2.8 SFPL STATE TRANSITION FROM LIVE TO TERMINED

The LFDPS changes the state of the FPL from LIVE to TERMINATED in one of the following cases: manual input of:

Termination order;Report on the last point of interest internal to the controlled airspace;Manual Landing report;




system based events, i.e.:Automatic report on the last point of interest internal to the controlled airspace (flight leaving the

Area of Responsibility);Automatic landing report;When the RDP has been unable to provide data after a variable system parameter time later than the

estimated exit time for the corresponding SFPL.

The SFPL is archived a variable system parameter time after termination.

5.2.9 UNDO ORDERS

It is possible to perform undo orders from each state to a previous one in accordacen with the following:

From pending to inactive From active to pending From Live to pending From terminated to live

Furthermore active departing flights are turned automatically to pending if within a VSP time no take off is performed.

It is possible also to perform order on live SFPL in order to inhibit the automatic termination. Also the inhibition of automatic termination can be removed by means of a dedicated manual order.

5.2.10 SFPL STORAGE

It is possible to perform SFPL manual storage in INACTIVE, PENDING, ACTIVE or LIVE state according to at least the following criteria:

access rights

The SFPL is archived in a suitable storage table, where the SFPL state at termination is also registered.

5.2.11 VFR FLIGHTS HANDLING

SFPLs relevant to VFR flights never assume the state of Pending, i.e. LFDPS assigns them only the following states:

Inactive Active Live Terminated

VFR flights are scheduled as stated below:




VFR flights is always inserted as Inactive LFDPS automatically assigns them the Active state a variable system parameter time before the

EOBT (inbound-overfly flights) or the ETI (local-domestic-outbound flights). LFDPs assigns them the Live state, after the issuance of a take off report (manual or automatic) or of

a manual inbound report according to the flight category.

According to the flight category, LFDPS automatically assigns them the Terminated state, upon the loss of the radar track by the RDP system, after a variable system parameter time, without any manual operation for the operator, if correlated, or, for non correlated flights, after the issuance of a manual landing report or an outbound report.




TABLE 5.2-1 – SFPL States within the LFDPS.

SFPL State State Description

INACTIVE When the SFPL is transmitted from the FPPS to the LFDPS it assumes the INACTIVE state.In this state, the flight has been assumed of future interest for the ATC Centre.

PENDING The flight is becoming of interest for the ATC Centre. It is planned to enter the controlled airspace (inbound-overfly flights) or it is planned to take off (local-domestic-outbound flights).

ACTIVE The flight is currently active in the air, the inbound conditions have been defined but it is not yet flying in the controlled airspace (inbound-overfly flights), or it is on the ground and the departure clearance has been issued (local-domestic-outbound flights).

LIVE The flight has been automatic or manually reported on the first reporting fix for the ATC Centre.

TERMINATED The flight has automatically or manually reported on the last point of interest for the ATC Centre.




6. CORE FUNCTIONS DESCRIPTION

6.1 ENVIRONMENTAL DATA PROCESSING

6.1.1 GENERAL

The Environmental Data Processing functions is concerned with the LFDPS and FPPS database where all environment data are stored and from which they can be retrieved.

The environment data are basically divided in two groups:

Static Data; Dynamic Data.

The first group consists of a set of predefined data used by functions to define their manner of operation. Examples of static data include data regarding the airspace structure definition. Static Data also includes system configuration parameters, those which configure the architecture of the system.The second group consists of a set of non-predefined data, the values of which change more or less continuously. Examples of dynamic data include weather data.When the LFDPS/FPPS is in Idle state, it is allowed to set-up the static environmental data, which include: the geographical information, i.e. aerodromes, Fixes, Airways, and other geographical elements

(managed by the FPPS and LFPDS) the pool of available SSR codes (managed by the LFDPS) the types of aircraft, with the definition of their performances (managed by the FPPS and LFPDS).




6.1.2 STATIC DATA

6.1.2.1 Airspace Data Handling

LFDPS/FPPS provides the capability to define airspace elements including : ATS routes (including airways, transition routes, SIDs, STARs); Significant points (navigational facilities, intersections and other point); Aerodromes; Boundary of the Area Of Responsibility (AoR).

Area of ResponsibilityIt will be allowed to eligible operators (FPPS/LFDPS) to define the AoR’s controlled airspace. It is composed of: a set of geographical items (e.g. Fixes, ATS routes or aerodromes); an airspace volume expressed as a composition of sectors, extended within a defined altitude band,

being FL656 the maximum FL managed by the system.

Area of InterestThe Area of Interest (AoI) is the airspace volume for which the ATS Unit shall have information such as: entering flights, airspace status, etc. This area includes the AoR and its vicinity.




Both the AoI and the AoR shall be identified

The AoI must be larger or equal to the AoR; and as a limit condition, the AoI could collapse to the AoR;

Overlapping sectors can be allowed within the AoI;

1. For flights proceeding via a direct route segment between two points internal to the AoR, sectors boundary crossing point is calculated.

2. For flights proceeding via a direct route segment from a point internal to the AoR to a point external to the AoR or vice versa, the AoR boundary crossing point is calculated.

3. For flights proceeding via a direct route segment from a point internal to the AoR to a point external to the AoR the system is able to discern the receiving ATS unit in order to transmit OLDI messages for these flights to the correct destination.

4. For all the flights crossing the AoR, flight data is distributed to all the involved sectors (i.e. all sectors crossed by the flight path).

5. Flights crossing only AoI sectors are allowed.

FixesEligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the Fixes, i.e. geographic relevant points generally but not necessarily associated to a radio assistance. Before inserting and storing a Fix, the operator shall provide the following information: ICAO Fix code short Fix code (optional) co-ordinates, in Latitude and Longitude Description (optional) Fix type, i.e. the type of the provided assistance (e.g. DME, NDB, TACAN, VOR, SYSTEM…) “is boundary” flag (Yes/No) Adjacent FIR ICAO code, if the Fix belongs to the boundary (optional) Level constraints

Within the Fixes database the operator can also store “System points”, i.e. points having the Fix type set to “system”, and available for the definition of SIDs and STARs.

Co-ordination PointsEligible LFDPS operators are enabled to manage information about the Co-ordination Points (COPs) to be used in the Co-ordination function for OLDI messages exchange (ref. to paragraph 6.9 for details).

SectorsThe AoR and AoI can be divided into several sectors defined as a union of zones, each of them is defined by specifying the vertexes of its base, its lower and its upper level. Eligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print Sectors data.




Moreover, the LFDPS provides the capability to foresee a proper data base containing all the frequencies associated to the ATC sectors the system is composed of. The frequencies data base stores the different system configurations. Depending on the configuration, it shall be possible to assign each sector a main and a spare frequency to be used in case of failure. The LFDPS has the capability of modifying and updating the frequencies data base.At the start up phase, the LFDPS shall deliver to the interested CWPs the frequencies data base. From the FDE position it shall be possible both to update the operating frequency of each ATC sector and notify the interested CWPs of frequency switching.

AerodromesEligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the following aerodrome information: Aerodrome code (ICAO location indicator) co-ordinates, in Latitude and Longitude of the point chosen as airport reference point Description (optional) Type (i.e. for LFDP:“Internal “ for aerodrome inside the FIR managed by the LFDP, “External” for

aerodrome outside the three Romanian FIRs and consequently outside Romanian national boundaries, “National” for aerodrome external to the FIR managed by the LFDP but located into one of the two remaining Romanian FIRs. For FPPS: “Internal “ and “National” for aerodrome inside the defined FPPS AoR and consequently internal to the Romanian boundaries, “External” for aerodrome outside the defined FPPS AoR and consequently external to the Romanian boundaries).

Departure Automation Level (e.g. SID provided, Tower provided) Arrival Automation Level (e.g. STAR provided, Tower provided) AoI if the Aerodrome belongs to AoI: in this cas also runway can be defined




RVSM ZonesEligible LFDPS operators are enabled to insert, update, delete and print the RVSM Zone data (i.e. Zone Id, Min Level, Max Level).

RunwaysEligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the following aerodrome’s runways information: Runway code (3 alphanumeric chars: the first two characters on the left must be digits, the third

character must be L, R or space) ICAO Location Indicator of the aerodrome which the Runway refers to Runway Fix (it is the RWY reference point used in the trajectory prediction algorithm to evaluate the

estimated time of arrival) Runway elevation usage (for departure or for landing) Taxi time Description (optional) Status (opened or closed) “is default” flag (default or not default, in case there are more than one runways)

AirwaysEligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the Airways, i.e. the following information relevant to ATS routes:

Airway code list of Fixes defining the airway level constraints

Defining the airway the operator is requested to specify the fixes sequence order along the ATS route. The sequence order used to define the airway is said forward, while the reverse, backward.

Both the LFDPS and the FPPS are in charge of the airway direction constraints (configurable according to the specific airway segment defined in the system) management..

LFDPS/FPPS is able to use the ATS route in both the directions (forward and backward).

SIDsEligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the following information relevant to the aerodrome’s SIDs: SID code list of Fixes defining the SID and, for each of these, the Minimum and maximum Crossing Level

STARsEligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the following information relevant to the aerodrome’s STARs:

STAR code list of Fixes defining the STAR and, for each of these, the Minimum and maximum Crossing Level




ICPs (initial climb path)Eligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the following information relevant to the aerodrome’s ICPs:

ICP code list of Fixes defining the ICP and, for each of these, the Minimum and maximum Crossing Level

FAPs (Final approach path)Eligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the following information relevant to the aerodrome’s FAPs:

FAP code list of Fixes defining the FAP and, for each of these, the Minimum and maximum Crossing Level

Junctions between aerodromes and airwaysEligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print information relevant to the junctions between aerodromes and airways.

The type of junction depends on the automation level of the aerodrome. and it is possible to define the following type of junctions: junctions between SID provided aerodromes and SIDs junctions between STAR provided aerodromes and STARs junctions between SID-less aerodromes and airways, describing not automated departing procedures junctions between STAR-less aerodromes and airways, describing not automated arrival procedures

Junctions between SID provided aerodromes and SIDsWhile storing a junction between a SID provided aerodrome and a SID, the following information is provided: joint SID code joint ATS route code Runway code which the SID refers to ICAO Location Indicator of the aerodrome which the Runway refers to

Junctions between STAR provided aerodromes and STARsWhile storing a junction between a STAR provided aerodrome and a STAR, the following information is provided: joint STAR code joint ATS route code Runway code which the SID refers to ICAO Location Indicator of the aerodrome which the Runway refers to

Junctions between SID-less aerodromes and airwaysWhile storing a junctions between a SID-less aerodrome and an airway, the following information is provided: ICAO Location Indicator of the joint aerodrome joint ATS route code ATS route’s joining Fixes, to enter the ATS in both the directions (forward/backward) while departing

from the aerodrome




Junctions between STAR-less aerodromes and airwaysWhile storing a junctions between a STAR-less aerodrome and an airway, the following information is provided: ICAO Location Indicator of the joint aerodrome joint ATS route code ATS route’s joining Fixes, to leave the ATS while arriving to the aerodrome from both the directions

(forward/backward)




Geographical Sectors ChangesDepending on current or expected traffic, sectors may be suitably combined. The following will require updating for affected flights: The list of sectors. The co-ordination process. Data distribution to sectors.

Modification of the allocation of airspace to sectors triggers re-calculation of the lists of sectors and SFPL data is distributed according to the new lists.Also the co-ordination functions will arrange their operations according to the new sector configuration.

6.1.2.2 Aircraft Data

In order to predict the future trajectory of a flight with sufficient accuracy and, consequently, to calculate the different times of the flight events (co-ordination, flight state changes, etc.), the system is provided with the aircraft performance data, stored in a dedicated library catalogued according to “classes” and “types”. The operator is requested to create, at first, a library with the aircraft classes. Then he is requested to define the aircraft performances, each of which referring to an existing aircraft class.

Aircraft ClassesEligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print Aircraft Classes. While storing an Aircraft Class at least the following information is provided: Aircraft Class code Wake Turbulence Category (Light, Medium, Heavy or superheavy) climbing rates with Minimum Take Off Weight climbing rates with Maximum Take Off Weight descending rates

The above information can be defined for different level ranges (level dependent data).

Aircraft PerformanceEligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print Aircraft Performance. While storing an Aircraft Performance the following information is provided: Aircraft Type Aircraft Class Type, which the Aircraft Type belongs to

6.1.2.3 Pool of SSR Codes

Eligible operators are enabled to set-up the pool of available SSR codes for the different flight categories. Details about SSR Codes management (executed by the LFDPS) are given in paragraph 6.7.




6.1.3 DYNAMIC DATA

In order to perform trajectory prediction with a sufficient accuracy it is necessary to know some meteorological data such as the wind direction and speed. These parameters do not have the same values for each point of the system AoR. Therefore, a set of them has to be associated to a volume of airspace in which they are applicable. The number of volumes is large enough to provide the trajectory prediction with a sufficient accuracy.It is allowed to handle the dynamic environmental data, which mainly include:

Upper wind data, manually inserted by eligible operators (FPPS/LFDPS). The upper wind data is stored into a 3-dimensional grid, together with their expiring time. The upper wind data is used while computing the flight trajectory, if not yet expired, otherwise is ignored. Wind data can be manually inserted by the operator who owns the requested access rights in the Wind Grid which is defined as a composition of cells, each of them is one latitude degree per one longitude degree wide. The grid is defined according to five layers relevant to different flight level ranges.




6.2 MESSAGE HANDLING

6.2.1 GENERAL

The Message Handling function deals with the messages exchanging with units external to the system and, even if with different characteristics, it is implemented on both FPPS and LFDPS.

The FPPS is able to automatically receive, store, process, extract, deliver for displaying and transmit in real-time ATS messages and MET/AIS1 messages.

The following ATS messages can be exchanged by means of the AFTN, according to ICAO format (see Doc. 4444-RAC/501/12):

Filed flight plan FPL Flight plan cancellation CNL Flight plan modification CHG Departure DEP Arrival ARR Delay DLA Estimate EST Current Flight Plan CPL ATC Flight Plan APL ATC Flight Plan Change ACH ATC Flight Plan Proposal AFP Request Flight Plan RQP

The following ATS messages can be exchanged with the Initial Flight Plan Processing System (IFPS), according to ADEXP format:

Filed flight plan IFPL Flight plan cancellation ICNL Flight plan modification ICHG Departure IDEP Arrival IARR Delay IDLA ATC Flight Plan IAPL ATC Flight Plan Change IACH ATC Flight Plan Proposal IAFP Request Flight Plan IRQP

1 The MET/AIS messages reception is enabled both on the FPPS and the LFDPSs (ref. to 6.2.4).




The following MET / AIS messages can be received by means of the AFTN, according to ICAO format (see annex 10 to Doc. 4444-RAC/501/12):

Message Type DescriptionFCRO61 Weather forecast (TAF 9 Hr)FCRO62 Weather forecast (TAF 9 Hr)FCRO63 Weather forecast (TAF 9 Hr)FCRO64 Weather forecast (TAF 9 Hr)FCRO65 Weather forecast (TAF 9 Hr)FTRO61 Weather forecast (TAF 18 Hr)SARO61 METARSARO62 METARSARO63 METARSARO64 METARSARO65 METARSPRO51 SPECIWSRO31 SIGMETFXRO41 Upper wind/significant weather forecast NOTAM Notice to airmanSNOWTAM Snow message

The following ATFM messages can be received from the Central Flow Management Unit (CFMU), according to ADEXP format:

Slot allocation SAM Slot cancellation SLC Slot revision SRM Flight Suspension FLS Flight De-Suspension DES

The First System Activation (FSA) message can be transmitted to the Central Flow Management Unit (CFMU), according to ADEXP format.

The following notification and co-ordination messages can be exchanged by the LFDPS according to the Eurocontrol Standard for OLDI (On Line Data Interchange) either via X.25 lines or TCP/IP protocol (FMTP):

BASIC PROCEDURE - MANDATORY MESSAGESAdvance Boundary Information Message (ABI) Activate Message (ACT) Revision Message (REV) Message for the Abrogation of Co-ordination (MAC) Preliminary Activate Message (PAC) Logical Acknowledgement Message (LAM)

BASIC PROCEDURE - COMPLEMENTARY MESSAGESSSR Code Assignment Message (COD)




PRE-DEPARTURE CO-ORDINATIONClearance Request (CRQ) Clearance Response Message (CRP)

Ground – Ground SITUATIONAL AWARENESSInformation Message (INF)

DIALOGUE PROCEDURE - COORDINATIONReferred Activate Proposal Message (RAP)Referred Revision Proposal Message (RRV)Stand-by Message (SBY) Acceptance Message (ACP) Co-ordination Message (CDN)

DIALOGUE PROCEDURE - TRANSFER OF COMMUNICATIONTransfer Phase Initiation Message (TIM) Supplementary Data Message (SDM) Hand-Over Proposal (HOP) Request on Frequency Message (ROF) Change of Frequency Message (COF) Manual Assumption of Communications Message (MAS)




6.2.2 ATS MESSAGES RECEPTION

The FPPS is able to perform semantic and syntactic checks on the ATS messages received via AFTN lines, according to ICAO PANS_RAC 4444 rules. If the checked message is error free, it shall be stored, automatically in its own SFPLs Data Base. If the checked message is not error free, it shall be inserted into a proper queue in order to be manually corrected by the operators. As soon as the wrong message is corrected, it shall be stored into the SFPL s Data Base.The FPPS manages the airway direction constraints. They are configurable according to the specific airway segment defined in the system.The FPPS is able to check on the received FPLs whether the route data (field 15 of the ICAO FPL format) are congruent with the established airways direction constraints.If the checked message is incorrect, it shall not be inserted in the FPLs Data Base.

In case of unavailability of AFTN connection, the FPPS is capable of keeping the ATS messages sequence received up to now. When the AFTN link is re-established if the number of the new ATS message is not following the last ATS message stored, the FPPS requires to AFTN switch to re-transmit the missing ATS messages in order to restore the message sequence.

For each FPL related message in ICAO format, the FPPS is able to validate its fields as follows: Field 3: Read message type to determine further processing Field 7: Check syntax Field 8: Check and decode letters for flight rules to determine processing Field 9: Check syntax, check A/C type versus WTC, TAS and RFL Field 10: Check letters against convention Field 13: Check syntax and relevance. Check time for correct notation. Field 14: Check estimate data Field 15: Check basic syntax and semantics as far as practical. Field 16: As for field 13 Field 17: Check arrival aerodrome and time Field 18: Check content of “keywords” for syntax. Field 22: Amendment

The same actions are performed for the corresponding fields in ADEXP format.




6.2.3 MANUALLY TRIGGERED GENERATION OF MESSAGES

It is possible to select for each flight under consideration the type of message to be transmitted, among the available ones, from a menu which is arranged in a logical order. After selection, a message proposal is suggested by the FPPS and submitted to the operator for modifications, if any.The resultant ATS messages is then validated (semantic, syntax) by the FPPS before transmission.If any error is detected this is indicated clearly (e.g. highlighted). Also semantic errors are presented to the operator in a clear and understandable way.When distributing to AFTN, the system formats the above mentioned information in ICAO format (see Doc. 4444-RAC/501/12) and ADEXP format (AFP and RQP messages).

6.2.3.1 Transmission of Free-text Messages

The operator can write and send an AFTN message as free text. On request, the system will open a blank form in order to: write the text of the message, as free text ask for the message transmission

If requested, from the FPPS client positions it is possible to open a form in which the operator is asked to specify the destination address and the requested transmission time (the FPPS suggests the system time).An Address Book is available to support the operator in choosing the addresses.

6.2.3.2 Messages Addressing

By means of proper addressing tables the FPPS automatically supports the AWP operator in addressing messages.The system provides the operators with an address book, loaded by the operators themselves, whose entry key is a couple of identifiers, four characters long each. (e.g. a couple of ICAO Location Indicators). For each couple the system maintains a list of AFTN addresses.The address book is provided with a button to add the addresses of the currently selected book item to the field Addressee Indicators of the message.On operator request, the FPPS can open the address book, to facilitate him during the selection of the destinations addresses.In any case, the operator is enabled to manually fill the field by himself or to update the system suggestions.




6.2.4 MET / AIS MESSAGES RECEPTION

The following MET/AIS messages can be received by the FPPS/LFDPS by means of the AFTN, according to ICAO format (see annex 10 to Doc. 4444-RAC/501/12):

Message Type DescriptionFCRO61 Weather forecast (TAF 9 Hr)FCRO62 Weather forecast (TAF 9 Hr)FCRO63 Weather forecast (TAF 9 Hr)FCRO64 Weather forecast (TAF 9 Hr)FCRO65 Weather forecast (TAF 9 Hr)FTRO61 Weather forecast (TAF 18 Hr)SARO61 METARSARO62 METARSARO63 METARSARO64 METARSARO65 METARSPRO51 SPECIWSRO31 SIGMETFXRO41 Upper wind/significant weather forecast NOTAM Notice to airmanSNOWTAM Snow message

LFDPS/FPPS client positions and CWPs shall be provided with the information contained in the received MET/AIS messages.

6.2.5 ATFM MESSAGES HANDLING

The ATFM messages are only managed by the LFDPS.The Message Handling function handles slot information data from CFMU/TACT received through the following ATFM (Air Traffic Flow Management) messages in ADEXP format via the AFTN:

SAM Slot Allocation Message; SRM Slot Revision Message; SLC Slot Cancellation Message. FLS Flight Suspension Message DES De-Suspension Message

When an ATFM message is received the eligibility of the sender is checked. If the sender is not eligible, the message is forwarded to the “Rejected messages queue”.Then, syntax and semantics checks are performed. If any error is found, the message is forwarded to the “Rejected messages queue”.If syntax analysis and sender eligibility check are successful, association with the corresponding flight plan data shall be attempted, by using the “ARCID”, “ADEP”, “ADES”, “IOBD” (if it is not available “EOBD” shall be used), “IOBT” (if it is not available “EOBT” shall be used) fields. All these fields are available in the listed messages.




If the association between the message and the referred SFPL is not successful (e.g. the referred SFPL is not stored in the LFDPS database or duplicated SFPLs are found) the message is transmitted to the “Wrong Messages Queue” for manual operation.If the association between the message and the referred SFPL is successful but the referred SFPL is already “active” or “live” the message is transmitted to the “Wrong Messages Queue” for manual operation.If the association between the message and the referred SFPL is successful and the SFPL state is “inactive” or “pending” the message shall be used to update the SFPL according to the received message as described in the following paragraphs.Regardless of the results of the SFPL association attempt, each received ATFM message is stored and can be retrieved on operator request. The rules for the management of the above messages are in accordance with what detailed in [6], [21], [22], [23], [24].

6.2.5.1 Slot Allocation Message (SAM) Handling

The SAM is used to inform the ATS unit of the Calculated Take Off Time for an individual flight to which it must adhere. It contains the following data: TITLE Message Name ADDR (optional) List of Addresses ARCID Aircraft Identification ADEP Aerodrome of Departure EOBD Date of Flight (YYMMDD) EOBT Estimated Off-Block Time IOBD (optional) Initial Off-Block Date IOBT (optional) Initial Off-Block Time CTOT Calculated Take-Off Time REASON (optional) Reason to explain an action ADES Aerodrome of Destination REGUL (one or more) Identifier for the restriction imposed COMMENT (optional - none, one or more) Additional information (if any) TAXITIME Difference between Off-Block Time and

Take-Off Time.

If syntax and semantics checks are met, the association between the message and the referred SFPL is successful and the SFPL state is “inactive” or “pending” the message is used to update the SFPL CTOT (see also section 6.3.3). In this case if “IOBD” and “IOBT” are included in the message, “EOBD” and “EOBT” values (different from “IOBD” and “IOBT”) are used to update the corresponding fields in the SFPL. The flight trajectory is re-calculated using the new calculated take-off time.




6.2.5.2 Slot Revision Message (SRM) Handling

The SRM is used to inform the ATS unit of a significant change of slot. It is issued after an initial SAM and indicates a delay increase or decrease. It contains the following data:

TITLE Message Name ADDR (optional) List of Addresses ARCID Aircraft Identification ADEP Aerodrome of Departure EOBD Date of Flight (YYMMDD) EOBT Estimated Off-Block Time IOBD (optional) Initial Off-Block Date IOBT (optional) Initial Off-Block Time NEWCTOT Revised CTOT REASON (optional) Reason to explain an action ADES Aerodrome of Destination REGUL (one or more) Identifier for the restriction imposed COMMENT (optional-none, one or more) Additional information (if any) TAXITIME Difference between Off-Block Time and Take-Off

Time.

If syntax and semantics checks are met, the association between the message and the referred SFPL is successful and the SFPL state is “inactive” or “pending” the “NEWCTOT” field is used to update the SFPL CTOT. In this case if “IOBD” and “IOBT” are included in the message, “EOBD” and “EOBT” values (different from “IOBD” and “IOBT”) are used to update the corresponding fields in the SFPL. The flight trajectory is re-calculated using the new calculated take-off time.If a SAM has not been received before the SRM, the SRM is processed like a SAM.

6.2.5.3 Slot Cancellation Message (SLC) Handling

The SLC is used to advise the ATS unit that a flight which has received a CTOT is no longer subject to an ATFM restriction. It contains the following data:

TITLE Message Name ADDR (optional) List of Addresses ARCID Aircraft Identification ADEP Aerodrome of Departure EOBD Date of Flight (YYMMDD) EOBT Estimated Off-Block Time IOBD (optional) Initial Off-Block Date IOBT (optional) Initial Off-Block Time REASON (optional) Reason to explain an action ADES Aerodrome of Destination COMMENT (optional-none, one or more) Additional information (if any) TAXITIME Difference between Off-Block Time and Take-Off

Time.




If syntax and semantics checks are met, the association between the message and the referred SFPL is successful and the SFPL state is “inactive” or “pending”, the slot time is removed from the SFPL. The SLC reception does not imply the cancellation of the SFPL. If there is no CTOT information available in the SFPL’s fields, the SLC message is transmitted to the “Wrong messages queue”.

6.2.5.4 Flight Suspension Message (FLS) Handling

Certain specific conditions may lead to flights being unable to depart. The CFMU/TACT sends a FLS to inform the ATS unit that a flight has been suspended. The FLS contains the following data:

TITLE Message Name ADDR (optional) List of Addresses ARCID Aircraft Identification ADEP Aerodrome of Departure EOBD Date of Flight (YYMMDD) EOBT Estimated Off-Block Time IOBD (optional) Initial Off-Block Date IOBT (optional) Initial Off-Block Time NEWEOBD (optional) New Estimated Off-Block Date NEWEOBT (optional) New Estimated Off-Block Time REASON (optional) Reason to explain an action ADES Aerodrome of Destination REGUL (one or more) Identifier for the restriction imposed COMMENT (optional- none, one or more) Additional information (if any) TAXITIME Difference between Off-Block Time and Take-Off

Time.

If syntax and semantics checks are met, the association between the message and the referred SFPL is successful and the SFPL state is “inactive” or “pending”, according to the contents of the message the following actions are undertaken: Shift of the EOBT

If the “NEWEOBT” field is contained in the message the SFPL is updated with this new value, the CTOT field is set to “FLS” and the Estimated Take-Off time is evaluated starting from this time.

True SuspensionCFMU/TACT indicates with the FLS that the flight is considered as not taking off. The “NEWEOBT” is not contained in the message. Flight data are kept in the database but the CTOT field is set to “FLS”.




6.2.5.5 De-Suspension Message (DES) Handling

The DES is used to inform the ATS unit that a flight, which was previously suspended, is now de-suspended and it is no longer subject to ATFM measures. DES is composed of the following data:

TITLE Message Name ARCID Aircraft Identification ADEP Aerodrome of Departure EOBD Date of Flight (YYMMDD) EOBT Estimated Off-Block Time IOBD (optional) Initial Off-Block Date IOBT (optional) Initial Off-Block Time NEWEOBD (optional) New Estimated Off-Block Date NEWEOBT (optional) New Estimated Off-Block Time REASON (optional) Reason to explain an action ADES Aerodrome of Destination COMMENT (optional-none, one or more) Additional information (if any) TAXITIME Difference between Off-Block Time and Take-Off

Time.

If syntax and semantics checks are met, the association between the message and the referred SFPL is successful and the SFPL state is “inactive” or “pending”, the SFPL is de-suspended and, if included, “NEWEOBD” and “NEWEOBT” fields are used to update the corresponding data in the SFPL. The ETOT value is calculated starting from the “NEWEOBT” and the CTOT field is set to ‘blank’.If DES is received for a SFPL, which is not stored with the suspension flag set, it is re-routed to the “Wrong message queue”.




6.2.5.6 First System Activation (FSA) Message Transmission

The LFDPS automatically generates FSA messages and send them to the CFMU/TACT via AFTN triggered by the following events:

SFPL activation Time (i.e.: ACT message, EST order) for inbound and overfly flights. (The message shall supply the estimated time, level and point of entry into the FDPA airspace)

Take Off for (i.e.: TKF order) departing flights (the message shall supply the ATOT)

SFPL Re-routing order inside FDPA (i.e. REV OLDI message or RCR, DCR orders on CWP or FDA) if:

- The re-routing doesn’t affect the exit point - If the information has not already been sent by an AFP

message

In this case the FSA messages are formatted as follow:

FSA_MESSAGES: = “-“+”TITLE FSA”+ (ifplid) + arcid + ades + eobt + eobd + (arctyp) + position + 0{geo} + 0{ref} + 0{rename} + furthrte + 0 {rfl}+ 0 {atsrt} + 0 {dct}

In the position field, the PTID contains the next route point or the point where the change starts.

The furthrte field contains the route inside the FDPS, from PTID forward (it will be defined as a list of consecutive points that the aircraft will over fly inside the FDPA).

The FSA message includes the IFPLID if contained in the original FPL/APL.For each of the above mentioned events it is possible to enable or disable the generation according to system parameters.

The LFDPS is able to store and manage each transmitted FSA message.




6.2.6 CO-ORDINATION MESSAGES EXCHANGE

The co-ordination messages are managed by the LFDPS. The FPPS has only the capability both to receive the INF messages transmitted by the LFDPS and to store the wrong OLDI messages in the dedicated queue, with the aim of allowing their manual correction.

The following notification and co-ordination messages can be exchanged according to the Eurocontrol Standard for OLDI (On Line Data Interchange):





DIALOGUE PROCEDURE - COORDINATIONReferred Activate Proposal Message (RAP)Referred Revision Proposal Message (RRV)Stand-by Message (SBY) Acceptance Message (ACP) Co-ordination Message (CDN)


The system contains a set of parameters in order to ensure timely, automatic initiation of OLDI messages, defining the following:a) lead time, per COP, to transmit the message, where applicable;b) time after transmission of a message within which an application level acknowledgement is to be

received (time-out).




c) parameters for triggering the event driven transmission of a message, where applicabled) optional fields

Moreover, the capability to manually initiate the transmission of a co-ordination message prior to the calculated transmission time is provided.The received OLDI messages are processed automatically and their information is used to update the related SFPL. Their content is displayed on operator request or with a warning indication in case of inconsistency in the data received.An acknowledgement message (Logical Acknowledgement – LAM or Stand BY - SBY) is generated and transmitted when the corresponding message has been processed. The actual implementation of the Co-ordination function is dependent upon the level of functionality offered by each individual co-ordination partner.Details about the processing of OLDI messages in order to accomplish the “Co-ordination” function which allows ground-ground co-ordination as required by the Eurocontrol Standard are given in paragraph 6.9.




6.3 INITIAL FLIGHT DATA HANDLING

6.3.1 GENERAL

The Initial Flight Data Handling (IFDH) function is concerned with the creation and the early modifications of a SFPL.Several sources are considered for these operations (operator, RPLs database, ATS and co-ordination messages), but their eligibility is always checked and the integrity of data is granted by the system.

Both the FPPS and the LFDPS are concerned with the IFDH capability which is customised considering the different eligible sources for the systems.

When the creation or the modification is the result of the reception of a message from an eligible external source, the FPPS/LFDPS process the messages as summarised by Table 6.3-1 and described in the subsequent paragraphs.

TABLE 6.3-1 - OPERATION ON SFPLs AT THE RECEPTION OF CORRECT MESSAGES

Received Message Operation on the eligible SFPL already existing in the database

Processing when the referred SFPL is not found in the database

FPL (AFTN) Update of the existing SFPL Creation of a new SFPL

CPL (AFTN) Update of the existing SFPL Creation of a new SFPL

CHG (AFTN) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

DLA (AFTN) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

DEP (AFTN) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

ARR (AFTN) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

CNL (AFTN) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

EST (AFTN) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

APL (AFTN) Update of the existing SFPL Creation of a new SFPL

ACH (AFTN) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

IFPL (IFPS) Update of the existing SFPL Creation of a new SFPL




TABLE 6.3-1 - OPERATION ON SFPLs AT THE RECEPTION OF CORRECT MESSAGES (CONT.)

Received Message Operation on the eligible SFPL already existing in the database

Processing when the referred SFPL is not found in the database

ICHG (IFPS) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

IDLA (IFPS) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

IDEP (IFPS) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

IARR (IFPS) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

ICNL (IFPS) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

IAPL (IFPS) Update of the existing SFPL Creation of a new SFPL

IACH (IFPS) Update of the existing SFPL Transmission to the Incorrect ATS Messages Queue

SAM (CFMU) Update of the existing SFPL Transmission to the Incorrect ATFM Messages Queue

SRM (CFMU) Update of the existing SFPL Transmission to the Incorrect ATFM Messages Queue

SLC (CFMU) Update of the existing SFPL Transmission to the Incorrect ATFM Messages Queue

FLS (CFMU) Suspension of the existing SFPL Transmission to the Incorrect ATFM Messages Queue

DES (CFMU) Update of the existing SFPL Transmission to the Incorrect ATFM Messages Queue

ABI (OLDI) Update of the existing SFPL Creation of a new SFPL

PAC (OLDI) Update of the existing SFPL Creation of a new SFPL

ACT /RAP (OLDI) Update of the existing SFPL Creation of a new SFPL

MAC (OLDI) Reversion of the existing SFPL data to the conditions prior to the abrogated co-ordination

Message rejection

REV, RRV, CDN, RJC, ACP, COF, MAS, ROF, HOP, CRQ, CRP,

(OLDI)

Update of the existing SFPL Message rejection

INF (OLDI) Message rejection Creation of a new SFPL if AOI only




6.3.2 SFPL CREATION

The FPPS creates a SFPL, based on the information derived from one of the following sources:

Data directly introduced by operators owning the requested access rights; IFPL, FPL, APL, IAPL and CPL messages received from an eligible source (e.g. IFPS) by the AFTN; Wake Up of RPLs from the relevant database.

Each time a message is proposed for creation of a new SFPL, the Route Analysis and Extraction function is performed as described in paragraph 6.5. The SFPL is created if initial route processing predicts that the flight will enter the controlled airspace.Independently from the originating source, the FPPS allows duplicated callsigns in the “inactive” state but inhibits the creation of SFPLs having the same values associated to all of the following fields: Flight Identification; Departure Aerodrome; Destination Aerodrome; Estimated Off Block Time; Date of Flight; Entry Point.

The FPPS checks on the received message whether the route data (field 15 of the ICAO FPL format) are congruent with the established airways direction constraints.If the checked message is incorrect, it shall not be inserted in the FPLs Data Base.

The LFDPS creates a SFPL, based on information received from the FPPS or introduced as a “short flight plan”:In the LFDPS, only a single callsign is allowed for SFPL from the “pending” state on. Thus, the transition to “pending” of an inactive “SFPL” is authorised only if the previous SFPL with the same callsign is terminated or cancelled. Anytime a new SFPL is created in the “inactive” state the Route Extraction function is activated as described in paragraph 6.5 in order to calculate the 2D path of the flight. After this operation the Estimated Time of Inbound (for flights entering the controlled airspace) or the Estimated Time of Departure (for flight departing from an aerodrome inside the controlled airspace) is also calculated.

The description of the rules for flight plan creation is provided in the following paragraphs for each different source.




6.3.2.1 Creation of a SFPL by Manual Input.

A SFPL can be manually created using the complete ICAO form or in a limited version, inserting at least the “Callsign” and the “Aircraft Type”. The flight data input is supported by the system which provides the operator with a user friendly interface, proposing suggestions. The FPPS supports the operator in the assignment of the route to the SFPL. Predetermined preferential routes can be retrieved from a database where they have been formerly defined specifying the couple Aerodrome of Departure / Aerodrome of Destination.The FPPS submits each manually entered SFPL to the following processing steps: format analysis, in order to find format and syntax errors according to the rules laid down in “Rules of

the Air & Air Traffic Services”, ICAO Document 4444 - RAC/501/12. check whether the same flight plan (i.e. having the same aircraft identification, departure aerodrome,

departure time and destination aerodrome) already exists in the database. route analysis and extraction consistency analysis, to find inconsistencies with the internal databases.

If any error is found in any of the above operations, the FPPS rejects the message to the operator together with an error indication, for the correction.

6.3.2.2 Creation of SFPL by Message Reception

The FPPS is able to create a new SFPL at the reception of a “FPL”, “IFPL”, “APL”, “IAPL” or a “CPL” ATS message via the AFTN or at the reception of an “ABI”, a “PAC” or an “ACT” or “RAP” OLDI message when the referred SFPL does not exist in the FPPS database. The rules for the creation of the new SFPL after the reception of an ATS message via AFTN are outlined in the present paragraph, while for the OLDI messages the relevant description is provided in paragraph 6.9.

As far as the ATS messages are concerned, the FPPS decodes the first part of text of each received AFTN message in order to check for the type. First, it is submitted to format analysis, in order to find format and syntax errors according to the rules laid down in “Rules of the Air & Air Traffic Services”, ICAO Document 4444 - RAC/501/12 (“FPL”, “APL” and “CPL”) or in the Eurocontrol Standard for ADEXP (“IFPL”, “IAPL”).

For each received “FPL”, “IFPL”, “APL”, “IAPL” or a “CPL message without any format or syntax error, FPPS performs the following operations: check, by means of the algorithm of Route Analysis and Extraction, if the Item 15 (route) is error free. consistency analysis, to find inconsistencies with the internal databases. check whether the same flight plan (i.e. having the same aircraft identification, departure aerodrome,

departure time, date of flight and destination aerodrome) already exists in the database. insertion of the corresponding flight plan or update of the already existing flight plan into the flight

plan data base.




In case of impossibility to accomplish one of the above operations, the associated message is rejected to the Incorrect ATS Message Queue for the appropriate operator for manual: correction or supplementation deletion

If the same SFPL (i.e. having the same aircraft identification, departure aerodrome, departure time, date of flight and destination aerodrome) already exists, “FPL”, “IFPL”, “APL”, “IAPL” or a “CPL messages data are considered for the update of the SFPL remaining fields.

6.3.2.3 Creation of SFPL by Repetitive Flight Plan Database

A Repetitive Flight Plan (RPL) is a collection of flight data, such as in the case of a FPL, more a validity period and a list of days of operations. Each RPL, is uniquely identified by: Aircraft Identification; EOBT; Departure Aerodrome; Arrival Aerodrome; validity period (from / to); days of operation (Sunday, Monday, …); Entry point.

The RPL data management is carried out at authorised AWPs where can be performed operations such as: insertion of a new RPL; updating of an existing RPL; deletion of an existing RPL; inquiring the RPL database; loading RPLs from disk.

Periodically a wake-up procedure is activated. The procedure creates a SFPL from each RPL whose ETD (Estimated Time of Departure) or ETI (Estimated Time of Inbound) is a variable system parameter after the current time, as illustrated in Figure 6.3.2.3-1.The created SFPL is stored into the flight plans database as an “inactive” SFPL, and processed independently, only if no other SFPL exists having the same Callsign, Aerodrome of Departure, Aerodrome of Destination, Estimated Off Block Time, Date of Flight fields as the originating RPL:




ETI or EOBT

time

VSP time beforeETI or EOBT

PERIODIC RPLsWAKE UP

PROCEDURE

INACTIVE SFPL = FPLs with the specified ETI or EOBT

FIG. 6.3.2.3-1 – RPLs WAKE UP




6.3.3 DETERMINATION OF THE ESTIMATED TAKE OFF TIME (ETOT)

The ETOT is the time at which it is calculated that the flight should take off based on the currently available data. It is initially determined using the filed EOBT, the CTOT (if any) and local data about the proposed departure runway usage and taxi times, but it is updated through the life cycle of the flight prior to take off. It may be modified manually if required.If no CTOT has been received for a flight, the initial ETOT is calculated using the EOBT (as initially filed in the SFPL), plus time for “taxi” from the departure position to the holding point of the departure runway.If a CTOT has been received from the CFMU for the flight, the ETOT is set to the CTOT.

6.3.4 INITIAL SFPL DATA MODIFICATIONS

After having created the SFPL, modifications can be performed on the stored data by eligible sources using one of the following means: ATS messages via the AFTN; OLDI messages; ATFM messages; Update facilities provided on the AWPs with the requested access rights; Orders issued by the AWP operators with the requested access rights; Orders issued by the CWPs.

The extent of the modifications authorised on each SFPL depends on the associated flight category and on the SFPL state. In the subsequent paragraphs, the rules for the modifications (update or deletion) of “inactive” and “pending” SFPLs are outlined, except for the management of changes due to the reception of OLDI messages, which is detailed in paragraph 6.9 and the management of changes due to the reception of ATFM messages, which is detailed in paragraph 6.2.5.

6.3.4.1 Modifications upon reception of an ATS message

The FPPS modifies SFPLs according to the elements contained in the following ATS messages: arrival message: ARR IARR; departure message: DEP IDEP; change message: CHG ICHG; delay message: DLA IDLA; estimate message: EST ATC Flight Plan Change ACH IACH

The FPPS deletes a SFPL according to the elements contained in the CNL/ICNL, Flight Plan Cancellation message. Furthermore an update of the SFPL is carried out also when a “FPL”, “IFPL”, “APL”, “IAPL” or a “CPL message is received and the related flight is already in the LFDPS database in Inactive/Pending state.




6.3.4.2 Manual modifications

If the SFPL is in the “inactive” or in the “pending” state (only for the LFDPS), the operator at the LFDPS client position owning the requested accessed rights, is allowed to open the same mask used for that SFPL creation to perform the update of one or more of the indicated fields. At this stage, all the fields can be updated, except the Callsign. After having carried out the modifications, the SFPL is proposed to the system which performs the same checks carried out when the SFPL is created for the first time.SFPLs in the “inactive” or “pending” states can be also deleted by authorised operators. The SFPL data reflect orders issued by controllers from the CWPs. A subset of the available orders can be also issued from the AWPs when the flight plan is “pending” by operators owning the requested access rights . Orders relevant to SFPLs in “active” and “live” state are described in paragraph 6.4. The set of orders available on the CWP can be configured before system integration.When an order is issued, a communication process is established with the ACD CSCI to perform all the checks relevant to the eligibility of the source.




6.4 FLIGHT PROGRESS DATA HANDLING

6.4.1 GENERAL

The Flight Progress Data Handling (FPDH) function is a LFDPS capability concerned with the modifications of SFPL’s data after its transition to the “active” state and until its termination, as it is illustrated in Figure 6.4-1.As already described and as it is illustrated in Figure 6.4-2 and Figure 6.4-3, the LFDPS changes the SFPL “pending” state into the “active” state upon: Manual input of a departure or an inbound clearance; Reception of an activation message (OLDI ACT); Issue of the EST Order.

As it is illustrated in Figure 6.4-4, the LFDPS changes the state of the SFPL from “active” to “live” in one of the following cases: Automatic report on the first internal fix (inbound-overfly flights) or after Take Off detection (local-

domestic-outbound flights) when correlation between SFPL/System Track exists. Manual input of a position report on the first internal fix (inbound-overfly flights) or of a Take Off

report (local-domestic-outbound flights).

In “active” and “live” SFPL states a set of system functions are automatically enabled to follow the flight progress and several orders are available on the CWPs and on the AWPs (depending on the access rights) with the same purpose.Therefore, the following sources are considered for these progress data update operations Manually issued orders; System Calculations; Reception of Revision (REV) and Abrogation (MAC) OLDI messages;

In the subsequent paragraphs, the rules for the modifications of “active” and “live” SFPLs are outlined, except for the management of changes due to the reception of OLDI messages, which is detailed in paragraph 6.9.

FIG. 6.4-1 – FPDH AND RELATED SFPL STATES




FIG. 6.4-2- AUTOMATIC SFPL ACTIVATION

FIG. 6.4-3 - MANUAL SFPL ACTIVATION




FIG. 6.4-4 – SFPL TRANSITION TO THE “LIVE” STATE

6.4.2 SFPL DATA UPDATE UPON SYSTEM CALCULATIONS

When the SFPL is correlated with the system track (according to the rules outlined in paragraph 6.8), the LFDPS is able to compare the actual flight data with the expected ones in the context of the environmental information stored in its database. Consequently, the LFDPS is able to verify the flight progress and to review information about its next positions using the refreshed data.The following events are captured during the flight progress: Automatic Report on Fix:

By following the actual flight along the expected trajectory, if no deviation occurs, its passage over a Fix is detected. The Actual Time Over the Fix and the Actual Flight Level are taken as source data for the 4D profile re-calculations, as described in paragraph 6.5. If the reported Fix is the first one in the controlled airspace, the SFPL turns from the “active” to the “live” state.

Inbound of an aircraft:The aircraft is considered entered in the controlled airspace when an automatic report on an inbound fix is given. As for the report on other Fixes, passage data are taken as a source for trajectory recalculation.

Outbound of an aircraftThe aircraft is considered out of the controlled airspace when an automatic report on an outbound fix is given.

Landing of an aircraftThe aircraft is considered landed when last report before arrival has been issued and the correlated surveillance data are lost for more than a VSP time.




Aircraft take off The aircraft is considered departed after a departure clearance when correlation with radar tracks occur after the runway threshold Fix. The Actual Time of Departure is taken as a source for trajectory recalculation.

Conditions for the automatic transmission of a notification or a co-ordination message.The actual aircraft position is considered to update the passage data over a Co-ordination Point, in order to detect the conditions to transmit OLDI messages as described in paragraph 6.9.

Deviations from the expected position.The actual aircraft position is compared with the expected one to detect deviations as described in paragraph 7.1.

6.4.3 MANUAL SFPL DATA UPDATE

The SFPL data reflect orders issued by controllers from the CWPs. A subset of the available orders can be also issued from the AWPs when the flight plan is “active” or “live” by operators owning the requested access rights. When an order is issued, a communication process is established with the ACD CSCI to perform all the checks relevant to the eligibility of the source.




6.5 TRAJECTORY PREDICTION

6.5.1 GENERAL

The aim of the Trajectory Prediction function is to predict the full trajectory that a flight will follow within the boundaries of the Controlled Airspace. This trajectory is used to determine the list of geographic sectors to be crossed and to detect the events associated to the SFPL life cycle.The Trajectory Prediction function is composed of two main algorithms, the first of which (Route Analysis and Extraction) checks the route from errors, recognises the portion of route belonging to the Controlled Airspace and computes a 2D path for the flight. The second (4D profile Calculation) computes a four-dimensional (x, y, z and time) path from the first controlled point to the last. Doing this, LFDPS and FPPS take into account the stored airspace structure which defines the Controlled Airspace (e.g. ATS routes, departing and arrival procedures, runways), the aircraft performances and upper wind information. Furthermore, the Trajectory Prediction function is able to consider direct route segments, internal to the Controlled Airspace, also if their limits are expressed in terms of longitude/latitude co-ordinates.All IFR flights are eligible for trajectory prediction. VFR flights with valid route are handled in same way as IFR flights. For VFR flights without valid route only a minimum processing is carried out, as described in paragraph Error: Reference source not found, since Trajectory Prediction cannot be performed accurately for VFR route segments as the route and the levels are indeterminate.For flights with routes containing more than one transition to or from VFR, the trajectory is disjointed as the VFR segment are indeterminate. It is assumed that information relevant to transition points from a VFR to an IFR segment is entered manually.In the subsequent paragraphs a description of the Route Analysis and Extraction and the 4D profile Calculation is provided. Examples relevant to the behaviour of the Trajectory Prediction are given in paragraph Error: Reference source not found.




6.5.2 DATA SOURCES

The data sources for the algorithm of Route Analysis and Extraction are: The following fields from the FPL: Field 8 Flight Rules; Field 13 Departure aerodrome and Estimated Off Block Time; Field 15 The Requested Speed and the Route; Field 16 Destination Aerodrome; The following Geographical Data: Aerodromes, with the relevant Departure/Arrival Automation Level (i.e. if their are SID/STAR

provided, or not); Runways; Fixes; Airways; The ATC Constraints.The data sources for the algorithm of 4D Profile Calculation are: The 2D flight path calculated by the Route Analysis and Extraction function; The field 9 (Aircraft Type) from the FPL; The field 15 (the Requested Speed and the Requested Flight Level) from the FPL; The Controlled Airspace Sectors breakdown; The aircraft performances; The upper wind data; The ATC Constraints; Data relevant to manual or automatic reports on fixes (ETO and Actual Flight Level); Longitudinal non - conformance detection data from the Conformance Monitoring Function as

described in paragraph 7.1.

ATC constraint is a unifying concept for expressing any restriction to the route or profile of flight. Two broad classes of constraints are defined: Strategic constraints. These constraints are generated by the airspace structure and are considered for

Departing and Arrival flights. For each runway it is possible to define a joining path to each airway, either for the departures and for the arrivals. These paths (SIDs and STARs) are defined in the Environmental database by means of associated levels to “system” fixes inserted with this purpose. Level constraints on fixes and airways can also be defined.

Tactical constraints. These constraints represent controllers' actions, guidance orders, or clearances. They are expressed by means of the orders available on the CWPs and on the AWPs to operators owning the requested access rights, as described in paragraphs 6.3 and 6.4.




6.5.3 ROUTE ANALYSIS AND EXTRACTION

The Route Analysis and Extraction process consists of building a 2D route by translating into a list of 2D points the route proposed in the flight plan or in ATS and OLDI messages,.LFDPS and FPPS perform complete route processing for those parts of the total route which are inside the Controlled Airspace each time: a new SFPL is created; an RPL is created or modified; an existing “inactive” or “pending” SFPL is modified on the route related items by a manual update or

by the reception of an external message containing route information; an order which modifies the route related items is issued for a “pending” SFPL; an order which modifies the route related items is issued for an “active” or “live” SFPL; an OLDI message which modifies the route related items is received for an “active” SFPL and is

approved by the operator.

The Route Analysis and Extraction algorithm: validates the route field data according to the rules laid down in ICAO PANS/RAC Doc. 4444 recognises the portion of route belonging to Controlled Airspace; calculates the list of 2D points defining the flight path, inserting the “system” points used to define

SIDs and STARs and breaking down each indicated airway by means of the fixes that compose them.

Furthermore, for each SFPL departing from an aerodrome inside the Controlled Airspace, it provides the Estimated Time of Departure and for each SFPL entering the Controlled Airspace, it provides the Estimated Time of Inbound, thus defining the time events referenced by the LFDPS for the transition of an “inactive” SFPL to the “pending” state. Here follows a summary of the algorithm behaviour for different categories of flights.

Flight departing from an aerodrome within the Controlled Airspace (domestic, local and outbound flights)If the aerodrome’s Departure Automation Level is “SID provided” the algorithm automatically assigns the proper SID, otherwise it will recognise the airway’s joining point, as laid down in the environmental data. The two dimensional path includes also points resulting from SID break down or the airway’s joining point. The Estimated Time of Departure is calculated.

Flight departing from an aerodrome outside the Controlled Airspace (inbound and overfligh flights)The algorithm defines the 2D flight path starting from the inbound Fix and compute its ETI (Estimated Time of Inbound). The calculation is performed in a spherical earth model.




Flight arriving at an aerodrome within the Controlled Airspace (domestic, local and inbound flights)The algorithm automatically assigns the proper STAR, if the aerodrome’s Arrival Automation Level is “STAR provided”, otherwise it recognises the airway’s leaving point, as laid down in the environmental data. The two dimensional path includes also points resulting from STAR breakdown or the airway’s joining point.

Flight arriving at an aerodrome outside the Controlled Airspace (outbounds and overflights)The algorithm defines the 2D flight path to the outbound Fix .

Route extraction algorithm allows route with multiple segments in AoI and AoR.

6.5.4 4D PROFILE CALCULATION

Starting from the two dimensional sequence computed by the Route Analysis and Extraction, the 4D Profile Calculation computes the trajectory profile, i.e. a four dimensional path giving for each point its Calculated Crossing Flight Level and the Estimated Time Over (ETO). The algorithm evaluates flight Top Of Climb (TOC), Top Of Descent (TOD) and the sector crossing points.The 4D Profile Calculation runs each time: the flight turns to the “pending” state; an existing “pending” SFPL is modified by a manual update or by the reception of an external

message containing route information; an order which modifies the route related items is issued for a “pending” SFPL; an order which modifies the route related items is issued for an “active” or “live” SFPL; an OLDI message which modifies the route related items is received for an “active” SFPL; a manual or automatic report is processed; a longitudinal non - conformance is detected by the Conformance Monitoring Function.

For each SFPL the profile calculation provides the following information: For each point given by the Route Analysis and Extraction the relevant Estimated Time Over (ETO)

and the Crossing Level are calculated by means of the information derived by the aircraft performance data (the aircraft take off weight is supposed as the 50% of the maximum value) and from the Planned level and the requested speed associated to the SFPL;

The Top Of Climb (TOC) and Top Of Descent (TOD) points with the associated 4D data; The traversed sectors list; The internal sector Coordination Points (as defined from FDE position) The Inbound Coordination Point The Outbound Coordination Point For each of the sectors to be traversed:

- the entry point, entry time, Planned Entry Level (PEL) and Supplementary Data on the Flight Level (if the aircraft crosses the sector climbing or descending);

- the exit point, exit time, Planned Exit Level (XFL) and Supplementary Data on the Flight Level (if the aircraft crosses the sector climbing or descending).




In case the crossing point (internal or external) is dynamic, i.e. the trajectory does not cross the boundary over a defined COP, the trajectory prediction is able to calculate the dynamic COP as range and bearing from the closest reference COP.The description of the algorithm behaviour follows the flight classification according to departure and destination aerodromes.




Flight departing from an aerodrome within the Controlled Airspace (domestic, local and outbound flights)The algorithm takes the 2D profile calculated by the Route Analysis and Extraction and completes data association to achieve the 4D Profile.The calculated 4D profile includes: Departure runway threshold point; Fixes already introduced in the route (identification, calculated level and ETO); Points expressed in the route by means of Latitude/Longitude Co-ordinates (calculated level and

ETO); Top Of Climb; Top Of Descent; Points resulting from break down of ATS routes(identification, calculated level and ETO); Points resulting from SID break down or airway’s joining point.

Flight departing from an aerodrome outside the Controlled Airspace (inbounds and overflights)The algorithm takes the 2D profile calculated by the Route Analysis and Extraction and completes data association to achieve the 4D Profile.Data relevant to the crossing flight level and the Estimated Time of Inbound on the Inbound Fix, received via ATS or OLDI messages or manually inserted, are considered as an input for the estimate on the next route points.

The calculated 4D profile includes: Inbound Fix (identification, calculated level and ETO); Fixes already introduced in the route (identification, calculated level and ETO); Points expressed in the route by means of Latitude/Longitude Co-ordinates (calculated level and

ETO); Top Of Climb; Top Of Descent; Points resulting from break down of ATS routes (identification, calculated level and ETO);

Flight arriving to an aerodrome within the Controlled Airspace (domestic, local and inbound flights)The algorithm takes the 2D profile calculated by the Route Analysis and Extraction and completes data association to achieve the 4D Profile.The calculated 4D profile includes: Inbound Fix (identification, calculated level and ETO); Fixes already introduced in the route (identification, calculated level and ETO); Points expressed in the route by means of Latitude/Longitude Co-ordinates (calculated level and

ETO); Top Of Climb; Top Of Descent; Points resulting from break down of ATS routes (identification, calculated level and ETO); Points resulting from STAR break down, or airway’s leaving point Arrival runway threshold point (or the aerodrome reference point, if the runway threshold is not

available)




Flight arriving to an aerodrome outside the Controlled Airspace (outbounds and overflights)The algorithm takes the 2D profile calculated by the Route Analysis and Extraction and completes data association to achieve the 4D Profile.If no data is inserted by the controller on the CWP, the Controlled Airspace exit level is calculated considering the planned flight level of the flight and its levelled, climbing or descending conditions.The calculated 4D profile includes: Fixes already introduced in the route (identification, calculated level and ETO); Points expressed in the route by means of Latitude/Longitude Co-ordinates (calculated level and

ETO); Top Of Climb; Top Of Descent; Points resulting from break down of ATS routes (identification, calculated level and ETO); Points resulting from STAR break down, or airway’s leaving point Outbound Fix (identification, calculated level and ETO)

The LFDPS performs recalculation of time information when a tactical time constraint has been applied.

6.5.5 SUSPENSION OF TRAJECTORY PREDICTION CALCULATION

The trajectory prediction algorithm is automatically suspended for flights entering holding (information of this event is obtained by means of the “Holding” order described in paragraph 6.4) or when an lateral deviation alert from Flight Progress Monitor is pending.Subsequently it is resumed upon report on the holding exit point or when the alert is cancelled.

6.5.6 UPPER WIND DATA

The upper wind data is stored into a 3-dimensional grid, together with their expiring time. The upper wind data is used while computing the flight trajectory, if not yet expired, otherwise is ignored. Details about the management of wind data are described in paragraph 6.1.




6.6 SFPL DATA DISTRIBUTION

6.6.1 FPPS TO LFDPS SYSTEM FLIGHT PLAN DISTRIBUTION

By the analysis of the route data contained in both RPLs and received ATS messages, the FPPS is able to compute the route extraction / trajectory prediction and consequently to recognize all the ATCUs interested by the pre-processed SFPL distribution which is realized a VSP time either before EOBT (departing flight) or ETI (inbound flight). In case of already distributed SFPL, if proper updates are received, the FPPS is responsible for the SFPL re-distribution to the concerned ATCUs.

Even though the main way of operating foresees the only FFPS to manage ATS messages, the LFDPs are allowed to create short flight plans (e.g. in case of FPPS failure) which have to be manually validated by the FPPS operators before final insertion.

At the start-up phase, the LFDPS asks, automatically, the FPPS for all the FPLs to be activated within a defined VSP interval.

In case of FPPS failure, the LFDPSs is able to perform the the FPLs insertion. At FPPS restore phase, the FPPS is able to realign its data bases with the LFDP ones.

6.6.2 FLIGHT PLAN DATA DISTRIBUTION FROM LFDPS TO USERS

The LFDPS is in charge of the SFPL information distribution to appropriate AWPs and to the other defined receivers (CWPs, external users, if any). This distribution is usually triggered by the occurrence of one or more of the following significant events:

An automatic or manual modification of the SFPL data. An automatic or manual change of the SFPL state. Eligible operator request.

SFPL data are internally distributed to all the CWPs controlling the sectors crossed by the flight path as calculated by the Trajectory Prediction function described in paragraph 6.5.

The capability of each AWP of accessing the provided SFPL data depends on the assigned Access Rights.

The SFPL data distribution to external adjacent ATCU is mainly carried out by means of OLDI messages.

The LFDPS also supports the delivery of flight information to facilitate internal co-ordination. When a flight is in proximity of the sector boundary, LFDPS automatically generates a warning to CWPs in order to advice the controllers of the accepting and transferring sectors to transfer the flight between them.




6.7SSR CODES MANAGEMENT AND ASSIGNMENT

6.7.1 GENERAL

The purpose of the SSR Codes Management and Assignment function is to handle SSR codes in accordance with ICAO Originating Region Code Assignment Method (ORCAM).It is assumed that the SSR Codes Management and Assignment function is split in the following modules: SSR Code Management, which is oriented to the definition of the classes of codes with the relevant

blocks of codes associated to each of them. SSR Codes Assignment, which is concerned with the assignment of SSR codes to flights according to

their characteristics (e.g. Departure Aerodrome, Destination Aerodrome, Route, etc.).The classes of codes to be assigned have been arranged in order to optimise the methods used when their association to a flight is to be performed.

6.7.2 SSR CODES MANAGEMENT

It is possible to store SSR Codes according to user definable categories:

The following states are considered for the SSR codes: Free State:

The code is ready to be assigned In use:

The code is currently assigned to a flight Unavailable:

The code is not ready to be assigned, even if it is not associated to any flight.




From "Configuration" Menu in FDE position it is possible to set the ORCAM rules for SSR code assignment. Each row, contained in the “SSR Slot Configuration” table, represents an ORCAM rule; FDP uses this rule for SSR code assignment.

In the SSR Slots Configuration the operator can select 4 subgroups and set each subgroup as follow:

SSR Code Slots, that shows all the configured ORCAM rules Fixes Groups, the operator can define group of fixes. Departure Groups, the operator can define group of Departure

Aerodrome/Country Destination Groups, the operator can define group of Destination

Aerodrome/Country

6.7.2.1 ORCAM Rules ADAPTATION

The operator can compose a rule selecting: In-Fix Gr.: list that contains all configured Fixes Group matching the SFPL Inbound

Fix Out-Fix Gr.: list that contains all configured Fixes Group matching the SFPL

Outbound Fix Dep. Group: list that contains all configured Departures Group matching the SFPL

ADEP Des. Group: list that contains all configured Destinations Group matching the SFPL

ADES FL Rule: list that contains the flight rules IFR/VFR or ANY matching the SFPL

Flight Rule Rule type: SSR allocation rule that identify if the SSR code is Retainable or

Allocatable Type of Flight: list that contains Military/Not Military or Any matching the SFPL

Flight Type




Category: list that contains all available ORCAM categories: Sub-Domestic, Domestic, Super-Domestic, transit, Super-Transit, Military, Other

OAT/GAT: list that contains OAT/GAT or ANY if GAT/OAT switches are in SFPL route field

SSR slot From: SSR code (four octal digit) SSR slot TO: SSR code (four octal digit) Time (min): insert time in the format hh:mm, time after SFPL termination taken into

account in order to release a code and provide it for re-assignment.

It is possible to include the same SSR code in more than one category.

After that all ORCAM rules are configured, for each SFPL, FDP checks if the SFPL is compliant with one configured rules (i.e.: FDP check if the inbound COP belongs to In-Fix Gr., if the outbound COP belongs to Out-Fix Gr., if the departure aerodrome belongs to Dep. Group, if the destination aerodrome belongs to Des. Group, if the FL Rule is IFR or VFR, if the previous code is retainable, if the flight is military or not, if the flight belongs to a configured category, if the flight is OAT or GAT). In case of the SFPL under analysis is compliant with an ORCAM rule then the first SSR Code free available in the slot.

For the Inbound and Overfly Flights categories, the Assignable SSR Codes is divided in the two following classes:

Allocatable SSR Codes class ; Retainable SSR Codes class.

For the Sub-Domestic, Domestic, Super-Domestic, Transit, Super-Transit, Military, the only Assignable SSR Codes class is the Allocated SSR Codes class

The Allocatable SSR Codes class is composed of all the SSR Codes which are eligible for assignment by the own ATS Unit: each allocatable slot is configured from FDA in descending order of priority.When an SSR is to be automatically assigned by the FDP (following a clearance, or OLDI message reception) the FDP assigns a code from the first allocatable slot whose rules match the flight plan and assigns the code that is available for assignment since the longest time.

The Retainable SSR Codes class is composed of all the SSR Codes slots which are eligible for retention for flights entering the Area of Responsibility: each retainable slot is configured from FDA in descending order of priority.If the SSR Code Received from the previous unit (via OLDI or via Phone) is found in one of the configured retainable slots and the flight plan matches the relevant slot rules then the FDP retains the PSSR in ASSR, otherwise the system shall assign a code from the proper configured allocatable slot (i.e. the allocatable slot whose rules match the flight plan)

The FDPS shall permit manual assignment of a specified SSR code, regardless if it is already configured in any slot, as long as it is in free state.




6.7.2.2 PSSR CODES ASSIGNMENT TO FLIGHTS

The FDPS assigns a PSSR code to an entering flight upon one of the following events: Reception of an ATS message with the SSR code indication for a SFPL in the Inactive or

Pending state; Reception of an OLDI ABI, ACT or PAC message with the SSR code indication for a SFPL in

the Inactive or Pending state;Manual insertion of the PSSR code by an eligible operator through the Wake-up order for a SFPL in the Inactive state.

The FDPS updates the PSSR code of an entering flight upon one of the following events: Reception of a OLDI REV message with the SSR code indication for a non-correlated SFPL in

the Active state;Manual modification of the PSSR code by an eligible operator for a SFPL in the Pending or Active state by means of the SSR Code Assignment order.ASSR CODES ASSIGNMENT TO DEPARTING FLIGHTS

The FDPS assigns an ASSR code to a departing flight upon one of the following events: Reception of an ATS message with the SSR code indication for a SFPL in the Inactive or

Pending state; Manual insertion of the ASSR code by an eligible operator for a SFPL in the Inactive state.

The FDPS updates the ASSR code of a departing flight upon manual modification of the ASSR code by an eligible operator for a non-correlated SFPL in the Pending or Active state.

The FDPS automatically assigns an SSR Code (ASSR code) to a departing flight, from those available in the proper flight category pool at the reception of a departure clearance or FFP order. The system assigns the first available SSR code of the eligible type for the flight, i.e. that one which has not been used for the longest time.The eligibility for departing flights is checked by FDPS by comparing the ADEP and ADES of the flight with those of the available SSR codes.

6.7.2.3 ASSR CODES ASSIGNMENT TO ENTERING FLIGHTS

The FDPS automatically assigns an SSR Code (ASSR code) to an entering flight, from those available in the proper flight category pool, at the reception of an en-route clearance order, or FFP, or OLDI ACT message.

If the entering flight in active status has already a previously assigned SSR Code (PSSR), the FDPS checks if that is a Retainable SSR Code or not, at the first clearance and following any change in PSSR code due to OLDI received messages (i.e. REV) or manual order (FFP).

If PSSR code is Retainable and it is not already assigned to another SFPL within the AoR, the FDPS assigns it to the SFPL as the ASSR, otherwise if the PSSR code is not Retainable or no PSSR code has been assigned to the SFPL, the FDPS assigns a new one.

When the FDPS has to assign a new code to an entering flight, it is the first available SSR code of the eligible type for the flight, i.e. the one which has not been used for the longest time.




6.7.2.4 SSR CODE DE-ASSIGNMENT AND ELIGIBILITY FOR RE-USE

The FDPS cancels the assignment of an SSR code to a flight upon one of the following circumstances: Reception of an SRL order;After the flight cancellation; After the assignment of a new code to the flight.

When an SSR Code is de-assigned, it assumes the "Unavailable" state and it is possible to change its state to free after a variable system parametric time (Protection Time defined for each SSR code pool).




6.8 FPL/TRACK CORRELATION

The objective of the SFPL/Track Correlation function is to logically associate surveillance data representing a track with a SFPL. This is achieved using the mode 3/A SSR code, which is common to both the track and the SFPL, as an association key.The establishment of correlation is done by scanning the uncorrelated tracks and the uncorrelated SFPLs eligible for correlation in search of matching codes. A SFPL becomes eligible for correlation if it contains a SSR code, either assigned by the system or assigned by another system such as the previous ACC system. The correlation process shall be triggered each time: A SFPL becomes eligible for correlation: this happens when a SSR code is stored in the SFPL during

the activation phase. In this case, the uncorrelated tracks are scanned to find a track with this code. A new track is created: the system scans the SFPLs to find a code identical to the state vector code.

A controller can also manually perform correlation. The operator uses the CWP HMI in order to designate a track and the SFPL with which it has to be correlated, in order to cater for:

More than one track fulfilling criteria for correlation Primary tracks A track with code 7700, 7600 or 7500 not previously correlated.

The track/SFPL correlation is also maintained when an aircraft changes its code to an emergency code (7500,7600,7700) or when it changes its code back from an emergency one to its assigned one.De-correlation occurs upon SFPL automatic or manual termination. Furthermore, the de-correlation upon system track loss is performed when the Surveillance System considers the track as no longer available. The track quality is managed by the Surveillance System.Manual de-correlation can also be performed. The operator uses the CWP HMI to designate either the track or the SFPL.




6.9FLIGHT LEVEL CO-ORDINATION

6.9.1 GENERAL

The “Co-ordination” function allows ground-ground co-ordination either between adjacent ATS units according to Eurocontrol Standards by means of OLDI (On Line Data Interchange) or between adjacent sectors belonging to the same ATS unit (i.e. XFL/PEL coordination).

The Cleared Flight Level shall be unique for all sectors and it can be modified only by the ATCO controlling the flight.

For the first sector (FIR incoming sector), the coordinated entry level (PEL) shall be either the one received in the ACT message or the one manually inserted by the clearance /EST order.

In case a manual coordination has not been performed yet, a VSP time before inter-sectors crossing point an automatic coordination procedure shall be finalised.

In particular:-If for a flight at least one coordination is not accepted (“Proposed” or “Modify”), the automatic coordination shall be inhibited till a manual action to accept the coordination is performed.-The values for automatic coordination of Entry/Exit flight level on SCL and FHI shall be set to:

i. For Inbound and Over-flights, the XLV (i.e. the sector boundary crossing level according to LFDP calculated trajectory).

ii. For Outbound, Local and Domestic flights, the Planned Flight Level (PFL) inserted by the Departure Clearance.

It shall be possible to configure Exit/Entry Sector couples for which automatic coordination shall be inhibited (AutoCoord Exceptions).

In case of manual XFL/PEL coordination between two or more sectors, the system shall allow the controller to re-coordinate the flight.

All the sectors for which the XFL/PEL value presented on the lists (FHI,SCL) comes out from the XFL/PEL propagation algorithm and not as a result of a real (manual/automatic) coordination shall have that value displayed in black as warning colour. As soon as the coordination is really finalised (manually/automatically), the XFL/PEL value shall be presented in the standard colour.

The evaluation of the predicted trajectory vertical profile as well as the updated list of the involved sectors shall be carried out taking into account the following constraints: position reports, XFL performed and aircraft performance, excluding the CFL. In particular, in case a XFL is performed in correspondence of a SID/STAR junction, the level to be used for trajectory calculation shall be according to the following rules:




1. if XFL<FL1701, the constraint to be applied in the predicted trajectory evaluation shall be the XFL itself.

2. if XFL>FL170, the constraint to be applied in the predicted trajectory evaluation shall be FL170.

1 Where 170FL is the maximum level (VSP) reached by a SID/STAR.




Taking into account a XFL/PEL coordination involving Sector A as proposing sector and Sector B as receiving sector, as the XFL proposal is issued by Sector A, the concerned flight shall be immediately presented in Sector B SCL to allow the proposal acceptance/rejection/counter proposal despite of the VSP time constraint for presentation. In case of rejection, if B was not a trajectory traversed sector, the flight shall be immediately removed from Sector B SCL, otherwise, the presentation shall be according to the standard VSP time constraint.

The flight level propagation shall be carried out according to the following rules:

Event Actions

OLDI ACT

RECEIVED

Over-flightsThe PEL of the receiving (first) sector shall be set equal to “Cleared

Level” sub-field of the estimated data field of the received message.

The SFL shall be set equal to corresponding field of the received

message (absent for levelled flights). The XLV of the LFDP

calculated trajectory shall be set as XFL/PEL for the downstream

sectors in “black”. If the time of ACT reception is within the VSP

time configured for auto-coordination and there is no “PROPOSED”

XFL set, auto-coordination shall be immediately triggered.

Arrivals

EST ORDEROver-flights

Same as OLDI ACTArrivals

XFL PROPOSED

XFL of the current sector and PEL of the next sector shall be set to the selected value. In

case the coordination between the downstream sectors is already established, it shall be

deleted and the corresponding fields on SCL and FHI shall be filled with the proposed

XFL value in “black”.

PEL ACCEPT

XFL and PEL relevant to the two sectors involved in the coordination shall be confirmed

and propagated to all the downstream sectors. If the time of acceptance is within the

VSP time configured for auto-coordination and there is no “PROPOSED” XFL set, auto-

coordination shall be immediately triggered.

XFL ACCEPT after

MODIFY

XFL of the current sector shall be set to the PEL value proposed by the next sector and

propagated to downstream sectors till the first coordination already established is found.

In case there is no coordination already established, it shall be propagated to all

downstream sectors. If the time of acceptance is within the VSP time configured for

auto-coordination and there is no “PROPOSED” XFL set, auto-coordination shall be

immediately triggered.

XFL/PEL REJECTThe proposed XFL shall be rejected, the co-ordination conditions previously established

between the two sectors shall be maintained.

DCL/DCR The values for automatic coordination of Entry/Exit flight level on SCL and FHI shall be

set to the Planned Flight Level (PFL) inserted by the Departure Clearance.

COO “Cleared Level” and “Supplementary Level” sub-field in the “Estimated Data” of the

related OLDI messages shall be set equal to XFL and SPL values of the COO order.




OLDI REV received

or RCL/RCR issue

Over-flights

1. The system shall erase all the internal co-ordinations already

performed and establish the new coordination according to

the new PEL value received.

2. In case an OLDI ACT has been already sent (automatic VSP

time), the new PEL value received shall be sent by an OLDI

REV.

3. In case a COO/XFL has been already manually performed

towards the down-stream macro-sector, the COO/XFL shall

be maintained.

ArrivalsThe PEL value shall be changed to the new value received and all

the co-ordinations already done shall be maintained

If coordination between the last two sectors in trajectory is initialised but not finalised yet and, at the same time, an ACT/REV message is automatically sent by the system, the coordinated level reported in the OLDI message shall be the one extracted from the new proposed trajectory.

In case of any trajectory re-calculation caused by the coordination flight level changing, if an ABI message has been already transmitted but no ACT has been sent yet, a revised ABI shall be transmitted with the coordination flight level calculated by the new trajectory.

The color of XFL in SCL and FHI shall be maintained “black” till the ACT is sent.

In case of any trajectory re-calculation forced by inter-sector coordination causing the vertical profile to be changed, if an ACT message is already transmitted, the system shall maintain the coordination level previously sent via ACT, transmit a REV and display the SFL (Supplementary Flight Level) resulting from the new trajectory calculation.

In case a COO is performed, the coordination level input by COO shall be used as a constraint for any trajectory re-calculation and transmitted via OLDI.




6.9.2 OLDI COORDINATION

LFDPS is able to automatically receive, process, store, deliver for display and transmit in real-time information related to the following messages:





DIALOGUE PROCEDURE - COORDINATIONReferred Activate Proposal Message (RAP)Referred Revision Proposal Message (RRV)Stand-by Message (SBY) Acceptance Message (ACP) Co-ordination Message (CDN) Reject Co-ordination Message (RJC)


The above messages allow the accomplishment of the “full procedure of notification, co-ordination and transfer of communications,” with the dialogue possibility between the transferring and accepting ATS Units and between civil and military units.




It’s possible to configure up to 32 different remote ATS unit (civil or military) for OLDI messages exchange. For each remote ATS Unit the messages to be transmitted and received can be configured. For each remote ATS unit it’s possible to configure the protocol and format of the messages to be exchanged (ICAO or ADEXP or BOTH and X25 or TCP/IP) and the maximum length of each OLDI message.For each remote ATS unit it’s possible to set the optional fields for each exchanged message separately, in ICAO or ADEXP format. The system is able to set some parameters in order to ensure automatic initiation of OLDI messages, such as the following:a) transmission time before flying over the COP, where applicable;b) distance before the COP to transmit the message, where applicable; c) time after message transmission within an application level acknowledgement is to be received

(time-out);d) time/distance before the COP after which coordination messages has to be considered non-

standard;e) levels relevant to the COP, over which the coordination messages has to be considered non-

standard. f) In case a COP is configured with strategic constraints the constraints will be applied, unless

overridden by a manual order (tactical constraint)

Moreover, the capability to manually initiate the transmission of a co-ordination message prior to the calculated transmission time is provided.The received OLDI messages are processed automatically and their information are used to update the related SFPL. OLDI message data are displayed to the controller working position together a warning indication in case of inconsistency of the received data.An acknowledgement message, Logical Acknowledgement (LAM), or Stand by (SBY) if further messages have to be transmitted, in order to accept (ACP), reject (RJC) or counter propose (CDN only for the accepting unit) the entry/exit conditions , is generated and transmitted when the corresponding message has been processed. If no related flight plan is found in Database upon reception of correct OLDI messages (e.g. received ABI, ACT or RAP) SFPL are created directly in pending or active status with the content of the messages and are highlighted to the relevant operator.Additionally the system supports the phone co-ordination (i.e.: PCO phone co-ordination order) reminder and order in case the connection is simulated (No real OLDI connection with that partener): in this case for each COP it’s possible to configure a time parameter before COP to remind the controller to perform a phone coordination. The Upstream Controller is enabled to issue a Phone Co-ordination order (PCO 1), to set the proposed coordination conditions to the next Adjacent Unit. Moreover the FDP reports missing or invalid sequence numbers in received OLDI messages.

1 The Phone Co-ordination order is available on the CWP and FDA.




6.9.2.1 Co-ordination Points Definition

6.9.2.1.1 COP Configuration

The Co-ordination Points logically represent the interface with the adjacent ATS Units and they are used to reflect the contents of the Letter of Agreement (LoA). Their definition deals with either the indication of the point and the assignment of the adjacent ATS Unit Identifier, the messages to be transmitted/received for that point, the parameters that regulate message transmission and the conditions for revisions. The system allows to define COPs having the same latitude and longitude co-ordinates but related to different altitude level ranges. In this way they can refer to different adjacent ATC Units.For each COP it is possible to define different time-out values for the acknowledgement to all transmitted messages. For each COP it’s possible to set different parameters for message transmission, acknowledgment or operational time-out for each message, revision threshold, type of COP (inbound, outbound, reference).The system allows to calculate Dynamic COPs for all flights entering or leaving the ATS Unit’s AoR on routes (either ATS routes or direct route segments) not containing published COPs: the calculated Dynamic COP is the point of boundary to be referred in the OLDI messages relevant to that flight, expressed as a bearing and distance from the closest bilaterally agreed point both for entering and exiting flights.

6.9.2.2 The Filter

The co-ordination dialogue procedure requires that the system is able to identify whether or not flight transfers are in accordance with some predefined "standard conditions" . The process, which checks such compliance, is referred as "the filter". In the transferring unit, the system sends OLDI messages for co-ordinations which are known to be standard (ACT/REV message type) and messages known as non-standard (RAP/RRV message type): the latter messages are referred to the accepting controller for a decision.The following data structure is considered to implement “the filter” conditions.

Conditional Data Check

ADEP ADES COP Aircraft Type

Standard levels or

level bands

Min/Max Time/distance

Prior to the COP;

It’s possible to assign special values (“Wild Cards”) to the “Conditional Data” fields. In this case the check will be performed according to the values in the remaining “Conditional Data” fields.




6.9.2.3 Notification Messages

6.9.2.3.1 Advance Boundary Information Message (ABI)

One or more ABI messages can be sent for each IFR flight, planned to cross the boundary of area of responsibility subject to OLDI procedures, in order to provide advance boundary information and revisions to the next ATC Unit.The ABI message is automatically transmitted a parameter number of minutes before the estimated time at the COP.A revised ABI message is sent if the subsequent ACT message has not been transmitted and one of the following condition occurs: the route of flight has been modified such that the COP in the previous ABI message is no longer the

same but the destination ATS Unit does not change; the aerodrome of destination has been changed; the type of aircraft has been changed; the expected boundary crossing level has been changed for a value that is greater than the COP flight

level variation threshold; the estimated time over the COP differs from the previous ABI message more than the COP ETO

variation threshold; the expected SSR code at the transfer of control point has been changed; the equipment field (i.e.: 8.33 and/or RVSM capability and status) is modified

When an ABI message is received, a syntactical check is performed and association with the corresponding flight plan data is attempted: if no discrepancy is found, a LAM is transmitted to the sender, the SFPL is updated with the message data and the SFPL is turned to the “pending” state. If there is no SFPL referring to the received ABI, a flight plan is created automatically in the “pending” state.When association with the corresponding SFPL cannot be achieved a flight plan is automatically created in the “pending” state; if any error is found, the ABI message is sent to a “Wrong OLDI Message Queue” for subsequent manual corrections or rejection.

6.9.2.3.2 Preliminary Activate Message (PAC)

The PAC message is used to perform notification and pre-departure co-ordination of a flight where flight time from departure to the COP is less than it is required to comply with the agreed time parameters for ACT message transmission.A revised PAC message is transmitted if, before departure (before Take Off report), any of the conditions described in the previous paragraph for the revised ABI transmission, are verified.When a PAC message is received, syntactical checks are performed and association with the corresponding flight plan data is attempted. if any error is found, the PAC message is sent to a “Wrong OLDI Message Queue” for subsequent manual corrections or rejection If the flight plan association is unsuccessful, and the flight is entering the area of responsibility of the ATS Unit involved, a flight plan is automatically created in the “pending” state. When association with the corresponding flight plan is




successful and no discrepancy is found, a LAM is transmitted to the sender, the SFPL is updated with the message data and it is turned to the “pending” state.

6.9.2.4 PRE-DEPARTURE CO-ORDINATION MESSAGES

6.9.2.4.1 Clearance Request Message (CRQ)

A CRQ message is sent by the Aerodrome/Approach unit to the next unit for each departing flight for which a departure clearance approval is required by means of a dedicated manual order (departure clearance mask with approval request check box filled)A revised CRQ message is sent if the departure runway, the SID, COP or route was included in the previous CRQ and the departure runway to be used by the flight has been changed or the SID, COP or route has been changed, or Estimated Take-Off Time has changed by more than a parameter time.If no SBY message and CRP are received as an acknowledgement and reply for a CRQ message, a warning is displayed at the position in the ATC unit responsible for co-ordination with the next unit and verbal co-ordination is initiated.

The ATC system receiving a CRQ message attempts association with the corresponding flight plan.If a corresponding flight plan is found and no discrepancy is present in the message that would inhibit correct processing, the clearance request is made available at the first sector in trajectory and a Standby (SBY) message is returned. If any error is found the message is rejected for further manual processing or deletion.If the CRQ message includes a request for the assignment of an SSR code and a SBY has been issued in response to the CRQ, an SSR code is assigned

6.9.2.4.2 Clearance Response Message (CRP)

A Clearance Response (CRP) message is manually generated in response to a received CRQ which has not been superseded by a subsequent CRQ messageThe ATC system receiving a CRP message attempts association with the corresponding flight plan (for which the CRQ was sent). If a corresponding flight plan is found and no discrepancy is present in the message that would inhibit correct processing, the clearance response content is made available at the CWP, the SFPL is updated and a LAM message is returned. If any error is found the message is rejected for further manual processing or deletion.

6.9.2.5 COMPLEMENTARY MESSAGES

6.9.2.5.1 SSR Code Assignment Message (COD)

The COD message satisfies the operational requirement for the issue of a Mode A SSR code by an Air Traffic Service Unit to another for a specified flight when requested.




The request for the assignment of an SSR code (by means of the “A9999” string in the SSR code field) is included into PAC message. If the received PAC message includes this request and no discrepancy is found, then a COD message is generated and transmitted automatically. The SSR code included in the COD message will be assigned to the flight and acceptance of the SSR code by the unit receiving the COD message is assumed.When a COD message is received, if a relevant flight plan with the string “A9999” in the SSR code field is found, and the Departure Clearance has not yet been issued by the transferring controller on that flight, the SSR code contained in the COD message is assigned to the SFPL and a LAM is returned.

6.9.2.6 Coordination Messages

6.9.2.6.1 Activate Message (ACT)

The ACT message satisfies the following operational requirements:

a) to replace the verbal boundary estimate by transmitting automatically details of a flight from one ATC Unit to the next before the transfer of control;

b) to update the basic flight plan data in the receiving ATC Unit with the most up-to-date information;

e) to provide transfer conditions to the receiving ATC Unit.

The ACT message is generated and transmitted automatically at a calculated time or distance from the COP, for flights in “active” or “live” state which are going to cross the boundary. Moreover, the operator can manually trigger its transmission prior to the calculated time. As soon as the acknowledgement has been received, the co-ordinated transfer conditions are displayed to the controller.When the ACT message is received, a syntactical check is performed: if it is successful, the association with the relevant flight plan is attempted. If the flight plan association is unsuccessful, but the flight is entering the area of responsibility of the ATS Unit, a flight plan is automatically created in the “active” state. It is a “limited FPL” if some information is missing. Otherwise the message is sent to the “Rejected messages queue” for manual handling and no LAM is delivered.When association with the relevant flight plan is successful and no discrepancy is found, a LAM is transmitted to the sender, the SFPL is updated with the message data and the SFPL is turned from the “inactive” or the “pending” state to the “active” state.

6.9.2.6.2 Referred Activate Proposal (RAP)

A RAP message is sent in place of the ACT message, for flights crossing the boundary, if the transfer conditions are found to be non-standard or if the transferring controller has indicated that the proposed transfer conditions are to be referred to the accepting controller (forced RAP).




When a RAP message is received, a syntactical check is performed and the association with the relevant flight plan is attempted: if no SFPL is found a SFPL is created in active status and a SBY is transmitted; if no discrepancy is found and the relvant SFPL is found, a SBY is transmitted to the sender, the SFPL is updated with the message data and the SFPL is automatically turned from the “inactive” or the “pending” state to the “active” state. The accepting controller is enabled to accept, reject or negotiate the proposed transfer conditions.

6.9.2.6.3 Revision Message (REV)

The REV message is used from transferring unit to transmit revisions to co-ordination data previously sent by ACT message.

One or more REV messages may be sent for IFR flights, planned to cross the area of responsibility, to the unit which flight has been previously co-ordinated by the ACT message when one of the following condition occurs: flight route has been modified such that the COP in the previous PAC message is no longer the same

but the flight destination ATS Unit does not change; expected boundary crossing level has been changed to a value that is greater than the COP flight level

variation threshold; estimated time over the COP differs from the previous ACT message more than the COP ETO

variation threshold; the expected SSR code at the transfer of control point has been changed the equipment field (i.e.: 8.33 and/or RVSM capability and status) is modified.

The REV message transmission is event driven and the message is immediately generated following any change to the one of the fields formerly indicated, in order to reflect a bilateral agreement. It’s possible to configure each remote ATS until in order to warn the controller whenever the conditions for REV transmission occur: in this case a reminder is given to last sector CWP and the REV message is sent only after manual controller confirmation.When a REV message is received, a syntactical check is performed: if any error is detected, the message is forwarded to the “Rejected messages queue”.If syntactical analysis is successful and the association with the relevant flight plan is successful, a LAM is transmitted and the received information are used to modify the relevant SFPL data.

6.9.2.6.4 Referred Revision Proposal (RRV)

A RRV message is sent in place of the REV message, for flights crossing the boundary, if the transfer conditions are found to be non-standard or if the transferring controller has indicated that the proposed transfer conditions are to be referred to the accepting controller (forced RRV). When a RRV message is received, a syntactical check is performed and the association with the corresponding flight plan is attempted: if no discrepancy is found, a SBY is transmitted to the sender, and the accepting controller is enabled to accept, reject or negotiate the proposed transfer conditions.




6.9.2.6.5 Accept message (ACP)

An ACP message is generated and transmitted by means a dedicated manual order when the accepting controller elects to accept the proposed transfer (entry) conditions or when the transferring controller elects to accept the counter-proposed transfer (exit) conditions.When an ACP message is received, a syntactical check is performed and the association with the relevant flight plan is attempted: if no discrepancy is found, a LAM is transmitted to the sender, and the proposed transfer conditions are updated for the relevant SFPL.

6.9.2.6.6 Reject message (RJC)

A RJC message is generated and transmitted by means a dedicated manual order when the accepting controller elects to reject the proposed transfer (entry) conditions or when the transferring controller elects to reject the counter-proposed transfer (exit) conditions.When a RJC message is received, a syntactical check is performed and the association with the corresponding flight plan is attempted: if no discrepancy is found a LAM is transmitted to the sender, and the actual coordination conditions are abrogated.

6.9.2.6.7 Coordination message (CDN)

The CDN message is sent by means a dedicated manual order when the accepting controller elects to forward a counter proposal to the transferring controller as a reply to RAP/RRV or to a ACT/REV with non-standard conditions.When a CDN message is received, a syntactical check is performed and association with the corresponding flight plan is attempted: if no discrepancy is found, a SBY is transmitted to the sender, and the transferring controller is enabled to accept or reject the counter proposed transfer conditions.

6.9.2.7 Acknowledgement MessageS

6.9.2.7.1 Logical Acknowledgement Message (LAM)

The LAM is the message by which the reception and safeguarding of a transmitted message is indicated to a sending unit. The LAM message is generated and transmitted immediately without human intervention according to the rules specified for each message. For LAM message no acknowledgement is expected.Every time that the system expects a LAM as acknowledgment for a transmited message and the LAM is not received within the relevant time-out (configurable for each COP and each message) a warning to adapted position(s) is sent.

6.9.2.7.2 Stand-by Message (SBY)




The SBY message acknowledges the reception of a message proposing transfer conditions and indicates that the proposal is being referred to the controller for a decision. The SBY message is generated and transmitted automatically immediately in response to a RAP, RRV or CDN message or to an ACT or REV message which fails the filter. For the SBY message no acknowledgement is expected.

6.9.2.8 Transfer of communications messages

6.9.2.8.1 Transfer Initiation Message (TIM)

The purpose of the TIM message is to signify the Transfer Initiation (TI) event (the end of the co-ordination phase and the start of the transfer phase) and to forward executive control data from the transferring to the accepting unit at a bilaterally agreed time/distance of the flight from the boundary.

When a TIM message is received, a syntactical check is performed and association with the corresponding flight plan is attempted: if no discrepancy is found, a LAM is transmitted to the sender, and the SFPL is updated with the message data.

6.9.2.8.2 Supplementary Data Message (SDM)

The primary purpose of the SDM is to transmit control data and changes from the transferring unit to the accepting unit, provided that it has been bilaterally agreed that the changes do not need to be acknowledged by the accepting controller. The SDM message, may also be used by the accepting unit to notify the transferring unit of the radiotelephony frequency to which the flight is to be transferred.SDM message is transmitted after the initiation of the transfer phase, following any change of the tactical constraints (cleared flight level, assigned speed, assigned rate of climb/descent, assigned heading).When a SDM message is received, a syntactical check is performed and association with the corresponding flight plan is attempted: if no discrepancy is found a LAM is transmitted to the sender, and the SFPL is updated with the message data.

6.9.2.8.3 Hand-Over Proposal Message (HOP)

The purpose of the HOP message, manually initiated by the transferring controller, is to draw the attention of the accepting controller to a specific flight for handover purposes and to transmit the tactical constraints ( cleared flight level, assigned speed, assigned rate of climb/descent, assigned heading).When an HOP message is received, a syntactical check is performed and association with the corresponding flight plan is attempted: if no discrepancy is found a LAM is transmitted to the sender, and the SFPL is updated with the message data.

6.9.2.8.4 Request on Frequency Message (ROF)




The ROF is sent by the accepting unit (manually initiated by the controller) to the transferring unit, when required, requesting the transferring controller to instruct the aircraft to change to the frequency of the accepting controller. The message may be used in reply to a HOP to signify the acceptance of the flight under the proposed conditions or to request the early transfer of the flight.When a ROF message is received, a syntactical check is performed and association with the corresponding flight plan is attempted: if no discrepancy is found a LAM is transmitted to the sender, and the SFPL is updated with the message data.

6.9.2.8.5 Change of Frequency Message (COF)

The COF is sent manually by the transferring unit to the accepting unit, to indicate that the flight has been instructed to contact the accepting controller.The use of the COF message is mandatory if, by bilateral agreement, the MAS message is not used.When a COF message is received, a syntactical check is performed and association with the corresponding flight plan is attempted: if no discrepancy is found a LAM is transmitted to the sender, and the SFPL is updated with the message data.

6.9.2.8.6 Manual Assumption of Communications Message (MAS)

The MAS is manually sent by the accepting unit to the transferring unit indicating that two-way radio contact has been established with the flight.The use of the MAS message is mandatory if, by bilateral agreement, the COF message is not used.When a MAS message is received, a syntactical check is performed and association with the corresponding flight plan is attempted: if no discrepancy is found a LAM is transmitted to the sender, and the flight is transferred (closing of the transfer of communication phase).




6.9.2.9 Message for the Abrogation of Co-ordination (MAC)

The MAC message is used to notify the receiving unit that the co-ordination or notification previously effected for a flight is being abrogated.A MAC message is sent to a unit to which notification or co-ordination had previously been effected for a flight by means of an ABI/PAC or an ACT/RAP or REV/RRV message, when one of the following event occurs: the expected level at the transfer point is different from the level contained in the previous message; flight route has been altered and the result is the change of the next unit in the co-ordination sequence; the system flight plan is cancelled in the sending unit and the co-ordination is no longer relevant; a MAC is received from the previous unit relevant to the flight.

The MAC message transmission is event driven and the message is immediately generated following any change to one of the fields formerly indicated.When a MAC message is received, a syntactical check is performed: if the analysis is successful and association with the corresponding flight plan is successful, a LAM is transmitted and the referred SFPL co-ordination is abrogated.

6.9.2.10 Ground – GROUND SITUATIONAL Awareness

6.9.2.11 Information Message (INF)

The INF message is used to provide information on specific flights to agencies not directly involved in the co-ordination process between the ATC unit and its co-ordination partners on the flight route.The INF message may be used to provide copies of OLDI messages (transmitted and/or received) and to communicate agreed co-ordination conditions to such agencies following a dialogue between controllers. For this purpose INF message may be generated by the system at the transmission or the reception of OLDI message. Each INF message is transmitted to the configured ATC units (civil or military).

6.9.3 EST ORDER

The EST order form is issued (from FDE and/or CWP PLN) to manually simulate the effect of the reception of an ACT message.

As soon as the Flight Identification field is filled and activated (e.g. clicking the ENTER button), the system verifies in the SFPL data base the presence of a SFPL characterized by that CALLSIGN. If at least one SFPL is found, the remaining fields of the EST order form are filled by the relevant fields of the selected SFPL. Successively, the operator is allowed to modify all the fields in the form.When the empty EST order mask is recalled with the possibility of multiple FPLs selection, the operator shall be allowed to have the form filled not only with data of the first FPL proposed (i.e. the first entering the FIR) but also with the information concerning all the other FPLs complying with the CALLSIGN




“key characters” inserted. The “Previous and Next” FPL scrolling shall be achieved by clicking on two dedicated buttons on the mask.If none FPL characterized by a CALLSIGN coincident to the one input in the relevant EST order field is found, the operator is enabled to insert the EST order missing data. As soon as the input is completed and confirmed, the data shall be sent to the FPPS repairing positions both to perform the route insertion (according to ADEP and ADES) and to obtain the necessary clearances.

Depending on the result of the research carried out on the SFPLs, the system shall perform the following actions:

Research Result

Entry Point Elaborations

Positive Unchanged The SFPL shall be modified using the values input by the operator and in case the flight is OLDI coordinated, the relevant message shall be managed.

Negative Whatever it is The SFPL shall be sent to the FPPS using the same procedure used for the short flight plans.




6.10 SUPERVISION

6.10.1 GENERAL

Most of the functions performed by the LFDPS/FPPS refers to system parameters and to configuration features.Also the orders enabled for each AWP user are based upon Access Rights previously defined. The operations relevant to these features are handled by the technical supervisor by means of the LFDP/FPPS supervision console as described in the subsequent paragraphs.The operations of the technical supervisor on the supervision console are enabled only if the LFDPS/FPPS is in the Operational “Idle” state apart from the transition from “Operative” to “Idle”.

6.10.2 NODE ROLES SWITCH

The LFDPS/FPPS technical supervisor is provided with a manual order to switch the nodes role. This order is enabled only if both the server computers are available (i.e. the working node is Master and not Master_Alone), and can be performed from the CMS too.The LFDPS/FPPS Supervisor is provided with manual orders to put the Master (or Master_Alone) node in either Idle or Operative state.

6.10.3 ACCESS RIGHTS

The LFDPS/FPPS maintains a list of FDE operator types and enables the Supervisor, who always has full power, to update the access rights to each FDE operator type on each LFDPS/FPPS mask.It is possible to assign different Access Rights to each potential user of a LFDPS/FPPS Client position and it must be related to the required functions assigned to the operative role. Different profiles can be defined (e.g Flight Data Operator, ATC Operator, etc.) and the profile name defines the key for Access Rights profiles database. Thus, the Access Rights keys are linked with the inserted User name. For each operational item and for each Access Right profile one or more of the following actions can be authorised: R : READ-OPEN FORM-BROWSE-CHECK I : ADD-INSERT-COPY-OK M : UPDATE-MODIFY-ORDERS D : DELETE P : PRINT A : AFTN Message Transmission

6.10.4 LOG & BACK UP FUNCTIONALITY

A log functionality is implemented in the LFDPS and the FPPS with the aim of recording the history of all FPLs modifications introduced by the operators, including the time and the operator who performed the action. Furthermore, the FPPS provides the FDE with a proper procedure to perform the database back-up on a DAT drive (in TAR format).




6.10.5 LINES CONFIGURATION

For every serial channel (i.e. the AFTN connection and the Physical layer of the OLDI connection) the following fields can be used for lines configuration: Com Port Protocol Baud Rate Data Bits Stop Bits Parity Input CID Output CID LFDPS Address Destination Address

For the Data Link layer of the OLDI connection the following fields can be used for lines configuration: Operation (DTE/DTE or DTE/DCE) Maximum number of bits in an I-frame Maximum number of outstanding frames

For the Network layer of the OLDI connection the following fields can be used for lines configuration: Default packet size (sending) Default packet size (receiving) Default window size (sending) Default window size (receiving)

6.10.6 SSR SLOTS ASSIGNMENT

The Technical Supervisor can perform the assignment of the SSR Codes slots for each flight category according to the rules described for the SSR Codes Management in paragraph 6.7.2 from the LFDPS supervision console when the system is in “idle” state by means of a user friendly interface.

6.10.7 MANAGEMENT OF SECTOR ASSIGNMENT

Sectors assignment is a facility controlled at system level. The sectors re-allocation starts from a default configuration, established at the system start up according to a configuration file. From this point it is possible to assume from one sector the responsibility of control of an entire sector formerly assigned to another position.When a re-allocation of operators is initiated, the LFDPS carries out verification and, after having completed all the checks, carries out the necessary re-distribution of FPL information to the correct positions.




6.11 INTEGRITY AND SECURITY

6.11.1 SFPL DATABASE ALIGNMENT

The LFDPS is able to run fully integrated with RDP and CWPs. Whenever the system transits from the “Idle” to the “Operative” state or after a period of unavailability of the connection with RDP the SFPL database is re-aligned by means of a communication session established with the ACD CSCI and already described in paragraph 4.2.The database alignment avoids data replication. In such a case a data recovery policy is followed.

6.11.2 DATA INTEGRITY

The LFDPS/FPPS database is relational, i.e. based on a RDBMS (Relational Data Base System) to ensure the data integrity from erroneous modifications or cancellations (e.g. the cancellation of a basic element is avoided if this is used to build higher level elements).

6.11.3 ELIGIBILITY

More than one operator is enabled to interact with the system but different type of AWP operators may not have the same access rights.Two type of access rights are distinguished: access rights to data items (e.g. environmental data or SFPLs) access rights to actions on SFPLs, e.g. enabling some operations and not others on the basis of the

FPL state and the operation itself, as already described in paragraphs 6.3 and 6.4 where orders have been listed for each SFPL state.

The LFDPS/FPPS maintains a list of operator profiles and provides an access control system, based on a login procedure. The operators are enabled to log into the system only providing a valid Username, i.e. an existing operator name, otherwise the access is denied. The assignment of the access rights is made by the LFDPS/FPPS Technical Supervisor.The LFDPS/FPPS also maintains a list of masks which the operators could recall to interact with the system.Access right on each mask to each operator type can be controlled. The LFDPS/FPPS Technical Supervisor always has full power.




7. ADDED FUNCTIONS DESCRIPTION

7.1 CONFORMANCE MONITORING FUNCTION

7.1.1 GENERAL

The LFDPS performs Conformance Monitoring Function, in order to provide other LFDP functions and operators with information regarding whether the actual progress of flights matches the expected. The Conformance Monitoring Function detects deviations between the actual position of the flight and its expected position as calculated by the trajectory prediction. The longitudinal deviations are considered in order to re-calculate ETOs and co-ordination events. The lateral deviations are taken into account because if the flight deviates far enough from its expected route, the ETOs may not be reliable. The vertical deviations are to be considered because such deviations can change the list of sectors to be crossed.The system compares the actual position of the aircraft calculated by the RDP System and the calculated position derived from the SFPL. If a longitudinal deviation is found to exist, the SFPL trajectory is re-calculated accordingly, but if longitudinal deviations lead to a significant time non conformance, updates are suspended until either the time deviation becomes acceptable or the controller modifies the SFPL route. If the lateral or vertical deviation from expected route and levels is greater than a VSP, updates are suspended until either the deviation becomes acceptable or the controller modifies the SFPL route.Automatic reports on fixes are also performed in order to follow the progress of the flight along the expected flights.The comparison between the expected and the actual flight position is not performed only on the points extracted by the Route Analysis and Extraction function, but also along the segment between two of them. Thus, also direct route segments, internals to the Controlled Airspace are checked. A sampling on the route segments is performed and the sampling period is a VSP time.

7.1.2 DEVIATIONS DETECTION

Conformance Monitoring Function automatically performs deviations detection for eligible flights according to the availability of data from Trajectory Prediction and other data sources. All flights eligible for trajectory prediction are eligible for deviations detection.The LFDP System checks the "matching" of a radar track with the cleared route and is able to detect the following deviations:- Lateral deviation: it is detected whenever a flight’s current track position is further than a lateral

deviation threshold parameter from the corresponding SFPL expected position as calculated by the Trajectory Prediction.

- Longitudinal deviation: it is detected whenever a flight’s current track position is further than suitable longitudinal deviation threshold parameters from the corresponding SFPL expected position as calculated by the Trajectory Prediction.Two classes of longitudinal deviations are considered by the Conformance Monitoring Function in order to distinguish between non conformance deriving from a transitory flight behaviour and an actual longitudinal deviation non conformance. They are:- Longitudinal distance deviation, and- Longitudinal time deviation.




A longitudinal distance deviation is detected whenever a flight’s current track position is further than a threshold parameter expressed in nautical miles from the corresponding SFPL expected position as calculated by the Trajectory Prediction. Each time a longitudinal distance deviation is detected, the equivalent time which is requested to cover the distance which separates the actual and the expected position is calculated and stored. It is indicated as “Partial Time Deviation” and will be used in the longitudinal time deviation calculation. A longitudinal time deviation is detected if the sum of the Partial Time Deviations is greater than a VSP time threshold.

- Vertical deviation: it is detected whenever the flight current altitude differs by more than a threshold parameter from the expected altitude, considered as follows: Climb Phase:

if the actual flight level is greater than the CFL plus the threshold parameter, a vertical deviation is declared.if the CFL is greater than the actual flight level, a vertical deviation is declared if the actual flight level is greater than the corresponding calculated flight level plus the threshold parameter.The calculated flight level origins from the Trajectory Prediction for flights planned to climb or to descent.

Descent Phase:if the actual flight level is lesser than the CFL plus the threshold parameter, a vertical deviation is declared.if the CFL is lesser than the actual flight level, a vertical deviation is declared if the actual flight level is lesser than the corresponding calculated flight level plus the threshold parameter.

En-Route Phaseif the actual flight level differs from the CFL for more than the threshold parameter, a vertical deviation is declared.

Deviation Detection functions can be enabled/disabled according to the following criteria: Sectors

For each sector type (e.g. APP, ACC) defined in the system configuration database it is possible to indicate if the function is to be performed or not.

Departures/ArrivalsFor each SID/STAR defined in the LFDPS/FPPS Environment database it is possible to indicate if the function is to be performed or not.

Phase of FlightFor climbing or descending flights, it is possible to indicate if the function is to be performed or not.




7.1.3 AUTOMATIC REPORT ON FIX

The LFDPS compares the current flight data received from the surveillance system, with the system trajectory. When the Estimated Time Over a “reporting fix” for a given FPL approaches, it opens a 3D window around the point, whose size is a system parameter. If the system track correlated with that FPL falls into the window, the system automatically “reports” that fix and triggers trajectory prediction for estimating times and levels on the next points in the FPL route.

7.1.4 ALERT GENERATION AND TRAJECTORY RE-CALCULATION

Conformance Monitoring Function generates an alert to the responsible operator in the following circumstances:- Lateral deviation;- Vertical deviation;Updates are then suspended until either the deviation becomes acceptable or the controller modifies the SFPL route. The existing correlation with the radar track is kept unless a de-correlation order is issued.For eligible flights, Conformance Monitoring Function requests re-calculation of trajectories when a longitudinal distance deviation is found, but the longitudinal time deviation is not reached. In this way, trajectory updates are continuously performed but non conformance situations are as well revealed.




7.2 GAT/OAT AND IFR/VFR MULTIPLE SWITCHES

7.2.1 ROUTE ANALYSIS

The FPPS/LFDP recognizes and process multiple GAT and OAT switches in the SFPL route field. If the route field contains more than one GAT/OAT switch the FPPS/LFDP accepts the SFPL only if these switches are alternate in the route:- the FPPS/LFDP rejects SFPL with route containing two subsequent GAT switches- the FPPS/LFDP rejects SFPL with route containing two subsequent OAT switchesThe FPPS/LFDP recognizes and process multiple IFR and VFR switches in the SFPL route field; if the route field contain more than one IFR/VFR switch the FPPS/LFDP accepts the SFPL only if these switches are alternate in the route:- the FPPS/LFDP rejects SFPL with route containing two subsequent IFR switches- the FPPS/LFDP rejects SFPL with route containing two subsequent VFR switches.If the route field contain more than one IFR/VFR switch the FPPS/LFDP accepts the SFPL only if- the Flight Rules is “Y” and the first route segment is IFR- the Flight Rules is “Z” and the first route segment is VFRFor VFR flights the FPPS/LFDP extracts only the first and the last AoR point of the route if the route is correctly expressed, otherwise if the route is not correct or not expressed the FPPS/LFDP extracts the first and the last AoR way-points planned to be traversed, calculated from the expressed Aerodrome of Departure (ADEP) and Aerodrome of Destination (ADES) couple. For flights containing one or more VFR/IFR switches in the route field the FPPS/LFDP extracts the complete route but only the first and the last point of each VFR segment of the route couple will be distributed to the system for graphic display, if any GAT/OAT switch is present in a VFR segment of the route, these switches will be not taken into account by the FPPS/LFDP. A dedicated order form (i.e.: SFPL updating for SFPL in inactive/pending state or RCR order for SFPL in active or live) will permit to the controllers who are enabled to perform this order, the flight rules (IFR/VFR) and flight type changing (OAT/GAT), associated to a specific point (one or more) along the route. For the IFR flights, every time that the route field is changed, for each point in the route field the FPPS/LFDP identifies if any change of flight rule switch or flight type switch has been performed.

7.2.2 DISTRIBUTION

7.2.2.1 IFR Flight Data Distribution

For IFR flights the distribution is performed to all the sectors crossed by the trajectory, the distribution sector chain will be identified using the trajectory and the GAT/OAT switches in the route field:- for IFR flights Type M and GAT the distribution shall be performed to civil sectors.- for IFR flights Type M and OAT the distribution shall be performed to MEA sector. For IFR flights the FPPS/LFDP categorises each route segment of the trajectory either as GAT or OAT. Regarding the route extraction, the route segments of the IFR flight plan will be categorised according to the “OAT” and “GAT” indicators:




a. If the route field contains a “FIX OAT” indicator, the route categorised as OAT will be composed of:

i. switching point (i.e.: FIX OAT) and

ii. route segments following the indicator, while the route segments prior to the switching point will be categorised as GAT;

b. If the route field contains a “FIX GAT” indicator, the route categorised as GAT will be composed of:

i. switching point (i.e.: FIX GAT)and

ii. route segments following the indicator while the route segments prior to the switching point will be categorised as OAT.

Regarding the SCL presentation and Strip Printing, the route segments of the IFR flight plan will be displayed/printed according to the following rules:

a. If the route field contains a “FIX OAT” indicator, the route displayed/printed as OAT will be composed of:

- switching point (i.e.: FIX OAT) and

- route segments following the indicator, while the route segments prior to the switching point (including the switching point) will be displayed/printed as GAT;

b. If the route field contains a “FIX GAT” indicator, the route displayed/printed as GAT will be composed of:

- switching point (i.e.: FIX GAT)and

- route segments following the indicator while the route segments prior to the switching point (including the switching point) will be displayed/printed as OAT.

IFR SFPL data, relevant to GAT route segments of the flight, will be distributed to the concerned GAT suites (civil sectors), while those relevant to OAT route segments to a default military suite (MEA)

7.2.2.2 VFR Flight Data Distribution

For flights whose flight rule is V, and the flight type is not “M” the distribution will be performed to the FIC sector. For flights whose flight rule is V, and the flight type is “M” the distribution will be performed to a default military sector (MEA). The FPPS/LFDP is able to recognize in the SFPL route field the switching point (speed/level) for Y or Z flight according to following examples:

Point VFR e.g. G1 KOK VFR Point IFR e.g. G1 KOK IFR Point/Speed Level VFR e.g. G1 KOK/N0210A020 VFR Point/Speed Level IFR e.g. G1 KOK/N0210A020 IFR Point/Speed VFR e.g. G1 KOK/N0210VFR




Point/Speed IFR e.g. G1 KOK/N0210IFR

7.2.2.3 “Y” and “Z” Flight Data Distribution

For flights whose flight rule is “Y” or “Z”, and the flight type is “M” the distribution will be performed in the following way:- if no GAT/OAT switch is present in the IFR segments of route field then the IFR segments will

be distributed to civil crossed sector while the VFR segments shall be distributed to the default military sector (MEA);

- if any GAT/OAT switch is present in the IFR segments of route field then the IFR segments will be distributed according to GAT/OAT switches while the VFR segments shall be distributed to the default military sector (MEA);

For flights whose flight rule is “Y” or “Z”, and the flight type is not “M” the distribution will be performed in the following way:- if no GAT/OAT switch is present in the IFR segments of route field then the IFR segments shall

be distributed to civil crossed sector while the VFR segments shall be distributed to the FIC sector;- if any GAT/OAT switch is present in the IFR segments of route field then the IFR segments shall

be distributed according to GAT/OAT switches while the VFR segments shall be distributed to the FIC or MEA sector according to GAT/OAT switches;

For flights with more than one IFR/VFR switch in the route field, each transition between IFR and VFR segment will be handled as “Y” flights with a single switch; each transition from VFR to IFR segment will be handled as “Z” flights with a single switch.

7.2.3 MANUAL ORDERS AND STRIP PRINTING FOR CIVIL-MILITARY FLIGHTS

The following Civil to Civil transfer of control order is extended for the transfer between Civil and Military suites:

a. TOF and AOC orders;

The TOC (i.e.: performed only between civil positions) and TOF (i.e.: performed between civil-military, civil-civil and military-military positions) orders will propose a transfer of control to the next sector in trajectory, being either GAT or the default OAT suite (MEA) according to the list of the crossed sectors.Manual transfer of control between OAT and GAT sectors will be allowed overriding default allocation by means of the TOF order. XFL/PEL level automatic coordination will not be allowed between civil sector and any military sector and between military-military sectors.




7.2.4 AFP MESSAGE

The AFP message automatic transmission is performed upon any OLDI reception or RCR execution that produces any change of flight rules (IFR/VFR) or flight type (OAT/GAT), associated to a specific point (one or more changes trigger only one AFP message transmission) along the route (i.e.: for SFPL pending/active/live). In detail the following circumstances will be a reason to send an AFP message after a route updating:- a new point is input in the route field and there is a switch (IFR/VFR or OAT/GAT ) associated to

it - a point, formerly present in the route field with a switch (IFR/VFR or OAT/GAT ) associated to

it, has been removed- the switch (IFR/VFR or OAT/GAT ), formerly associated to point present in the route field, has

been removed- a new switch (IFR/VFR or OAT/GAT ) has been associated to a point, formerly present in the

route field

For changes of flight rules (IFR/VFR) or flight type (OAT/GAT), it is possible to enable or disable the AFP automatic generation according to system parameters.


Annex 1 - Flight Data Processing System

Documents

Transcript of Annex 1 - Flight Data Processing System