Annex 1 - Flight Data Processing System

BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
ANNEX 1
FPPS AND LFDPS
FUNCTIONAL DESCRIPTION
This ANNEX contains a total of 106 pages
E184-01-04449SAD_A-Draft
UNCLASSIFIED
Page 1
BUSINESS UNIT ATMAS
E184-01-04449SAD
UNCLASSIFIED
Issue
Date:
A-Draft
09/05/06
LIST OF ABBREVIATIONS
ABBR.
DESCRIPTION
ACC
ADS
Area Control Centre

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
UNCLASSIFIED
Page 2
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
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
UNCLASSIFIED
A-Draft
09/05/06
Page 3
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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..............................................................................................................................18

4.2 OPERATIONAL STATES................................................................................................................19
5. SYSTEM FLIGHT PLAN REFERENCE MODEL...................................................................... 24
5.1 SYSTEM FLIGHT PLAN DEFINITION............................................................................................24
5.2 SYSTEM FLIGHT PLAN STATES MODEL......................................................................................28
5.2.1 INACTIVE-READY-TO-BE -SENT TRANSITION...................................................................................28
5.2.2 READY-TO-BE -SENT-SENT TRANSITION.......................................................................................28
5.2.3 TERMINATED STATUS FOR FPPS...................................................................................................28
5.2.4 INACTIVE PENDING TRANSITION..............................................................................................29
5.2.5 PENDING ACTIVE TRANSITION.................................................................................................29
5.2.6 INACTIVE-ACTIVE TRANSITION..................................................................................................29
5.2.7 SFPL STATE TRANSITION FROM ACTIVE TO LIVE.....................................................................29
5.2.8 SFPL STATE TRANSITION FROM LIVE TO TERMINED...............................................................29
5.2.9 UNDO ORDERS...........................................................................................................................30
5.2.10 SFPL STORAGE........................................................................................................................30
5.2.11 VFR FLIGHTS HANDLING.........................................................................................................30
6. CORE FUNCTIONS DESCRIPTION........................................................................................... 33
6.1 ENVIRONMENTAL DATA PROCESSING.........................................................................................33
6.1.1 GENERAL..................................................................................................................................33
6.1.2 STATIC DATA..............................................................................................................................34
6.1.2.1 Airspace Data Handling..............................................................................................................34
6.1.2.2 Aircraft Data..............................................................................................................................40
6.1.2.3 Pool of SSR Codes.....................................................................................................................40
6.1.3 DYNAMIC DATA.........................................................................................................................41
6.2 MESSAGE HANDLING..................................................................................................................42
6.2.1 GENERAL..................................................................................................................................42
6.2.2 ATS MESSAGES RECEPTION.......................................................................................................45
6.2.3 MANUALLY TRIGGERED GENERATION OF MESSAGES..................................................................46
6.2.3.1 Transmission of Free-text Messages...........................................................................................46
6.2.3.2 Messages Addressing..................................................................................................................46
6.2.4 MET / AIS MESSAGES RECEPTION..............................................................................................47
6.2.5 ATFM MESSAGES HANDLING.....................................................................................................47
6.2.5.1 Slot Allocation Message (SAM) Handling..................................................................................48
6.2.5.2 Slot Revision Message (SRM) Handling.....................................................................................49
6.2.5.3 Slot Cancellation Message (SLC) Handling................................................................................49
6.2.5.4 Flight Suspension Message (FLS) Handling...............................................................................50
UNCLASSIFIED
Page 4
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
6.2.5.5 De-Suspension Message (DES) Handling...................................................................................51

