A model toolbox facility to evaluateinnovative solutions for a cleaner

airportL. Basora∗ S. Aubry M. Brunet T. Chaboud

T. Riviere

Onera Centre Midi-Pyrenees,2, Av. Edouard Belin,

BP 4025 - 31055 Toulouse Cedex 4France

23 October 2008

Abstract

IESTA (Infrastructure for evaluating air transport systems) is a global eval-uation facility for air transport systems that is currently being developed atOnera. The project aims to build a generic simulation platform, designed toease the integration of new or existing models in order to assess new air trans-port concepts. This paper describes the model toolbox capability developedwithin the context of Clean Airport, the first IESTA application. Clean Air-port will allow the assessment of the effect of innovative concepts on air trafficnoise and chemical pollution on airports’ surroundings. Starting from a set ofexisting models, an effective modelling capability has been built and achievedby integrating Onera’s expertise in physical modelling. The simulation envi-ronment is based on the fast-time paradigm, and so time constraints on themodels are strict. Building such a platform means enabling the interoperabil-ity of a wide range of models, so a different integration approach is necessarydepending on the model. This paper overviews the approach followed and theresulting model toolbox architecture.

∗luis.basora@onera.fr, tel: +33 (0)5 6225 2699, fax: +33 (0)5 6225 2593

1

Keywords: air transport systems, air traffic simulation, air traffic noisemodelling, air traffic pollution modelling

1 IntroductionThe worldwide air transport system is confronted with unprecedented environmen-tal constraints, capacity demand and rising fuel cost. Programs like Clean Sky JTI,one of the largest European research projects ever, give an idea of the magnitudeand complexity of the challenges to be faced in the future.

As new technologies and operational concepts are developed, a systems engi-neering approach is imperative to evaluate candidate solutions accurately prior totheir implementation. The complexity of the air transport system makes it nec-essary to perform conceptual trading evaluations covering many criteria and met-rics. While a myriad of simulation tools exist, the vast majority are designed forstand-alone operation and to meet specific needs rather than to conduct analyses ofsystem-wide performance.

IESTA, a project being developed at Onera, aims to develop a generic simu-lation infrastructure and an extensible toolbox of models in order to provide theaeronautical community with advances in modelling and simulation tools througha global evaluation facility. The model toolbox capability is built incrementally byimprovements to existing models as well as development of new ones, thus provid-ing incentive for Onera and research partners’ investment into the platform.

The initial effort concentrates on the development and the validation of a toolboxof compatible models to conduct high-fidelity assessments of concepts and tech-nologies in order to mitigate the noise and air pollution impact of air traffic aroundan airport. In parallel, another team is working on the development of a fast-timesimulation framework together with scenario generation and simulation manage-ment utilities, databases and post-processing tools. The set of environmental mod-els integrated into this platform will form the core of the first IESTA application:Clean Airport.

This paper is organised as follows. First, the high-level requirements for thesimulation, modelling facility and Clean Airport are presented. Following that, ashort introduction is given on the problem of combining existing models with onesspecifically developed for the platform. A presentation of the resulting architecturefor the Clean Airport model toolbox is then described, firstly from a global point ofview then through a more detailed description of each model.

2

2 RequirementsThis section introduces the main high-level requirements that have driven the designof the simulation platform, the modelling toolbox capability and the Clean Airportapplication.

In order to evaluate the effects of a large range of operational concepts and tech-nologies at a system-wide level, the simulation platform architecture must provide:

• an open and flexible simulation environment that can be tailored to specificuser needs;

• an extensible simulation framework to provide different levels of complexityand fidelity;

• a fast-time simulation framework;

• standardised interfaces to ease the integration of new or enhanced models andlegacy simulations;

• a set of tools and utilities to manage the simulation configurations, runs, stud-ies, scenarios and results;

• data collection facilities to ease integration of external aeronautical informa-tion.

This simulation platform architecture relies on a model toolbox facility requir-ing:

• models that are able to compute the necessary data to support the evaluations;

• models that are conformed to the standardised architectural interfaces, sup-porting a ”plug-and-play” paradigm;

• models of selectable level of fidelity to meet specific assessment needs.

