[american institute of aeronautics and astronautics aiaa modeling and simulation technologies...
TRANSCRIPT
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.
American Institute of Aeronautics and Astronautics
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
American Institute of Aeronautics and Astronautics
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)
American Institute of Aeronautics and Astronautics
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
American Institute of Aeronautics and Astronautics
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
American Institute of Aeronautics and Astronautics
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
American Institute of Aeronautics and Astronautics
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