[american institute of aeronautics and astronautics aiaa modeling and simulation technologies...

American Institute of Aeronautics and Astronautics

1

Algorithm for the Calculation of Distances between

Simulated Aircraft on the Ground

George L. Smith III*

Titan Corporation

William J. Hughes Technical Center

Atlantic City International Airport, Atlantic City, New Jersey

Douglas Baart†

Federal Aviation Administration

William J. Hughes Technical Center

Atlantic City International Airport, Atlantic City, New Jersey

Nomenclature

x = latitude of a point given by the simulator representing the location of the center of gravity

y = longitude of a point given by the simulator representing the location of the center of gravity

X = latitude

Y = longitude

CSV = Comma Separated Version

OOP = Object Orientated Programming

object = a self-contained entity that consists of both data and procedures to manipulate the data

cardinal point = an aircraft’s part (i.e., tail, starboard wing, port wing, nose )

dr = distance in radians

df = distance in feet

ht = true heading in radians

hr = relative heading in radians

Tc = true course in radians

π = PI =3.1415926535897932

radians = decimal degrees * (π / 180)

distancer = (pi/(180*60))*distance in nautical miles

nautical miles = ((180*60)/pi)*distance in radians

I. Introduction

he Federal Aviation Administration (FAA) Office of Runway Safety and Operational Services formed a

simulation team to investigate the safety effects of standardizing the use of aircraft landing lights in the

airport environment. Specifically, the simulation team explored the procedural use of landing lights as a direct

message to other pilots indicating that aircraft were cleared to depart. The necessary data included a measure of

Runway Incursions (RI), accidents, and pilot situation awareness (SA).1 Analysis of the collision potential between

the B747-400 simulator and the computer generated aircraft required metal-to-metal distances between the aircraft.

Most of the data outputted by the simulator met the researchers’ requirement for analysis. However, the

identification of the position of the aircraft was inadequate; it only reported the latitude and longitude of the aircrafts

center of gravity.

An algorithm was necessary to adequately depict the metal-to-metal distances to give the researchers a more

accurate picture of the aircraft involved. This was accomplished by combining the simulator’s center of gravity

reference point (latitude, longitude), the aircrafts’ kinematical heading, the relative position and distances of the

aircrafts’ cardinal points. The distance values of the aircrafts’ cardinal points were supplied by NASA. See Table 1.

* Staff Programmer, Titan Corporation, William J. Hughes Technical Center † Mathematician, FAA (Federal Aviation Administration), William J. Hughes Technical Center

T

AIAA Modeling and Simulation Technologies Conference and Exhibit15 - 18 August 2005, San Francisco, California

AIAA 2005-6017

Copyright © 2005 by the American Institute of Aeronautics and Astronautics, Inc.The U.S. Government has a royalty-free license to exercise all rights under the copyright claimed herein for Governmental purposes.All other rights are reserved by the copyright owner.


2

Aircraft

TypeNose Tail Tail Top Wing

Wing

Leading

Edge

Wing

Trailing

Edge

Tail Top to

Ground

Fusalage

Top to

Ground

B737 48.000 59.000 61.000 48.081 16.000 21.000 37.630 17.630

B747-400 92.873 133.350 139.000 106.379 57.770 77.940 63.611 31.141

B757 72.876 81.549 81.557 62.387 16.509 22.661 44.504 20.529

B767 82.289 93.779 97.245 77.220 25.186 32.294 52.000 23.170

Center Of Gravity To

Table 1(distances are represented in feet)

Aircraft dimensions used were provided by NASA.

II. OOP

“Simply stated, object-oriented design is a technique for programming that focuses on the data (=objects) and

on the interfaces to that object. To make an analogy with carpentry, and ‘object-oriented’ carpenter would be

mostly concerned with the chair he was building, and secondarily with the tools used to make it; a ‘non-object-

oriented’ carpenter would think primarily of his tools. The object-oriented facilities of JAVA™ are essentially those

of C++.”2

A discussion about algorithms would not be complete without first discussing, if not in detail at least

superficially, object oriented programming (OOP). Data Objects were created utilizing the OOP methodology,

primarily focusing on the data.

The algorithm was written in the JAVA™ programming language making it almost impossible to program using

any other methodology. JAVA™ was chosen for this project because operating system portability was a higher

priority than speed. The plan was to write this program in the Linux environment and then port the program into a

Windows XP™ environment. This would give the researchers the ability to develop their own results. However,

because of operation needs, the program stayed in Linux. The solution for portability to the researchers was to

output the results into a text based CSV file that was easily imported into Microsoft Excel™ for evaluation and

plotting.

A separate output was developed to depict the trajectories of the aircraft in a form which could be viewed on a

computer with a program to display that aircraft’s path. Displaying the trajectories gave us a view of the actual

tracks of the aircraft, which was useful in troubleshooting the algorithm.

III. The Simulator

The simulator output a myriad of data. It collected data at a rate of 30 Hz. The data included control

manipulations inside the cockpit, the response of the B747-400, and behavior of the computer generated aircraft in

the environment.

“Unlike the typical training simulator the NASA 747-400 simulator

has unique research capabilities. These

include six high-resolution commercial

raster-based CRT displays which are

used to simulate the 747-400’s

electronic flight displays. These

displays are programmable to support

the development of new or revised

flight displays and/or system synoptics

to support aviation human factors or

airspace operations research. In

addition, cameras have been installed

throughout the cockpit allowing

researchers to record flight crew

interactions or any of the different

cockpit instruments or displays during an experiment. Repeater monitors have

also been installed in the control room to allow researchers to see exactly what the pilots are seeing inside the cab.

User friendly touch screen experimenter operator stations are located in the control room as well as in the simulator


3

to allow interactive control and manipulation of experimental conditions during scenario runs. In addition, a separate

IBM RISC 6000-560 computer is used for data collection purposes, allowing researchers the ability to collect as

much as 9 to 10 gigabytes of data during an experiment run. In support of full-mission simulation, the 747-400

simulator can be integrated with the facility’s air traffic control simulator allowing the creation of complex multi-

aircraft scenarios, including the typical air-ground communications that are an integral part of normal everyday

cockpit operations.”3

IV. The Data

The data submitted to us was in a tab separated format. An aircraft tokenizer was designed to specifically gather

the data we required. Various bits of information were represented. Most important for our purpose, was the NASA

747-400 simulators kinematical information as well as the kinematical information of the seven “comparison” or

computer generated aircraft for that “run”.

The entire datums were represented in double precision format. Latitude and Longitude were represented using

decimal degrees with eight decimal places. This put our rendered results in the neighborhood of much less than an

inch in accuracy. The actual data received from the simulator was represented with thirteen decimal places;

however, we only used eight of those decimal places.

Each line of data represented information at a specific moment in time. A sample rate of 30 Hz gave us a new

center point latitude and longitude approximately every half-second.

V. The Objects

Each “object” was created with the ability to interact with other objects; either aircraft to aircraft, or aircraft to

airspace. Airspace in this case was a runway and a runway crossing at designated airports. Several other “objects”

were also created to do the mathematics as well as some of the common functions. These were kept separate from

the “data” objects because we wanted to be able to use this functionality in the future (we were creating a common

library of functions). Each object was equipped with an internal cleanup routine and were created only once during

the process operation saving allocated memory and giving us the ability to reuse that particular object. Besides

saving on allocated memory, this also saved on instantiation and destruction time. Cleanup became a simple task

when the overall process was complete.

Below are listed each of the objects created and an explanation of the task each accomplished. At the end of

each explanation in brackets is the actual JAVA™ classes name that was used in the algorithm.

1) Aircraft Math is a class that holds all of the mathematics involved in calculating all aircraft measurements.

