Skip to main content
European Commission logo print header

Knowledge-based EFB for green flight trajectory decision aid

Final Report Summary - KLEAN (Knowledge-based EFB for green flight trajectory decision aid)

Executive Summary:
The objective of the KLEAN (Knowledge-based EFB for green flight trajectory decision aid) project has been the development of a custom knowledge-based EFB (Electronic Flight Bag) with SW packages implementing Advanced Weather Radar Post-processor (AWRP) and QAI (Quasi-Artificial Intelligence) agent algorithms for green trajectory optimization (reduction of CO2 and NOX emissions as well as noise pollution).

The AWRP is a software tool that processes the polarimetric radar signals in order to provide hydrometeor classification maps and related no flight zone based on threshold parameters of the weather risk settable by the user.

The QAI is an event based software tool that provides flight trajectory that allow to avoid the no flight zone, whether provided by the WRPP and by any other informative source, and optimize the fuel consumption and the emitted noise.

The EFB has been also customized to include an ad hoc Graphical User Interface (GUI) for output presentation and pilot interaction and custom I/O interfaces to radar processor, external sensors/systems/database and the Mission/Flight simulator.

To get this goal, the following activities have been carried out:

• KLEAN architecture - A specific architecture for implementing the AWRP and the QAI functionalities on a generic EFB has been defined. A four main modules (AWRP, QAI, GUI, I/O interfaces) interconnected among them has been designed,

• EFB overview, selection and purchasing. After a market analysis the EFB Nexis, produced by Astronautics Corporation of America, has been the one most complying with the project necessities in terms of presence of a Software Developer’s Toolkit, powerful in computing capabilities and completeness with all the possible avionics interfaces,

• SW integration and refinement of AWRP and QAI agent algorithms for green trajectory optimization: the AWRP algorithm have been optimized and coded for the EFB Nexis,

• GUI design. A specific GUI for result display and user control on the EFB Nexis has been fully designed and implemented,

• Specific I/O interfaces for the AWRP, for the Mission/flight simulator and for the internal/external sensors/system/database has been fully design and implemented for the EFB Nexis,

• All the software tools have been integrated and implemented in the KLEAN_V1.0 SW package that run over the Nexis EFB. The EFB Nexis with installed the KLEAN_V1.0 is the final product of the KLEAN project,

• The Testing of the KLEAN_V1.0 have been carried out simulating true flight plane and realistic polarimetric radar signals,

• A Roadmap for the KLEAN system certification has been also provided.

Project Context and Objectives:
Technical background

An Electronic Flight Bag (EFB), according to the FAA's Advisory Circular (AC No. 120-76A), is an electronic display system intended primarily for cockpit / flight deck or cabin use. It has been designed to replace the traditional pilot flight bag and to reduce or eliminate the need for paper and other reference materials in the cockpit. In addition, EFB devices can display a variety of aviation data or perform basic calculations. It typically consists of a screen and a control unit that may be installed, mounted or contained in one sole portable unit. According to the FAA, EFBs can be divided into three hardware classes:

• Class 1: Standard commercial-off-the-shelf (COTS) equipment such as laptops or handheld electronic devices. These devices are used as loose equipment and are typically stowed during critical phases of flight. A Class 1 EFB is considered a Portable Electronic Device (PED). They can only read data from the aircraft systems and receive/transmit data connectivity for Aircraft Administrative Communications (AAC) only.
• Class 2: Also PEDs, and range from modified COTS equipment to purpose-built devices. Typically, they are connected to the aircraft during normal operations. They require an administrative control process before the use in the aircraft. The EFB data connection may receive information from any aircraft system as well as receive or transmit information for AAC purposes.
• Class 3: Considered “installed equipment” and subject to airworthiness requirements and, unlike PEDs, they must be under design control. The hardware is subject to a limited number of RTCA DO-160E requirements.

The EFB may host a wide array of applications, categorized in three software categories:

• Type A: pre-composed, fixed presentations of data currently presented in paper format. They are then static applications, such as document viewer (PDF, HTML, XML formats) used to read printed documents.
• Type B: dynamic and interactive applications that can manipulate data and presentation. Examples are: flight performance calculation and panning, zooming, scrolling, and rotation for approach charts.
• Type C: applications that require Aircraft Certification Service (AIR) design approval, except for user modifiable software, which may be utilized to host Type A and B applications. Examples of Type C applications include primary flight displays.

Objectives

The MAIN OBJECTIVE of the KLEAN project is to develop a custom knowledge-based EFB (Electronic Flight Bag) with SW packages implementing Advanced Weather Radar Post-processor (AWRP) and QAI (Quasi-Artificial Intelligence) agent algorithms, provided by Selex Galileo, for green trajectory optimization (reduction of CO2 and NOX emissions as well as noise pollution).
The EFB is also customized to include an ad hoc Graphical User Interface (GUI) for output presentation and pilot interaction and custom I/O interfaces to radar processor, external sensors/systems/database and the Mission/Flight simulator.
To get this goal, the following SPECIFIC OBJECTIVES are aimed:

Ob.1 - EFB overview, selection and purchasing.
Ob.2 - SW integration and refinement of AWRP algorithms.
Ob.3 - SW integration and refinement of QAI agent algorithm for green trajectory optimization.
Ob.4 - Design and implementation of a GUI interface for result display and control.
Ob.5 - Design and implementation of a few I/O interfaces for the AWRP, for the Mission/flight simulator and for the internal/external sensors/system/database.
Ob.6 - Realization and testing of a demonstrator of the KLEAN system.
Ob.7 - Roadmap for the KLEAN system certification.

Innovative contributions of the project

The innovative contributions of the project are summarized in:

In1 - A customization of existing EFB with new advanced functionalities for facilitating the pilot on the decision of trajectory changes in presence of evident external change conditions
In2 - SW integration and refinement of advanced radar post-processing and QAI agent algorithms for green trajectory optimization
In3 - Design and implementation of customized GUI interfaces for a friendly interpretation of QAI outcomes and for EFB system control
In4 - Validation and testing of the customized EFB to specific realistic operative scenarios through the use of mission/flight simulator in order to enhance the added value provided by the KLEAN system.
In5 - Roadmap for the FAA certification of the KLEAN EFB.

Progress beyond the state of the art

Classical EFBs are capable to show the map and the trajectory of the aircraft, in order to show to the pilot where he/she is flying. Plus, they provide information about the aerial traffic along the route and the meteorological condition, receiving data from other avionic systems like the on-board weather radar or sensors like the ADS-B. Often weather information are not very refined, and it is impossible to know the level of hazard that the encountered phenomenon poses. Thus, pilots decide to evade with a greater detour the potentially dangerous area, even if in reality it would pose very little hazard. Only thirty percent of "red echo" radar returns represent actually a threat. These detours involve higher polluting emission due to the longer trajectory, higher fuel consumption and, ultimately, a greater impact on the environment. In EFB of class 2, type B, the weather provided by the weather radar can be displayed to the pilot. Moreover, a planning program can operate on EFB to plan a new trajectory to a different goal if needed, giving to the pilot an immediate tool to better evaluate the decision of taking a detour.
Weather factors cause hazards to flight in any of its phases. Studies of aviation show that only a small fraction of accidents due to bad weather conditions occur during the cruise phase, the largest fraction of an aircraft light time. On the other hand, most accidents happen during the take off-climb or the descent-approach-landing operations. On the contrary, trajectory changes due to bad weather conditions, with related longer flight paths and increased fuel consumption and consequent greater environmental pollution, occur mainly in the cruise phase, including subsequent decision about detour on a different arrival airport. The main proposed enhancement in EFB class 2 type B consists in two main aspects:

- 1) The weather representation is extended respect to classical weather radar acquisition, in term of distance covered by the forecast and in term of better understanding of the condition near the aircraft. With radar polarimetry it is possible to understand more accurately what lies within the core of a phenomenon, and to classify different types of hydrometeors like hail (one of the most dangerous weather phenomena), rain (usually non-dangerous) or snow. With this knowledge, it is possible to calculate more efficient routes that take into consideration the estimated level of risk (e.g. evading hail dominated zones or penetrating non-turbulent rainfalls).

- 2) The online planning algorithms are capable of using updated weather conditions and risk regions to compute in a fixed amount of computational time a new trajectory that reduces the emissions of CO2, NOx and noise. The resulting Decision Support System (DSS), due to time constraints of online processing, shall be capable to compute suboptimal solutions based of graph discrete representations of the problem parameters. The suboptimal trajectories are determined using fuzzy decision systems, dynamic programming and genetic optimization techniques on multi-objective functions.

Project work plan

Operationally the KLEAN project has been implemented with nine Work Packages (WPs) whose interactions are shown in the project flow of Fig. 1 (see attachment),

WP1 - Project management
This WP primarily aimed at providing a structured system for the full administrative and technical management of the project.

WP2– System requirements and architecture design
The main architectural functional blocks of the KLEAN system have been defined and the specific requirements for each block have been detailed in terms of input, output and requested performances. Methodologies, techniques and software architecture have been detailed.
The SW architecture design and the software integration have been made taking into account the aeronautical standards and best practices. Also Workshops and special meeting with pilots have been made for defining the high level system requirements.

WP3 – EFB system analysis, selection and performance analysis
The goals of this work packages have been the overview of the existing EFBs and the analysis of the main characteristics in terms of type, class, re-configurability, reliability, customizability. Then selection criteria based on the accessibility of the EFB SW development tools and on the EFB computational performance have been defined. Astronautics Corporation of American has been selected as the best SUB by the “best price-quality ratio” and by its experience in the EFB production.

WP4 – SW analysis and refinement of the Polarimetric Weather Radar post-processor (AWRP) algorithms
The algorithms of the Polarimetric radar post-processing provided by Selex Galileo have been analysed and optimized to be compatible with the EFB hardware characteristics and with the SW development framework of the chosen EFB platform. Some algorithm refinements have been made following some pilot suggestions during ad hoc KLEAN meeting and workshops

WP5 – SW analysis and refinement of the Quasi-Artificial Intelligence (QAI) agent algorithms
The QAI agent algorithms provided by Selex Galileo have been analysed and optimized for the EFB hardware characteristics. Some refinement and specific coding of the QAI algorithm have been made and new functionalities and option have been added following suggestions and advises of pilots during ad hoc KLEAN meeting and workshops.

WP6– Graphical User Interface (GUI) design and implementation
The goal of this WP has been the design and the implementation of a friendly graphical interface for AWRP and QAI display and control. The GUI has been designed to interact with pilots for system control. The proposed touch screen GUI is easy to use and friendly. The graphical and numerical representation of the information on screen has been designed in order to reduce end users perceptual and cognitive workload, and to reduce the potential to misinterpret indicators. To achieve this goal, a pre-test phase based on an interview on a selected groups of civil aircraft pilots has been carried out.

WP7– I/O interfaces
Specific I/O interfaces have been designed, developed and implemented. Interfaces with EFB external devices account for: 1) Interface with the FMS, 2) Interface with the on board communication systems, 4) Interface with other sensors, 4) Interface with the Weather Radar Processor (WRP), 5) Interface with the Mission/flight simulator. Interfaces with EFB internal modules and database: a) Interface with the EFB database, b) Interface between AWRP and QAI SW modules

