The CREDOS Project Appendix A of CREDOS D4-3. Data Collection and Data Transfers

Transcription

1 The CREDOS Project Appendix A of CREDOS D4-3 Data Collections and Data Transfers Contract Number: AST5-CT Proposal Number: Project Acronym: Deliverable Title: Delivery Date: Responsible: Nature of Deliverable: Dissemination level: File Id N : CREDOS Data Collection and Data Transfers T9 EUROCONTROL Report Public CREDOS_421_ECTL_DLV_D4-3 Appendix A.doc Status: Approved Version: 1.0 Date: 31 March 2008 Approval Status Document Manager Verification Authority Project Approval ECTL NLR PMC Vincent Treve Lennaert Speijker PMC members WP1 Leader WP4 Leader

2 Table of Contents 1 INTRODUCTION 1 2 CREDOS MEASUREMENT TOOLS AND DATA COLLECTED WAKE AND WIND US LIDAR DLR LIDAR ONERA LIDAR WEATHER DFS WTR/RASS DLR SODAR DFS METAR and weather data AIRCRAFT INFORMATION DFS Radar Data MERGED DATA 7 3 CREDOS AVAILABLE PRE-EXISTING DATABASE WAKE AND WIND KSTL Database WEATHER EDDF NOWVIV Database EDDF Wind Database 10 4 DATA EXPECTATIONS WP 2 DATA ANALYSIS & WV BEHAVIOUR MODELLING: WP 2.1 Data Analysis WP 2.2 Adaptation and validation of the WV prediction models WP 2.3 WAke Vortex ENcounter Detection Algorithm WAVENDA WP 3 RISK MODELLING & RISK ASSESSMENT: WP 3.1 Model development and validation Objectives WP 3.2 Wake vortex encounter safety assessment for departure WP 4 OPERATIONAL CONCEPT & VALIDATION WP 4.1 Operational concept and system requirements WP 4.2 Validation cases development WP 4.3 Real-time simulations 16 5 SUMMARY OF THE DATA EXCHANGES BETWEEN WP1 AND THE OTHERS WP S DATA USER (OTHERS WP S) POINT OF VIEW 17 II

3 5.2 WP1 POINT OF VIEW Data transfer Database Transfer 21 ANNEX 1 ANNEX 2 DESCRIPTION OF THE DATA CHARACTERISTIC REQUIRED FOR WV MODEL IMPROVEMENT 22 DATA NEEDS FOR LES AND REAL-TIME WAKE VORTEX MODELS: US PERSPECTIVE 25 ANNEX 3 CREDOS DATA NEEDS FOR US ACTIVITIES 27 ANNEX 4 CREDOS DATA NEEDS FOR REAL TIME SIMULATION 31 ANNEX 5 LMCT WINDTRACER SYSTEM PERFORMANCE SPECIFICATION 32 ANNEX 6 INSTALLATION, SCENARIOS AND MEASUREMENTS OF DLR EQUIPMENT 33 ANNEX 7 STRUCTURE OF DATA AND DATA FILES DELIVERED BY DLR 39 ANNEX 8 STATUS OF MEASUREMENT CAMPAIGN EDDF2 AT FRANKFURT AIRPORT 46 III

4 1 Introduction The CREDOS project has 3 high level objectives: To evaluate the feasibility of a Concept of Operations allowing reduced separations for Single Runway Departures under crosswind To provide all stakeholders with required information to facilitate the implementation of this concept where appropriate in the near term (pre-2012) To increase the body of knowledge concerning wake vortex behaviour during the initial climb phase of flight. In order to reach these objectives, a significant part of the work will be based on data collected in the various campaigns of WP1. The purpose of this document is to map the expectations of the various CREDOS work packages with what can actually be achieved in the data collection and databasing activities of WP1. Based on this comparison, the present document will propose a dataflow towards the other work packages feeding the various CREDOS activities. Section 2 describes the measurement system deployed for the CREDOS project. Short descriptions of the data that such systems are able to deliver have been provided by the WP1 partners. The aim is to inform other work package partners of the content and limitations of the data collection campaigns in WP1. Section 3 follows a similar approach, presenting the available databases in order to let the other work packages partners identify the use they can make of the available data. Section 4 summarizes the various CREDOS tasks that could (potentially) require data from WP1. The descriptions of these tasks are based on partner contributions or on work package management plans. In addition to these descriptions, when data requirements have been identified and provided by the relevant partner, these are also described. The information provided in Sections 2 and 3 has led to iterations with WP1, which have allowed the partners to identify more accurately the data they require for feeding their own activities. Based on the information provided by Sections 2, 3 and 4 and discussions between WP1 and CREDOS data users, Section 5 presents the foreseen data dissemination amongst the various work packages and sub work packages together with a planning of the data deliveries. This planning could be nevertheless revised by future WP1 Management Plan. 1

5 2 CREDOS measurement tools and data collected The CREDOS data will be mainly collected by research measurement tools deployed specially for the project or from systems already installed on the airport since a certain time. In addition to these research tools, operational data available at airport such RADAR data, METAR, anemometer measurements, will also provide relevant information for the project. This section describes the data expected from each of the previously voiced sources. The type of data (wake, wind, turbulence, traffic ) and the quantity of data are briefly described. An overview of the system deployments is also provided. This overview presents the tools capabilities, their locations, the measurement areas, the periods of measurement and the data acquisition procedures... The purpose of this high level description is to draw a complete summary of what are the feasible measurements following work packages can count on. 2.1 Wake and Wind US LIDAR The Lockheed Martin Coherent Technology (LMCT) lends by the FAA to EUROCONTROL will be operated by Volpe. The system will be deployed south the runway 25L in order to monitor the departures from the runway 25R. The departures from the 25L, within the first 400 meters blind area of the LIDAR system will not be considered. Following the results of the heavy rotation point survey, a region of interest has been defined for the heavy wake vortex measurements NGE and IGE (Figure 1). The LIDAR scanning planes will be defined in order to cover as much as possible this departure area. Of course due to their earlier rotation potions and due to their higher climb rates, the medium aircraft will be at higher altitude (NGE or OGE WV generation) when crossing the measurements planes. Figure 1 : This figure shows the definition of the area of interest. The area is bounded by the desire to be at least 2600 meters down the runway, but no more than 3200 meters and the need to be 900 meters from the centerline. This defines an area near the general aviation ramp. The picture in the image is a few years old and does not show the new Lufthansa Technik hangar which fills in a large portion of the desired area. 2

6 The system will be colleting data only for west wind operation from January 2007 for at least 6 months and will deliver wake vortex trajectories and strength decay data files. The accuracy of the measurements and further technical information on the LMCT system can be found in the Annex DLR LIDAR The DLR 2 µm pulsed Lockheed Martin Coherent Technology (LMCT) lidar will be located close to the da Vinci house in the south-east edge of the terminal area (see Figure 2). The lidar will perform vertical scans in three different planes. One plane is oriented perpendicular to the flight path; the other planes employ viewing directions shifted by 33.5 deg (the plane used in the WakeFra 2004 campaign) and 55 deg. The measurement phase starts in the beginning of December 06 and will end in February For landings on 25L/R the DLR lidar be used as part of the wake-vortex prediction and monitoring system (WVPMS) developed within the Projekt Wirbelschleppe of DLR. For that purpose it will mainly monitor wake transport in the three measurement planes in order to confirm the wake-vortex prediction system. The emphasis is put on the determination of vortex ages at which the vortices have cleared a safety corridor around the glide paths. For departures on runway 07L the lidar is used for vortex characterization needed in CREDOS. For this purpose the lidar scans perpendicular to flight direction and collects vortices generated at a nominal altitude of 170 m. This generation height assumes a rotation point after 3000 m and a climb angle of 7 deg. Since these values vary in broad bands, we can expect also near ground effect (NGE) cases. For the evaluation of wake-vortex properties, an interactive four-stage data processing algorithm is applied. First profiles of vortex tangential velocities are estimated from which vortex positions and circulations are derived. The error for vortex core position was determined to about 4.5 m in the vertical and 6.5 m in the horizontal direction and for circulation to 13 m²/s. Eddy dissipation rate can be determined from the second order structure function based on 5 min averages and a vertical resolution of 5 m. For more details about data formats see Annex 6 and Annex three LIDAR viewing angles aircraft glide paths (3 for arrivals, 7 for departures, rotation point after 3000 m) x ac = 0.27 NM z ac = 61 m r 900 m ε = 4 X Rot. Point for Heavies 500 m 1400 m 07 L x ac = 0.35 / 0.75 NM z ac = 34 / 172 m r = 892 m ε = 2 / 12 x ac = 0.67 / 1.05 NM z ac = 61 / 239 m r = 1070 m ε = 3.3 / m x ac = 0.4 / 1.3? NM z ac = 40 / 260? m r = 374 m ε = 6 / ( 35 ) 518 musa m 1070 m x ac =0.6 NM z ac =57 m X LIDAR X SODAR/RASS x ac =1.0 NM z ac = 97 m r = 1460 m ε = m x ac = 0.75 NM z ac = 71 m r = 624 m ε = 6.5 X X sites of ONERA Lidar Sites of DLR LIDAR and SODAR/RASS/USA Intersection of glide path with LIDAR beam Figure 2 : Location of sensors and measurement planes 3

