FLIPAutomatic FLIght Plan management tool

State of the art – Background

By year 2020, the air transportation sector will produce a total of 800 billion tons of CO2, which underlines the urgent need for taking significant measures in reducing the range and volume of damaging emissions. This is why the Advisory Council for Aeronautical Research in Europe (ACARE) established four targets to be reached by the aviation industry by 2020:- a 50% reduction in CO2 emissions per passenger kilometre- a 80% reduction in NOx emissions- a 50 % reduction in perceived noise- make substantial progress in reducing the environmental impact of the manufacture, maintenance and disposal of aircraft and related products.

The first Clean Sky programme has been built to cope with these targets.With the aim of strengthening environmentally sustainable flight operations, the Systems for Green Operations (SGO) branch of the Clean Sky programme focuses achieving the above-mentioned reduction by working on improvements on one-hand on the management of the aircraft energy (all-electric equipment system architecture and thermal management) and on the other hand on the management of the trajectories and missions. In particular, dedicated work is required on new systems and procedures (to perform optimized trajectories in airport areas), on new systems for smart ground operations (for minimizing the use of the aircraft’s engine power on the ground) and on new or optimized technologies to adapt the flight path depending on local meteorological variations.

To achieve the CleanSky SGO objectives, specific developments need to be carried out to develop innovative green flight management functions in view of the prototyping of the Flight Management System (FMS) of the future. The integration of such new flight management functions requires the enhancement of on-board databases in order to handle environmental parameters required by the future FMS. To do so, the SGO part of Clean Sky needs to confirm in ground-based rigs the results obtained at TRL3-4 of those green FMS functions. With the ultimate objective to increase the technology readiness level and to

demonstrate the robustness of such green FMS functions up to TRL 5-6, a large number of validation scenarios need to be tested; they should cover a wide range of conditions where several parameters vary (weather conditions, aircraft parameters related to engines, to undercarriage etc).

In this context, a Call for Proposal was published, in order to enhance and automatize the FMS testing process by injecting into the FMS a large number of realistic flight plans.

Objectives

Consequently, it has been all about the FLIP project to develop and validate a software application compatible with the FMS test bench, able to provide and consult actual airlines flight plans databases as well as to inject into the FMS equipment under test specific flight plans representative of the dedicated robustness scenario to be validated.

This main objective has been developed in five sub-objectives, which made the overall FLIP project realistic, measurable and successful within a 15-month time frame.

1. The first sub-objective was to specify the overall FLIP system architecture as well as the Flight Plans file format, which would allow building all the validation scenarios needed for demonstrating the 5/6 technology readiness level of the newly developed green FMS functions.

2. Then, it was planned to build the FLIP database by collecting a very large amount of existing European, transatlantic and American airlines public flight plans covering the widest range variety of flight conditions (e.g. weather conditions) and to develop the FLIP database update process to be able to incorporate additional flight plans on a regular basis.

3. The third sub-objective was to develop a user-friendly Human-Machine Interface (HMI) allowing to display, search and edit flight plans.

4. It was also identified as a necessary achievement to develop a core business module managing the communication between the database, the HMI and the FMS test bench. This tool would handle the data exchange process to and from the FMS including for batch processing.

5. Finally, the last sub-objective identified was to integrate all the FLIP technological modules and to have tested and validated their full compliance with the CFP Topic leader requirements in the FMS test bench environment.

Description of work

Three main expectations were set forth in the initial Call for Proposal. The solution had to:- Provide a flight plan database consisting of public data from airlines,- Provide consultation means to query this database,- Provide a software tool able to inject a selection of flight plans into the FMS using the existing test equipment.

The solution achieved by the partners meets these expectations in many ways.

1. Flight plan database

1.1 Content of each flight plan: the FIXM format