See “The Mathematics” below. (AcrftMath.java)

2) Aircraft Model contained the static values represented in Figure 1, giving us the ability to specify a type of

aircraft. Because the simulator only reported the center of gravity, any aircraft type could be represented

simply by changing the distances between the cardinal points. (AircraftModel.java)

3) Aircraft Data was used to compare the two aircraft to each other as well as to a particular runway situation.

It also facilitated the writing of a file overwriting the previous closest point-to-point distance.

(AircraftData.java)

4) Aircraft is a container used to calculate the distance from the center of gravity to each of the cardinal points

on the aircraft; basically, building the imaginary aircraft frame. (Aircraft.java)

5) Tokenize Aircraft is a specialized file parser that read the inputted data file and outputted the specific

aircraft within that data file. (TokenizeAircraft.java)

6) Latitude is a container object which held the decimal degree latitude value; it also supplied methods which

gave us the ability to output the latitude in a variety of formats. (Latitude.java)

7) Longitude is a container object which held the decimal degree longitude value; it also supplied methods

which gave us the ability to output the longitude in a variety of formats. (Longitude.java)

8) Latitude Longitude Point is a container object which holds the latitude and longitude objects of a point.

Keeping the latitude and longitude in a close knit package. (LatLonPoint.java)

9) Runway Model contained the static values represented in Table 2, giving us the ability to specify a specific