As for Clean Airport, from an assessment point of view, it must enable evalu-ation of the effects of proposed operational concepts and technologies intended toreduce the impact of noise and chemical pollution of air traffic in an airport. It mustespecially support evaluations of the effects of:

• modifications of the daily flight scheduling;

• changes in the composition (population) of the aircraft fleet flying;

• introduction of innovative aircraft concepts (for example new airframe con-figurations and propulsion technologies);

3

• using new terminal procedures, (for example concepts like Continuous De-scent Approach (CDA)1).

Unlike the common commercial off-the-shelf products, such as the FAA Inte-grated Noise Model (INM) [5] and the Emissions and Dispersion Modelling System(EDMS) [6], IESTA aims to provide an integrated platform based on physical mod-els. These models and the quality of the results obtained will nonetheless dependon the quality of the data given as inputs.

3 Models to be integratedAs the IESTA platform aims to integrate some existing Onera models and new onesbeing currently developed, satisfying the previously presented constraints, a differ-ent integration approach must be applied to these various models.

The existing physical models are the followings:

• CEDRE [10] an Onera Computational Fluid Dynamics (CFD) numerical codeable to simulate turbulent combustion and multi-physics phenomena (see sec-tion 5.7);

• CESAR [9] an Onera numerical code able to compute the aircraft noise instal-lation effects, i.e. diffraction, refraction and reflection (see section 5.3);

• SIMOUN [11] an Onera numerical code able to compute the propagation ofacoustic rays (see section 5.3).

In order to integrate all these physical models, several new models need to bedeveloped from scratch:

• an aircraft ground traffic model to compute ground trajectories;

• an air traffic model to compute air trajectories;

• a weather forecast model to take weather conditions into account:

• an aircraft engine model to compute engine data such as fuel consumption,gas emission, etc;

Also, as CESAR and SIMOUN work only for one aircraft, one needs to developan aggregation model to compute, from single ones, the global air traffic noise foot-print.

1CDA involves the continuous, gradual descent of aircraft on a constant slope while idling with-out deployment of flaps and landing gear, thus reducing airframe noise and fuel consumption.

4

As some of the existing models are time-consuming at runtime, which is notcompatible with the fast-time constraint, they will have to be divided into severalparts in order to compute data which do not depend on the simulation performed ata pre-processing time or to compute results depending on a high number of data ata post-processing time.

4 Architecture overviewThe architecture of the platform issued from the integration constraints previouslydescribed is presented here.

To support the platform requirements, the IESTA simulation facility is based ona distributed simulation approach, called High Level Architecture (HLA) [2]. HLAprovides a blueprint for the assembly of existing simulations and offers guidelinesto create future simulations with interoperability in mind. Individual simulations,called federates in HLA terminology, are integrated using the HLA Run-Time In-frastructure (RTI), an interface providing the common set of services required by adistributed simulation system. The integrated set of simulations is called a federa-tion.

In addition to the HLA-based simulation framework, IESTA includes a numberof utilities to monitor and manage the simulation configurations and runs, to preparethe scenarios and to analyse the results. While these are all critical components ofthe infrastructure, the paper will only focus on the model toolbox architecture forClean Airport.

An overview of the resulting model toolbox architecture is depicted in figure 1,including the main two sub-systems interacting with it.

At its lowest level, the architecture contains a data layer providing data persis-tence services through an object-oriented API. As the physical models require hugeamounts of data to work, the data layer is a key component of the architecture.Three databases exist in IESTA:

• ScenarioDB is a relational database containing the aircraft and engine mod-els, the flight plans and associated aeronautical information (procedures, way-points...), etc. This data is stored by the scenario generation tool and can beaccessed by the the federation to provide the models with the necessary sce-nario input parameters.

• TechnoDB is a set of files either provided by external organisations, such asthe Eurocontrol BADA [1] aircraft performance data, or generated by the pre-processing models. This database can be directly accessed by the models.

5

HLA SimulationPreprocessing Postprocessing

Models toolbox

Federation and platform Tools

Data LayerFile Interface SQL Interface

Air Traffic Simulation

CESAR

Ground Traffic Planning

Aircraft Engine Thermo

SIMOUN

Ground Traffic Simulation

Weather

Cartonoise

Aircraft Engine Emissions CEDRE

Cartometer

Air Traffic

Environment

Chemistry

Acoustics