Flight Plans are a keystone of aviation operations management. They are today filled by airlines with Air Traffic Management (ATM) authorities. They include information such as departure and arrival points, ETA of en-route waypoints, alternate airports in case of bad weather, etc. Consolidation of Flight Plans is performed on a regional level (EUROCONTROL Network Operations), so as to optimise the traffic efficiency.

All the exchanges of Flight Plan information between airlines and ATM are ruled by ICAO document 4444. This legacy standard, inherited from paper filing, is regularly maintained and improved. The latest upgrade has been performed in 2012 in Europe.

However, the ATM Flight Plan is not the unique flight plan model that Airlines Operational Centres (AOC) have to deal with. With generalisation of FMS, the need to be able to transmit flight plan information from AOC to the aircraft has emerged in the last decade. This has been standardised under ARINC702 specification, which uses ACARS data link system for automatic upload of flight plan updates.

More recently, with the development of paperless cockpit, still another scheme specified in ARINC 633, with more information embedded, was defined to feed Electronic Flight Bags (EFB) via IP data links.

As a result, today’s flight-related information between all stakeholders is not consistent in either format or content. Systems under the ATM

umbrella currently operate as separate entities servicing different flight domains. Each domain shares operational data using its own rules, definitions and formats. Communication between systems is mostly point-to-point, and the cost and complexity of establishing new interfaces – or modifying existing ones – is high. In many cases these systems maintain different data about the same flight, resulting in information segmentation. Furthermore, the information that these systems might have in common is sometimes named or represented differently, and a translation layer is required for these systems to communicate. Current information exchanges do not reliably support coordination, situational awareness, or collaborative decision making because they were designed to support their own domain exclusively.

This is why EUROCONTROL and the Federal Aviation Administration (FAA) (within NEXGEN / SESAR programmes), in conjunction with multiple other international partners, are currently in the process of developing the Flight Information Exchange Model (FIXM). FIXM is an interoperable, XML-based exchange model capturing Flight and Flow information that is globally standardized. The need for FIXM was identified by the International Civil Aviation Organization (ICAO) Air Traffic Management Requirements and Performance Panel (ATMRPP) in order to support the exchange of flight information as prescribed in Flight and Flow Information for a Collaborative Environment (FF-ICE).

FIXM is the equivalent, for the Flight domain, of AIXM (Aeronautical Information Exchange Model) and WXXM (Weather Information Exchange Model), both of which were developed in order to achieve global interoperability for, respectively, AIS and MET information exchange. FIXM is therefore part of a family of technology independent, harmonized and interoperable information exchange models designed to cover the information needs of Air Traffic Management.

FIXM aims to be the single common reference for information about flights available to all systems and air traffic stakeholders. It allows authorized system stakeholders and the Airspace Navigation Service Providers to electronically exchange consistent flight data that is tailored to their specific need and use. FIXM facilitates the sharing of common flight information between systems and enables collaboration using a common reference framework.

As a consequence, this state-of-the-art file format was chosen to store and transport flight plan information within the proposed solution. In particular, this format allows to store in a normalized way all the pieces of information required to initialize the target FMS:- Departure Procedure:

- Departure Airport- Departure runway- Standard Instrument Departure (SID)

- En-route:- Waypoint list (ICAO ID and/or

geographical coordinates)- Cruise Flight level- Arrival Procedure:- Arrival Airport- Arrival runway- Approach- Standard Terminal Arrival Route (STAR)

The target FMS also requires information pertaining to the aircraft associated with each flight plan. This type of information is not covered by the current FIXM specification. That’s is why the delivered database contains additional information allowing to run flight plans with a large number of aircraft types. These elements of information not covered by the FIXM specifications are:- Cost Index (CI)- Zero Fuel Weight (ZFW)- Zero Fuel Centre of Gravity (ZFCG)- Block Fuel- Low Speed (V1, VR, V2)

1.2 Flight plan gathering process

To build up a signification flight plan database, the partners concluded an agreement with two flight plan providers: the FAA for North American flight plan, and EUROCONTROL for European flight plans.