runway at a specific airport. (RunwayModel.java)

10) Runway Area was a data object created to contain the runway area information. More specifically, the “hot”

zone of the runway where the actual calculations took place. This was used to eliminate “false” incursions

created by the take off aircraft and the taxiing aircraft coming close together while the taxiing aircraft was

passing the takeoff aircraft approaching the “hot” zone, or runway crossing area. (RunwayArea.java)

11) Process object performs the actual iteration function, see “Iteration” below. (Process.java)


4

12) Constants maintains the basic elements used in the aviation field. This is an abstract class and as such must

be extended by another class to be utilized. (Constants.java)

13) Version is an object created to keep track of the versions currently being used. This is an abstract class and as such must be extended by another class to be utilized. (Versions.java)

Runway Taxiway Primary Secondary Length Width Latitude Longitude Latitude Longitude Latitude Longitude Latitude Longitude

ORD5 Chicago OHare 32L T10 320˚ 140˚ 10005 150 041.97245 087.91163 041.97214 087.91212 041.97179 087.91268 041.97148 087.91318

ORD6 Chicago OHare 9L P 90˚ 270˚ 13000 200 041.98324 087.89624 041.98368 087.89671 041.98410 087.89718 041.98441 087.89753

SFO1 San Francisco 28L E 297.8˚ 117.8˚ 10602 200 037.61983 122.37906 037.62013 122.37864 037.62051 122.37809 037.62081 122.37767

Designated points

Hold Entry Exit BoundryScenerio AirportDesignators

Runway

Direction Dimensions

Table 2 (distances are represented in feet)

Airport dimensions used were provided by NASA.

VI. Iteration

Process was the threaded object that performed the iterations through the inputted data file. The data file was

parsed one line at a time and that whole line of data was sent into the Aircraft Tokenizer to be broken into several

data objects.

The data objects representing the simulated aircraft were

then stored in local memory and calculations which determined

the aircrafts cardinal points were performed as each aircraft

object was re-initialized. The cardinal points (nose, right wing,

left wing, tail) were represented by their own latitude and

longitude, and were calculated using the formula in Figure 6.

The overall distance between the two imaginary aircraft skins

were determined by calculating the distance between the

cardinal points of the two aircraft as shown in Figure 1.

The next line of data was read and the distances were

calculated. The overall distance from that line of data was

compared to the previous line of data and the shorter distance of

the two was retained until the entire data file was read. The

output file, a single line of comma separated data, was generated

depicting the point in time where only the shortest distance

between each aircraft was represented.

As the simulated aircraft traveled along the airport’s

taxiway, there were several points where the aircraft may have come into a closer proximity to each other. Because

our goal was to determine the closest proximity at runway crossings, we had to institute a safe guard in order to

eliminate any “false” closest proximity recordings. An imaginary rectangle was overlaid at the runway crossings

and data prior to the primary aircraft reaching that “test area” was discarded.

Figure 1 Calculating distances between aircraft


5

VII. The Mathematics

The NASA 747-400 simulator not only reported the center of gravity, but other parts of the aircraft’s kinematical

information. We needed some of this other kinematical information to perform the calculations necessary to

accurately overlay our imaginary airframe over the aircraft’s center of gravity. Throughout the algorithm, extensive

mathematics were used to calculate the distances from the aircrafts center of gravity to the individual aircraft’s

cardinal points. These formulas are commonly used in the aircraft simulation industry, and are listed and explained

below. Distances that were reported to us in feet had to be converted into radians for the formulas to work. The

resultant distances were converted from radians to nautical miles and ultimately back into feet and inches.

A. Distance between two points on a sphere

When calculating the distance

between two points on the earth, we

decided on a spherical shaped earth

model, where the earth's radius is

3443.9557 nautical miles. See the

formula in Figure 2. A spherical earth

model was used because we were

calculating such small distances between

the aircraft’s parts and between the

simulated aircraft themselves; therefore

we determined that an ellipsoid earth