7 2.1.3 ONERA LIDAR New ONERA wake vortex lidar results from research completed within ONERA/DOTA on 1.5 µm fiber lasers. This new technology makes it possible to consider more compact and less expensive systems. It is eyesafe and out of visible range. The scanner sweeps space in a vertical plane according to a programmed sector. It is necessary to add to this unit a computer which controls the lidar and carries out signal processing. This lidar measures wind speed by an absolute frequency measurement (measurement of the Doppler shift). It thus does not need to be calibrated. If a measurement is available (i.e. if there is sufficient signal),this measurement is inevitably good. System performances are: range 400 m on vortices (the distance lidar- axis of the track must be lower than 250 m). Velocity dynamics: between - 25 and + 25 m/s Velocity resolution about 1 m/s Longitudinal resolution: about 2 m after signal processing Side resolution: 1 m for a measurement distance of 300 m, i.e. 3 mrad in angle. The Figure 3 give examples of simulated lidar measurement of a wind field associated with a pair of wake vortices. The location of the circles centres is the result of a correlation calculation with a model of wake vortex. The former positions of the vortices are preserved on real time posting in order to follow the trajectory. Figure 3: Simulated lidar measurement of a wind field associated with a pair of wake vortices 4

8 For Credos campaign in Frankfort, ONERA lidar will be located under the axis of runway 25 R. (red point in the above Figure 4). Figure 4: Sensor Locations at Frankfurt Airport The scan plane is flexible, either perpendicular to the runway or parallel to DLR scan plane as shown in the Figure 5. Figure 5: Flexible scan planes Being almost under the flight path will allow us to measure very accurately vortices position and separation. For each over flight, ONERA lidar will provide vortices positions and circulation values as a function of time. The lidar trailer will be installed during two months, from mid January to mid March, and the lidar will be operated during four weeks if good weather is available during the period. 5

9 2.2 Weather DFS WTR/RASS The wind-temperature radar with radio acoustic sounding system, WTR/RASS, of DFS has been deployed in May 2004 as part the development of DFS wake vortices warning system, WVWS, at Frankfurt airport. It is located to the west of runway 18, approximately 120 south of the extended runway centreline of runway 07R. Although the WVWS never became operational, the WTR/RASS is now running since more than 2½ years in dedicated measurement campaigns as well as for routine measurements. Its data has been used for a broad range of applications. Every two minutes the WTR/RASS delivers 3-dimensional wind- and temperature profiles together with additional information about data quality, turbulence and other system related items. Normally wind profiles are available in the height band from 60 m up to 1500 m above ground level in 30 m increments. Due to technical restrictions the range of the temperature measurements ends around 1000 m AGL on average. Data from the entire 2½-year period is available. For the purpose of CREDOS a dedicated campaign has started on June 1 st, 2006, which will continue at least until July It is recommended to concentrate the analyses of real meteorological data to that period, since format of the data and the modes of operation of the WTR/RASS have been changed a few times in 2004 and For more details about data formats see Annex 6 and Annex DLR SODAR DLR A Sodar with a RASS extension (METEK DSDPA.90-24, MERASS 1274 MHz) provides vertical profiles of the three wind components, vertical fluctuation velocity, and virtual temperature. The vertical resolution is adjusted to 20 m and the averaging time to 10 minutes. The lowest measurement height is 40 m and the instrument reaches maximum heights between 160 m and 300 m. Based on the assumption of isotropy, the rms value of turbulence can be calculated from the vertical fluctuation velocity. The Brunt-Väisälä frequency can be derived from the virtual temperature profiles. The Sodar/RASS system is complemented by a sonic anemometer with a sampling frequency of 20 Hz mounted on a 10 m mast which provides the three wind components, turbulent kinetic energy, and virtual temperature. Eddy dissipation rate can be determined from longitudinal spectra and structure function (2nd & 3rd order). Both instruments are operated permanently and are situated close to the DWD station in the middle between runways 25L and 25R (see Figure 2 in section 2.1.2). The measurement phase starts in week 51 and will end in February For more details about data formats see Annex DFS METAR and weather data Deutscher Wetterdienst, DWD, the German meteorological service provider is responsible for the provision of standardised meteorological data, such as METAR, TAF and SIGMET. For this purpose DWD operates anemometers, ceilometers, pressure- and visibility sensors on the airfield. The data, which is updated every ten seconds is sent to the responsible ATS-units, e.g. Frankfurt Tower and Frankfurt Approach. On June 10 th 2006 DFS R&D unit started to store these data for subsequent analysis within the CREDOS project. Collection of these data will continue at least until July The dataset contains wind-direction and speed measured at three different locations. QNH, QFE, several runways visual range measurements complete the set of surface observations. If necessary the data can be supplemented by measurements with the ten sonic anemometers of the Frankfurt windline. For more details about DFS data format see Annex 8. 6

10 2.3 Aircraft information DFS Radar Data For a reliable prediction of the areas where wake turbulence might constitute a risk for following traffic rather precise information about actually flown aircraft trajectories, including rotation point, initial climb rate, airspeed etc. is needed. DFS Deutsche Flugsicherung GmbH is collecting such surveillance data since June 1 st For security reasons the data is retrieved through DFS Test-RadNet, a system similar to the operational RadNet which collects the data from all Radars and distributes it to the concerned ATS-units. Due to its very nature, the test system has not such a high-redundancy and fail-safe layout as the operational RadNet. Nevertheless experience during the past 7 months showed that periods where no data could be retrieved are rare. The raw radar data is treated by the PHOENIX-Multiradar-Tracking System before it is filtered and stored. The data basically consists of series of position information (latitude and longitude in the WGS84 reference frame, the Mode-C pressure altitude) combined with a timestamp, groundspeed, heading and if available other information like callsign, aircraft type, Mode-S address of the aircraft. The data covers a corridor along the extended runway centrelines, which extends 1 km to either side of the runways 25/07 (total width of approximately 2.5 km). Within this corridor all aircraft lower than or at 5000 ft and within a ten nautical miles range are captured. Further processing steps need to be taken before the data fits to the needs: Position information for singular flights have to be selected and in particular the vertical position information has to be corrected. Mode-C corresponds to the height above mean sea level in a standard atmosphere with an air pressure of hpa at mean sea level. As part of data processing at DFS the aircraft Mode-C information is correlated with the local QNH and the temperature profile (from the WTR/RASS) during the particular flight event. With this additional information and the airport elevation the position data is converted into an airport centred reference frame and the height of the aircraft above ground level can be delivered with a much higher accuracy. It is important to note that only DFS will have access to the full radar information. For other CREDOS partners only anonymous data will be accessible, i.e. call sign, Mode-S address and date and time of the event will be removed from the files. However all other information about each flight event will be visible: aircraft type and runway, most recent meteorological observations and vortex trajectories. Note that thanks to Existing Memorandum of Cooperation between DFS and Volpe Centre the complete information, required for US LIDAR data postcessing can be delivered to Volpe. For more details about DFS data format see Annex Merged data US LIDAR data and radar data, WTR/RASS, METAR and other weather information will be merged by DFS and will constitute the main EDDF2 output. For more details about DFS data format and merging process see Annex 8. 7