6.2.5.6 First System Activation (FSA) Message Transmission................................................................52
6.2.6 CO-ORDINATION MESSAGES EXCHANGE......................................................................................53
6.3 INITIAL FLIGHT DATA HANDLING..............................................................................................55
6.3.1 GENERAL..................................................................................................................................55
6.3.2 SFPL CREATION........................................................................................................................57
6.3.2.1 Creation of a SFPL by Manual Input..........................................................................................58
6.3.2.2 Creation of SFPL by Message Reception....................................................................................58
6.3.2.3 Creation of SFPL by Repetitive Flight Plan Database.................................................................59
6.3.3 DETERMINATION OF THE ESTIMATED TAKE OFF TIME (ETOT)...................................................61
6.3.4 INITIAL SFPL DATA MODIFICATIONS..........................................................................................61
6.3.4.1 Modifications upon reception of an ATS message.......................................................................61
6.3.4.2 Manual modifications.................................................................................................................62
6.4 FLIGHT PROGRESS DATA HANDLING.........................................................................................63
6.4.1 GENERAL..................................................................................................................................63
6.4.2 SFPL DATA UPDATE UPON SYSTEM CALCULATIONS...................................................................65
6.4.3 MANUAL SFPL DATA UPDATE...................................................................................................66
6.5 TRAJECTORY PREDICTION..........................................................................................................67
6.5.1 GENERAL..................................................................................................................................67
6.5.2 DATA SOURCES..........................................................................................................................68
6.5.3 ROUTE ANALYSIS AND EXTRACTION..........................................................................................69
6.5.4 4D PROFILE CALCULATION........................................................................................................70
6.5.5 SUSPENSION OF TRAJECTORY PREDICTION CALCULATION..........................................................73
6.5.6 UPPER WIND DATA.....................................................................................................................73
6.6 SFPL DATA DISTRIBUTION........................................................................................................74
6.6.1 FPPS TO LFDPS SYSTEM FLIGHT PLAN DISTRIBUTION..............................................................74
6.6.2 FLIGHT PLAN DATA DISTRIBUTION FROM LFDPS TO USERS........................................................74
6.7 SSR CODES MANAGEMENT AND ASSIGNMENT..........................................................................75
6.7.1 GENERAL..................................................................................................................................75
6.7.2 SSR CODES MANAGEMENT...........................................................................................................75
6.7.2.1 ORCAM Rules ADAPTATION..................................................................................................76
6.7.2.2 PSSR CODES ASSIGNMENT TO FLIGHTS..........................................................................78
6.7.2.3 ASSR CODES ASSIGNMENT TO DEPARTING FLIGHTS...................................................78
6.7.2.4 ASSR CODES ASSIGNMENT TO ENTERING FLIGHTS.....................................................78
6.7.2.5 SSR CODE DE-ASSIGNMENT AND ELIGIBILITY FOR RE-USE.......................................79
6.8 FPL/TRACK CORRELATION........................................................................................................80
6.9 FLIGHT LEVEL CO-ORDINATION.................................................................................................81
6.9.1 GENERAL..................................................................................................................................81
6.9.2 OLDI COORDINATION................................................................................................................85
6.9.2.1 Co-ordination Points Definition..................................................................................................87
6.9.2.1.1 COP Configuration..................................................................................................................87
6.9.2.2 The Filter....................................................................................................................................87
6.9.2.3 Notification Messages.................................................................................................................88
6.9.2.3.1 Advance Boundary Information Message (ABI)......................................................................88
6.9.2.3.2 Preliminary Activate Message (PAC).......................................................................................88
6.9.2.4 PRE-DEPARTURE CO-ORDINATION MESSAGES...............................................................89
6.9.2.4.1 Clearance Request Message (CRQ).........................................................................................89
UNCLASSIFIED
Page 5
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
6.9.2.4.2 Clearance Response Message (CRP).......................................................................................89

6.9.2.5 COMPLEMENTARY MESSAGES..........................................................................................89
6.9.2.5.1 SSR Code Assignment Message (COD)...................................................................................90
6.9.2.6 Coordination Messages...............................................................................................................90
6.9.2.6.1 Activate Message (ACT).........................................................................................................90
6.9.2.6.2 Referred Activate Proposal (RAP)...........................................................................................91
6.9.2.6.3 Revision Message (REV).........................................................................................................91
6.9.2.6.4 Referred Revision Proposal (RRV)..........................................................................................91
6.9.2.6.5 Accept message (ACP)............................................................................................................92
6.9.2.6.6 Reject message (RJC)..............................................................................................................92
6.9.2.6.7 Coordination message (CDN)..................................................................................................92
6.9.2.7 Acknowledgement MessageS......................................................................................................92
6.9.2.7.1 Logical Acknowledgement Message (LAM).............................................................................92
6.9.2.7.2 Stand-by Message (SBY).........................................................................................................93
6.9.2.8 Transfer of communications messages........................................................................................93
6.9.2.8.1 Transfer Initiation Message (TIM)...........................................................................................93
6.9.2.8.2 Supplementary Data Message (SDM)......................................................................................93
6.9.2.8.3 Hand-Over Proposal Message (HOP).....................................................................................93
6.9.2.8.4 Request on Frequency Message (ROF)....................................................................................94
6.9.2.8.5 Change of Frequency Message (COF).....................................................................................94
6.9.2.8.6 Manual Assumption of Communications Message (MAS).......................................................94
6.9.2.9 Message for the Abrogation of Co-ordination (MAC).................................................................95
6.9.2.10 Ground GROUND SITUATIONAL Awareness.....................................................................95
6.9.2.11 Information Message (INF)......................................................................................................95
6.9.3 EST ORDER..............................................................................................................................95
6.10 SUPERVISION.............................................................................................................................97
6.10.1 GENERAL................................................................................................................................97
6.10.2 NODE ROLES SWITCH..............................................................................................................97
6.10.3 ACCESS RIGHTS.......................................................................................................................97
6.10.4 LOG & BACK UP FUNCTIONALITY...........................................................................................97
6.10.5 LINES CONFIGURATION............................................................................................................98
6.10.6 SSR SLOTS ASSIGNMENT.........................................................................................................98
6.10.7 MANAGEMENT OF SECTOR ASSIGNMENT..................................................................................98
6.11 INTEGRITY AND SECURITY.......................................................................................................99
6.11.1 SFPL DATABASE ALIGNMENT...................................................................................................99
6.11.2 DATA INTEGRITY......................................................................................................................99
6.11.3 ELIGIBILITY.............................................................................................................................99
7. ADDED FUNCTIONS DESCRIPTION....................................................................................... 100
7.1 CONFORMANCE MONITORING FUNCTION................................................................................100
7.1.1 GENERAL................................................................................................................................100
7.1.2 DEVIATIONS DETECTION..........................................................................................................100
7.1.3 AUTOMATIC REPORT ON FIX....................................................................................................102
7.1.4 ALERT GENERATION AND TRAJECTORY RE-CALCULATION........................................................102
7.2 GAT/OAT AND IFR/VFR MULTIPLE SWITCHES.......................................................................103
7.2.1 ROUTE ANALYSIS.....................................................................................................................103
7.2.2 DISTRIBUTION.........................................................................................................................103
UNCLASSIFIED
Page 6
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
7.2.2.1 IFR Flight Data Distribution.....................................................................................................103