Figure 1: The IESTA-Clean Airport Architecture

• ResultsDB is a set of files storing the output data for the models operating atsimulation or post-processing time, e.g. aircraft trajectories, noise and chemi-cal emissions, noise footprint grids, concentration of pollutants on the ground,etc. This is the data that a final user is interested in for further analysis. Thefiles can be generated by the models themselves, or more often, by the feder-ates.

Above this layer, the model toolbox facility is represented, with componentsclassified according to their execution phase and the domain they belong to. Therole of each model is as follows:

• AirTrafficSimulation is a simulation model computing the 4D trajectories andother flight parameters for the given scenario flight plans. The model is basedon Eurocontrol BADA [1], an aircraft performance database implementing atotal energy model.

6

• GroundTrafficPlanning operates at pre-processing and simulation time. Atpre-processing, it computes, given an airport graph, a set of preferred groundpaths for each pair of gate-runway referenced by a flight plan. At simulationtime, it provides the arriving and departing aircraft with a free-conflict groundpath.

• GroundTrafficSimulation computes at simulation time the ground trajectoriesfor the given ground paths from the threshold of the runway to the gate andvice-versa.

• AircraftEngineThermo is a numerical code to compute at pre-processing thethermodynamic parameters of an engine model.

• AircraftEngineEmissions computes at simulation time the exhaust emissionsas well as other engine state parameters, such as the jet Mach number andtemperature. It uses the engine thermodynamic parameters and several emis-sion databases, such as the ICAO Engine Exhaust Emissions Data Bank [3].

• CEDRE is a post-processing numerical code computing the atmospheric dis-persion of the exhaust emissions computed by the AircraftEngineEmissions.

• CESAR is a numerical code to compute at pre-processing the aircraft noiseinstallation effects, i.e. diffraction, refraction and reflection.

• SIMOUN is a numerical code to compute at pre-processing the propagationof acoustic rays from the aircraft to the ground.

• Cartonoise computes the noise footprint for the air traffic at a given simula-tion time. This model uses the data generated by CESAR and SIMOUN tocompute the footprint for a single aircraft and then integrates every footprintcomputed.

• Cartometer is a post-processing model that computes several acoustic met-rics such as LAeq or Lden by integrating the noise footprints generated byCartonoise.

• Weather provides the simulation time models with the meteorological con-ditions at a given 4D position. This model is based on data provided by theMeteo-France ALADIN model 2.

Finally, the top layer of the architecture represents the clients of the toolboxfacility: the HLA federation, for the simulation time models, and the simulationmanagement tool, for some of the pre-processing and post-processing ones.

2See http://www.cnrm.meteo.fr/aladin/ for more information about ALADIN.

7

The communication between the federation and the models is done through de-fined interfaces. All the domain logic is encapsulated in the models, the federatesneeding to compute simulation data by calling the appropriate model service. Onthe other hand, the federation may provide interfaces enabling the models to com-municate some events to the platform, for example the AirTrafficSimulation modelmay need to signal to the platform that an aircraft has landed.

It is important to note that the design of the model toolbox components does notdepend on the particular architecture of the federation, which is not even consideredin the paper. This is of paramount importance from a development point of view: itmeans that once the model interfaces and the performance requirements are speci-fied, the development of the models and the federation can be done independently.In that sense, the approach followed has been component-based.

5 Model toolboxIn the previous section, we offered a high-level view of the model toolbox architec-ture and the sub-systems interacting with it. This section will provide some insighton the role and functionality of each model.

5.1 Air Traffic SimulationThe AirTrafficSimulation is a 4D trajectory generation model based on BADA [1], atotal energy model. Although some of the computation is done supposing a standardatmosphere (ISA), the model is able to use air pressure, temperature, and wind speedand direction provided by the platform through the Weather model.

In addition to the trajectory, several other flight parameters, such as the Eulerangles, the engine thrust or the aerodynamic configuration are computed to feedto the models Cartonoise and AircraftEngineEmissions. The Euler angles and theengine thrust are computed by using a parabolic polar with linear lift coefficient andthe classic aircraft flight mechanic equations.

When the simulation starts, the federate provides this model it encapsulates withthe list of the scenario flight plans. A flight plan contains the usual parameters, in-cluding a reference to the aircraft and a list of orders encoding most of the manoeu-vres found in the AIP3 procedures.

