June 2001 

NASA/TM-2001-211027 

Description of Selected Algorithms and 

Implementation Details of a ConceptDemonstration Aircraft VOrtex Spacing 

System (AVOSS) 

David A. Hinton 

Langley Research Center, Hampton, Virginia 
The NASA STI Program Office ... in Profile 

Since its founding, NASA has been dedicated 

to the advancement of aeronautics and space 

science. The NASA Scientific and Technical 

Information (STI) Program Office plays a key 

part in helping NASA maintain this important 

role. 

The NASA STI Program Office is operated by 

Langley Research Center, the lead center for 

NASA’s scientific and technical information. 

The NASA STI Program Office provides 

access to the NASA STI Database, the largest 

collection of aeronautical and space science 

STI in the world. The Program Office is also 

NASA’s institutional mechanism for 

disseminating the results of its research and 

development activities. These results are 

published by NASA in the NASA STI Report 

Series, which includes the following report 

types: 

• TECHNICAL PUBLICATION. Reports 

of completed research or a major 

significant phase of research that 

present the results of NASA programs 

and include extensive data or theoretical 

analysis. Includes compilations of 

significant scientific and technical data 

and information deemed to be of 

continuing reference value. NASA 

counterpart of peer-reviewed formal 

professional papers, but having less 

stringent limitations on manuscript 

length and extent of graphic 

presentations. 

• TECHNICAL MEMORANDUM. 

Scientific and technical findings that are 

preliminary or of specialized interest, 

e.g., quick release reports, working 

papers, and bibliographies that contain 

minimal annotation. Does not contain 

extensive analysis. 

• CONTRACTOR REPORT. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees. 

• CONFERENCE PUBLICATION. 

Collected papers from scientific and 

technical conferences, symposia, 

seminars, or other meetings sponsored 

or co-sponsored by NASA. 

• SPECIAL PUBLICATION. Scientific, 

technical, or historical information from 

NASA programs, projects, and missions, 

often concerned with subjects having 

substantial public interest. 

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign 

scientific and technical material 

pertinent to NASA’s mission. 

Specialized services that complement the 

STI Program Office’s diverse offerings 

include creating custom thesauri, building 

customized databases, organizing and 

publishing research results ... even 

providing videos. 

For more information about the NASA STI 

Program Office, see the following: 

• Access the NASA STI Program Home 

Page at http://www.sti.nasa.gov

• E-mail your question via the Internet to 

help@sti.nasa.gov 

• Fax your question to the NASA STI 

Help Desk at (301) 621-0134 

• Phone the NASA STI Help Desk at (301) 

621-0390 

• Write to: 

 NASA STI Help Desk 

 NASA Center for AeroSpace Information 

 7121 Standard Drive 

 Hanover, MD 21076-1320
National Aeronautics and 

Space Administration 

Langley Research Center 

Hampton, Virginia 23681-2199

 

June 2001 

NASA/TM-2001-211027 

Description of Selected Algorithms and 

Implementation Details of a ConceptDemonstration Aircraft VOrtex Spacing 

System (AVOSS) 

David A. Hinton 

Langley Research Center, Hampton, Virginia 
Available from: 

NASA Center for AeroSpace Information (CASI) National Technical Information Service (NTIS) 

7121 Standard Drive 5285 Port Royal Road 

Hanover, MD 21076-1320 Springfield, VA 22161-2171 

(301) 621-0390 (703) 605-6000 
Description of Selected Algorithms and Implementation Details of a 

Concept-Demonstration Aircraft VOrtex Spacing System (AVOSS) 

A ground-based wake vortex system was developed to demonstrate the feasibility of providing weatherdependent wake vortex spacing criteria for Air Traffic Control use. The system provides automated 

collection of relevant weather data, prediction of wake vortex behavior, derivation of safe wake vortex 

spacing criteria, estimation of system benefit, and comparison of predicted and observed wake vortex 

behavior. This report describes many of the system algorithms, features, limitations, and lessons learned, 

as well as suggestions for system improvements. A condensed version of the development lab book is 

provided along with samples of key input and output file types. This report is intended to document the 

technical development process and system architecture, and to augment archived internal documents that 

provide detailed descriptions of software and file formats. 

Scope and Development Approach

The AVOSS hardware and software were designed and developed to provide a concept feasibility 

demonstration of a spacing system concept. The demonstration AVOSS was developed to fulfill several 

concept demonstration and research requirements: 

1. Automate assimilation of relevant weather and aircraft information for wake prediction. 

2. Convert wake predictions to spacing values and estimated runway throughput. 

3. Operate fully automated, without human intervention to screen data or provide real-time decisions. 

4. Automate collection of performance statistics and error (diagnostic) statistics. 

5. Provide adequate flexibility for iterative system implementation as lessons were learned in field 

operations and as subsystems matured. 

6. Provide flexibility in field operations, for example to relocate a wake sensor. 

7. Operate with specific field sensors deployed, and operate in batch mode for sensitivity studies. 

The demonstration system was not required to provide an information interface to Air Traffic Control nor 

possess the reliability or safety feedback mechanisms required for actual spacing reduction. The system 

design process was complicated by the lack of specific requirements. Since no wake spacing system has 

been produced or used operationally in the U.S., specifications such as altitude and weather domains to be 

considered, sensor resolution and accuracy, system update rates, and ATC information requirements were 

not available. Even with respect to known functional requirements, such as wake vortex drift and decay 

prediction, the state of the art did not allow specification of a weather system (parameters, resolution, 

accuracy required) to produce the needed inputs. The development approach taken was one of iterative 

builds, learning, and refinement. 

Available knowledge at the project outset was used to field an initial system for the purposes of testing 

sensors, collecting a complete aircraft/wake vortex/weather data set for numerical model validation, and 

answering subsystem performance issues needed to perform more detailed system design. The resulting 

deployments1,2,3 to the Memphis International Airport in 1994 and 1995, were optimized for scientific data 

collection and testing of advanced Continuous Wave (CW) lidars for wake detection and tracking. The 

meteorological instrumentation was assembled in cooperation with NOAA, MIT Lincoln Laboratory, 

Volpe National Transportation Systems Center, FAA, and others. The resulting instrumentation was the 

most comprehensive used to date for wake vortex studies. No AVOSS system was present at those 

deployments and data was reduced and analyzed after the fact. Data from the Memphis deployments were 

used in the validation of numerical wake vortex simulation models4

, for evaluating existing and new 

algorithmic wake vortex prediction models5,6, refining and validating planetary boundary layer simulation 

models7

, and refinement and selection of sensors for use in AVOSS. 

The Memphis field systems were moved to the Dallas-Fort Worth International Airport (DFW) in 1997 for 

integration into the initial AVOSS. Dallas was chosen due to significant daytime traffic, presence of the 

Center-TRACON Automation System (CTAS) and an Integrated Terminal Weather System (ITWS), and 

adequate real estate for flexible sensor siting. Components added for the DFW tests (not present at 
2 

Memphis) were a pulsed wake vortex lidar8 developed at NASA Langley Research Center, two identical 

acoustic sodars to replace a borrowed sodar at Memphis, and the networks required for real-time linkage of 

all systems to a central location to support AVOSS operation. The DFW AVOSS systems performed two 

separate functions: (1) gathering additional scientific data for validation of numeric wake vortex and 

planetary boundary layer models and for wake algorithm development, and (2) operation and refinement of 

an automated wake vortex spacing system. The two functions frequently required different data 

characteristics. For example scientific use of data for wake model development required that the wind 

values during a wake lifetime, typically 1 to 2 minutes, be quantified near the wake location, while AVOSS 

requires a statistical description of a mean wind and confidence intervals over a period of about 30 minutes. 

Scientific model validation also required dedicated rawinsonde balloon launches during deployments, while 

AVOSS did not use that data set at all. As a result the field sensors represent a superset of those sensors 

required by an operational system, but the presence of those sensors provided additional redundancy for 

AVOSS operations, and the archived data sets are available to investigate alternative processing methods. 

The DFW installation was used from late 1997 through 2000 to incrementally test the AVOSS concept, 

refine the concept and subsystems, and perform a system capability demonstration in July 2000. It was 

judged to be more efficient to begin operations with existing maturity levels of each component, and then 

learn which functions were most critical to system operation and performance prior to focusing on specific 

subsystem refinements. The demonstrated system contains an initial implementation of most functions 

required for an operational system, but without the robustness needed for an operational system. 

General Design Architecture

Software Functions: 

Numerous interrelated functions were implemented within AVOSS, many of which are not required in 

wake vortex sensor installations deployed solely for research purposes. These functions include: 

1. Definition of approach corridor lateral and vertical limits in an absolute runway coordinate system. 

2. Definition of specific locations along the corridor, called windows, to include the window location 

in space, glide slope height, and vertical/lateral corridor limits at that window. Wake vortex 

behavior predictions and observations are only made at these discrete window locations. 

3. Ability to add window locations at run time, to accommodate new wake sensor locations or other 

factors. 

4. Maintain a database of aircraft representing the arrival flow, with all information needed to 

estimate both initial wake state and final approach speed. The database represents an assortment 

of large and heavy aircraft types, including estimated “worst-case” types within a category. 

5. Accept weather profiles (weather parameters vs. height) and associate weather parameters with 

each approach corridor window based on the glide slope altitude. An assumption is made 

regarding spatial homogeneity of weather statistics, i.e. mean wind over a 30-minute period, in 

that the wind statistics at a specified distance from the runway may be found by finding the glide 

slope height at that distance and selecting the weather statistics from a single profile at that 

altitude. 

6. Predict wake vortex behavior at each corridor window for each aircraft. 

7. Estimation of wake prediction confidence intervals to determine worst-case behavior. 

8. Compare wake behavior to corridor dimensions and a wake demise definition to derive the 

minimum time spacing required behind each aircraft at each window. 

9. Provide automated quality assessment of derived weather profiles and disable, or lock out, the use 

of wake drift when confidence is low in the crosswind parameter. Wake lateral drift is not used 

for spacing reductions when the crosswind standard deviation exceeds a threshold. 

10. Compute the spacing requirement at each window (window spacing). Using estimated aircraft 

speeds and wind, calculate spacing required at the top of the approach (approach spacing) required 

to meet all constraints along the approach. Convert aircraft type-based data (i.e., wakes behind a 

B-737) to aircraft category-based data (i.e., separation behind large aircraft). 
3 

11. Limit spacing values to fall between a minimum value, dictated by runway occupancy time, and 

an upper value dictated by current spacing criteria. The lower limit is needed to avoid providing 

absurd spacing criteria such as 1⁄2 mile when wakes are rapidly drifting or decaying, and the upper 

limit need will be described below. 

12. Calculate estimated runway arrival rate using these separation values and airport traffic mix, or 

ratio of small, large, and heavy aircraft. Estimate the base arrival rate using current static spacing 

criteria to estimate the increase due to AVOSS. 

13. Detect and track wake vortices in a runway coordinate system (not local axis system at the sensor) 

and in absolute time from aircraft passage. This requires data to augment base sensor data since 

the wake lidars cannot be expected to detect aircraft passages from skin-hits of the lidar beam. 

14. Compare predicted and observed wake behavior to detect system prediction errors and accumulate 

performance statistics. This function would be enhanced to a warning, or safety monitoring, 

function in an operational system. 

15. Provide logging of results and displays for real-time and post-event interpretation of results. 

The demonstration AVOSS was intended as a proof-of-concept system and a tool for performance and 

tradeoff studies, not as an operational system. Also, since system design requirements did not exist at the 

beginning of the project, an iterative design and build process was followed to determine essential system 

functions and refine those most critical to performance. As such, the functions listed above are only 

developed to the degree required for research and demonstration purposes. Suggestions for future system 

improvement are provided in Appendix A. 

Software Architecture: 

The system was designed as a core set of functions and software, applicable to the general AVOSS concept, 

and a shell, or interface, required to run the core with the specific sensors installed at the DFW airport. 

Figure 1 depicts the general architecture. Information is passed from one process to another via files on 

networks or shared disk space. The core modules accept three basic weather information files, an aircraft 

specification data base, and a parameter file describing run configuration, and then computes wake 

behavior predictions, derives spacing criteria and throughput, and writes diagnostic log files. Examples of 

the aircraft database, parameter file, and output spacing files are given in appendices B and C. The three 

weather files provide vertical profiles of wind, turbulence, and temperature. This core code is suitable for 

field use, for batch runs with archived input data, or with input data created to investigate behavior in 

specific situations. The first method of batch running is useful for investigating long-term system 

performance with archived data for variations in system algorithms or parameters9

, while the latter is useful 

for sensitivity studies10 to investigate the relative contributions of the various inputs. 

The shell modules perform functions more specific to the DFW installation, such as derivation of the three 

weather file types from the specific sensor compliment used and comparison of predicted wake behavior to 

that observed by the wake sensors. Figure 2 shows a detailed breakdown of the weather data flow. The 

wind profile is created by a process managed by MIT Lincoln Laboratory that combines data from two 

acoustic sodars, a radar profiler, wind sensors along a 45-meter tall tower, and two nearby Terminal 

Doppler Weather Radar (TDWR) systems11. The turbulence profile is generated using eddy dissipation rate 

calculated from 10-Hertz sonic anemometer data at the meteorological tower, other tower data, and 

atmospheric similarity theory12. The thermal profile is calculated from tower temperature measurements 

and temperature aloft data from the Radio Acoustic Sounding System associated with the radar profiler. 

Each process includes quality checks of the input data and quality indicators in the output files. An 

example of the flexibility of this approach (separation of software into a core and shell) was operation of 

the AVOSS driven only by pulsed-lidar data at the JFK International Airport9

 in 1998. In this test the 

AVOSS core code was unchanged, but the pulsed lidar was used to derive a wind and turbulence profile 

normally provided by the shell code and DFW sensors. These input files were provided to AVOSS, along 

with a static neutrally-stable thermal profile, to drive wake predictions. 
4 

Description of Selected Algorithms

This section will provide a description of several internal algorithms within the AVOSS. Not described is 

the wake predictor algorithm. Wake predictor algorithms are described in references 5, 6, 13 and 14. The 

algorithms to be discussed here are dimensions of the AVOSS corridor, calculation of approach spacing 

from individual window spacing, definition of weather quality requirements for use in spacing reduction, a 

lockout feature that prevents use of lateral drift in low wind, throughput calculation, and scoring of wake 

predictions with wake observations. 

AVOSS Corridor Dimensions 

The coordinate system used to describe the approach corridor, wind values, and wake locations is shown in 

Figure 3. The origin is fixed at the center of the runway threshold, the X-axis extends along the localizer 

and is positive toward the outer marker, the Y-axis extends laterally to the right, as viewed by an 

approaching aircraft, and Z is positive upwards. When runway-axis wind values are provided, a positive 

longitudinal wind is a headwind (positive X-derivative of the position of an air particle) and a positive 

crosswind is one that blows from left to right of an approaching aircraft (positive Y-derivative). 

The AVOSS corridor has three major components, the region close to the ground where the wakes are 

interacting with the surface, the area above this zone and where aircraft are on glide-slope, and the top-ofapproach. The largest zone is between the glide-slope intercept and the region of ground effect on the 

wake. In this zone wakes can vacate the corridor either via lateral drift, vertical sinking below the glideslope, or decay. A corridor floor is established, below which wakes are not considered a factor to following 

aircraft. The floor is defined such that a following aircraft at the floor would either be below glide-slope, to 

the extent that a glide-slope deviation indicator in the cockpit would show “full-scale” error, or at higher 

altitudes the altitude deviation from assigned altitude would be on the order of 60 meters (at least 200 feet). 

The lateral limits are set in this region to protect an aircraft flying a 3-standard deviation localizer error, as 

determined from previous flight technical error data collected at two major airports15. 

As an aircraft approaches the ground, the wakes become affected by the earth’s surface. Wake sink rate 

slows and stops near the ground, generally asymptoting to an altitude between about one-half and threequarters the wingspan of the wake-generating aircraft16,17. Wakes generated at lower altitudes tend to rise 

to an altitude of one-half span. Since the ground interferes with wake sinking, it is not feasible to vertically 

separate aircraft from wakes near the ground. In this region the AVOSS corridor floor is defined to be at 

ground level, which effectively removes wake vertical position from the spacing calculations. The altitude 

of the transition from no vertical motion allowance to a useable corridor floor is at an aircraft altitude of 

about 61 meters (200 feet). The rationale is that the largest span aircraft today (65 meters or 215 feet) will 

generate wakes that will tend to seek a minimum altitude of 100 feet, and the corridor option chosen 

provides an altitude buffer of 100 feet above such a wake. 

The top of the approach is unique from one perspective. While on glide slope the aircraft are flying with 

precise lateral and vertical guidance. Prior to intercepting the glide slope, however, the aircraft are 

generally flying an assigned altitude, but with less precise lateral guidance prior to intercepting the 

localizer. At the top of the approach, defined to be the glide-slope intercept altitude, the corridor is 

artificially widened to a large value to prevent spacing reduction due to lateral drift. At this altitude the 

aircraft spacing is calculated from wake sink and decay only, implying that the spacing provided is safe to 

use while intercepting the localizer. The mechanism of implementing this feature proved awkward for later 

sensitivity studies, and future implementations should instead consider a logic lockout of drift at specific 

altitudes rather than an arbitrary corridor width change. 

The following equations provide the dimensions of any particular corridor window, in terms of Ylim (lateral 

distance of the corridor side from the localizer, meters), Zlim (altitude of the corridor floor, meters). The 

window information is calculated as a function of the window distance from the runway threshold (X). 
5 

Base equations: 

The altitude of the nominal flight path is assumed to be the glide slope of the instrument landing system. 

Given that GSA is the glide slope angle (typically 3 degrees), and that the subscripts FP and GPIP refer to 

“flight path” and “glide path intercept point” on the runway surface (typically negative 305 meters), the 

altitude (Z) of the flight path can be calculated from the X coordinate by: 

Z (x X )tan(GSA) FP = − GPIP (1) 

A transition point on the approach is used defined the location where the corridor floor transitions from a 

specified height below the glide slope to ground level. Between this point and the runway the corridor 

floor is at ground level, preventing wake sinking motion from being used to reduce spacing. 

) tan( )