11 3 CREDOS available pre-existing database This section describes the databases constituted by CREDOS partners before or outside the project and made available for CREDOS activities. 3.1 Wake and Wind KSTL Database Since the KSTL data collection is still on going, this paragraph will only provide a snap shot of the status at the time of this writing. Figure 6: the KSTL site configuration from the period of April 2006 to early October 2006 FAA2 pulsed LIDAR was deployed in a dedicated wake mode to measure departures off Runway 30s. Departures off 30L is mostly in NGE and IGE generation height. However, the departures off 30R through the LIDAR scan will mostly be OGE generation heights. The Figure 6 reflects the KSTL site configuration from the period of April 2006 to early October Wake data from April 2006 to August 2006 have been processed for 30s departures and again, at the time of this writing, consists of the following wake tracks in the Microsoft ACCESS database form: Heavies 105 Wake data from September 2006 to November 2006 off the 30s departure have been processed but not yet in the Microsoft ACESS database. QA process is underway to examine the overall quality of the data since August The crosswind data came from both the Lidar, which has a five sec. temporal resolution and from airport s ASOS sensor which has a one min. update rate. The Lidar s crosswind measurements cover up to 1150 feet AGL where as ASOS is a point measurement at 33 feet. From early October to present, a NASA funded meteorological tower was added to the KSTL site configuration and schematically shown in the Figure 7. The tower is 106 feet in height and instrumented with the following sensors: Three high speed sonic anemometers (Campbell Scientific CSAT3) at three heights 8

12 Three thermocouples (Campbell Scientific FW03) at three heights Nine propeller anemometers (R.M. Young model 27106RS) Three dew-point temperature and relative humidity sensors (Vaisala Air Temperature & Relative Humidity Probe HMP45D) The initial QA of the meteorological tower data is underway and to be followed by EDR and Brunt Vaisala frequency calculations. The overall Lidar and meteorological tower data statistics from October 2006 and onward will be updated. Figure 7: the KSTL site configuration after October Weather EDDF NOWVIV Database The non-hydrostatic mesoscale weather forecast model system NOWVIV (NOwcasting Wake Vortex Impact Variables) comprises a full physics package including boundary layer turbulence, surface energy and momentum balance, soil physics, radiation processes including cloud effects, cumulus convection, and cloud physics. The core of NOWVIV is the mesoscale model MM5 where a Yamada & Mellor 2.5 level turbulence closure scheme is employed from which turbulent kinetic energy (TKE) is computed as a prognostic variable. The eddy dissipation rate is extracted from the TKE budget equation. NOWVIV has been employed to establish a one-year data base of realistic meteorological conditions for the Frankfurt terminal area. For this purpose two nested domains with sizes of about km 2 and about km 2 centred on Frankfurt airport with grid distances of 6.3 km and 2.1 km, respectively, were used. The model employed 60 vertical levels such that in the altitude range of interest (z < 1100 m above ground) 26 levels yielded a vertical resolution varying between 8 m and 50 m. Initial and boundary data were taken from the numerical data assimilation model LM (Local Model) of DWD (German Weather Service). These data represent the best possible forcing of NOWVIV since actual observations (radio soundings, AMDAR, satellite data, surface observations, etc.) are used to analyse the state of the atmosphere. Detailed topography, land use and soil type data for the Frankfurt area were employed. Profiles of meteorological data were extracted at 25 locations separated by one nautical mile along the glide paths for approaches on the 07 and 25 runways. An output frequency of 10 minutes was selected. 9

13 The resulting number of profiles amounts to about The meteorological quantities comprise the three wind components, air density, virtual potential temperature, turbulent kinetic energy, eddy dissipation rate (EDR), and pressure. The 1-year meteorological data base has been validated against a 30-year wind climatology and a 40- days subset has been compared to ultrasonic anemometer, SODAR/RASS, and LIDAR measurement data acquired at Frankfurt airport at height levels ranging from the surface up to 300 m. Case studies with weak and strong synoptic forcing complement the assessment. Assessments of wake prediction skill based on predictions of meteorological conditions with NOWVIV can be found in TBD The different assessments indicate a high quality of the synthetical data set. Exemplarily for the verification work, the Figure 8 below shows the comparison of the 1-year synthetic wind data with the 30-year surface wind climatology. The climatology considers winds averaged over one hour measured at 10 m above ground in a time frame from 1967 to The observed main surface wind directions are not only the result of predominant synoptic patterns, but are also influenced by the orography in the vicinity of the airport, here in particular the Taunus mountain ridge. The joint frequency distribution of wind speed and direction established with NOWVIV (lower panel) shows in general good agreement with the climatology (upper panel). The Frankfurt wind climatology is characterized by two main wind directions: South-westerly winds with a peak around 200 and northeasterly winds around 50. For both main wind direc tions the corresponding peak in the mean wind speed is between 2-4 m/s. In the synthetic data the occurrence of stronger winds is slightly under-represented. Part of the minor differences in wind direction can be attributed to climate variability and trends. For example, in accordance with NOWVIV predictions, a higher frequency of easterly winds is noted by controllers at Frankfurt airport in recent years with more frequent landings on runway 07. Note that the data base can only be used within CREDOS after formal approval. Figure 8: Comparison of the 1-year synthetic wind data with the 30-year surface wind climatology EDDF Wind Database In contrast to DLR s EDDF NOWVIV Database which provides synthetic weather on a mesh covering roughly the terminal manoeuvring area, DFS owns a database of measured wind-, temperature and turbulence profiles, which represent the conditions at a single location each. For details see section about WTR/RASS of DFS. 10

14 4 Data expectations This section provides descriptions of the various WP s, tasks and sub-tasks based on the Technical Annex 1 - Description of Work and on detailed task descriptions as delivered in the various WP management Plans. When identified, the data requested for theses various sub WP have also been listed and described. 4.1 WP 2 Data Analysis & WV Behaviour Modelling: The aim of this work package Data Analysis & WV Behaviour Modelling is to analyse the evolution of wake vortices shed by departing aircraft under various atmospheric conditions, to improve and adapt the real-time models APA, P-VFS and P2P for that flight conditions, and to develop the algorithm WAVENDA, which detects wake encounters from the aircraft controls and motion, for the departure phase WP 2.1 Data Analysis The data analyses performed here will aim to identify the primary wake vortex behaviour classes of interest for the departures situation for a single runway. The data will be studied to reveal typical wake vortex transport and decay behaviour under the different meteorological conditions. The crosswind component is the condition of main interest but it will be important to study the impact of the simultaneous longitudinal component. Also of interest will be departure-specific circumstances such as jet thrust and vortex end effects WP Meteorological Classification Partners: DLR, DFS, US to identify and classify the meteorological conditions and flown a/c trajectories (from DFS); to determine the strength and the frequency of sudden crosswind changes, which are of utmost operational concern; to seek for quantities that are easy to measure (and forecast) and are strongly correlated with the observed wake vortex behaviour (weather classification); (to assess the skills of DLR s NOWVIV to forecast crosswind conditions.) Note: DLR has a one year weather data set for Frankfurt airport: Profiles of wind, temperature and turbulence each 10 min. This data set is produced by NOWVIV and resembles real weather in Frankfurt in the course of one year. DATA REQUIRED by WP 2: DFS Departure radar a/c tracks DLR SODAR/RASS/SONIC (7 measuring days, 21/22 Dec. 2006, 23/24/25 Jan. and 16/17 Feb. 2007) DFS WTR data in the period from to DFS METAR data in the period from to WP Wake Vortex Data Correlation w.r.t. the ConOps Partners: DLR, UCL, Airbus, DFS, US 11