The FAA flight plans are provided by HARRIS CORPORATION through their web service named FOXS (Flight Object eXchange Service). The HARRIS FOXS REST Interface provides an API for clients to consume FIXM formatted flight information such as flight plans, tracks, hazardous cargo, and fleet priority information. In addition to Flight Object services, a Globally Unique Flight Identifier (GUFI) web service manages flight object IDs. The current FIXM versions supported within FOXS are versions V1.0, V1.1 and V2.0.

The FOXS database is reachable through a Virtual Private Network (VPN) thanks to a VPN client. This service is then usable in both Linux and Windows environments. Credentials are required to connect to FOXS, and were negotiated for the duration of this project.

The Harris Flight Object Query REST Service enables the client to query for a flight object (FO) using several methods. The main ones are getGufis, getFlightHistory and getFlightObjects. The last one has been used in our case. Groups of Flight Objects can be queried through either the aircraft identification, departure airport, destination airport, status of the flight plan, aircraft type or airline.

In order to avoid any overload issues (at most 1000 flight objects can be returned per request), the query aims at requesting all the Flight Objects from a specific origin airport to a specific destination airport. The target list of airports will consist in the 30 main airports in the world in addition to an exhaustive list of North American airports (see deliverable D2.1, Appendix C).

To generate a FIXM database from a set of FOXS responses, a specific tool has been developed in Linux Bash scripting language.

As a result, more than 30,000 FAA flight plans were obtained thanks to this agreement with HARRIS Corporation over a period of six months. Not all the flight plans flown during this period were collected (only a selection of IFR flight plans).

As regards European flight data, EUROCONTROL NM B2B service provides to eligible operational stakeholders a set of programming tools that enables them to develop user software applications. NM B2B is based on open web service technologies that don’t require the installation of proprietary software. SOAP and REST-like web services are available through NM B2B.

Today, NM B2B provides the following services:- Flight Services (flight plan preparation, flight plan filing and associated operations, flight data retrieval)- Airspace service (electronic airspace management information, FUA service, airspace data)- Flow services (ATFCM Notification Messages)- General information services (ATFCM Information Messages)

Moreover, two kinds of services are implemented: the Operational service (OPS) platform, which is used for operational applications and the Pre-operational service (PREOPS) platform, fed with live data, available for application testing.

In FLIP’s scope, the PREOPS service has been used to collect data.

The NM B2B service requires certificates delivered by EUROCONTROL. The procedure to obtain such certificates outside of the frame of this project is provided in deliverable D2.1, Appendix F. As the web service does not provide FIXM data directly, Jumpstart (a research software tool developed by EUROCONTROL) was used to as an interface to obtain FIXM 2.0 flight plans.

As a result, more than 700,000 European flight plans were obtained thanks to this agreement with EUROCONTROL, over a period of three months. Almost all the flight plans flown during this period were collected, with the exception of a few dates where technical difficulties occurred (service unavailable, gathering errors, etc.)

1.3 Significant start dataset

In the end, the total number of collected flight plans covers amply the requirements expressed in the call for proposal.

2. Consultation means

2.1 Efficiency of the flight data management system

Since all flight plan data and aircraft data are provided as XML files in a file structure, the choice of a Native XML DBMS has been made. In fact, the choice of a Relational DBMS (such as Oracle), an Object-Oriented or an Object-Relational DBMS would have implied to design data models matching FIXM data and aircraft data. Therefore, choosing a Native XML DBMS is much more straightforward.

It is also much more flexible since Native XML DBMS are able to store data in any XML format. Any data model may then be stored in the same DB instance.

BaseX has been chosen based on the thesis by Christian Grün at Universität Konstanz, and

especially on the results of the benchmark he ran on different Native XML DBMS open source implementations, namely BaseX, Monet, QIZX and eXist. Dr Grün has used XMark as a common reference to compare storage and queries performances. He has demonstrated clearly that BaseX is the most efficient and the fastest implementation of all available open source Native XML DBMS.