7.2.2.2 VFR Flight Data Distribution...................................................................................................104
7.2.2.3 Y and Z Flight Data Distribution.......................................................................................105
7.2.3 MANUAL ORDERS AND STRIP PRINTING FOR CIVIL-MILITARY FLIGHTS.......................................105
7.2.4 AFP MESSAGE.........................................................................................................................106
UNCLASSIFIED
Page 7
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
1.
A-Draft
09/05/06
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 Handling
The 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 coordination messages.
3. Initial Flight Data Handling
The 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 Handling
The Flight Progress Data Handling (FPDH) function is concerned with the modifications of SFPLs
data after its transition to the active state and until its termination.
5. Trajectory Prediction
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.
6. Distribution
The 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.
UNCLASSIFIED
Page 8
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
7. SSR Codes Management and Assignment

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).
8. SFPL/Track Correlation
The objective of the SFPL/Track Correlation function is to logically associate surveillance data
representing a track with a SFPL.
9. Co-ordination
The Co-ordination function allows ground-ground co-ordination by the implementation of an OLDI
(On Line Data Interchange) facility between ATS units.
10. Supervision
The 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 Security
The 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 switches
The 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. MULTITREADHING
The FDP capacity is improved using the multithreading software architecture.
UNCLASSIFIED
Page 9
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
2.
A-Draft
09/05/06
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.4
OPR-ET1.ST03.1000-ORD-01-00
Working Draft - October 1996
3. Eurocontrol Standard for On-Line Data Interchange (OLDI)
Edition 2.3
DPS.ET1.ST06-STD-02-00
Released Issue - December 2000
4. Eurocontrol Standard Document for Flight Data Exchange
Interface Control Document
Part 1: Point-to-Point and Limited Networking Circuits
COM.ET1.ST12.DEL-XX-01
Proposed Issue: April 30th, 1997
5. Eurocontrol Standard Document for ATS Data Exchange Presentation (ADEXP)
Edition 2.0
DPS-ET1-ST09-STD-01-01
Released Issue: June, 1998
6. Eurocontrol Guide to ATFM message Exchange
Edition 6.0
DPS-ET1-ST09-STD-01-01
March, 1998
7. Eurocontrol Operational Requirements for EATCHIP Phase III ATM Added Functions
Volume 1 Monitoring Aids
OP1.ET1.ST04.DEL01.02.1
Released Issue: May 14th, 1999
8. ROMATSA-Operational Requirements for Flight Plan Pre-Processing System (FPPS)- Edition 2.027/11/98
9. ROMATSA -Modernization project of Romanian ATM system- ROM.OPR.PROJ.ATM-Edition2.027/11/98.
10. ROMATSA-AMS- Minute of Meeting (MoM-TM02) -Roma 4th October 2000 6th October 2000.
UNCLASSIFIED
Page 10
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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 13rd15th 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
UNCLASSIFIED
Page 11
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
3.
A-Draft
09/05/06
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 preprocessed 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.
UNCLASSIFIED
Page 12
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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 subsystem 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.
UNCLASSIFIED
Page 13
BUSINESS UNIT ATMAS
E184-01-04449SAD
UNCLASSIFIED
Issue
Date:
A-Draft
09/05/06
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
LFDP
In-Out: ATS messages

In: Short flight plans, terminated flight plans, OLDI INF messages, locally inserted
flight plans.
ROMATSA GWY
Out: Validated and Pre-processed SFPLs, validated OLDI messages, updated

SFPLs.
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 In-Out: configuration data
Supervisor
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.
UNCLASSIFIED
Page 14
BUSINESS UNIT ATMAS
E184-01-04449SAD
UNCLASSIFIED
Issue
Date:
A-Draft
09/05/06
TABLE 3-2 - LFDPS GENERAL CONTEXT DIAGRAM.

System
FPPS
DATA
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 In: QNH Information.
meteo system
Out: QNH correction, Transition Level.
CFMU/IFPS
In-Out: ATS messages
CFMU/TACT
In-Out: ATFM messages
Foreign 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 In: Information about aircraft position (system radar tracks).
Processing System
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 Orders
Out: Diagnostics
LFDP
Technical In-Out: Configuration data
Supervisor
FDE Position
In: environmental data, aircraft performance, orders, meteo data management
Out: archived data, warnings
In/Out: configuration data, FPLs management, coordination management
UNCLASSIFIED
Page 15
BUSINESS UNIT ATMAS
E184-01-04449SAD
UNCLASSIFIED
Issue
Date:
METEO/AIS
Units
ATS Units
CFMU/IFPS
MET/AIS messages
ATS
messages
A-Draft
09/05/06
ATS and Free

Text
messages
AFTN Network
FPPS Positions
MET/AIS
messages
Environmental Data
Aircraft Performance
Meteo Data management
Corrected /Validated Pre-Processed SFPLs
Orders
ATS
messages
ATS and Free
Text
messages
FPPS Technical
Supervisor
Configuration Data
Incorrect ATS messages