model was not necessary.

B. Calculating true course heading

True course heading was

calculated using the formula in Figure

3, making sure to use a reference to

true north, these calculations were also

measured in radians. This formula was

used to build the imaginary rectangle

that was placed over the

runway/taxiway crossings.

)cos())cos()(cos())sin()(sin( 212121 lonlonlatlatlatlatd r −∗∗+∗=

Figure 2 Distance between two points on a sphere.

)))cos()/(sin())cos()sin()n(arccos((si 112 latddlatlatT rrc ∗∗−=

Figure 3 True Course Heading


6

C. Calculating the distances of the aircrafts parts

)cos()sin()cos()sin()(arcsin(cos1 rrc dxxdTX ∗+∗∗=

180)( <cTif

yXxXxdY r −∗−= ))cos()/(cos()sin(*)sin()s(arccos((co 111

180)( ≥cTif

yXxXxdY r +∗−= ))cos()/(cos()sin(*)sin()s(arccos((co 111

The NASA 747-400 simulator’s output included the heading of the aircraft in relationship to true north or 000˚

true. With that information, we calculated the aircrafts’ cardinal points relative to the heading of the aircraft itself.

That gave us an accurate latitude (X1..) and longitude (Y1..) for that aircraft’s part. For instance the 747-400’s nose is

92.873 feet due north (from Table 3, 000˚) relative

from the center of gravity of the aircraft. The aircraft

in turn is traveling a course of 090˚ true north; we

therefore know that the nose of the aircraft is 92.873

feet on a bearing of 090 from the aircraft center of

gravity’s latitude and longitude (h = 000+090). If the

Figure 4 Calculating the distances of the aircrafts parts

Aircraft part Relative heading (hr)

Nose 000

Starboard Wing tip 090

Tail 180

Port Wing tip 270

Table 3 Relative heading of aircraft parts


7

addition of the relative and true headings exceeded 360˚, we subtracted 360 from our total.

In order to accurately calculate the latitude and longitude of the 747-400’s wing tips, it was necessary to use an

offset value provided to us by NASA. The wing tips of a 747-400 are not directly 90 and 270 degrees relative from

the aircrafts center of gravity. See Figure 4.

The calculation of a point’s latitude (X), longitude (Y), distance in feet (d) and heading in radians (h) from a

reference point (center of gravity) was derived from the heading and distance formulas above. If the heading of the

aircraft was less than 180 degrees, the y value (longitude (y) value of the center of gravity) would be added to the

new Y1.. coordinate. Otherwise, the given y value would be subtracted from the new Y1.. coordinate value. This

calculation was necessary to account for the absolute difference of the y variables in the distance formula. Wingtip,

head and tail position calculations would add 90 or 180 degrees according to how it is reference to the direction

(heading of the plane) and distance from the center of gravity. Aircraft dimensions for the aircraft used in the

simulation were provided by NASA.

VIII. Conclusion

The algorithm provided critical information to the researchers with regards to aircraft position and distance

between two aircraft that were involved in an incursion. This information was used to determine a number of

performance measures and scenario descriptions that they used to make inferences about the impact on safety that

the procedure under study had on the system. The concept of measuring aircraft from metal-to-metal could also be

utilized in other algorithms where a more accurate picture of the aircraft needs to be depicted. As in this study, the

precision of the measurements (metal-to-metal) will be based on the accuracy of the recorded latitudes and

longitudes of the NASA simulator or any other simulator used.

Acknowledgments

G.S Author thanks Paul Valenti, for providing the graphics needed to represent the simulated aircraft.

1 Buondonno K., Bender K., Racine N., and Sierra E “Aircraft Landing Lights Enhance Runway Traffic Safety,” DOT FAA

CT-TN05/18, 2005

2 Horstmann, Cay S., and Cornell Gary, “Core JAVA Volume I – Fundamentals”, Sun Microsystems Press, A Prentice Hall

Title, 1999, Sun Microsystems Inc., 901 San Antonio Road, Palo Alto, California, Chap 1, pp 6.

3Sullivan, Barry T, and Soukup, Paul A, “The NASA 747-400 Flight Simulator: A National Resource for Aviation Safety

Research”, URL http://www.simlabs.arc.nasa.gov/library_docs/tech_papers/747_flight_simulator.html

[american institute of aeronautics and astronautics aiaa modeling and simulation technologies...

Documents