WP8 – KLEAN system test and assessment
A test plan has been defined for validating and analysing the performance of each sub-system and of the overall KLEAN system in comparison with the call requirements. The systems have been tested on specific operative scenarios based on Mission/flight simulator. The goal has been the quantitatively assessment of the added value provided by the new implemented functionalities for improving the flight trajectory in terms of lower fuel consumption, emissions and noise pollution as well as the performance assessment of the designed GUI and I/O interfaces.

WP9 - Exploitation and dissemination
This WP outlined how to develop an exploitation and dissemination of KLEAN results in the SGO CLEANSKY program, in other European projects (FP7, etc.), manufacturing industries and in the technical and scientific community, following Clean Sky JU directives. The certification roadmap for the EFB upgraded with KLEAN tool to get the final certificate from the competent authorities has been provided. Workshops and scientific conferences have been carried out in order to receive appropriate feedbacks on the KLEAN system.

Project Results:
System requirements and architecture design

The objective of the KLEAN project was the customization of an Electronic Flight Bag (EFB) with the integration of new SW packages implementing Polarimetric Weather Radar Postprocessor (WRPP) and trajectory optimization system based on artificial intelligent agent algorithms (Q-AI, Quasi-Artificial Intelligence), provided by SELEX Galileo, for green trajectory optimization (reduction of CO2 and NOX emissions as well as noise pollution).

In order to create an operative background for the KLEAN architecture design a questionnaire for pilots related to the use of EFB was prepared and submitted. The questionnaire has been submitted to a group of seven selected pilots. According to pilot responses, the proposed EFB results very useful and interesting. In particular, such device can largely improve flight safety aspect, while they do not see many improvements in terms of Reduction of air pollution and Reduction of noise annoyance. In their opinion, the main interesting aspect of the EFB is the integration with the weather-radar.

From a technical point of view, the pilots find the EFB very useful in the cruise phase of the flight, while the use in SID or STAR seems very problematic due to the heavy traffic characterizing the airports. The questionnaire pointed out a possible criticality. According to pilot opinions too much information (weather, plus old trajectory, new trajectory, etc.) on a single instrument can be problematic: the attention of the crew could be focused too much in the new devices creating a sort of complacency

The general architecture of the KLEAN system is shown in Figure 2. It is composed by functional blocks and connection links. The WRP is an external block located between the output digital interface of the polarimetric radar receiver and the input interface of the EFB. Its main purpose is to process the raw data coming from the polarimetric weather radar. The WRP role is to extract the polarimetric features which will be used by the WRPP inside the EFB for weather phenomena classification and risk assessment purposes.

The Weather Radar Post Processor (WRPP) is the functional block integrated in the EFB that is interfaced in input with the WRP. Its main purpose is to process the polarimetric features provided by the WRP for hydrometeor classification. The WRPP will interact with the pilot GUI, to provide simplified, easy-to-read reflectivity maps and detailed hydrometeor classification maps with related classification confidence, and with the Q-AI block, to provide a synthetic representation, on a geo-referenced spatial grid, of dangerous weather situations, such as heavy turbulence or hail.

The Q-AI trajectory optimizer block is aimed for supporting the pilots during normal and safe situations. It is part of the DSS (Decision Support System) in charge of helping the pilot, when a new event happens, to select the better trajectory in term of a selectable criteria (emissions reductions, time, etc.), decreasing the decision time safely. Q-AI is activated by unforeseen events that can affect the planned trajectory. If the pilot can/must change the planned trajectory, Q-AI can suggest a new trajectory. Q-AI produces trajectories optimized in term of emissions of CO2, NOx and Noise reduction. The optimized trajectories are computed on the basis of aircraft types, aircraft dynamics, weather conditions, wind fields, and regions to be avoided (for example as there are dangerous weather phenomena). The Q-AI block into KLEAN EFB performs two main functions: Event Management and Trajectory Management.

The Q-AI Event Management module manages events that can be generated by the following sources: new data from the Weather Radar, new data from the Flight Management System, new ground information (i.e. NOTAM, METAR, ATC/ATM information, new forbidden areas), new messages from other aircrafts (i.e. advising about turbulence or wind in a certain zone). A change in one or more of these external events may need an urgent decision making process. The Q-AI Trajectory Management module is made by the following applications: Trajectory Generation, Trajectory Validation and Trajectory Decision.

The GUI block has a double role: it visualizes the data provided by the WRPP and the Q-AI and allows the input of user defined configuration parameters. The GUI have been designed based on the outputs of the WRPP and Q-AI trajectory optimizer as well as on the analysis and interpretation of pilot answer to interview and questionnaire. The GUI was designed also in accordance with the expectation of pilots about the presentation of the meteorological and trajectory information on the GUI display as well as on the touch command interface.

For the visualization purposes, the GUI is directly connected to the internal data base. From the data base the GUI reads the information provided by the WRPP and from the Q-AI (meteorological and trajectory information) and visualize these information. The data can be displayed in graphical and/or numerical modes according to user settings. The GUI allows the pilot to choose which information to be visualized with a configuration menu.

The GUI will also allow the pilots to insert some configuration parameters for the WRPP and the Q-AI. The GUI cab be used via touch screen input interface.

The Internal database is the storage block of the data that are necessary for the KLEAN operation. Within the internal database, various types of data can be stored permanently as well as temporarily.

The specific requirements for each component of the KLEAN system have been defined in terms of input, output and requested performances. All these data have been lead to the overall EFB system requirements in terms of computational power, display memory, number of cores etc.

Fig. 2-KLEAN architecture scheme

3.2 EFB system analysis, selection and performance analysis

The main requirements that affected the EFB provider selection are the following:

- the implemented software shall run, at least, on EFB class 2 Type B that shall have and Open Architecture,
- the Software shall be implemented in accordance to AC 120-76 (rev B) Guidelines for the Certification, Airworthiness, and Operational Approval of Electronic Flight Bag Computing Devices.
- the software shall read from Share memory, Database, the LAN, or WIFI,
- the software shall read from the LAN or WIFI connection or from database contained on EFB,
- aircraft flight data (position, speed, etc.) provided by FMS,
- flight plan with the predefined global trajectory (3D or 4D) uploaded before flight,
- database with the off flight areas, uploaded before flight,
- weather data, provided by WXR and by aircraft bus, or preloaded GRIB files,
- concurrent routes bounds, uploaded before flight.

The software application has to run on a portable workstation that has at least as CPU a quadcore i7 or similar, 8 Gigabyte of RAM, touch screen, OpenGL and CUDA compatible GPU, 2 Ethernet (1 Giga Ethernet), AFDX port, ARINC 429 port, USB port..
The EFB has to guarantee that the graphic elaboration does not interfere with the CPU load needed by trajectory optimization. The graphic device and the display must be able to represent the result of the trajectory optimization with the necessary resolution. The display resolution shall be at least XGA (1024 x 768).
The workstation has provide a suitable data interface to collect the input variables from the aircraft database. Moreover, it shall provide external access to its file system by means of standard USB cable and (optionally) wireless connection.

Fig. 3: List of EFB providers

The EFB providers (see Figure 3 for a snapshot of the producer’s logo) have been analysed and ranked taking into account mainly the set of software requirements and the hardware that can support such requirements. Moreover, in order to effectively obtain a support for the subcontracting activity, the following factors have been considered, selecting companies that could sell EFB software:

- clear prices;
- logistic convenience, mainly concerning customs, distance and time zone;
- cross-platform software support;
- software development kit (SDK) availability;
- previous experiences with third party application integration;
- if the company can sell the hardware directly;
- hardware availability of avionic interfaces;
- hardware class of EFB;
- full on-board solutions;
- if the company can sell avionic maps directly;
- can the company provide support for SUB 2;
- has the company good certification competence for SUB 3;
- company’s contacts were quick and helpful in answering.

Among all the providers that replied to the request for quotation for EFB, the possible choice was limited to three companies which showed interest in cooperating with KLEAN project and that have systems with characteristics complying with our requirements.
The system offered by Astronautics, the NEXIS EFB (Figure 4), was ranked the best one since it was the most complying with the project requirements.

Fig. 4 - NEXIS EFB unit on the left, display unit of the right

The Astronautics’ NEXIS EFB solution is composed by a display unit and an electronic unit; it provides:
- Class 2 and 3 EFB product running a Certified Linux Operating System, DO178 Level C;
- 8’’ XGA 1024x768 pixels display on display unit;
- 2 GHz Core i7 Intel CPU;
- 4GB DDR3 1066 MHz memory;
- touch screen;
- 8 ARINC-429 receive channels, 4 ARINC-429 transmit channels;
- 1 ARINC-717 receive channel;
- 4 full duplex Ethernet channels (10/100 Base-T);
- 1 USB port on display unit, 2 USB ports on electronic unit;
- 1 RS-422 channel.

The package also include the SDK that allows the development of Class2 Level B applications to be executed on top of the provided certified Operating System. The SDK has all the characteristics required to correctly implement the KLEAN project.

3.3 SW analysis and refinement of the Polarimetric Weather Radar post-processor (AWRP) algorithms
A critical analysis of the general architecture of the avionic radar processing chain proposed by Selex ES, with specific reference to the Weather Radar Processor (WRP) and Weather Radar Post-processor (WRPP), have been carried out. Specific processing procedures for implementing realistically and satisfactorily the WRPP module of the KLEAN system on the EFB have been identified. In particular, since the core of the WRPP is the hydrometeor classification system, the analysis was focused on the most efficient way to implement a sufficiently fast though highly reliable classification algorithm, well compatible with the EFB data transfer and processing constraints and with the other EFB tasks.

The proposed classification scheme, explained and discussed with reference to some preliminary analysis based on simulated radar environment and on real radar data, is based on a mixture of two methods: the Support Vector Machine (SVM) classifier, exhibiting very good performance in terms of processing times but requiring an accurate preliminary training, and the fuzzy logic approach, widely used in the ground weather radar community thanks to its recognized accuracy, but rather slower.

The optimal solution found, based on a preliminary accurate off-line training of the SVM using output of fuzzy-logic-based classificatory, was proven by data collected by the dual-polarization radar Polar 55C to be quite effective and consistent with the microphysics of precipitation.

Input to the WRPP module on board EFB has been defined by the matrices of radar measurements provided by the WRP (see Figure 5 for an example of polarimetric parameters), the height of melting 0° isothermal (a scalar) and three matrices, of the same dimension of those of radar measurements with geolocation information (Lat, Lon, Height) of radar measurements (see table I for the set of input parameters).

Fig. 5 - Example of polarimetric observables that are measurable during a cruise phase at 6000 m. From left to right: Horizontal Reflectivity, Differential reflectivity, Differential phase and correlation coefficient.

The method for hydrometeor classification to be implemented in the EFB was chosen based on the most efficient way to implement a sufficiently fast though highly reliable classification algorithm, well compatible with the EFB data transfer and processing constraints and with the other EFB tasks. The selected scheme is based on a mixture of two methods: the Support Vector Machine (SVM) classifier that has very good performance in terms of processing times and the fuzzy logic approach, widely used in the ground weather radar community, thanks to its recognized accuracy, but rather slower. The time-consuming training phase required by the SVM classifier is not performed during the flight, but is used to configure the EFB off-line.