At each simulation step, several services from the AirTrafficSimulation interfaceare requested by the federate in order to execute the following algorithm:

Note that the taxiing, the accelerating along the runway to takeoff and the decel-erating along the runway after landing are all aircraft movements managed by the

3Aeronautical Information Publication

8

Activate new aircraft transferred by the GroundTrafficSimulation modelActivate inactive aircraft not managed by the GroundTrafficSimulation model with departure timeinferior to simulation timefor each active aircraft do

Compute the new position taking into account the previous one and using the BADA perfor-mances table.Knowing the previous state vector and the new position, compute the Euler angles and theengine thrustif aircraft initiates descend then

Signal to the federate the eventend if

end forInactivate aircraft to be transferred to the GroundTrafficSimulation modelInactivate aircraft which have reached their destination and are not managed by the GroundTraf-ficSimulation modelSignal to the federate the new inactive aircraft

GroundTrafficSimulation model and not by AirTrafficSimulation.Concerning the events, AirTrafficSimulation signals to the federate when an air-

craft is to be transferred to the GroundTrafficSimulation. Also, the federate is in-formed when an aircraft initiates the descent phase so that it can be provided by theGroundTrafficPlanning model with a ground path.

5.2 Ground Traffic SimulationThe Ground Traffic Simulation functionality is provided by the GroundTrafficPlan-ning and GroundTrafficSimulation models.

The GroundTrafficPlanning model operates both at pre-processing and simula-tion time. At pre-processing, it computes a set of ground plans for each gate-runwaypair referenced by a flight plan, by using the MPS and Floyd-Warshall graph algo-rithms [8, 7]. To this end, the algorithm needs as input a graph representing thelayout of the airport and the scenario flight plans. Since the gates and the runwaysare nodes of the graph, the algorithm can compute a set of ground paths for eachgiven gate-runway pair by applying variations to the shortest path of the pair in thegraph.

A ground plan is defined by a list of waypoints, each waypoint being associatedwith a temporal window and a speed control parameter. Both the airport graph andthe generated ground plans are stored in the TechnoDB.

At simulation time, GroundTrafficPlanning is first initialised by the federatewith the necessary data, including the airport graph and the generated ground paths.Then, the federate requests the model every time it is informed by the AirTraffic-

9

Simulation that an aircraft initiates the descent phase, or by the GroundTrafficSim-ulation, that an aircraft is due to push-back. These requests are stored by the modeland, at each simulation step, the federate asks the model to provide the pendingrequests with the ground paths. GroundTrafficPlanning uses a depth-first searchbased algorithm to find a conflict-free ground path for each demand.

The GroundTrafficSimulation model computes the trajectories for the aircrafton the ground by executing the ground plans provided by the GroundTrafficPlan-ning. The model is responsible for all the movements of the aircraft on the ground,including the taxiing and the acceleration or deceleration along the runway to takeoff or to land. At each simulation step, the federate thus requests the model to com-pute the next position and the other state parameters for the active aircraft on theground. Concerning the processing of transfer events, the behaviour of the model issymmetrical to the one of the AirTrafficSimulation.

5.3 Aircraft noise emissionTo compute the acoustic field emitted by an aircraft, it is necessary to compute boththe noise source levels and the propagation of these sources nearby the aircraft.While the former computation depends on simulation parameters such as the currentjet Mach number, the latter can be done at pre-processing time, by calculating thelocal propagation coefficients which depend only on the geometrical characteristicsof the aircraft model and are independent of the sources’ levels.

The whole computation was performed originally by a single existing Oneramodel called CESAR [9]. For performance issues, CESAR has been split into twodifferent models: CESAR itself, running at pre-processing time to compute the localpropagation coefficients, and CESAR-S, an internal Cartonoise component operat-ing at simulation time to compute the source levels.

Thus, whenever a new aircraft model is included in the platform, CESAR isrequested to compute the propagation of the acoustic field nearby the aircraft, tak-ing into account the installation noise effects. The calculation of the total soundpressure field including the direct, reflected and diffracted fields is based on a geo-metrical method. The problem of diffraction is performed within the framework ofthe uniform Geometrical Theory of Diffraction (uniform GTD).