60.9756 ( GSA

XT = Integer X GPIP + (2) 

In this equation the constant 60.9756 is the flight path height in meters at the location of the transition 

point. 

Corridor lateral limit equations: 

The corridor lateral limit is represented by Ylim, which is the absolute value of the Y coordinate of corridor 

walls. A Ylim of 50 meters indicates that the corridor is 100 meters wide centered on the X axis. Corridor 

limits are calculated for three discrete regions from the runway. 

10000

45.73 0.012695( )

45.73

lim

lim

lim

≥ =

≤ < = + −

< =

If x X Y

If X x X Y x X

If x X Y

SP

T SP T

T

 (3) 

In these equations XSP is the coordinate of the “spacing point” used for calculation of the top-of-approach 

spacing. In the current system this point was at the assumed glide slope intercept point of 600 meters 

altitude and 11128 meters from runway threshold. The step change in corridor width at the spacing point 

was used to disable lateral wake drift as a spacing reduction factor beyond the glide slope intercept. In the 

absence of this step the corridor would be about 352 meters wide at that point (176 meters each side of 

centerline). 

Corridor floor equations: 

Previous reports18 described two corridor floor options. Only option 2 was used in the final years of the 

AVOSS project. The floor equations are: 

(21.3 0.00471( ))

(21.3 0.00471( ))

0

lim

lim

lim

SP FP SP T

T SP FP T

T

If x X Z Z X X

If X x X Z Z x X

If x X Z

≥ = − + −

≤ < = − + −

< =

 (4) 

These equations state that the corridor floor is at ground level (Z = 0) from the runway to the transition 

point, then steps to an altitude of 21.2 meters below flight path, increases in distance below flight path out 

to the glide slope intercept, then remains at a constant altitude. At and beyond the glide slope intercept in 

the current implementation the corridor floor is 69.7 meters (229 feet) below the flight path. 
6 

Objects within the AVOSS core code (implemented in C++) represented approach corridor windows. A 

default set of 6 windows is created when the program initializes the approach. These windows are located 

at X = 0, 430, 843, 982, 5000, and 11128 meters. The window at 843 meters is at the location where the 

corridor floor steps from ground level to a calculated distance below glide slope, and the window at 982 

meters was co-located with the windline wake sensor deployed by Volpe. The last window, at 11 km from 

the runway, is at the top of approach for a typical approach scenario, not for the published approach to 

runway 17C. AVOSS has the ability to dynamically create other windows as required to accommodate the 

changing location of wake sensors. Typical locations of the additional windows at the system 

demonstration were X = 84 meters (Continuous Wave (CW) Lidar location), and X = 1080, 1702, and 2262 

meters (pulsed Lidar scan locations). 

Approach Spacing Calculation 

Several steps are followed to compute the approach spacing from the wake predictions. Figure 4 shows the 

flow of information in the AVOSS software when estimating wake behavior and spacing. The steps are: 

1. The shell code invokes AVOSS with a weather data set and aircraft and parameter file data. The 

three weather files describe vertical profiles of 30-minute statistics of runway axis winds (cross 

wind and head wind), turbulence, and temperature. The wind values include both the mean and 

standard deviation of the 30-minute wind values. 

2. Use weather and aircraft data to compute the wake trajectories of each aircraft at each approach 

window. Run the wake predictor with three crosswind values (mean, mean – standard deviation, 

mean + standard deviation) to predict a range of wake drift behaviors. In certain situations where 

the drift factor cannot regulate the spacing, only the mean wind run is made. 

3. Compare the time history of each wake track to the window dimensions to derive a vertical and 

horizontal residence time of the port and starboard wake, for each aircraft at each window. Of the 

three wake predictor runs made in step (2), only the largest drift time is used. A demise time value 

is also determined by comparing the predicted wake strength history to a wake demise value. If a 

particular time value cannot be determined, that value is filled with the value of 9999. 

4. Apply lockout conditions to the time values. For example, if the crosswind is low relative to the 

standard deviation, as described below, the lateral residence times of both wakes are set to the 

value 9999. Similarly, low confidence in the weather data quality can reset times to 9999 in the 

residence time computation. 

5. Combine the wake vortex lateral, vertical, and demise times into a wake pair residence time value, 

using the equation: 

( ( , , ), ( , , )) pair Max Min PL PV PD Min SL SV SD τ = τ τ τ τ τ τ (5) 

where the values are time (seconds) and the subscripts P, S, L,V, and D refer to port, starboard, 

lateral, vertical, and demise, respectively. In words, the equation says that the port wake is no 

longer a factor when any of its factors (lateral, vertical, or demise) removes it from the corridor, 

and that the wake pair is no longer a constraint when both the port and starboard wake are no 

longer in the corridor. 

6. Use wind and aircraft speed data to predict the time required at the top of the approach that is 

required to meet the constraint at the window. Wind data (head wind component) is taken from 

the weather profiles and a typical aircraft speed is taken from an aircraft data base file. The point 

at the top of the approach at which the spacing is calculated is referred to as the “spacing point”. 

The top-of-approach requirement is useful from several standpoints; (a) it integrates the wake 

constraints at each window and provides a single value that would be useful to air traffic control, 

(b) it allows a system-level assessment of benefits, since reduced spacing at one location does not 

affect overall spacing unless that location was constraining the approach, and (c) provides an input 

to a simple approach throughput calculation. Note that the speed of both the generator and 

follower aircraft are required for this process. Since the type of aircraft to follow a particular 

aircraft is not known in advance, and since small aircraft are not included in the aircraft data base 

file, a conservative approach is to assume the maximum speed of each follower category in this 
7 

calculation. The maximum approach speed assumed for each follower category is included as a 

parameter in the aircraft data base file. 

7. The top-of-approach spacing values provided in step 6 are time values and are calculated for each 

aircraft in the data base file and for each approach window. The time values from each window 

are used to determine a worst-case time for approach spacing and then the approach spacing 

criteria are converted to distance values. For each generator aircraft the spacing point time 

requirement behind it is calculated by: 





















− +

− −

− +

− = +

= −

=

( ) 2

1

( )

( ) 2

1

( )

max

,

1

0

F SP n

SP n

G SP n

SP n

pair n

n N

n

SP

V HW HW

X X

V HW HW

X X

τ MAX τ (6)

where n represents the individual approach windows, τpair,n is the wake pair residence time at 

window n, X is the runway x-axis coordinate distance (distance from runway threshold), HW is 

the headwind at the location given, Vg is the estimated airspeed of the generator aircraft, Vfmax is 

the maximum estimated airspeed of the aircraft in the follower category of interest, and subscripts 

SP and n refer to the location of the spacing point and of the window generating the value of τpair,n. 

The headwind at a given location is determined from the glide slope altitude at that location and 

the wind data at that altitude in the wind profile. The headwind at the spacing point and the 

window are averaged as an approximation to the average headwind between those two locations, 

and then used to convert airspeed to ground speed. Effectively, this equation is adjusting the wake 

time requirement at window n by the difference in the time required by the lead and the follower 

aircraft to fly from the spacing point to the window, than taking the largest of the adjusted window 

time from all windows as the top-of-approach requirement for that aircraft pair. For each 

generator weight category (large and heavy) AVOSS determines the worst-case time behind the 

individual generator aircraft. For example if 5 “large” aircraft are in the aircraft data base, the 

largest of 5 aircraft approach spacing values will be found to determine the following time behind 

large aircraft. Figure 5 shows how individual window and aircraft type residence times are used to 

generate a category-based top-of-approach spacing. In this example there are 3 windows (at X = 

0, 900, and 11000 meters), 2 large aircraft types (L1 and L2) and 2 heavy aircraft types (H1 and 

H2) in the wake predictor database, where L1 is a particular type such as a Boeing 737. Assumed 

approach speeds are 60 m/s for L1, 70 m/s for L2, 70 m/s for H1, and 80 m/s for H2. No small 

aircraft are in the database, but the assumed maximum approach speed for all small, large, and 

heavy aircraft is 60, 70, and 80 m/s respectively. Headwind is zero at all altitudes in this example. 

The column “wake residence time” provides residence time data for each aircraft-window 

combination derived from wake predictions and corridor definitions. The “delta time” column is 

provided by the 2nd and 3rd terms inside the brackets of equation 6 and is computed for each 

weight category that can trail a given aircraft type. The “time adjusted” column represents all 

terms in the brackets of equation 6. For example a heavy aircraft trailing a type L1 must be 90.8 

seconds in trail at the spacing point in order to meet a 45-second requirement at window 1. The 

“maximum” column represents the output of equation 6, the spacing point time that meets all 

window requirements. Finally the category-based output reduces the 3xn matrix (3 trail categories 

and n generator types) to a 3x2 matrix in this example. In the actual system the B-757 is treated as 

a 4th generator category and small generator data is provided using FAA provided criteria. Note 

that aircraft types must not be combined until after determining the top-of-approach criteria. For 

example if the window 1 residence time values for both large aircraft were combined initially, the 

worst case value of 65 seconds would be used to provide the worst-case time adjustment of 26.2 

seconds for a top-of-approach value of 91.2 seconds for large aircraft following large aircraft, 

while only 71.2 seconds is actually required. Note also that the final approach spacing value given 

is not dependent on just one window. In some cases window 1 set the approach spacing values, in 

other cases window 3 drove spacing. 
8 

8. Convert time values to distance values. This final step is performed primarily for output display 

purposes. Time is used internally to represent spacing. While all internal calculations are 

performed in metric units, spacing distance is converted to nautical miles for display. 

Note above that the time value of 9999 is used to denote residence time factors that cannot be quantified. 

This value is used both in wake predictions and in wake observations. For example the wake predictor 

algorithm terminates at a preset elapsed time, typically 120 to 180 seconds. If termination takes place prior 

to the wake drifting laterally from the corridor, then it is not possible to define a lateral residence time and 

that value is set to 9999. If a wake sensor does not observe a wake to sink below the corridor floor then no 

vertical residence time can be defined and the value is reported as 9999. Data uncertainties must be 

accommodated in the design, and the fact that a wake is not observed to exit the corridor is a different 

statement than saying the wake was observed to remain in the corridor. Frequently wake sensors will lose a 

wake track prior to a wake exiting the corridor, for example due to wake demise. In many cases the wind 

line did not detect wakes until they had already drifted outside the corridor, since wakes had to sink close to 

the wind line for detection. Since the transition from inside the corridor to outside the corridor was not 

observed in these cases, lateral residence time was reported as 9999. The ability to disable any predicted 

wake factor from reducing spacing was implemented in software by resetting predicted residence times for 

that factor to 9999. For example to ignore lateral drift when calculating spacing, as is done when cross 

wind variability is high relative to the cross wind value, any predicted drift time is reset to 9999 prior to 

combining with the other factors and translating to distance. When the individual window constraints are 

used to derive an approach constraint and converted to distance, the value 9999 is treated as other time 

values, and produces a “very large” spacing value that is much larger than current FAA criteria. Since this 

value indicates uncertainty or lack of knowledge, rather than an actual prediction of a 9999-second 

residence time, the spacing values must then be limited to maximum values based on current FAA criteria. 

Since AVOSS does not predict where a wake will actually go, but rather calculates a range of possible 

locations given various system uncertainties, the system does not support providing spacing values larger 

than the current criteria. In practice the use of this value had two separate meanings, which caused 

difficulties. A time of 9999 could mean that either the value could not be determined, or that the wake was 

still a factor at the longest time considered. For example an observed drift time of 9999 could result either 

from a wake decaying in only 20 seconds, prior to leaving the corridor, or from a wake that took 3 minutes 

to decay while remaining on the localizer. Future software versions should adopt another technique to 

differentiate between invalid data and factors that cannot be fully quantified but indicate long-lived wake 

times. 

Weather Quality Requirements 

An operational system using AVOSS technology would require self-test and data quality monitoring 

capability. A first approximation to this capability was provided in the demonstration system. The 

operation of a real-time wake system provided a requirement on the weather system that was not present for 

general scientific use. In scientific wake studies data is reported as it is collected, in that missing data is 

reflected in the data files with missing values. Since AVOSS can create a prediction window at any 

altitude, and since wake predictions must be made at all windows to produce a final output, the weather 

system was required to provide AVOSS data files that had no missing data at any altitude from the surface 

to a minimum height of 600 meters, which was the assumed glide slope intercept altitude. The weather 

system provided this requirement by combining data from several sensors, to fill in altitude gaps that might 

be created by one sensor, and through data interpolation and conservative extrapolation as required. 

Since the data fill-in creates the possibility of making wake predictions that are based on poor weather 

measurements, an automated quality process was implemented. This process required each of the three 

weather file types (wind, turbulence, and thermal) to contain a set of quality flags that described sensor 

health and the weather profile confidence. The AVOSS then tested the data quality and prevented the wake 

predictions from being used to reduce spacing in specific conditions. A Lincoln Laboratory process 

referred to as the AVOSS Winds Analysis System (AWAS), which was able to determine data quality at 
9 

each altitude region of interest, derived the wind profile. Each file type contains 16 quality flag fields with 

each value an integer. Unused fields were set to zero. 

The quality flags for each file type are: 

Wind Profile Flags: 

1. Percent of altitude levels from 15 through 100 meters that contain data values filled in by the data 

fusion process. Ranges from 0 to 100. 

2. Percent of altitude levels from 101 through 300 meters that contain data values filled in by the data 

fusion process. Ranges from 0 to 100. 

3. Percent of altitude levels from 301 through 600 meters that contain data values filled in by the data 

fusion process. Ranges from 0 to 100. 

4. Percent of altitude levels from 601 through 1000 meters that contain data values filled in by the data 

fusion process. Ranges from 0 to 100. 

5. Percent of South Sodar data points failing AWAS algorithm checks, from 0 through 300 meters. 

Ranges from 0 to 100. 

6. Percent of South Sodar data points failing AWAS algorithm checks, from 301 through 600 meters. 

Ranges from 0 to 100 

7. Percent of North Sodar data points failing AWAS algorithm checks, from 0 through 300 meters. 

Ranges from 0 to 100 

8. Percent of North Sodar data points failing AWAS algorithm checks, from 301 through 600 meters. 

Ranges from 0 to 100 

9. Percent of Radar Profiler data points failing AWAS algorithm checks, from 0 through 600 meters. 

Ranges from 0 to 100 

10. Percent of TDWR wind data points failing AWAS algorithm checks, from 0 through 600 meters. 

Ranges from 0 to 100 

11. Gust fronts or convective storms are impacting the area within 6 nm of the airport center during the 30-

minute observation period (from ITWS products). No storms = 0, storms = 1 

12. Gust fronts or convective storms are impacting the area within 16 nm of the airport center during the 

30-minute observation period (from ITWS products). 

13. Integer to indicate method of determining wind variance (0 = not defined, 1 = using TKE similarity 

theory, 2 = using radar profiler variance data) 

14. This field was not used, set to zero 

15. This field was not used, set to zero 

16. Data source indicator. Lincoln AWAS process sets to zero (0). North Carolina State University 

nowcast process sets to one (1). 

Turbulence Profile Flags: 

1. 5 meter meteorological tower fluxpac (10 Hz sonic anemometer) data missing (EDR and/or TKE) 

2. 40 meter meteorological tower fluxpac data missing 

3. 3 meter meteorological tower data missing (virtual potential temperature or wind speed) 

4. 10 meter meteorological tower data missing (virtual potential temperature or wind speed) 

5. Last 30-minmute period valid turbulence profile in use (unable to fix errors and compute an EDR) 

6. Constant turbulence profile in use, using 40 meter EDR and TKE values 

7. Canned turbulence profile in use (insufficient valid data available recently to estimate any profile) 

8. through 15: not used, set to zero 

16. Data source indicator. Observed weather system sets to zero (0). Nowcast sets to one (1). 
10

Thermal Profile Flags: 

1. An integer from 0 to 5 indicating the number of valid temperature measurements (altitude levels) from 

the meteorological tower that are used in computing a thermal profile. This value is labeled 

“Good_Tower”

2. An integer from 0 to 9 indicating the number of valid Radio Acoustic Sounding System measurements 

(altitude levels) that are used in the thermal profile. This value is labeled “Good_RASS”. 

3. through 15: not used, set to zero 

16. Data source indicator. Observed weather system sets to zero (0). Nowcast sets to one (1). 

From each flag set a status was computed within AVOSS to indicate that the file type was suitable for use. 

The three status words are defined by: 

ATMPRO_Good = [(Flag1 < 40 AND Flag2 < 50 AND Flag3 < 60) AND (NOT Flag11)] OR [Flag16] 

EDATA_Good = [NOT (Flag5 OR Flag6 OR Flag7)] OR [Flag16] 

TDATA_Good = [(Flag1 >= 2) AND (Flag2 >= 4)] OR [Flag16] 

In the current implementation of AVOSS, only the ATMPRO_Good status is used to effect spacing. If the 

ATMPRO_Good status is false, and if a parameter file bit is set to enable the use of the weather quality 

data (which was the mode always used in real-time operations), then AVOSS ignored the wake lateral and 

vertical motion in calculating spacing. In this situation only wake decay is used to reduce spacing. 

IF ((NOT ATMPRO_Good) AND QA_Enable) THEN disable all vertical and lateral wake motion. 

The method used to disable wake motion was to reset any computed vertical or lateral wake residence time 

values to 9999 prior to passing the residence time values to the spacing calculations. The automated 

comparison of wake predictions and observations is inhibited if the predictions were made with either 

ATMPRO_Good or EDATA_Good in a false status. TDATA_Good is computed and logged but is ignored 

during spacing calculations due to the low sensitivity of wake prediction results to temperature profile 

changes10. 

The initial criteria for the wind file acceptance also included tests of the individual sensor quality 

indicators. During testing in early 2000, these criteria proved excessively restrictive. In numerous cases 

poor data from one sensor was being filled by good data from another sensor and both the Lincoln 

Laboratory AWAS process and an independent meteorologist indicated that the derived wind profiles were 

accurate, yet the quality process was rejecting the file and eliminating periods of valid AVOSS output. The 

individual sensor requirements were eliminated for the system demonstration. 

Cross Wind Lockout 

Specific logic was implemented to prevent relying on wake drift in low cross wind or highly variable cross 

wind conditions. A cross wind component of about 1.5 to 2 meters/second (3 to 4 knots) can just cancel the 

natural tendency for wakes to separate in ground effect and cause one wake vortex to stay near the runway 

centerline, potentially creating a hazard. A calm wind will allow the wakes to separate as they near the 

ground, possibly creating a calculated aircraft spacing reduction as the wakes rapidly drift out of opposite 

sides of the corridor. This drift scenario could be hazardous to apply, since a slight unexpected momentary 

crosswind could cause a wake to remain on the runway. Recall that the wind values used for drift 

calculations are a 30-minute mean and a confidence interval based on the crosswind standard deviation. A 

gentle and varying wind could create a mean near zero. 

Another undesirable scenario is that of a significant mean crosswind, that would lead to calculated reduced 

spacing, but with a large variability in the wind. This scenario would be likely in conditions dominated by 
11

convective thermal activity, which produce large changes in wind speed and direction as thermals influence 

the measurement location. Application of reduced spacing due to wake drift could also be hazardous in this 

condition due to the possibility of a lull in the wind for a specific arrival that allows the wake to remain on 

the runway. 

Logic was implemented to reduce the likelihood of these scenarios. The crosswind lockout feature 

examines the mean and standard deviation of the crosswind component and calculates the two values 

(Mean – N* Standard Deviation) and (Mean + N*Standard Deviation). The value N is a parameter used to 

establish the size of the confidence interval relative to the standard deviation. The two calculated values 

form the confidence interval used for wake drift calculations. A crosswind lockout threshold (XwindMin) 

was also defined. If any part of the crosswind confidence interval intersected the lockout value range from 

–XwindMin to +XwindMin then the computed wake drift was not used to calculate the wake residence 

time and aircraft spacing. AVOSS used a value of N = 1 and a cross wind lockout of 1 meter/sec for all 

field operations. Therefore any mean wind of 1 m/s or less would prevent spacing reduction due to wake 

drift. With these parameters wake drift could only be used to reduce spacing if the absolute value of the 

mean minus the standard deviation was greater than 1 m/s. For example a 1 m/s cross wind standard 

deviation would require the mean cross wind to exceed 2 m/s in order to use drift to reduce spacing. This 

feature did not affect the use of wake sink or decay in spacing reduction. 

Throughput Calculation 

The spacing criteria calculated by AVOSS were used to estimate the potential runway arrival rate, or 

throughput, that could be achieved. Details of the calculations are described in reference 19. The 

throughput calculation makes use of the top-of-approach spacing criteria calculated, an aircraft category 

mix specified in a parameter file (expected percent of arriving small, large, B-757, and heavy aircraft), 

expected approach speeds for each category, the vertical profile of headwind (to estimate groundspeed), 

and expected ATC controller variance in meeting the prescribed spacing. No interface to the actual ATC 

system is used in the throughput calculation; hence it does not describe actual airport arrival rates during 

periods of AVOSS operation. The throughput calculations essentially determine the average period 

between arriving aircraft weight categories, then determines the relative frequency of each aircraft category 

pair, then determines an expected mean inter-arrival period for the traffic set. This time is then converted 

to aircraft operations per hour. Throughput is calculated with two spacing criteria, the AVOSS provided 

values and the FAA criteria. The difference in these throughput values is used to estimate the performance 

benefit of the AVOSS system operation. 

Wake Prediction Scoring Calculations 

The AVOSS concept calls for a safety monitoring function provided by ground-based wake vortex sensors. 

Detailed development of this safety monitoring logic is dependent on knowledge of the failure modes of the 

wake predictions, the criteria used to define a safe and unsafe event, and the capabilities of the wake 

sensors. To gather information in these areas an initial wake prediction comparison feature was 

implemented. The purpose of this logic was to automate the process of comparing wake predictions and 

observations, provide feedback on overall system performance, automatically log events that merit analysis, 

and gather insights that would be necessary in the development of an actual safety monitoring function. 

The basic parameter used to define aircraft spacing criteria, and for scoring comparison, is the wake 

residence time in the safety corridor. The predicted behavior is broken down into three wake factors (drift 

out of the corridor lateral limits, sink below the corridor vertical limit, and circulation decay below the 

wake demise definition). The residence time of each factor is computed from wake final exit from the 

corridor, vertically or laterally, or the time to demise. The residence time for the port and starboard wake is 

the minimum of the residence times of the three factors for that wake. The residence time of the wake pair 

is the time that both the port and starboard wakes are no longer in the corridor, as represented by the 

maximum function in equation 5. 
12

A wake residence time can also be determined from the wake sensor data and compared to the predicted 

wake pair residence time. Note that these comparisons are made, within the current AVOSS system, on a 

window-by-window basis. It is very possible, however, that aircraft could not be crossing a particular 

window with the spacing prescribed by predicted wakes at that window for two reasons. One, wake 

behavior at another window may be establishing the overall approach spacing. Wakes my only be a 

constraint at a window for 60 seconds (predicted), but 70-second spacing may be required there to satisfy 

constraints at other approach locations. Second, wake comparisons are made for each aircraft type 

measured for which a prediction is made, yet aircraft spacing prescribed by AVOSS will be based on the 

worst-case wake generated by all aircraft types in a given weight category. For example, an ATR-72 and a 

B-727 are both large aircraft and may have predicted wake residence times of 50 and 70 seconds, 

respectively. AVOSS will require at least 70 seconds behind all large aircraft in this case, so a 60 second 

wake observation from an ATR-72 does not correlate to a specific safety threat. More complex logic 

would be required for a true safety monitoring function to consider spacing that aircraft may actually have 

at a given window rather than only the predicted wake residence time at that window from one specific 

aircraft type. 

The difference between a predicted and observed wake pair residence time is referred to as a “buffer”. A 

positive buffer indicates that the predicted wake residence time was greater than the observed time. A 

negative buffer indicates that the observed wake residence time was greater than predicted. A negative 

buffer is also referred to as an “exceedance”. As suggested above, an exceedance may, but does not 

necessarily represent a situation that would have led to a wake encounter. Rather it indicates an event 

requiring analysis to diagnose system error modes and required improvements. The exceedance may 

indicate that the wake pair may not have been fully out of the approach corridor or fully decayed if another 

aircraft had been flying the prescribed spacing. An exceedance may also indicate some other aspect of 

system operation that requires analysis. In general, differences between predicted and observed wake 

residence times have at least four components: 

Diff = DiffIC + DiffWX + DiffPRED + DiffSENSOR (7) 

Where IC represents a component of difference due to wake initial conditions, WX represents a contribution 

due to wake weather conditions different than expected, PRED represents a contribution due to the 

predictor algorithm not adequately modeling all relevant factors, and SENSOR represents a contribution 

due to sensor measurement errors. Examples of each component are 

1. IC: An aircraft conducting a visual approach may be well above glide slope or to the side of the 

localizer, changing the time that the wake remains in the corridor. 

2. WX: Frontal passages or other factors may create different than expected wind or turbulence 

conditions at the wake location. 

3. PRED: The wake behavior may not be fully described by the wake prediction algorithms, for 

example reduced sink rate due to vertical wind shear. 

4. SENSOR: Difference between actual wake behavior and sensor measurements, such as a sensor 

inadvertently combining two aircraft arrivals into one wake track or failure to terminate tracks at 

wake demise due to atmospheric turbulent eddies. 

The initial attempt to develop a comparison algorithm19 simply took the observed residence time of each 

wake from the wake sensors and applied equation 5. This simple approach failed due to several factors: 

1. If the wake factor that set spacing was not observed by the sensor, then the factors that were 

observed led to a calculation suggesting a poor prediction, even when the observed wake behavior 

was essentially identical to that predicted. For example a wake may sink below the corridor floor 

in 15 seconds at the wind line location but require 70 seconds to drift laterally from the corridor. 

The wind line did not quantify sink time, leading to calculated prediction errors on the order of 55 

seconds when the wake acted as predicted. 

2. The wake sensors in use frequently did not track both wakes long enough to quantify a residence 

time for both wakes. The current criteria in use for declaring a residence time for any factor 

required positive observation of the wake outside the corridor limits or at a circulation value below 
13

the demise value, not simply the absence of a wake detection within the corridor. Both the wind 

line and the CW lidar would frequently not track the most rapidly drifting wake, and all sensors 

would sometimes lose tracks prior to the wake decaying below the defined demise value or exiting 

the corridor. Limitations of the sensors and the criterion for declaring an observed residence time 

led to a situation where many wake sensor data files were not usable for comparison purposes. 

3. Many comparisons were being made in domains where the wakes were persisting for periods of 

time much less than operationally feasible aircraft spacing (i.e., 10 to 30 second residence times). 

Inclusion of these events can complicate interpretation of prediction errors in domains that are 

operationally significant (i.e., 50 to 80 second wake residence time). 

The wake comparison logic was modified to address these problems. Two changes were made to 

accommodate the sensor limitations relative to the validation criterion and allow more observed events to 

be scored. One was to break the events into categories called Class 1, Class 2, Class 3, and Class 4. Class 

1 are the events where both the predicted and observed wake pair residence time was less than a minimum 

time (TauMin). TauMin was set to 50 seconds for AVOSS operations and represents an expected lower 

bound on actual aircraft spacing given a typical runway occupancy time on the order of 45 seconds. Class 

1 events indicate that the wake vortex was not a constraint to that aircraft operation. Class 2 events are 

counted if both the predicted and observed wake residence time was greater than a value TauMax. TauMax 

was set to 180 seconds and represents an expected upper bound on separation using current FAA spacing 

criteria. These events indicate that AVOSS has no potential to reduce spacing. No Class 2 events were 

detected during AVOSS operations. Remaining events (class 3 and 4 described below) are those where the 

buffer is negative and wake residence time falls between minimum aircraft spacing due to runway 

occupancy and current criteria. It is in this domain where wake prediction errors are potentially hazardous. 

In this domain prediction buffers are calculated as a diagnostic tool for system refinement. 

When the wake sensor data does not quantify the same wake factor used to establish spacing criteria, a 

buffer computed from that data is considered “soft”. This is a class 3 event. For example if the residence 

time is 15 seconds at a given approach window due to wake sinking, but the sensor only quantifies a drift 

time of 60 seconds (does not quantify the actual vertical residence time), the resulting calculated 

exceedance of 45 seconds is considered soft, since it may or may not represent an actual case of a wake 

persisting in the corridor longer than predicted. It is not possible to determine from sensor data in this case 

if the wake actually sank as predicted. When the sensor does observe the same factor then the calculated 

buffer is considered “hard”, indicating a high confidence in the wake comparison. These hard buffer events 

are considered class 4. 

A second major change was to determine if an observed wake event could be used for scoring if only one 

of the two wakes was quantified. Generally, when the sensors could only track and quantify one wake, that 

wake was usually the slowest moving, or the wake most critical to quantify for following aircraft to the 

same runway. A test was implemented for these cases that performed a least-squares fit to the wake lateral 

position time history data in the wake sensor file to determine drift rate. If the single quantified wake was 

drifting in a manner to suggest that the other wake must have had a shorter lateral residence time, then the 

observed wake was considered the “critical wake” and the data file could be used for scoring. The test 

required that the observed wake drift in a direction towards the runway centerline at a rate of at least 1.0 

m/s (2 knots). This drift condition indicates that the wakes are being effected by cross wind in a manner 

that will cause the unobserved wake to vacate the corridor in less time than the observed wake. If this test 

is failed then there is no certainty that the unobserved wake vacates as quickly as the observed wake, and 

both wakes are considered critical. When both wakes are critical then both must be quantified to allow the 

data to be used to score predictions. Note that only the wake drift is considered in this critical wake test. 

The nature of the current wake predictor algorithm is such that both wakes sink and decay at nearly the 

same rate in all weather conditions, so quantification of these factors for either wake is sufficient for 

scoring sink and decay. Once the wake predictor is enhanced in the future to predict differential sink and 

decay rates due to vertical cross wind shear, the current critical wake logic will require modification, unless 

it is no longer required due to improved sensor performance. Note that the calculation of hard and soft 

buffers is an artifact of the relationship of two factors, the limitations of the available sensors to reliably 

quantify residence time for both wakes and the philosophy that absence of wake detection in the corridor is 
14

not sufficient to declare a residence time. Division of observations into soft and hard would not be 

desirable for an operational system. 

There are special situations handled by the revised comparison logic. In particular when wind line data is 

used all buffers are soft, and the predicted wake residence time is recalculated using only wake drift prior to 

calculating the wind line buffer. Since wind line data could not be used to derive vertical residence time or 

demise time at that location, the revised logic allowed the wind line to be used solely for verifying drift 

predictions. Due to a large volume of wind line data, these buffers are useful for diagnosing the ability of 

AVOSS to quantify cross wind statistics and the resulting drift behavior. 

The current AVOSS comparison algorithms do not represent a true safety monitoring function, but rather a 

system diagnostic tool. The log of exceedance cases (Appendix C) provides a list of events deserving of 

analysis. During interpretation it is important to avoid assuming that comparisons reflect only wake 

predictor output and “truth” as provided by the wake sensors. As noted above numerous factors can create 

differences between predicted and observed wake behavior. Trends or systematic characteristics of the 

exceedances should be exploited to suggest refinements to specific subsystems or changes to system 

criteria or even architecture. For example, if a large fraction of exceedance events occurs due to wake 

demise at low altitudes, then attention should be placed on verification of turbulence measurements, wake 

decay prediction algorithms, and sensor algorithms that determine when to terminate a track and when 

background atmospheric turbulence can be confused with a very weak wake. Any trends for exceedances 

to occur in specific weather domains or times of day would also suggest processes for phasing the AVOSS 

into operational use, that is the system would not initially be used in the domains leading to low confidence 

predictions. 

Figure 6 shows flowcharts for the current wake comparison logic, taken from software specifications and 

slightly modified for readability. Prior to comparing wakes sensor data to predictions, the Compare code 

verifies that a prediction has been made in the past 35 minutes and that the prediction was made while the 

weather file quality flags indicated valid wind and turbulence data were used in those predictions. Next the 

wake data file is examined to determine which of the two wakes may be deemed critical, or if both wakes 

are critical, and then the wake residence time is computed from the individual components provided in the 

wake file. Next, two tests are applied to determine if the wake file is useful for scoring. First, the critical 

wake (port, starboard, or both) must not have a residence time value of 9999, that is, the sensor must have 

quantified a valid residence time for those wakes that would constrain spacing for following aircraft. 

Second the aircraft type observed by the sensor and the location of the scan (in the runway coordinate 

system) must match predictions made by AVOSS. The aircraft database used in the field consisted of 19 

aircraft types that included the types most common at DFW. 

Summary

A ground-based system has been developed to demonstrate the feasibility of automating the process of 

collecting relevant weather data, predicting wake vortex behavior from a data base of aircraft, prescribing 

safe wake vortex spacing criteria, estimating system benefit, and comparing predicted and observed wake 

vortex behavior. This report has described many of the system algorithms, features, limitations, and 

lessons learned, as well as suggested system improvements. The system has demonstrated concept 

feasibility and the potential for airport benefit. Significant opportunities exist however for improved 

system robustness and optimization. A condensed version of the development lab book is provided along 

with samples of key input and output file types. This report is intended to document the technical 

development process and system architecture, and to augment archived internal documents that provide 

detailed descriptions of software and file formats. 
15

Appendix A – Suggested System Improvements 

Lessons learned from AVOSS operations suggest numerous considerations for future implementations. 

Some considerations deal with system architecture or philosophy, others with implementation details. 

System Philosophy Considerations

A major issue that cuts across several areas of system design is the definition of wake vortex demise. A 

demise definition is needed both for the AVOSS internal algorithms that examine wake predictor results to 

search for a demise time, and for wake sensors as a minimum design requirement and a track-termination 

criteria. Comparison of current FAA spacing criteria to typically observed decay rates20 was made to 

determine the wake strengths that may be encountered today with current spacing rules and an assortment 

of large and heavy generator aircraft at approach speed. The analysis indicates that current rules will 

prevent small aircraft from encountering wakes stronger than about 100 m2

/s with worst-case generator 

aircraft, which is about the strength of the wake generated by a turboprop commuter aircraft, with 

encounters behind most aircraft weaker than 30 m2

/s. Large and heavy aircraft that are following current 

spacing criteria may encounter much stronger wakes. The large aircraft may encounter wakes of about 100 

m2

/s behind the average generator and up to 200 m2/s behind worst-case generators. Heavy aircraft may 

encounter wakes of 200 to 300 m2

/s behind other heavy aircraft. For comparison the wake generated by 

large aircraft such as the B-727 range from 170 to 270 m2

/s between minimum and maximum landing 

weight. Sensors in use during the AVOSS project could typically detect wakes as weak as 100 m2

/s, with 

slightly weaker wakes being detectable in very calm conditions. In windy conditions wakes may be lost at 

strengths around 120 m2

/s and attempts to track weaker wakes may lead to false wake detections from 

atmospheric turbulence. 

Conservative industry input suggests that there is no wake strength that can be safely encountered, i.e., zero 

strength. This value poses system design problems, as theoretically wakes may never decay to zero, and 

sensors cannot be designed to detect near-zero strength wakes to quantify that decay time. The current 

AVOSS approach is to never reduce spacing for small follower aircraft due to wake decay, since existing 

sensors cannot track all wakes that are significant to small aircraft. For large and heavy followers a demise 

definition is established that determines when the wake strength has essentially weakened to a level no 

greater than commonly encountered atmospheric turbulence and is below the strength that may be 

encountered with current FAA criteria. For AVOSS operations to date the demise definition has been 

circulation strength of 90 m2

/s. Even with this value for demise, the sensors in use may have difficulty in 

accurately tracking wakes and determining when to terminate a track and declare demise as the wake 

strength becomes comparable to atmospheric turbulence and circulation estimation noise becomes large 

relative to the wake strength. 

The total AVOSS system will become more robust when a consensus can be reached on an acceptable 

demise definition for large and heavy aircraft, not for intentional encounters but as a value that will be nonhazardous and will not require a go-around maneuver if inadvertently encountered. The wake sensors and 

prediction system can then be optimized to determine when wakes have decayed below this threshold. 

Consideration should be given to thresholds that are dependent on the category of the follower aircraft and 

are compatible to the circulation strengths in today’s environment, about 100 m2

/s for large aircraft in trail 

and 200 m2

/s for heavy follower aircraft. Values of this magnitude are consistent with flight safety and 

current flight rules, provide a more robust target for sensor tracking, and will improve system spacing 

performance. Absence of an industry standard definition of demise may actually decrease safety, as the 

past practice tends towards avoidance of any wake that can be measured. Without minimum performance 

standards the minimum measurable wake is sensor-dependent and may be greater than the proposed values. 

Closely coupled with the demise definition is the criteria used to declare wake residence time by the 

sensors. The approach used was to require the sensor to observe the wake actually drifting or decaying 

through the corridor or demise limits. This approach was taken for two reasons, to ensure that sensor 

failure or degraded detection performance could not lead to a false indication that the corridor was safe and 

also to provide a definitive time for the drift and demise residence time factors for predictor validation. 
16

The alternative to this approach is to declare the corridor safe when the sensor can no longer detect a wake 

within it. The approach used requires the sensor to track both wakes long enough to determine residence 

times. Very frequently however, a wake could not be tracked for this length of time. For example demise 

time was often not available when the wake vanished before reaching the demise value. This could occur 

for numerous reasons, including drift beyond the sensor range, rapid decay between scans of the lidar 

systems that caused the wake to decay from above demise to an undetectable value before the next scan 

sweep, or difficulty in tracking wakes near the demise value due to atmospheric turbulence. Likewise a 

wake that decayed before exiting the corridor led to indeterminate “9999” values for the drift or sink 

residence times. In some cases the downwind wake would drift away so rapidly that the wake sensor never 

tracked it. The end result was a large fraction of wake observations unusable for predictor scoring as well 

as special logic within AVOSS to maximize use of marginal observations. 

The approach of declaring the corridor safe when the wake cannot be observed is much less demanding of 

the sensor but leads to strict reliability and probability of detection requirements on the part of the sensor. 

There must be a very high probability that lack of wake detection is due to a lack of a wake rather than 

inadequate sensor minimum performance, extremely dry and clear air that compromises lidar detection, or 

any other factors. With appropriate minimum performance specifications, well understood sensor failure 

modes, self-testing, and reasonable wake demise definitions, consideration can be given to allowing sensors 

to declare a residence time, or corridor safe, when no wake is observed. Sensor design and safety 

monitoring logic within AVOSS may be greatly simplified if robust detection is assured. 

Another significant system philosophy enhancement would be a stronger probabilistic basis for wake 

prediction and risk management. The system currently considers wind statistics in determining a 

confidence interval on wake drift rates and aircraft flight technical error statistics for sizing the safety 

corridor. Discrete logic is used in domains where the statistical process may break down, for example the 

low cross wind lockout logic for wake drift use. However the wake predictor and the corridor residence 

time logic use relatively simple discrete logic for risk rather than a statistical process. The wake predictor, 

given a description of the weather, will provide a wake trajectory with no statistical description of the 

confidence of that prediction. AVOSS runs the predictor multiple times per aircraft prediction, using the 

wind confidence interval to vary the weather inputs, to estimate the potential range of wake motion. The 

function of estimating wake uncertainty was only implemented for uncertainty in the crosswind, not for 

turbulence or thermal gradient uncertainties. Expectations and later analysis10 both suggested that wake 

spacing is more sensitive to the cross-wind than to the other parameters, and cross wind is more likely to 

change significantly over short periods of time than ambient turbulence or thermal gradients. Although this 

approach worked well in system operation9

, it possesses limitations. First, the inherent uncertainty in the 

wake prediction algorithm itself is not quantified. Given multiple runs with identical initial conditions and 

weather conditions, the wake predictor will always produce identical outputs. Field observations of wake 

behavior in nearly identical conditions will produce a small range of behavior (decay time or motion rates). 

Variation in wake behavior, particularly sink rate, increases as atmospheric turbulence increases, or 

convective activity or thermal inversions create vertical wind shears. Normal wake behavior, such as the 

sinusoidal shape taken by a wake pair due to the Crow instability, can create small variations in wake 

altitude or lateral position relative to the mean position when a sensor randomly samples the wake system. 

Current predictor algorithms are not able to provide a quantifiable bound, or confidence interval, on the 

wake altitude, lateral position, or strength. Ideally the predictor could accept a description of the weather 

and provide information at each time step to indicate the confidence in the prediction. For example the 

lateral and vertical position may be provided as a mean and a standard deviation. Turbulent conditions, 

known to make sink rate estimation less reliable and sometimes slow the wake sinking motion, might 

increase the confidence interval as well as slow the predicted sink rate. The wake predictor might describe 

the Crow instability as an increasing position standard deviation over time. Such a statistical wake 

predictor would simplify the system logic and be more easily adaptable to formal risk analysis methods. 

Another limitation of the current spacing criteria method is that it is single-dimensional, in that the 

uncertainty of one wake factor at a time, such as drift, is calculated. When extended to multiple factors 

(drift and sink for example) the results may be overly conservative. This hypothesis is made from 

observation that temporary weather conditions that may create worst-case behavior in one factor may tend 

to provide benefits in the other factors. For example, a temporary cross wind shear that reduces wake sink 
17

rate requires a cross wind, which will move the wake away from the localizer. A lull in the wind that may 

allow the wake to remain on the localizer in turn will not be accompanied by a cross wind shear that could 

prevent wake sinking. Wake residence time confidence intervals should be estimated based on the 

interdependency of all wake factors and the probability of an encounter, while the current method would 

combine worst-case times from an independent assessment of each factor. 

The use of the corridor to determine residence time would be enhanced with a statistical approach that 

considered contours of risk rather than the current binary risk/no risk method, figure 7. Currently a wake is 

either inside or outside the corridor, and a wake that has drifted to the edge of the corridor carries the same 

risk weight within AVOSS as a wake on the aircraft path. Many of the exceedance cases logged in field 

tests involved wakes that had nearly drifted out of the corridor. These exceedance cases carry the same 

weight as a wake that remains on flight path, yet an aircraft encounter would not have occurred unless the 

aircraft had a large (3 standard deviation) flight technical error in the direction needed to reach the wake. 

The binary risk model used has also impeded the definition of a demise definition, since a wake that has not 

left the corridor is assumed to carry an encounter probability of 1, while in reality the encounter probability 

is much less. Obviously the wake strength permitted for an encounter probability of 1 will be much less 

than for an encounter probability on the order of 10-3 or 10-6. Consideration should be given to defining a 

probability of a significant encounter, which involves wake strength and position as well as the flight 

technical error of the aircraft, and designing AVOSS to determine spacing values to meet specific 

probabilities. A model for the next system design might therefore result from a formal system risk analysis 

of the current system. Figure 7 shows this approach. The encounter probability can be determined from 

the probabilities of lateral and vertical positions coinciding with the aircraft location, and the probability of 

no demise. Each of these probabilities will reduce as time increases and the system could be designed to 

determine the time for a given probability, without the need for a defined corridor shape. If the 

probabilities of the three factors are not independent, as suggested by field experience, then the calculation 

can be done on a domain-by-domain basis. For example the crosswind shear conditions leading to 

increased wake vertical position uncertainty will tend to reduce the lateral position uncertainty. 

Implementation Considerations

Within the current system philosophy numerous enhancements would improve system operation. One of 

the most significant would be wake sensor upgrades to state-of-the-art systems. The lidars in use had a 

research heritage and were roughly 4 to 6 years old at the AVOSS demonstration. This represents a 

considerable gap in both laser technology and digital signal processing capabilities. The scanning 

capabilities (pulse repetition frequency, range bin size) of the AVOSS lidars led to long gaps between lidar 

hits, typically 10 seconds or more between laser sweeps past the wake and larger than optimal uncertainties 

in the wake position at each hit. This time interval was adequate for a wake to significantly decay or vanish 

between measurements, complicating demise time determination. The wake data collected had sufficient 

frame-to-frame noise that curve fitting processes had to be used to smooth the track and decay histories. 

These curve fits introduced other potential error sources, possibly not properly reporting a wake rebound 

from the ground or curve fits to a few noisy data points leading to unrealistic decay or motion data plots. 

The scan capabilities of current systems also compromises wake detection of departing aircraft. Due to 

wide spatial dispersion of aircraft shortly after liftoff, a large area of the sky must be scanned to acquire the 

wake. Slow scan rates can lead to first detection up to 30 seconds after passage, and no second detection 

due to decay between scans. Systems currently available21 have improved scanning capabilities and can 

produce high quality wake tracks with position updates roughly every 5 seconds. These improved 

capabilities create the potential to eliminate curve fits to the data and enhance the ability to track both 

wakes and accurately determine residence time. 

The wake lidar also presents an opportunity for simplification of the weather system. Lidars can provide 

high resolution and high update rate cross wind data within the arrival or departure corridor, at the altitude 

of interest. Atmospheric turbulence data (turbulent kinetic energy and eddy dissipation rate) have been 

measured also by lidars and particularly validated with in situ measurements. In 1998 a simplified AVOSS 

was operated using only lidar wind and turbulence data. Lidar wind data was not used within the DFW 

weather system since year-round AVOSS operation (weather and spacing predictions) was desired and the 
18

lidars were only deployed for a few weeks per year for full system tests. While the lidars were not 

deployed the AVOSS operated with dedicated weather sensors and a single wind line for wake data. 

The time required to drift out of the lateral limits of the safety corridor was calculated from a cross wind 

confidence interval computed from the mean and standard deviation of the cross wind. The 30-minute 

mean and standard deviation were computed from a series of 30 1-minute cross wind measurements. The 

system performance, both throughput and exceedance counts, were sensitive to the multiplier applied to the 

standard deviation, hence the confidence interval used. Additional analysis is in order to determine (a) if 

other methods of estimating the wind confidence interval produce better results (for example a percentile 

cross wind represented by the 30 individual 1-minute values) or (b) if modifications to the corridor are 

appropriate (for example an inner corridor with high criticality and an outer corridor with a higher allowed 

probability of wake presence). 

The weather system was designed initially as a research system, with inclusion of all sensors that were 

believed to be needed to avoid missing critical signals. Considerable opportunity exists to eliminate 

sensors for a more economical installation, particularly if the wake lidars are employed as weather sensors. 

Two separate weather systems were used, a local system at Dallas using ground based sensors, and a 

planetary boundary layer model22 for short-term “nowcast” predictions of all weather parameters. The in 

situ system was used for all wake vortex spacing criteria outputs and the nowcast system was used to 

predict future runway acceptance rates for planning purposes. The nowcast model was operated by North 

Carolina State University, using operational weather products from the National Center for Environmental 

Prediction for initialization. Although the nowcast model used no in situ sensors at DFW for initialization 

or correction, wind estimation accuracy was typically within 1.5 m/s (3 knots) of observed winds with 5 to 

10 hour old forecasts. This accuracy is not adequate for use near the ground, where critical cross wind 

values are typically on the order of 1 or 2 m/s and small changes in cross wind have large effects on wake 

motion. The nowcast model may be adequate however for use above ground effect where wake drift is not 

effected by the ground and is less sensitive to small cross wind changes, wake drift is less of a factor in 

spacing than sink rate, and where current ground based sensors have the most difficulty in providing robust 

data. Limited manual comparisons of sensor observed winds aloft (fused from multiple sensors) and 

nowcast winds aloft suggest that the accuracy of the two systems is similar at altitudes above about 200 

meters. Although the demonstrated weather system was adequate to realize some initial system benefit in 

limited weather domains, significant opportunity exists to improve wind estimation, vertical profiling, and 

sensor cost reduction by blending the observed and nowcast systems, along with wake lidar wind data and 

perhaps downlink of aircraft data for validation. The nowcast data could also be used to predict changes in 

the observed weather profile. Currently data taken for a 30-minute period is used to estimate weather 

statistics for the next 30 minutes using persistence. In general this approach worked well and wake spacing 

changes were typically small from one thirty-minute period to the next in the absence of major weather 

changes. The nowcast could be used to improve the persistence forecast further when conditions are 

changing. Such blending is non-trivial, however, and would require a significant field presence to test and 

refine algorithms with significant data sets at all times of the year. 

Other implementation enhancements include modifying the use of the value 9999 for invalid data, as 

mentioned earlier and developing true safety monitoring logic. Lessons learned from the current wake 

scoring software would be needed for the safety monitor function, which would run in parallel with more 

detailed scoring software for diagnostics purposes. Safety monitoring might not consider deviations from 

observed and predicted wake behavior as much as it might consider deviations between observed wake data 

and actual aircraft spacing being provided. For example a B-737 predicted residence time at a window may 

be 30 seconds and the observed may be 60. This would not be a safety issue if other windows or another 

large aircraft in the database were requiring 70-second spacing at that window. The safety logic must also 

anticipate wake exceedance events in order to provide adequate notice in the rare event that a go-around is 

required. This could be performed by also comparing observed weather to that used in the wake 

predictions. For example a sudden lull in the winds when the prediction was for a steady crosswind would 

also indicate that wakes will not be drifting as predicted. During the wake calculation process AVOSS 

could quantify and provide weather values that would require caution alerts to ATC. 
19

Appendix B – Aircraft Database and Parameter File 

The aircraft data required to run AVOSS is stored in a disk file named “ac_dbase.acd”. The data base used 

for DFW field operations is presented below. The file contains two comment lines, denoted by the initial 

character “#”. The second comment provides a key to the fields provided for each aircraft. All units are 

metric. The third line provides the expected maximum speed (m/s) on final approach for the small, large, 

and heavy category aircraft, respectively. These values are used only for computing the required top-ofapproach spacing given the spacing required at individual approach windows. The next line contains the 

number of aircraft in the database and is used by the file reader to increment the loop that reads data. If 

more aircraft are listed than indicated by this line then they are not read or used for wake predictions. 

The remaining lines each provide the data required for one aircraft type. This data is used to initialize the 

wake predictor algorithms and to match wake predictions to sensor observations. The first field provides 

an aircraft identification that is matched to an equivalent wake sensor data file field to enable scoring of 

predictions. The second field provides a common name label for the type, including variants that are 

considered similar for wake predictions. Field two is not used by the machine, Field 3 indicates if the type 

is considered large “L”, a B-757 “B”, or a heavy aircraft “H”. This field is used when combining spacing 

criteria for each aircraft type into a category-based matrix. The final three fields provide wing span 

(meters), estimated maximum landing gross weight (kilograms), and estimated approach speed (m/s). The 

data is intended to represent the aircraft types most common at DFW as well as worst-case types in each 

category. For example the ATR-72 is a worst-case large aircraft with respect to wake sink rate, due to a 

large wing span relative to the strength of the generated wake and the B-727 is one of the heaviest aircraft 

in the large category. 

#Aircraft data set 

#AC_ID, AC_Type, Category, Span, Max_LD_GW, Est_APP_Speed 

65,75,82.4 

19 

AT72,ATR-72,L,27.1,19913,61.8 

FK10,Fokker F100,L,28.1,44453,69.5 

DC9,DC-9,L,28.5,49896,69.5 

B737,B737/73F/73J/73S,L,28.9,54432,72.1 

MD80,MD80/83/88/90,L,32.9,58061,69.5 

EA32,A320,L,33.9,64502,74.6 

B727,B-727,L,32.9,72576,72.1 

B757,B757,B,38.0,89813,69.5 

DC8,DC-8,H,45.2,113400,72.1 

EA31,A310,H,43.9,123016,72.1 

B767,B767,H,47.6,126101,74.6 

EA30,A300,H,44.8,137985,74.6 

L101,L-1011,H,47.3,166925,77.2 

EA34,A340-200,H,60.3,180986,69.5 

DC10,DC-10,H,50.4,182801,72.1 

MD11,MD-11,H,51.7,195048,77.2 

B777,B777-200,H,60.9,206388,72.1 

B747,B747-100/200/300,H,59.7,265356,77.2 

B74F,B747-400,H,64.3,285768,82.4

Many AVOSS run-time options are controlled by a parameter file named pfile.prm. The file begins with 

any number of comment lines, denoted by “#”. Following the comments lines is a description of the data 

fields. This was provided as a reference to minimize the chances of error when modifying parameters in 

the field. Following the field descriptions are the actual parameters used by AVOSS. The example file 

below shows the values used by AVOSS at the DFW field site. 

The corridor option was used to select one of two corridor floor options, as described in reference 18. 

N_Sigmas is a multiplier to apply to the cross wind standard deviation when estimating the bounds on wake 

drift behavior. SINKPCNT is used to reduce the effective sink rate of the predicted wakes when 

calculating spacing. For example if the wake predictor estimates a wake to sink below the corridor floor in 
20

15 seconds, and SINKPCNT is set to 50, then the residence time applied becomes 30 seconds. This value 

was set to 100 except during sensitivity studies. TIMEADD was also implemented for sensitivity studies. 

It provides a constant bias (addition) to computed wake residence times and was set to zero for field work. 

Both SINKPCNT and TIMEADD were included to test techniques for accommodating wake prediction 

uncertainties. Demise_Def and Demise_VAL are wake circulation values (m2

/s) used to estimate demise. 

The first value is used by the spacing calculations and is normally set to 90 m2

/s. Since the wake sensors 

frequently cannot track wakes of this low strength, a higher value can be used for scoring predictions. For 

example if Demise_Val is set to 120, then AVOSS compares the predicted and observed time for wakes to 

decay to that value. The value UPDATE_PERIOD is not used within AVOSS 

The NUM_TRACK_WRITE field is used to control writing of wake predictor outputs (wake motion and 

decay time histories) to disk. These files are quite large and in general are only needed for plotting wake 

lidar data against predictions. Each track file contains all wake track predictions for all aircraft at a given 

window. With 19 aircraft and up to three wake predictions per aircraft, each file contains up to 57 wake 

tracks. This line contains a number that indicates the number of windows to write, followed by a list of the 

window numbers. The default windows created at program execution are numbered 0 through 5 and any 

additional windows begin with the number 6. 

The next four lines contain flags used to disable specific wake factors in calculating spacing. The output 

spacing file (Appendix C) contains an “upper set” of spacing values and a “lower set” of values. The upper 

set ignores wake demise, that is, only uses wake drift and sink to establish spacing. The flags 

Disable_Lat_Upper and Disable_Vert_Upper also allow the user to switch off the consideration of wake 

drift or sink, respectively. With all factors disabled the upper spacing values provide the current FAA 

spacing criteria. That setting is run by default so that AVOSS will compute throughput with the FAA 

criteria and hence the performance benefit with reduced spacing. The flags for the lower set provide the 

same function for the lower set of spacing matrices. With both flags set the only factor considered in the 

lower matrix set would be decay. 

Taumin and Taumax provide the time values required by the wake comparison algorithms to determine if 

an observation is a Class 1 or 2 event. QA_Enable determines if AVOSS will use the weather quality 

assurance process when computing spacing. If disabled, spacing will be computed regardless of the 

weather data quality. QA_Enable was always enabled in the field. P_Version and Batch are not read by 

AVOSS. Path was used to direct AVOSS output to a specific disk area. The current shell code ignores 

Path and directs the output as needed. 

Runway_ID is a character string that labels the runway in use. This string is used within AVOSS when 

building output file names. Future version of AVOSS may run independent predictions for different 

runways and this field would provide a means to select the appropriate wind files, which are specific to the 

runway orientation, and label outputs. The airport elevation data is not currently used within AVOSS. All 

calculations and weather files are with respect to altitude above ground. 

The next three fields directly effect the AVOSS corridor dimensions by providing the point where the glide 

slope intercepts the runway, the glide slope angle, and the altitude above ground that the aircraft are 

assumed to intercept the glide slope. The glide slope is assumed to intercept the runway at –305 meters 

(about 1000 feet down the runway, on the negative X-axis), the glide slope angle is 3 degrees, and the 

aircraft are assumed to intercept the glide slope at 600 meters (1968 feet) above ground. 

The next four fields provide the fractions of small, large, B-757, and heavy aircraft in the traffic mix and 

must sum to 1. In current FAA spacing criteria the B-757 is essentially its own class when it is the 

generating aircraft, and is considered a large aircraft when in trail. The ATC rounding interval rounds 

spacing outputs to specified nautical mile intervals before estimating throughput. For example an AVOSS 

output of 3.38 miles may be rounded to the half-mile prior to throughput estimation, on the assumption that 

ATC controllers could not make use of any finer criteria. The ATC variance value of ten seconds is used 

also in the throughput calculations, as described in reference 19. 
21

Finally the list of additional windows is given. The file reader assumes that this data is last in the file. The 

first number is the number of additional windows, flowed by the X-axis location of those windows. 

Typically new windows are added to provide wake predictions at the locations of wake sensors. For 

example at DFW in 1999 and 2000, the continuous-wave lidar was scanning at X = 84 meters (near 

threshold) and the pulsed lidar could scan at 1080, 1702 or 2262 meters by changing scan azimuth. Future 

systems might also use this capability to adapt to specific meteorological conditions, for example to place a 

prediction window at a glide slope location likely to be affected by a strong cross wind shear or thermal 

inversion. 

# Parameter file for AVOSS Version 2, format modified July 1999 

# 

# Program Control Information 

Corridor_Option (integer) 

N_Sigmas (integer 1,2,3) 

SINKPCNT (% of avg. sink rate to use in establishing spacing. 0 to 100) 

TIMEADD (is a constant time bias to be used before computing spacing) 

Demise_Def (integer meters squared per second, for spacing calculation) 

Demise_Val (integer meters squared per second, for validation) 

Update_Period (integer minutes for refresh of separation matrices) 

NUM_TRACK_WRITE (number of track files to write followed by window number(s) to 

use) 

DISABLE_LAT_UPPER (1 to disable lateral spacing for upper output matrices) 

DISABLE_VERT_UPPER (1 to disable vertical spacing for upper output matrices) 

DISABLE_LAT_LOWER (1 to disable lateral spacing for lower output matrices) 

DISABLE_VERT_LOWER (1 to disable vertical spacing for lower output matrices) 

TAUMIN (minimum time for wake buffer calculation, simulates ROT) 

TAUMAX (maximum time for wake buffer calculation, simulates max spacing) 

QA_Enable (1 to enable QA, 0 to disable) 

P_VERSION (For later use to select versions of the predictor algorithm) 

Batch (0 to run batch, 1 to run real-time data) 

Path (path or string "UNIX" for file output) 

Runway_ID (char) 

Airport_Elevation (real, meters) 

Glide_Path_Intercept_on_Runway (int, meters) 

Glideslope_Angle (real) 

Glideslope_Intercept_Altitude (integer, meters, AGL) 

FRAC_Small (fraction of throughput in small category. must be between 0 and 1) 

FRAC_Large (fraction of throughput in large category. must be between 0 and 1) 

FRAC_B757 (fraction of throughput in B757 category. must be between 0 and 1) 

FRAC_Heavy (fraction of throughput in heavy category. must be between 0 and 1) 

ATC_Round_Interval (spacing rounding interval (NM) used in the throughput 

calculations) 

ATC_Var (ATC variance) 

Num_Extra_Windows (to add to defaults, follow with list of integer X values) 

2 

1 

100 

60 

90 

120 

30 

3 3 6 7 

1 

1 

0 

0 

60 

120 

1 

3 

0 

/export/home/adam/avoss/avoss_v2.4.0/data/temp_data/ 
22

R17C 

183.6 

-320 

3.0 

600 

0.25 

0.60 

0.10 

0.05 

0.5 

10 

3 84 1080 1702 2262 
23

Appendix C – Output data files, Spacing, Log, Statistics, and Exceedance 

Several output file types are discussed. Figure 1 shows the software modules that create each file type 

discussed. The core code writes a spacing file and a log file. The code that compares wake predictions and 

observations, which resides just outside the core, writes a statistics file and an exceedance file. Batch 

programs exist to allow the core and the comparison code to be run together with archived weather and 

wake sensor data files. 

The output spacing criteria are provided in one file per 30-minute period. A typical file name is 

“DIST_R17C.991201_010000”. All spacing file names begin with DIST, followed by the runway 

identification from the parameter file, then date and time in YYMMDD_HHMMSS format. The files begin 

with an arbitrary number of comment lines, each beginning with “#”. These lines are used to describe the 

file contents. The data begins with a line that repeats the runway identification, year, month, day, hour, 

minute and second. The next line echoes the corridor option number, N_Sigma, the Demise_Def, and the 

number of aircraft in the database. The next line echoes the QA_Enable flag, the QA status of the three 

weather files that made up the prediction, and weather flag 16 which indicates if the weather was derived 

from the sensors at DFW (flag = 0) or from the nowcast system (flag = 1). The fourth data line echoes the 

data used to estimate runway throughput, that is, the fraction of each weight class, the rounding interval, 

and the ATC variance, all from the parameter file. The fifth data line provides two throughput values, the 

first based on the top-of-approach spacing in the upper set of spacing matrices, the second based on the topof-approach spacing in the lower set. In this sample the upper set is providing default, or current FAA, 

spacing since the lateral and vertical motion were disabled using parameter file flags. The next line 

indicates the number of windows used. The size of the spacing file will change as windows are added. 

The rest of the file is divided into an upper and lower set of spacing values. Each set first contains the 

spacing at individual windows, followed by the resulting top-of-approach spacing at the spacing point. The 

spacing at each location is provided in a 3x3 matrix of nautical mile values. While calculations are 

performed using metric units, AVOSS converts to the conventional ATC units of nautical miles for output. 

The columns represent large, B-757, and heavy lead aircraft and the rows represent small, large, and heavy 

following aircraft. Windows 0 through 5 are the default windows with Window 0 at the runway threshold 

and Window 5 at 11.128 km from threshold. Additional windows, 6 through 9 in this case, will be located 

between the other windows. In this case window 6 is at X = 84 meters. Each matrix has a text label to aid 

reading. The text will change according to the flags that disable lateral or vertical motion. In this case the 

upper set is labeled “Default Spacing” since both wake motion factors are disabled, and the lower set is 

labeled “Trans & Demise Spacing” since all wake motion is enabled. Recall that wake decay is never 

considered in the upper set and is always considered in the lower set. Each label begins either with the 

window number “Win 0” or the word “Approach” to indicate top-of-approach. In this sample the AVOSSproduced reduced spacing for large category aircraft following heavy aircraft is 2.75 miles at the threshold 

(Window 0, lower set), 2.50 miles at the other windows, and 2.95 miles at the top-of-approach. Current 

FAA spacing criteria would have applied 5 miles at all windows with 5.47 miles being required at the topof-approach to allow for the speed difference between the slowest heavy aircraft and the fastest large 

aircraft on final. 

#Distance separation arrays (nautical mile) 

#Rows are S,L,H follower, Cols are L,B757,H generator 

#Header: runway,date,time,CorOption,Nsigma,DemiseDef,Naircraft 

#qa_enable, atmpro_good, edata_good, tdata_good, atmpro_flag16 

#frac_small, frac_large, frac_757, frac_heavy, round_interval, atc_var 

#tp, dtp 

#NWindows 

R17C 99 12 1 1 0 0 

2 1 90 19 

1 1 1 1 0 

0.25 0.6 0.1 0.05 0.5 10 

34.0817 30.5695 

10 

#Win 0 Default Spacing 
24

4.00 5.00 6.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Win 1 Default Spacing 

3.00 5.00 5.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Win 2 Default Spacing 

3.00 5.00 5.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Win 3 Default Spacing 

3.00 5.00 5.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Win 4 Default Spacing 

3.00 5.00 5.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Win 5 Default Spacing 

3.00 5.00 5.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Win 6 Default Spacing 

3.00 5.00 5.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Win 7 Default Spacing 

3.00 5.00 5.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Win 8 Default Spacing 

3.00 5.00 5.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Win 9 Default Spacing 

3.00 5.00 5.00 

2.50 4.00 5.00 

2.50 4.00 4.00 

#Approach Default Spacing 

4.11 5.00 5.28 

3.76 4.46 5.47 

4.50 5.06 5.06 

#Win 0 Trans & Demise Spacing 

2.50 2.50 2.73 

2.50 2.50 2.75 

2.50 2.50 3.02 

#Win 1 Trans & Demise Spacing 

2.50 2.50 2.50 

2.50 2.50 2.50 

2.50 2.50 2.50 

#Win 2 Trans & Demise Spacing 

2.50 2.50 2.50 

2.50 2.50 2.50 

2.50 2.50 2.50 

#Win 3 Trans & Demise Spacing 

2.50 2.50 2.50 

2.50 2.50 2.50 

2.50 2.50 2.50 

#Win 4 Trans & Demise Spacing 

2.50 2.50 2.50 

2.50 2.50 2.50 

2.50 2.50 2.50 
25

#Win 5 Trans & Demise Spacing 

2.91 2.50 2.50 

2.50 2.50 2.50 

2.50 2.50 2.50 

#Win 6 Trans & Demise Spacing 

2.50 2.50 2.50 

2.50 2.50 2.50 

2.50 2.50 2.54 

#Win 7 Trans & Demise Spacing 

2.50 2.50 2.50 

2.50 2.50 2.50 

2.50 2.50 2.50 

#Win 8 Trans & Demise Spacing 

2.50 2.50 2.50 

2.50 2.50 2.50 

2.50 2.50 2.50 

#Win 9 Trans & Demise Spacing 

2.50 2.50 2.50 

2.50 2.50 2.50 

2.50 2.50 2.50 

#Approach Trans & Demise Spacing 

2.91 2.50 2.50 

3.76 2.95 2.95 

4.50 3.59 3.61 

A log file is produced to summarize the results of multiple runs. The file provides a TECPLOT header to 

allow rapid plotting of a full day of spacing results. The file contains one line of data per 30-minute 

AVOSS cycle, or 48 data lines for a full day of operation. Each line lists date, time, the lower set top-ofapproach spacing in the order "LS" "BS" "HS" "LL" "BL" "HL" "LH" "BH" "HH" where S, L, B, H are the 

4 categories and the first letter is the leading aircraft category, i.e., LS = large leading a small aircraft. The 

next 9 values are the upper set for the same 9 categories, which normally are the default or FAA spacing. 

Next are 6 fields for meteorological weather observation data (time, visibility, ceiling, wind direction, wind 

speed, and precipitation). A process for merging the log file with hourly weather reports was intended to 

fill in these fields and allow sorting results by weather domain. The merge routine was not written in time 

for deployments so these fields are filled with “9999”. Next are the status of five parameter file flags, 

DISABLE_LAT_UP, DISABLE_VERT_UP, DISABLE_LAT_LOWER, DISABLE_VERT_LOWER and 

QA_Enable. Next the quality status of the three weather file types is listed (0 fail, 1 pass), and finally the 

individual QA flags of each weather file type. To save space only the defined flags are listed. In total there 

are 61 fields per line. The log file is written by the AVOSS core code and is appended to at each AVOSS 

execution. It is up to the user or shell code to copy the file to another name or location at the date change 

over to force AVOSS to create a new file. The sample below contains the header and one line of data from 

a log file. The length of each line mandates line wrapping in this printed format. 

TITLE="AVOSS Prediction Log File from: 1999, 12, 1, 0, 0, 0 to 1999, 12, 1, 1, 

30, 0" 

VARIABLES="Dt" "Tm" "LS" "BS" "HS" "LL" "BL" "HL" "LH" "BH" "HH" "DLS" "DBS" 

"DHS" "DLL" "DBL" "DHL" "DLH" "DBH" "DHH" "TP" "DTP" "MTm" "Mvis" "MCl" "Mwd" 

"Mws" "Mprec" "PF1" "PF2" "PF3" "PF4" "PF5" "AGood" "EGood" "TGood" "WQ16" 

"WQ13" "WQ12" "WQ11" "WQ10" "WQ9" "WQ8" "WQ7" "WQ6" "WQ5" "WQ4" "WQ3" "WQ2" 

"WQ1" "EQ16" "EQ7" "EQ6" "EQ5" "EQ4" "EQ3" "EQ2" "EQ1" "TQ16" "TQ2" "TQ1" 

ZONE I=3 F=POINT 

19991201 0000 4.12129 4.3561 5.30665 3.74367 2.92169 2.92169 4.48002 3.57156 

3.57156 4.12129 5.00001 5.30665 3.74367 4.39784 5.39026 4.48002 5.04083 5.04083 

33.5788 31.9784 9999 9999 9999 9999 9999 9999 1 1 0 0 1 1 1 0 0 0 0 0 56 60 67 

6 100 61 37 0 0 0 0 0 0 0 0 0 0 0 0 5 0

A statistics file is also produced for each day of operation. The data in the statistics file provides a detailed 

high-level summary of a day’s operation, including the number of system runs, weather system 

performance, spacing statistics, and wake observation comparison statistics. Like the log file, the AVOSS 

creates the statistic file if it does not exist and modifies it with accumulated statistics at each 30-minute 
26

cycle if it does exist. It is up to the user or shell code to move or rename the file to reinitialize the statistics. 

Statistics over longer time periods can be accumulated simply by running continuously without removing 

or renaming the file. This file accumulates statistics on AVOSS spacing results as well as on comparisons 

to observed data. File contents are described throughout by “#” comment lines. The file begins with the 

date and time that it was begun and last updated. In this sample the file was written over a 13-minute 

period since it was generated by a batch reprocess of archived field data. The next data line indicated the 

total number of runs and the number run with weather files that passed the quality tests. In this sample 24 

of 30 runs were made with wind data that passed the quality tests. The next line provides throughput 

statistics for all runs, including the mean AVOSS value, the mean FAA-criteria value, and the minimum, 

mean, and maximum percentage increase. In this case the mean runway throughput from the 30 runs with 

AVOSS spacing is 33.4, the mean increase was 6.23 percent, and one run produced a 14.34 percent 

increase. The next data line provides the mean spacing value, at the top-of-approach, for the nine category 

pairs. Next the mean spacing reduction, again at the top-of-approach, relative to current criteria is listed. 

In this sample the mean spacing reduction behind the B-757 is over 1 nautical mile for all follower 

categories. The next two lines indicate the mean and the variance of the spacing change for each category 

pair between the half-hourly updates. This is a measure of the stability of AVOSS spacing values for use 

by ATC. 

The next block of statistics relates to the comparison of predicted and observed wake motion. First data 

echoes TauMin and TauMax from the parameter file, then counts the fields received from each sensor. The 

comparison code will reject wake files for several reasons (see figure 6) and the counts of these occurrences 

are listed. In this list the wake sensor identifications are wind line (wl1), NASA pulsed lidar (lna) and 

Lincoln contunious wave lidar (lli). In this sample a total of 351 wake files were available and only 102 

met all criteria for use. 

Next four groups of numbers with the same format provide residence time buffer statistics for all sensors 

combined, and then broken out by sensor. The “#” comment lines describe the format. The first line 

provides class 3 (soft) buffers and the counts of class 1 and 2 events. The next line describes class 4 (hard) 

buffers. In this sample, when all sensors are combined, there are 11 class 3 buffers (8 positive and 3 

negative), 91 class 1 events, and no class 2 events. The next line in each group gives the mean and 

standard deviation of all soft and hard buffers, then the mean of all exceedances, where an exceedance is a 

negative class 3 or 4 buffer. The exceedance mean is done for all exceedances, then all soft exceedances, 

and then all hard exceedances. The hard exceedance mean of “9999” indicates that no hard exceedances 

were detected and a mean could not be computed. The final line in each group gives the largest soft and 

hard exceedance detected. The data in this group shows 91 class 1 events, 68 of which were detected by 

the pulsed lidar, the average buffer calculated was a positive 34.3 seconds, three exceedances were 

detected, 2 from the pulsed lidar and 1 from the CW lidar, and no hard buffers were calculated. The largest 

soft exceedance was 60 seconds and was provided by pulsed lidar data and the largest exceedance seen by 

the CW lidar was 4 seconds. 

The final group of data provides a distribution of exceedance data into the indicated time bins. The data in 

this sample shows one soft exceedance each between 0 and 5 seconds in duration from the CW and pulsed 

lidars, and one soft exceedance of between 40 and 80 seconds from the pulsed lidar. 
27

# AVOSS Statistics File 

# Start and Stop Date/Time 

 000611 153327 

 000611 154647 

# Num Runs (total and ATMPRO/EDATA/TDATA Good) 

 30 24 30 21 

# Throughput averages (AVOSS, default, increase min/mean/max) 

 33.40 31.44 0.74 6.23 14.34 

# Average spacing values for LS, BS, HS, LL, BL, HL, LH, BH, HH 

 3.658 3.910 4.318 3.767 3.046 3.399 4.572 3.693 3.991 

# Average spacing reduction (from default) for the 9 pairs 

 0.337 1.090 0.842 0.000 1.338 1.975 0.000 1.331 1.033 

# Mean spacing change between consecutive updates for the 9 pairs 

 0.033 0.086 0.086 -0.001 0.037 0.072 0.001 0.015 0.049 

# Variance of the spacing change between consecutive updates for the 9 pairs 

 0.380 0.642 0.736 0.092 0.429 1.000 0.083 0.378 0.573 

# 

# Exceedance statistics: 

# Wake compare TauMin & TauMax are: 50 120 

# Bad file counts (Wake Sensor, Spacing & Predicted Tau): 0 0 0 

# Number of all wake sensor files (lna, lli, wl1, total) 

# Number with no AVOSS prediction (lna, lli, wl1, total) 

# Number with invalid tau values (lna, lli, wl1, total) 

# Number with invalid X or AC_ID (lna, lli, wl1, total) 

# Number of valid wake files (lna, lli, wl1, total) 

 110 164 77 351 

 26 41 35 102 

 12 93 34 139 

 2 6 0 8 

 70 24 8 102 

# 

# Four-line format for Combined and Individual Sensor Statistics: 

# Number of soft buffers (total, positive, negative) & Class 1, Class 2 

# Number of hard buffers (total, positive, negative) 

# Mean and std dev of all buffers (sec) then exceed mean (total, soft, hard) 

# Maximum exceedance time (soft, hard) 

# 

# Combined Sensor Stats 

 11 8 3 91 0 

 0 0 0 

 34.3 40.1 22.3 22.3 9999.0 

 60.0 0.0 

# Pulsed Lidar Stats 

 2 0 2 68 0 

 0 0 0 

 -31.5 40.3 31.5 31.5 9999.0 

 60.0 0.0 

# CW Lidar Stats 

 1 0 1 23 0 

 0 0 0 

 -4.0 9999.0 4.0 4.0 9999.0 

 4.0 0.0 

# Wind Line Stats 

 8 8 0 0 0 

 0 0 0 

 55.5 10.5 9999.0 9999.0 9999.0 

 0.0 0.0 

# 

# Exceedance Distribution 

# Time_Bin Soft: lna lli wl1 Hard: lna lli wl1 

 0 - 5 1 1 0 0 0 0 

 5 - 10 0 0 0 0 0 0 

 10 - 20 0 0 0 0 0 0 

 20 - 40 0 0 0 0 0 0 

 40 - 80 1 0 0 0 0 0 

 > 80 0 0 0 0 0 0

The final output file type discussed is a log of exceedance events. Whenever a negative residence time 

buffer is computed a summary entry is written to this file. The purpose of the file is to provide an index to 

events that merit additional analysis, or during field operations may merit immediate examination of 
28

weather sensor and wake sensor inputs to verify system health. The exceedance log file that corresponds to 

the statistics file above is shown below. Each line provides date, GMT time, the aircraft identification, the 

location of the prediction window involved, the wake sensor identification, the buffer type (soft or hard) 

and the exceedance duration. This data allows rapid isolation of the particular weather data set, wake 

prediction, and sensor file involved. 

991201,172320, DC8, 1702, lna, soft, 60 

991201,174811, B737, 1702, lna, soft, 3 

991201,232112, B777, 84, lli, soft, 4
29

Appendix D – Lab Notes

During the AVOSS development lab notes were kept as a Word document. A slightly condensed version of 

those notes is provided in this appendix as additional insight into the development process and lessons 

learned. The notes are provided in the order recorded, with minor grammatical cleanup and clarification of 

terms. Some material has been omitted that was judged to be insignificant to understanding the system 

evolution or confusing in light of later changes. In some cases this material is more fully explained in the 

text of this report.

Dec 11, 1996:

The idea of AVOSS version 1 is to provide an end-to-end AVOSS system that will:

1. Force data specifications and interfaces of all required systems.

2. Act as a checklist, or discovery mechanism, to list all the areas of work and tasks required to 

develop and operate an AVOSS. This knowledge will be incorporated in later version design, 

add or re-prioritize research activities, or used in a SOW for a contract effort.

3. Provide the first data on the most critical factors and domains (for example decay at the 

threshold) required for spacing reductions.

4. Provide the framework for testing enhanced predictor algorithms and weather systems.

The mechanism for evaluating the uncertainty in wake behavior due to uncertainties in the weather 

is currently simplistic. A brute force method of calling the predictor algorithm with mean weather, 

mean plus n*sigma, and mean minus n*sigma will be used with no attempt to call with different 

airplane weights or search for the worst case combination of conditions. This is a research area in 

itself.

A different default separation matrix is needed at the runway threshold than at the outer marker, 

since there are threshold separation requirements for Small following Large and Heavy. In this 

implementation a default separation matrix will be placed in the parameter file. This matrix will be 

the same for all windows except the threshold, or window 1. The compression algorithms will adjust 

outer marker spacing if required to meet the threshold requirement. 

February 28, 1997:

After a hiatus from AVOSS design, work resumed the week of Feb 24. Processes worked on 

included the steps and order required to go from wake prediction time history to approach spacing, 

and definitions of the diagnostics required from these calculations to assess system level 

performance.

Definitions: Window spacing is the distance or time spacing required at any one window to meet 

only the wake constraint at that window. Approach spacing is the distance or time spacing 

required at the “spacing point”, or outer marker in this case, to meet all the spacing constraints 

along the approach. It takes into account the change in spacing of aircraft due to speed 

differences. 

The final output of the AVOSS (approach spacing) will include the distance needed to 

accommodate space compression. Therefore, when producing the “default” spacing matrix the 

output will contain some cells that are larger than the usually seen matrix. This can be partially 

offset by producing an output of the distance-based window spacing at each window. This output 

has not yet been written into the specifications.
30

July 1, 1997: 

AVOSS is being descoped per program funding cuts. The changes will not be reflected in the 

Version 1 to be deployed at DFW this year. The changes include calculation of CATEGORY 

spacing rather than aircraft type spacing, use of demise rather than decay to threshold. Small 

category aircraft will not be given reduced spacing due to demise. We will need to model fewer 

aircraft types, only enough to bound wake behavior in each category. 

August 19, 1997:

Getting back into AVOSS design after another long gap for project management tasks. Realization 

about current approach to estimating confidence intervals of window spacing: We are only 

evaluating mean and mean +- N*sigma cross winds. It is possible that this will miss the most 

critical crosswind in cases of light cross wind and high sigma. For example, if the crosswind is 4 

m/s with sigma = 3 m/s, and we apply 3 sigma to the calculation, then we will only evaluate wake 

trajectory for -5 m/s, +4, and +13 m/s. This could lead to low window spacing intervals although 

zero cross wind is included in the uncertainty interval and could lead to stalled wakes.

August 22, 1997:

Implement fix to problem noted above: If the magnitude of (N*Standard Deviation) is greater than the 

mean cross wind, then lateral wake drift will not be used to reduce spacing. Vertical motion and 

decay may still provide reduced spacing in this case.

August 25, 1997:

For treatment of variants at DFW, treat the following types as one:

B737, B73F, B73J, B73S will all be considered as one type within AVOSS. The data file labels 

these as B737.

MD80, MD83, MD88, MD90 will all be considered as one type. Data files label these as MD80.

Sept 13, 1997:

Comments from Donner suggest that the predictor code is using the assumption that wake ascent 

rate is tied to circulation, i.e., sign of circulation can reverse. This must be investigated and 

removed from the system if true. There would be obvious dangers from a system that predicted 

circulation sign reversal when sink rate stops.

November 4, 1997:

The following represent a summary of decisions made regarding the AVOSS code rewrite and other 

post-deployment activities:

1. Go to a flat earth assumption. The ground elevation does not differ significantly at DFW in the 

near runway region, and does not effect wakes at far from runway locations. Simplify the 

parameter file, data volume, and internal logic by removing all references to elevation and using 

the runway Z-axis for all altitude references. This would need to be changed in later versions of 

AVOSS either for hilly terrain or if the airport density altitude needs to be considered.

2. The safety corridor will be standardized in terms of the distance from the runway where the floor 

drops to the ground. Previously tying the location to the middle marker and outer marker adds 

unnecessary survey issues and variations. The wake behavior and flight technical error also are 

not effected by middle marker position. The "no floor" position will be set at the point where the 
31

glide slope reaches 200 feet Z, and the approach spacing will be computed at the X location of 

the glide slope intercept.

3. Lateral wake motion will not be allowed as a separation reduction mechanism at distances from 

runway larger than the glide slope intercept. This enables the same reduced spacing on the 

localizer prior to glide slope intercept.

4. The wake predictions and output matrices will not include small aircraft. Small aircraft 

distances will be added as part of the external interface.

5. Wake coordinate transformations will be moved from AVOSS to the sensors. In future 

deployments the wake files will give wake location in runway axis. This also implies changes to 

the wake file header, to be resolved.

6. Difficulties in getting real-time TKE and thermal profiles will be corrected in stages. Since 

thermal profiles are not expected to be first-order effects, the AVOSS re-code will make an 

assumption of a standard atmospheric lapse rate (stability TBD). A fixed TKE value or profile 

will also be provided. Currently we do not know the precise turbulent scale length to use as a 

TKE input to the predictor, and Fred expects significant progress on this in the next 6 months. 

His results will be added when available.

7. Simplify the code and add features in small steps. The first recode will only provide wake 

based separation criteria (no default limit) and will use fixed TKE, thermal profiles. Default min 

and maximum separations will then be added, as will diagnostic calculations.

8. A window class (C++) will be added. The constructor will compute the corridor dimensions. 

This simplifies the parameter file and enables dynamic window creation. Although a window will 

exist at the glide slope intercept, the point of the glide slope intercept itself will be the reference 

point for adjusting approach times. 

9. Change the parameter file and aircraft data to metric units. Review and clean up unused values. 

November 8, 1997:

Discussions with Tom Doyle yesterday indicated that DFW, and a few other airports, have glide 

slope intercept altitudes well above the nominal 1600 feet or so AGL. DFW uses 5000 feet MSL 

(about 4400 feet or 1340 meters AGL) for runway 17C when using the triple approaches. This 

implies two things: (1) the weather system and displays need to reach an altitude of close to 1500 

meters and (2) the corridor needs some redefinition. Using the current corridor floor slope will 

produce a large distance between glide slope and the floor at these large distances. We may need 

to allow the floor to drop below the glide slope to some maximum delta, and then maintain this 

offset at larger distances. 

Nov 12, 1997:

Investigation conducted to determine a method of combining transport and decay times into 

separation arrays, considering the new category-based spacing. Questions were:

1. Do we need to carry each aircraft type through all the time and distance arrays, or just worst 

case transport (T) or transport and decay (TD) time for each category?

2. If we go to using min and max speeds of each category, do we need to use both min and max 

or only one?

Note that simplification from a 20x20 array should be possible, since decay time is no longer a 

function of the follower aircraft type. The investigation determined the following:

1. The worst-case aircraft type may be different at each window. If we only used the worst-case 

time for a category, and a different airplane had a worst-case speed, the final calculations would 

be unnecessarily large. The wake T and TD time must be carried for each generator type until 

the final step of determining category-based spacing.

2. We can simplify the follower axis of the array to category, using only worst case (Vmax) 

category speed for adjusting window times to approach time (assuming that no windows exist 

outside the "Spacing Point" where the approach time is calculated.

In this method we define a "Spacing Point". All window times are adjusted to this point, and it is 

not absolutely required to have a window at this point. The adjusted times are;
32

TSP = TWin + TTG − TTF

where subscript SP denotes Spacing Point, TWin is time at a window, TT is Transit Time from the 

Spacing Point to the Window, G denotes the generator aircraft and F the follower aircraft. The 

values of TT are determined by the compression technique in use. For AVOSS 1.1 this is simply 

the distance covered divided by the average speed, or:

( ) ( )

T T

X X

V

X X

V

SP Win

SP Win

G

SP Win

F

= +

−

−

−

$ $

In the case of a window between the runway and the Spacing Point, the only follower time required 

is the Maximum Speed of all the aircraft in the specific follower category. If we only used one 

generator speed then the minimum category speed would provide the most conservative Spacing 

Point time.

In the case of a window beyond the spacing point, the most conservative time is provided by the 

maximum generator speed and the minimum follower speed. 

For AVOSS 1.1 windows outside the spacing point do not serve a function and will not be allowed. 

Discussion with FAA & industry is required to determine the need for such windows and the desired 

algorithms for using them.

Modify existing Approach and aircraft data classes as follows:

• Change the window XLoc test to disallow any windows at X > X of the spacing point).

• The "spacing point" will be the glide slope intercept point GS_IntX.

• Add a comment to the Approach code that changing the maximum window X limit also requires 

changes to the compression code and a function to return minimum category speed. Add 

similar comment to compression code that minimum follower speed needed if X is outside 

spacing point.

• Add a member function to Acdata to return the maximum speed of any category.

December 8, 1997:

Current code written includes window and approach classes, a modification to Don’s profile 

generator code to allow linear interpolation of wind at any altitude, a mod to Don’s aircraft data base 

to return the Vmax of any aircraft category, and a WSeps class to compute time and distance 

separations. All these currently run together with real-time DFW data.

Don and I are working to get the wake predictor code operational. It is currently linked but not being 

called. It seems to run okay when called with the NWRA C driver code, after we removed the 

commas from the input files. I will write a class based on the NWRA code to call the APA 

predictor. By structuring this such that it passes the aircraft and weather data pointers rather than 

discrete arguments, it should be easier to add additional predictor codes at a later time, i.e. have a 

section of code to select the appropriate predictor, then call the appropriate predictor driver shell 

that has access to all weather and aircraft data. Initial circulation strength is currently computed 

from the aircraft data base speed, ignoring the difference between indicated and true airspeed. 

December 15, 1997:

There is a need for more intelligent residence time calculation. Currently the lateral and vertical 

transport times are kept separate until the last step. This is done in part to diagnose which factor 

(lateral or vertical motion) is most effective in reducing spacing. Several problems can arise:

1. A wake may leave the corridor out of one boundary, then leave the other boundary at a later 

time, then reenter the first boundary. An example would be a wake that sinks below the floor in 
33

50 seconds, leaves the lateral boundary at 75 seconds, then bounces and reenters the vertical 

limit at 90 seconds. The final residence time produced by the current method would either be 

75 seconds or 9999, even though the wake has been continuously out of the corridor since 50 

seconds.

2. If a circular or elliptical corridor cross section is devised then the lateral/vertical numbers lose 

their meaning.

3. Currently the wake predictor track search engine returns 9999 for any Tau whose exit criteria is 

only met in the last data time, or is never met in the file. This can cause unnecessary increase 

in spacing when a predictor is run for 3 weather cases. For example the vertical transport time 

may be valid for two weather conditions but 9999 for the third due to a different wake factor 

causing the track to terminate before the wake sinks below the floor. In this case 9999 would 

be returned at the wake transport time, and is overly conservative.

Consider replacing the lateral/vertical times with a residence time instead, or add left/right residence 

as two additional values. This may be done in the next version of the AVOSS, but for this version 

the lidar files should have two extra values added, Transport Port and Transport Starboard. This 

would produce a line of 8, rather than 6, variables.

Times: Horizontal, Vertical, Transport, Demise for port then starboard.

December 16, 1997: Draft rules for derivation of the various wake residence time parameters, from 

either wake sensor or predictor algorithm.

General: The times produced will represent the time at which the sensor or predictor data verifies 

that the particular wake characteristic (i.e., demise, lateral motion, vertical motion, or overall 

transport) meets the criteria for safe aircraft passage. The time should not represent the last time 

at which the wake could be sensed or quantified. For example, if demise is defined as an observed 

circulation of 90 meters squared/second, the predictor and sensor demise values will reflect the 

time at which the wake is observed at a strength below 90. Failure to observe the wake at all 

cannot be construed as meeting the demise value. This position may be altered in later versions, if 

adequate sensor or predictor validation demonstrates acceptable probability of detection. When a 

particular wake characteristic cannot be quantified then the returned time should be 9999.

The wake predictor currently in use provides time histories of wake motion and strength. The 

returned time values for transport or demise represent the latest time at which the predictor places 

the wake position or strength outside the safety region. If the wake track has no data points 

outside the safety region, or only the last point in the file is outside the safety region, then 9999 is 

returned as the time value. At least two points outside the safety region are required. If the wake 

reenters the corridor the first exit will not be returned. The final time value will reflect the last exit 

from the corridor. 

The algorithms used by the predictor code and the wake sensors to determine these times from 

wake tracks will differ primarily in the need to handle noisy data. Predictor algorithms in general will 

provide smooth wake tracks, while sensor data will provide sensor position plus measurement 

variance. 

Demise Time: A value (WLIMIT) of observed circulation that represents wake demise will be 

provided. This value will generally be in the range of 50 to 90 meters squared/second during the 

AVOSS program. The wake predictor will return 9999 for demise time if the prediction run 

terminates prior to two data points being below WLIMIT. If at least two data points are below 

WLIMIT in strength, the first time that the wake is below this strength will be returned.

The wake sensor data should be processed similarly, except that, for this program, the strength 

data may be smoothed prior to the WLIMIT test, or other sensor specific processes may be 

employed to best estimate when the demise has occurred. In the case where a wake track is lost 
34

prior to strength reaching the WLIMIT value, extrapolation may be used provided the following 

conditions are met:

1. A quality wake track has been maintained at least X seconds prior to wake loss. 

2. The wake circulation strength was no higher than Y meters squared/second prior to track loss.

3. The extrapolated demise time is not more than Z seconds after track loss.

4. Suggested values of X, Y, Z: 15 seconds, 110 m^2/s, 10 seconds.

The intent is to provide a demise time value when the sensor data almost tracks the wake to 

demise, but limit the degree of extrapolation allowed. Each sensor team must document the 

method used to filter data and provide demise times for later transfer to FAA, ATA, ALPA groups.

Lateral Transport Time: A value of Ylim is used to describe the lateral extent, from runway 

centerline, of the safety corridor. This value ranges from about 45 meters at the runway to over 200 

meters near the outer marker. The predictor algorithm will return a lateral transport time of 9999 if 

the wake is still less than Ylim from centerline at the end of the track, or if it exits only at the last 

data point. The wake sensor data should perform similarly. If the wake track persists until the 

wake has left the corridor (at least two data points), return the first time that the wake leaves (and 

stays out of) the corridor. In the presence of noisy data, sensor specific track filtering may be 

employed, or a process whereby at most one point reenters the corridor after exit can be used. The 

process must be documented for description to industry groups. If the track is lost prior to corridor 

exit, return 9999.

Vertical Transport Time: A value of Zlim is used to define the Z coordinate of the safety corridor 

floor. This value is zero near the runway, preventing separation reduction due to vertical transport. 

The predictor and the wake sensors should process this data in the same manner as the lateral 

transport, that is return 9999 if safety corridor floor exit cannot be shown, and return the time of the 

final corridor exit if that time can be determined. The wake sensors may perform filtering of noisy 

data.

Transport Time: Due to the ability of wakes to depart and reenter corridor vertical or lateral limits, 

simple processing of lateral and vertical wake motion times may produce overly conservative 

residence time values. An example is a wake that sinks below the floor at 50 seconds, exits the 

lateral wall at 70 seconds, then bounces and reenters the vertical boundary at 75 seconds, while 

still outside the lateral boundary. In this case the vertical transport time would be reported as 9999 

(assuming the wake never sank below the floor a second time) and the lateral time would be 

reported as 70 seconds. Combining the two values would produce a residence time of 70, although 

the corridor was free of the wake at 50 seconds. A test that uses lateral position OR vertical 

position to derive an overall transport time will also be applied. The same rules for returning 9999 in 

the absence of confirmation of corridor exit and treatment of noisy data will be followed.

January 28, 1998:

Examination of first runs of AVOSS in early January indicated that the predicted spacing is rarely 

less than today’s standards. This was particularly true for any aircraft following a large generator. 

Likely reasons:

1. The Lincoln Profile Generator continues to provide a standard deviation “bloom” at about 50 to 

60 meters. The large standard deviation combined with low cross wind will disable the use of 

wake lateral transport. This is likely a major cause since windows 0 and 1 frequently showed 

very small required spacing (less than 1 mile) while window 2 usually showed a much large 

requirement. Window 2 is at x=843 meters which gives a glide slope height of 60 meters, 

which is the altitude of the standard deviation bloom. Lincoln sent an email on 1/27/98 saying 

that a bug in the PG code was just corrected and should fix the bloom. We have not had time 

to evaluate the change.
35

2. The large category contains the ATR-72. The wake from this aircraft will have a small sink rate 

compared to the other large aircraft. This raises the question as to whether this aircraft should 

be a constraining factor for the small commuters.

3. The wake predictor code is not yet highly validated or accurate in ground effect. Not all factors 

are modeled yet (shears, formation of wakes in ground effect..).

4. The files examined were produced by early code that does not read the parameter file. There is 

a little uncertainty as to whether we were running corridor option 1 or 2. The output file headers 

say 1 but 2 was intended.

February 19, 1998:

Performed examination and verification (by hand calculation) of system outputs using the profile 

atmpro_17C.980213_134255. Verification consisted of taking the raw wake track outputs, manually 

determining transport and decay times at each window for each aircraft, manually computing 

window spacing and approach spacing using the aircraft data base and profile headwinds. All 

checked values were correct (spot check of spacing matrix elements, including all followers behind 

B757 and heavy for Transport & Demise and all followers behind large and 757 for transport.

Observations:

1. The Fortran APA routine did not compute a wake track at all for the AT72, leading to 9999 tau 

values for the large generator. Wakes generated low always seemed to level at exactly 15.00 

meters altitude with no bounce or oscillation. Why?

2. While the B747 had the worst case wake demise time, when adjusted back to the spacing 

point the EA34 created the worst case approach spacing. The difference in time was about 16 

seconds, or about 0.6 miles. The difference was due to the lower assumed approach speed of 

the EA34 and the fact that the limiting window was near the runway. More space is then 

required behind this airplane at the spacing point. This implies we cannot simply model the 

demise of the worst case generator in the AVOSS system, as previously assumed. The 

interplay of wake behavior and aircraft operations procedures may create a different worst-case 

airplane.

3. The sign of the cross wind changes with altitude in this profile. This implies the possibility of 

predicting low transport times at several windows, and not catching a large transport time at a 

location (altitude) between the windows where the wind is lighter. Potential solution: Only use 

vertical wake sinking above some minimal altitude such as 150 to 200 meters, and either use a 

dense window structure or create a special window if a low cross wind condition is detected.

4. Wake sink time was always less than 50 seconds in this case (at windows where sink was 

possible). Does this also argue for simplifying the system to only using wake sink and demise 

(not lateral motion) above some low altitude, with a safety system to detect conditions that will 

arrest the sink rate?

5. Window 2 (843 meters) always failed to provide reduced spacing in this run. The cross wind 

was only 0.5 m/s, variance was 0.46, and there is no corridor floor.

The predictive algorithms are not yet sophisticated enough to detect situations that will prevent 

normal wake sinking.

March 24, 1998: Development in moving the residence time calculation function to the sensors: 

RTI found that in some cases the wakes are generated outside the safety corridor in VMC 

conditions. The logic they will implement is that if a wake pair is generated outside and drifts in -

apply normal rules to exit time. If the wakes never enter the corridor, use 9999 for the time. This 

raises the issue of revalidating prior aircraft localizer tracking statistics in IMC conditions, and 

perhaps verifying the safety corridor size in VMC to reflect the larger dispersion.

March 25, 1998: Dave Burnham advised that additional fields may be required at the end of each 

residence time line in the wind line wake files. In some cases the wind line may not detect wakes 

until AFTER they have left the corridor lateral limits, due to the requirement that wakes settle into 
36

the proximity of the array before they are detected. If they simply report the first time the wakes are 

detected outside the array, they may greatly over estimate wake residence time. 

April 17, 1998: We are working the issue of introducing the “most appropriate” turbulence data into 

the APA predictor algorithm for real-time AVOSS, to be used until more is learned about turbulence. 

Lessons:

• The APA predictor turbulence input “q” should be Sqrt(2*TKE). NWRA uses the 1-minute TKE 

average at the tower top. 

• NWRA has altered gain 3 in the Greene equation to be 0.41, rather than the original 0.8199. 

They say it provides better correlation to data. Fred/Sarpkaya are unsure.

• Don Bagwell is creating code to take the tower top TKE and load the QDATA file with q. The 

issue is - grab the last one minute TKE, create a running average of the last 15 1-minute 

averages, or other?

None of these is actually implemented at this time in the real-time code.

April 17, 1998:

The lidar wake files received from RTI do not fully comply with the file specifications. These 

problems were discovered by Metin:

1. The scan plane X values given in the files do not correspond to AVOSS-defined windows. The 

explanation from RTI is that they had to tweak the scan azimuth to avoid poles, trees, etc. 

Why was this not communicated to AVOSS while in the field in September and how do we 

prevent future misunderstandings?

2. More than one wake track in a given file at times. 

3. Beacon times provided by RTI do not agree with beacon times provided by Lincoln for a given 

window. Metin will use Lincoln times.

April 24, 1998:

More discussion with Lincoln/RTI/Metin: The event correlation process only tags files with aircraft 

type if the estimated passage time is within 30 seconds of the ATC radar beacon time. This was 

first discovered with the Volpe wind line when it was brought back on line and Lincoln was not 

tagging the files with aircraft type. For deployment we need:

1. Positive assurance of coordinated clocks, at all sensors and ITWS network, wake network and 

CTAS network.

2. Automated process to open files and notify us if aircraft tagging is not taking place.

3. Investigate more positive means of determining aircraft passage time at the sensors.

Note: The event correlation process uses ATC radar beacon data to determine aircraft passage 

time at each wake sensor scan plane. The sensor provides an estimated aircraft passage time 

which may be in error, i.e., the sensor may not detect the aircraft until the wake is first detected 10 

or more seconds after passage. The event correlation process examines the sensor-estimated 

passage time and the ATC data derived time and then corrects the wake file residence time values 

and wake time history data time tags.

May 3, 98:

Two issues have surfaced that will need attention in the system validation or test-bed phase:

1. Currently the system will not allow lateral wake drift to reduce spacing if the cross wind 

standard deviation exceeds the mean. Donner pointed out that it might be possible for lateral 

drift to be used if the standard deviation is set to zero (for example in parametric runs with 

canned data) and the cross wind is very low or zero. This is not an issue in real-time 

operations with the current system, as the standard deviation is always substantial. In the testbed there may be another test required, to prevent spacing reduction if the port/starboard wakes 

are predicted to go out opposite sides of the corridor. In parametric tests, we need to make 

sure that some small standard deviation is included.
37

2. The NWRA predictor uses the (false) assumption that any wake that has stopped sinking has 

also gone to zero circulation. Sarpkaya pointed out the danger of this assumption. NWRA 

replied that they intentionally make use of this assumption since, in their words, wakes are not 

observed to last long once the sink rate is arrested. This comes into the predictor via the 

stratification term. This assumption must be revisited in the test-bed, and proper predictions 

taken to maintain safety.

May 26, 1998:

The APA code has recently been revised per instructions from NWRA to improve stability and 

switching from one phase to another.

A quick sensitivity study to the Demise Definition was conducted today, using the canned QDATA 

then q = 0.50, 0.90, and 1.20 at all altitudes. These values were estimated from TKE plots from 

Memphis (q = sqrt(2*TKE)). Night smooth air provides TKE about 0.10 and the highest "eyeball 

average" in the day is about 0.7. This provides the q limits of 0.5 and 1.2. At any one q value, the 

sensitivity of separation to demise values was less than expected (to be quantified later). One 

problem resurfaced: The NWRA APA code seems to be terminating prematurely due to sink rate 

approaching zero, with circulation still high. For a B747 with q = 1.2 the wake track stopped at 61 

seconds with circulation = 187 and altitude stalled at 26 meters. 

A very interesting observation was seen at q = 1.2. In this case the following distance of a large or 

heavy, behind a B-757, was less than the following distance behind a Large. This turned out to be 

due to wake sink rate. The B-757 produced a wake that sank below the corridor floor quickly, 

before the demise value was reached. At 70 to 80 m^2/s the distances behind the B757 and large 

were similar. At larger values of demise the separation for large generators was less than the B757. 

At low demise values much more distance had to be allowed for large generators than for B757 

generators.

Approximate sensitivity of separation distance to demise value, using demise interval 50 to 90:

At q = 0.50 slope is 0.14 to 0.18 nm per 10 m^2/sec of circulation.

At q = 0.90 slope is 0.08 to 0.18 nm per 10. The 0.18 was heavy behind large. If we only include 

the classes that matter, the slopes were about 0.09 nm per 10.

At q = 1.2 slope is significant for large generators, about 0.24 nm per 10 m^2/sec. For B757 

generators it is very low, about 0.07 nm per 10. Cannot assess slope for heavy generators due to 

premature APA termination, before demise.

June 11, 1998:

Tests a few weeks ago showed that the predictor was terminating too early (60 seconds) for some 

aircraft in ground effect. NWRA provided constant changes to prevent phase termination (moved 

from a 60 second limit to a 120 second limit) and this was implemented by CSC. CSC delivered 

yesterday AVOSS Version 1.6, which includes spacing limited to minimum threshold and maximum 

values.

In preparation for AVOSS sensitivity runs, and to document the potential temperature feature Vs 

sensible temperature, the following was provided by NWRA:

“The algorithm accepts both sensible (in deg C) and potential temperature (in deg K). If the first 

line of the TDATA file is > 0, then sensible in assumed; if the first line is < 0, then potential is 

assumed. Note that the first line is a single number, NDATA, which gives the number of following 

points in the profile. In the case NDATA < 0, the algorithm reverses the sign and goes into the 

potential temperature mode.”
38

12/9/98: Case study 1 (see zip file). While trying to duplicate a JFK3 run locally (weather file for 

981021_164808) on the PC, I found a case where the results were identical to the field data, except 

for the small following large. The field data produced 2.91 nm while AVOSS produced 4.31 nm with 

default windows, and 2.91 nm with the extra window added at 642 meters. The input files and EXE 

file were zipped into Labbook_Case1.zip. I am using version 1.62 with the new flags (disable 

vertical or lateral) off.

12/14/98: Found two bugs. One in WSEPS will cause a "9999" window residence time to be 

overwritten with a lower value, only if a window has been added after the default set, and at least 

one default window produces 9999, and the added window has a lower time. This error occurs in 

the code that finds the maximum of all window adjusted residence times for the approach. This bug 

does not effect any of the DFW data as we have only used the default windows there to this date.

A second bug is in the spacing limiting code. It computes limit approach spacing from the min and 

max window spacing at each window, then uses these approach limits to limit the computed 

approach time spacing. In the case of reduced spacing at windows near the runway but large 

spacing at some other window, this calculation tends to use FAA default spacing (i.e., 4 nm) rather 

than the actual required threshold spacing (i.e., 2.5 nm) and produces larger approach spacing than 

it should. This makes the AVOSS performance to date conservative, as the error will always 

produce an approach spacing that is equal to or larger than needed. Software request 9A corrects 

this error and delivers code version 1.7.

December 20, 1998:

Another numeric issue with APA: I found a situation where I could find no cross wind value that 

produced a spacing for small followers other than 2.5 or 4 at window 0. At one point changing the 

cross wind by 0.1 m/s caused the spacing to jump between lower and upper limit. Examination of 

residence time outputs and wake tracks showed that the wakes of some large aircraft were 

decaying to zero at almost the exact same time of leaving the corridor. Since the APA algorithm 

stops when the circulation gets to zero, a very tiny change in inputs caused the wake predictor to 

either clear the corridor in about 54 seconds, and give 2.5 nm, or decay while still in the corridor, 

and give 4.0 nm. For production we need a predictor that can carry the motion out farther in time, 

regardless of strength, or we need to get away from explicit equations of motion such as this and 

predict drift or other factors separately as far as possible. Can NWRA modify the code such that 

lateral drift of the wake is modeled out to at least 90 seconds, even if the circulation goes to zero?

December 23, 1998:

Potential third corridor option: Rationale - shape the floor such that the transition point (Xt), where 

the floor steps from Z = 0 to Z = K, is such that the initial floor height completely removes ground 

effects on the wake drift, sink, and decay rates. This offers the potential to apply simpler predictors 

beyond Xt, or to apply default behavior with subsystems that look for exceptions (shears, strong 

inversions, etc.). Per discussion with Fred, a conservative altitude, above which ground effect is a 

non-issue, is 1.5 or 2*span. The largest span is 65 meters for a B747-400. Determine the Xt and 

floor height and clearance (FP_Z - Zlim) for the following conditions:

1. The floor is at the bottom of the glide slope limits for a typical 1.4 degree wide, 3 degree glide 

slope that intersects the runway at X = -305 meters (0.7 degrees below glide slope)

2. K values (floor height at Xt) of 65m, 100m, 130m (1, 1.5, and 2 * span)

Set K = (Xt + 305)tan(2.3 degrees). Then FP_Z is (Xt + 305)tan(3)

K Xt, meters Xt, nm FP_Z FP_Z - K Ylim*

65 1313 0.7 85 20 51.7

100 2185 1.2 130 30 62.8

130 2932 1.6 170 40 72.2
39

Note that Ylim is based on the current corridor lateral shape, which is defined with Xt = 843. A new 

floor or definition of Xt may require revisit of the point where the lateral corridor begins to widen. 

Each of these options provides wake clearance at Xt if the following aircraft is full-scale low on the 

glide slope and the wake is below the floor, but only with the core of the wake. Some influence may 

still be felt. Given that typical sink rates are 1 to 1.5 m/s and runway occupancy time is about 50, 

a larger initial floor height is appropriate to allow for lead aircraft flight technical error and provide a 

greater buffer with the wake , without sacrificing performance. Therefore a suggested initial floor 

shape is to set K = 130 meters. The tradeoff is that the lateral limits are getting wider, and vertical 

motion is being ignored inside the Xt point. This may create a bottleneck in the altitude region of 

about 60 to 130 meters, where vertical motion is ignored, decay is not being sped up by ground 

effects, and drift is less effective due to wide lateral limits. This argues to select K of 65 to 100 

meters.

1. Consider a floor definition that provide the following inputs:

2. Glide slope intercept on runway and angular limits.

3. K

4. Minimum value of (FP_Z - Zlim).

5. Altitude of initial glide slope intercept.

6. Floor distance below FP_Z at glide slope intercept.

The algorithm then computes Xt, and Zlim at any X location.

January 8, 1999:

Will need more thought on corridor reshape noted above due to:

1. Fred Proctor's AIAA paper suggesting ground effects may extend up to 3 spans

2. Realization that ignoring sink up to high altitude will create a wide corridor at that point, 

requiring substantial cross wind. In other words this could create a region on the approach 

where ground effects are not expediting decay, where wake sink is ignored, and a substantial 

cross wind is required due to a wide corridor.

3. Current project reassessment leading to the conclusion that this type of optimization may need 

to wait for the follow-on due to limited resources.

Version 1.7 was delivered today and checks against hand calculations. 

2/17/99: Reviewing predict.cpp code for NWRA and revisited the test to skip rerun of APA (runs 

with mean plus & minus N*Standard Deviation wind). One condition for skipping is that the 

horizontal transport time of both wakes is greater than the vertical times for those wakes. The 

premise is that, since the rerun will not change the vertical time with this predictor algorithm, and 

can only increase the horizontal time, there is no need to rerun. This test must be removed if a 

predictor is implemented that varies the wake sink rates between the different weather conditions, 

i.e., shear terms.

2/18/99: Steve Riddick has found that there is a positive spike in throughput as cross wind is varied 

and TKE = 0 in his batch sensitivity runs. The spike used to occur at zero cross wind, due to 

wakes drifting out both sides of the corridor, and the fact that the batch runs can use identically 

zero mean and standard deviation. I modified his batch code to ignore wake drift if cross wind 

magnitude is less than 1 m/s. Now he sees the spike at 4 m/s cross wind if standard deviation is 4 

m/s, and at 2 m/s if standard deviation is at 2 m/s. Throughput increase is zero as the wind 

increases to the value causing the spike, the throughput increase then jumps to about 6% when 

mean = standard deviation, then drops again to a low value (cannot see that point on the contour 

plot) for about 1 wind mean value, then increases rapidly to > 10%. 

Tentative diagnosis: The test that determines if lateral drift should be disabled consists of 

multiplying the mean by the (mean + standard deviation) and testing for the product < 0. The test is 
40

repeated for mean*(mean-standard deviation). If either test is true then lateral drift is disabled. In 

this case the mean and the standard deviation can be identical, therefore the product equals zero 

(fails < 0 test) and lateral drift is enabled. At this wind condition, all three crosswind values run 

through APA produce significant wake drift, either due to strong wind or due to zero wind. In other 

words, the uncertainty technique being used fails to find the worst case drift in this situation. 

To verify diagnosis:

1. Run these cases with the unmodified version 1.7 software. The results should be the same at 

these wind/standard deviation values.

2. Examine the residence time output files at the wind value causing the peak and the first wind 

value each side of the peak. At the peak wind value the low-altitude horizontal residence times 

should be low (on order of 60 seconds) while at the wind values each side of peak the same 

values should be high (greater than 80 seconds or 9999). 

3. The best test would be to find the aircraft exhibiting the characteristic in (2) and then examine 

the wake trajectory files. At the wind value causing the peak throughput the wake should be 

observed drifting out opposite corridor walls.

April 8, 1999:

Software upgrades will be requested to fix several small issues:

• Fix the wind mean/standard deviation test noted above.

• Use the absolute value of the line count in TDATA files, since the nowcast uses negative values 

to signify potential temperature.

• Repair APA to use temperature in Kelvin

• Remove old lines from predict.hpp (// #define for nzmax and ntmmax)

• Correct Asearch bug, change array index from 6 to 8 for reset of 9999 values.

April 13, 1999:

NOTICED: that the computed demise time of the right wake is sometimes equal to the last time in 

the wake track file, even when that strength is above the demise definition!!!

Found bug, when the Asearch function in Predict.cpp was modified to include a separate demise 

value for validation, an array index to rest Tau array values to 9999 was not changed from 6 to 8. 

Therefore the last two values (right demise and demise validation) was set to the last time in the file 

as long as the number of points (ntm) was above the threshold for doing the residence time search. 

Added to list of changes above.

4/14/1999:

Also found that the Asearch logic will return 9999 for a time value if the demise or residence 

threshold is already satisfied in the initial condition. This only surfaces for the validation demise 

definition for the ATR-72. The initial strength is about 121 and the validation threshold was set to 

150, the validation time produced is 9999 while the actual demise is at a less time.

4/21/1999:

An AVOSS design meeting was held with the NASA lidar team on 4/21/99. An update meeting was 

held on May 3. 

Decisions:

1. We will keep the nowcast weather system and the observed weather system isolated from each 

other in this build. No link from nowcast to thermal profile.

2. We will not send ATC beacon data to the NASA lidar

3. We will not pursue new hardware for the lidar, i.e., laser range finders to detect aircraft 

passage.
41

4. There will be no 3rd corridor option during the TAP program. Therefore the third line of 

residence time values in the wake data file may be used for other data. These values must be 

integer.

5. Two methods of computing demise time will be implemented. Method one is the current 

process of providing the elapsed time at which the wake was observed below the demise value. 

Method two provides a single demise time for both wakes, and is defined as the elapsed time at 

which the corridor does not contain any wake above the background ambient turbulence level. 

The threshold for ambient turbulence and the demise value will be provided on the third 

residence time line in the wake files.

The following items are potential add-ins to the wake file, all could go on the 3rd residence time line 

(as integers):

1. A value to indicate if the sensor-provided pass_time1 is accurate enough that the event 

correlation process should not be used to adjust aircraft passage time in the file.

2. One or two values to indicate the sensor detection threshold, and whether the threshold is 

driven by ambient turbulence or lidar performance (i.e., lack of signal return)

3. A word to indicate that the wakes of more than one aircraft are in the corridor at the same time 

and cannot be separated.

4. A quality word to indicate that the data is considered poor or unreliable for some reason 

(suggest using zero for good data, and non-zero for bad. This lets us define different values to 

indicate the reason, i.e., error numbers.

5. Demise time defined by absence of detectable wake in the corridor, as defined by the threshold 

provided by item 2.

Thoughts on variable demise value:

1. Requires QA or probability of detection values to ensure that the wake really is not there when 

it’s not observed.

2. In very calm air the threshold could go down near 50. Is this over-conservative? Would we want 

to make it equal to ambient turbulence with a floor of about 70 to 90? 

3. Does AVOSS need to know the value? AVOSS could make the demise value dependent on 

wind or EDR. We could also keep 90, knowing that strong winds will cause rapid decay and 

reduce the sensitivity to the demise value, while low turbulence will cause such a long lasting 

wake that the value does not matter. The latter assumption may not be true in all 

environments, that is, AVOSS may produce a decay to 90 that reduces spacing, while the 

wake may be observable to 70 for a longer period.

4. As part of the quality assurance, can the lidar continuously, between tracks, provide automatic 

gain control and verify detection as the threshold is lowered?

4/22/99: Draft QA information for real-time system:

This is a set of draft suggestions for the QA status content to be provided in the next AVOSS 

version. The ground rules for a status bit are:

1. The information relates to the quality or confidence of the wake predictions and spacing 

predictions provided by AVOSS.

2. The information is readily determined by each subsystem (wind, thermal, turbulence).

The format for packing QA status and placing it in the data files is TBD. This is a draft for the 

information content only. Please look this over and let me know if it makes sense from your 

subsystem perspective. Should any items be removed, added, or modified? (NOTE: remainder of 

email message with proposed flag definitions is removed. See current ICD for implemented flag 

definitions.)

4/28/99:

Steve Riddick proposed the following cross wind lockout logic for preventing wake drift use in light 

cross wind:
42

To detect occurrence of the region mean-standard deviation to mean+standard deviation overlapping 

the region -min to +min (i.e. where min is a minimum allowable cross wind such as 1 m/s), use:

((mean - standard deviation) <= min) AND ((mean+standard deviation) >= -min))

If the result is true then set Sigtest = 1

This works. Question: Is lock out of the wake drift when the (mean - standard deviation) is below 1 

too restrictive, when the uncertainty include sensor noise as well as the actual wind standard 

deviation? Example: cross wind mean 4 m/s with 3 m/s uncertainty?

Decision: Flag this as a safety issue to be addressed in the AVOSS follow-on with industry input. 

For now, assume that the lateral drift is disabled if Steve’s test is true, but use a value of min closer 

to zero. The value will be defined in the code as a variable and changeable at compile time. The 

initial setting of this value will be 0.5 m/s. (Note: The cross wind lockout threshold was set to 1.0 

m/s).

Rationale, Notes on EDATA Formats

Note from 5/24/99: A discussion was held between Dave Hinton and Tim Dasey on 5/24/99 

regarding the tower flux file and EDR data. Summary:

1. The current Lincoln AWAS process determines wind standard deviation using a 30-minute 

standard deviation of 1-minute wind means. The current fluxpac process uses a 30-minute 

variance of the 10 Hz data to compute TKE. The latter is believed to be anywhere from 0 to 

50% larger than the AWAS process, with little difference on sunny summer days and large 

differences in mechanically generated turbulence on stratiform cloud days. Lincoln may look at 

some data to determine the magnitude of the differences.

2. The AVOSS has no real need for 5 or 15 minute averages or variances, nor for 5-minute file 

updates. The 15-minute average is a hold-over from the first average period used and the 5-

minute update a hold-over from the fact that the AWAS has been processed at that interval. 

Reconsider, for AVOSS, only seeing the 30-minute updates with only 30-minute period values. 

Include both versions of TKE in this file, standard deviation from 30 1-minute wind values and 

TKE from 30 minutes of 10 Hz data.

3. The scientific data format can remain as-is or changed to add new variables. This data can 

continue to arrive at 1-minute updates while 30 minutes are provided to AVOSS. 

4. The 3 and 10 meter savpac data is also needed within AVOSS at 30 minute updates to support 

EDR profile data. The NCSU/NWRA EDR profile code will run within AVOSS.

5. I need to check with Don or Sarpkaya/Proctor to resolve:

(a) Should we remove the start time and stop time fields from the fluxpac files, since they 

are not really used, or keep them to prevent changes to file readers?

(b) If Sarpkaya and/or NWRA derive a relationship between EDR and TKE that affects 

wake sink motion, which wind standard deviation do they need (30-minute average of 1-

minute winds or true TKE based on 10 Hz data)?

6. The current Lincoln system timing is such that the AWAS and other files (flux, savpac) will 

generally become available on the hour and half-hour, plus a few seconds for processing and 

writing, say at 30:30 past the hour.
43

Notes on 5/25/99:

1. Sarpkaya replied and suggested that he would like to see a 30-minute course TKE calculated 

from an average of 6, 5-minute TKE values. He would compare that to a 30-minute EDR.

2. Consideration: Plotting of sensor data Vs AWAS profiles may require getting the 5-minute or 1-

minute tower wind data every 5 or 1 minute. The AWAS file however, is only required every 30 

minutes.

Notes on 5/26/99:

Sarpkaya indicted interest in TKE_fine only and Mike Kaplan (nowcast) can provide TKE_course 

only. We will drop the TKE_course from the flux file. It can be synthesized later from the AWAS 

profile, since the U and V variance will be contained there. I also decided to split the two competing 

time average data into two file versions of flux and savpac, one at 5 and one at 30 minutes, and have 

them written to two different folders. Tim and Don concurred.

The U, V, W wind components that are provided at 5-minute periods are used for display and 

comparison of sensor data with AWAS profiles. The data provided at 30-minute periods are used in 

AVOSS wake predictions. Only the updates on the hour and half-hour are used for wake 

predictions.

----- End EDATA format notes -------

6/8/99:

Notes for future enhancements:

Al Zak suggested using rain data to determine how to treat the radar profiler RASS data. He is 

seeing thermal biases due to rain and can select a different RASS set in these conditions to get

better thermal profiles. Resources do not allow this level of maturity for the demo system, but 

detailed consideration of all sensor QA issues needs to be revisited for follow on deployments. For 

this demo we will understand that rain, thunderstorms, etc may contaminate sensors.

6/15/99: Note for future enhancements to software:

Currently the disable of drift or sink or demise for spacing reductions is applied at all altitudes. This 

should be made an altitude-dependent feature, perhaps by making it a property of each window. 

Parameter file flags could alter all windows, or weather QA and other considerations within the code 

could set individual windows. In other words: make weather QA a function of altitude and make 

ability to disable lateral, vertical, or demise a function of altitude.

Rewrite the WSEPS function to pass disable flags to it, rather than altering residence time values 

prior to WSEPS. This would allow more modular programming. Once the residence time array is 

calculated then WSEPS could be called as many times are required to get full-feature spacing, 

default spacing, or selectively disable wake factors. In this case WSEPS should probably pass a 

single spacing matrix back to the program, and write a spacing file for each call with both window 

and approach spacing values.

BETTER YET: Currently the ability to disable one wake factor by resetting the appropriate Tau 

value to 9999 is distributed between predict.cpp and wseps.cpp. Strip these functions out of those 

modules and write a "policy.cpp" module that sits between predict and wseps. After this change 

the predict module would ONLY provide residence time based on wake motion and corridor 

geometry, the policy module would examine those arrays and any weather QA data to reset or 

condition times, and wseps would use these to compute spacing. It may still be necessary to pass 

a category specific demise definition or disable demise to allow the small aircraft special case. 

Also, the "wide" window at the top of the approach would be a "policy" implementation and the 
44

windows themselves would not get wider there. These changes will NOT be made for the 

demonstration Version 2 due to time and resources available. We will live with the current 

distributed logic.

8/23/99:

AVOSS V1.7 uses disable_vert and lateral flags in predict.cpp to condition the residence time 

arrays, while demise lock out for small aircraft is hardwired in wseps. This V1.7 technique means 

that Pred_Tau contains times based on lockout of wake factors (actual wake motion time is lost). 

This is acceptable but implies that if sensor observed times are compared, and if motion is disabled 

in the prediction, then the prediction error (buffer) statistics will be biased. This is not a major factor 

in 2000 since the demo will use all wake factors, and batch studies do not have the real-time 

sensors data to compare to. For enhanced flexibility in the future, suggest removing disable’s from 

predict and placing in Wseps.

October 7, 1999:

Noticed another challenge in automated comparisons of predicted and observed residence time, due 

to process of taking the maximum of left or right wake as the pair residence time. Assume 

Left Right wake

predicted lateral times are: 50 sec 9999 sec

and observed are: 9999 90 sec

Both agree - the left wake drifts rapidly and the right wake hangs around. If a comparison process 

were to compare the 50 sec prediction with the 90 second observation though, we would 

inadvertently get an exceedance of 40 seconds.

Also, the wind line will set residence time = first observed wake time, if the wake is first observed 

outside the corridor. This may commonly happen when the wakes are rapidly drifting and do not 

sink to the wind line until they are clear of the corridor. The actual residence time in this case will 

be less than the reported time, but this will create havoc with automated wake prediction scoring by 

detecting exceedance where none exist. In this case the sensor can verify that the corridor is clear, 

but not when the exit happened. (Note: this was later corrected in the wind line logic by reporting 

9999 drift times if the wake is first observed outside the corridor.)

10/14/1999

Current issues:

(1) wake residence time. Comparing wake residence time is proving to be a coordination challenge. 

Different techniques are needed depending on the application (scientific validation of both wakes, 

just prove that the corridor is free, validate the worst-case wake). Different and novel techniques are 

in use by the different teams. One will set residence time to the first time observed, if the wake is 

already outside the corridor when observed, while another will write 9999 due to undeterministic 

clearance time. Another will fit a track to the date and backwards extrapolate to get the clearance 

time. The issue of estimating the residence time of the worst-case (critical) wake Vs both wakes 

has not been addressed. An issue with providing residence times based on first detection outside 

the corridor is that the actual residence time may be close to that predicted, and be much less than 

the time of first detection. The result when returned to AVOSS is an erroneous “exceedance” 

detection. Possible system solutions:

1. Go back to passing wake tracks to the main system and then use consistent algorithms to 

curve fit, adjust times, etc. to get residence time. Disadvantage: We only pass a small 

subset of the data available at the sensor (confidence, signal to noise, etc. are not passed) 

and the sensor team is better suited to use all available data for a best estimate. 

Advantage: Common processes at the AVOSS. This will not be done in this program.
45

2. Require that any wake detected outside the corridor receive residence times of 9999, to 

prevent false exceedance detections. Allow very minimal extrapolation for data to the 

corridor.

3. The current method of comparing wake residence times will discard a wake file if both wake 

times are 9999, even though the prediction might be for default spacing and the 9999 may 

be due to wakes still alive after several minutes. Provide for a residence time value to 

indicate that the wake was definitely still alive inside the corridor at a time equivalent to 

default spacing. Do not use 9999 for both bad value and long residence time.

The entire concept of matching wake data to predictions (aircraft type, port VS starboard wake, 

tracks Vs residence time) needs fresh evaluation. Also, the use of "9999" to indicate that the wake 

has not left the corridor creates validation problems. The use of this value both for "bad data" and 

for "no corridor exit" prohibits meaningful validation when the wake is predicted to remain in the 

corridor and the wake sensor agrees.

(2) Nowcast sensitivity: Cases are seen where the difference in spacing for an aircraft pair may be 

over 1 mile (TAPPS Vs observed weather). This situation occurred today when the observed 

weather provided minimal spacing reduction and TAPPS provided large reductions. Observed cross 

winds were less than 1 m/s below 100 m while TAPPS winds were about 2 m/s. Standard 

deviations were about 0.10 to 0.23 m/s in this region. This cross wind is in a range shown by Steve 

Riddick to be very sensitive to small cross wind changes. An effort will be made to better quantify 

the accuracy of TAPPS. We may need to add another term to its standard deviation value to 

indicate this uncertainty.

(3) Aircraft data base & beacon process: The AC_ID fields being received from ATC are now more 

varied than in 1997, for example getting A310 rather than EA31 and seeing variants of the B727 

(B722, B72Q, etc.) We will create a process (implemented by Lincoln) to match the variants up 

with aircraft data base entries so that more wake comparisons can be made. Some slight errors 

may be expected due to conducting prediction and validation with slightly different airframes. 

Lincoln has learned that the CTAS beacon tracks cut off at about 400 feet AGL. They will need to 

extrapolate tracks below this altitude to estimate passage time. I estimate a 3 second error at the 

threshold if an aircraft made a 10 knot speed change immediately after the radar track was lost.

11/03/99:

Need to consider setting up AVOSS for runway 35C operations. (Note: This change was never 

made.) To do this we need:

1. Change the runway ID in the parameter file from R17C to R35C.

2. DIST files have runway number in file name, automatically taken from pfile.prm string. The call 

to Compare must still pass the correct file name, DIST_R35C.date_time.

3. Use that string to select the directory and file name for reading AWAS weather (TDATA and 

EDATA are scalars and require no changes).

4. Coordinate with Lincoln so that the beacon process runs for R35C. This means that the wake 

sensors on 17C do not get processed. Archive for later transmission to NASA, but do not place

those files in the area for reading wake sensor data.

5. The sign of cross wind and head wind must be changed in the TAPPS files in use. AVOSS 

must either (a) read those files and write an altered version for reading or (b) modify the file 

reader to invert the sign if runway ID = 35C.

6. Display code that resolved sensor data into runway axis must change the runway orientation 

(sodar, profiler, tower). cross wind = wind speed * sin((runway heading - wind 

direction)/57.2958) and headwind = wind speed * cos((runway heading - wind 

direction)/57.2958).
46

Deployment notes:

November 11, 1999:

Residence time validation method -> A case study today of note. The wind line wake file at 

991111_200914 produced an exceedance time of 75 seconds. Examination of conditions revealed:

1. The 20:00 GMT AWAS crosswind was very light, less than 1 m/s.

2. The wind line file was for a B757 at the wind line window (X = 982 meters). The lateral 

residence times were 44 sec and 88 sec for Port/Starboard wakes. The vertical residence 

times were given as 9999, which is normal for the wind line.

3. The Pred_Tau file for 2000Z for the B757 at X = 982 gave a lateral residence time of 9999 for 

both wakes and a vertical residence time of 13 sec.

4. Therefore the wind line file agreed with predictions in the lateral (in that the observed lateral 

residence was long and less than predicted) and the wind line file did not contain data to 

refute the vertical prediction (wind line does not do vertical. Yet the process produced a 75 

second exceedance.)

5. This case may explain the exceedance seen in 1998 analysis and strengthens need to 

revisit comparison process, use of 9999 both for no data and long tracks, etc.

11/18/99:

Another residence time case study: Pulsed Lidar at 991118_1438. Exceedance = 29 sec

1. Winds are strong and from the south.

2. The wake file is for a B757 at X = 1702 meters (initial altitude about 106 m.

3. Wake file gave times (starboard wake is critical, see wake file Interface Control Document 

(ICD) for format).

9999 9999 9999 9999 9999 9999 9999 41

44 60

4. Pred_Tau file for B757 at 1430 gives times

9999 15 15 50 49 9999 15 15 50 49

Therefore the prediction was for a 15 sec time based on sink while the wake file did not validate sink 

and provided a 44 second time based on demise. 

Four conclusions/questions:

1. Need more intelligent compare logic and separate compare for each wake factor.

2. Not all exceeds are hazardous. 15 Vs 40 seconds may not be an issue since aircraft 

cannot be separated by as little as 40 seconds. Likewise errors when the prediction is 

greater than about 90 seconds may not be an issue.

3. May need different logic for "scientific" or demo evaluation of the system than for an 

operational safety system.

2/9/00: 

1. Need to refine system buffers (N_Sigma, nowcast vs. observed, sink rate, constant bias, dual 

safety corridor (inner for validation and outer for spacing) optimization.

2. Design of alerting method, timing if a wake lasts longer than expected and aircraft must be 

waved off - Vs system that tracks multiple wakes and opens up early based on trends.

3. Need for much better logic to compare predictions and sensor observations of the wake. Stop 

using 9999 for both long life and invalid data (loss of information), scientific Vs safety validation.

3/20/00: Noticed throughput values jumping or oscillating by about 2 aircraft per hour at times, for 

example from 1330 to 14 to 1430 Z on 11/12/99 the throughputs went from about 32 to 30 to 32. 

Since the default TP also made this swing, the evidence pointed to headwind. An analysis was 

done on 3/20 and I sent the summary to Bo Trieu & others. 
47

My notes were: 

Evaluate Throughput (TP) dip at 1400 on 11/12

Baseline > Run with weather files from 1330, 1400, 1430 Z => get TP dip from about 32 to 30

1. Substitute 1430 TDATA file for 1400, both flags & data => get dip

2. restore TDATA and do substitution for EDATA => still get dip

3. restore EDATA and do substitution for atmpro => removed dip

4. restore files and use 1430 QA flags in 1400 atmpro => get dip

5. restore all and use 1430 wind data in 1400 file => removed dip

therefore issue is in ATMPRO winds

6. restore all files and take absolute value of headwind to remove some

 tailwind at 1400 => still get dip

7. restore all and use 1430 headwind values in 1400 file up to 950 meters

 => removed dip!

8. baseline except headwind = 0 in 1400 file => still get dip

Could there be an error is use of headwind internally? 

9. Try baseline files except that headwind at 600m at 1400 is taken from 1430 file.

 => dip in TP was reduced, dip in DTP was gone!

Re-verified with two fresh runs - changing a single headwind value at

 600 meters (Z of spacing point) removed the dip! Why?

10. Try ramping through HW @ 600 meters to get TP at each value:

HW@600 TP DTP

 Base -0.42 30.1139 30.0244 

 0 30.1139 30.0244 

 0.50 30.1139 30.0244 

 1.00 30.1139 30.0244 

 1.50 32.08 31.9784 

 2.00 32.08 31.9784

2.50 32.08 31.9784

3.00 32.08 31.9784 

 3.50 32.08 31.9784 

from 1430 3.96 32.204 32.1017 

4.00 32.204 32.1017 

5.00 32.6123 32.4031

The email to Bo, Don, Jim was:

Update on the throughput value step changes:

I ran most of this morning to isolate the causes of the rapid changes in throughput observed on the 

plots we discussed. It was fairly quickly isolated to the head wind column of the ATMPRO files. 

There was nothing obviously wrong with the files on hand, so I looked into the equations for use of 

the headwind data. The headwind at two altitudes is used to estimate the average headwind 

between the "spacing point" and each window when computing "approach" spacing time intervals 

from "window" intervals. One altitude is the glide slope at the window and the other is the glide 
48

slope at the spacing point. As currently configured the spacing point is at 11128 meters from 

runway and the altitude there is 600 meters.

The sudden drop in throughput for the time being examined (14Z on 11/12) could be eliminated by 

editing only one value in the ATMPRO file, and that value was the headwind at 600 meters. At 

13:30 it was 3.77 m/s, at 14Z it was -0.42 m/s, and at 14:30 it was 3.96 m/s. When the 14Z data 

was edited to change the 600 meter headwind from -0.42 to 3.96, the throughput drop at that time 

vanished.

A quick look at the sensitivity of the equations suggests that a 4 m/s headwind change or a 1/2 

nautical mile change in window spacing can alter throughput by more than 1 aircraft per hour. 

Another factor contributing to the jumps is the use of rounding of the spacing values prior to 

computing throughput. The approach spacing values are not used as is, but are rounded to the 

nearest 1/2 mile before calling the throughput equations. I did not intend for this rounding to be 

applied to the default spacing values but apparently it is. The following table shows the throughput 

and default throughput from AVOSS as the headwind at 600 meters was changed:

 HW@600 TP DTP

 Base -0.42 30.1139 30.0244 

 0 30.1139 30.0244 

 0.50 30.1139 30.0244 

 1.00 30.1139 30.0244 

 1.50 32.08 31.9784 

 2.00 32.08 31.9784

 2.50 32.08 31.9784

 3.00 32.08 31.9784 

 3.50 32.08 31.9784 

from 1430 3.96 32.204 32.1017 

 4.00 32.204 32.1017 

 5.00 32.6123 32.4031 

There are discrete jumps in throughput rather than a smooth change.

Bottom line???

1. The throughput jumps are explainable from the weather files and the throughput equations.

2. The system is very sensitive, as-is, to the noise in the wind estimates at altitude. 

3. The throughput estimates may or may not improve (smooth out) as the radar profiler and 

south sodar are repaired, hopefully improving the wind estimates.

4. Throughput can change by 2 aircraft per hour for a 1/2 mile spacing change. 

3/22/00:

Investigate effects of setting the rounding interval to 0.

Run 11/12 at 1330, 1400, 1430 with round = 0 and 0.5

 round = 0 round = 0.5

TP DTP TP DTP

1330 32.535 31.690 33.003 32.102

1400 30.824 30.761 30.114 30.024

1430 32.450 31.653 33.003 32.102

Effects were: (1) delta throughput (TP) at 1400 was about 1.7 Vs 1.9 and

 delta default throughput (DTP) was 0.9 Vs 2.1 when rounding was removed. (2) peak TP

 was less than with rounding. 
49

Repeat test above with sweep of HW at 600 meters with round = 0:

 HW@600 TP DTP

 Base -0.42 30.8241 30.7608

 0 30.919 30.8492 

 0.50 31.0327 30.9552 

 1.00 31.1474 31.062

 1.50 31.263 31.1696 

 2.00 31.3795 31.2781

 2.50 31.497 31.3874

 3.00 31.6155 31.4975 

 3.50 31.7349 31.6086

from 1430 3.96 31.8457 31.7115 

 4.00 31.8554 31.7205 

 5.00 32.0994 31.947

Therefore the rounding is having a significant effect on throughput (TP) and default TP. A plot of TP 

and DTP Vs time for all of 11/12 was made for rounding = 0 and 1/2 nm, the zero value provided 

much smoother TP variations with time. 

3/24/00: Discussions were held with regard to biasing the nowcast weather products with local 

observed weather prior to calculating future throughput. Presently small (about 1 m/s biases in the 

low-altitude nowcast winds are having large effects on projected runway acceptance rate. Analysis 

indicates that local observations could improve performance by removing the biases and using the 

temporal trends provided by the nowcast to estimate future arrival capacity. This process could not 

be implemented and tested in time for the final system demonstration so the discussion has been 

removed from these notes.

3/29/00:

Have verified Compare outputs with wind line files, Lidar_L files, and Lidar_N files. All operate 

correctly, singly and in multiples. Found numeric errors in calculation of standard deviation and 

submitted software correction to CSC. The issue has only appeared when calling compare multiple 

times with the same file set. CSC is modifying code now and says that even if the output for one 

compare is in error, the intermediate storage is not affected and will be correct with the next call.

Have run the entire 1999 deployment in batch mode with the new Compare code. Results were 

excellent, with no hard exceedances noted and very few soft exceeds. We are hand examining 

specific cases for verification, to date a lidar file and two wind line files that produced large exceeds 

in the first code and a positive buffer with the new code. All so far have been correct. Several "gotya's" noted:

1. Remember that the wind line compare now is only of the lateral drift, that is, the predicted Tau 

is taken from the lateral motion only. That is the reason that two large exceeds on 11/19/99 

turned into positive buffers, since the predicted sink time was not used in the score.

2. The alternate demise definitions are used for the lidars, and the alternate drift is used for the 

pulsed lidar. See wake file ICD.

3. The SW_requests are ambiguous as to which demise values in the Pred_Tau file to use in 

comparing predicted Vs observed decay time. The documents say DL and DR, but email follow 

up changed that to DVL and DVR.
50

Plan: Compile and run batch mode with original compare code and compare both batch runs to the 

real-time log files to determine if the batch process is altering results.

Results: Only ran 12/01/99 due to need to edit Pred_Tau files to remove new data in V1.3. Found 

that new runs had more wake files to work with than were captured in the real-time statistics files. 

More buffers were computed on the batch rerun than in real-time, otherwise the trends were the 

same. Numerous cases that had created large exceedances in V1.2 Compare now produce 

smaller soft exceeds or even positive buffers with V1.3, see "got-ya" 1 above.

One case: NASA lidar on 12/01 at 172320 gave a 105 sec exceed initially and now a 60 sec soft 

exceed. The initial 105 sec exceed is due to 17 sec predicted vertical Vs 122 sec observed decay 

of starboard wake (77 for port). This file is likely in error on the right wake (sank to 19 meters at 47 

sec life then rose to 114 over the next 60 sec with little decay). This is not realistic and likely due 

to tracking the next aircraft. New Compare gave soft exceed due to "9999" time for right sink time. 

The value of 105 changed to 60 due to the TauMin and TauMax limits of 60 and 120 sec (TauPred = 

17 adjusted to 60 and TauObserved = 122 adjusted to 120). IF the wake file were valid in its wake 

rise data, this would have been a legitimate hard exceedance. The limitation here in determining 

soft Vs hard is the use of 9999 for no data, bad data, and legitimate wake-in-corridor data. Future 

implementations must address the issue. Simply reporting the last time in the file as the residence 

time is not satisfactory, since the file could end at 60 sec then claim a 60 sec residence (unsafe). 

A method of handling "wake was still there at last observation" is needed.

Another case was pointed out to lidar group as an error (tracked next aircraft at end of track to give 

erroneous rising wake). This case was MD-80 on 12/03 at 150629. V1.2 gave a 57 sec exceed and 

V1.3 gave a 14 sec soft exceed.. The value changed due to the TauMin limit (17 sec vertical time 

changed to 60) and it was soft due to 9999 vertical time.

Possible solution: Sensor reports the file end time of the wake factor is still in the corridor at that 

time, perhaps with a flag to indicate that the wake was still there at track loss. AVOSS then 

compares to prediction. If the factor and file and time are the same and less than predicted time, 

then no validation is possible. If the factor and file time are the same and greater than predicted 

then a hard exceedance can be reported. This differs from the current code only in that a positive 

buffer cannot be calculated if the end-of-track time become the factor time. Example, if the wake 

track lasts 90 seconds and the wake is still in the corridor at that time, currently the sensor reports 

9999 residence. In the proposed logic the reported time is 90 seconds but AVOSS cannot report a 

positive buffer, only an exceedance from it.

3/29/00:

About 1 week ago - ran batch runs with AVOSS V2.4 to determine throughput performance with 

various sink rate factors. Ran for SINK_PERCENT = 0, 50, 100%. Results are tabulated in 

"Three_Sinks.xls" sheet. General results:

Reducing effective sink rate from 100% to 50% produced small decreases in throughput. On most 

days the throughput decreases by less than 1% (i.e. from a 6% throughput increase with SINK = 

100% to 5% throughput increase with SINK = 50%). The largest decrease was on 11/30 when 

throughput decreased from 11.1% to 9.2%. The average loss of TP increase was 0.6%. When 

disabling sink altogether the loss was much greater, averaging a loss of 2.5% with a max loss on 

11/30 of 5.4%. This suggests a good opportunity to increase safety margins and reduces 

exceedance counts with small throughput losses. The optimal range of SINK_PERCENT is TBD 

but likely between 40% and 80%, and would likely be weather dependent. Actual aircraft spacing 

reduction in test bed use should start with SINK_PERCENT = 0 until the wake stalking factors can 

be better predicted.
51

4/3/00:

From batch runs to study effects on changing N_Sigma and percent of sink applied and the 

rounding interval:

This folder contains sensitivity runs, including all Dist and 

Pred_Tau files.

General parameter interests:

- Rounding 0,0.5 nm

- % Sink 0, 50, 75, 100

- N_Sigma 1, 2, 3

- TimeAdd 0, 5, 10

- Demise Def (studied by Riddick)

- A/C selection (default only at this time)

- Corridor Option (only #2 at this time)

- Disable Lateral (not at this time)

- QA_Enable (enabled at this time)

Eventually compare to wake files for exceed values:

- Number of Hard exceeds (=0?)

- Number of soft exceeds

- Maximum or mean exceeds

Initial Runs begun 3/30/00 with AVOSS V2.4: 

(TimeAdd = 0)

Run # Round %Sink N_Sigma

1 0.5 100 1

2 0.5 50 1

3 0 100 1

4 0 50 1

5 0.5 100 3

6 0.5 50 3

7 0 100 3

8 0 50 3

Write one log file per day. Zip file names are SensRun##

 where ## is run number.

Results of 1st eight runs:

Plotting average throughput increase by day showed 4 groupings.

Runs 1 & 3 almost overlapped and had the highest throughput

 increase (100% sink, N = 1, rounding 0 and 0.5)

Runs 2 and 4 were the next best and not far below the first group.

 They were 50% sink and N = 1, both roundings.

Runs 5 and 7 were next, and beginning to be seriously degraded from

 the baseline. They were 100% sink, N = 3, both rounding.

The worst was 6 and 8, with 50% sink, N = 3, both roundings.

Conclusions: 

1. The rounding interval makes no significant change in daily throughput increase (but other data 

shows it may have a significant effect on changes between updates).
52

2. Changing the wind standard deviation multiplier from 1 to 3 has a larger effect on the 

performance than changing the sink rate from 100% to 50%.

3. Values of sink between 50% and 100% should have acceptable impacts on performance as well 

as N = 1 or 2. Combining high N and low sink provides significant performance reduction.

4/4/00: Al Zak had an interesting observation about the list of exceedances I provided. The time of 

most were in the 23Z to 01Z evening transition period. This is significant, as they were wind line 

exceedances and therefore due to lateral drift errors. A common thread was low cross wind, about 

1.5 m/s, and very low cross wind standard deviation values, about 0.02 to 0.11 m/s. The cross wind 

standard deviation is taken at the tower 40 meter level and extracted upwards. This is valid in wellmixed PBL but is not when an inversion forms above the tower. A future system will need to 

consider this and either open up spacing during this period, provide other sensors such as lidar to 

measure standard deviation profiles, or develop algorithms to estimate worst-case standard 

deviation above the inversion, perhaps based on models, forecasts, or the standard deviation that 

existed before the inversion formed.

5/13/00:

Have examined about 3 of the time periods for which AWAS wind standard deviation was low, and 

we saw a wind line drift exceedance. When the minimum and maximum cross wind is compared to 

the (mean+- standard deviation), the min/max gave a slightly larger confidence interval, by a few 

tenths of a m/s. Later Bo asked if we were really using variance or standard deviation. Standard 

deviation would also have provided a slightly larger interval. 

The issue of finding the best metric for cross wind uncertainty requires further study. The current 

method appears to work well, but leads to drift exceedance in a very few cases. Study of this issue 

would be enhanced by modifying the software to allow real number multipliers to standard deviation. 

We are currently limited to the integers 0, 1, 2, 3.

5/22/00:

Realization that the current method of flagging convective storms and gust fronts is only a half-hour 

product. Operationally AVOSS needs another process running at higher than every half-hour for 

issues such as this and for feedback to ATC from safety monitoring.

6/1/00:

Several system timing issues have been noted:

1. The QA flag that advises that a gust front or convective storm is effecting the approach is set 

based on the presence of an event within the 30 minutes preceding the AWAS profile 

calculation. This means that a storm on the approach will not cause default spacing while the 

storm is there, but will cause default spacing in the next half-hour period. A test bed system 

needs predictions of such meteorological events and the ability to tell ATC about require 

spacing changes in between the regular half-hour updates.

2. Someone suggested that we could run multiple copies of AVOSS, all at 30-minute periods, in 

order to provide smoother spacing changes or predictions that spacing will change at the next 

update. If weather trending is added to persistence this could provide benefits in deriving that 

derivative.

3. There is a several minute time lag between the file time of wake files (they are referenced to 

aircraft passage time) and the time at which the wake file is received by AVOSS. The current 

"compare" logic runs on half-hour periods, and throws out the old Pred_Tau file when a new one 

is created. The result is that wake files started one to two minutes before the half-hour may not 

be received until after the half hour. The current scheme will not use those files in the scoring 
53

process. We appear to be losing about 2 to 3 wind line files per hour from the scoring process. 

Currently AVOSS runs at 1 and 31 minutes past the hour.

4. No process is in place to actually feedback wake prediction errors to the spacing values. That 

is a feature to be added in the next project using the data gathered from this project.

6/12/00:

Recent bug finds and fixes:

1. Examination of May runs showed numerous "spikes" in spacing values Vs time. Examination 

showed that on some days 1/3 to 1/2 of the ATMPRO files were failing the quality check. Further 

examination shows that the failures were due to degraded individual sensor performance, ie., 

combination of profiler and sodar, and that the QA criteria appeared too strict. It was possible for 

the overall QA to fail with valid weather being provided, in situations where a sensor was degrading 

but other, redundant data was available. Al Zak examined the data and suggested that the Lincoln 

AWAS assessment of the wind profile quality (flags 1 through 4) was adequate. The QA criteria 

has been modified to avoid use of the individual sensor QA flags and rely on the Lincoln process 

flags, as well as the gust front flag. 

2. Review disclosed that the ATMPRO file from AWAS was providing cross wind variance, while the 

TAPPS was providing standard deviation. The correct units are standard deviation. To avoid 

splitting the years of data into two formats, the AWAS file is left as-is and the AVOSS software has 

been modified to take the square root of variance when an AWAS file is read. This change alone 

prevents 6 of the 34 wind line exceedances (17%) in the 1999 deployment data set. 

The two changes above are incorporated into AVOSS V2.5, which began real-time operations at 

13:30 Z on 6/12/00.

7/6/00:

Batch runs of 1999 deployment data with V2.5 show:

1. Vastly more wake compares – fixes timing issues and revised QA results in far more good 

weather QA cases for wake compares. Now have 952 compares vs. just over 400 in realtime in 1999.

2. Of 952 comparisons we have 656 class 1 (taumin = 50), 244 positive (2 hard), and 52 

negative.

3. Mean throughput increase from entire deploy fell to about 5%. Did quick study of exceeds 

vs. throughput for N_Sigma = 0 and 1, and crosswind lockout threshold = 1.0 and 1.5 m/s. 

Found:

N_Sigma Cross wind 

lock

Average 

throughput 

increase

exceeds Wind line drift 

exceeds

0 1.0 7.46 82 59

1 1.0 4.94 52 29

1 1.5 4.10 46 23

4. Suggests need for parametric tradeoff of exceeds and performance, and methods of 

quantifying wind confidence intervals. Keep in mind that a drift exceedance is not 

necessarily a safety error (sink & decay at windline not scored) and that a genuine drift 

exceed may not be a safety issue depending on location of the wake at the time. Also 

consider wind confidence vs. stability class, time of day or year, etc. rather than use of 

constant gains in all weather.
54

Table to collect software enhancement ideas:

Change Reason

Remove hard-coded description of the corridor 

and place it in a parameter file. Do not 

"increase" corridor width at glide slope intercept 

altitude, but use a policy flag

Ease of performing tradeoff studies, 

evaluating improved flight technical error, 

parallel runway concepts

End-to-end functional decomposition of the 

software and rewrite from ground up

Improve modularity, implement other ideas

"Disable" flags due to parameter file settings 

and QA tests are scattered through code. 

Gather these into 1 or at most 2 modules to 

implement QA and policy restrictions on 

spacing

Improve understanding of code, reduce 

chances for implementation or interpretation 

errors.

Implement feature to determine which windows 

are critical to the spacing values, or which ones 

could be dropped from consideration (i.e. by 

showing the spacing would not increase for any 

aircraft pair by any significant amount if a 

window were removed.

Tremendous costs benefits to the system if 

windows far from airport can be ignored.

Make weather QA a function of altitude and 

make ability to disable lateral, vertical, or 

demise a function of altitude

See note of 6/15/99. May improve 

performance or cost in situations where one 

weather parameter is good at low altitude but 

questionable at high altitude, while another 

weather parameter is good at altitude and is 

removing the wake

Integrate the currently-separate "scientific" and 

"real-time" data sets, in strictly controlled 

modular sets (raw sensor, processes 

consensus files, etc). Provide common data 

processing and visualization tools

Allow for faster assessment of alternate 

mans of processing sensor data (i.e., wind 

min/max intervals Vs standard deviationbased intervals) and quick answers to what-if 

questions (EDR as function of wind?) Must 

provide controlled access to copy of real-time 

process by researchers.

Add the ability to run an arbitrarily oriented 

runway. Some code is hard-wired for runway 17 

at DFW.

Obvious

Add outputs for parallel runway operations 

(alternate corridor size, product formats).

Obvious
55

References

 

1

 Campbell, S.; Dasey, T.; Freehart, R.; Heinrichs, R.; Matthews, M.; and Perras, G.: Wake Vortex Field 

Measurement Program at Memphis, TN., AIAA 96-0399, Presented at the 34th Aerospace Sciences Meeting 

& Exhibit, Reno, NV, 15-18 January, 1996. 

2

 Campbell, S.D.; Dasey, T.J.; Freehart, R.E.; Heinrichs, R.M.; Matthews, M.P.; Perras, G.H.; Rowe, G.S.: 

Wake Vortex Field Measurement Program at Memphis, TN Data Guide, Lincoln Laboratory Project Report 

NASA/L-2, January 14, 1997. Also published as NASA CR-201690, April 1997. 

3 Dasey, T. J., Campbell, S. D., Heinrichs, R. M., Matthews, M. P., Freehart, R. E., Perras, G. P., and P. 

Salamitou: A Comprehensive System for Measuring Wake Vortex Behavior and Related Atmospheric 

Conditions at Memphis, Tennessee, Air Traffic Control Quarterly 5(1): 49-68, 1997. 4

 Proctor, F.H.: Numerical Simulation of Wake Vortices Measured During the Idaho Falls and Memphis 

Field Programs. AIAA 96-2496, 14th AIAA Applied Aerodynamics Conference Proceedings Part-2, June 

17-20, 1996, pgs. 943-960; New Orleans, LA. 

5

 Robins, Robert E.; Delisi, Donald P.; Greene, George C.: Development and Validation of a Wake Vortex 

Prediction Algorithm, AIAA 98-0665, 36th Aerospace Sciences Meeting & Exhibit, January 12-15, 1998, 

Reno, NV. 

6

 Robins, Robert E. and Delisi, Donald P.: Further Development of a Wake Vortex Predictor Algorithm 

and Comparisons to Data, AIAA 99-0757, 37th AIAA Aerospace Sciences Meeting & Exhibit, January 11-

14, 1999, Reno, NV. 

7

 Schowalter, D. G.; DeCroix, D. S.; Lin, Y. -L.; Proctor, F. H.; Arya, S.P.; and Kaplan, M. L.: Turbulent 

Statistics in the Atmospheric Boundary Layer: A Comparison of Large Eddy Simulation with Observations. 

11th Symposium on Boundary Layers and Turbulence, March 27-31, 1995, Charlotte, NC. 

8 Britt, Charles L.; Nguyen, Dung Phu Chi; and Koch, Grady: Pulsed Lidar Measurements of Aircraft 

Wake Vortices at DFW and JFK, AIAA 99-0982, 37th AIAA Aerospace Sciences Meeting & Exhibit, 

January 11-14, 1999, Reno, NV. 

9

 Hinton, David A. and O’Connor, Cornelius J.: Development of a Wake Vortex Spacing System for Airport 

Capacity Enhancement and Delay Reduction, 19th Digital Avionics Systems Conference, Paper 3.E.6, 

Philadelphia, PA., October 7-13, 2000 

10 Riddick, Stephen E. and Hinton David A.: An Initial Study of the Sensitivity of Aircraft Vortex Spacing 

System (AVOSS) Spacing Sensitivity to Weather and Configuration Input Parameters, NASA/TM-2000-

209849, January, 2000. 

11 Matthews, Michael P. and Denneno, Andrew P.; Integration of Multiple Meteorological Sensor 

Observations for Wake Vortex Behavior Comparison, 79th AMS Annual Meeting, Eighth Conference on 

Aviation, Range, and Aerospace Meteorology 10-15 January 1999, Dallas, TX, Paper #11.1 

12 Han Jongil; Arya, S. Pal; Shen, Shaohua; Lin, Yuh-Lang: An Estimation of Turbulent Kinetic Energy 

and Energy Dissipation Rate Based on Atmospheric Boundary Layer Similarity Theory, NASA/CR-2000-

210298, June 2000. 

13 Sarpkaya, T.: A New Model for Vortex Decay in the Atmosphere, AIAA 99-0761, 37th AIAA Aerospace 

Sciences Meeting & Exhibit, January 11-14, 1999, Reno, NV. 

14 Sarpkaya, T.; Robins, R.; and Delisi, D.: Atmospheric Environment Wake-Vortex Eddy Dissipation 

Model Predictions Compared with Observations, AIAA 2000-0625, 38th AIAA Aerospace Sciences 

Meeting & Exhibit, January 10-13, 2000, Reno, NV. 

15 Hinton, David A.: Aircraft Vortex Spacing System (AVOSS) Conceptual Design, NASA TM-110184, 

August 1995. 16 Proctor, Fred H. and Han, Jongil: Numerical Study of Wake Vortex Interaction with the Ground Using 

the Terminal Area Simulation System, AIAA 99-0754, 37th AIAA Aerospace Sciences Meeting & Exhibit, 

January 11-14, 1999, Reno, NV. 

17 Proctor, Fred H.; Hamilton, David W.; and Han, Jongil: Wake Vortex Transport and Decay in Ground 

Effect: Vortex Linking with the Ground, AIAA 2000-0757, 38th AIAA Aerospace Sciences Meeting & 

Exhibit, January 10-13, 2000, Reno, NV. 

18 Hinton, D.A.: An Aircraft Vortex Spacing System (AVOSS) For Dynamical Wake Vortex Spacing 

Criteria, AGARD 78th Fluid Dynamics Panel Meeting and Symposium on the Characterisation & 

Modification of Wakes from Lifting Vehicles in Fluids, Trondheim, Norway, 20-23 May, 1996, AGARD 

CP-584, Paper 23. 
56

 19 Hinton, David A.; Charnock, James K., and Bagwell, Donald R.: Design of an Aircraft Vortex Spacing 

System (AVOSS) for Airport Capacity Improvement, AIAA 2000-0622, 38th AIAA Aerospace Sciences 

Meeting & Exhibit, January 10-13, 2000, Reno, NV. 

20 Hinton, David A.; Charnock, James K.; Bagwell, Donald R.; and Grigsby, Donner: NASA Aircraft Vortex 

Spacing System Development Status, AIAA 99-0753, 37th Aerospace Sciences Meeting & Exhibit, January 

11-14, 1999, Reno, NV. 

21 Hannon, Dr. Stephen M.; Assessment of C-130J and C-130H Wake Vortex Transport and Decay Using a 

Pulsed 2 um Coherent Doppler Lidar: Final Test Results, Coherent Technologies, Inc. Report CTI-TR2000-3, January 27, 2000. 

22 Kaplan, Michael L.; Lin, Yuh-Lang; Charney, Joseph J.; Pfeiffer, Karl D.; Ensley, Darrell B.; DeCroix, 

David S.; and Weglarz, Ronald P.: A Terminal Area PBL Prediction System at Dallas-Fort Worth and its 

Application in Simulating Diurnal PBL Jets, Bulletin of the American Meteorological Society, Vol. 81, No. 

9, September 2000. 
57

Figure 1 – General System Architecture. The core code provides one set of wake 

predictions and spacing calculations for each call with weather, aircraft, and parameter 

data. EDATA, TDATA, and ATMPRO are file name prefixes for turbulence, 

temperature, and wind profiles, respectively. DefSpace is a file providing minimum 

threshold spacing for runway occupancy time considerations as well as the FAA spacing 

criteria. AVOSS was run with both observed weather (top inputs) and nowcast 

(predicted) weather (bottom input) but aircraft spacing values and wake comparisons are 

only provided for observed weather.

Core (suitable for run-time and batch use)

Run-Time Shell (Unique to Dallas facilities)

Wake 

Predictor,

Residence 

time, and 

Spacing 

calculations

Field 

systems

(tower, radar 

profiler,

sodars, etc.) 

and Wind 

Profile 

Turbulence

Profile

Code

Thermal

Profile

Code

}

ATMPRO

TDATA

EDATA

Weather

AC Data

Parameter file

DefSpace

Throughput 

calculations

AC data & traffic mix

ATC options

ATMPRO

Wake Track & 

Residence Time Files Spacing File Log File

Nowcast 

weather 

products

Display

& Compare

Weather

Data

Display

& Compare

Wake

Data

Lidars &

Wind Line

System Status 

Displays

Statistics File

Exceed File
58

Figure 2 – Data flow within the AVOSS weather system. Wind profiles and eddy 

dissipation rate (EDR) is provided by MIT Lincoln Laboratory systems based on field 

sensor data. Derivation of thermal profiles and EDR profiles are provided within the 

AVOSS shell code. Nowcast weather products are provided in identical format to 

observed weather, and the field sensor QA processes are not applied. 

Tower winds

Sodars

Radar Profiler

ITWS, TDWR

Tower thermal

RASS

Pressure @ 3m

(all at 5 minute 

period)

Tower fluxpac

Lincoln 

AWAS 

code

Lincoln 

EDR 

IDL code

NASA 

Thermal 

Profile 

code

EDR profile code,

(in AVOSS)

See EDR list

below

Terminal Area 

Planetary 

Boundary Layer 

Prediction System 

Nowcast @ NCSU

FTP to Lincoln 

@ 

Lexington, MA

TAR file Lincoln DFW 

Wake 

Network

Each TAR file contains:

- Atmpro

- Tdata

- Edata

for 30 minute blocks for 12 to 18 hours

Tdata file (virtual potential temperature profile & QA)

Edata file (EDR and 

TKE profile & QA)

Atmpro file (wind profile & QA) 

IF

(NOT ATMPRO_GOOD) 

AND (QA_Enable)

THEN

Disable lateral and disable 

vertical motion in spacing 

reduction

ELSE

Use pfile.prm values of 

Disable_Vert and 

Disable_Lat in spacing 

reduction

Un-TAR

(in AVOSS)

Atmpro

Edata

Tdata

Display of basic sensor 

data and processed 

profiles

To Wake Predictor

- Observed Wx Set 

- Flags

To Wake Predictor

- TAPPS Wx Set

- flags

.

.

QA screening and shell 

for EDR code

(in AVOSS)

.

EDR List from Lincoln to EDR profile code shell, all at 30-min period:

- 5 and 40 meter altitude EDR

- 5 and 40 meter altitude TKE

- 3 & 10 meter altitude virtual potential temperature, Kelvin

- 3 and 10 meter altitude wind speed. m/s

}

Base sensor data

Note:

EDR – Eddy Dissipation Rate

IDL – Interactive Development Language

QA – Quality Assurance

RASS – Radio Acoustic Sounding System

TAPPS – Terminal Area Planetary boundary layer Prediction System

Wx - Weather
59

Figure 3 – Runway axis system and approach corridor.

Figure 4 – Flow of data from weather and aircraft parameters to wake residence time and 

approach spacing. 

Predict.cpp

Calls wake predictor 

for each aircraft at 

each window, 

compares wake 

trajectory to corridor 

dimensions to derive 

residence time for each 

wake run.

Weather data

Parameter file

AC database

Wseps.cpp

Window and Approach 

spacing calculation. 

Provides top-ofapproach spacing in 

time and distance units

Parameter file

AC database

Default A/C spacing @ windows

Wake

Tracks To display of spacing

Runway 

Throughput 

Calculation

Atmpro (headwind profile)

AC database

Traffic Mix/ATC Options

Spacing Matrix 

providing individual 

window and top-ofapproach spacing 

criteria, both reduced 

and based on FAA 

criteria

To display of predicted Vs sensed wake tracks 

Residence

Time Data

APA.C

Wake predictor code

To display & comparison of predicted Vs sensed residence time

Runway arrival 

capacity both for 

reduced spacing and 

based on FAA criteria

Notes: 

•“Residence time data” provides lateral, vertical, and demise residence time values for port 

and starboard wake for each aircraft at each approach window loc ation. 

•Each data type (wake tracks, residence time data, spacing matrix, and runway throughput) is 

written to disk file for archival and comparison with sensor data as appropriate.

X

Y

Window

Window at 

Glide Slope 

Intercept Altitude

Window at

Runway Threshold

Window

Window

Runway

Z

Flight 

Path

Corridor floor and lateral limits 

represented by “goal posts”

Top-of-approach, or “Spacing Point”
60

Figure 5 – Use of equation 6 to calculate category-based spacing at the top of the approach from multiple window and aircraft wake 

predictions. 
New wake 

sensor file Notes: 

1) Four comparison classes are used (1) Both predicted & observed residence times are less 

than TauMin, (2) both times are greater than TauMax, (3) the buffer is “Soft”, (4) the buffer 

is “Hard”. Any buffer calculated from the windline is soft.

2) Compare only if a Pred_Tau file has been created in the past 35 minutes and is based on 

good weather files (ATMPRO_Good AND EDATA_Good).

Increment wake file counter, 

Num_Wfiles(sensor)

Determine “critical” wake (P, S, or B), see note 3

IF DISABLE_LAT_LOWER then tau_hp = tau_hs = 9999

IF DISABLE_VERT_LOWER then tau_vp = tau_vs = 9999

ResTimeP = Min(tau_vp, tau_hp, tau_gp)

ResTimeS = Min(tau_vs, tau_hs, tau_gs)

ResTimePair = Max(ResTimeP, ResTimeS)

V = vertical, H = horizontal, D = demise

P = port, S = starboard

Therefore tau_vp is residence time for vertical motion

of the port wake.

Wake file residence time line contains (in order):

tau_hp, tau_vp, tau_tp, tau_dp, tau_hs, tau_vs, tau_ts, tau_ds

final residence time line contains tau_gp and tau_gs

Increment Num_Invalid_Tau(sensor_ID) 

counter

Increment Num_Invalid_Place(sensor_ID) 

counter

Increment Valid_W files(sensor_ID) 

Do 

Statistics, 

write files, 

done

ResTime”critical” = 

9999

Yes

No

Do Aircraft_ID 

AND Window_X 

match predictions

Yes

No

Pred_Tau file 

and “good” 

weather (see 

note 2)

Increment No_Pred(sensor_ID) counter

Yes

No

Note: If “critical” = “B” then this test is 

(ResTimeP = 9999 OR ResTimeS = 9999)

These operations are applied to the sensor file, not the predicted time file. 

Note: Predictor window X and sensor scan plane 

X match if within 10 meters.

B

A

A & B, flow to and from next page, Figure 6b

Figure 6a – Comparison process for scoring predicted wake 

residence time with observed residence time 61
Increment appropriate counters and 

accumulators for output statistics

Increment appropriate counters and 

accumulators for output 

statistics

Write entry to Exceed File

Display exceedance message

Buffer < 0 

sec

Yes

No

A

Increment counters for class 1 (both residence 

times less than minimum)

Increment counters for class 2 (both residence 

times above maximum)

Buffers and exceedances 

calculated will be “soft”

Buffers and exceedances 

calculated will be “hard”

B

Is Criteria Met 

for “soft” 

compare

Yes

No

Both TauPred 

AND 

TauObserved > 

TauMax

Yes

No

Both TauPred 

AND 

TauObserved < 

TauMin

Yes

No

Calculate Buffer, using special 

rules for wind line and for times 

that span TauMin or TauMax

See definitions of TauPred and TauObserved in Figure 6c

See “Criteria for Soft and Hard Residence 

Time Comparison”, Figure 6d

See “Buffer Calculation”, 

Figure 6c

Figure 6b – Comparison process continued

62
Accept predicted 

residence time & 

wake sensor file

From APA predictions: 

TauPred = MAX (Min(HL,VL,DL), Min(HR,VR,DR))

If ((TauPred < TauMin) AND (TauObserved > TauMin)) then TauPred = TauMin

If ((TauObserved < TauMin) AND (TauPred > TauMin)) then TauObserved = TauMin

If ((TauPred > TauMax) AND (TauObserved < TauMax)) then TauPred = TauMax

If ((TauObserved > TauMax) AND (TauPred < TauMax)) then TauObserved = TauMax

IF (ResTimeP < 9999 AND ResTimeS < 9999) 

then TauObserved = ResTimePair

else TauObserved = ResTime”critical”

Done

Sensor = windline

Yes

No

From APA predictions: 

TauPred = MAX (HL,HR)

Buffer = TauPred - TauObserved

These actions applied to 

sensor data

These actions applied to 

predicted time values

Figure 6c – Calculation of predicted and observed residence time an buffer 

calculation, including special rules for the windline data and times that span 

TauMin or TauMax

Notes:

APA refers to the wake predictor algorithm.

HL, VL, DL are horizontal, vertical, and demise residence times of the left wake, 

HR, VR, DR are the same times for the right wake

ResTimeP and ResTimeS are observed residence times of the port and starboard 

wake due to all factors.

63
Hard comparisons between predicted and observed residence time is only possible when the factor 

(drift, sink, demise) that establishes the predicted residence time has been quantified by the sensor. 

The factors that determined the predicted residence will be determined and then the wake file will 

be examined to determine if those factors have “9999” values for the critical wake. When the 

sensor returns “9999” for a time there is no certainty that the wake remained in the corridor, or even 

that the wake was even tracked and the buffer is soft. An actual situation from a lidar file was:

Source Drift time Sink Time Demise Time Pred or Obs Tau

Predictor 9999 17 72 17

Sensor 9999 11 Port 77 Port 122

9999 Starboard 122 Starboard

In this case the software version 2.3 computed a 122 - 17 = 105 sec exceedance. This exceedance 

is soft because we do not know if the sink of the starboard wake actually took place in less than or 

more than 17 seconds due to the 9999 value. This case is used as an example (italics) in the 

flowchart below. The word “factor” refers to drift, vertical, or demise time. 

Calculate TauPred 

(predicted wake pair 

residence time)

Examine all individual 

times in PredTau line to 

determine which factors = 

TauPred

Examine the wake file 

residence times to determine, 

for each factor in previous 

step, if that factor time = 9999 

for the critical wake (port, 

starboard, or both)

Declare buffer 

“hard” Sensor = windline

Declare buffer 

“soft”

Done

Factor for 

either wake 

= 9999

Yes

Yes

No

No

Example above, 17 sec

Example 

above, factor 

is sink time, 

note possibility 

that more than 

one factor will 

have the same 

time value

Example above, vertical sink time of 

observed starboard wake = 9999

Example above, Yes if the 

critical wake was 

starboard or both, 

otherwise No.

Example above, Buffer is soft

Accept predicted 

residence time & 

wake sensor file

Figure 6d – Criteria for Soft and Hard Residence Time Comparison with 

example

64
AND

Aircraft lateral 

position = wake 

lateral position

Wake has not 

demised

Aircraft vertical 

position = wake 

vertical position

Aircraft encounter 

with wake vortex

L V D

P(encounter) = P(L)*P(V)*P(D)

for L,V,D independent

Aircraft position probability

Wake position probability

at time 2

Wake position probability

at time 1

Probability of lateral positions 

coinciding, at times 1 and 2

Corridor lateral limits

Figure 7 – Calculation of encounter probability from distributions of following 

aircraft position and wake positions at various elapsed times from generating 

aircraft passage. 

65

Lateral position

Centerline
REPORT DOCUMENTATION PAGE Form Approved

OMB No. 0704-0188

Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data

sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other

aspect of this collection of information, including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and

Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-0188),

Washington, DC 20503.

1. AGENCY USE ONLY (Leave blank) 2. REPORT DATE

June 2001

3. REPORT TYPE AND DATES COVERED

Technical Memorandum

4. TITLE AND SUBTITLE

Description of Selected Algorithms and Implementation Details of a

Concept-Demonstration Aircraft VOrtex Spacing System (AVOSS)

5. FUNDING NUMBERS

576-02-11-11

6. AUTHOR(S)

David A. Hinton 

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

NASA Langley Research Center

Hampton, VA 23681-2199

8. PERFORMING ORGANIZATION

REPORT NUMBER

 L-18079

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space Administration

Washington, DC 20546-0001

10. SPONSORING/MONITORING

AGENCY REPORT NUMBER

NASA/TM-2001-211027

11. SUPPLEMENTARY NOTES

 

12a. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified-Unlimited

Subject Category 03 Distribution: Nonstandard

Availability: NASA CASI (301) 621-0390

12b. DISTRIBUTION CODE

13. ABSTRACT (Maximum 200 words)

A ground-based system has been developed to demonstrate the feasibility of automating the process of collecting

relevant weather data, predicting wake vortex behavior from a data base of aircraft, prescribing safe wake vortex

spacing criteria, estimating system benefit, and comparing predicted and observed wake vortex behavior. This

report describes many of the system algorithms, features, limitations, and lessons learned, as well as suggested

system improvements. The system has demonstrated concept feasibility and the potential for airport benefit.

Significant opportunities exist however for improved system robustness and optimization. A condensed version

of the development lab book is provided along with samples of key input and output file types. This report is

intended to document the technical development process and system architecture, and to augment archived

internal documents that provide detailed descriptions of software and file formats.

14. SUBJECT TERMS

Air Traffic Control; Airport capacity; Wake vortex

15. NUMBER OF PAGES

70

 16. PRICE CODE

A04

17. SEC U RITY CL ASSIF IC AT ION 

O F REPO R T

Unclassified

18. SEC U RITY CL ASSIF IC AT ION 

O F TH IS PA GE

Unclassified

19. SECURITY CLASSIFICATION

 OF ABSTRACT

Unclassified

20. LIMITATION

 OF ABSTRACT

 UL

NSN 7540-01-280-5500 Standard Form 298 (Rev. 2-89)

Prescribed by ANSI Std. Z-39-18

298-102