Variable description; Variable Name; Unit; Coding; bytes
Number of azimth (#); NA; float; 4
Number of range bin (#);NR; float; 4
Reflectivity factor (dBZ); ZH; dBz; array of float; NR×NA×4
Differential reflectivity; ZD; dB; array of float; NR×NA×4
Specific Differential Phase Shift; KD; deg; array of float; NR×NA×4
Co-polar correlation coefficient; RC; -;array of float; NR×NA×4
0° isothermal height; T0; °C; float; 4
Latitude; LA; deg; array of float; NR×NA×4
Longitude;LO; deg; array of float; NR×NA×4
Height; HH; deg; array of float; NR×NA×4
time stamp; TT; -; float

Tab 1: Input of WRPP

The fuzzy logic classifier provides state-of-the-art results for hydrometeor classifications on radar polarimetric measurements, also in operational weather radar systems. The SVM classifier is trained on classification maps generated by a fuzzy classifier.

The further process, i.e. the Risk map performs a rough re-classification of measurements, assigning risks to points in which algorithm detected graupel/hail or rain/hail mixtures. This matrix is provided in binary form (0 or 1) to Q-AI. Table 2 summarizes output of the WRPP.

Variable description; Variable Name; Unit; Coding; bytes
Hydrometeor class; HC: -; array of integer; NR×NA×1
Risk Flag; RK; -; array of float; NR×NA×4

Tab 2: Output of WRPP

For the validation of the SVM performances the analysis is based on the simulation of 38 time radar sequences of two flights during tht cruise phase through the same weather phenomenon at different height, 6000 and 9000 m , respectively. Figure 6 shows an example of SVM-map and of Fuzzy logic map at 6000 m altitude. Figure 7 shows the related risk map as well as it exits from the WRPP for the QAI usage. The overall accuracy of the SVM classifier is provided as percentage and by means of matched true positives among the total amount of measured points for a fixed step with respect to the Fuzzy logic classifier. Table 3 and table 4 report the performance evaluation for the two flights respectively at 6000 m and 9000 m altitude.
The computing time are within a few tenth of seconds. All tests are performed with the C-source code for EFB running on a Quad Core PC Intel-i7@3,40GHz.

Fig. 6 - SVM (left) and Fuzzy Logic (right) map at 6000 m altitude

Fig. 7 - Risk-map related to the SVM map of previous figure

#; classification accuracy (%); True positive rate (#pos/#tot); Classification time (s)

Step 1; 98.63; 14771/14915; 0.257
Step 15; 97.01; 12044/12404; 0.146
Step 30; 95.86; 5997/6256; 0.055
Step 38; 99.46; 749/753; 0.023

Table 3: Performances stated by the SVM (Fuzzy-driven) classifier for KLEAN_Test2_Dataset_6000m

#; classification accuracy (%); True positive rate (#pos/#tot); Classification time (s)

Step 1; 99.91; 15505/15069; 0.115
Step 15; 99.05; 12638/12650; 0.046
Step 30; 99.88; 6250/6257; 0.022
Step 38; 99.06; 750/753; 0.089

Table 4: Performances stated by the SVM (Fuzzy-driven) classifier for KLEAN_Test2_Dataset_9000m

3.4 SW analysis and refinement of the Quasi-Artificial Intelligence (QAI) agent algorithms
The general structure of the Q-AI software is composed by the following modules:

A) Event detection:
- Q-AI checks if environmental changes can affect pre-planned aircraft trajectory

B) Trajectory planning:
- the problem is represented as an aircraft state change graph;
- on the arcs, connecting the node of the graph (aircraft state), CO2, NOx and Noise emissions are evaluated;
- optimization algorithms: Dijkstra, dynamic programming and genetic approach.
C) Trajectory selection:
- several multi-objective optimizations can be selected
- computational time may vary using the different algorithms in different flight phases
- selection of real-time computable trajectory is performed

D) Visualization:
- the QAI software provides a visualization of the results.

From a theoretical point of view, the optimization problem has been modelled as follows: the Aircraft state is a multidimensional vector having 5D state: latitude, longitude, true altitude, speed, heading. The optimization is graph based, and each node of the graph represents an aircraft state. The arcs of the graph represent transitions between two states. The arcs are inserted in the graph taking into account several set of constraints, namely: aircraft and engine constraints (from BADA model), aircraft and pilot manoeuvers constraints, wind field (as, in the state, TAS - True Air Speed - is considered). The arcs’ costs consider the emissions of CO2, NOx and Noise that are produced in each admissible aircraft state transition. Moreover, the weather conditions and the avoided zones are considered, and the No flight zone map, provided by the KLEAN Weather Radar Post Processor, are processed by the arc removal function.

On the populated graph computed as described above, a set of graph based optimization algorithms can be executed. In the current implementations, the algorithms include: Dijkstra, dynamic programming and genetic approach. All the algorithms can be executed considering single-objective optimization (for example CO2 only) or multi-objective optimization. In multi-objective optimization, linear combinations or fuzzy computed combinations of normalized emissions of CO2, NOx and NOISE are considered. Note that Dijkstra and dynamic programming are based on the same principles and, in a huge number of cases, produce the same results.
Moreover, genetic optimization can use global trajectory constraints: limitation of number of speed variation, heading variation, etc.

The general structure of the Q-AI software has been implemented according to the following structure:
- QAI: implements data exchange with the external world, Q-AI event detection and Q-AI decision system.

- trajectory planning thread: the QAI thread can launch and join from one up to three execution threads that compute the aircraft trajectory planning according to different optimization criterion. These threads shall periodically compute their execution time and if it is over a given threshold force the stop of the computation returning a failed value in the suited field of data output.