The overall pre-processing generates a significant amount of data in the Techn-oDB and is computationally expensive, as the propagation coefficients for an aircrafthave to be computed for different frequencies, aerodynamic configurations and lo-cations on a sphere surrounding the aircraft.

Once this data has been generated, the rest of the process takes place at simula-tion time. At each simulation time step, the Cartonoise model is requested by the

10

federate to compute the noise footprint for the traffic taking part into simulation.The noise footprint for each individual aircraft is computed by ACOU-S, anotherinternal Cartonoise component. As part of this calculation, ACOU-S asks CESAR-Sto compute the noise source levels arising from the main noise components of theaircraft, e.g. jet Mach number, high-lift devices and landing gear. CESAR-S allowsfor fast-time computation, as it is based on semi-empirical and analytical modelsrequiring a limited number of variables. Finally, the data preprocessed by CESARand the sources levels computed by CESAR-S are used by ACOU-S to compute theacoustic field emitted by an aircraft. ACOU-S corrects the frequency spectrum inthe source to take into account the Doppler effect resulting from the aircraft motion.

5.4 Noise propagationThe noise propagation computation follows a similar approach to the one used tocompute the noise emission, i.e. a set of preprocessed propagation coefficients aregenerated in the TechnoDB to accelerate the calculation of noise levels at simula-tion time. However, this time the noise levels are computed on the ground and thepreprocessed coefficients represent the atmospheric effects on the acoustic fieldsemitted by the aircraft.

The preprocessed data is generated by the SIMOUN model [11], an existing On-era model originally designed to compute the long range propagation of the sonicboom from the Concorde. SIMOUN is based on a standard geometrical acousticmodel, where the acoustical energy propagates along rays impacted by wind pro-files and temperature gradients. The propagation model provides the attenuationcoefficients for the acoustic power spectrum originating from the noise source. Theatmospheric attenuation is taken into account as well as the geometrical attenuationdue to the divergence of ray tubes along paths. The atmospheric parameters areprovided by the Meteo-France ALADIN model and shared with the Weather model.SIMOUN has to be run again when a new weather scenario is included in the plat-form.

At each simulation time step, Cartonoise is called to compute the traffic noisefootprint on the ground. This is done by integrating the individual noise footprintscomputed by the ACOU-S component for each aircraft of the simulated traffic. Tothis end, ACOU-S computes the acoustic field emitted by the aircraft and usesthe preprocessed data generated by SIMOUN to obtain the noise footprint on theground. An ACOU-S produced footprint for a given frequency is depicted in fig-ure 2.

The generated footprints are further processed by Cartonoise to produce a gridstructure at each simulation step representing a map of the traffic noise on theground (see figure 3). Please refer to [4] for further details on the operation ofCartonoise.

11

Figure 2: Noise footprint for one aircraft and one frequency

Footprint ofaircraft

A1

Ai

Aj

AN

A1

Figure 3: Integrated noise grid on the ground computed by Cartonoise

Even though the integration of the models is not finished yet, figure 4 illustratessome examples of results which could be produced by the noise emission and prop-agation models, whereas figure 5 shows some preliminary acoustic results producedby the models integrated in a IESTA-Clean Airport prototype [4].

5.5 Noise metricsResultsDB stores the data generated during simulation, such as the aircraft trajecto-ries or the noise grids. Cartometer exploits this data to compute some of the mostusual noise metrics like LAeq, Lnight or Lden at post-processing time. The computedmetrics can then be used by analysis and statistical tools to display noise contourmaps or to combine noise metrics with geographical information, e.g. to evaluate

12

Figure 4: Examples of acoustic results to be produced by the platform IESTA

the noise impact on population and sensitive buildings (hospitals, schools...).

5.6 Engine emissionsThe design of the models calculating the engine emissions is also based on theapproach presented in section 3. Originally, a numeric code was available at Onerato compute the thermodynamic characteristics of some engine models. The modelwas not suitable for fast-time, so it has been modified to generate the necessary datainto the TechnoDB at pre-processing time. This data is then exploited at simulationtime by a new developed model compatible with the fast-time requirements, as itsoperation is based on data interpolation.