15 to determine minimum x-wind (profile) to clear the corridor for phase 1; to relate that threshold wind (profile) to weather conditions ( as known to the airport ); to determine the frequency of crosswind conditions with respective benign WV behaviour in the data sets and assess the possibility of reduced separations for departing aircraft at KSTL and EDDF. DATA REQUIRED by DLR: DLR LIDAR wake and wind data and DLR SODAR/RASS/SONIC data DFS METAR data DATA REQUIRED by US: Wake and crosswind profiles from the Lidar will be used as a baseline study. However, operationally it would be more useful to see crosswinds as seen by the Lidar compare with existing wind sensors on the airport to better address if a dedicated wind sensor would be required operationally. For example, a higher update rate of the METAR (in the US, it is called ASOS) data would be highly desirable, particular if they are available from both areas near Runway 25 and Runway 18. The windline and Sodar data are also considered highly desirable. The comparison crosswinds at various heights from the Lidar data will also be made to establish if a lower altitude wind sensor can satisfy the safety case of ensuring that OGE vortex will not be an issue and what constraint it may place on the aircraft departure trajectories in the future. US LIDAR wake and wind data A higher update rate of the DFS METAR data DLR SODAR/RASS/SONIC Departing aircraft list with a/c type, position in the scanning plane, See Annex 3 for more details WP 2.2 Adaptation and validation of the WV prediction models Wake vortex behaviour data which have been analysed for different weather conditions in WP 2.1 will be used to update the existing behaviour prediction models, APA (NASA), P-VFS (UCL) and P2P (DLR). These models have been in existence for several years and have been progressively improved through their usage in other projects. Note that P2P and P-VFS are also being improved for vortices in-ground, near-ground effects (IGE, NGE) in the FAR-Wake project. DATA REQUIRED by DLR: Data of the 130 to 150 heavies from EDDF1 DATA REQUIRED by UCL: See Annex 1 DATA REQUIRED by US: See Annex 2 12

16 4.1.3 WP 2.3 WAke Vortex ENcounter Detection Algorithm WAVENDA 4.2 WP 3 Risk Modelling & Risk Assessment: The aim of the work package is to provide a simulation environment for the assessment of wake vortex hazard under different crosswind conditions. The first phase sees the updating of existing airspace models to cover the departure situation. This work also includes the development of pilot models representing the cockpit reaction to wake vortex encounter. Another important result from this WP will be the establishment of severity criteria taking account of the real risk associated with a wake vortex encounter. Operational scenarios will then be defined representing the full range of situations. These will be set up in the upgraded models to determine the quantitative risk associated with different separation minima and so leading to recommendations for the separations to be used under certain crosswind strengths WP 3.1 Model development and validation Objectives 1.) For the risk assessment an offline wake vortex encounter simulation for take-off and departure will be developed. This requires Development of pilot models that represent the pilot s behaviour during take-off and departure as well as the pilot s compensatory reactions during a potential wake vortex encounter Development of severity criteria that relate objective a/c parameters to the pilot s assessment of a WVE for take-off and departure Integration of the models to set up the offline-simulation for take-off. 2.) Adaptation of an air space simulation (vortex evolution, a/c trajectories, etc.) to the take-off and departure flight phases. 3.) Coupling of the air space simulation with the flight dynamical wake vortex encounter offline simulation WP Development of trajectory models for take-off and departure Partners: TUB, DLR This tasks will provide a model for the take-off and departure trajectories of a variety of different aircraft types (A320, A340, B747 ) based on aircraft performance data, taking into account Meteorological conditions (Horizontal wind, atmospheric conditions) Aircraft characteristics (weights of generator and follower aircraft, performance ) Different Standard Instrument Departures (SID) The trajectories will be computed in six segments from the aircrafts start position up to a height of 3000 ft. A parametric model will be defined which allows easy variation and sensitivity analysis as well as portability to other airports. DATA REQUIRED by TUB: DFS Departure radar a/c tracks 13

17 WP Airspace simulation for take-off and departure Partners: DLR, UCL WP Definition of relevant scenarios Partners: DLR WP Preparation of piloted simulator tests Partners: AD, TUB, UCL WP Piloted simulator tests Partners: AD, TUB, UCL WP Development of WVE severity criteria Partners: TUB WP Development of a pilot model for take-off and departure Partners: TUB WP Advanced WVE offline simulation for take-off and departure Partner: AD, DLR WP 3.2 Wake vortex encounter safety assessment for departure WP Definition of operational scenarios Partner: AD, DLR 14

18 WP Quantitative safety assessment Partner: AD, DLR WP Safe separation distances for take-off and departure Partner: AD 4.3 WP 4 Operational Concept & Validation WP 4.1 Operational concept and system requirements WP 4.2 Validation cases development WP Validation Strategy Description WP Pre-implementation Safety Case To provide a justification for the safe introduction of WV Crosswind Departures operations (typically by justifying the predictions and assumptions & putting in place a safety monitoring regime). This will be done through the use of the Safety Case Methodology: As part of these activities a Functional Hazard Assessment (FHA) and Preliminary System Safety Assessment (PSSA) will be produced, using risk assessment results from WP 3. To develop a plan for conformance of CREDOS Safety and Risk Assessment Results with European Safety Regulatory Requirements (ESARRs), so as to facilitate a smooth and safe implementation of a validated crosswind departure concept at airports. To provide a template approach showing how the monitoring requirements will be met. DATA REQUIRED by NLR/ECTL: Integrated traffic, wake and weather data 15

19 WP Human Factors Case WP Other Cases WP Airport WV Safety Management System WP 4.3 Real-time simulations The main thrust of the operational feasibility study will be the real-time simulations to be performed on the NLR simulator. The objective of these studies will be to expose the concept to operational controllers and make an assessment of the overall acceptability in terms of HMI, working procedures and workload. Two formal evaluation sessions are foreseen with a third open session where the concept can be demonstrated to a wider group of controllers. The main task is to carry out the real-time simulations to assess end-user perceptions of the concept and its feasibility. This will be done in two phases: - Part-task simulation phase: for parameter tuning of system components and demonstration of feasibility of operational procedures and concept in a real-time simulation environment; - Full-scale simulations for validation of tuned simulation environment such that operational benefits can be assessed (baseline and advanced system) Meteorological data for the simulated airport will be acquired from real recorded data. DATA REQUIRED by NLR: Three dimensional grid-based meteorological data See Annex 4 for more details 16

20 5 Summary of the data exchanges between WP1 and the others WP s 5.1 Data user (others Wp s) point of view Type of Data Required Specific Data Requirement WP 2 Data Analysis & WV Behaviour Modelling Aircraft tracks WP 2.1 Data Analysis Wind profile measurements Wind measurements as known to the airport WP Meteorological Classification DATA REQUIRED by DLR: DFS Departure radar a/c tracks DLR SODAR/RASS/SONIC (7 measuring days, 21/22 Dec. 2006, 23/24/25 Jan. and 16/17 Feb. 2007) DFS WTR data in the period from to DFS METAR data in the period from to WP Wake Vortex Data Correlation w.r.t. the ConOps DATA REQUIRED by DLR: Aircraft tracks Wind profile measurements Wind measurements as known to the airport Wake data DLR LIDAR wake and wind data DLR SODAR/RASS/SONIC data DFS METAR data DATA REQUIRED by US: (See Annex 3 for more details) US LIDAR wake and wind data A higher update rate of the DFS METAR data DLR SODAR/RASS/SONIC Departing aircraft list with a/c type, position in the scanning plane, WP 2.2 Adaptation and validation of the WV prediction models Aircraft position in the scanning plane 3D wind profile measurements in the scanning plane 2D wake vortex tracks in the scanning plane DATA REQUIRED by DLR: Data of the 130 to 150 high quality heavy measurements from EDDF1 DATA REQUIRED by UCL: (See Annex 1 for more details) DATA REQUIRED by US: (See Annex 2 for more details) WP 2.3 WAke Vortex ENcounter Detection Algorithm WAVENDA 17

21 Type of Data Required Specific Data Requirement WP 3 Risk Modelling & Risk Assessment WP 3.1 Model development and validation Objectives WP Development of trajectory models for take-off and departure Departure a/c tracks DATA REQUIRED by TUB: DFS Departure radar a/c tracks WP Airspace simulation for take-off and departure WP Definition of relevant scenarios WP Preparation of piloted simulator tests WP Piloted simulator tests WP Development of WVE severity criteria WP Development of a pilot model for take-off and departure WP Advanced WVE offline simulation for take-off and departure WP 3.2 Wake vortex encounter safety assessment for departure 18

22 Type of Data Required Specific Data Requirement WP 4 Operational Concept & Validation WP 4.1 Operational concept and system requirements WP 4.2 Validation cases development WP Validation Strategy Description WP Pre-implementation Safety Case Integrated traffic, wake and weather data DATA REQUIRED by NLR/ECTL: EDDF 6-Month Wake and Weather Dataset RWY25L/R [EDDF-2] WP Human Factors Case WP Other Cases WP Airport WV Safety Management System WP 4.3 Real-time simulations Three dimensional grid-based meteorological data DATA REQUIRED by NLR: (See Annex 4 for more details) 19