Short and locally inserted (from LFDPs) flight plans
Archived Data
Warnings
Terminated SFPL
OLDI INF messages
Active FPLs
FPPS
ROMATSA GWY
Configuration Data
FPLs management
Request for single flight

Request for multiple flights
Request for multiple OLDI
Request for re-transmission
Short flight plans
Terminated flight plans
OLDI INF messages
locally insertded flight plans
(when FPPS is down)
Validated and Pre-Processed SFPLs

Validated OLDI
Updated SFPLs
Romanian TCP/IP Network
Short flight plans

Terminated flight plans
OLDI INF messages
locally insertded flight plans
(when FPPS is down)

Validated OLDI
Updated SFPLs
LFDPs
FIG. 3-1 - GENERAL FPPS CONTEXT DIAGRAM.
UNCLASSIFIED
Page 16
BUSINESS UNIT ATMAS
E184-01-04449SAD
UNCLASSIFIED
Issue
Date:
A-Draft
09/05/06
FPPS
Internal
ATCUs

Validated OLDI messages
Updated SFPLs
OLDI Messages
Short flight plan

terminated flight plan
OLDI INF messages
locally insertded flight plan
(when FPPS is down)
Safety Nets
Romanian TCP/IP Network
FPL Data
OLDI
Messages
RDPS

Validated OLDI messages
Updated SFPLs
Short flight plan

terminated flight plan
OLDI INF
locally insertded flight plan
(when FPPS is down)
LFDP Technical
supervisor
Radar
Tracks
Configuration Data
PLN/EXE Orders
Diagnostics
CWP
LFDP
Warnings
Environmental Data
ATC sectors frequency management
CMS
S FPL Data
Co - ordination Data
Supervisor Orders
Warnings
Archived Data
FDE
Position
Environmental Data
Meteo Data management
Orders
Co-ordination
Configuration Data
FPLs Management
MET/AIS
MESSAGES
ATS
messages
ATFM
messages
OLDI Messages
X.25 Network
AFTN Network
QNH
INFO
Romanian
Local Meteo
System
MET/AIS
MESSAGES
METEO/AIS
UNITS
ATS
messages
CFMU/IFPS
ATFM
messages
CFMU/TACT
OLDI Messages
ADJACENT
FOREIGN
ATCUs
FIG. 3-2 - GENERAL LFDP CONTEXT DIAGRAM.
UNCLASSIFIED
Page 17
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
4.
NODE ROLES AND OPERATIONAL STATES
4.1
NODE ROLES
A-Draft
09/05/06
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-by
The node assumes this role when it is properly running but the partner node is in charge of the master
properties.
Master_Alone
The 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-by
The 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_Alone
The 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 Master
LFDPS 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_Alone
The 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.
UNCLASSIFIED
Page 18
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
Transition from Master_Alone to Master

The 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-by
LFDPS 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
Idle
Wake up
Operative
Idle
Wake up
Operative
Not Available
Not Available
Not Available
LFDPS/FPPS Node
B
Not Available
Not Available
Not Available
Idle
Wake up
Operative
Idle
Wake up
Operative
UNCLASSIFIED
Page 19
BUSINESS UNIT ATMAS
E184-01-04449SAD
UNCLASSIFIED
Issue
Date:
A-Draft
09/05/06
The operational states transition model is described in figure 4.21 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.
IDLE
Fault
Go
Operative
OFF
POWER ON
POWER OFF
LFDPS/
FPPS
WAKE UP
Shutdown
Fault
FAULT
CONDITION
End of
alignment
OPERATIVE
Fault
FIG. 4.2-1- LFDPS/FPPS OPERATIONAL STATES.

Idle
The 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.)
UNCLASSIFIED
Page 20
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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).
UNCLASSIFIED
Page 21
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
Wake Up
Wake 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.
UNCLASSIFIED
Page 22
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
Operational states transitions

It 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.
UNCLASSIFIED
Page 23
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
5.
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 24
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 25
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06

SFPL DATA ITEM
DESCRIPTION
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
UNCLASSIFIED
Page 26
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06

SFPL DATA ITEM
DESCRIPTION
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
UNCLASSIFIED
Page 27
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
5.2
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 28
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
5.2.4
A-Draft
09/05/06
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 PreActivation 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 (localdomestic-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;
UNCLASSIFIED
Page 29
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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:
UNCLASSIFIED
Page 30
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 31
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
TABLE 5.2-1 SFPL States within the LFDPS.

SFPL State
INACTIVE
PENDING
ACTIVE
LIVE
TERMINATED
State Description
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.
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).
The flight is currently active in the air, the inbound conditions have
been defined but it is not yet flying in the controlled airspace (inboundoverfly flights), or it is on the ground and the departure clearance has
been issued (local-domestic-outbound flights).
The flight has been automatic or manually reported on the first
reporting fix for the ATC Centre.
The flight has automatically or manually reported on the last point of
interest for the ATC Centre.
UNCLASSIFIED
Page 32
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.
CORE FUNCTIONS DESCRIPTION
6.1
ENVIRONMENTAL DATA PROCESSING
6.1.1
GENERAL
A-Draft
09/05/06
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).
UNCLASSIFIED
Page 33
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.1.2
A-Draft
09/05/06
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 Responsibility
It will be allowed to eligible operators (FPPS/LFDPS) to define the AoRs 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 Interest
The 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.
UNCLASSIFIED
Page 34
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
Fixes
Eligible 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 Points
Eligible 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).
Sectors
The 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.
UNCLASSIFIED
Page 35
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
Aerodromes
Eligible 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
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
UNCLASSIFIED
Page 36
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
RVSM Zones
Eligible LFDPS operators are enabled to insert, update, delete and print the RVSM Zone data (i.e. Zone Id,
Min Level, Max Level).
Runways
Eligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the following aerodromes
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
Status (opened or closed)
is default flag (default or not default, in case there are more than one runways)
Airways
Eligible 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).
SIDs
Eligible operators (FPPS/LFDPS) are enabled to insert, update, delete and print the following information
relevant to the aerodromes SIDs:
SID code
list of Fixes defining the SID and, for each of these, the Minimum and maximum Crossing Level
STARs
relevant to the aerodromes STARs:
STAR code
list of Fixes defining the STAR and, for each of these, the Minimum and maximum Crossing Level
UNCLASSIFIED
Page 37
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
ICPs (initial climb path)