The pre-processing model, AircraftEngineThermo, is to be used when a new en-gine model is included in the platform in order to generate a data set of engine per-formance samples for different thrusts, air pressures and Mach numbers. Generatedperformance data includes specific fuel consumption, outputs, jet Mach number,etc. The data set includes thermodynamic parameters as well, such as the pressureand temperature conditions for the engine internal components.

The generated data is used at simulation time by the AircraftEngineEmissionmodel to provide CESAR-S with the needed parameters to compute the engine noisesource, e.g. jet Mach number. In order to index and interpolate the engine perfor-mance data, it receives the weather conditions (air pressure, temperature) and flightparameters for the aircraft (position, Mach, thrust,...) through the federate.

In addition, AircraftEngineEmission estimates the fuel burn and resulting com-bustion emissions for each aircraft active in the simulation. The model is based onthree different certification databases provided by external agencies: ICAO EngineExhaust Emissions Data Bank [3] (turbofans), Swedish Defence Research Agency(turboprops) and Federal Office of Civil Aviation (Swiss confederation) (pistons).At each simulation time step and for each aircraft engine, AircraftEngineEmission

13

Figure 5: Example of a noise impact grid of air traffic at the Toulouse-Blagnacairport

is called to compute the ejection speed, jet temperature and flow rate for the fol-lowing emission pollutants: CO, CO2, NOx, HC, SOx, soot. This output, storedin ResultsDB, represents a time history of flow rate for these emission species.The dispersion model uses the data points of these engine trajectories as emissionsources.

5.7 Chemical species dispersionTo evaluate the impact of the emissions on the air quality, it is necessary to modelthe atmospheric dispersion and the reaction of the aircraft exhaust species. This willbe achieved by adapting CEDRE, an Onera Computational Fluid Dynamics (CFD)numerical code able to simulate turbulent combustion and multi-physics phenom-ena. The code has been used in the AIRPUR project [12] to simulate the pollutantflow characteristics around the airport buildings and the dispersion of emissions (seefigure 6). The suitability of the code for atmospheric dispersion computation has

14

been further validated during the tests performed in IESTA. Currently, the code isbeing adapted to support emissions from mobile sources (aircraft), as the model wasoriginally designed to simulate the dispersion of emissions from stationary sources.

In fact, CEDRE is a tool set including several solvers as well as a set of pre-processor and post-processor utilities requiring particular file formats. The integra-tion of CEDRE in the IESTA platform is progressing in spite of the complexity ofthe tool set and the high computation resources required by the code. The idea is tohave CEDRE operating as a stand-alone process at post-processing time, launchedautomatically by the platform in the end of the simulation.

Figure 6: CEDRE simulation: dispersion of a pollutant around the buildings of theOrly airport

All the inputs required by CEDRE need to be previously stored in files, eitherin the TechnoDB or ResultsDB database, and converted to the required file formatsif necessary. CEDRE accesses these files directly to obtain the following data:

• Engine emission parameters provided by the AircraftEngineEmission model.

• Aircraft trajectories provided by the AirTrafficSimulation and GroundTraffic-Simulation models.

• Meteorological conditions : temperature, pressure, and wind speed and direc-tion

• Atmospheric chemistry: concentration of chemical species in the airport at-mosphere.

15

• 3D Modelling of the airport layout (see figure 7).

• The list of chemical species to simulate.

The meteorological conditions provided by the Meteo-France ALADIN 4 mustbe converted into the required CEDRE format. On the other hand, the concentra-tion of chemical species is produced by the Meteo-France Chemistry and TransportModel (CTM) called MOCAGE 5. Regarding the 3D modelling of the airport, it isimportant to note that the resolution of the mesh representing the airport has a bigimpact on both the performance of the code and the fidelity of the results. There-fore, the mesh has to be carefully defined, increasing the polygon density in theareas of interest. That is because each polygon in the mesh can be considered as apotential source of chemical emission, which is active when at least one aircraft isflying it. Finally, another parameter strongly impacting the model performance isthe number of chemical species to be simulated.

Figure 7: 3D mesh modelling the ground and main buildings of the Orly airport

CEDRE includes a post-processor module to export the results in several exter-nal formats recognised by analytical tools such as TECPLOT 6. The goal is to graph

4see http://www.cnrm.meteo.fr/aladin for more information.5see http://www.cnrm.meteo.fr/gmgec/mocage/mocage.html for more information.6See http://www.amtec.com for more information.