23 5.2 WP1 point of view Data transfer Wake and Wind Data Available Delivery date Data Users US LIDAR data ( FAA/ NASA) At least 6 months of wake vortex tracks and 2D wind profiles (See Annex 5 for more details) LIDAR data (DLR) 130 to 150 high quality heavy measurements collected during 10 weeks profiles (See Annex 6 and 7 for more details) LIDAR data (ONERA) Between 50 to 100 measurements collected during 3 weeks Weather WTR/RASS data (DFS) 1 year of 3D wind profiles, temperature profiles and turbulence measurements (See Annex 8 for more details) SODAR data (DLR) 10 weeks of 3D wind profiles, temperature profiles and turbulence measurements (See Annex 6 and 7 for more details) METAR and Weather data (DFS) 1 year of METAR and other airport weather measurements (See Annex 8 for more details) Aircraft Information RADAR data (DFS) departure tracks from runway 25/07 and 1 year of departure tracks from runway 25/07 (See Annex 8 for more details) Merged Data (DFS) 6 months of correlated aircraft and vortex tracks each one provided with the corresponding WTR/RASS wind and temperature profile, METAR information and other airport weather Intermediate Monthly Deliveries 01/05/07 WP FAA/NASA for analysis related to ConOps validation WP 1.3 DFS for merging with weather information WP DLR for analysis related to ConOps validation WP 2.2 DLR/UCL/FAA/NASA for WV models benchmarking and improvement 01/09/07 Not identified 28/09/07 28/09/07 28/09/07 23/02/07 28/09/07 28/09/07 WP 2.1 DLR for analysis related to ConOps validation WP 2.2 DLR/UCL/FAA/NASA WV modes benchmarking and improvement WP DLR for analysis related to Weather Classification and ConOps validation WP DLR for analysis related to Weather Classification WP DLR for analysis related to ConOps validation WP TUB for development of trajectory models for take-off and departure ( track) WP 2.2 DLR/UCL Models benchmarking and improvement WP NLR/ECTL for analysis related to Pre-implementation Safety Case 20

24 measurements (See Annex 8 for more details) Database Transfer Databases Available Delivery date Databases Users Wake and Wind US KSTL database ( FAA/ NASA) 105 heavy departure wake vortex measurements and corresponding 2D wind profiles Weather 09/03/07 WP UCL/FAA/NASA for analysis related to ConOps validation EDDF NOWVIV Database (DLR) one-year data base of realistic meteorological conditions for the Frankfurt terminal area EDDF Wind Database (DFS) Entire 2½-year WTR/RASS 3D wind profiles, temperature profiles and turbulence measurements Not identified WP 4.3 NLR for Real Time simulation Not identified 21

25 Annex 1 Description of the data characteristic required for WV model improvement Cerdic Cotin, UCL Grégoire Winckelmans, UCL Frank Holzäpfel, DLR November 22th, 2006 The DLR wake vortex prediction model P2P needs high-quality wake trajectory and circulation data as well as vertical profiles of meteorological impact parameters. The latter include all three wind components, potential temperature, turbulent kinetic energy (TKE), and eddy dissipation rate (EDR). This data should be detected at a distance not larger than about 500 m from the location of wake evolution with a vertical resolution of at least 20 m and a temporal average of at least 10 minutes. About 30 high-quality cases appear sufficient for the planned analysis. If the deviations between approach and departure characteristics turn out to be significant and difficult to assess a larger amount of data may be needed. Basically the same is used for the DVM and PVM: Wake vortex track: high-quality wake trajectory and circulation data: basically the time evolution, for the two vortices, of the lateral (perpendicularly to the aircraft trajectory) and vertical positions, and their circulation (the way it is provided has to be well-defined: total circulation or Γ 5-15?). The track must start as soon as possible once the roll-up process is completed. Indeed, since the first measurement is used as input (at least when no sufficient information about the aircraft trajectory is available), the data must be representative of the initial wake vortices (relatively symmetric, not having experienced any decay yet). Aircraft Information: aircraft lateral and vertical position, aircraft flight speed, aircraft wing span, and aircraft weight are used as inputs of the wake predictor models. These data have to be known at the time when the aircraft flies through the wake vortex track measurement plane. If not available, we can only use the circulation and vortex spacing from the initial wake vortex track measurement as input. Thus it must be sufficiently accurate. Weather data: vertical profiles, at least for the altitudes at which the vortices are measured and with resolution of at least 20 m, of the meteorological impact parameters: head- and cross-wind mean components (i.e., time-averaged), standard deviation components, stratification (potential temperature), turbulence: EDR or TKE (if EDR not available). Best is to have both EDR and TKE. By standard deviation, we mean the physical wind fluctuations that occurred during the integration time of the instrument, as well as the measurement uncertainties of the instrument. If the standard deviation is provided only for the vertical wind component (as typical of SODAR), then, the standard deviations for the other two components will be approximated from it. Concerning the wind data: it is important to have the real head-wind (i.e. direction parallel to the flight path) and cross-wind (i.e. direction perpendicular to the flight path) components. If the three mean wind components are given by a SODAR and if an additional LIDAR measurement gives the wind component in a plane non-perpendicular to the flight path, the data must be consistent (when projected into the aircraft coordinate system and taking into account the accuracy of each device) to be relevant and useful. One should also avoid wind and/or temperature profiles with unphysical sharp variations due to measurement errors: such unrealistic gradients will significantly weaken the wake vortex behaviour prediction. It is important to stress that vortex behaviour is very sensitive to the weather conditions. The quality of 22

26 weather data measurement has a direct impact on the capability of wake vortex predictors. Poor weather data accuracy implies poor prediction quality. Concerning the quantity of data required to improve/validate the models, the order of magnitude is good quality cases for each situation (OGE/IGE, crosswind, headwind, light/heavy aircraft ). For instance, one situation would be: heavy aircraft, OGE, no or weak wind ( 1 m/s), no or weak turbulence. The relevant classes of situations will be determined in the framework of WP 2.1, dedicated to data analysis. Since models in ground effect are less mature, a large number of data NGE/IGE will be particularly needed. The expectations of KSTL (20,000 departure data sets of mainly light to medium aircraft) and EDDF2 (16,000-20,000 departure data sets including heavy aircraft) campaigns should provide a reasonable number of good quality data sets. Some important requirements concerning the data transfer: Cerdic Cotin, UCL Grégoire Winckelmans, UCL April 5th, 2007 Data must be provided officially together (at the same time) with detailed information in a single document rather than in s. Information required includes: Precise definition of the coordinate system for the measured positions and for the velocity profiles. Definition of the site topology including the exact position of the runways. Definition of the measured quantities (including the units): position (lateral and vertical), circulation (total or Γ 5-15 ), initial time, meteorological data (cross- and head wind profiles, potential temperature profile, EDR profile) For the initial time t 0 : the relation to the time when the aircraft crosses the scanning plane is of great importance since a large difference, t = t 0 -t aircraft, can explain some of the unexpected initial data (as seen so far in some databases). Uncertainties for the different parameters measured or computed. Capabilities of the measurements tools: minimal/maximal lateral/vertical position and minimum circulation measured by the Lidar. The A/C type for each Wake Vortex track. In case of databases with data sets of different quality (e.g., circulation measurements of poor quality during a certain period at the beginning of the EDDF2 data collection, as mentioned), the data sets have to be provided separately with the information concerning their respective quality (there is no reason for low quality data sets to be used in the same way as high quality ones: both for data analysis and for models improvement/assessment. For this to be properly taken into account, the data users need to know if they cannot rely on some particular parameters in a specific data set). 23

27 Also, it is necessary that the post-processing of the data includes some arrangement and cleaning of the data (e.g., if the positive and negative vortex tracks are recorded separately for any reasons, they should be put together before being provided; unrealistic measurements (negative vertical position, lateral transport opposite to cross-wind direction ) should also be corrected or removed ). Data users won t perform any cleaning or quality check since they do not have the information required to do it in a proper and relevant way. The best would be that the data be provided using the MKSA unit system (and in any case, the units have to be provided). 24