The main thread of the QAI module manages data input provided from several data source providers: FMS, Weather Forecast provider, NOTAM, METAR. For module testing reason, another data source provider has been implemented, the Risk Zone provider, to simulate what will be the WXPP module of the full KLEAN architecture. The data format for I/O exchange are specified in the I/O Interface description document of the KLEAN project. The QAI thread is launched by the main application thread of the graphical application interface, and if needed it activates further threads to parallelize the executions of the trajectory planning tasks. The QAI thread implements essentially the A) and C) sub-modules of the Q-AI module structure, namely the Event Detection and the Decision phase after joining the trajectory planning threads.
The trajectory planning thread computes an optimized aircraft trajectory using the selected algorithm and criteria.

The event detection sub-module has the task of identifying situations where the QAI trajectory planning thread has to be launched.
The input data are compared with the pre-planned trajectory and in situations where, due to updates received as input, it is seen that the pre-planned trajectory is no longer feasible or no longer optimal, the QAI trajectory planning will be run in order to find and propose to the pilot a feasible and optimal alternative.
A typical example of such a situation is shown in figure 8. A new input (be it from NOTAM, METAR, risk map, weather update …) shows a no-flight zone, described as a polygonal region, that intersects the planned trajectory (shown as dotted line). It is now necessary to find a new route. The QAI trajectory planning will be run in order to find and propose to the pilot one or more feasible and “green” trajectories (with reduced emissions).

Fig. 8 - Sketch of a no flight zone (polygonal area in red), planned trajectory (dot line), new route (green line)

The trajectory planning thread has to solve a problem of path optimization on a graph.
A bottleneck was identified in the fact that, while the run time of optimization algorithms is relatively short, the time needed to construct a graph based on current airplane position is (at the current stage of development of the algorithms) too long to be feasible.
As a solution, we decide to divide the entire trajectory of the airplane in legs, according to the pre-planned flight plan. Each leg can be defined by two consecutive waypoints of the flight plan or according to a given maximum length of each leg. The graphs of each leg covering the region where the flight takes place are pre-computed off board and loaded on the NEXIS EFB. When the trajectory planning thread is launched, the more suitable pre-computed graph that covers the current position of the airplane and the region where it can fly in the following period is loaded.
The weather update and avoided zones management are performed. These tasks require a much shorter time than the construction of the whole graph. The updated graph with current no flight zones considered is then used by one or more optimization algorithms in order to find one or more optimized trajectories in the graph. Figure 9 shows and example of sub-graphs covering a wider flight region

Fig. 9 - First two intersecting sub-graph covering the initial part of the flight plan

This decision module determines, when more than one trajectory are computed in parallel, if the computation is accurate in the time interval selected in the ini file, typically set as less than one minute. If not all the trajectories computed are accurate, this module marks the not accurate trajectory as not valid setting a flag.

For testing purpose a trajectory of an Airbus A320 with 2 V2500 engines has been considered assuming the starting mass of the aircraft is 64000 kg.
A real trajectory originating from Paris/Orly (LFPO) to Nice/Cote d'Azur (LFMN) obtained by Flight Aware website (http://flightaware.com/) has been used: the flight EZY4063 of the 25th February 2014 at about 11.30 UTC. The trajectory and the points reported by Flight Aware are depicted in figure 10.

Fig. 10 - Trajectory of EZY4063 and two no flight zones along the route

Once computed the graphs of the trajectory, these have been loaded on the NEXIS EFB.
In order to test the trajectories computed by the NEXIS EFB, it has been connected via Ethernet to a PC. This PC simulates the FMS of an aircraft and sends to NEXIS the position of the aircraft. The data about the position of the aircraft reported by Flight Aware are used to simulate the FMS.
At time 11:50 (UTC) the position of the aircraft is 46.8449° of latitude, 3.1128 ° of longitude, 11168 feet. The computed true airspeed is 212.2 m/s and heading is 162°. At this time the PC sends also data about two no flight zones.
The Q-AI event detection module verifies that the two zones intersect the pre-planned trajectory (Figure 10) and starts the computation of a new trajectory. The two zones are in the third graph and Q-AI chooses it as graph to be used for trajectory computation. The computed starting point of the new trajectory is: 46.2° latitude, 3.4° longitude, 11168 m altitude, 215 m/s true airspeed and 180° heading. The ending point is the other waypoint of the third graph: 45.2° latitude, 4.2° longitude, 11168 m altitude, 225 m/s true airspeed and 135° heading.
Q-AI computes three trajectories avoiding the two no fly zones: one minimising CO2, one minimising NOx and another minimising a combination of CO2 and NOx (50% CO2 and 50% NOx). The three trajectories are represented in Figure 11.

Fig. 11 - Q-AI trajectories computed by NEXIS EFB

The trajectory that minimises COs is in blue, the one that minimise NOx in green and the one that minimises a combination of the two pollutants is in pink.

3.5 Graphical User Interface (GUI) design and implementation
The requirements that the GUI has to satisfy are the following:

Pilot workload KLEAN EFB should reduce as much as possible the additional workloads created to the pilot.
Procedures to Mitigate and/or Control Workload Procedures should be designed to mitigate and/or control additional workloads created by using an EFB.
Proposed Trajectory Display The proposed trajectory different type of constraints shall be visualized on the display with a dedicated colour and marked with its name in the same colour, for immediate identification. As well the different type of constraints shall be displayed by different shapes, markers and colours that allow their immediate recognition.
Active Trajectory Display The active trajectory shall be visualized on the display along the proposed trajectory. It shall be clearly distinct by the proposed trajectory, employing different line styles and/or colours.
Trajectory update graphics The scenario shall be updated step by step in order to minimize the effort of the pilot in understanding the new information
Best Trajectories Display Optionally, the top best trajectories should be represented on the display. A different transparency shall indicate the grade of performance of the displayed trajectories. The number of the displayed trajectories shall be selectable.
Selection on other optimization criteria Apart from NOx, CO2 and Noise, Q-AI on EFB shall give the possibility to select and add the following optimization criteria:
- fuel consumption

- number of turns

