EUROPEAN ORGANISATION
FOR THE SAFETY OF AIR NAVIGATION
EUROCONTROL
EUROCONTROL EXPERIMENTAL CENTRE
SOFT
Study of Operational Flight Plans and Trajectories
Requirements for Advanced Flight Plan Information
EEC Note No. 14/98
EEC Task R23
EATCHIP Task ODP-5-E3
Issued: June 1998
The information contained in this document is the property of the EUROCONTROL Agency and no part should be reproduced in
any form without the Agency’s permission.
The views expressed herein do not necessarily reflect the official views or policy of the Agency.
REPORT DOCUMENTATION PAGE
Reference:
EEC Note No. 14/98
Security Classification:
Unclassified
Originator:
EEC - FDR
(Flight Data Research)
Originator (Corporate Author) Name/Location:
EUROCONTROL Experimental Centre
BP15
91222 Brétigny-sur-Orge CEDEX
FRANCE
Telephone : +33 (0)1 69 88 75 00
Sponsor:
EATCHIP Development Directorate
DED.2
Sponsor (Contract Authority) Name/Location:
EUROCONTROL Agency
Rue de la Fusée, 96
B -1130 BRUXELLES
Telephone : +32-(0)2-729 90 11
TITLE:
SOFT
Study of Operational Flight Plans ans Trajectories
Requirements for Advanced Flight Plan Information
Author
R. Schuppenhauer
EATCHIP Task
Specification
ODP-5-E3
Date
Pages
Figures
Tables
Appendix
References
6/98
xii + 92
12
13
6
34
EEC Task No.
R23
Task No. Sponsor
Period
1997
Distribution Statement:
(a) Controlled by:
Head of FDR
(b) Special Limitations: None
(c) Copy to NTIS:
YES / NO
Descriptors (Keywords):
Flight Plan, Business Objects, Trajectory
Abstract:
This diploma thesis was written in the of a collaboration agreement between the EUROCONTROL
Experimental Centre (EEC) in Brétigny-sur-Orge and the research group Computergestützte
Informationssysteme (CIS) of Technische Universität Berlin. It proposes the definition of a business object
that realises extended flight plan functionality/information. This business object would allow for more
precise prediction of aircraft trajectories and thus for optimised use of the already overcrowded airspace in
Europe.
A flight plan represents the basic contract between a pilot and air traffic control. However, the current
format for filed flight plans contains only limited information with equally limited precision about flights,
while the airlines have access to significantly more detailed data. This extended flight plan functionality
makes use of information about aircraft already available to airline pilots but not communicated to air
traffic control.
The thesis aims to demonstrate that an enhanced set of flight plan information would assist air traffic
control in their tactical decisions and that different analyses of radar data and flight plans might give
researchers a better understanding of the causes of discrepancies between predicted and realised
trajectories.
This document has been collated by mechanical means. Should there be missing pages, please report to:
EUROCONTROL Experimental Centre
Publications Office
B.P. 15
91222 - BRETIGNY-SUR-ORGE CEDEX
France
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
CONTENTS
ABBREVIATIONS ................................................................................................................. VII
LIST OF FIGURES .....................................................................................................................X
PREFACE ................................................................................................................................. XI
1. INTRODUCTION ...............................................................................................1
1.1
1.2
1.3
1.4
Air Traffic Control and Information Technology............................................ 1
The SOFT Project .....................................................................................................
Business Object Developed in this Paper ......................................................... 4
Outline of the Thesis ............................................................................................. 5
2. THE PROBLEM DOMAIN 6
2.1
2.2
The Situation in Flight Planning Today............................................................ 6
EUROCONTROL Strategy .......................................................................................... 8
3. BUSINESS OBJECTS:
MODULAR REUSABLE STRUCTURES ...........................................................12
4. REQUIREMENTS DEFINITION FOR A FLIGHT PLAN BUSINESS OBJECT ..17
4.1
4.2
User Requirements .............................................................................................. 18
4.1.1
Airlines ..................................................................................................... 18
4.1.2
Airports ..................................................................................................... 19
4.1.3
Area Control Centres.............................................................................. 20
4.1.4
BADA ........................................................................................................ 24
4.1.5
CFMU ........................................................................................................ 25
4.1.6
CRCO ........................................................................................................ 27
4.1.7
DIFODAM ................................................................................................ 28
4.1.8
FREER ....................................................................................................... 29
4.1.9
FAA’s “New Age Flight Plan” .............................................................. 30
Classification of User Requirements ................................................................ 32
5. DEVELOPMENT OF AN XFPL BUSINESS OBJECT ........................................40
5.1
5.2
Definition of an XFPL Format ........................................................................... 41
Mapping the XFPL Object to the Relational Data Model ............................ 52
6. EVALUATION OF THE XFPL BUSINESS OBJECT ........................................70
6.1
6.2
Results .................................................................................................................... 70
Strategies for the Evaluation of the Business Object .................................... 70
6.2.1
Comparison of Trajectories .................................................................... 70
7. CONCLUSION ................................................................................................72
ANNEX I:
THE ICAO FILED FLIGHT PLAN FORMAT .................................... 74
ANNEX II: OPERATIONAL FLIGHT PLANS ....................................................75
V
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ANNEX III: SYSTEM FLIGHT PLANS OF THE AREA CONTROL CENTRES ....78
ANNEX IV: RADAR DATA DESCRIPTION .......................................................80
ANNEX V: METEOROLOGICAL DATA............................................................81
ANNEX VI: CFMU DATA ...............................................................................82
REFERENCES .......................................................................................................................... 84
GLOSSARY ............................................................................................................................. 87
VI
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ABBREVIATIONS
(EC) or (CFMU) after an explanation means the abbreviation is from the EUROCONTROL or Central Flow Management Unit projects, and is not a common ATC
abbreviation.
ACC
ADEP
ADES
ADEXP
ADS-B
AFTN
AOBT
API
ATN
ATC
ATFM
ATM
ATS
AWY
Area Control Centre
Departure airport
Destination airport
ATS Data Exchange Presentation (CFMU)
Automatic Dependent Surveillance-Broadcast
Aeronautical Fixed Telecommunications Network
Actual Off-Block Time
Application Program Interface
Aeronautical Telecommunications Network
Air Traffic Control
Air Traffic Flow Management
Air Traffic Management
Air Traffic Services
Airway
BADA
BO
Base of Aircraft DAta (EC)
Business object
CASE
CBO
CEU
CFMU
CFPS
CIS
Computer Aided Software Engineering
Cooperative business object
Central Executive Unit (CFMU)
Central Flow Management Unit (EC)
Collaborative Flight Plan Studies
Research group for Computation and Information Structures
at Technische Univeristät Berlin
Communication-Navigation-Surveillance
Calculated Off-Block Time
Common Object Request Broker Architecture
Centre Régional de la Navigation Aérienne
Calculated Take-Off Time
Controller Working Position
CNS
COBT
CORBA
CRNA
CTOT
CWP
EATCHIP
EATMS
ECAC
European Air Traffic Control Harmonization and Integration
Program (EC)
European Air Traffic Management System (EC)
European Civil Aviation Conference
VII
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
EEC
EER
ENV
EOBT
ERD
ETA
ETO
EUROCONTROL Experimental Centre, Brétigny-sur-Orge,
France (EC)
Extended Entity-Relationship notation
Environment (CFMU)
Estimated Off-Block Time
Entity Relationship Diagram
Estimated Time of Arrival
Estimated Time Over
FAA
FDPS
FF
FIR
FL
FMS
FPL
FREER
Federal Aviation Agency in the USA
Flight Data Processing System
Field Flow
Flight Information Region
Flight Level
Flight Management System
ICAO Filed flight Plan
Free Route Experimantal Encounter Resolution (EC)
GS
Ground Speed
HMI
Human Machine Interface
ICAO
IDL
IFPL
IFPS
IFPU
IFR
IOBT
ISA
International Civil Aviation Organization
Interface Description Language
Initial Flight PLan
Initial Flight plan Processing System (CFMU)
Initial Flight Plan Processing Unit (CFMU)
Instrument Flight Rules
Initial Off-Block Time
International Standard Atmosphere
LW
Landing Weight
MOCA
MORA
MT
MTCA
MTCD
Minimum Obstacle Clearance Altitude
Minimum Off-Route Altitude
Magnetic Track
Medium Term Conflict Alert
Medium Term Conflict Detection
OAT
OMG
Operational Air Traffic
Object Management Group
VIII
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
OOA
OOD
Object-Oriented Analysis
Object-Oriented Design
PRE-TACT
RDPS
RFL
RPL
RTCA
Pre-Tactical system (CFMU)
Radar Data Processing System
Requested Flight Level
ICAO Repetitive flight PLan
Radio-Technical Commission for Aeronautics
SAM
SFPL
SID
SIP
SITA
SSR
STAR
STIP
STRAT
Slot Allocation Message (CFMU)
System Flight Plan
Standard Instrument Departure
Slot Improvement Proposal message (CFMU)
Société Internationale de Télécommunication Aéronautique
Secondary Surveillance Radar
STandard (instrument) ARrival
Système de Traitement Initial de Plans de Vol
STRATegic System (CFMU)
TACT
TAS
TMA
TMP
TOW
TWR
Tactical System (CFMU)
True Air Speed
Terminal Manoeuvre Area
Temperature
Take-Off Weight
Aerodrome control ToWeR
UAC
UTC
Upper Area Control centre
Universal Time Co-ordinated
VFR
Visual Flight Rules
WAN
WCA
WPT
Wide Area Network
Wind Correction Angle
Waypoint
XFPL
Extended Flight Plan
ZFW
Zero Fuel Weight
IX
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
LIST OF FIGURES
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
Figure
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
The XFPL Object 44
XFPL Aggregation 45
Model and View 46
XFPL Model and View 47
Client Views 48
Database Adapter 49
Persistence Pattern 50
State Model 51
Mapping of the Object Class Model 52
A simplified flight plan relation 53
flight plan formats Object Model 54
ER-Diagram of the SOFT Database 57
X
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
PREFACE
This diploma thesis was written in the frame of a cooperation agreement
between the Eurocontrol Experimental Centre (EEC) in Brétigny-sur-Orge and
the research group Computergestützte Informationssysteme (CIS) of Technische
Universität Berlin. It was conducted as a sub-project of SOFT (Study of Operational Flight Plans and Trajectories).
The thesis proposes the definition of a business object that realizes extended
flight plan functionality/information. This business object would allow for more
precise prediction of aircraft trajectories and thus for optimized use of the already
overcrowded airspace in Europe.
A flight plan represents the basic contract between a pilot and air traffic control.
However, the current format for filed flight plans contains only limited information with equally limited precision about flights, while the airlines have access to
significantly more detailed data. This extended flight plan functionality makes
use of information about aircraft already available to airline pilots but not communicated to air traffic control.
The thesis aims to demonstrate that an enhanced set of flight plan information
would assist air traffic control in their tactical decisions and that different analyses of radar data and flight plans might give researchers a better understanding
of the causes of discrepancies between predicted and realized trajectories.
XI
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Intentionally left blank.
XII
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
1.
INTRODUCTION
1.1
Air Traffic Control and Information Technology
The constantly increasing air traffic in Europe demands optimized use of scarce
resources. Flight plans are fundamental for tactical planning in air traffic control
(ATC). At present, flight plans transmitted to ATC contain only a minimal set of
information about aircraft, while the different air carriers make internal use of
much more detailed plans. Present flight plans contain for example information
about the type, route and flight level of an aircraft. So there is more information
available at several places than effectively used by ATC.
The flight plan is the contract between the pilot and the air traffic control organizations and it is obligatory for flights under instrumental flight rules in controlled airspace (France: above 19,500 feet). It has to be deposited at least 30
minutes1 before planned take-off time by the pilot or the airline, generally at the
departure aerodrome.
Since 1986, traffic has increased by more than 50% and if the forecast annual
average increase of 4.5% continues, European air traffic will have doubled by the
end of the century [ATM97]. This explains the need for improved air traffic management.
Table 1: Estimated increase of air traffic in Europe
1988
Passengers
per annum
Passengers at
rush hour
2000
2015
3,065,000
low 5.3 M
medium 6.7 M
high 7.7 M
low 7 M
medium 10 M
high 13 M
12,657
low 17,500
medium 25,000
high 28,000
low 23,000
medium 38,000
high 48,000
The mismatch between flight plans filed in the ICAO format and the so-called
operational flight plans (OFPL) used internally by the air carriers is quite significant. Flight plan information as the unique source of planning information could
1. Three hours, if it passes through regulated airspace.
AIR TRAFFIC CONTROL AND INFORMATION TECHNOLOGY
1
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
be enhanced by the tactical decisions that air carriers have taken for flight trajectories, which are fed into sophisticated Flight Management Systems (FMS) in
each aircraft.
Trajectories and their distribution are considered to be a very important feature
of the next generation of flight data processing systems (FDPS). There are different proposals as to how the trajectories should be calculated and distributed. Currently the EEC is working on several projects in this direction, one of which is the
SOFT project in which the author had the opportunity to participate. This thesis
aims to find out if adding further detail would permit more efficient air traffic
management and more precise prediction for the controllers on the ground and
increase their work efficiency.
Meanwhile, progress in computer science in recent years has coined the term
Common (or Cooperative) Business Object, or business object for short. Unlike
objects and classes in object-oriented programming languages, business objects
(BO) represent things or concepts relevant to an application domain. They are
self-contained deliverables that can cooperate with other, separately developed
BOs.
1.2
The SOFT Project
This diploma thesis reflects a part of the Study of Operational Flight Plans and Trajectories (SOFT) which itself is part of the Collaborative Flight Plan Studies (CFPS)
project which began in May 1997 at the EEC in Brétigny-sur-Orge.
In the Centre of Expertise Flight Data Research (FDR) at the EEC scientists and engineers are studying the benefits that could result from an intensified data exchange
between air carriers and air traffic management. The exchange of operationally significant information between the ATC systems and the airspace users is not being used
to its full capacity. AOCs have access to detailed operational data [FMS95] while
ATFM disposes of data that would help the AOCs in planning their operations in a
more efficient manner. Although there is a significant amount of data available, only a
small part of this data is actually being exchanged today. Also this exchange is largely
non-automated, e.g. telephone conversations between airline dispatchers and traffic
THE SOFT PROJECT
2
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
management personnel are still common practice.
The project is motivated by the assumption that an exchange of the data currently
available to ATM and to the different AOCs can be quickly, easily and inexpensively
initiated today. The use of airline data could lead to improved trajectory handling in
future FDPS. Today the trajectory calculation in ground-based FDPS is based initially
on the FPL obtained by the IFPS. Interviews with different air carriers have shown
that the cockpit FMS provide enhanced trajectory predictions both before take-off and
in-flight (for long-range flights).
At the beginning of the project contacts to all the different potential providers of
data had to be established. Air France, British Airways, Condor, KLM, LTU,
Lufthansa, OAL, SAS, Swissair, and TAT have provided their OFPLs. In addition to
these airlines, SITA was contacted as a provider for flight plans from several other airlines, e.g. UK Air and Syrian Airlines. Then the Centre Régional de Navigation Aérienne (CRNA) Reims, as well as the CRNA in Athis-Mons were contacted to provide
radar data and corresponding system flight plans (SFPL). The CFMU in Brussels sent
flight plans in the so-called All_Flights format, and Météo France provided meteorological data for the ECAC region.
A detailed description of the contents of all the different data formats is given in
the Annexes. The 17th of June 1997 was chosen for the actual data collection.
Once all the data had arrived at the EEC, an analysis of the different formats and
of the semantics of the data fields was initiated. Interviews with aeronautics specialists at the EEC allowed data of genuine relevance to be filtered from data of
merely internal importance.
All the collected data had to be stored in a persistent form, so it was decided to
create a database to which the relevant data should be transferred. The choice
between a relational and an object-oriented database was made with respect to
the available database management systems at the EEC. PERL was the chosen
programming language [WCS96] for parsing and extracting information from the
large files, because a freely available database interface exists between PERL
scripts and ORACLE databases.
THE SOFT PROJECT
3
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
1.3
Business Object Developed in this Paper
We are trying to find a means for optimization of the existing ATC system by
defining common, modular and reusable business objects as a design option for
future systems. Following the ideas of Oliver Sims [Sim94] the ATC domain can
be decomposed into prototypical business objects. Focusing on flight plans, as the
central information source for pilot intentions, requirements for the definition of
such business objects have to be detected.
The shift in paradigm from monolithic systems to reusable independent components will result in new architectures for industry-scale systems. The central
objective of this thesis is the definition of a common and reusable business object
to be used in a distributed architecture for the ATC domain. The ATC domain can
be decomposed into prototypical BOs. With special regard to flight plans, requirements for the definition of business objects have to be elicited. This raises the following questions:
• How should the clients’ various requirements be classified?
• What are relevant information sources for the definition of ATC BOs?
• How can the different data formats be adequately reflected in future BOs?
• Which aspects concerning the operational environment of the BO may influence its design?
Consequently, this thesis shall propose business objects for the ATC domain
with special regard to flight plans. On the basis of the “SOFT” project, existing
data sources have to be evaluated and their relationships to requirements defined
by a set of clients/actors have to be studied. The available information sources,
e.g. operational flight plans provided by different airlines, have to be analysed
with respect to their structure and semantics. Relating the requirements of individual actors/clients to the available information analysed in the previous phase
will outline the structural requirements for the BO.
BUSINESS OBJECT DEVELOPED IN THIS PAPER
4
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
1.4
Outline of the Thesis
First I would like to present an introduction to the subject treated in this thesis,
followed by an outline of the problem domain, i.e. air traffic control in Europe, and
in particular the use of flight plans for air traffic flow management and control. In
the first part of this chapter I will describe the current situation including the different phases and format transformations in the existence of a flight plan, its different users, the authorities involved in controlling and managing air traffic as
well as the problems that occur due to the constantly increasing number of flights
in Europe. The second part of the chapter will treat research strategies followed
by the EEC [EMS97] that propose to resolve these problems, followed by a brief
sketch of the research project FREER that might one day bring a complete change
to the way air traffic control is organized.
Then I will describe the benefits of the use of business objects as modular reusable
software structures and I will give a technical description of a BO.
The main part of the thesis begins with the evaluation of the requirements of potential users and clients of such a business object, where the focus remains on structural
aspects. After this, I will give a classification of these requirements.
The classification of the users’ requirements will then lead to the definition of the
eXtended Flight PLan (XFPL) as a business object that integrates the user requirements. For this CBO I will also propose an infrastructure for persistence and state
behaviour. Finally, I will map the object class model to the relational data model that
underlies the construction of the SOFT database.
Then I will propose a strategy for the evaluation this XFPL business object. Finally, I
would like to draw a conclusion from the insights gained through my work at
Brétigny.
OUTLINE OF THE THESIS
5
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
2.
THE PROBLEM DOMAIN
Today airspace users want a more cost-effective and flexible air traffic management (ATM) system which corresponds to their business needs. A new ATM system should provide airspace users with the opportunities for greater flight
efficiency when and where capacity is sufficient. Present systems are becoming
less and less adequate as traffic levels rise. The overriding need for ATM is to
increase productivity and to generate extra capacity in the busiest traffic areas.
Since the aircraft operators know their own flight constraints best, like the optimum altitude, the minimum air distance, the fuel policy followed, or the individual performance of each aircraft, it would be useful to combine knowledge of the
operators and ATM.
2.1
The Situation in Flight Planning Today
Life cycle of a flight plan and its different formats
A filed flight plan is created by an airline, either in an airline operating centre
(AOC) or by the pilot himself to express the flight intention. This flight plan must
be in a standard format, called the ICAO format (the ICAO filed flight plan). It is
sent to the Central Flow Management Unit (CFMU) in Brussels, which has two
sections1 responsible for a first treatment of the filed flight plan: the Integrated
Initial Flight Plan Processing Unit (IFPU) 1 and 2, located in Brussels and
Brétigny-sur-Orge respectively. The IFPU 1 in Brussels takes care of all flights in
the north of Europe while the IFPU 2 handles the south. The Initial Integrated
Flight Plan Processing System (IFPS) performs a syntax check on the filed flight
plans; all fields in the ICAO FPL must be filled out correctly, otherwise the FPL is
handled manually (if possible) or sent back to its originator. Today approx. 60% of
all FPLs can be treated automatically. The IFPU 2 in Brétigny currently handles
2000-2500 FPLs manually per day, with 400-500 reject (REJ) messages.
The ICAO FPL format is then transformed into an internal format called Automatic Data Exchange Presentation (ADEXP) which is the unambiguous basis for
1. IFPU 1 and 2 are fallback systems.
THE SITUATION IN FLIGHT PLANNING TODAY
6
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
trajectory calculation.
From the IFPS, the flight plan is fed into the tactical CFMU system called TACT
that is in charge of allocating departure time slots for those flights in Europe
which pass through regulated areas. In order to do this it calculates a predicted
trajectory for each flight. In superposing all planned flights for one day the system can detect congested areas. Since it is a common fact that there are certain
times of the day and certain routes which are in very high demand, it is the TACT
system’s task to make sure that the maximum capacity of an airspace sector is
not exceeded. If TACT cannot satisfy all requests for slots it has to regulate a
number of flights each day. This means that the pilot is accorded a departure time
different from the one he originally requested.
Once this is done, the airline receives a message informing it that they have
been allocated a departure time slot and the CFMU sends the flight plan, now
with an added trajectory prediction, to all the area control centres (ACC) concerned by the flight, including the departure and arrival aerodromes and departure and arrival approach control centres.
In France, the flight plans are then sent to an initial flight plan treatment system called STIP (Système de Traitement Initial de Plans de Vol), which in turn
distributes the flight plans to the five regional control centres (CRNA).
Each control centre on the way will change the flight plan into an internal system flight plan (SFPL) format and they will perform their own trajectory calculations. At the moment actual trajectories are only updated locally, they are not
sent to the subsequent control centres.
Finally, there is a European office called the Central Route Charges Office
(CRCO), also located in Brussels, that receives all filed flight plans. Each airline
has to pay route charges for using the airspace. These route charges are calculated for each flight in function of the weight category (‘Light’ < 7 tons, ‘Medium’ 7
- 136 tons, or ‘Heavy’ > 136 tons) of the aircraft and of the number of passengers.
With the current situation, several problems occur. On one hand, airline participation and response to airline needs could be improved, and on the other hand
control centres do not receive updated flight plans from the preceding centres to
THE SITUATION IN FLIGHT PLANNING TODAY
7
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ensure a smooth flow of traffic.
In order to improve ATFM, it would also be important to revise the “frozen slot”
concept as it is in use today. Regulated flights receive their departure time slots
two hours before take-off. Allowing slot revisions beyond the current Slot
Improvement Proposal message from the CFMU (SIP) and re-routing in this time
would provide the CFMU and airlines1 with higher flexibility.
The proposed solution allows for an enhanced integration of the air carriers’
business needs into flight planning, it makes sophisticated FMS data accessible to
ATS, and it provides all clients with up-to-date flight information.
2.2
EUROCONTROL Strategy
In this chapter I will give an overview of the general research strategies of the
Eurocontrol Experimental Center, describe the European Air Traffic Harmonization and Integration Program (EATCHIP), and the future European Air Traffic
Management System (EATMS).
EATCHIP was motivated by the need to combat the ATC delays experienced in
the 1980s. While the early stages of EATCHIP focused on the harmonization of
current ATM operations, the constant growth of air traffic and increasing pressure from airspace users to lower the costs of ATM cause the need to develop new
ATM concepts for Europe.
Several technical trends will enable changes in ATM operations, e.g. advances
in communications (use of data link communications), navigation (use of global
satellite systems), surveillance (integrated surveillance networks), data processing (new open connective networks), and more sophisticated FMS capable of optimum 4D trajectory planning.
The target operational concept options range between a ‘managed’ ATM environment based on traffic structuring, greater traffic predictability, longer planning horizons, and extensive automatic support, to a ‘free flight’ system based
mainly on free routings and, eventually, autonomous separation. In practice, the
1. Airlines may, however, send a Ready (RDY) message to indicate that an aircraft is ready
for take-off, i.e. able to take the next free slot.
EUROCONTROL STRATEGY
8
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
EATMS will have to contain elements of different available options to satisfy the
various requirements of all airspace users and the differing types of regional traffic conditions. Some parts of European airspace are among the busiest and most
complex in the world and contain high concentrations of climbing and descending
traffic.
The gate-to-gate strategy that is followed for a future EATMS starts at the
moment the user first interacts with ATM and ends with the switch-off of the
engines. It also includes the processes of charging airlines for the ATM services.
The framework consists of nine elementary phases which represent both the
flight preparation and execution process. Each phase reflects a period of time
where aircraft operators, airport authorities and ATM providers take specific
ATM actions. These phases are: Strategic planning, Pre-tactical planning, Tactical planning, Pre-departure, Departure-taxi, Departure, En-route, Arrival-taxi,
Post flight.
The overall objective of the ECAC gate-to-gate strategy is to define, develop and
implement an integrated ATM concept which will enable a smooth and seamless
process from flight preparation through flight execution to an integrated charging
for service rendered in a cost-effective manner.
FREER
FREER is a research project at the EEC whose main goal is to investigate the
feasibility of the ATM concept according to which ATC responsibilities can be
transferred to the cockpit, exploiting the potential of ADS-B and data-link technology. Future CNS technology will determine the outcome of the FREER project.
It will be interoperable with the Free Flight concept in the USA. The objective of
FREER is to support the users’ needs and to provide them with more flexibility
and freedom regarding airspace use. There are two main studies:
• FREER 1
This is the autonomous airborne mode where ATC responsibilities for aircraft
separation are fully transferred to the cockpit to operate in low-density airspace
or where the ground infrastructure is not fully available.
• FREER2
This is the ground-air coordinated mode designed for high density airspace.
EUROCONTROL STRATEGY
9
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Here the ATC responsibilities are partially transferred to cockpit with assistance
from the ground infrastructure.
Any implementation of FREER would need all aircraft to be equipped with
ADS-B technology. A single aircraft without this system would induce an unacceptable risk factor.
A possible scenario would be that the pilot hands in his preferences and has
them confirmed by ATC, at take-off and at landing he gets in contact with the
respective tower to announce his preferred departure/arrival route.
There are several constraints to the development of FREER, like the dependency upon the range and the contents of ADS-B, the availability of the Cockpit
Display of Traffic Information (CDTI) standard (being developed in the USA), or
the availability of the “Extended Rules-of-the-Air” to be applied in case of conflict.
To a certain scale, these extended rules of the air may have to be developed in
FREER. In parallel to this work, there are developments in the prediction of the
“long term” trajectory of the aircraft, the complete input and output data format
of on-board Flight Management System (FMS), and the functionality of the conflict avoidance function in TCAS-IV.
“Free Flight” in the USA
The Federal Aviation Agency in the USA is working on the construction of a
National Airspace (NAS) Information Architecture that should comprise the processes and components required to manage NAS operational data. The primary
purpose of the NAS information architecture is to manage information efficiently
to support operational decision-making.
In 1994 US government and industry representatives started an initiative
named Free Flight, that they defined as a “safe and efficient flight operating capability under instrument flight rules (IFR) in which the operators have the freedom to select their path and speed in real time. Air traffic restrictions are
imposed to ensure separation, to preclude exceeding airport capacity, to prevent
unauthorized flight through special use airspace, and to ensure safety of flight.
Restrictions are limited in extent and duration to correct the identified problem.
EUROCONTROL STRATEGY
10
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Any activity which removes restrictions represents a move towards free flight.”
[RTCA 95]
While users would be responsible for their flight operations ATC should be
responsible for the services they provide, e.g. separation assurance. In order for
such a system to function, the so-called partnership would rely on shared responsibility and shared data. Accurate, consistent, complete and timely data will be
required by all decision makers sharing responsibility for traffic management and
safety. Users should be allowed to choose departure and arrival times and the
route that suit their needs. Still, some form of underlying structure remains, e.g.
arrival and departure routes. There are four main groups of participants in free
flight:
• On the user side:
•
Pilots
•
Flight planners
• On the service side:
•
Air traffic controllers
•
Traffic flow managers
EUROCONTROL STRATEGY
11
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
3.
BUSINESS OBJECTS:
MODULAR REUSABLE STRUCTURES
In this chapter I would like to introduce the term Cooperative Business Object
(CBO) proposed in [Sim94], or business object for short.
While a business object is an object in the sense of object-oriented programming,
it has to be distinguished from an object used by a developer as a component of an
OO application. A business object is an end product whose size maps to business
items and it can be understood and manipulated by the end user. It provides a
natural way for describing application-independent concepts such as ‘customer’,
‘order’, ‘payment’ etc. It encourages a view of software that transcends tools,
applications, databases and other system concepts. A business object is a self-contained deliverable that has a user interface, state, and knows how to cooperate
with other separately developed business objects to perform a desired task.
I will try to distinguish between an application, a system, a class, and a business object:
• System: A system is a well defined arrangement of structures that mutually
influence each other. These structures can be things as well as thought methods and their results (mathematical methods, programming languages, etc.).
This arrangement is delimited from its environment by a shell. A system program is part of an operating system and it executes service functions for application programs [Sch91].
• Application: An application consists of application programs together with
organizational rules necessary to implement and effectively use the application
program in a specific environment (company, administration etc.). The term
application software designates all programs that are not part of the operating
system. The programs of individual application systems solve the data processing tasks defined by the user’s objectives. They are often tailored for a concrete
data processing machine. Due to their individual adjustment, these programs
are generally useless to other users [Sch91].
• Class: A class is a set of objects that share a common structure and a common
behaviour. A single object is simply an instance of a class [Boo94]. A given class
12
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
typically has two kinds of clients: instances and subclasses. Class instances
may be transient, i.e. they cease to exist when the application is terminated.
• Business object: Although a BO is an object (a class instance), it is not limited to a single application or a single system. Usually, individual programming
language classes that form an application cannot be manipulated from outside
this application, it is usually not persistent, and it cannot be used in another
application. A BO is persistent, it has a consistent state (e.g. in a database),
and provides data consistency through a transaction mechanism. A BO is
encapsulated like any other object and it can be used in heterogeneous applications and systems through a middleware layer that provides the necessary
logic and services. In the OMG Object Management Architecture (OMA) they
are called common facilities [OHE96]. The middleware services let various BOs
communicate with each other, so that there will be no single application, but a
collection of business objects that together perform the needed tasks. For the
work of the business objects it will be irrelevant which hardware or operating
systems are installed beyond the middleware layer.
So a CBO can be defined as an application-level component that can be used in
an endless series of new combinations, independent of any single application
[Pri96].
It is not sensible to introduce new technology into a business environment without any concrete necessity. If, on the other hand, the business demands new solutions due to changes in the business domain, these solutions will attract the use
of new technology. In this case we would like to build an object-oriented architecture and model business domain objects as a means of applying modern information technology in ATC.
Such cooperative business objects are a new development in application structuring: in theory, the CBO is a deliverable in itself, it is concurrently executable
and able to run in distributed heterogeneous computing environments. In order to
find business objects in a particular domain one may examine the external parties
the organization deals with, such as suppliers, customers, distributors etc. The
products and services that the organization sells or buys as well as the resources
that are necessary in the production process are also potential business objects
13
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
[YWT+95].
Reusing the objects from the user’s problem domain saves significantly on the
system design, documentation and training effort.
Properties of an object
One usually distinguishes between static and dynamic properties of an object.
While the actions that can be performed on an object belong to the static properties, the pre- and post-conditions valid for these actions belong to the dynamic
properties. The object’s attributes (static) necessitate a data validation logic
(dynamic) that will for instance refuse illegal attribute contents. Finally, the triggering events from and interactions with other objects (static) can be shown in a
finite-state-machine (dynamic) to model the behaviour with an original state, the
performed action and the condition applying to the action.
Developing a cooperative business object
First one should describe an operational model of the business and identify the
business domain items; the architecture of the information system will reflect
these same objects internally and externally. So the OO information system may
be regarded as the operational model of the business. Users will find the objects in
the graphic user interface and will see the attributes and actions available under
these objects while location, storage, and retrieval remain transparent to the
user.
Definition of a cooperative business object1
• It is an object just like any object in OO programming, i.e. it is encapsulated, it
can be part of an inheritance hierarchy, it has class and instance data, and it
sends messages to other objects.
• It is a deliverable; it is the end product of the software development process,
delivered to the end-user, and it can be identified as an execution unit. A single
CBO can be executed by itself, needing only its superclasses.
• It is an independent software executable; it can be executed by itself independently from other CBOs by some build-time process. Such CBOs are loosely
1. cf. [Sim 94].
14
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
bound and can be packaged independently from other CBOs.
• It is language-neutral, i.e. it can be written in any language, object-oriented or
procedural. An implication of language neutrality is of course, that the language in which a CBO is written is irrelevant to the underlying infrastructure.
• CBOs are easy to integrate; in order to integrate applications they must have a
mechanism to communicate, and a mechanism for data exchange, i.e. there
must be a common syntax (data types) and semantics (data meaning) of interchange. Since CBOs are objects that use messages to interact, they fulfil the
first of these two requirements. For data exchange binary interfaces are
needed, e.g. provided by the interface definition language (IDL) in CORBA.
IDLs are probably best employed where high performance is required regardless of other considerations such as ease of programming, or where middleware
is being built. An alternative would be a self-defining data stream, together
with sophisticated build and parse support. In using the latter, one trades performance (which may be provided by an IDL) for run-time type evaluation provided by self-defining data, but there will be no recompile or relink necessary
when using another CBO for the first time, and there is run-time dynamic
binding for the data.
• CBOs are message- or event-driven; by using messages for communication
with other objects there is no difference between local and remote CBOs, synchronous as well as asynchronous messages can be sent, objects can send messages to themselves or to their superclass, and all events are transformed into
a common message form by the CBO infrastructure.
• A CBO is location-transparent; i.e. the programmers need not consider if a
CBO is in the same or in a different thread, process, or system. Specifically, the
target may be written in another language, it may be running on another operating system, or reside at the other side of a wide-area network (WAN).
• It is written in code that is serially reusable, so as to avoid unnecessary blocking of the thread or process in which it runs.
• It is persistent; but without the use of an effective and pervasive OO database
the system has to provide for CBO persistence, where required. This can be
achieved via system-provided superclasses, and then the programmer is
handed CBO persistence by default. The system provides a persistence data-
15
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
base and a framework for persistence. At closing or restoring of an object, a
CBO can override superclass behaviour to handle its own saving or restoring
procedures if necessary. So CBOs are persistent unless the programmer overrides the persistence framework or unless subclassed from a non-persistent
class.
• It requires a software infrastructure, since the CBO infrastructure is a runtime layer of software, together with several superclasses from which CBOs
can inherit common behaviour. In order to maintain a certain ease of programming it is important to provide a set of base classes which include appropriate
frameworks.
16
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
4.
REQUIREMENTS DEFINITION FOR A FLIGHT PLAN
BUSINESS OBJECT
The requirements section considers eight potential clients for an extended flight
plan; three of them are research projects of the EEC that might benefit from
enhanced flight plan information. In addition to these clients, I have described
the elements of the so-called “New Age” flight plan, a project at the FAA, to indicate that the US are also putting efforts into improving data exchange between
the air carriers and ATS. Once these requirements have been listed, the second
part of this chapter contains a classification that will allow the construction of an
object that encompasses all the necessary data in an adequate structure.
The requirements listed here are divided into structure and behaviour according to the object paradigm as described in [Boo94]. Since this thesis concentrates
on the structural aspects of an XFPL format, I will not model use cases and life
cycle behaviour. In order to understand the different users’ needs I had to identify
their requirements with the help of interviews and documentation. The requirements of airlines, airports, radar control, the CFMU and the CRCO have been
identified mainly through requirements documents [AP95, EAF96], the CFMU
Handbook [CFMU96], and questioning of ATC specialists at the EEC. In order to
identify the requirements of DIFODAM, BADA, and FREER with respect to flight
plan formats, I have interviewed the respective members of the projects.
By letting all relevant stakeholders participate in the design process we can
achieve more effective systems. This is why the data modelling process should not
be considered a purely technical task, but one that requires understanding of the
different users’ needs and the integration of requirements and views into one
solution. The requirements gathered here will allow the definition of relevant
attributes and member functions that an XFPL business object will contain. The
distinction between objects and attributes depends on the chosen level in the
analysis phase. In the OMT notation that I will use for modelling [RBP+91]
attributes are interpreted as data carried around by an object. Generally,
attributes are simply values uniquely associated with each object.
During analysis, attributes have a logical character and it is therefore not necessary to interpret these values as specific data types. Attributes can be identified
17
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
by the following criteria [YWT+95]:
• Attributes represent data which has to be remembered by an object.
• Attributes do not have an independent existence, i.e. they are an integral part
of a given object.
• All attributes of a class should apply to each instance of the class.
• Implementation constructs such as linked lists should be eliminated. This
guideline will lead to the separation of “Flight Plan” and “Trajectory”.
• Also, one should beware of objects whose names are ‘window’, ‘scroll bar’,
‘menu’ etc. These may be objects that are necessary for the user interface and
are therefore related to the design phase.
4.1
User Requirements
The different requirements may be divided into structural requirements, which
relate to the kind of data that is needed, non-behavioural requirements, which
designate the necessary quality of the data, and behavioural requirements,
which indicate the needed timely behaviour of the data. I will however concentrate on requirements that are relevant for the design of an XFPL format and
therefore leave out most of the data that is already communicated to ATM via the
ICAO FPL, since the proposed extended flight plan format will comprise all the
data items of the current ICAO format [ICAO85].
The gathering and classification of the user requirements is done in the perspective of finding objects, attributes and methods from three different perspectives:
the data, the functional and the behavioural perspective.
4.1.1
Airlines
A general requirement of all airlines is that they wish a more cost-efficient and
flexible ATM system capable of responding dynamically to their operational and
business needs. A gate-to-gate service as well as AOC-requested flexible and
dynamic trajectories would help to make the airlines’ operations more cost-efficient. The airlines and their aircraft operations centres would benefit from new
means of communication with ATC to provide them with increased flexibility of
airspace use.
USER REQUIREMENTS
18
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
If it was common practice for an airline to ask ATC to re-route a flight that had
been delayed (e.g. because of the high traffic load on the departure aerodrome) the
pilot might be able to compensate for a part of the delay en-route, thus avoiding
inconvenience for the passengers. So if the airline could change the route in the
FPL and if ATC could react to the airline’s needs by recalculating the aircraft’s
trajectory and alerting the other concerned control centres, progress would have
been made.
• Structural requirements:
•
The planned take-off and arrival times.
•
The planned take-off and arrival aerodromes.
•
A list of alternative arrival aerodromes if the first choice is not available, e.g.
due to bad weather.
•
Acceptable delays for take-off and landing due to slot allocation.
•
A preferred route and an alternative route if the first choice should be subject
to regulations.
•
A preferred runway.
• Non-behavioural requirements:
•
The communicated data should increase flight safety.
•
The data format should be adaptable to technological changes.
•
The FPL should be processed automatically.
•
There should be an effective use of airspace.
• Behavioural requirements:
•
It should be possible to use the FPL in interoperable systems.
•
The deadline for filing should be closer to take-off time.
•
There should be the possibility to change an FPL after initial filing.
•
The flight plan should allow for an orderly flow in increasing traffic.
•
The transmitted data should allow for more efficient traffic flow.
4.1.2
Airports
The requirements in this section refer to the airport technical services. Three
important parts of the air transport system interact here: the airport, the airline,
and the passenger.
USER REQUIREMENTS
19
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
As to the requirements of airports, it can be said that they could do more efficient planning if they were aware of changes in the scheduled arrivals, i.e. if they
shared updated data with the ACCs. This way, an airport would know earlier
about impending delays and re-routings.
• Structural requirements:
Table 2: List of data required by airports
Description
Source
Estimated arrival/departure time
CFMU TACT system or OFPL
Type of flight (charter, domestic,
EU, international)
CFMU or OFPL
Type of aircraft
ICAO FPL
Amount of cargo and way
of loading
OFPL
Number of passengers
Airline Operations Centre
Type and duration of delays
ACC or CFMU TACT system
ATC slot
CFMU All_Flights plan
Environmental information
CFMU ENV system
• Non-behavioural requirements:
•
There should be better information on charter flights.
•
There should be better information about delays.
•
The estimated times of departure and arrival should be precise.
•
The booking figures should be exact.
• Behavioural requirements:
•
The continuous availability of stored ATC flight plans should be guaranteed.
•
Certain standard company procedures should be defined.
•
There should be permanent contact with airline branch staff.
4.1.3
Area Control Centres
There are different forms of radar control: the airport tower (TWR), approach
control (TMA), and the en-route or area control centres (ACC). This section will
only consider the ACC. There are five en-route control centres in France, called
“Centre Régional de la Navigation Aérienne”: the CRNA Brest, Bordeaux, AthisMons, Aix-en-Provence, and Reims. Approach control takes place in a mini-ACC
USER REQUIREMENTS
20
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
usually situated on the departure and arrival aerodrome or in an ACC, but separated from the tower.
Airspace control centres need up-to-date information about each aircraft that
will enter one of their sectors. Control centres use so-called system flight plans
(SFPL) that contain a subset of the ICAO FPL data items and a predicted trajectory for each aircraft. This trajectory prediction is currently done separately in
each ACC, with different algorithms. Every control centre should be able to
update their system flight plans and hand them over to the next concerned centre.
This of course requires a common format for the system flight plans. In France,
this format is called COURAGE; all five CRNA use it. If the control centres had
access to additional information about a given flight, like the take-off and landing
weights or the four-dimensional trajectory calculated by the AOC, they could calculate a more realistic trajectory prediction.
• Structural requirements:
Table 3: List of SFPL Items
SFPL Data Item
Description
Source
Aircraft callsign
Filed flight identifier
FPL
Flight rules and type
The rules under which the
flight will proceed.
FPL
Number of aircraft
The number of aircraft
making up the flight
(usually 1, except military).
FPL
Type of aircraft
The aircraft type.
FPL
Airport of departure
The airport from which the
flight is departing.
FPL
EOBT
Estimated off-block time.
FPL
Cruise speed
The speed at which the flight
will proceed when at cruising
altitude.
FPL
Requested flight level
The flight level the flight
wishes to cruise at.
FPL
Route
The route of flight between the
departure and destination
aerodromes.
FPL
USER REQUIREMENTS
21
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Table 3: List of SFPL Items
SFPL Data Item
Description
Source
Destination
The point of first intended
landing.
FPL
Total estimated flight
time
Estimated flight time from
take-off to landing.
FPL
Communication,
navigation, and
approach facilities
Avionics equipment level for
the flight.
FPL
SSR facilities
SSR capabilities of the flight.
FPL
Previous SSR code
The SSR code on which the
flight is responding while it is
under control of an upstream
ACC.
upstream ACC
Next SSR code
The SSR code of the aircraft to
which the flight will respond
when under the control of the
next downstream unit.
downstream ACC
Assigned SSR code
The SSR code that has been
assigned to the flight.
Core function, or
operator
Diversion airport(s)
The airport to which the flight
may divert.
FPL
SFPL route
The route the flight is
expected to fly after the
application of rules and
constraints.
Trajectory prediction
ATC tactical
constraints
Constraints entered by a
controller for a specific flight.
Controller
Specific flight
performance data
The rates of climb, descent,
and other specific aircraft type
related data.
Aircraft operators
Expected trajectory
The set of 4-dimensional
points that describe the
expected profile of the flight.
Trajectory
prediction
Alternative trajectory
The set of 4-dimensional
points that describe the
expected profile of the flight
when other constraints and
SFPL data are applied.
Trajectory
prediction
USER REQUIREMENTS
22
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Table 3: List of SFPL Items
SFPL Data Item
Description
Source
Co-ordination sector
list
A list of sectors expected to
coordinate the flight.
Trajectory
prediction
Notified sector list
A list of the sectors to be
notified of the flight.
Trajectory
prediction
Traversed sector list
A list of the sectors expected
to be traversed by the flight.
Trajectory
prediction
SFPL states
The life-cycle state of the
SFPL.
Basic functionality
Current position
The current position of the
flight in relation to the
expected trajectory.
Basic functionality
Correlation state
The correlation between a
radar track and a SFPL.
Basic functionality
and controller input
Co-ordination states
The co-ordination state for
each leg of the flight.
Basic functionality
The structural requirements of a control centre are adequately explained by this
list of system flight plan items [ADEX93].
• Non-behavioural requirements:
•
Accuracy of the trajectory, with respect to time, vertical position, lateral position, speed [EAF96, Vol 1, p. 4-14f.].
• Behavioural requirements:
•
Reception of flight plans ~10 min. before the aircraft enters the controller’s
sector.
•
The recalculated trajectory should be communicated to the subsequent centres.
•
The SFPL global state (initial, notified, active, terminated) should be communicated to all ACCs.
•
There should be an assured separation between aircraft.
•
Pilots have to be provided with relevant information (meteorological hazards,
airspace restrictions).
•
The flight plan data should assist the controller in abnormal situations.
•
The flight plan should help provide tactical ATM.
USER REQUIREMENTS
23
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
4.1.4
BADA
The Base of Aircraft Data (BADA) is an aircraft performance database developed
and maintained at the EEC. This database has been developed using operating
manuals, flight manuals etc. as reference sources.
Its main application is in trajectory simulation and prediction in the ATM
domain. BADA uses a “Total Energy Model”, i.e. a reduced point-mass-model that
ignores the four forces thrust-drag-lift-gravity. There are 165 different aircraft
models in the database, which corresponds to ~90% of European air traffic.
• Structural requirements:
Table 4: List of data items required by BADA
Description
Source
ICAO filed flight plan data
ICAO FPL
List of waypoints
OFPL
Waypoint latitude coordinate
OFPL or database of all beacons
Waypoint longitude coordinate
OFPL or database of all beacons
Time flown between waypoints
OFPL
Ground speed for each trajectory
point
OFPL
True air speed for each trajectory
point
OFPL or own calculation
Mach number over waypoint
OFPL or own calculation
Flight level over waypoint
OFPL
Taxi fuel
OFPL
Take-off weight
OFPL
Landing weight
OFPL
Zero Fuel Weight
OFPL
Aircraft heading
OFPL
Flight distance
OFPL
Fuel burn
OFPL
Wind magnitude
OFPL or meteorological data database
Wind heading
OFPL or meteorological data database
Total flight time
OFPL
USER REQUIREMENTS
24
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
• Non-behavioural requirements:
•
The aircraft weight should be precise.
•
There should be precise 4D trajectories.
•
The trajectory should be calculated without consideration of expected meteorological conditions.
• Behavioural requirements:
•
The flight plans should be stored in a persistent form.
4.1.5
CFMU
There are two central operational divisions in the CFMU: Flight Data Operations (FDO) and the Central Executive Unit (CEU). The FDO division is responsible for the acquisition and treatment of data and is divided into several
departments:
• Integrated Initial Flight Plan Processing System (IFPS)
• CFMU Strategic System (STRAT)
• ATS Infrastructure database (ENV)
• Archive System (ARC)
The CEU division is responsible for all aspects of ATFM planning, coordination
and execution. It is divided into the following sections:
• Tactical System (TACT)
• Aircraft Operators Liaison Cell
• Flow Management Positions (FMP)
The CFMU [CFMU96] provides ATFM for the ECAC region; ATFM activities
can be divided into three phases:
Strategic: up to two days before the flight,
Pre-tactical: during the two days before the flight,
Tactical: the day when the flight takes place (before/after departure)
The general requirement of the CFMU is that it has to be notified by all aircraft
operators as early as possible and on a regular basis of all planned flight operations which are scheduled prior to the day of operation, will operate either into,
USER REQUIREMENTS
25
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
within, through, or out of the area covered by the CFMU operations, and require
ATS. The responsibility for notification of flight data lies with the aircraft operator.
• Structural requirements:
Table 5: Data items requested by the CFMU
Description of data items
Source
Callsign
ICAO FPL
Aircraft type
ICAO FPL
Period of operation (date of operation for a single flight)
ICAO RPL
Day(s) of operation
ICAO RPL
Frequency of operation
ICAO RPL
Departure airport
ICAO FPL
Requested departure time in UTC
ICAO FPL
Airport of first intended landing
ICAO FPL
Requested arrival time (UTC)
ICAO FPL
Name of AO who is operating the
flight if different from the sender
ICAO FPL
Preferred route
ICAO FPL
Requested light level
ICAO FPL
Requested air speed
ICAO FPL
•
Non-behavioural requirements:
•
Ghost and duplicate flight plans should be avoided, i.e. only one flight plan
per flight.
•
Behavioural requirements:
•
A flight plan for a flight should be provided to ATS at least 60 minutes prior
to departure (general ICAO requirement).
•
Flights subjected to ATFM measures should submit their flight plans at least
three hours before EOBT.
•
Any changes to the EOBT of more than 15 minutes shall be the subject of a
modification message by the CFMU (e.g. SIP).
USER REQUIREMENTS
26
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
•
A flight plan which replaces a RPL or a previously filed flight plan designated
as a replacement flight plan, shall be filed at least 30 minutes before EOBT.
•
The flight plan originator should cancel a flight plan as soon as he/she knows
that the flight is not going to take place.
•
The flight plan originator should cancel an existing FPL before filing a replacement FPL for the same flight.
4.1.6
CRCO
The Central Route Charges Office in Brussels collects fees from airlines in function of the flown route and the weight category of the aircraft. At the present
time, there are only the three weight categories Light, Medium and Heavy.
• Structural requirements:
Table 6: Data items required by the CRCO
Description of the data
Source
City pair: ADEP/ADES
ICAO FPL
Time of departure/arrival in UTC
ICAO FPL
Callsign
ICAO FPL
Day of operation
ICAO FPL
Type of aircraft
ICAO FPL
Aircraft operator
ICAO FPL
Weight of the aircraft
BADA database
Number of passengers
Airline operations centre
Filed route
ICAO FPL
Actually flown route
CFMU
• Non-behavioural requirements:
•
A data format that allows automatic processing is needed.
•
The aircraft weight should be accurate.
•
The number of passengers should be precise.
•
The route description should be complete.
• Behavioural requirements:
•
The reception of all flight plans upon termination of the flight should be performed automatically (from CFMu ARC system).
USER REQUIREMENTS
27
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
4.1.7
DIFODAM
The EEC research project Distributed and Fault Tolerant Flight Data Management (DIFODAM) proposes a client/server architecture which gives all ACCs
access to a shared flight plan and trajectory through the use of event filtering,
dynamic access rights, and a notification server, thus realizing a gate-to-gate view
for each flight.
There is a base class “Shared Flight Plan” from which all kinds of flight plans
may inherit, so that DIFODAM has no requirements to the original structure of a
flight plan.
• Structural requirements:
Table 7: Data items required by DIFODAM
Description
Source
All flight plans should be available
in DIFODAM
Airline or CFMU
ICAO FPL items
Airline or CFMU
Creator: reference to a registered
client
A DIFODAM client
Owner: Rotating right to modify
the FPL
A DIFODAM client
Version number
DIFODAM
Date of creation
Airline operations centre
Reason for creation
Airline operations centre
Official/temporary version
A DIFODAM client
Waypoint latitude coordinate
OFPL or beacon database
Waypoint longitude coordinate
OFPL or beacon database
Time over waypoint
OFPL or SFPL
Flight level over waypoint
OFPL or SFPL
Speed over waypoint
OFPL or SFPL
• Non-behavioural requirements:
•
There should be a validity check on trajectory modification.
•
A reliable distributed database is needed for flight plan persistence.
•
The flight plan data should be shared between all users.
USER REQUIREMENTS
28
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
•
The system should be fault tolerant.
• Behavioural requirements:
•
All the clients should be registered with DIFODAM.
•
There is a difference between READ and READ/WRITE access.
•
The right to modify an FPL should be exclusive.
•
Different versions of an FPL (official/temporary version) should be available.
•
The first version is created by the IFPS.
•
After the actual time of arrival of the flight the flight plan should only be
stored for a fixed length of time.
•
During flight, ETO points of the trajectory become ATO points.
•
A new trajectory should be computed after deviation or delay.
•
The system should support 30,000 FPL creations/day.
•
The system should allow 200 updates per FPL.
•
The delay between an update and the notification of the other clients should
be < 1min.
4.1.8
FREER
The data items listed here would be exchanged via an air/ground data link.
• Structural requirements:
Table 8: Data items required for FREER
Description
Source
Registration
Airline or FMS
Callsign
Airline or FMS
Aircraft type
Airline or FMS
Preferred STAR
Airline or FMS
Preferred SID
Airline or FMS
Preferred route, consisting of:
FMS or AOC
•
•
•
list of LAT/LONG coordinates
list of flight levels over the WPT
speed over each point
Applicability area
CFMU systems
ADS-B data
Aircraft
USER REQUIREMENTS
29
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Table 8: Data items required for FREER
Description
Source
Advance information of the reserved
(military) airspace
CFMU systems
Uniform weather information
CFMU meteorological database
•
Non-behavioural requirements:
•
There should be a certification possibility for a preferred route.
•
A long term prediction of the aircraft trajectory is necessary.
•
There should be accurate pilot “intent” information.
• Behavioural requirements:
•
The trajectory should be dynamically updated, thus allowing re-routing and/
or dynamic modification of trajectory in the free-route/user-preferred route
context.
•
There should be message exchange between ATC and cockpit.
4.1.9
FAA’s “New Age Flight Plan”
I would like to mention the efforts being made in the USA with respect to flight
planning to demonstrate how the FAA arrives at different solutions in a different
context. In the United States too, government and industry have recognized the
need for enhancing the ground-to-ground information exchange capability
between ATM and Aeronautical Operational Control, as well as the potential benefits from this exchange. They hope to enable more efficient, smoother traffic flow
by increasing the accuracy and predictability of system operations. In this scenario, ATM will have real-time dynamic information about user demand to help
determine the best use of available capacity. The information exchange will rely
on air/ground data link technology.
The new initial flight plan contains all the data items from the ICAO FPL plus
the following:
• Planned take-off weight
• Intersection take-off capability
• Time to top of climb
USER REQUIREMENTS
30
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
• Preferred departure runway
• Runways the flight is capable of using
• Acceptable delay for preferred runway and/or route
• Unacceptable runways
• Alternate route if preferred route is not available
• Planned landing weight
• Preferred landing runway
• Acceptable delay waiting for preferred runway
• Unacceptable landing runway
• Approach and landing minimal capability for aircraft and crew
• Description of alternate route
• EETs on alternate route
Once the initial flight plan has been filed, amended flight plans (APL) may be
filed up to a predetermined time prior to the proposed departure time. Once a
flight is en- route, revised or rerouted flight plans (RPL) may be filed to allow for
point-aloft replanning (due to weather, ATM constraints, technical needs etc.)
Furthermore, the airline will transmit a departure plan (DPL) with updated
and expanded information for the departure and en-route phases of flight. It contains the following information:
• Departure plan ID
• Aircraft type
• Proposed departure time
• Planned take-off weight
• Preferred departure runway
• Unacceptable runway
• Acceptable delay for preferred runway and/or route
• Alternate route if preferred route is not available
• Planned, preferred, or optimal climb schedule
• ETA at significant points along the route of flight
• ETA at destination
Once the flight is en route and near its destination, the airline will transmit a
landing plan (LPL) with updated and expanded information for arrival at the des-
USER REQUIREMENTS
31
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
tination airport. This plan contains the following items:
• Landing plan ID
• Aircraft type
• Planned touchdown time
• Estimated/actual current weight, planned landing weight
• Planned, preferred, or optimal descent schedule
These departure and landing plans are supposed to optimize traffic flow around
the TMA, where congestion problems exist. In the US, en-route congestion does
not generally exist. I have only listed the structural requirements for a “New Age”
flight plan. The behaviour and quality of the data will depend on the air/ground
data link that will be used to communicate the flight plans in this scenario.
4.2
Classification of User Requirements
Due to the very complex processes in the ATC application domain there seems
to be a great variety of different requirements. The requirements listed in the previous sections can nevertheless be refined and thus categorized with respect to
their structure, behaviour, distribution, and the access rights for each user.
The distinction between structure and behaviour is characteristic for object-oriented analysis and design. The distribution aspect of flight plans is another
important point because flight plans are used in the many different ATC systems
in the ECAC region.
Finally, the access rights and the frequency of access to flight plans have to be
defined correctly, because not every user has the same rights to modify a flight
plan and some items will probably be accessed and changed many times. The trajectory, on the other hand, will possibly be changed several times.
Among all the different client requirements there are some that cannot be satisfied directly through the flight plan structure, behaviour, distribution, or access
rights. These more general requirements demand an efficient organization of ATC
systems and well-defined client procedures, and they are therefore not included in
this section. The data items and needed functionalities collected here will allow
me to define a common flight plan format for all users, and to develop this format
as a business object, with its attributes and methods, in the next chapter.
CLASSIFICATION OF USER REQUIREMENTS
32
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
• Structure of a flight plan
In order to identify a classified set of structural requirements we can follow a
certain procedure: The different users often require the same structural data, e.g.
the aircraft callsign. Thus repeating requirements could be eliminated as a first
step. Then those requirements that need not be included in the flight plan information should be discarded, e.g. data that will only be available in a future scenario (FREER), data that belongs to internal client systems (sector names in an
ACC), or redundant data that can be calculated when needed (machnumber speed in knots). Finally, it is possible to group requirements that have a strong
semantic relation, and only give different values for the same unit, such as estimated and actual times for departure and arrival.
The structural requirements in the table below refer to data that may be either
unchangeable after filing, and data that may change one or many times after filing or as the flight progresses. It is obvious that certain data elements cannot be
changed after filing, such as the departure airport. On the other hand it is an
important requirement that certain other data should be updated after filing,
such as the trajectory and meteorological information.
The table below lists different requirements that refer to the departure and
arrival times, the estimated and actual total elapsed times. and to the first
requested and alternative arrival aerodromes. These required data as such
should not be changed after filing, but it is possible to unify them into one single
data field. Instead of indicating static information such as “planned take-off time”
and “allocated take-off slot time” etc. it is possible to simply indicate the “take-off
time”. This take-off time would at first be the take-off time as planned by the airline. Then the calculated take-off time by the CFMU would replace this initially
indicated time, and finally the actual take-off time may replace the slot time if the
two are not the same. Every change in the exact semantics of the attribute “takeoff time” should be tracable through the version number and the state of the flight
plan object.
The same could be done for the “estimated total elapsed time” and the “actual
total elapsed time”. It would be sufficient to indicate a “total elapsed time”, that
may be updated if delays occur.
CLASSIFICATION OF USER REQUIREMENTS
33
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Also, the planned and actual arrival times could be expressed as an “arrival
time” that may be updated, and the arrival aerodrome could be updated if the
first requested aerodrome is unavailable and the aircraft has to land on an alternative aerodrome.
Table 9: Classification of structural requirements
Data item
Description
Source
Possible
update
after filing?
Flight plan ID
Unique ID number for
the flight plan
IFPS
No
Day of operation
Date of the flight
Airline AOC
No
Callsign
Callsign of the aircraft
Airline AOC
No
Registration
Tailnumber of the
aircraft
Airline AOC
No
Type of flight
Domestic, charter, EU,
etc.
Airline AOC
No
Type of aircraft
Aircraft type in ICAO
code abbreviation
Airline AOC
No
Equipment
Communication,
navigation, approach
Airline AOC
No
SSR code
SSR code assigned to
the aircraft by an ACC
Each control
centre
No
Number of
aircraft
Usually one
Airline AOC
No
Flight rules
Instrumental or visual
Airline AOC
No
Wake turbulence
category
Light, Medium or Heavy
Aircraft model
database
No
Departure
aerodrome
ICAO code abbreviation
for the ADEP
Airport
database
No
Arrival
aerodrome
ICAO code abbreviation
for the aerodrome of
first intended arrival
Airline,
Airport
database
Yes
Alternative
arrival
aerodrome
The arrival aerodrome
in case the first intended
one should be
unavailable
Airline AOC
Yes
CLASSIFICATION OF USER REQUIREMENTS
34
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Table 9: Classification of structural requirements
Description
Planned take-off
time
Take-off time as planned
by the airline before slot
allocation
Airline AOC
No
Allocated
take-off slot
time.
CTOT allocated by the
CFMU
CFMU
Yes
Actual take-off
time
Actual take-off time in
UTC
Departure
airport
No
Planned arrival
time
The arrival time in UTC
as planned by the airline before take-off
Airline AOC
No
Actual arrival
time
Actual arrival time in
UTC
Arrival
aerodrome
No
Total estimated
flight time
Total time of the flight
in hours:minutes as
planned by the airline
Airline or FMS
No
Actual total
flight time
Actual total time of the
flight in hours:minutes
Arrival
aerodrome
No
Acceptable delay
for take-off
The delay the airline is
willing to accept
between the demanded
TOT and the allocated
slot time
Airline AOC
No
Preferred
runway
The runway the pilot
wishes to use for
take-off/landing
Airline AOC
No
Number of
passengers
Exact number of
passengers on the flight
Airline branch
office at ADEP
No
Planned route as
4D trajectory
The trajectory of the
aircraft with the
LAT/LONG
coordinates, the flight
level, and the time for
each waypoint
Airline or FMS
Yes
CLASSIFICATION OF USER REQUIREMENTS
Source
Possible
update
after filing?
Data item
35
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Table 9: Classification of structural requirements
Data item
Possible
update
after filing?
Description
Source
Alternative
route as 4D
trajectory
An alternative route in
case the first chosen one
should be subject to
unacceptable
regulations or
unavailable.
Airline or FMS
Yes
Requested cruise
flight level
Flight level as requested
by the airline
Airline AOC
No
Requested cruise
speed
Cruise speed as
requested by the airline
Airline AOC
No
Taxi fuel
Amount of fuel intended
for taxiing on the ADEP
Airline AOC
No
Take-off weight
Planned take-off weight
Airline AOC
No
Zero fuel weight
Weight of the aircraft
with empty tanks
Airline AOC
No
Landing weight
Planned landing weight
of the aircraft
Airline AOC
No
Wind heading
Wind direction relative
to the aircraft’s heading
FMS
Yes
Wind magnitude
Wind force at the
current flight level
FMS
Yes
Outside air
temperature
Temperature at the
current flight level
FMS
Yes
• Behaviour of a flight plan
Here I will list those behavioural client requirements that need to be considered
in the design of an XFPL CBO in order to solve the given problems. There are several coinciding requirements from different clients that could be unified in one
single requirement.
•
The deadline for filing should be closer to take-off time. This is an airline requirement; it should be satisfied in order to increase the airlines’ planning
flexibility.
CLASSIFICATION OF USER REQUIREMENTS
36
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
•
It should be possible to change the filed flight plan. This is another airline requirement with the same goal as the one mentioned above.
•
The flight plan should be continuously available and persistent. This is a general requirement from all users, and it is therefore necessary to provide a
mechanism for permanent flight plan access and persistence.
•
The flight plan should have global states throughout its life cycle. This is required by the ACCs and by the CFMU. By implementing well-defined life cycle behaviour we can assure access control to each flight plan.
•
The flight plan originator should cancel a flight plan as soon as he/she knows
that the flight is not going to take place. This is a CFMU requirement. By assuring that each flight is represented by exactly one flight plan, we can avoid
so-called “ghost” flight plans that interfere with ATFM performance.
•
The flight plan originator should cancel an existing flight plan before filing a
replacement flight plan for the same flight. This is another CFMU requirement that is closely related to the preceding one. In addition to the cancelling
mechanism mentioned above, this requirement asks for an explicit replacement mechanism. This behaviour will allow exactly one flight plan per flight
at a given time.
•
There should be the possibility for dynamic trajectory updates after regulation or delay. This is required by the ACCs and by FREER. It is important to
fulfil this requirement because updated trajectories are essential in enhancing the controllers’ work.
•
During the flight, the planned trajectory points should be updated and
marked as realized trajectory points. This is a DIFODAM requirement that
will allow every user to observe flight progress.
There are also several requirements that have not been selected for the required
flight plan behaviour. There are ACC requirements that do not concern flight plan
behaviour as such; those requirements have to be satisfied by handover procedures. Furthermore, the requirement that the CRCO should receive all flight
plans automatically upon termination of each flight is a function that has to be
implemented within the CRCO system. The FREER requirement that there
should be a message exchange between cockpit and ATC refers to data-link technology and not to the actual flight plan format. Finally, there are DIFODAM
CLASSIFICATION OF USER REQUIREMENTS
37
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
requirements that rather concern system performance (FPL/day).
• Access rights for the users
The requirements listed here have been selected from those clients’ behavioural
requirements that relate to access control for flight plans. All the requirements in
this section originate from DIFODAM requirements, since DIFODAM proposes
an architecture with well-defined client roles and rights.
•
Each flight plan has one creator. This is a DIFODAM requirement that refers
to the flight plan’s life cycle behaviour - only a pilot or an AOC may create a
flight plan.
•
The creator should have the possibility to modify a flight plan after filing and
send a new one. This DIFODAM requirement extends the “modify flight plan”
requirement from the behaviour section. It limits the right to modify and revise a flight plan upon filing to the creator.
•
Each flight plan has a current owner who holds the access token that allows
him/her to modify the flight plan. This is another DIFODAM requirement
that asks for the implementation of a state behaviour with controlled read/
write access.
•
Each flight plan has a version number that will be updated. This is also a DIFODAM requirement. Recording the different versions of a flight plan is useful in combination with controlled state behaviour.
•
The right to modify a flight plan is exclusive. This is an essential requirement
from DIFODAM. It requires an access token mechanism. This would allow for
consistent client views because any modification by a client would first result
in an update of the database model and consequently in a client view update
before the access token is passed on to the next client.
•
Depending on the user, there should be either READ or READ/WRITE access.
This DIFODAM requirement is important because it requires the definition
of different client roles and consequently the implementation of individual
client rights.
•
Access to a flight plan should be possible at any time during the flight plan’s
existence. This is another DIFODAM requirement that requires particular
infrastructure services.
CLASSIFICATION OF USER REQUIREMENTS
38
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
•
All users should have access to changes in a flight plan immediately after
these changes have been made, which could be provided via an event notification service. One last DIFODAM requirement, this one also refers to an infrastructure capability.
• Flight plan distribution
•
There should be different interfaces for different users who have their own
specific needs. This is a general requirement from all clients, and it is important to respect this requirement for the realization of a common format with
individual client views.
•
The flight plan should be stored in a persistent form at one or more locations
that are transparent to the user. This requirement from DIFODAM extends
the more general requirement for persistence. The transparent access to
flight plans is another service that has to be provided by the infrastructure.
•
It should be possible to use the flight plan in interoperable systems. This requirement comes from the airlines, but it is also a general requirement, that
results from the fact that there are many different heterogeneous systems in
the ECAC region using flight plans.
CLASSIFICATION OF USER REQUIREMENTS
39
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
5.
DEVELOPMENT OF AN XFPL BUSINESS OBJECT
This chapter contains the definition of the data structure of a proposed extended
flight plan format that is based on the existing ICAO format. This XFPL will be
modelled as a CBO and I will propose a possible infrastructure for the CBO. In
the last part of this chapter I will map the object model to the relational data
model of the SOFT project database.
There are several reasons for modelling the XFPL as an object. Object technology is an innovative computing paradigm and its principles encourage the construction of modular and adaptable systems. A CBO has all the advantages of
object orientation: possible re-use, incremental development through inheritance,
encapsulation of data, and reduction of the scope of changes [Boo94]. Also, it corresponds to the idea of ‘networked objects’. The integration of all the relevant user
requirements into one object will allow all concerned users to view and manipulate the same object and it would eliminate the current problems that arise from
the different formats used by the flight plan clients. The following approach for
finding objects from the structural perspective has been suggested by Yourdan
[YWT+95]: persons, places, things, events, concepts, and other systems are all
candidate objects which can be captured in a class diagram. One could imagine
CBOs other than the XFPL for the ATC domain, such as ‘Aircraft’, ‘Airport’, ‘Sector’ etc.
Candidate business objects
All the concepts listed above are candidate business objects for the ATC domain.
It would also have been possible to create a ‘Trajectory’ business object that could
be used by the CFMU, approach control, and by the en-route centres. This ‘Trajectory’ object could be modelled as an aggregation of the FMS 4D-trajectory and of
some basic data from the ICAO FPL. In a future scenario with air/ground data
link technology, such an object could be used for cockpit-controller interaction.
Although the four-dimensional trajectory is an important product for ATC, I have
not considered it as the essential product. There are less clients for a ‘Trajectory’
business object (CFMU, approach control and ACC) than for a ‘Flight Plan’ business object (the eight clients listed in chapter 4). The aircraft trajectory is of central interest for ATFM and while the flight is in the air. During all the other
40
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
phases, especially from a gate-to-gate viewpoint, the trajectory is not of primary
interest.
I have however chosen to extend the existing flight plan format and to integrate
the trajectory into it. The main reason for not separating ‘Trajectory’ and ‘flight
Plan’ is that there is always a one-to-one relation between a flight performed by
an aircraft and the aircraft’s trajectory. Both are strongly related and this semantic relation has led to the design decision presented here. This solution admits
more clients for the CBO and therefore it can be of greater use to all participants.
Those clients who are primarily interested in the trajectory are free to define
their own particular view on the XFPL object, with the trajectory as the central
element.
For the object modelling part I use the Object Modelling Technique (OMT). Of
the three models for a complete system description [RBP+91] I will only use the
object model, because the emphasis of this paper lies on the structural aspects of
the flight plan. I have restricted the number of methods shown in the diagrams to
those definitely needed.
I will limit the area of discourse to those functions and parts of ATS that are
actually involved in creating, using, and changing flight plans. Now it is not easy
to define the exact semantics of the term “flight plan” because to each succeeding
user of a flight plan (each user has his own flight plan format) the term has its
own meaning. The airline pilot who creates a flight plan to be filed in the ICAO
format expresses his flight intentions in it. Then the CFMU TACT system will
regard it as a requested flight route that has to be arranged in an optimized manner in order to make the best use of the available airspace. The controller in a
radar centre will use the flight plan as a flight history and as a working aid to
perform his tasks. So a flight plan has many different roles during its existence.
5.1
Definition of an XFPL Format
Based on the classification of the user requirements in the previous chapter it is
now possible to create an XFPL object containing the following attributes and
methods. All attributes have to be declared as ‘private’ to avoid access from an
unauthorized part of the system.
DEFINITION OF AN XFPL FORMAT
41
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
From the ICAO filed flight plan format the XFPL will contain the following elements:
• Message type: Today, there are only two types of flight plans: the filed flight
plan (FPL) or repetitive flight plan (RPL).
• Callsign: The callsign1 of the aircraft in ICAO code abbreviation.
• Flight rules: Indicates if the flight is under visual or under instrumental flight
rules.
• Type of flight: Indicates if the flight is scheduled or non-scheduled.
• Number: The number of aircraft; usually one.
• Type of aircraft: The aircraft type in ICAO code.
• Wake turbulence category: The aircraft’s weight fits in one of three categories,
Light, Medium, or Heavy.
• Equipment: The aircraft’s communication, navigation, and approach aid equipment.
• Departure aerodrome: The departure aerodrome in ICAO code name.
• Departure time: The planned departure time. This time may be modified if different from the actual departure time.
• Cruising speed: The cruising speed demanded by the pilot.
• Cruising level: The cruising level demanded by the pilot.
• Destination aerodrome: The planned destination aerodrome.
• Alternative destination aerodrome: An alternative aerodrome if the first choice
is unavailable.
• 2nd alternative destination aerodrome: A second alternative aerodrome if the
first two aerodromes are unavailable.
• Registration: The aircraft registration2.
• Total EET: The total planned flight time.
• Passengers: The number of passengers is a supplementary piece of information
in the ICAO flight plan, but it is not currently transmitted in the FPL message.
This data is currently used and it will be necessary to include it in the proposed
XFPL format3.
1. In the ICAO filed flight plan this field is called “Aircraft ID”.
2. Often called the “tailnumber” of the aircraft.
3. See also: chapter 4.1.9 The “New Age” Flight Plan.
DEFINITION OF AN XFPL FORMAT
42
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
The planned route from the ICAO FPL will be replaced by a precise 4D route
calculated by the AOC before take-off. The AOC that has access to all the OFPL
information will supply the following data elements:
• Arrival time: The planned arrival time.
• Take-off weight: The planned take-off weight of the aircraft.
• Landing weight: The planned landing weight of the aircraft.
• Zero fuel weight: The planned zero fuel weight of the aircraft.
• 4D trajectory: This will be the trajectory prediction from the FMS. For each
waypoint there will be the name of the airway (if any), the position in lat/long
coordinates, the flight level, and the estimated flight time (∆t) from one waypoint to the next. Also for each waypoint there will be a ‘flag’ indicating if the
point has already been reached or not.
• Alternative 4D trajectory: The same format as the first 4D trajectory. If the aircraft cannot be allocated a departure slot within the acceptable delay, or if the
requested route is unavailable, the CFMU may try to allocate a slot for this
alternative route.
Furthermore, the airlines may include preferences for the flight. There will be
two attributes ‘Acceptable delay’ and ‘Preferred runway’. If the airline indicated
an acceptable delay for take-off, this might help avoid the disturbing practise of
multiple filing that leads to ghost flight plans in the CFMU systems.
The 4D trajectory can also be changed and updated by an ACC. The only
attribute that is filled by the ACCs is the SSR code.
The CFMU would provide the following information:
• File time: The UTC time of flight plan receipt.
• Origin: The originating AOC.
• Flight plan ID: A unique ID number attributed to the flight plan.
• State: The XFPL’s state which changes during the different flight stages.
The CFMU will also be authorized to modify the departure time initially indicated by the airline. Then a planned take-off time becomes the calculated take-off
time following any necessary regulation.
DEFINITION OF AN XFPL FORMAT
43
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
FIGURE 1: THE XFPL OBJECT
XFPL
message_type : string
file_time : string
origin : string
flight_plan_ID : string
number : int
type_of_flight : string
flight_rules : char
callsign : string
departure_aerodrome : string
dep_time : string
cruising_speed : int
cruising_level : int
destination_aerodrome : string
arr_time : string
alternative_aerodrome : string
2nd_alternative_aerodrome : string
take_off_weight : int
landing_weight : int
zero_fuel_weight : int
acceptable_delay : string
preferred_runway : string
passengers : int
registration : string
total_EET : string
ssr_code : char
type_of_aircraft : string
equipment : string
wake_turbulence_category : char
state : string
create_xfpl()
cancel_xfpl()
update_trajectoy()
get_state()
set_state()
modify_xfpl()
Because the data contained in the XFPL object comes from different sources, it
can be seen as an aggregate object. This object is composed of attributes from the
ICAO filed flight plan, it contains information sent from the controllers and from
the CFMU, and it contains FMS data including the 4D trajectory. There will be a
first requested trajectory and an alternative trajectory for each XFPL object. The
class name “Air/Ground Data Communication” is supposed to indicate that the
OFPL data provided by the airline might as well be sent via an air/ground data
link. This link between an aircraft and ATS is a possible replacement for the current filing practice. For the time being, the solution proposed here assumes that
the air carriers will simply include more information in the flight plans they file
to ATS. The next diagram shows the classes that compose the XFPL class.
DEFINITION OF AN XFPL FORMAT
44
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
FIGURE 2: XFPL AGGREGATION
XFPL
1+
ICAO Flight Plan
1..2
1+
Controller Correlation Air/Ground Data Communication 4D Trajectory
CFMU Regulation
CBO infrastructure
Now that the structure of the XFPL object has been defined it is necessary to
integrate the object into an infrastructure that will deliver the required services.
First of all, there have to be independent interfaces for all clients. Then the object
will have to be made persistent and its state behaviour will have to be controlled.
Separate client views
We can achieve a separation of concern by defining individual client views. Each
business object may be subdivided into three cooperating parts: the model object,
the view object and the control object.
The model encapsulates all the internal properties of the object, like the data
structure of the attributes and the services, and it ensures the object’s persistence.
The view encapsulates all of the external properties, it deals with the presentation of and the access to the object.
The control encapsulates the communication infrastructure, it covers the collaboration aspect: it translates the request for an action (by a user in a new
object) into a set of interactions with other objects and thus provides the dynamic
binding mechanism between collaborating objects (e.g. mouse, keyboard).
Together, these three parts form a framework for business information objects.
A detailed technical description of a CBO can be found in [Sim94]. In a computer
network system with multiple users the communication infrastructure will provide a view of an object at the location where its usage is requested. These views
DEFINITION OF AN XFPL FORMAT
45
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
will be active views, i.e. a model object instance must keep a record for each active
view of the object elsewhere in the network. For each change that occurs it will
update each view in all its remote locations. The original of such a database view
will only know the logical address of the view’s location, just as every view knows
the original’s logical address.
FIGURE 3: MODEL AND VIEW
Product
20 50 30
Change Notification
Sales
Football 20
Ski
50
50
70
30
Views
Model
Modifications, Requests
The next diagram shows how the separation between the data model of the
XFPl and the different client views can be achieved. CBOs follow a Model/View
separation which causes the presentation of the CBO to be separated from its
business logic and data. This allows for distribution of CBOs across client/server
boundaries. I will not deal with the necessary control logic, because it is part of
the communication infrastructure and therefore beyond the scope of this thesis.
Many object-oriented systems contain recurring patterns of classes and communicating objects. These patterns solve specific design problems and make objectoriented designs more flexible and reusable. Design patterns explain these recurring designs in OO systems. They are descriptions of communicating objects and
classes that are customized to solve a general design problem in a particular context.
This design uses the Observer pattern described in [GHJ+95], a tried and tested
software component. The Observer pattern defines a one-to-many dependency
between objects so that when one objects changes state, all its dependants are
notified and updated automatically. In this way we can achieve consistency
between all the related objects (the client views and the XFPL model) without a
tight coupling of the classes. The XFPL model knows its observers (clients) and it
DEFINITION OF AN XFPL FORMAT
46
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
provides an interface for attaching and detaching client objects. The clients have
an updating interface for other clients who should be notified of changes in a
flight plan. One effect of this pattern is that it supports broadcast communication
[GHJ+95, p. 296]. The XFPL model does not know how many observers exist; it is
only responsible for client notification.
FIGURE 4: XFPL MODEL AND VIEW
XFPL_Client
get_attribute()
set_attribute()
FA_Airport
FA_ACC
XFPL_view
update()
FA_AOC
FA_CFMU
FPL_model
attach()
detach()
notify()
Access_token
The flight plan model has the necessary methods to attach and detach clients
upon request. It also contains a notification method that will notify the attached
clients of changes in the model. The AOC that has created a flight plan object will
instantiate an access token and this token will control who has the right to
change the object.
One disadvantage of the OMT notation is that it is not possible to designate
multiple interfaces. Introducing a naming convention is one possible solution to
work around this deficiency. By naming the classes, e.g. FA_CFMU, I have tried to
indicate that this class represents only an interface or facade of the complex systems behind it. In this case it would be useful to model the clients in the Open
Distributed Processing (ODP) notation, since this notation supports multiple
interfaces.
Since there are multiple clients with differing views and needs it would be wise to
avoid “fat” interfaces (i.e. interfaces that are not specific to a single client) by
DEFINITION OF AN XFPL FORMAT
47
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
applying the so-called interface segregation principle so that users will not be
forced to depend on interfaces they do not use.
It is possible to break up the interfaces of a class into groups of methods with
each group serving a different set of clients. Thus, some clients use one group of
methods and other clients use the other groups. Even though there are objects
that require non-cohesive interfaces, clients should not know about them as a single class. Instead, clients should know about abstract base classes that have cohesive interfaces. Because clients exert forces upon their server interfaces, separate
clients should have separate interfaces as well.
The next diagram shows possible client views in detail. Each client has a specific
state and its specific ‘update’ method that it inherits from the abstract class
‘XFPL View’. When the XFPL View class receives a notification message from the
model object it will update all the concerned client views.
FIGURE 5: CLIENT VIEWS
XFPL_view
update()
FPL_model
attach()
detach()
notify()
XFPL
state : string
get_state()
set_state()
Airport_view
Airport_state : string
update()
ACC_view
ACC_state : string
update()
AOC_view
AOC_state : string
update()
CFMU_view
CFMU_state : string
update()
DEFINITION OF AN XFPL FORMAT
48
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Persistence
In order to provide persistence for the XFPL model object, there has to be a
mechanism that implements a connection to a database. Within the SOFT project
an XFPL object could be constructed from the project database, and since the
relational database interface is not adapted to the object, it has to be converted
into another interface expected by the client XFPL object. Here the target class
defines the domain-specific interface that the XFPL uses. The XFPL collaborates
with objects conforming to the target interface. The database has an existing
interface that needs adapting, and the Adapter class takes care of this by adapting it to the target interface. This design is an Object Adapter pattern [GHJ+95,
pp. 139].
FIGURE 6: DATABASE ADAPTER
XFPL
Target
store()
Database
specific_store()
XFPL_Adapter adaptee
store()
Another possibility for obtaining persistence is the pattern in the following diagram. The pattern supposes a relational database that has to be connected to an
object-oriented application [YWT+95]. For this pattern I suppose a system-wide
unique object-ID for persistent objects, and two states of a persistent object: the
volatile state and the database state. The volatile state is defined in the XFPL
class, while the database state is described by the corresponding tables of the
relational model. The correspondence between both states is established through
the unique object ID. Volatile states can survive database transaction limits.
When a transaction commits, volatile and database states are consistent and a
new transaction begins.
The unique instance of the Object Manager class manages all persistent objects
currently existing in volatile memory. It initiates the retrieval of persistent
objects from the database and handles backup and recovery in transaction
DEFINITION OF AN XFPL FORMAT
49
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
sequences which involve the updating of multiple objects. The Persistent Object
class is an abstract class from which all XFPL objects inherit their unique object
ID and the methods to communicate with the corresponding database objects. The
Database Object class is the superclass of all concrete database classes. It establishes the protocols for the different database access operations.
FIGURE 7: PERSISTENCE PATTERN
Object Manager
new_object()
get_object()
store_object()
remove_object()
Persistent Object
save()
remove()
XFPL
Database Object
db_retrieve()
db_insert()
db_update()
db_delete()
Database XFPL
db_retrieve()
db_insert()
db_update()
db_delete()
XFPL states
There are different alternatives for implementing object life cycle models.
Advantages of using state machines result from their contribution to system
maintainability [YWT+95]. A flight plan has a complex behaviour pattern, and we
can associate its object life cycle to a finite-state-machine with a finite set of
states, an equally finite set of transitions from one state to another, and event
rules for the transitions. This machine can be implemented as a Finite State
Model (FSM) object.
The Finite State Model class of the pattern serves to tie together all transitions
that belong to the object life cycle. There is exactly one instance of this class per
object life cycle model. The Transitions class contains the data describing each
transition: old state - new state - event - action.
The XFPL class inherits from the abstract class Active Object. This abstract
class provides the methods and attributes an XFPL object needs to communicate
DEFINITION OF AN XFPL FORMAT
50
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
with its FSM object and to perform the appropriate state transition for an event.
FIGURE 8: STATE MODEL
Finite State Model
transitions : Transition
Active Object
transitions : Transition
current_state : State
XFPL
create()
traverse()
add_transition()
Transition
old_state : state
new_state : State
event : Event
action : Action
match()
create()
DEFINITION OF AN XFPL FORMAT
51
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
5.2
Mapping the XFPL Object to the Relational
Data Model
This section demonstrates how the object classes on the level of object-oriented
programming, which as a whole constitute the XFPL business object, can be
mapped to the relational data model that underlies the SOFT project database.
FIGURE 9: MAPPING OF THE OBJECT CLASS MODEL
Object class model
EER-model
Conceptual view
Realization
Database tables
In a first step, the object classes can be modelled as entity types in the EERmodel. The concepts of inheritance and aggregation of the object-oriented paradigm are also supported as generalizations and aggregations in the EER-model.
However, only the structural aspect of the object classes can be modelled in EER
notation. The relational data model does not support the modelling of dynamic
aspects or roles. Furthermore, the concept of the unique identity of each object is
lost in the relational data model. By using keys in database tables we can achieve
a surrogate for this concept.
The next step is the realization of a relational database with tables by using the
conceptual EER-model. The abstract object classes that can be represented as
generalizations of entity types in the EER-model cannot be realized as database
tables. The two generalized entity types Trajectory and Flight Plan contain only
those attributes that are common to all different kinds of trajectories and flight
plans. I have chosen to include these attributes in each table in order to accelerate
access to the different tables. The columns in each table represent the attributes
of the corresponding entity type in the EER-model.
On a very abstract level one can distinguish the following four basic concepts
concerning a flight: the “Flight Plan”’, the “Aircraft”, the “Trajectory”, and the
“Radar Tracks”.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
52
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
FIGURE 10: A SIMPLIFIED FLIGHT PLAN RELATION
Radar Tracks
Flight Plan
Trajectory
Aircraft
Each flight plan is associated with one aircraft and with one set of radar tracks
that record the actual flight progress. The predicted flight path is expressed in
the “Trajectory”. This “Trajectory” can be simply a set of route points alone, or the
same set of points with additional information such as latitudinal/longitudinal
coordinates, time, and flight level for each point.
The class diagram on the next page shows the object classes needed for the construction of an XFPL object. There is an abstract class Flight Plan that enables
uniform treatment of all kinds of flight plans. One aircraft can perform many
flights one after the other, and therefore is associated to many flight plans. Each
flight plan is then associated to many radar tracks that record its flight path.
Every position in space expressed by a radar track is subject to meteorological
conditions.
Each flight plan is also associated to a trajectory. The abstract class Trajectory
enables the uniform treatment of all the different predicted flight paths. Each
individual flight plan (e.g. an operational flight plan from an airline) is composed
of a set of trajectory points; in this case a list of tuples with a waypoint name, an
airway name, a flight level, a time, and the current speed.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
53
System Flight Plan
Flight Plan
CFMU All_Flights
CFMU Point Profile
CFMU Sector Profile
Demanded Trajectory Point
Trajectory
Realized Trajectory Point
OFPL Trajectory Point
FLIGHT PLAN FORMATS
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
OFPL Meteorological Data
ICAO Flight Plan
Radar Track
FIGURE 11:
Operational Flight Plan
Meteorological Data
Aircraft
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
OBJECT MODEL
54
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Now this object model has to be mapped to a relational data model for the relational SOFT database.
This is a brief description of the 15 entity types in the EER-model:
• Meteorological Data: has attributes describing wind direction, wind force,
and air temperature as provided by Météo France.
• Radar Trajectory Point: has attributes describing radar tracks for all flights
that were recorded in the CRNA Reims and the CRNA Athis-Mons. This relation does not qualify as a specialization of the Trajectory relation, because,
unlike the system flight plans for instance, it contains radar tracks (recorded
flight path) and not waypoint or sector names (predicted flight path).
• Flight Plan: this entity type is a generalization of the four different flight plan
formats; it contains only the attributes common to all flight plans.
• Aircraft: has attributes describing each physical aircraft observed in the concerned area.
• CFMU_All_Flights: this is a specialized flight plan; it is also an aggregation
of two flight profiles calculated by the CFMU after slot allocation and an eventual regulation.
• System Flight Plan: this is also a specialization of a flight plan; it is an aggregation of two possibly different trajectories recorded in the CRNA Reims and
Athis-Mons (the database table System Flight Plan will be filled with data
extracted from SFPLs in the COURAGE format).
• Operational Flight Plan: a specialization from the Flight Plan entity type; it
contains the attributes of the operational flight plans used by the airlines that
the pilots receive before take-off. This entity type is an aggregation of the flight
trajectory calculated by the airline, and the meteorological information used
for the calculation.
• ICAO Flight Plan: a specialization of the Flight Plan entity type; contains all
the attributes from the ICAO filed flight plan.
• Trajectory: a generalization of all kinds of predicted flight paths.
• CFMU_Sector Profile: contains one of the two components of the
CFMU__All_Flights entity type; the list of the traversed sectors for each flight.
• CFMU_Point Profile: contains the other of the two components of the
CFMU__All_Flights entity type; a list of waypoints for each flight.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
55
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
• SFPL_Realized Trajectory Point: contains atributes describing a flight trajectory that is possibly different from the demanded trajectory due to controller
actions.
• SFPL_Demanded Trajectory Point: contains the attributes of a flight trajectory as it was originally requested in the flight plan.
• OFPL_Trajectory Point: one of the two components of the OFPL entity type;
contains the flight route as it was predicted by the airline.
• OFPL_Meteorological Data: the other component of the OFPL entity type;
contains the attributes describing meteorological information used by the airline to predict a precise flight trajectory.
The following diagram represents the relational database schema for the SOFT
project database in EER notation.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
56
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
FIGURE 12: ER-DIAGRAM OF THE SOFT DATABASE
1
CFMU_Sector
Profile
1
CFMU_Point
Profile
n
SFPL_Realized
Trajectory
Point
n
SFPL_Demanded
Trajectory
Point
Meteorological
Data
n
CFMU
All_Flights
has
1
Radar
Trajectory
Point
n
record
progress
Trajectory
System
Flight Plan
1
Flight
Plan
n
n
uses
OFPL
Trajectory
Point
Operational
Flight Plan
n
1
Aircraft
OFPL
Meteorological
Data
ICAO
Flight Plan
An aircraft that is going to perform a flight will always1 use a flight plan to
inform ATS of the intended date, time, place, route etc. The integrity constraint
added to the relationship type indicates that each single aircraft has to be associated with at least one flight plan. For each flight plan there are many radar
1. This abstraction only considers flights under instrumental flight rules in controlled airspace.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
57
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
tracks which as a whole compose the flight’s actually recorded progress. There
should only be radar tracks for those flights for which we have the flight plan. So
there is another integrity constraint on this relationship type to indicate its totality.
Each point in space represented by a radar track has certain meteorological conditions that are modelled in the Meteorological Data entity type. Due to the quality of the meteorological data it is necessary to interpolate between different sets
of weather information to evaluate the temperature, wind force and heading for
each radar track. So each radar track has different meteorological data that
serves to calculate its approximate weather conditions, and the integrity constraint on the relationship type expresses that each tuple of meteorological data
has to be associated with one radar track.
The Flight Plan entity type is a generalization of four different entity types: The
CFMU All_Flights flight plan, the System Flight Plan, the Operational Flight
Plan, and the ICAO Flight Plan.
The CFMU All_Flights flight plan is an aggregation of one CFMU_Sector Profile
and of one CFMU_Point Profile. The integrity constraints on both profile entity
types indicate that each profile has to be associated to one CFMU All_Flights
flight plan.
The System Flight Plan entity type is an aggregation of many SFPL_Realized
Trajectory Points and of many SFPL_Demanded Trajectory Points. Here also,
there are integrity constraints on both components to indicate that they have to
be associated to one System Flight Plan.
The Operational Flight Plan entity type is an aggregation of the OFPL Trajectory Point entity type and of the OFPL Meteorological Data entity type. There is
an integrity constraint for the relationship between the trajectory points and the
OFPL because the OFPL trajectory points always have to be associated to one
OFPL.
Finally, the Trajectory entity type is a generalization of the five different trajectory entity types: CFMU_Sector Profile, CFMU_Point Profile, SFPL Realized Trajectory Point, SFPL Demanded Trajectory Point, and OFPL Trajectory Point. The
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
58
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Trajectory entity type has the attributes that are common to all the different
trajectories.
From this relational data model I have created a database in ORACLE 7 containing the following tables and attributes:
THE OPERATIONAL FLIGHT PLAN TABLE
Primary keys:
• ADEP: Departure airport in ICAO code.
• ADES: Destination airport in ICAO code.
• Callsign: Callsign of the aircraft.
• Date_Dep: Date of departure; may be different from the date the flight passes
over a waypoint.
Mandatory attributes:
• Planned_Arr_Time: Arrival time in UTC as planned by the airline before takeoff.
• Planned_Dep_Time: Departure time in UTC as planned by the airline before
take-off.
Optional attributes:
• Avge_Temperature: Average outside air temperature in degrees Celsius at
cruise flight level according to weather forecast.
• Avge_Wind: Average wind component at cruise flight level, according to
weather forecast.
• Avge_Wind_Heading: Average wind heading at cruise flight level in degrees
relative to the aircraft’s heading.
• Avge_Wind_Magnitude: Average wind magnitude in knots at cruise flight level,
according to weather forecast.
• Climb_Speed: Planned ground speed during climb in knots.
• Cruise_Flight_Level: Cruise flight level in feet*100 planned by the airline.
• Cruise_Machnumber: Cruise speed planned by the airline, expressed as machnumber.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
59
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
• Cruise_Speed: Planned ground speed for cruise in knots.
• Descent_Speed: Planned ground speed during descent in knots.
• Landing_Weight: Planned landing weight of the aircraft in kg.
• Take_Off_Weight: Planned take-off weight of the aircraft in kg.
• Taxi_Fuel: Planned amount of fuel in kg needed for taxiing at the departure
aerodrome.
• Zero_Fuel_weight: Planned zero-fuel weight of the aircraft in kg.
Taxi fuel is added here because the real take-off weight will be the planned takeoff weight minus the fuel burned during taxiing. This table receives two foreign
keys from the Aircraft table: AC_Type and Registration. Since the different airlines use different sets of data, most of the attributes are optional.
THE TRAJECTORY TABLE
Primary keys:
• ADEP: Departure airport in ICAO code.
• ADES: Destination airport in ICAO code.
• Callsign: Callsign of the aircraft.
• Date_Dep: Date of departure; may be different from the date the flight passes
over a waypoint.
• Waypoint: This may be either the name of a beacon or of a reporting point.
Mandatory attributes:
• Delta_Time: The estimated time (hours:minutes) it will take the aircraft to get
to the next waypoint.
• Total_Time: The estimated total time (hours:minutes) elapsed at this point
since take-off.
• Date_Over: This is the date when the aircraft crosses a waypoint; may be different from the departure date if the flight has left late at night and only
arrives the following day.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
60
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
THE OFPL TRAJECTORY POINT TABLE
Primary keys:
• Date_Over: This is the date when the aircraft crosses a waypoint; may be different from the departure date if the flight has left late at night and only
arrives the following day.
• Waypoint: This may be either the name of a beacon or of a reporting point.
Mandatory attributes:
• Delta_Time: The estimated time (hours:minutes) it will take the aircraft to get
to the next waypoint.
• Total_Time: The estimated total time (hours:minutes) elapsed at this point
since take-off.
Optional attributes:
• Airway: The name of the airway the waypoint is on, if any.
• Beacon_Frequency: The frequency emitted by a beacon in MHz.
• Delta_Distance: This is the estimated ground distance in nautical miles
between the current waypoint and the next one.
• Delta_Fuel_Burn: This is the estimated amount of fuel in kg burned until
reaching the next waypoint.
• FL_Over_WPT: The flight level in feet*100 at which the aircraft crosses the
waypoint.
• Ground_Speed: The ground speed in knots at which the aircraft crosses the
waypoint.
• Latitude_WPT: The latitude coordinate of the waypoint, according to WGS 84.
• Longitude_WPT: The longitude coordinate of the waypoint, according to WGS
84.
• Machnumber: The speed expressed as machnumber at which the aircraft
crosses the waypoint.
• Magnetic_Track: The magnetic track of the aircraft at crossing the waypoint.
• MORA: The minimum off-route altitude in feet*100 at this point.
• Remaining_Fuel: The amount of fuel in kg remaining at this point.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
61
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
• Total_Distance: This is the total ground distance in nautical miles flown since
take-off.
• True_Air_Speed: The true air speed in knots while crossing a waypoint.
This table has a relationship to the OFPL table, since the data contained in it
has the same origin, i.e. the air carrier. For one flight there are one or many trajectory points that as a whole constitute the aircraft’s predicted trajectory.
Because the different contacted airlines have widely differing sets of data in their
respective OFPLs, many of the attributes in this table are optional. To identify
each row, this table receives four foreign keys from the OFPL table: ADEP, ADES,
Callsign, Date_Dep.
THE CFMU ALL FLIGHTS TABLE
Mandatory attributes:
• AC_TYPE: This is the ICAO standard abbreviation for the aircraft type.
• AOBT: The actual off-block time in UTC.
• EOBT: The estimated off-block time in UTC.
• FIRST_REQ_FL: The pilot’s first requested flight level for the flight in feet *
100.
• FLIGHT_STATUS: This is the status of the flight: TE for “terminated”, CA for
“cancelled”, AA for “ATC activated”, FI for “filed”, FS for “filed and slot issued”,
TA for “tact activated”.
• IFPS_ID: The ID number issued to the flight by the IFPS.
• IOBT: This is the initially estimated off-block time in UTC.
• LATE_FILER: This field indicated if or if not the flight plan was filed later
than EOBT - 3h.
• LATE_UPDATER: This field indicated if or if not the flight plan was filed later
than EOBT - 3h.
• TACT_ID: This is the ID number issued to the flight by the CFMU TACT system.
Optional attributes:
• COBT: This is the calculated off-block time in UTC from the CFMU.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
62
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
• SAM_CTOT: The slot allocation message for the calculated take-off time
(CTOT).
• SIP_CTOT: The slot improvement proposal for the CTOT.
• SLOT_FORCED: This field indicates if the slot has been forced on a flight
[Y|N].
This table contains data from the CFMU file “All Flights”, which is generated at
the CFMU after any necessary regulation and it contains the estimated as well as
the calculated and actual take-off slots. For each OFPL row there may be zero or
one
rows
in
the
CFMU_All_Flights
table,
while
each
row
in
the
CFMU_ALL_FLIGHTS table refers to exactly one row in the OFPL table. To identify each row this table receives four foreign keys from the OFPL table: ADEP,
ADES, CALLSIGN, DATE_DEP.
THE CFMU SECTOR PROFILE TABLE
Primary keys:
• Date_Over: This is the date when the flight has passed over the waypoint; possibly different from the day it took off at the departure aerodrome.
• Sector: This is the name of the sector flown over.
Mandatory attributes:
• Entry_Time: The time UTC when a flight enters the sector.
• Exit_Time: The time UTC when a flight leaves the sector.
Optional attributes:
• Airway: The name of an airway, if the waypoint is situated on it.
This table lists the sectors crossed by a given flight with the entry and exit times
for each sector. For each row in the CFMU_All_Flights table there are one or
many rows in the Sector_Profile table, each of which describes a sector in the aircraft’s trajectory. To identify each row this table receives four foreign keys from
the CFMU_All_Flights table: ADEP, ADES, Callsign, Date_Dep.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
63
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
THE CFMU POINT PROFILE TABLE
Primary keys:
• Date_Over: This is the date when the flight has passed over the waypoint; possibly different from the day it took off at the departure aerodrome.
• Waypoint: The name of a waypoint (e.g. reporting point or beacon).
Mandatory attributes:
• Flight Level: This is the flight level in feet * 100.
• Time_Over: This is the time UTC when a flight passes over a waypoint.
Optional attributes:
• Airway: The name of an airway, if the waypoint is situated on it.
For each row in the CFMU_All_Flights table there are one or many rows in the
Point_Profile table, each of which describes a waypoint in the aircraft’s trajectory
as calculated at the CFMU. To identify each row this table receives four foreign
keys from the CFMU_All_Flights table: ADEP, ADES, Callsign, Date_Dep.
THE RADAR TRAJECTORY POINT TABLE
Primary keys:
• Time_Over: The time UTC hours`h`minutes`:`seconds’, for each radar track.
Mandatory attributes:
• Date_Over: This is the day when the radar track was recorded; possibly different from the day the flight took off at the departure aerodrome.
• Flight Level: This is the flight level in feet * 100.
• Ground Speed: This is the ground speed in knots.
• Latitude: For each radar track there is a WGS84 latitudinal position
degrees[N|S]minutes’seconds
• LONGITUDE: For each radar track there is a WGS84 longitudinal position
degrees[E|W]minutes’seconds
For each flight described in the OFPL there are zero or many rows in the radar
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
64
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
trajectory point table, each of which describes a radar track in the aircraft’s trajectory. There is one radar track every 8 sec, the LAT/LONG positions for each
flight have a precision of 1” which corresponds to ~30 metres on the equator. This
table receives four foreign keys from the Flight Plan table: ADEP, ADES, CALLSIGN, DATE_DEP.
THE METEOROLOGICAL DATA TABLE
Primary keys:
• Date: The date when the data was recorded.
• FL_as_Isobar: The flight level expressed as air pressure in steps of 10,000 feet;
i.e. there are values for FL 100, 200, 300, 400, 500.
• Latitude_Cube: This figure gives the latitude coordinate in degrees and 1/100
of a degree: e.g. `LATITUDE 2750’ means two degrees and 45 minutes (75/100
of a degree).
• Longitude_Cube: This figure gives the longitude coordinate in degrees and 1/
100 of a degree.
• Time: There are data for every three hours UTC time: 3.00, 6.00, 9.00, 12.00,
15.0, 18.00, 21.00, 24.00.
Mandatory attributes:
• Temperature: This is the outside air temperature in degrees Kelvin.
• Wind_Heading: This is the wind heading in degrees relative to the aircraft’s
heading.
• Wind_Magnitude: This is the wind magnitude in metres/second.
This table is filled with actual weather data received from Météo France. It will
be necessary to interpolate several sets of weather data in order to obtain a good
approximation for the real weather conditions at a given point in an aircraft’s trajectory. This is because Météo France provides meteorological information for
every three hours UTC time. The measurements are taken at intervals of 10,000
feet up to an altitude of 50,000 feet; they are expressed not as flight levels but as
air pressure, so that the exact altitude may vary. Longitude and latitude coordinates together with the altitude define a cube in space. For each latitude value in
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
65
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
a file from Météo France, there are ten longitude values in steps of 15 minutes.
Each following latitude value is then also increased by 15 minutes. For this cube
in time and space, there is information about the temperature, the wind direction,
and the wind force.
Since the units metres/second, degrees Kelvin, and 1/1000 of a degree are not
the same as in the other tables with columns for wind speed, temperature, and
lat/long coordinates, these have to be converted before entering them into the
database.
THE OFPL METEOROLOGICAL DATA TABLE
Optional attributes:
• ISA_DEVIATION: This is the deviation +/- from the international standard
atmosphere (1013.2 HectoPascal).
• TEMPERATURE: This is the outside air temperature in degrees Celsius.
• WIND_COMPONENT: This is the wind component, relative to the aircraft’s
heading.
• WIND_HEADING: This is the wind heading in degrees, relative to the aircraft’s heading.
• WIND_MAGNITUDE: This is the wind magnitude in knots.
For each trajectory point described in the OFPL trajectory point table some airlines give meteorological conditions based on the weather forecasts for the time
and day of the flight. These weather forecasts are used to predict a precise flight
trajectory. So for each row in the OFPL Trajectory Point table there may be zero
or one rows in the OFPL Meteorological Data table. To identify each row this
table receives four foreign keys from the OFPL Trajectory Point table: ADEP,
ADES, Callsign, Date_Dep.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
66
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
THE ICAO FLIGHT PLAN TABLE
Mandatory attributes:
• AC_Type: This is the ICAO abbreviation for the aircraft type name.
• Alt_Airport_List: A list of alternative aerodromes in case the scheduled arrival
aerodrome should not be available.
• Arr_Time: The filed arrival time in UTC.
• Cruise_Flight_Level: The filed cruise flight level in feet * 100.
• Cruise_Speed: This is the filed cruise ground speed in knots.
• Dep_Time: This is the filed departure time UTC.
• Route: This is the filed route for the flight, i.e. a list of waypoints.
• SSR_Code: The aircraft’s responder code: currently mode A or C.
• Type_of_Flight: This indicates whether the flight is scheduled or non-scheduled [S|N].
• Wake_Turbulence_Category: This field contains one of the three existing categories Light, Medium or Heavy.
This table contains information from the ICAO filed flight plan that some air
carriers add to their OFPL. For each row in the OFPL table, there are zero or one
rows in the ICAO Flight Plan table. To identify each row, this table receives four
foreign keys from the OFPL table: ADEP, ADES, Callsign, Date_Dep.
THE AIRCRAFT TABLE
Primary keys:
• AC_TYPE: This is the ICAO abbreviation for the aircraft type name.
• REGISTRATION: This is the aircraft’s tail number.
Mandatory attributes:
• NAME_TYPE: The aircraft type full name.
Since there may be several OFPLs for one and the same aircraft I have chosen
to create a separate table for information about each aircraft.
For each row in the aircraft table there may be zero or many rows in the OFPL
table, i.e. there may be zero or many OFPLs for one aircraft, while each OFPL
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
67
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
belongs to exactly one aircraft.
THE SYSTEM FLIGHT PLAN TABLE
Mandatory attributes:
• AC_Type: This is the ICAO abbreviation for the aircraft type name.
• Delay_ATC: An eventual delay in minutes imposed by the controller.
• Dep_Time: This is the departure time slot in UTC as allocated by the CFMU.
• Exit_Time: This is the time UTC when a flight leaves the control centre’s
responsibility.
• No_CAUTRA: The CAUTRA number allocated to a flight by the control centre.
• Requested_Flight_Level: This is the flight level in feet * 100 that the pilot has
requested in the filed flight plan.
• Requested_Speed: This is the ground speed in knots that the pilot has
requested in the filed flight plan.
The system flight plan is used by the five CRNA in France. All control centres
use the same format, called COURAGE. For one flight described in an OFPL
there may be zero or one system flight plans from the CRNA. To identify each row
in this table, there are four foreign keys from the OFPL table: ADEP, ADES, Callsign, Date_Dep.
THE SFPL REALIZED TRAJECTORY TABLE & SFPL
DEMANDED TRAJECTORY POINT TABLE
Primary keys:
• Beacon: This is the name of a beacon.
• Date_Over: This is the date when a flight crosses over a beacon; possibly different from the take-off date.
Mandatory attributes:
• FL_Over_Beacon: This is the flight level in feet * 100 at which a flight crosses
over a given beacon.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
68
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
• Time_Over_Beacon: The time UTC when a flight crosses over a given beacon.
For each row in the system flight plan table, i.e. for each flight, there may be one
or many trajectory points which together compose the aircraft’s trajectory, while
each trajectory point belongs to exactly one flight. To identify each row this table
receives four foreign keys from the SFPL table: ADEP, ADES, CALLSIGN,
DATE_DEP. Both tables contain the same attributes, nevertheless it is necessary
to realize them as separate tables. This realization will allow a comparison of the
difference between requested and realized trajectories, if the two are different.
Normalization of the database schema
For the design of the database I had to find a compromise between the degree
normalization [EN94], i.e. functional dependency, of the modelled data and the
performance and intended use that imply certain frequent requests to be facilitated.
The database schema is designed to satisfy the second normal form (2NF). It
also guarantees lossless join, it avoids spurious tuples after a join, and it has the
dependency preservation property ensuring that all functional dependencies are
represented in a relation resulting from a join.
The schema is in 1NF, because there are only atomic attributes; it is also in 2NF,
because every non-prime attribute is not partially dependent on any key of the
relation it belongs to. However, the schema does not fulfil the conditions for 3NF,
because some non-prime attributes are transitively dependant on one of the keys
in the same relation.
For instance, in the relation Operational Flight Plan, the attribute Machnumber
depends on the Speed and Temperature, because the unit Machnumber is derived
from the outside air temperature and the speed. So in a way Speed and Temperature are keys for Machnumber, without being keys to the relation. However, it
would mean a loss of performance for the database to create a separate relation
Speed, because the speed of an aircraft is not going to be a frequently requested
item. The schema as it is fits the intended use and it accommodates the expected
frequent requests made on the database.
MAPPING THE XFPL OBJECT TO THE RELATIONAL DATA MODEL
69
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
6.
EVALUATION OF THE XFPL BUSINESS OBJECT
6.1
Results
So far all the necessary data have been collected from the airlines, the CFMU, the
control centres in Reims and Athis-Mons, and Météo France. There has been a
very positive response from the airlines who consider an enhanced data exchange
between their AOCs and ATS as a possibility for more economical operations and
higher flight efficiency. Several airlines have expressed a great interest in the
final results of the project.
On the practical side, the data transfer into the database has proved to be a
more complex task than originally estimated. The formats from the COURAGE
files, the radar data, the CFMU All_Flights format as well as the meteorological
data files are relatively easy to parse with PERL scripts. So on this side the programming effort was reasonable. The OFPLs from the 12 contacted airlines, on
the other hand, all come in an individual format, each one using different abbreviations and units. So each format required a special parser for extracting the data
to be inserted into the database. Also, a number of validity checks had to be performed on the extracted data. There are syntactic checks on the data format and
semantic checks on the names of airfields, aircraft, and beacons.
The CBO defined in the previous chapter is capable of fulfilling the clients’
requirements and in the next step, we need to evaluate strategies for testing the
object with respect to ease of operation, accessibility, and safety.
6.2
Strategies for the Evaluation of the Business
Object
The SOFT database enables us to construct prototypical XFPL objects and to
compare the four-dimensional OFPL trajectories contained in them with the
actual trajectories and those predicted by the CFMU.
6.2.1
Comparison of Trajectories
A tool called RASS-C (Radar Analysis Support System for Centre), a radar plot
evaluation and tracker analysis program developed at the EEC, will allow the vis-
RESULTS
70
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ualization and comparison of trajectories. The flown trajectories can be classified
into flights that have proceeded as planned and flights which had to change their
trajectory due to controller instructions.
The RASS-C tool allows a trajectory reconstruction for each recorded flight by
chaining the multiradar data. A subprogram can reconstruct the aircraft state in
terms of positions, height, speed, and transversal and longitudinal acceleration.
The reconstructed trajectories can be displayed together with their associated
plots. Another functionality of the tool, a set of inventory display and statistic programs, allows a basic analysis of the radar data entered into the system. These
programs check on possible data loss, traffic distribution and configuration, radar
coverage, and overall radar quality with respect to invalid replies.
There will be three different trajectory comparisons:
• The comparison between the predicted OFPL trajectory and the trajectory calculated by the BADA aircraft performance database for the given aircraft type
and route.
• The comparison between the predicted OFPL trajectory and a trajectory that
BADA could calculate based on the exact take-off weight as indicated by the
airline.
• The comparison between the predicted OFPL trajectory and the trajectory calculated by the CFMU TACT system.
The comparison of the different trajectories should show whether adding the
exact weight of the aircraft and the 4D trajectory predicted by the air carrier
would actually improve flow management. The airlines would be willing to
change their flight plan filing procedures if it helped them to operate their business more economically. For the other flight plan clients it would be necessary to
interview them concerning the XFPL format.
STRATEGIES FOR THE EVALUATION OF THE BUSINESS OBJECT
71
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
7.
CONCLUSION
Object technology as the state-of-the-art computing paradigm provides organizations with a flexible and adaptable software infrastructure. An organization
that wishes to increase its performance by redefining its business processes will
discover that the CBO concept is the adequate software metaphor for its products.
CBOs are common modular structures that represent the relevant actors, products, and services throughout the business domain. The conceptual shift towards
client participation characterizes CBOs compared to ordinary objects.
The “Flight Plan” is an essential product in the ATC domain. This domain1 is
characterized by its very high complexity, differing client requirements, and heterogeneous computing environments. Therefore I have identified a set of relevant
actors/clients in flight planning whose requirements with respect to flight plans I
have defined and classified. This classification and a selection of those requirements that would indeed satisfy all clients have led to the definition of a common
extended flight plan format. By designing the extended flight plan as a CBO it is
possible to improve communication between the air carriers and ATS, to allow for
slot revision and re-routing less than three hours before take-off, and to enhance
the air traffic controllers’ tactical decisions by providing them with updated and
precise trajectories.
So the new common flight plan business object solves the problems identified at
the beginning: it makes use of sophisticated AOC data and it lets the air carriers
express their business needs in the flight plan. The CBO infrastructure delivers
the necessary services that provide the controllers with up-to-date flight information, it allows for an improved slot revision and re-routing concept, and it permits
interoperability in the present heterogeneous computing environment in the
ECAC region.
The proposed XFPL structure is based on the current ICAO FPL format: the
most important additions to the ICAO format are the precise weight of the aircraft and the four-dimensional trajectory calculated by the AOC. The single most
important change in the flight plan’s life cycle behaviour is that with an XFPL
business object, flight trajectories would be updated as the aircraft progresses. I
1. i. e. in the ECAC region.
CONCLUSION
72
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
have mentioned the FAA “New Age” flight plan to demonstrate that experiments
in the US are going in the same direction: improving data exchange between the
airlines and ATS by extending the flight plan format.
The remaining problems include both customer acceptance and safety issues.
First experiences with business objects [OBM97] have shown that users gain a
better understanding of the advantages and possible uses of object technology if
they can see objects no longer as program units but as things from their own business domain. The users know the semantics of these business objects and they
can interact with them on the user interface. The fact that users will be able to
interact with objects instead of applications may convince them of the advantages. It is no longer necessary to develop new applications for a changed business
field; it will be enough to customize an existing business object or to add a new
business object to those already in use.
Beyond customer acceptance, the chances for a successful implementation of
business objects in the ATC community will also depend on the safety and accessibility provided by the middleware layer. The 22 heterogeneous ATC systems in
the ECAC region should be able to safely manipulate and view the same flight
plan format. Current implementations of middleware platforms (e.g. CORBA) do
not yet provide the necessary transparence and fault tolerance.
Despite technical issues, with respect to the operational systems and the early
stages in the development of object-oriented middleware technology, business
objects offer a possibility for a completely different approach on a conceptual
level. The notion of encapsulation allows an integrated view of the concept XFPL,
without going into the details of a concrete and maybe existing implementation.
On the other hand, this integrated view facilitates a more ATC-related perspective towards flight plans, instead of coping with the existing infrastructure.
CONCLUSION
73
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ANNEX I: THE ICAO FILED FLIGHT PLAN FORMAT
The list below does not mention the originator, the adressee, or the filing time.
Table 10: ICAO Filed Flight Plan Data
Item name
Description
Message type
Filed Flight Plan
Aircraft Identification
ICAO designator for the aircraft.
Flight rules
I (IFR), V (VFR), Y (IFR first), or Z (VFR
first)
Type of flight
Scheduled, Non-scheduled, general, military, other.
Number
Number of aircraft, if more than one.
Type of aircraft
ICAO appropriate designator.
Wake turbulence category
Heavy, Medium, or Light
Equipment
Radio communication, navigation, and
approach aid equipment, including SSR
equipment.
Departure aerodrome
The ICAO four-letter location indicator.
Time
The estimated off-block time in UTC.
Cruising speed
True air speed in km/h, machnumber, or
knots.
Level
Cruise flight level in feet*100.
Route
The departure aerodrome followed by a list
of ATS route segments, or significant
points.
Destination aerodrome
The ICAO four-letter location indicator.
Total EET
Estimated elapsed time in four digits.
Altn. aerodrome
The ICAO four-letter location indicator of
the first alternative aerodrome.
2nd altn. aerodrome
The ICAO four-letter location indicator of
the second alternative aerodrome.
Other information
74
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ANNEX II: OPERATIONAL FLIGHT PLANS
75
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
76
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
The previous two pages show a sample operational flight plan from Scandinavian Airlines (SAS). This OFPL contains the following items that are of interest:
• Flightnumber: ‘SK561’ callsign of the aircraft.
• Date: ‘17JUN97’ date of flight.
• City Pair: ‘ENFB-LFPG’ departure and arrival airport in ICAO code.
• Registration: ‘LN-RMJ’ aircraft registration.
• Type: ‘M82’ aircraft type (MD 82).
• ISA DEV: ‘+5’ deviation from international standard atmosphere.
• FL: ‘350’ planned cruise flight level in feet * 100.
• ZFW: ‘41.2’ zero fuel weight in kg *1000.
• TOW: ‘49.1’ take-off weight in kg *1000.
• LW: ‘43.9’ landing weight in kg *1000.
• SKED DEP: ‘0605’ scheduled departure time in UTC.
• SKED ARR: ‘0820’ scheduled arrival time in UTC.
• AWY: ‘UB31’ name of an airway.
• REP: ‘BOURSONNE’ name of a radar beacon or a reporting point.
• FREQ: ‘D117.8’ radar frequency emitted by a beacon.
• TIME: ‘22’ - ‘0:22’ total time since take-off in hours:minutes, and in between
beacons.
• FUEL: ‘7.9’ remaining fuel in tons.
• WIND: wind heading in degrees and magnitude in knots.
• AMT: ‘194’ magnetic track.
• D: ‘137’ distance between waypoints in nautical miles.
• TTL D: ‘721’ total distance flown in nautical miles.
• WINDS: ‘FL370 261/21’ wind information in knots/heading for different flight
levels.
• RPL FILED: information about a repetitive flight plan.
77
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ANNEX III: SYSTEM FLIGHT PLANS OF THE AREA
CONTROL CENTRES
Sample system flight plan in the COURAGE format:
05
11
20 BAW2053 EGKK FVHA 1673 -1 B74F
21 1261 330 493
31 I VEULE ROU BAMES RBT PTV NEV CMF GARMI MAGER FJR ERTOL
KONDA PERLE COUTO BALEN KAMER CSO
32 -172 -169 -165 -161 -158 -153 -144 -133 -127 -125 -115 -110
-109 -106 -97 -92 -77 -76
33 310 310 330 330 330 330 330 330 330 330 330 330 330 330 330
330 330 330
41 EG UZ ZU V2 T3 M3 D3 ET
42 -177 -177 -177 -168 -135 -135 -111 -92
43 -172 -171 -163 -153 -117 -109 -96 -91
44 -76
12
20 BAW2053 EGKK FVHA 4391 -1 B74F
21 1271 330 493
31 I VEULE ROU BAMES RBT PTV NEV MTL MTG SOFFY PERLE COUTO
BALEN KAMER CSO
32 -89 -86 -82 -78 -74 -68 -60 -39 -30 -27 -24 -15 -10 6 7
33 310 321 330 330 330 330 330 330 330 330 330 330 330 330 330
41 =
42 -94 -94 -94 -75 -59 -59 -29 -10
43 -89 -88 -80 -60 -41 -33 -14 -9
44 7
78
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Table 11: Format of a system flight plan
Line No.
Description
00
Comment line
01
Current version of data format
02
Date on which the plans were archived
03
Date
04
Number of flight plans contained in the file
05
Indicates beginning of plan description
11
Indicates beginning of description type DEMANDED
20
Aircraft ID-departure aerodrome-arrival aerodrome-No CAUTRArelative date (in days, relating to reference day)-aircraft type
21
Departure time UTC (in minutes)-RFL-ground speed
31
List of beacons ordered according to followed route
32
Time over each beacon (in minutes)
33
Flight level for each beacon
41
List of traversed sectors ordered according to followed route
42
Strip entry time for every sector (in minutes)
43
Geo entry time for every sector (in minutes)
44
Exit time of last sector (in minutes)
50
Delay ATC-time allocated (in minutes)-point of allocation
51
List of regulations concerning the flight
12
Indicates beginning of description type REALIZED. The rest is
identical to the DEMANDED plan, if the data is identical there is
a “=” in the corresponding line
79
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ANNEX IV: RADAR DATA DESCRIPTION
Table 12: Example of radar data
CAUTRA
X
CAUTRA
Y
GM - LAT
GM LONG
23h59:
31.0
5828
4186
47N03’55
05E12’30
01h06:
3.0
4531
5875
50N41’52
01E25’10
NM-x
indic
Vitesse
FL
Heure
1
AFR
1466
000 kts
000’
2
PNR
601
490 kts
350’
3
• NM-x: Line number; irrelevant for the project.
• Indic: Callsign of the aircraft.
• Vitesse: Ground speed in knots.
• FL: Flight level in feet * 100.
• Heure: Time UTC at which the aircraft passes over a given point.
• CAUTRA X: Coordinate point in the CAUTRA format.
• CAUTRA Y: Coordinate point in the CAUTRA format.
• GM LAT: Latitude coordinate in format WGS 84.
• GM LONG: Longitude coordinate in format WGS 84.
We have collected radar data from the CRNA Nord in Athis-Mons and the
CRNA Est in Reims. Every CRNA carries out its recordings in the same format.
The position of each flight is recorded every eight seconds by radar, so that one
receives a very precise trajectory recording with all the above information.
80
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ANNEX V: METEOROLOGICAL DATA
The collected meteorological data is provided by Météo France. There is an
updated set of weather information every three hours UTC time about the outside
air temperature (in degrees Kelvin), the wind heading (in degrees) and the wind
magnitude (in metres/second). The measurements are taken at intervals of
10,000 feet up to an altitude of 50,000 feet; these altitudes are not expressed as
flight levels but as air pressure (in Isobars).
Latitude and longitude coordinates together with the altitude form a point in
space. For each latitude value there are ten longitude values in steps of 15 minutes. The latitude values are also separated in steps of 15 minutes.
In order to find out the actual weather conditions for a given radar track, it will
be necessary to interpolate between different values obtained from Météo France.
•
Temperature: Parameter “T”
LONGITUDE 3500 LATITUDE 5000 VALEUR 275.718750
LONGITUDE 3250 LATITUDE 5000 VALEUR 275.687500
LONGITUDE 3000 LATITUDE 5000 VALEUR 275.750000
LONGITUDE 2750 LATITUDE 5000 VALEUR 275.781250
.....
•
Wind heading: Parameter “DD”
LONGITUDE 3500 LATITUDE 5000 VALEUR 162.619049
LONGITUDE 3250 LATITUDE 5000 VALEUR 162.097092
LONGITUDE 3000 LATITUDE 5000 VALEUR 156.841644
LONGITUDE 2750 LATITUDE 5000 VALEUR 151.066879
.....
•
Wind magnitude: Parameter “FF”
LONGITUDE 3500 LATITUDE 5000 VALEUR 7.378403
LONGITUDE 3250 LATITUDE 5000 VALEUR 6.102624
LONGITUDE 3000 LATITUDE 5000 VALEUR 4.472177
LONGITUDE 2750 LATITUDE 5000 VALEUR 3.377075
.....
81
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ANNEX VI: CFMU DATA
Sample of an “All_Flights” plan (the field separator is “;”):
BGBW;EKCH;SAS298;SAS;B73S;9706172200;BB09195143;9706172200;FP
L;SAS298;290;NEXE;LONG;Y;Y;Y;_9706172200;AA;FI;NS;000603160;_;
_;_;_;N;_;0;0;_;ACH;_;_;FPL;FNM;_;_;_;2215:BGBW:NO_ROUTE:00037
:MY:NO_ROUTE:2900040:*6263:NO_ROUTE:2900045:CONNY:NO_ROUTE:290
0108:VALDI:NO_ROUTE:2900139:SOL:UP610:3300149:SOTAM:UP610:3300
156:LASPO:UP610:3300203:AAL:ATSEK17:3300213:TESPI:EKCHTESPI0C:
2430215:ROSBI:EKCHTESPI0C:1980218:TNO:EKCHTESPI0C:1300227:*1KA
S:EKCHTESPI0C:068 0232:EKCH:EKCHTESPI0C:0 ;0037:EKVGTIA:0045
0108:ENSVSN:0133 0133:ENSVSS:0149 0149:ENOSUPP:0156 0156:EKDKUSV:0213 0213:EKDKLSE:0217 0217:EKCHTMA:0232
Table 13: Description of the ALL_FT file
Field no.
Description
1
ADEP
2
ADES
3
Aircraft_ID
4
Aircraft_Operator
5
Aircraft_Type_ICAO_ID
6
AOBT
7
IFPS_ID
8
IOBT
9
Flight_Data_Quality # FPL, RPL
10
Flight_ID
11
First_Requested_Flight_Level
12
Exemption_Reason_Type
13
Exemption_Reason_Distance
14
Late_Filer
15
Late_Updater
16
North_Atlantic
17
COBT
18
EOBT
82
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Table 13: Description of the ALL_FT file
Field no.
Description
19
Flight_Status # TE (terminated), CA (cancelled), AA (ATC-activated), FI (filed), FS
(filed and slot issued), TA (TACT activated)
20
Status_Previous_To_Activation # FI (filed),
SI (slot issued), NE (not exempted)
21
Suspension_Status # NS (not suspended),
SM (slot missed), TV (trafic volume condition)
22
TACT_ID
23
SAM_CTOT
24
SAM_SENT
25
SIP_CTOT
26
SIP_SENT
27
Slot_Forced
28
Most_Penalizing_Regulation
29
Nr_Of_Regulations_Affected_By
30
Nr_Of_Regulations_Excluded_From
31
Last_Received_ATFM_Message
32
Last_Received_Msg
33
Last_Sent_Msg
34
FIELD_34
35
Original_Flight_Data_Quality # FPL, PFD,
RPL
36
Source
37
FIELD_37
38
FIELD_38
39
Min_To
40
Point_Profile ::= TimeOver:Point:Route:Level
41
Sector_Profile ::= EntryTime:Sector:ExitTime
83
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
REFERENCES
[ABC88]
ABC- ICAO Abbreviations and Codes.
Procedure for Air Navigation Services.
International Civil Aviation Organization Doc. 8400: 1988.
[ADEX93] Air Traffic Services Data Exchange Presentation (ADEXP).
Edition 1, Ref: 002/93.
[AP95]
Air Traffic Services Data Exchange Presentation (ADEXP).
Edition 1, Ref: 002/93.
[ATM97]
Airports User Requirements Document.
AIRPORTS/CES-TECH-W1-04-R5. Version 2.1.
[ATS88]
Air Traffic Services Planning Manual.
International Civil Aviation Organization, Technical Publication No.
9426.
[BCN92]
Conceptual Database Design: An Entity-Relationship Approach.
Carlo Batini, Stefano Ceri, Shamkant Navathe.
Redwood City, CA: Benjamin/Cummings 1992.
[Boo94]
Object-Oriented Analysis and Design with Applications (second edition).
Grady Booch.
Redwood City, CA: Benjamin/Cummings 1994.
[CFMU96] CFMU Handbook.
Eurocontrol, 12.12.96.
[COF97]
COFEE Interface Requirements Specification.
Eurocontrol 66242/D/IRS-001, Version 1.2: May 1997.
[DAC88]
Designators of Aircraft Operating Agencies, Aeronautical Authorities
and Services.
International Civil Aviation Organization, Technical Document No.
8585.
[DEC95]
DECADE FDPS - Requirements Specifications Part 3.
Object Model - Problem Domain Concept.
Document-Id: RS3_V0.DOC.
DFS Deutsche Flugsicherung GmbH.
Offenbach 1994.
[EAF96]
Operational Requirements Document for EATCHIP Phase III.
ATM Added Functions, Volume 1 and 2.
Eurocontrol, OPR.ET1.ST04.DEL01.01/02: 3.6.1996.
[EAT95]
EATCHIP III - Operational Requirements for FDMD Basic Functions
Core Functions (Area Control), OPR.ET1.ST03.1000-ORD-01-00.
Version: V21R draft, 28.11.1995.
[EMS97]
European Air Traffic Management System (EATMS).
Operational Concept Document.
EATCHIP Doc: FCO.ET1.STO7.DEL01, issue 1.0, 1.3.1997.
84
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
[EN94]
Fundamentals of Database Systems (second edition).
Ramez Elmasri, Shamkant Navathe.
Redwood City, CA: Benjamin/Cummings 1994.
[FDP97]
Operational Requirements for Flight Data Processing and Distribution
Core Functions (Area Control), OPR.ET1.ST03.1000-ORD-01-00.
Eurocontrol, 21.1.97.
[FMS95]
Integrating Flight Management System Data into Air Traffic Control.
EEC Note 28/95, EEC Task AS09, EATCHIP Task FCO/ET1/ST10.
Eurocontrol, Dec. 1995.
[GHJ+95] Design Patterns: Elements of Reusable Object-Oriented Software.
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.
Menlo Park, CA: Addison-Wesley 1995.
[ICAO85] Rules of the Air and Air Traffic Services - 12th ed.
Doc. 4444-RAC/501/12.
International Civil Aviation Orginzation.
Montreal Quebec 1985.
[ILex85]
ICAO Lexicon
International Civil Aviation Organization, General Publication
ICAO Document No. 9794.
Montreal Quebec 1985.
[ISST97]
Modelling Guidelines for Object-Oriented Analysis.
ISST Report 4/97, Edition 1.0: 14.4.97.
[JCJ+92]
Object-Oriented Software Engineering - A Use Case Driven Approach.
Ivar Jacobson, Magnus Christerson, Patrik Jonsson, Gunnar Övergaard.
Addison Wesley.
Wokingham England 1992.
[OBM97]
"Business Components for End-User Assembly" by Greg Baster.
In: Object Magazine, January 1997 issue.
[OOA97]
Object Oriented Analysis for Advanced Flight Data Management.
Eurocontrol, EEC Report No. 306, March 1997.
[OLDI95] EUROCONTROL Standard for On-Line Data Interchange
Draft 1.4
P. M. Bailey, Work Program Manager DED-2.
EUROCONTROL DPS-ET1-ST06-STD-01-00.
EUROCONTROL
EATCHIP Planning Division
96, Rue de la Fusée
B-1130 Bruxelles
[OHE96]
The Essential Distributed Objects Survival Guide.
Robert Orfali, Dan Harkey, Jeri Edwards.
New York City, NY: John Wiley&Sons, Inc. 1996.
85
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
[PID96]
Pilot Information Description.
Final Report DRA/LS1(ATC)/PID/CR/002-003-004.
Eurocontrol EATCHIP: 7.10.97.
[Pri96]
Developing Business Objects.
A Framework Driven Approach.
Robert Prins.
Maidenhead, Berkshire, England: McGraw-Hill 1996.
[RBP+91] Object-Oriented Modelling & Design.
J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorensen.
Prentice Hall Englewood Cliffs 1991.
[RTCA95] Report of the RTCA Board of Directors’ Select Committee on Free
Flight.
January 1995.
[Sch91]
Lexikon der Informatik und Datenverarbeitung (3. Aufl.).
Hans-Jochen Schneider (Hrsg.).
München: R. Oldenbourg Verlag, 1991.
[Sim94]
Business Objects - Delivering Cooperative Objects for Client-Server.
Oliver Sims.
Maidenhead, Berkshire, England: McGraw-Hill, 1994.
[WCS96]
Programming Perl (second edition).
Larry Wall, Tom Christiansen, Randal L. Schwartz.
Sebastopol, CA: O’Reilly&Ass. 1996.
[YWT+95] Mainstream Objects: An Analysis and Design Approach for Business.
Ed Yourdan, Katherine Whitehead, Jim Thomann, Karin Oppel, Peter
Nevermann.
Upper Saddle River, NJ: Prentice Hall, 1995.
86
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
GLOSSARY
ACC
Area Control Centre, a unit established to provide air traffic
control service to controlled flights in control areas under its
jurisdiction.
Active view
A view which is linked to the underlying objects such that
attributes and relationships represented in the view are
kept up-to-date with the states of the underlying objects.
Aggregation
A data abstraction which allows a relationship between
named objects to be thought of as a (higher-level) named
object. Aggregation is the concurrence of a certain amount
of characteristics into an object-type which can be referred
to without having to refer to its components, but can be
decomposed into the instances of the component objects.
AFTN
Aeronautical Fixed Telecommunications Network is the
standard communication network, based on teletypewriter
technology. AFTN will be replaced by ATN in the coming
years.
Aircraft
Any machine that can derive support in the atmosphere
from the reactions of the air other than reactions of the air
against the earth’s surface.
Airway
A control area, or portion thereof, established in the form of
a corridor equipped with radio navigational aids.
Altitude
The vertical distance of a level, a point or an object considered as a point, measured from mean sea level.
Application components
Manifestation of business objects within the context of the
Business Object Facility.
ATFM
Air Traffic Flow Management is the process of regulating
how many planes are in the system, while ensuring an optimum flow of traffic by preventing overload situations in
ATC centres.
ATM
The term used to describe the total system, ground and air,
needed to ensure the safe and efficient movement of aircraft, in all phases of operation. It covers airborne equipment (such as FMS) and the ATC systems; ATFM provides
management and control of air traffic, both in the air and on
the ground. Besides Air Traffic Control, ATM comprises Air
Traffic Flow Management (ATFM) and Airspace management (ASM).
87
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
ATN
Aeronautical Telecommunication Network, as successor of
ATFN will soon be the future basic communication facility
in aeronautics.
Atomic
Non-decomposable.
ATS
Air Traffic Services, a generic term meaning variously, flight
information service, alerting service, air traffic advisory service, air traffic control service, area control service,
approach control service or aerodrome control service.
Attribute
Describes a single, static property of an object and does not
have an existence independently of the object.
BADA
Base of Aircraft DAta. Developed by J.L. Renteux at the
Headquarters of EUROCONTROL, it supplies operational
data about the performance of aircraft types, at the moment
even taking into account the way different airlines use the
aircraft types resulting in different performance values. The
way it does this is by using a set of equations driven by coefficients for each aircraft type. The input is the environment
of the aircraft, such as air pressure, speed and so on, and
the ouput is data responding to the input.
Business Object
A representation of a thing active in the business domain,
including at least its business name and definition,
attributes, behaviour, relationships, rules, policies, and constraints. A BO may represent for example a person, place,
event, business process or concept. Typical examples of BOs
are: employee, product, invoice and payment.
Business Object
Facility
The infrastructure (application architecture, services, etc.)
required to support business objects operating as cooperative application components in a distributed object environment.
Cardinality
The number of instances that participate in a relation.
CAUTRA
(Automatic Air Traffic coordinator) French ATC system.
CFMU
The Central Flow Management Unit establishes regulations
in congested airspace by providing central Slot Allocation
within the ECAC member states. Its major objective is to
cut peaks in sector load, minimize Holding Pattern and
share delays on a fair basis.
88
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Common
Business Object
An object representing those business semantics that can be
shown to be common across most businesses. CBOs are
models, templates, designs and/or patterns which include
the necessary defined semantics for interaction. CBOs are
also runtime software constructs, and map without significant transformation to the design models.
Component
Concept of specialized, application-independent, encapsulated, unit of functionality.
Constraints
Rules defining static and dynamic application properties
that are not conveniently expressed using the object and
operation features of a data model.
Database
A collection of related data under control of a database management system (DBMS).
Data model
A term used in a variety of situations in connection with
data storage at either a logical or physical level but usually
the former. It normally implies a formally defined structure
within which the data may be represented.
DBMS
DataBase Management system, a software system for the
use and control of databases.
Elevation
The vertical distance of a point or a level, on or affixed to the
surface of the earth, measured from mean sea level.
Entity
A thing of significance, whether real or imagined, about
which information needs to be known or held. A different
word for ‘object’ or ‘object-type’, often used in connection
with Entity-Relationship modelling.
FDPS
Flight Data Processing System.
Flight
Management
System
Flight Management Systems (FMS) are part of the on-board
computer equipment of modern aircraft. FMS guides an aircraft on its trajectory using information on weather,
engines, Flight PLan and position.
Flight Plan
Specified information provided to air traffic services units,
relative to an intended flight or portion of a flight of an aircraft.
Flow Control
Measures designed to adjust the flow of traffic into a given
route, or bound for a given aerodrome, so as to ensure the
most effective utilization of the airspace.
Foreign key
A unique identifier in a table that is imported from another
table.
89
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
FPL
Filed flight plan, the flight plan as filed with an ATS Unit by
the pilot or his designated representative, without any subsequent change.
Gate-to-gate
service
Starts at the moment when the user first interacts with
ATC and ending with the switch-off of the engines. It also
includes the process of charging users for ATM services.
Generalization
A data abstraction which enables a class of individual
objects to be thought of generically as a single named object.
Generalization is the creation of a generic object when similar characteristics of different object-types are recognized
and grouped together to form the generic type. In the specializations the different properties of the disjunct specializations can be found.
Hierarchy
A ranking or ordering of abstractions.
Initial Flight
Plan, Initial
Flight plan
Processing
System
The Initial Flight plan Processing System is used to correct/
complete FPL. Corrected data will afterwards be sent to all
ATC authorities along the route and will be fed in the TACT
system as Initial Flight Plan (IFPL).
IFR
Instrumental flight rules, a set of rules governing the conduct of flight under instrumental meteorological conditions.
Instance
One (composed) element of data from one object type. Also:
database instance. The data in a database at a particular
moment in time. Something you can do things to. A single
real world thing.
Metadata
Executable form of business object information representation. This may include: constraints, rules, roles, policies,
relationships, states, attributes, visibility, dependencies,
protocols, pre- and post-conditions, error conditions, warning conditions, or events.
MTCD
Medium Term Conflict Detection.
New-Age Flight
Plan
The envisioned future flight plan to be filed by most airspace users in the US when ATC-AOC information
exchange is fully implemented. It will be based on the ICAO
flight plan, but with additional information on airline priorities and preferences.
90
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Normalization
A step by step process that produces relational definitions
that have:
- no repeating groups
- the same kind of values assigned to attributes or columns
- a distinct name
- distinct and uniquely identifiable rows.
Objects
All concrete facts, and abstractions thereof, which need to
be distinguished in an information system.
Object type
An abstraction of a group of similar objects in the real
world, including the typical characteristics of this group
(also called ‘data types’).
Path
The way an aircraft flies expressed in three dimensions.
Planned Flight
Data (PFD)
All flights published in the OAG are known as Planned
Flight Data within the CFMU context and only contain the
served city pair, i.e. no route information is provided.
Point
Any geographical location on the surface of the earth used
by any aspect of aviation.
Pre-Tactical
Phase
Pre-Tactical
system
Uses FPL data and statistical data to establish ANM.
Primary Key
The attribute in a relational table which uniquely identifies
the table tuples.
Primary Radar
A radar system which uses reflected radio signals.
Profile
The orthogonal projection of a flight path or the portion
thereof on the vertical surface containing the nominal track.
Query
A command given to the DBMS to search for specific data,
and return it in table formats.
Redundancy
When the same data is represented in more than one place
and/or way.
Reflection
Ability of a system to analyze and report its state and activities and to alter them based on this analysis.
Repetitive Flight
Plan (RPL)
A Repetitive Flight Plan is published by a operational carrier, announcing the served city pair, the preferred route,
flight levels and the frequency of flights, i.e. every Monday
& Friday.
91
REQUIREMENTS DEFINITION FOR ADVANCED FLIGHT PLAN INFORMATION
EUROCONTROL
Route
A planned way to fly between points.
Slot Allocation /
Slot Allocation
Message
The term Slot Allocation refers to the Calculated Take-Off
Time (CTOT) slot for a given flight and is sent to every regulated flight and all relevant ATC authorities along the route
by the CFMU.
Strategic ATC
constraint
Generated by airspace structure and organization of ATC.
Strategic System
As part of the CFMU Strategic System is used to calculate
sector workloads on a mid-term basis (6 month - 48h).
Surveillance
The representation of the measurement of an aircraft’s
present position independently of navigational position
sources aboard the aircraft.
System Flight
Plan (SFPL)
This is the FDPS internal representation of the flight plan
resulting from the Initial Flight Plan Processing. The SFPL
supports the real-time control of the flight and stores the
flight intentions for a given aircraft during the flight
progress.
Tactical ATC
constraint
These constraints represent controllers’ actions, guidance
orders, or clearances. They are divided into complete/incomplete constraints.
Tactical System
The Tactical System as is used for centralized Slot Allocation within the CFMU.
TMA
A control area normally established at the confluence of
ATS routes in the vicinity of one or more major aerodromes.
Track
The projection on the earth’s surface of the path of an aircraft, the direction of which path at any point is usually
expressed in degrees from North (true, magnetic or grid)
(ICAO).
Trajectory
The way an aircraft flies expressed in three dimensions,
plus time over the locations sampled.
View
A simplified representation that excludes some attributes,
relationships and operations, and also flattens a complex
structure. Insulates individual applications from evolutionary changes in the enterprise model.
92