28 Annex 2 Data Needs for LES and Real-time Wake Vortex Models: US Perspective Wayne Brayan (FAA), April 16th, 2007 Given the current state of technology, below is what is needed in a data set intended to develop and validate probabilistic wake models. The number of data runs is defined in the following table. It is assumed there will be 4 aircraft wake classes (either the ones below or the present USA versions); and that both the headwinds and crosswinds are binned into groups of 5 kts., resulting in a total of 16 headwind/crosswind bins for each aircraft class. For each intersection of wind/aircraft class, it is assumed that 50 quality checked runs would be adequate (25 to train, 25 to validate). The total number of quality checked data files is thus 3200 samples. Wind Components (Headwind/Crosswind) Headwind Component Crosswind Component Aircraft Class Super Heavy Heavy Medium Light Total Number of Quality Checked Departure Wake Records Required = 3200 Operations at a busy airport with a mix of heavy-light aircraft. A continental based airport located between 45 and 20 degrees latitude would be best in order to achieve a wide range of meteorological conditions. Measurements at least through 18 hours each day. Need to accumulate a large number of cases to cover diurnal and seasonal ranges in weather. For each of these samples, the following data is required Pulsed LIDAR measurement of wake vortices. The algorithm for computing circulation needs to be validated. LIDAR measurements at four locations between the runway and outer-marker would provide data for IGE, NGE, and OGE model development. Measured Wake Vortex Parameters: Lateral position (+/- 5 m) Vertical position (+/- 5 m) Average 5-15m circulation ( +/- 25 m^2/sec, and threshold of 100 m^2/s) 25