- deviation from the preplanned route
- length of the path

- heading variations at the waypoints
- flight time
Optimization Weights The following weights of optimization variables shall be configurable by the user:
• Emissions of: NOx, CO2, CO, HC
• Flight time
• fuel consumption,
• number of turns
• deviation from the preplanned route
• length of the path
• heading variations at the waypoints 
For each phase of flight, a different set of weights shall be available. 

Best Trajectory Description 
Optionally, the pilot should be able to select each of the best trajectories and see inside a numerical display the value of the variables affecting the performance index. 

Inability to compute the result 
If Q-AI module, once triggered, is unable to find a feasible trajectory among the given constraints, it shall do nothing just as if it wasn’t triggered. 

Interface accessibility, clarity and efficiency 
The pilot should be able to access information remaining at the normal position at the cockpit; the information shall be presented in a graphical way and the interaction shall be possible directly at the device with an intuitive GUI: pilot’s attention shall be alerted by use of colors, shapes and sounds
Information discriminability The pilot shall be able to distinguish information accurately; the active trajectory shall be clearly distinguished from the proposed trajectory, and the associated information like emissions, new event information, etc. shall be indicated. The represented information shall be selectable.
Information conciseness To avoid information overload, the system should only visualize the minimum information useful to the pilot for decision making about trajectory selection.
Information legibility The information presented on the GUI shall be:
- easy to interpret: the way the information is presented shall comply with cockpit language and symbol conventions commonly accepted.
- configurable: specific pieces of information shall be de-selectable from viewing to avoid cluttering.
Controllability If necessary, the pilot shall be allowed to manually select the parameters that will be optimized when calculating the proposed trajectory (e.g. distance, number of waypoints to recalculate, emission index, variables to optimize, etc.); if no manual selection is operated a default shall always be presented.
Conformity The way pilot data are loaded and displayed shall conform to the applicable numeric standards; but the pilot should be able to load his own data configuration.

The GUI implements two main functions: visualization of the data provided by WRPP and QAI and input of user defined configuration parameters.
For visualization purposes, the interface is accessed in read only mode. Once retrieved, information supplied by WRPP and QAI are displayed on the screen. Only few buttons are available on the screen and only fundamental information are displayed: flight parameters, WRPP output, actual and optimized trajectory. Such kind of simple and easy to use visualization is particularly suited for users not completely familiar with the system or during moments with closed attention to critical aspects of airplane operations
Concerning the possibility of interacting with the GUI, pilots are able to insert configuration parameters for the WRPP and the QAI. To be able to interact with such blocks, beyond having the possibility of access in write mode the Internal Database, GUI is directly connected with dedicated bidirectional links and interfaces with WRPP and QAI. The direct connection to the QAI block allows pilots to require user defined trajectories or provide specific decision parameters, such as optimization parameters or optimization criteria. The direct connection to the WRPP block allows pilots to define post processor parameters such as thresholds, required accuracy, achievable range.

The GUI has been designed to interact with pilots for system control. The proposed touch screen GUI is easy to use and friendly. The graphical and numerical representation of the information on screen is designed in order to limit end users perceptual and cognitive workload, and to avoid the potential to misinterpret indicators. Moreover, the selection of appropriate colours in this specific context has been evaluated to reduce the discrimination workload and to create a motivational effect.
Figures 12, 13 and 14 show some of the KLEAN GUI graphical windows on the EFB NEXIS

Fig. 12 - GUI KLEAN Project Windows (different map style)

Fig. 13 - GUI Menu Window – Activation of the WRPP function (Risk Map) and Classification map

Fig. 14 - GUI Menu Window –WAYPOINTS and NOTAM/METAR Visualization

3.6 I/O interfaces

The I/O data providers are from typical external instruments and equipment available on board of an aircraft. The main data sources available on the aircraft and that provide valuable information to the KLEAN software are:

- Flight Management System (FMS);
- Weather Radar Processor (WRP);
- NOTAM data;
- METAR data;
- Weather forecasts update;
- New trajectory received from ATC.
- No flight zones

In our KLEAN architecture implementation, we have considered two main Ethernet based inputs.
The KLEAN software implements two different sockets, one devoted to the processing of WXP incoming data, the other devoted to the processing of all the other data, in particular the FMS data.

The communication is actuated using simple messages delivered using UDP sockets. The message format of the message is the same for all types of messages, and it consists of two chunks of data divided as follows:

a) HEADER, composed by the following fields:
a.1) TYPE field;
a.2) TS field.

The TYPE field is a numeric type consisting of a single unsigned integer value coded inside a single byte. Regular TYPE values are integer in the range from 1 to 127. The type 0 is a debug value, and values from 128 to 255 are invalid.
The TS (time-stamp) field is a sequence of 20 bytes that contains a string with the format derived from ISO-8601. The TS string is formed as follows:
“YYYY-MM-DDThh:mm:ssZ”
An example of valid time-stamp for the first second of next new year UTC time: “2015-01-01T00:00:01Z”

b) The CONTENT field is a sequence of bytes that contains all the data required for a message of type TYPE. The CONTENT field is of variable dimension and are defined according to the type of data to be transferred.

All the fields are coded in little endian.