relevant to the aerodromes ICPs:
ICP code
list of Fixes defining the ICP and, for each of these, the Minimum and maximum Crossing Level
FAPs (Final approach path)
relevant to the aerodromes FAPs:
FAP code
list of Fixes defining the FAP and, for each of these, the Minimum and maximum Crossing Level
Junctions between aerodromes and airways
Eligible 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 SIDs
While 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
Junctions between STAR provided aerodromes and STARs
While storing a junction between a STAR provided aerodrome and a STAR, the following information is
provided:
joint STAR code
Runway code which the SID refers to
Junctions between SID-less aerodromes and airways
While storing a junctions between a SID-less aerodrome and an airway, the following information is
provided:
ICAO Location Indicator of the joint aerodrome
ATS routes joining Fixes, to enter the ATS in both the directions (forward/backward) while departing
from the aerodrome
UNCLASSIFIED
Page 38
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
Junctions between STAR-less aerodromes and airways

While storing a junctions between a STAR-less aerodrome and an airway, the following information is
provided:
ICAO Location Indicator of the joint aerodrome
ATS routes joining Fixes, to leave the ATS while arriving to the aerodrome from both the directions
(forward/backward)
UNCLASSIFIED
Page 39
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
Geographical Sectors Changes

Depending 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 Classes
Eligible 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).
Eligible 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.
UNCLASSIFIED
Page 40
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.1.3
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 41
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.2
MESSAGE HANDLING
6.2.1
GENERAL
A-Draft
09/05/06
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

Flight plan cancellation
Flight plan modification
Departure
Arrival
Delay
Estimate
Current Flight Plan
ATC Flight Plan
ATC Flight Plan Change
ATC Flight Plan Proposal
Request Flight Plan
FPL
CNL
CHG
DEP
ARR
DLA
EST
CPL
APL
ACH
AFP
RQP
The following ATS messages can be exchanged with the Initial Flight Plan Processing System (IFPS),
according to ADEXP format:
Filed flight plan

Flight plan cancellation
Flight plan modification
Departure
Arrival
Delay
ATC Flight Plan
ATC Flight Plan Change
ATC Flight Plan Proposal
Request Flight Plan
IFPL
ICNL
ICHG
IDEP
IARR
IDLA
IAPL
IACH
IAFP
IRQP
The MET/AIS messages reception is enabled both on the FPPS and the LFDPSs (ref. to 6.2.4).
UNCLASSIFIED
Page 42
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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
FCRO61
FCRO62
FCRO63
FCRO64
FCRO65
FTRO61
SARO61
SARO62
SARO63
SARO64
SARO65
SPRO51
WSRO31
FXRO41
NOTAM
SNOWTAM
Description
Weather forecast (TAF 9 Hr)
METAR
METAR
METAR
METAR
METAR
SPECI
SIGMET
Upper wind/significant weather forecast
Notice to airman
Snow message
The following ATFM messages can be received from the Central Flow Management Unit (CFMU),
according to ADEXP format:
Slot allocation
Slot cancellation
Slot revision
Flight Suspension
Flight De-Suspension
SAM
SLC
SRM
FLS
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 MESSAGES
Advance 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 MESSAGES
SSR Code Assignment Message (COD)
UNCLASSIFIED
Page 43
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
PRE-DEPARTURE CO-ORDINATION
Clearance Request (CRQ)
Clearance Response Message (CRP)
Ground Ground SITUATIONAL AWARENESS
Information Message (INF)
DIALOGUE PROCEDURE - COORDINATION
Referred Activate Proposal Message (RAP)
Referred Revision Proposal Message (RRV)
Stand-by Message (SBY)
Acceptance Message (ACP)
Co-ordination Message (CDN)
DIALOGUE PROCEDURE - TRANSFER OF COMMUNICATION
Transfer 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)
UNCLASSIFIED
Page 44
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.2.2
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 45
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.2.3
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 46
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.2.4
A-Draft
09/05/06
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
FCRO61
FCRO62
FCRO63
FCRO64
FCRO65
FTRO61
SARO61
SARO62
SARO63
SARO64
SARO65
SPRO51
WSRO31
FXRO41
NOTAM
SNOWTAM
Description
METAR
METAR
METAR
METAR
METAR
SPECI
SIGMET
Upper wind/significant weather forecast
Notice to airman
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
SRM
SLC
FLS
DES
Slot Allocation Message;