16

the output data and/or to plot the evolution or final concentration of air pollutantson maps.

6 ConclusionsThis paper describes the IESTA platform and the approach used to build a modeltoolbox capability for Clean Airport, the first IESTA application. The aim of theproposed approach is to combine the physical models available at Onera with a setof new or existing fast-time models..

The feasibility of the approach has partially been validated through a prototypeintegrating the acoustic models [4]. Given that the results were satisfactory, thedevelopment and integration of the models on the operational platform is underway,with a first deliverable for Clean Airport due in June 2009. IESTA is a multi-phased,multi-year project, and further development is planned to extend the model toolboxfunctionality by increasing the scope and fidelity of the models. A second IESTAapplication is thus expected to be available by 2011, allowing for evaluations ofconcepts that may impact the whole air transport system.

7 AcknowledgementsIESTA is financed by the French Territorial Collectivities (the Midi-Pyrenees re-gion, the Haute-Garonne department and the Agglomeration community of GreaterToulouse), the French Government and the European Fund for the Regional Devel-opment (FEDER). The authors wish to acknowledge the efforts of the many individ-uals that have contributed to the design and development of the simulation platformand the modelling facility. Specifically, we would like to thank the contributors ofthe Onera Long-Term Design and Systems Integration Department (DPRS), boththe members of the team in Paris developing the simulation infrastructure and thosein Toulouse working on the model toolbox; the members of the Computational FluidDynamics and Aeroacoustics Department (DSNA) providing the numerical codesCESAR, SIMOUN and CEDRE; the members of the Systems Control and FlightDynamics Department (DCSD) developing the ground traffic planning and simu-lation models (in Toulouse) and contributing to the development of the air trafficsimulation model (in Lille); and the members of the Physics, Instrumentation andSensing Department (DMPH) for the contribution to adapt CEDRE to the needs ofIESTA.

17

References[1] Eurocontrol, User Manual for the Base of Aircraft Data (BADA), Revision 3.6,

July 2004.

[2] F. Kuhl, R. Weatherly, J. Dahman, Creating Computer Simulation Systems: AnIntroduction to the High Level Architecture, Prentice Hall, ISBN 0-13-022511-8, 1999

[3] ICAO, ICAO Engine Exhaust Emissions Databank, First Edition 1995, ISBN0-13-022511-8, ICAO, Doc 9646- AN/943

[4] M. Adelantado, A. Oyzel, J.B. Chaudron, T. Riviere, Rapid Prototyping ofIESTA, a Platform to Evaluate Innovative Air Transport Concepts, AIAA Mod-eling and Simulation Technologies Conference, Honolulu, Hawaii, August2008

[5] J.M. Gulding, J.R. Olmstead, G.G. Fleming, Integrated Noise Model (INM)Version 6.0 Users Guide, Department of Transportation, Federal Aviation Ad-ministration, Report No. FAA-AEE-99-03, September 1999.

[6] Federal Aviation Administration Office of Environment and Energy, Emissionsand Dispersion Modeling System(EDMS) Users Manual, Report No. FAA-AEE-07-01, January 2007

[7] R. Floyd, Algorithm 97 : Shortest Path, Report No. FAA-AEE-07-01, In Com-munications of the ACM, no5 (1962)

[8] J-B. Gotteland, Optimisation du trafic au sol sur les grands aeroports, Ph.DThesis, INP, Toulouse (2004)

[9] J. Bulte, Simplified Acoustic Modelling of Aircraft Noise during Take-off andLanding, Onera Technical Report RTI2/F00201DPRS, September 2003.

[10] D. SCHERRER, F. VUILLOT, MSD/MSDH code applications, 1st ONERA-DLR Aerospace Symposium, September 1999. http://cedre.onera.fr

[11] G. Menexiadis, J. Varnier, Long range propagation of the sonic boom fromConcorde airliner: analyses and simulations, Accepted in May 2008 to be pub-lished in AIAA Journal

[12] R. Ramaroson, F. Vuillot & All, Impact of air traffic emissions on airportair quality: Multi-scale modeling, test bed and field measurements, AmericanGeophysical Union, San Francisco, USA, Fall Meeting 2004

18