3.7 KLEAN system test and assessment
A validation plan for the KLEAN project has been proposed to validate specific functionalities of each macro element and the general functionalities of the whole KLEAN tool. The general KLEAN tool functionalities have been tested on past true flights in cruise modality. The general validation plan gas been summarized with the following five cases:
C1 The preloaded route is the shortest and the weather forecast is good weather. During the flight no dangerous weather event is detected. It is expected that the WRPP produces negative risk maps, the Q-AI does not offer a different route, the GUI does not show both new routes and risk maps
C2. The preloaded route is the shortest and the weather forecast is good weather. During the flight a dangerous weather event is detected. It is expected that the WRPP produces a positive risk map, the Q-AI offers a new longer route, the GUI show new routes and the risk maps.
C3. The preloaded route is not the shortest because the weather forecast is bad weather. During the flight no dangerous weather event is detected. It is expected that the WRPP produces a negative risk map, the Q-AI offers new shorter routes, the GUI shows new routes and no risk maps
C4 The preloaded route is not the shortest because the weather forecast is bad weather. During the flight the dangerous weather event is detected as forecasted. It is expected that the WRPP produce positive risk maps, the Q-AI does not offer different route, the GUI shows the risk map
C5. the preloaded route is not the shortest because the weather forecast is bad weather. During the flight the dangerous weather event is detected but much greater than the forecasted one. It is expected that the WRPP produce positive large risk maps, the Q-AI does not offer different route because it cannot give any other route, GUI shows the large risk map and the warning about no alternative routes.

Fig. 15 - Radar coverage area in red, bad weather center (yellow star), F1 flight route, gray
During the KLEAN project the first two cases of the validation plane have been tested. In order to simulate the presence of hazardous weather along the route a simulated set of radar measurements have been computed off-line for the whole flight trajectory Figure 15 shows the area interested by the radar observation during the test flight Paris Nice and the position of the dangerous weather event for the C2 case.
An external software tool for generating the input data required to the EFB has been implemented. A data flow simulating the FMS output and the polarimetric radar output is generated off-line and send to the EFB through the Ethernet connections.
Figure 16 shows the snapshot of the EFB screen after the risk detection by the WRPP and the following Q-AI results (i.e. new route and) after its activation. On EFB screen the following main elements are shown:
• the state of the flight on one of the geographic views and the related text (lat, lon, alt, speed, heading) below the map;
• the preloaded flight plan (green line);
• the legend with the weather classes defined by the WRPP (top right);
• The classified radar map (in this case a groupel area in front of the plane) that generates the event “bad weather” and the related no flight zone for the Q-AI;
• The new route (black line) as computed by the Q-AI that allows to avoid the no flight zone minimizing the emissions.
• The text summarizing the optimization emission in terms of reduction of CO2 and NOx.

Fig. 16 - Snapshot of the EFB screen

Potential Impact:
4.1 Expected impact

The aim of the CleanSky system for Green Operations ITD, and specifically the Management of Trajectory and Mission (MTM) work package, is to demonstrate that the mitigation of external noise generated by the aircraft and the reduction of emissions (main environmental goals of ACARE, the European Technology Platform for Aeronautics and Air Transport) can be supported by the prediction of the new Green trajectory development.
The KLEAN system is the practical application of the trajectory optimizer on the EFB platform. KLEAN is the system that realistically allows quantifying how much the new functionalities implemented in the EFB through the weather post-processor and the QAI agent algorithm can impact in the mission/flight in terms of fuel consumption and noise pollution.

Test with pilots will provide the practical choices of the optimized solutions during simulation trials that will be used to evaluate the consumption reduction, the overall emissions and the noise pollution. Moreover, the behaviour of the pilot with the KLEAN decision aid in presence of hazard weather phenomena will be also experimented using the EFB, customized with the KLEAN tool, together to the state of the art of present flight simulators.

Dissemination and exploitation of project results, and management of intellectual properties

The dissemination of the project results has been carried out in two different ways:

- Internal dissemination: the dissemination among the consortium partners has been done through the organization of internal meeting operated by audio or video conferences or held directly in the main sites of participants. Internal reports facilitated the divulgation of technical results among the project consortium staff.

- External dissemination: External dissemination has been carried out in three different ways.

a) project web site (www.klean.cnit.it)
b) Four open workshops addressed for the Cleansky community
c) Participation to international scientific conferences

4.2 Exploitation of the project

The results of the KLEAN project provide useful benefits to existing correlated EU projects such as FP6 FLYSAFE (on flight safety), FP7 ALICIA (on operative conditions) SESAR (on overall air traffic optimization), SANDRA (on next generation of air-to-ground telecommunication systems) and CLEANSKY (on air traffic optimization to reduce emissions and noise pollution).
Specifically, KLEAN represents in this context a new tool for pilot decision support that will have impact for other flight key factors than green trajectory, like flight safety (the optimized trajectories must continue the avoidance of hazard situations), wider view and characterization of weather phenomena trough new and ad hoc GUIs.

4.3 Management of intellectual property rights

The CNIT participation will agree, before project start, on rules defining the access rights to the Intellectual Property Rights (IPR) on the Knowledge and on the pre-existing know-how, for the purpose of the achievement of the project on one side, and for further exploitation of those results on the other side.

4.4 Contribution to European Competitiveness

The results of the KLEAN project are considered as a powerful tool for the airplane of the future. Moreover, assessment and validation of the KLEAN system with Mission/flight simulator will be a proved test of the benefits that can be derived by the use of KLEAN.
European dissemination throughout the Europe also allows stakeholders to have a clear idea of the project and transfer it to the air transport community, with a right level of new know how.
All these aspects are in the direction of providing significant gain in Europe, both individually and collectively, to have a tangible impact for return of investment on Europe.

List of Websites:
Address of project public website:

http://klean.cnit.it

Relevant contact details:

Person Role Email

Fabrizio Berizzi Primary Project co-ordinator f.berizzi@iet.unipi.it
Fabrizio Cuccoli Scientific co-ordinator fabrizio.cuccoli@cnit.it
Paola Magri Administrative co-ordinator paola.magri@cnit.it
Walter Ukovic WP leader ukovich@units.it
Luca Facheris WP leader luca.facheris@unifi.it
Vito Pascazio WP leader vito.pascazio@uniparthenope.it
Enzo Dalle Mese WP leader enzo.dallemese@cnit.it