BaseX stores XML documents in their DOM representation; that is as a tree of DOM elements. BaseX manages, for each node in the tree, a set of values in order to retrieve efficiently adjacent nodes in all axes defined by XPath. BaseX actually manages tag names, URIs, attribute names, attribute values and text content in different tables (which rows are referred from the main table) because those kinds of DOM elements do not need to be ordered.

BaseX also offers optional Full-text indexes organizing parts of text data depending on locale languages. These indexes are case insensitive, diacritics (such as accents) are removed and tokens are stemmed via dictionaries (including or not a thesaurus) and some tokens may be skipped that are defined in an optional stop word list.

As a consequence FLIP software is based on a very efficient, state-of-the-art XML data search engine.

2.2 Search criteria

All the data elements from the FIXM flight data model can be used as filters to build a search query:- Departure/arrival time- Departure/arrival airports (primary and alternate)- Runway information: length, name, landing system class- Airport procedures (SID, SID Trans, STAR, STAR Trans, VIA, Approach)- Flight duration and length- Cruising level and speed- Presence of a given waypoint/airway in the route

In order to improve query performances further on, additional data is computed before a flight plan is pushed into the database, to model complex business criteria defined in collaboration with the Topic Manager. These additional pre-computed elements are:- Length of the cruising phase

- Number of waypoints/airways in the route- Polar overflight- Equator crossing- Minimum and maximum distance between two consecutive waypoints- Presence of cruising level changes- Presence of specific constraints associated with airport procedures

The software tool provides a user-friendly GUI to define a flight plan query, which can be a combination of any of the aforementioned search criteria.

2.3 Interactive visualization tool

FLIP software is written in JavaScript, HTML5 and CSS using the application runtime environment node-webkit, which is based on WebKit (the layout engine component of Chromium) and node.js.

This approach allowed the flight plan search GUI to be implemented with regular HTML5 controls (text fields, time controls, check-boxes, etc.) All the details of any flight plan can be obtained by selected its identifier with the mouse.

2.4 Multiple flight plans representation

The other advantage of using Web technologies to build FLIP’s UI, is that all the npm modules are available. For instance, Leaflet is the module that was used to manage the mapping capabilities. It uses the Web Map Tile Service standard to fetch maps from a server (that may be local directory).

In addition to this map representation, it is also possible to examine every flight plan in detailed full text description.

2.5 Flight plan creation/modification tool

To enable users to test the FMS with unusual flight plans, which may not exist in the flight plan database delivered along with the software application, FLIP was endowed with flight plan edition capabilities.

To modify a set of features of a selected flight plan, a specific GUI can be used. The list of features that may be modified has to be exhaustive. It consists in the fields of the ICAO 4444 form (only those relevant to the context of FLIP) in addition to a sequence of latitude/longitude points.

Similarly, to create a flight plan from scratch, FLIP offers the possibility to automatically fill in the sequence of latitude/longitude points by looking up the route labels in the navigation DB. In the case where no navigation database is available, the points have to be entered manually. When a navigation DB is available and the route contains a label associated with more than one latitude/longitude location in the navigation DB, the user is asked to choose among these locations. In any case, the user will be allowed to modify the sequence automatically generated.

Throughout the process of completing the flight plan features, the user is informed of the data completeness (i.e. whether there is enough information to allow FMS initialization). Should any information be missing, the GUI allows the user to look up for it in the navigation database.

3. Provide a mean to inject flight plan into the FMS equipment under test

To be able to communicate with the FMS test bench, the software application had to be compatible with various external agents:- A navigation database accessible through an API specified by the Topic Manager.- The test bench itself is designed to listen to messages over the standard AOC protocol. An API to generate such messages was also specified by the Topic Manager.- To enable users to run batch tests, the software application was requested to be able to generate scripts in a scripting language that may or may not be entirely defined by the end of the project.