29 Environmental wind profiles derived from the Pulsed LIDAR at times before and after each aircraft passage. (At minimum, the in-plane winds) An instrumented meteorological tower on or near the airport premise. The tower should be at least 100ft (200ft would be preferable), and have two or more levels of instruments capable of high-frequency measurements A reliable SODAR or similar sensor to obtain temperature profiles. Environmental Parameters: Vertical profile of crosswind (5 min avg) (+/- 2 m/s, vertical resolution of 15 m) Vertical profile of head/tail wind (5 min avg) (+/- 4 m/s, vertical resolution 25 m) Turbulence Profile, 15 min Eddy Dissipation Rate (tolerable error within same order of magnitude, but must perform at low and high values of edr) Turbulence Profile, 15 min Turbulence Kinetic Energy (+/- 50%) Temperature Lapse rate (+/- 2.5 deg C/km) Identification of each aircraft type. If their weights could be obtained this information would be useful. Aircraft Parameters: Aircraft type and model: e.g., B Aircraft airspeed (+/- 10 m/s) Aircraft Weight (+/- 10% MTW) Aircraft Lateral Position (+/- 15m Aircraft Height (+/- 10 m) Time at middle marker (+/-2 sec) ASOS data to determine current meteorology; ie. rain, fog, precipitation, etc. A continual assessment of data quality from the sensors to ensure they are performing to specifications Rapid processing, collection, and cataloguing into one data base. Data from other wake and weather sensors would be plus. 26

30 Annex 3 CREDOS Data Needs for US activities Introduction USDOT Volpe Center January 11th, 2007 For the subsequent data processing and integration of the met data into a database to facilitate the statistical analysis of CREDOS, the following types of data have been identified as high-priority: 1. Aircraft Departure List 2. Equivalent of the 1-min. ASOS used at EDDF 3. Equivalent of the 5-min. ASOS used at EDDF 4. EDR (if raw data can be obtained from a sonic anemometer) We have exchanged some with Jens, but would like this to be discussed further in meetings next week. The input exchanged with Jens seems to indicate that the mode of exchange to be one in which we provide the time of the lidar tracks and DFS will match the aircraft ID afterwards. This works well for dedicated, manned test, but it is not very convenient for the existing software setup / infrastructure of the US owned cti lidar, which is intended to be doing post processing of unmanned 24/7 type of data collection. Aircraft Departure List A subset of the Radar track data is desired. Such a list is an input file to the Lidar processing and is useful in compiling wake detection statistics for the Lidar. The wake detection statistics also provides an independent way to monitor the health of the sensor. A short example of such a departure list from STL is shown below (based on Multilat): Day,Hour,SODmed,HTmed,Op,Code,Owner,Mfg,Model,Hour,Min,sec 01-Aug-06,0,2186,550,A,AB153A,OF5519,Douglas,DC94,0,36,26 01-Aug-06,0,2233,550,A,A4995F,AL9836,Boeing, ,0,37, Aug-06,1,5727,525,A,A44441,HQ5330,Boeing,B752,1,35,27 02-Aug-06,1,6179,525,A,A4794E,UNK,Boeing, ,1,42,59 Day and Hour fields in UTC: Note that the month information is in the form of three-character field. SODmed is second of day since each UTC day s mid-night. Each SOD is the time when the aircraft passes by the Lidar scan. For RADAR data, due to its slower update rate, interpolation might be required. HTmed is the height of the aircraft as reported by Multilat or Radar passing through scan. The desirable data here would be the already pressure corrected altitude. Op is operation, but will always be listed as A for us. Code, Owner are the mode-s code in hex and flight-id. Mfg is manufacture of the aircraft Model is the model, strong preference in the FAA 4-digit notation which preserves the series of the model Hour, Min and sec are the flyby times on the particular day. For example, 0,36,26 then adds up to 2186 as indicated in the third field. 27

31 Although the structure of the file has 12 columns, only the fields marked in bold characters (see below) are absolutely needed (and the rest can be filled in by dummy data). The file should be in csv format. Day,Hour,SODmed,HTmed,Op,Code,Owner,Mfg,Model,Hour,Min,sec 01-Aug-06,0,2186,550,A,AB153A,OF5519,Douglas,DC94,0,36,26 01-Aug-06,0,2233,550,A,A4995F,AL9836,Boeing, ,0,37,13 Alternatively, if radar tracks themselves were accessible to us, such a list can then be generated by the US Lidar team. However, the strong preference is to have such a list be generated by the European partner. 1-Min ASOS Type of Wind Data The METAR data used so far in benefit studies of CREDOS is an hourly averaged wind and the temporal resolution is considered too coarse for wake turbulence studies. It is assumed that EDDF controllers have access to a higher temporal resolution wind source. In the case of US, such a wind source is the ASOS, which is typically the center-field wind outputted every minute. There is no need to obtain this wind data in real-time. During one of the CREDOS meeting trips in 2006, we were briefed that there exists a wind sensor mounted on 10 meter pole between the two parallel runways and closer towards the thresholds of Runway 25s. The recollection was that the wind sensor is maintained by the German Weather Service (DWD). Being close to the 25 end of the runway, the sensor is very well suited for studying IGE transport for the measurement experiment of CREDOS in Frankfurt. The output data does not need to duplicate the format of ASOS or METAR, but the fields of the data are preferred to be separated by either column and semi-column. A generic format in the following form is sufficient: Column1: Some form of time stamp, such as yyyymmdd_hhmm in UTC or yymmdd:hhmm in UTC. Column2: Magnitude of the horizontal wind (either SI or English units will be fine) Column3: Direction of the wind in degree relative to either true or magnitude north. If gust (or max wind) information were also recorded as the output from the same time interval, those data would be desirable, but not absolutely necessary. If obtainable, they may be included as Columns 4 and 5: Column4: Magnitude of the gust/max wind. Column5: Direction of the gust/max wind in degree. Ps. If the wind is outputted as headwind and crosswind relative to Runway 25, that is ok as well. 5-Min. ASOS Type of Ceiling and Visibility Data Correlation between ceiling, visibility and wind can have important implication in shaping a final operational concept / details in a wind based wake alleviation scheme. In the US, information regarding ceiling and visibility are found in the five-minute form of the ASOS data, which is more or less a higher update rate of the METAR. If higher update rate ceiling and visibility data are not available, METAR data might be sufficient. But if the higher update rate ceiling and visibility data were available, they are preferred over METAR. In the event that the ceiling and visibility data do not come from METAR, the preferred format is as follows: Column1: Column2: Column3: Some form of time stamp, such as yyyymmdd_hhmm in UTC (but yyyymmdd:hhmm would work as well) Ceiling value (either SI or English units are ok) Visibility value (either SI or English unites are ok) 28

32 EDR Data Although EDR may not be likely to become part of the operational concept that may emerge from the results of CREDOS, the quantity is required in support of wake transport prediction algorithm development which may then be incorporated into monte carlo based safety assessments. High speed sonic anemometer derived EDR is preferred since it has the most history of validation and is considered more reliable. Since wake measurements also will be focused on near the ground, 10 meter height EDR data would be sufficient. The sonic data should have a minimum sampling rate of 10 Hz and the desired location is as close to the wake measurements as possible. If the wind sensor maintained by DWD discussed in the 1-min. ASOS data were a high speed sonic anemometer with 10 Hz or greater sampling rate whose raw data can be saved, that data set can then support the EDR data needs. Alternatively, EDDF has an array of high speed (25 Hz) sonic anemometers located on the Runway 7 end of the aiport, which can also be candidates for surface EDR source. The raw data format is somewhat flexible, as long as documentation exists. A small sample, if available, would be desirable. Data Merger Statistical analysis of the CREDOS data is believed to be the appropriate approach for examining the operational concept and a rational database has been shown to be an effective mean of supporting the study. For the data collected by the US Lidar, the database management tool proposed is Microsoft Access. Database queries can be done in either Access, or most probably, in Matlab. The wake, met and aircraft ID data will be merged into various tables and linked within Access. An example of a table within the departure database from St. Louis is shown in figure 1. Figure 1: Example of a Table within the STL Departure Database. This particular table shows the time of the wake detection, aircraft ID, class, Runway, wake positions and strength data as a function of wake age, and the associated wind conditions, all for port vortices. 29

33 Other Issues The additional support needed from a European partner (not necessarily DFS): 1. Internet setup (we have a small write up on the specs) 2. Local point of contact for first line type of trouble shooting 3. Arrangement for data retrieval 30

34 Annex 4 CREDOS data needs for Real Time simulation Théo Verhooght (NLR) January 4th, 2007 A three dimensional grid-based model is used for storing the meteorological data that has influence on the performance of the aircraft. The distances and heights between grid-posts can be adjusted. For each gridpost the following data can be stored: - Air pressure, air temperature, air density, wind (direction and velocity). During real-time simulation two of these grids are used for simulating changes over time. The time step between these two grids can be adjusted. In general the time step is 10 minutes. A time step smaller than 1 minute is not useful for real-time ATC simulation. The Tower controller has a panel which shows wind information from the wind sensor close to the active runway. Data needed is: - wind direction - wind speed This data shall be updated every 12 seconds (ICAO). Other general metrological data (METAR) which may be needed is: - Visibility - Dew point - QNH - Cloudlevel - Trend data (expected weather changes). Preferable SI units shall be used. 31

35 Annex 5 LMCT WindTracer system performance specification 32

36 Annex 6 Installation, Scenarios and Measurements of DLR equipment Thomas Gertz (DLR), February 22nd, 2007 Installation of DLR s LIDAR In week 50 (11. Dec.) the LIDAR has been installed at the proposed site SE from the thresholds of runways 07R/L (25L/R), see Fig. 3. The LIDAR is connected via UMTS with the LOZ, see below. Installation of Metek s SODAR/RASS/USA Metek s SODAR/RASS together with an ultrasonic anemometer (USA) has been rented by DLR. The system has been installed by Metek on 18. and 19. Dec. close to the DWD observer house (see sketch) and works with full functionality. It is connected via ethernet with the LOZ-PC. Installation of the Local Operation Centre (LOZ) at DWD s observer house The DWD observer house, which is located along the extended centreline of the taxi way in between both runways (labelled Rollbahn C ) just below the scan plane centre, hosts our Local Operation Centre, LOZ. A Linux-PC has been installed which is connected via UMTS to the computers at DLR (IPA in OP), via UMTS to the lidar container, and via ethernet to the SODAR/RASS/USA system. This PC serves as a front-end for the weather and wake forecasts and observations. It is accessible from the IPA premises in Oberpfaffenhofen. Scenarios: CREDOS or Wirbelschleppe (WS) Wind from easterly directions: a/c depart on 07L/R: scenario CREDOS Wind from westerly directions: a/c land on 25R/L: scenario Wirbelschleppe (WS) Forecast and measurement procedures of the installed and integrated system, WSVBS DLR s wake vortex prediction and monitoring system, WSVBS, as employed now at Frankfurt Airport for the Wirbelschleppe campaign, predicts temporal separations of aircraft landing on the parallel runway system 25L/R and translates the required separation between two a/c into an approach procedure which can eventually be used by ATC. At the same time, the wake behaviour (esp. wake transport) is monitored by LIDAR in different control gates. WSVBS runs off-line, i.e. its output is not used by ATC for separating aircraft. After the campaign all data including traffic flow will be analysed and possible capacity gains compared to ICAO standards will be assessed. For CREDOS the weather forecast part of the WSVBS is used to guide measurement strategies. The gathered weather and wake data are used for analysis in WP 2. Within the forecast system NOWVIV, the mesoscale model MM5 predicts the meteorological conditions for the Frankfurt terminal area in two nested domains with sizes of about 250 x 250 km² and about 90 x 90 km² centred on Frankfurt airport with grid distances of 6.3 km and 2.1 km, respectively. 60 vertical levels are employed such that in the altitude range of interest (z < 1100 m above ground) 26 levels yield a vertical resolution varying between 8 m and 50 m. NOWVIV runs twice a day (at 00 and 12 UTC) on a dedicated LINUX cluster at University of Stuttgart. Profiles of meteorological data are extracted at 25 locations separated by one nautical mile along the glide paths for approaches on the 07 and 25 runways. An output frequency of 10 minutes is selected. The 33

37 meteorological quantities comprise the three wind components, air density, virtual potential temperature, turbulent kinetic energy, eddy dissipation rate (EDR), and pressure. The forecast profiles are transferred to the LOZ-PC. The SODAR/RASS delivers its 10 minutes averaged data of vertical profiles of wind, temperature and a measure for turbulence via ethernet to the LOZ-PC. EDR is estimated from USA data. The real-time wake transport and decay model P2P uses both, forecast and measured, profiles to predict envelopes of the wake behaviour of aircraft from class HEAVY (H) in 13 gates along the glide path to runways 25 L/R, see Fig. 1. The safety area model SHAPe computes safety allowances for HEAVY and MEDIUM follower a/c. The allowances are superimposed on the envelopes of the vortex locations, yielding an overall safety area. The time between the instant when the a/c has crossed a gate and the instant when this safety area does no longer overlap with the ILS corridor in that gate determines the minimum temporal separations of two a/c pairings HH or HM. Fig wake prediction gates along the nominal ILS flight path 25 R/L ( x = 1/3 NM - 1 NM). Theses minimum separations are then translated into the approach procedures STAGGERED (both runways can be used independently) or MODIFIED STAGGERED LEFT (right runway can be used independently from the left if all HEAVY a/c are landing on left) or RIGHT (vice versa). The recommended approach procedures are displayed as shown in Fig. 2. ICAO is the standard procedure. Fig. 2. Display for a/c approach procedures. Fig. 3 depicts the measurement geometries and distances between lidar and the flight tracks of a/c departing from 07R/L or landing on 25L/R, hence for CREDOS and Wirbelschleppe purposes, respectively. For Wirbelschleppe, the LIDAR scans the air in three planes, the so-called control gates, labelled left/west, centre, right/east in alternating order to detect wakes of landing a/c. For CREDOS the wakes of climbing heavy a/c (which almost all depart from 07L with easterly wind conditions) are tracked and characterised in the scan planes left and centre where the a/c have reached a nominal altitude of 172 and 239 m. 34

38 The LOS velocity in a scanned plane is immediately visible in the so-called quick-look. These quicklooks are transmitted via UMTS to the LOZ computer. Each quick-look also displays the position of both flight corridors for landing aircraft. Thus, it is possible to roughly check if the predicted minimum separation times are correct: the vortices visible in the LIDAR quick-look should not reside within the flight corridors when the forecast system allows for the next a/c to enter the control gate. Fig. 3. Sketch of instrumentation set-up at Frankfurt Airport, DLR and ONERA only. x ac, z ac denote the distance to touchdown zone and the height of landing aircraft in the three vertical scan planes (bold numbers refer to departing a/c); r is the distance to the LIDAR and ε is the required maximum elevation angle for the laser beam to capture the aircraft. Figure 4 shows the complete measurement site with the positions and scan planes of all three lidars. Figure 5 shows pictures taken during the installation of the SODAR / RASS and the USA by Fa. Metek at the north-eastern part of the airport and the LOZ-PC in the DWD observer house. 35

39 Fig. 4. Full Instrumentation set-up at Frankfurt Airport. Fig. 5. Installation of equipment at Frankfurt Airport on 18. December

40 Preliminary Overview and example of measurements for the CREDOS scenario The EDDF1 and FRA2006 campaign is over now for DLR except for the comparison with ONERA s LIDAR, which is scheduled for 25 to 28 of February. In the measurement period between the and , the CREDOS scenario has been measured on five days: 21/22 Dec. 2006, 23/24/25 Jan. and 16/17 Feb The three days in January suffer from high winds and strong turbulence; those data are not of sufficient quality for analysing wake vortex physics and checking/adapting the real-time models. On the other 4 days the wind was still significant but the quality of most measured wakes (and the period of vortex tracking) is probably good enough for wake vortex physics and checking/adapting the real-time models: High quality measurements of wakes of about 130 to 150 heavy aircraft are available for that purpose (TBC!!). Figure 6 depicts a series of 6 quick-looks as measured on 17. Feb between 09:04:00 UTC and 09:04:40 UTC. Significant wind shear as well as a slowly descending vortex pair can be identified. The vortices have been shed by a heavy aircraft (type tbd) taking off on runway 07L. 37

41 Fig. 6. LOS velocity as measured by LIDAR in steps of 8 seconds with signatures of wind shear and a slowly descending and weakening wake vortex pair (CREDOS scenario). 38

42 Annex 7 Structure of data and data files delivered by DLR Thomas Gertz (DLR), April 17th, 2007 Co-ordinate system Co-ordinate system in red as used by LIDAR and SODAR/RASS/USA to determine wake positions (red y,z) and the wind components parallel (red u) and perpendicular (red v) to the runway. Origin (red x=y=0) is at the intersection of the lidar scan plane with the extension of centreline of runway 07L, see sketch below. The co-ordinate system in black defines the meteorological wind directions as used in NOWVIV. Vertical co-ordinates are pointing upwards. Measurement geometry at Frankfurt Airport for CREDOS, EDDF1 campaign. 39

43 Wake Data The CREDOS scenarios during the campaign took place on 7 days: 21/22 Dec. 2006, 23/24/25 Jan. and 16/17 Feb (see _FRA2006+EDDF1_report.doc). For these days, LIDAR data of wake vortices from departing heavy aircraft are available (at different levels of quality). File names of the wake data are termed: lidar_a/c-type_yymmdd_hhmmssutc.dat where a/c-type - e.g. A346 for A , B744 for B yy mm dd hh mm ss - year - month - day - hour - minute - second Each file contains a header declaring a/c type, used rw (07L or 07R), yymmdd_hhmmssutc (time of first measurement) and then 7 columns of data: time vortex age in s, is the time after first measurement (hence, first value always 0 s) y l z l Γ l y r z r Γ r lateral position of left vortex in m vertical position of left vortex in m circulation averaged over radii of 5 to 15 m of left vortex lateral position of right vortex in m vertical position of right vortex in m circulation averaged over radii of 5 to 15 m of right vortex Co-ordinate system in use is as sketched above. 40

44 Wind Data From 20/12/2006 until 28/02/2007 vertical profiles of the three wind components and temperature have been measured by SODAR/ RASS and a USA. Each 10 minutes (= averaging time), a data file is produced which contains data at 10, 40, 60, 80, 100,, 400 m (max) altitude above ground. File names of the profiles are termed: sdr_cl_yymmdd_hhmm00utc.dat where yy mm dd hh mm - year - month - day - hour - minute Each file has 11 columns containing the following data: height (m) wind velocity (m/s) wind direction (deg) standard deviation of vertical wind component (m/s) parallel wind component (m/s) cross wind component (m/s) turbulent kinetic energy (m^2/s^2) virtual temperature ( C) virtual potential temperature (K) vertical wind (m/s) turbulence energy dissipation rate (m2/s3) Orientation of cross-wind and runway parallel wind components can be found in the sketch above. 41

45 File example for a SODAR/RASS/USA profile: sdr_cl_061221_114000utc.dat e e e e e e The content signifies data not valid / not available. All profile files are stored in single tarred and zipped data file: sdr_cl_ tar.gz. This data set (appr. 7.5 MByte) will be made available to partners upon request. Note that there are periods where entire profiles are missing or incomplete. However, for the CREDOS scenarios, 21/22 Dec. 2006, 23/24/25 Jan. and 16/17 Feb (see _FRA2006+EDDF1_report.doc), the SODAR/ RASS/USA set should be complete. 42

46 NOWVIV data base The DLR weather forecast model system NOWVIV has predicted vertical profiles of meteo data for Frankfurt Airport for a time frame from 6 December 2006 to 28 February 2007 in 10 min increments at 25 glide slope locations for approaches on the 07 and 25 runways. File names of the profiles are termed: profil_xx_yyyymmddhhmm, where xx yyyy mm dd hh mm - profile number denotes the location along the glide slope - year - month - day - hour - minute Thus, for one instant of (forecast) time 25 data files exist (for the 25 glide slope locations). There are 2 NOWVIV runs per day that are launched at 0:00 and 12:00. The prediction horizon is always 24 hours and each data file starts with a 6-line header. Example: Date: UTC. MM5 run: UTC + 11 hrs 50 Min. Point 25, z= 112.0m, lat,lon= , p= mb blh(m) reg() hol() ust(m/s) shf(w/m^2) lhf(w/m^2) net(w/m^2) E levels Interpretation: k z(m) u(m/s) v(m/s) w(m/s) rho(kg/m3) thv(k) tke(m2/s2) edr(1.e-3 m2/s3) p(hpa) Date: MM5 run: Point: date and time of the current profiles start time of weather predictions + time since start of weather predictions profile locations are numbered from 1 to 25, where point 1 is the first point in the southwest, point 25 the last point in the northeast, point 13 therefore in the middle, at airport center, defined as latitude, longitude for Frankfurt airport. Distance between profiles is 1 nm. Point 14 is close to the local operation center (LOZ) and the Sodar/Rass/Usa measurement site. z: model surface height above sea level [m] lat,lon: latitude and longitude [deg] p: mean sealevel pressure [mbar] blh: boundary layer height [m] reg: boundary layer regimes [] (1-4) defined within MM5: 1=stable, 2=stable (mechanically driven turbulence), 3=unstable (forced convection), 4=unstable (free convection) hol: boundary layer height (pbl) / l(monin-obukhov length) [] ust: shf: lhf: net: levels: friction velocity [m/s] at surface sensitive heat flux [W/m^2] at surface latent heat flux [W/m^2] at surface net radiation(w/m^2) at surface total number of vertical model levels included in data sheet 43

47 The block of data is described by the 6 th header line: k: number of vertical model level [-] z: height above sea level [m] u: wind velocity from west to east [m/s] v: wind velocity from south to north [m/s] w: vertical wind velocity, upwards direction positive [m/s] rho: thv: tke: edr: air density [kg/m^3] virtual potential temperature [K] turbulent kinetic energy [m^2/s^2] eddy dissipation rate [1.E-3 m^2/s^3] p: pressure [mbar] NB for the use of EDR data from NOWVIV output: In P2P predictions EDR from direct NOWVIV output is only used for altitudes above 100 m. Below EDR has been derived from TKE following the relation given by Donaldson & Bilanin (1975): EDR=TKE^1.5/311m. In this relation the one-half integral scale of atmospheric turbulence is kept constant in order to avoid unrealistically large EDR values caused by overestimated turbulence levels close to the ground. Full data file example: profil_19_ (last NOWVIV profile for EDDF1 campaign) Date: UTC. MM5 run: UTC + 24 hrs 00 Min. Point 19, z= 129.3m, lat,lon= , p= mb blh(m) reg() hol() ust(m/s) shf(w/m^2) lhf(w/m^2) net(w/m^2) E levels k z(m) u(m/s) v(m/s) w(m/s) rho(kg/m3) thv(k) tke(m2/s2) edr(1.e-3 m2/s3) p(hpa)

48

49 Annex 8 Status of Measurement Campaign EDDF2 at Frankfurt Airport Jens Konopka (DFS), March 13th, 2007 Aircraft track information example: WTR RASS data example: 46

50 Surface observation data Treatment of LIDAR / Wake Vortex data 1. Work around: 47

51 2. Input: 3. Output: 48