Slot Revision Message;
Slot Cancellation Message.
Flight Suspension Message
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.
UNCLASSIFIED
Page 47
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 48
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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
ADDR (optional)
ARCID
ADEP
EOBD
EOBT
IOBD (optional)
IOBT (optional)
NEWCTOT
REASON (optional)
ADES
REGUL (one or more)
COMMENT (optional-none, one or more)
TAXITIME
Message Name
List of Addresses
Revised CTOT
Difference between Off-Block Time and Take-Off
Time.
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
ADDR (optional)
ARCID
ADEP
EOBD
EOBT
IOBD (optional)
IOBT (optional)
REASON (optional)
ADES
TAXITIME
Message Name
List of Addresses
Time.
UNCLASSIFIED
Page 49
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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
SFPLs 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
ADDR (optional)
ARCID
ADEP
EOBD
EOBT
IOBD (optional)
IOBT (optional)
NEWEOBD (optional)
NEWEOBT (optional)
REASON (optional)
ADES
REGUL (one or more)
COMMENT (optional- none, one or more)
TAXITIME
Message Name
List of Addresses
New Estimated Off-Block Date
New Estimated Off-Block Time
Time.
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 Suspension
CFMU/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.
UNCLASSIFIED
Page 50
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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 desuspended and it is no longer subject to ATFM measures. DES is composed of the following data:
TITLE
ARCID
ADEP
EOBD
EOBT
IOBD (optional)
IOBT (optional)
NEWEOBD (optional)
NEWEOBT (optional)
REASON (optional)
ADES
TAXITIME
Message Name
New Estimated Off-Block Date
New Estimated Off-Block Time
Time.
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.
UNCLASSIFIED
Page 51
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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 doesnt 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.
UNCLASSIFIED
Page 52
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.2.6
A-Draft
09/05/06
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):
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 applicable
d)
optional fields
UNCLASSIFIED
Page 53
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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 Coordination 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.
UNCLASSIFIED
Page 54
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.3
INITIAL FLIGHT DATA HANDLING
6.3.1
GENERAL
A-Draft
09/05/06
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)
CHG
(AFTN)
DLA
(AFTN)
DEP
(AFTN)
ARR
(AFTN)
CNL
(AFTN)
EST
(AFTN)
APL
(AFTN)
Transmission to the
Messages Queue
Transmission to the
Messages Queue
Transmission to the
Messages Queue
Transmission to the
Messages Queue
Transmission to the
Messages Queue
Transmission to the
Messages Queue
ACH
(AFTN)
IFPL
(IFPS)
UNCLASSIFIED
Incorrect ATS
Incorrect ATS
Incorrect ATS
Incorrect ATS
Incorrect ATS
Incorrect ATS
Transmission to the Incorrect ATS

Messages Queue
Page 55
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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)
IDLA
(IFPS)
IDEP
(IFPS)
IARR
(IFPS)
ICNL
(IFPS)
IAPL
(IFPS)
Transmission to the
Messages Queue
Transmission to the
Messages Queue
Transmission to the
Messages Queue
Transmission to the
Messages Queue
Transmission to the
Messages Queue
IACH
(IFPS)
SAM
(CFMU)
SRM
(CFMU)
SLC
(CFMU)
FLS
(CFMU)
Suspension of the existing SFPL
DES
(CFMU)
ABI
(OLDI)
Transmission to the Incorrect ATS

Messages Queue
Transmission to the Incorrect ATFM
Messages Queue
Messages Queue
Messages Queue
Messages Queue
Messages Queue
PAC
(OLDI)
ACT /RAP
MAC
(OLDI)
Incorrect ATS
Incorrect ATS
Incorrect ATS
Incorrect ATS
Incorrect ATS
(OLDI)
Reversion of the existing SFPL Message rejection

data to the conditions prior to the
abrogated co-ordination
REV, RRV, CDN, RJC, Update of the existing SFPL
Message rejection
ACP, COF, MAS, ROF,
HOP, CRQ, CRP,
(OLDI)
INF (OLDI)
Message rejection
Creation of a new SFPL if AOI only
UNCLASSIFIED
Page 56
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.3.2
A-Draft
09/05/06
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;
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.
UNCLASSIFIED
Page 57
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 58
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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;
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:
UNCLASSIFIED
Page 59
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
time
ETI or EOBT
VSP time before