All these aspects were successfully tested in real environment during the integration and validation phases of the project.

3.1 Compatibility with current navigation database API

To operate the FMS correctly, some details are missing in the FIXM flight plans as obtained by both data providers. For instance, it is necessary to know the detailed airport procedures as well as the runways to use for the FMS to accept a flight plan. These elements of information can be inferred from the content of the flight plans available with the support of a navigation database. To ensure flawless compatibility of the delivered application with the target technical environment, the Topic Manager provided the partners with the specifications of a Java API

available on-site to query such a navigation database. Thus, FLIP was endowed with the necessary software interface to this API, so as to complete any incomplete flight plan when uploading it into the database.

3.2 Compatibility with current AOC protocol API

Once all the data necessary to describe a flight plan with enough details for the FMS to fly it, FLIP can send it to the test bench over a standardized protocol (AOC protocol). The Topic Manager provided a grammar specification that was implemented in FLIP’s source code so that messages can be generated out of FIXM data. FLIP application is able to broadcast such messages over UDP protocol, which is the communication expected by the test bench.

3.3 Compatibility with current and future batch grammar

At the time of the implementation of the application, the target scripting grammar to use for batch processing was not definitively decided upon. To maximize the usability of the software application, the users can define script templates thanks to a flexible grammar allowing to mix hard-coded text elements with flight plan attributes (and optionally, control structures like loops for instance).

Results

a) Timeline & main milestones

MS1 Kick off meeting (T0)MS2 Requirements Review (T0+4)MS3 Integration Readiness Review (T0+11)MS4 First Tools delivery (T0+10)MS5 Final review (T0+15)

b) Environmental benefits

As mentioned earlier, the project accelerates the maturation of the green functions of the FMS by developing an automatic management tool to be integrated into an FMS test bench. It allows handling, visualizing and injecting selectively dedicated flight plans, selected for their representativeness of the different scenario for which the green FMS functions’ robustness needs to be tested.By using the FLIP tool and by working on actual and operational airlines flight paths data, there will be a possibility to compute accurately the fuel consumption savings that the ‘future green FMS’ will be in position to generate thanks to the adoption, in a reactive mode but in full safety, of adapted trajectories.

c) Maturity of works performed

By increasing the TRL of the green FMS functions from 3/4 to 5/6 , the FLIP tool will help accelerating the introduction on the market of the future European green FMS solution, thus proving faster to Airlines the opportunity to generate , in real conditions, substantial fuel savings. The FLIP tool makes now possible to compute precisely how many tons of fuel could be saved in a year by introducing on the market such Green FMS functions on new aircrafts.By allowing for a more rapid deployment of such green solutions onto the market, the FLIP tool fully complies with the SGO ITD expectations and contributes, at its own level, at limiting the impact of aeronautical activities on the environment.

FLIP Main window: selection of Flight Plans in the database to test the FMS

Project Summary Acronym : FLIP

Name of proposal: Automatic flight plan management tool for integration in bench for

avionics equipment validation

Technical domain: Transport, Management of Trajectory and Mission

Involved ITD System for Green Operation (SGO)

Grant Agreement: 632479

Instrument: Clean Sky JU

Total Cost: 403 680 €

Clean Sky contribution: 302 760 €

Call: JTI-CS-2013-2-SGO-03-25

Starting date: 01/04/2014

Ending date: 30/06/2015

Duration: 15 months

Coordinator contact details: Luc ORIAT,

ORME, 227 rue Pierre Gilles de Gennes, 31670 LABEGE, FRANCE

+33 5 61 00 25 70

luc.oriat@orme-toulouse.com

Project Officer: Antonio Vecchio

Antonio.Vecchio@cleansky.eu

Participating members ORME (Labège, France)

ATMOSPHERE (Ramonville, France)