ETI or EOBT
PERIODIC RPLs
WAKE UP
PROCEDURE
INACTIVE SFPL = FPLs with the specified ETI or EOBT
FIG. 6.3.2.3-1 RPLs WAKE UP
UNCLASSIFIED
Page 60
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.3.3
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 61
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 62
BUSINESS UNIT ATMAS
E184-01-04449SAD
UNCLASSIFIED
Issue
Date:
6.4
FLIGHT PROGRESS DATA HANDLING
6.4.1
GENERAL
A-Draft
09/05/06
The Flight Progress Data Handling (FPDH) function is a LFDPS capability concerned with the
modifications of SFPLs 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 (localdomestic-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.
INACTIVE
PENDING
IFDH
ACTIVE
LIVE
TERMINATED
FPDH
FIG. 6.4-1 FPDH AND RELATED SFPL STATES
UNCLASSIFIED
Page 63
BUSINESS UNIT ATMAS
E184-01-04449SAD
UNCLASSIFIED
Issue
Date:
Inactive SFPL
Pending SFPL
Active SFPL
A-Draft
09/05/06
Live SFPL
SFPL Life-Cycle
Flights satisfying the following condition:

- traffic inbounding the FIR and flagged as 'OLDI ACT received'
Data to CWPs to produce

Controller oriented representations
Automatic SFPL
Activation
Correlation Data to CWPs and MRTS
FIG. 6.4-2- AUTOMATIC SFPL ACTIVATION
Inactive SFPL
Pending SFPL
Active SFPL
Live SFPL
SFPL Life-Cycle
Cleared flights
Pending flight data+ new trajectory updated

(with new trajectory data based on new cleared estimate time, level, etc.)
Manual SFPL
Activation

Correlation Data to CWPs and MRTS
"departure clearance"
for flight departing from controlled airspace
"inbound clearance"
for flight inbounding the controlled airspace
FIG. 6.4-3 - MANUAL SFPL ACTIVATION
UNCLASSIFIED
Page 64
BUSINESS UNIT ATMAS
E184-01-04449SAD
UNCLASSIFIED
Issue
Date:
Pending SFPL
Active SFPL
A-Draft
09/05/06
Live SFPL
SFPL Life-Cycle
Updated SFPL Data
MRT correlated tracks

First Report
Activities
- "Manual position report" orders

- "Manual take off report" orders
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 aircraft
The aircraft is considered out of the controlled airspace when an automatic report on an outbound fix is
given.
Landing of an aircraft
The 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.
UNCLASSIFIED
Page 65
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 66
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.5
TRAJECTORY PREDICTION
6.5.1
GENERAL
A-Draft
09/05/06
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 fourdimensional (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.
UNCLASSIFIED
Page 67
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.5.2
A-Draft
09/05/06
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
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.
UNCLASSIFIED
Page 68
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.5.3
A-Draft
09/05/06
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 aerodromes Departure Automation Level is SID provided the algorithm automatically assigns
the proper SID, otherwise it will recognise the airways joining point, as laid down in the environmental
data. The two dimensional path includes also points resulting from SID break down or the airways
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.
UNCLASSIFIED
Page 69
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
Flight arriving at an aerodrome within the Controlled Airspace (domestic, local and inbound
flights)
The algorithm automatically assigns the proper STAR, if the aerodromes Arrival Automation Level is
STAR provided, otherwise it recognises the airways leaving point, as laid down in the environmental
data. The two dimensional path includes also points resulting from STAR breakdown or the airways
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).
UNCLASSIFIED
Page 70
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 71
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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 airways joining point.
Flight departing from an aerodrome outside the Controlled Airspace (inbounds and overflights)
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.
Inbound Fix (identification, calculated level and ETO);
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)
Inbound Fix (identification, calculated level and ETO);
ETO);
Top Of Climb;
Top Of Descent;
Points resulting from STAR break down, or airways leaving point
Arrival runway threshold point (or the aerodrome reference point, if the runway threshold is not
available)
UNCLASSIFIED
Page 72
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
Flight arriving to an aerodrome outside the Controlled Airspace (outbounds and overflights)
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.
ETO);
Top Of Climb;
Top Of Descent;
Points resulting from STAR break down, or airways 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.
UNCLASSIFIED
Page 73
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.6
SFPL DATA DISTRIBUTION
6.6.1
FPPS TO LFDPS SYSTEM FLIGHT PLAN DISTRIBUTION
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 74
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 75
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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

follow:
Configuration the operator can select 4 subgroups and set each subgroup as
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
UNCLASSIFIED
Page 76
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
Category:
OAT/GAT:
SSR slot From:

SSR slot TO:
Time (min):
A-Draft
09/05/06
list that contains all available ORCAM categories: Sub-Domestic,

Domestic, Super-Domestic, transit, Super-Transit, Military, Other
list that contains OAT/GAT or ANY if GAT/OAT switches are in SFPL
route field
SSR code (four octal digit)
SSR code (four octal digit)
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.
UNCLASSIFIED
Page 77
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
6.7.2.3 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.4 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.
UNCLASSIFIED
Page 78
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.5 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).
UNCLASSIFIED
Page 79
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.8
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 80
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
1
Where 170FL is the maximum level (VSP) reached by a SID/STAR.
UNCLASSIFIED
Page 81
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
2. if XFL>FL170, the constraint to be applied in the predicted trajectory evaluation shall be

FL170.
UNCLASSIFIED
Page 82
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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
Over-flights
OLDI ACT
RECEIVED
EST ORDER
XFL PROPOSED
PEL ACCEPT
XFL ACCEPT after

MODIFY
XFL/PEL REJECT
DCL/DCR
COO
Arrivals
Actions
The 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.
Over-flights
Same as OLDI ACT
Arrivals
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.
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, autocoordination shall be immediately triggered.
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 autocoordination and there is no PROPOSED XFL set, auto-coordination shall be
immediately triggered.
The proposed XFL shall be rejected, the co-ordination conditions previously established
between the two sectors shall be maintained.
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.
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.
UNCLASSIFIED
Page 83
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
1.
OLDI REV received

or RCL/RCR issue
Over-flights
Arrivals
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.
The 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.
UNCLASSIFIED
Page 84
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.9.2
A-Draft
09/05/06
OLDI COORDINATION
LFDPS is able to automatically receive, process, store, deliver for display and transmit in real-time
information related to the following messages:
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.
UNCLASSIFIED
Page 85
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
Its 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 its 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 its 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 (timeout);
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 its 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.
The Phone Co-ordination order is available on the CWP and FDA.
UNCLASSIFIED
Page 86
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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 its 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 Units 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 coordinations which are known to be standard (ACT/REV message type) and messages known as nonstandard (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
ADEP
ADES
Check
COP
Aircraft
Type
Standard
levels or
level bands
Min/Max
Time/distance
Prior to the
COP;
Its 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.
UNCLASSIFIED
Page 87
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
6.9.2.3 Notification Messages
6.9.2.3.1
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
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
UNCLASSIFIED
Page 88
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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 coordination 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
A Clearance Response (CRP) message is manually generated in response to a received CRQ which has not
been superseded by a subsequent CRQ message
The 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
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.
UNCLASSIFIED
Page 89
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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
The ACT message satisfies the following operational requirements:

a)
b)
e)
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;
to update the basic flight plan data in the receiving ATC Unit with the most up-to-date information;
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).
UNCLASSIFIED
Page 90
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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
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. Its 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.
UNCLASSIFIED
Page 91
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.9.2.6.5
A-Draft
09/05/06
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
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
UNCLASSIFIED
Page 92
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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
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
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
UNCLASSIFIED
Page 93
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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
6.9.2.8.5
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
6.9.2.8.6
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).
UNCLASSIFIED
Page 94
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.11Information 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
UNCLASSIFIED
Page 95
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 96
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.10
A-Draft
09/05/06
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).
UNCLASSIFIED
Page 97
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 98
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
6.11
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 99
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
7.
ADDED FUNCTIONS DESCRIPTION
7.1
CONFORMANCE MONITORING FUNCTION
7.1.1
GENERAL
A-Draft
09/05/06
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 recalculated 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 flights 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 flights 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.
UNCLASSIFIED
Page 100
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
A longitudinal distance deviation is detected whenever a flights 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 Phase
if 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/Arrivals
For 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 Flight
For climbing or descending flights, it is possible to indicate if the function is to be performed or not.
UNCLASSIFIED
Page 101
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
7.1.3
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 102
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
7.2
GAT/OAT AND IFR/VFR MULTIPLE SWITCHES
7.2.1
ROUTE ANALYSIS
A-Draft
09/05/06
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 switches
The 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 VFR
For 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:
UNCLASSIFIED
Page 103
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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
UNCLASSIFIED
Page 104
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 105
BUSINESS UNIT ATMAS
UNCLASSIFIED
E184-01-04449SAD
Issue
Date:
7.2.4
A-Draft
09/05/06
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.
UNCLASSIFIED
Page 106

Annex 1 - Flight Data Processing System

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Annex 1 - Flight Data Processing System

Enviado por

Direitos autorais:

Formatos disponíveis

BUSINESS UNIT ATMAS

This ANNEX contains a total of 106 pages

BUSINESS UNIT ATMAS

Area Control Centre

Aeronautic Fixed Telecommunication Network

Airport Reporting Offices

Air Traffic Control

Air Traffic Flow Management

Air Traffic Management

Air Traffic Services

Auxiliary Working Position

Cleared Flight Level

Central Flow Management Unit

Control Working Position

European ATC Harmonisation and Integration Program

Estimated Time Over

Flight Data Processing System

Flight Information Region

Flight Management System

General Air Traffic

Human Machine Interface

International Civil Aviation Organisation

Initial Flight Plan System

Instrument Flight Rules

Local Area Network

Medium term Conflict Detection

Non Directional Beacon

Operational Air Traffic

On-Line Data Interchange

BUSINESS UNIT ATMAS

System Flight Plan

Standard Initial Departure

Secondary Surveillance Radar

System Supported Co-Ordination

Temporary Segregated Area

Visual Flight Rules

VHF Omni-directional Radio Range

Variable System Parameter

Wide Area Network

BUSINESS UNIT ATMAS

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

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

4.1 NODE ROLES..............................................................................................................................18

BUSINESS UNIT ATMAS

6.2.5.5 De-Suspension Message (DES) Handling...................................................................................51

BUSINESS UNIT ATMAS

6.9.2.4.2 Clearance Response Message (CRP).......................................................................................89

BUSINESS UNIT ATMAS

7.2.2.1 IFR Flight Data Distribution.....................................................................................................103

BUSINESS UNIT ATMAS

BUSINESS UNIT ATMAS

7. SSR Codes Management and Assignment

BUSINESS UNIT ATMAS

BUSINESS UNIT ATMAS

BUSINESS UNIT ATMAS

FDP SYSTEM CONTEXT DESCRIPTION

BUSINESS UNIT ATMAS

BUSINESS UNIT ATMAS

TABLE 3-1 - FPPS GENERAL CONTEXT DIAGRAM.

In: MET/AIS messages exchanged via AFTN.

In-Out: ATS messages, free text messages.

In-Out: ATS messages

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

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