NASA/TM-2017-219669

An Efficient Universal TrajectoryLanguage

George E. Hagen, Nelson M. Guerreiro, Jeffrey M. Maddalon, Ricky W. Butler, Langley Research Center, Hampton, Virginia

September 2017

https://ntrs.nasa.gov/search.jsp?R=20170009610 2019-02-15T21:49:32+00:00Z

NASA STI Program . . . 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 plays a key part in helping NASA maintain this important role.

The NASA STI program operates under the auspices of the Agency Chief Information Officer. It collects, organizes, provides for archiving, and disseminates NASA’s STI. The NASA STI program provides access to the NTRS Registered and its public interface, the NASA Technical Reports Server, thus providing one of the largest collections of aeronautical and space science STI in the world. Results are published in both non-NASA channels and by NASA in the NASA STI Report Series, which includes the following report types:

• TECHNICAL PUBLICATION. Reports ofcompleted research or a major significant phase ofresearch that present the results of NASAPrograms and include extensive data or theoreticalanalysis. Includes compilations of significantscientific and technical data and informationdeemed to be of continuing reference value.NASA counter-part of peer-reviewed formalprofessional papers but has less stringentlimitations on manuscript length and extent ofgraphic presentations.

• TECHNICAL MEMORANDUM.Scientific and technical findings that arepreliminary or of specialized interest,e.g., quick release reports, workingpapers, and bibliographies that contain minimalannotation. Does not contain extensive analysis.

• CONTRACTOR REPORT. Scientific andtechnical findings by NASA-sponsoredcontractors and grantees.

• CONFERENCE PUBLICATION.Collected papers from scientific and technicalconferences, symposia, seminars, or othermeetings sponsored or co-sponsored by NASA.

• SPECIAL PUBLICATION. Scientific,technical, or historical information from NASAprograms, projects, and missions, oftenconcerned with subjects having substantialpublic interest.

• TECHNICAL TRANSLATION.English-language translations of foreignscientific and technical material pertinent toNASA’s mission.

Specialized services also include organizing and publishing research results, distributing specialized research announcements and feeds, providing information desk and personal search support, and enabling data exchange services.

For more information about the NASA STI program, see the following:

• Access the NASA STI program home page athttp://www.sti.nasa.gov

• E-mail your question to help@sti.nasa.gov

• Phone the NASA STI Information Desk at757-864-9658

• Write to:NASA STI Information DeskMail Stop 148NASA Langley Research CenterHampton, VA 23681-2199

NASA/TM-2017-219669

An Efficient Universal TrajectoryLanguage

George E. Hagen, Nelson M. Guerreiro, Jeffrey M. Maddalon, Ricky W. Butler,Langley Research Center, Hampton, Virginia

National Aeronautics andSpace Administration

Langley Research CenterHampton, Virginia 23681-2199

September 2017

Available from:

NASA STI Program / Mail Stop 148

NASA Langley Research Center

Hampton, VA 23681-2199

Fax: 757-864-6500

The use of trademarks or names of manufacturers in this report is for accurate reporting and does not

constitute an official endorsement, either expressed or implied, of such products or manufacturers by the

National Aeronautics and Space Administration.

Abstract

The Efficient Universal Trajectory Language (EUTL) is a language for specifyingand representing trajectories for Air Traffic Management (ATM) concepts such asTrajectory Based Operations (TBO). In these concepts, the communication of atrajectory between an aircraft and ground automation is fundamental. Historically,this trajectory exchange has not been done, leading to trajectory definitions thathave been centered around particular application domains and, therefore, are notwell suited for TBO applications. The EUTL trajectory language has been definedin the PVS formal specification language, which provides an operational semanticsfor the EUTL language. The hope is that EUTL will provide a foundation formathematically verified algorithms that manipulate trajectories. Additionally, theEUTL language provides well-defined methods to unambiguously determine positionand velocity information between the reported trajectory points. In this paper, wepresent the EUTL trajectory language in mathematical detail.

iii

Contents

1 Introduction 1

2 Related Work 3

3 Trajectory Overview 6

3.1 Trajectory Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 Well-Formed Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.3 Consistent Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3.1 Turn TCP Constraints . . . . . . . . . . . . . . . . . . . . . . 10

3.3.2 Ground Speed TCP Constraints . . . . . . . . . . . . . . . . 10

3.3.3 Vertical Speed TCP Constraints . . . . . . . . . . . . . . . . 11

3.4 Velocity-Continuous Plans . . . . . . . . . . . . . . . . . . . . . . . . 11

4 Language Elements 11

4.1 The Plan Data Structure . . . . . . . . . . . . . . . . . . . . . . . . 11

4.2 EUTL Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Informal Semantics of Position and Velocity Functions 13

5.1 Non-accelerating Segments . . . . . . . . . . . . . . . . . . . . . . . . 13

5.2 Multiple Acceleration Zones . . . . . . . . . . . . . . . . . . . . . . . 15

5.3 Path Distance Between Index Points . . . . . . . . . . . . . . . . . . 15

5.4 Interpolating Within Acceleration Zones . . . . . . . . . . . . . . . . 17

5.4.1 Computing Ground Speeds at Index Points . . . . . . . . . . 17

5.4.2 Determining Distance From a Time Within a Segment . . . . 18

5.4.3 Advancing a Specified Distance Within a Segment . . . . . . 18

5.5 Velocity at a Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.6 Vertical Component of Position . . . . . . . . . . . . . . . . . . . . . 19

5.7 Summary of Calculation Steps . . . . . . . . . . . . . . . . . . . . . 20

6 Operational Semantics 20

6.1 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

6.2 Summary of Utility Functions . . . . . . . . . . . . . . . . . . . . . . 21

6.3 Calculating Path Distance . . . . . . . . . . . . . . . . . . . . . . . . 23

6.3.1 Straight Path . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.3.2 Circular Turn . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6.3.3 Combined Function . . . . . . . . . . . . . . . . . . . . . . . 24

6.4 Ground Speed Within a Segment . . . . . . . . . . . . . . . . . . . . 24

6.5 Determining Distance From a Time in a Segment . . . . . . . . . . . 25

6.6 Advancing a Calculated Distance Within a Segment . . . . . . . . . 26

6.6.1 Straight Linear Segment . . . . . . . . . . . . . . . . . . . . . 26

6.6.2 Turn Segment . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.7 Full Position and Velocity Function . . . . . . . . . . . . . . . . . . . 28

6.8 The posVelWithinSeg Function . . . . . . . . . . . . . . . . . . . . 28

iv

6.9 The initialVelocity Function . . . . . . . . . . . . . . . . . . . . 296.10 The interpolateAltVs Function . . . . . . . . . . . . . . . . . . . . 296.11 Consistent Plans, Revisited . . . . . . . . . . . . . . . . . . . . . . . 30

6.11.1 Track TCP Constraints . . . . . . . . . . . . . . . . . . . . . 306.11.2 Ground Speed TCP Constraints . . . . . . . . . . . . . . . . 316.11.3 Vertical Speed TCP Constraints . . . . . . . . . . . . . . . . 31

6.12 Velocity-Continuous Plans, Revisited . . . . . . . . . . . . . . . . . . 32

7 TCP Generation 347.1 TrajGen.makeKinematicPlan . . . . . . . . . . . . . . . . . . . . . . 357.2 DistPlan.makePlan . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

8 Generation of Medium Fidelity Trajectories 38

9 Concluding Remarks 47

A Support Functions 50A.1 TCP Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50A.2 The getSegment Function . . . . . . . . . . . . . . . . . . . . . . . . 51A.3 In Acceleration Zone Functions . . . . . . . . . . . . . . . . . . . . . 51

B Great Circle Functions 52B.1 angular distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.2 distance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52B.3 initial course and final course . . . . . . . . . . . . . . . . . . 52B.4 angle between . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53B.5 velocity initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54B.6 linear initial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

C Chordal Radius 56C.1 Function chord distance . . . . . . . . . . . . . . . . . . . . . . . 56

D Ground Speed vs. Airspeed 58

v

Abbreviations

2D 2-Dimensional3D 3-Dimensional4D 4-DimensionalAIDL Aircraft Intent Description LanguageATN Aeronautical Telecommunications NetworkATM Air Traffic ManagementBGS Beginning of Ground Speed accelerationBOT Beginning Of TurnBVS Beginning of Vertical Speed accelerationCAS Calibrated AirspeedEGS End of Ground Speed accelerationEOT End Of TurnEPP Extended Projected ProfileEUTL Efficient Universal Trajectory LanguageEVS End of Vertical Speed accelerationFAA Federal Aviation AdministrationFMS Flight Management SystemsIAS Indicated AirspeedRTA Required Time of ArrivalRTCA Radio Technical Commission for AeronauticsTAS True AirspeedTBO Trajectory Based OperationsTIGAR Toolkit for Integrated Ground/Air ResearchTCP Trajectory Change Point

vi

1 Introduction

In this paper we present a language for representing aircraft flight trajectories in amanner that allows for precision, simplicity, and efficiency. Although hundreds ofpapers have been written about trajectories and trajectory generation [1–8], we willnot seek to provide a comprehensive treatment of the subject or even to develop ataxonomy of the plethora of approaches that have been proposed. Instead we willstart from the desired basic mathematical properties and then proceed to developthe language along with a practical data structure that provides all of the neededfunctionality. We call this language the Efficient Universal Trajectory Language(EUTL). It is efficient because trajectories can be stored and communicated in away that is reasonably compact and positions and velocities can be quickly calcu-lated. The language is universal in that it does not require other aircraft systems orcomponents, such as the flight management computer or flight control computer, tore-construct the trajectory for an aircraft. Universality is a important requirementbecause it allows trajectories to be exchanged between aircraft and ground-basedsystems without ambiguity. This paper presents a detailed, mathematical descrip-tion of the EUTL language, which can be used to precisely define the trajectory foran aircraft. This paper does not focus on the problem of how to generate a trajec-tory to meet specified objectives or how to use trajectory information from a EUTLtrajectory. Methods for constructing trajectories for different types of aircraft andvarious levels of fidelity are also not addressed here. This paper is only concernedwith the problem of how to represent a trajectory in an unambiguous and efficientmanner.

A moving object follows a path, or a sequence of positions, through space. Whenthis path is augmented with a time for each position, it is referred to as a trajectory ora four dimensional trajectory (4DT). In the literature, a path is sometimes referredto as a “3D trajectory.” We avoid this terminology due to an intrinsic ambiguity.Does this 3D trajectory mean three spatial dimensions, without time or two spatialdimensions (typically latitude and longitude) and time? For this reason, we willrefer to a sequence of positions, without reference to time, as a path and a path, ofany dimension, that is augmented with times, as a trajectory.

Although the aviation and Air Traffic Management (ATM) communities haveproduced a large amount of work on trajectory generation and trajectory repre-sentation, there is a surprising lack of unity among the approaches. This could bebecause trajectories are fundamental to many different types of operations, eachhaving a different focus. For instance, a pilot enters a sequence of waypoints into aflight management system (FMS), then adds a cruise speed and altitude. With thisinformation, the flight management system can compute a reference path and/or aset of guidance commands necessary to meet the pilot’s instruction. It is thereforenot surprising that trajectories are sometimes defined as a series of these guidancecommands along with their associated execution times. This approach works wellif one is only concerned with communicating a trajectory between the flight man-agement system and the flight guidance system. However, if a recipient externalto this aircraft were to receive this sequence of guidance commands, it would have

1

to have a fairly detailed model of the flight guidance system of the sending aircraftto determine where the aircraft will be at any time. In other words, this abstractversion of the trajectory must be converted to a more concrete version before it canbe effectively used by the recipient. This process is typically called trajectory pre-diction.1 All recipients of the abstract trajectory must have a detailed model of theaircraft dynamics in order to perform this trajectory prediction process. We believethat trajectories that will be communicated to external agents should be representedin a form that does not require a complex trajectory prediction process. It is for thisreason that we introduce the EUTL language. Trajectories generated by any agentin the ATM system can be accurately translated to EUTL and then communicatedconsistently to all other participants. And these participants can interpret EUTLthrough use of the unambiguous mathematical semantics given in this paper. Wehave, therefore, sought to provide sufficient details so that readers of this papercould create their own implementation of EUTL on any desired platform.

A trajectory defined using EUTL only models the position and velocity statevariables of an aircraft. Conceptually, a trajectory language could also model otherstate variables such as the attitude angles of the aircraft, the angular rates of thesevariables, or even higher order derivatives, such as positional or angular acceleration.We have deliberately chosen to not include these state variables in our language. TheEUTL language is intended to be used for air traffic management systems that willbe necessary for Trajectory Based Operations (TBO). In such systems, the accuraterepresentation and communication of trajectories is the essential capability. Otherstate variables may be used in generating a trajectory, but we do not believe (at thistime) that they will be needed by other systems that receive the trajectory. Futureresearch can investigate if there is benefit to including other state variables in anair traffic management trajectory language.

In this paper we present a method for defining a relatively small set of dataand associated functions, such that the trajectories can be computed in an accurateand efficient manner. Although many of these derivations may seem obvious, thechoice was made to describe the data and functions completely instead of leavingoften significant details unstated. This work builds on [9], where our trajectorydefinition did not allow ground speed acceleration zones to overlap with turns. Theprevious version also relied heavily on the use of Euclidean calculations and the useof mathematical projections to geodesic coordinates. Instead of projections, the newapproach described in this paper uses spherical trigonometry because we have foundthis to be computationally faster and more accurate.

A formal semantics for EUTL has been developed in the PVS specification lan-guage [10, 11], which is presented in Section 6. We believe that this language canprovide a foundation for mathematically verified algorithms that manipulate trajec-tories. There is much evidence that a major obstacle to the deployment of advancedsoftware systems in the National Airspace (NAS) is the current lack of suitable

1Historically, the trajectory prediction process generates a trajectory from an aircraft’s flightplan, its current state, and from wind and temperature data. A sequence of guidance commandsprovides additional information and enables better prediction.

2

verification technology that can establish the safety of software-intensive advancedsystems [12]. Java and C++ implementations of EUTL have also been developedand have been used to store and manipulate trajectories in the Stratway program [13]and for fast-time conflict-detection studies [14,15].

2 Related Work

In this section we will look at some of the past methods used to describe trajectories.We will not delve into the massive and complex set of approaches to trajectory gen-eration. Instead, we will restrict our attention to methods used to specify the outputfrom a trajectory generation process, whether by a person or a machine. Accordingto the International Civil Aviation Organization, a trajectory is, “a description ofthe movement of an aircraft, both in the air and on the ground, including position,time and, at least via calculation, speed and acceleration” [16]. In the air trafficmanagement literature, a wide number of approaches to trajectory representationhave been described:

• a sequence of 3D points (latitude, longitude, altitude) with a small, fixed timeinterval between them (e.g., 1 second) and a start time. Trajectories like thisare referred to as trajectory traces or raw trajectories and may be representedas a sequence of uniformly-sampled 4D points [17];

• a sequence of 4D points (latitude, longitude, altitude, time) with large andirregular time intervals between them (e.g., 15 minutes). There are many dif-ferent approaches to interpolating between them including straight-line, La-grange, Hermite, Bezier, homotopy, and various spline methods [18];

• a sequence of timed guidance commands [19];

• a sequence of 2D points with a separate speed profile and vertical profile thatare functions of path distance [1];

• a sequence of 2D points with speed/altitude constraints and perhaps a finalrequired time of arrival (RTA) [20];

• a sequence of 4D points (latitude, longitude, altitude, time) that has a contin-uous velocity vector by adding information about accelerations (e.g. EUTL);

Probably the most basic notion of a trajectory for air traffic management isthe flight plan that is filed with the Federal Aviation Administration (FAA) fora particular flight. This flight plan route defines a set of waypoints that will besequenced by the aircraft during its flight. This is augmented with some informationabout the expected departure time, cruise altitude, and target airspeed for thatflight. This provides a very crude prediction of where an airplane will be at anygiven time in the future. At the other end of the spectrum is the reference trajectorythat is calculated by a flight management system. This is the most precise, mostdetailed representation of the trajectory of any entity in the system. However, this

3

trajectory is contained in an internal data structure of the FMS and is traditionallynot exported to other agents in this form.

Another notion of a trajectory is a sequence of guidance commands such asHOLD TO AN ALTITUDE, CONSTANT RADIUS TO A FIX, COURSE TO AN INTERCEPT, orDIRECT TO FIX. These guidance commands are expected to be generated by anFMS and sent to a flight guidance system/flight control system [21]. This notionof a trajectory can also be used to communicate aircraft trajectory information toother airspace users [22]. Determining the exact trajectory represented by theseguidance commands requires a detailed model of the guidance and control systemsof the aircraft. Without corresponding precise models, the exact trajectory is notknown. This can be considered an advantage in that the guidance commands areindependent of a specific manufacturer’s implementation. Unfortunately this leadsto a greater error between the trajectory as flown and the trajectory represented bythe guidance commands. Depending on the intended purpose of the trajectory, thiserror may or may not be acceptable.

There have been many proposed mechanism to specify a trajectory in a mannerthat enables its communication to other agents in the ATM system. We will look atonly a few. We begin with Paielli’s approach presented in [1] because this approachprovides a set of requirements that they believe should be met by any method thatseeks to specify a trajectory for air traffic operations. They state that the basicrequirements of a trajectory representation should be:

1. able to precisely specify any reasonable 4D reference trajectory;

2. able to precisely specify error tolerances relative to the reference trajectory;

3. based on a global earth-fixed coordinate system (e.g., the WGS84 geodeticcoordinate system);

4. parametric and reasonably compact;

5. based on a text format readable by humans; and

6. suitable for an international standard.

We concur that these requirements move the field of trajectory specification towardsa more solid foundation. We also add to that list the following requirement:

7. the method for calculating position and velocity at any point in the trajectoryshould be specified in detail.

Paielli then presents an XML-based language that can be used to specify a trajec-tory in a way that meets all of these requirements. The horizontal path of such atrajectory is specified using a sequence of straight, great circle segments connectedby turns of a specified radius. The along-track position is specified as a polynomialfunction of time; altitude is a polynomial function of along-track position. Thesepolynomials are obtained from trajectory traces by curve fitting and are not lim-ited to any particular order of polynomial. This method is similar to ours in that

4

it enables a mathematically precise determination of where an aircraft is at anytime. There is a close connection between his approach and ours for the 2D path;however, altitude and speed are handled very differently. He makes the followingobservation [1]:

“Suppose, for example, that an aircraft is on approach for landing andis one minute behind schedule (but still within tolerance). If altitudeis specified as a function of time, the aircraft will be required to landseveral miles before it reaches the runway! On the other hand, if altitudeis a function of along-track position, the aircraft will be required to landat the runway regardless of its status with respect to its schedule.”

This design choice has some domain specific advantages. However, there are sometrade-offs. For example, one cannot perform conflict detection without having aprecise mapping from time to 3D position. We also note that in his approach,along-track position is specified as a polynomial function of time. So this part ofhis trajectory specification must be recalculated in the very context he is describ-ing. Nevertheless, this decomposition approach may provide some computationalefficiencies. Here we see why there are so many different approaches to trajectoryspecification. What is given priority or what is ignored in a specification is depen-dent upon where it is used. Tools can be constructed that generate trajectoriesgiven a myriad of different combinations of constraints. But in the end, that result-ing trajectory should be a mathematical function from time to position2. One ofthe uses for the EUTL is described later in this paper, where we developed a toolthat takes altitude as a function of path distance and speed as a function of pathdistance and generates a trajectory in our specification language.

The next approach to trajectory specification that we would like to consideris the Aircraft Intent Description Language (AIDL) [19, 23]. AIDL is essentiallyan abstraction of the most common guidance commands that are available on atransport class aircraft. It is therefore the input to a guidance or control systemand so does not meet requirement (1) of the Paielli requirements. This languageis suitable for describing the output of an FMS, but reconstructing an accuratetrajectory of the aircraft requires a detailed model of the guidance and/or controlsystem of the aircraft.

Another example of a trajectory description that has been defined for air trafficoperations is the Extended Projected Profile (EPP). The EPP has been defined inthe RTCA Data Communications standards for the Aeronautical Telecommunica-tions Network (ATN), Baseline 2 as a method for the exchange of trajectory infor-mation between an aircraft and ground automation [24,25]. Appropriately-equippedaircraft are expected to be able to translate their FMS reference trajectory into theEPP specification and provide that EPP trajectory to ground automation as neededor as required.

The EPP specification calls for a set of up to 128 trajectory points with infor-mation such as the 2D reference position, the reference altitude, the predicted time,

2The closely related function from time to velocity is also defined in our operational semantics.

5

the predicted airspeed, as well as other optional information, such as turn radiusand speed, altitude, or time constraints. Although this specification is intended tobe a detailed description of the planned trajectory for an aircraft, it has inherentambiguities. First, the points provided in the EPP trajectory provide estimates forthe times at those reference points but assumptions have to be made in order toestimate the position of the aircraft at times between available trajectory points.Even though the EPP points provide estimated speed information, these speeds areindicated airspeeds, which require the use of wind and temperature forecast tablesto properly convert to ground speeds that can be used to estimate the positionsbetween points. As a consequence, significant along-track errors may be presentin an EPP-described trajectory, especially in trajectories containing long segmentsbetween turns. Lateral turn points are provided in terms of the reference 2D point(e.g., the sequenced waypoint), an estimated altitude and time, an expected air-speed, and the predicted turn radius. Depending on the coordinate system used,the computations to estimate other points of the turn, such as the expected startand end of turn, which are important when the aircraft is using a fly-by maneuver tosequence a waypoint, can produce somewhat different positions and estimated times.Because of potential significant along-track error and a lack of rigorous mathemat-ical definition and the ambiguities it creates, the EPP trajectory specification maynot be the best suited trajectory description for performing certain air traffic systemfunctions, such as conflict detection.

In the following sections we describe EUTL as well as its associated mathemat-ical properties and functions, which make EUTL a mathematically unambiguousdescription of a trajectory.

3 Trajectory Overview

A trajectory in EUTL is modeled as a function of time into position and denoted,s(t). The velocity is also defined along all points of the trajectory and it is denotedas v(t). Trajectories can come in one of two forms, one where the positions are inEuclidean coordinates (x, y, z) or one where the positions are in geodesic coordinates(latitude, longitude, and altitude). Euclidean coordinates are often more appropri-ate when modeling trajectories of aircraft that fly in small localized areas, such assmall unmanned aircraft. Geodesic coordinates are more appropriate when model-ing long distance trajectories in the National Airspace System. The specificationof many of the properties of a trajectory does not rely on a particular coordinatesystem; however, the low-level functions that compute positions and velocities do.

The position and velocity functions are, in some sense, the essence of the specifi-cation of a trajectory. Nevertheless, the equations that define these functions, givena sequence of 3D positions and time, are non-trivial and hence are developed in twosteps. First, we define a path function as a function from distance along the path toposition and denote this function as p3D(d). Next, we define a function d3D(t) thatmaps time to total path distance. These functions can then be composed to obtains(t) = p3D(d3D(t)). One advantage of this decomposition is that the path of the air-

6

craft can be specified separately from the speed of the aircraft. With the completespecification of these two functions, then s(t) and ultimately v(t) can be defined.We note that this decomposition also enables us to use distance as an alternativeindex for trajectories.

Typically, navigation is divided between horizontal planning and vertical plan-ning. Therefore, a single three dimensional path distance function is usually not thefocus of ATM service providers. They typically measure distance between points ona map (horizontal path distance), which does not include distances obtained fromaltitude changes. We therefore separate the horizontal and vertical dimensions. Thevertical dimension is simpler than the horizontal, so a decomposition into two sub-functions is not necessary. The vertical position z(t) is defined directly as a functionof time.

s(t) = (p(d(t)), z(t))

We make the assumption that the horizontal path of the aircraft only consists ofcombinations of straight and circular segments, so the horizontal path function, p,can be defined in a straightforward manner (details are provided in Section 5.7).

Next we turn our attention to the horizontal path distance function, d(t). Thisfunction fundamentally relies on the horizontal speed. As an example, if the groundspeed is constant, then the path distance function could be defined as

d(t) = vgs min(t, T )

where, vgs is the ground speed and T is the end time of the trajectory. A realistictrajectory with many speed changes has a much more complicated d(t) function.With this background, we can turn to how to encode the key information of atrajectory.

3.1 Trajectory Abstraction

Instead of arbitrary functions s and v, we provide five key assumptions that enablethe encoding of these functions to be efficient in both space (relatively few bytesof information are required to store or communicate them) and time (they can bereconstructed quickly). These assumptions, several of which were alluded to in thediscussion above, are:

1. the trajectory is divided into segments—sections of the trajectory partitionedby time;

2. a segment is either an accelerating segment or a non-accelerating segment;

3. viewed from above, all segments are either straight or circular arcs, and arcsalways have associated angles of less than 180◦;3

4. all changes in ground speed are represented via constant acceleration segments;and

3Larger arcs can be created using a sequence of consecutive arcs each having associated anglesof less that 180◦.

7

5. all changes in vertical speed are represented via constant acceleration seg-ments.

Real aircraft are subject to non-constant accelerations and may follow paths thatare neither straight nor circular; however, with a sufficient number of segments,this structure can model very complex trajectories. Future work will characterizethe accuracy of the EUTL approach in representing trajectories used in differentapplication domains.

The EUTL trajectory abstraction is a time-sequence of 3D points where some ofthese points are labeled as Trajectory Change Points (TCPs). Since the abstractionrelies on points and not functions, we introduce notation to describe these points.The symbols si,vi, ti represent the position, velocity, and time of the ith point in thetrajectory, respectively. A segment within a trajectory refers to the interval betweenpoints, so the ith segment refers to the interval between the ith and ith +1 pointsin the trajectory. The presence of absolute time values in the trajectory implicitlydefines an average ground speed over the segment. Although aircraft performancefundamentally relies on airspeed, many ATM functions depend on accurate predic-tions of aircraft locations relative to each other. For a discussion about the issuesassociated with ground speed vs. airspeed see Appendix D.

The TCPs represent the start or end of a segment over which there exists aconstant acceleration. There are three types of acceleration: turns, ground speed(horizontal) acceleration, and vertical speed acceleration. Furthermore, we mustindicate whether a TCP is the beginning or end of an acceleration segment.4 Tosummarize, the TCPs defined in the EUTL language are:

BOT beginning of turnEOT end of turnBGS beginning of ground speed accelerationEGS end of ground speed accelerationBVS beginning of vertical speed accelerationEVS end of vertical speed acceleration

The beginning TCP also encodes the exact acceleration value; in the case of a turn,this is the turn radius and center of turn position5. The end TCP provides theduration of acceleration, as well as a position reference for checking the accelerationcalculations. This concept is illustrated in Figure 1. Each of the dots represent a 3Dwaypoint. The colored waypoints are TCPs. The black waypoints could representestablished reference navigation fixes or other points of reference such as RTA points,or could be redundant and optionally eliminated.

In EUTL a trajectory is encoded as a sequence of points, with some designatedas the beginning or end of an acceleration zone. We refer to this structure as aplan. A trajectory is an abstract concept, whereas a plan is a structure that can beencoded in software. Much of the discussion in the rest of this paper is about plans.

4The inclusion of both a beginning and end point, as opposed to only a beginning point with aduration parameter, allows for additional easy consistency checking of an encoded trajectory.

5The center of turn is stored for computational efficiency.

8

BOT

EOT

BOT

EOT

BOT

EOT

BOT

EOT

BVS

EVS

EVS

BVS

EGS

BGS

Figure 1: Example Trajectory with TCPs

If a plan does not contain any acceleration segments we say it is a linear plan. Ifit contains at least one acceleration segment, then it is said to be a kinematic plan.Because there is a time associated with each point in a plan, an average velocityis implicitly defined for each segment; however, for kinematic plans the velocitymay vary over an accelerating segment. A linear plan typically has a discontinuousvelocity at the index points, whereas a kinematic plan (if constructed properly) willhave a continuous velocity vector throughout the plan.

3.2 Well-Formed Plans

Not all sequences of points form an arrangement that properly defines a trajectory.Certain restrictions need to be placed on a sequence of points to ensure that atrajectory can be formed from them. We refer to these conditions as: well-formed,consistent, and velocity-continuous. These conditions are described in this sectionand the next two sections.

A plan is well-formed if:

• there are at least two points in the plan;

• each point is appropriately ordered by time (that is, time(i) < time(i+ 1));

• every beginning TCP has a corresponding ending TCP; and

• there are no two acceleration zones of the same type that are overlapping intime.

Given the three types of TCP-pair segments (turn, ground speed, and verticalspeed), we allow different segment types to overlap in time, but segments of thesame category cannot overlap. For example, a beginning of turn TCP (BOT) mustbe followed at some point later in the plan by a corresponding end of turn TCP(EOT) and this zone must not overlap another BOT/EOT pair. This must also be trueof all (BGS/EGS) and (BVS/EVS) pairs. As a special case, one acceleration zone canend at precisely the same point where another acceleration zone of the same typebegins. This is accomplished through use of the special combination TCPs: EOTBOT,EGSBGS, and EVSBVS.

9

3.3 Consistent Plans

A plan is consistent when:

• it is well-formed; and

• every end TCP point matches the position kinematically-calculated from itscorresponding beginning TCP point and its acceleration value.6

In essence, consistent plans ensure that the mathematical relationship between thebeginning TCP point and the ending TCP point is maintained. The trajectorygeneration process can be quite complex and latent errors in this complexity maycause the formation of inconsistent plans. The mathematical constraints that defineconsistency for each of the three types of TCPs are presented in the next threesubsections.

3.3.1 Turn TCP Constraints

The BOT and EOT positions and associated acceleration data must be consistent witheach other. A constant-acceleration turn is described by a radius and center ofturn, which defines the turn arc from the BOT point to the EOT point. The radiusis stored as a signed value, where the sign encodes the turn direction (a positiveradius is clockwise, negative counterclockwise) and the magnitude is the actualradius value. For a plan to be considered consistent, it is necessary that both theBOT and EOT points are on this circle. In addition all other points between BOT andEOT should be on this circle. Each of these tests is accomplished by measuring thedistance from the point to the center of turn and ensuring that this distance is thesame as the radius.

Because the only information stored about a turn is the radius and turn center,not all information contained in the BOT and EOT is tested in this consistency check.Specifically, neither the altitude, nor the time components are checked because thesevalues are not constrained by the turn structure.

3.3.2 Ground Speed TCP Constraints

The information stored for a ground speed change in segment i is the ground speedacceleration value, denoted agsi . The path distance between BGS and EGS mustsatisfy the following equation:

path distance = vgsi∆t +1

2agsi∆

2t ,

where ∆t is the time between BGS and EGS and vgsi is the ground speed at thebeginning of the segment, that is, the ground speed coming out of BGS. The pathdistance refers to the two-dimensional path distance and this path distance is definedassuming the plan is turn consistent, per Section 3.3.1.

6We note that this calculation can be complicated if this TCP pair overlaps with other TCPpairs of a different type.

10

3.3.3 Vertical Speed TCP Constraints

The information stored for a vertical speed change is the vertical speed accelerationvalue, denoted avsi . The vertical path distance between the BVS/EVS pair mustsatisfy the following equation:

vertical distance = vvsi∆t +1

2avsi∆

2t ,

where ∆t is the time between BVS and EVS and vvsi is the vertical speed at thebeginning of the segment, that is, the vertical speed coming out of BVS. The verticaldistance is simply the change in altitude from BVS to EVS.

3.4 Velocity-Continuous Plans

A linear plan can contain instantaneous velocity changes at the index points; how-ever, conventional aircraft cannot make instantaneous velocity changes. Althoughlow momentum vehicles, such as rotorcraft or quadcopters, can perform nearly in-stantaneous velocity changes (i.e., direction changes with no turn radius), we con-strain our discussion in this section to trajectories with continuous velocity vectorsat all points. We call such plans kinematic plans. We note, however, that thetrajectories of low momentum vehicles can easily be be described using the EUTLlanguage.

The velocity of a trajectory is said to be continuous at some point i providedthe velocity into point i is the same as the velocity coming out of point i. Therequirement that the velocity be the same means that every component of velocity(track angle, ground speed, and vertical speed) must be the same.

We note that linear plans typically have many velocity discontinuities whereasproperly-constructed kinematic plans are velocity-continuous. Observe that planconsistency is primarily a restriction on the positions of points, sometimes called thestructural aspects of the plan, whereas velocity-continuous plans are a restrictionon the velocity at points, and velocity relates to times of the points.

4 Language Elements

Section 3 provides an overview of trajectories and how trajectories can be encodedinto a form that is suitable for storing in a computer or communicating betweencomputers. This section provides a more detailed description of how a plan is storedand the basic functions used with a plan. The key functions of position and velocityare given sections of their own. This section provides many of the important detailsnecessary to understand the sections describing position and velocity.

4.1 The Plan Data Structure

We will now use Plan to refer to the pseudo-code operational specification of a plan.The notation used here is based on the PVS specification language. A Plan consistsof these lists:

11

points: [nat -> NavPoint]

data: [nat -> TcpData]

A NavPoint is a data structure that consists of 3D position, a time, and a stringname. It can be defined as follows:

(p:Position, time: real, name: String)

A Position can be defined with either Euclidean coordinates, with the functionnewPositionXYZ, or geodesic coordinates, with the function newPositionLLA, whichthus provides a common interface and allows most other software to ignore the detailof the true nature of a position. Position is effectively a disjoint union of the twotypes. In the software, the type coercions to the appropriate type are needed, butin this paper, we leave these out to simplify the presentation. Similarly, given aNavPoint np, the expression position(np) is often just written as np. However,time(np) will always be explicit. The method isLatLon(p) returns a booleanvalue indicating whether the position is geodesic (latitude, longitude) or not. If aposition p is Euclidean the accessors x(p), y(p) and z(p) can be used to retrievethe components. If the position is geodesic, then the accessors lat(p), lon(p),alt(p) are used.

In addition to the NavPoint, each point also has a TcpData data structure. Thisstructure contains the information about whether the point is a TCP point or not.Furthermore, if the point is a TCP point, then this structure stores whether it isa beginning or ending TCP, and what type of TCP it is (track, ground speed, orvertical speed). Finally, if the point is a BOT, then the radius and center of turn arealso stored, if the point is a BGS then the ground speed acceleration is stored, andif the point is a BVS then the vertical speed acceleration is stored in TcpData.

One observation made from this definition of Plan is that the velocity is notexplicitly stored. Instead, each point contains a time and, given knowledge of theacceleration regions in a Plan, the velocity is implicitly defined for all positionsbetween these points. The computations used for velocity are foundational to thedefinition of a trajectory and thus the specification of these equations becomescritical to the definition of the trajectory.

4.2 EUTL Syntax

In this section we present a simple syntax of the Efficient Universal TrajectoryLanguage. While we are not concerned with a particular encoding of the elementsof the language, we provide a representative syntax to illustrate the main aspects ofthis information. The syntax of EUTL is extremely simple: a semicolon-separatedlist of points, with point names and TCP data being included if appropriate. Thelanguage grammar is shown in Figure 2.

Quoted terms along with parentheses, semicolons, and commas indicate literalvalues. Terms in all capital letters represent numeric or string values. Expressionscontained in square brackets ([ and ]) are optional. This data can easily be rep-resented in various formats, a human-readable one being a simple text table. Anexample of such is shown in Section 8 and Figure 20.

12

plan ::= LATLON? point listpoint list ::= point point list

::= point pointpoint ::= navpoint tcpdatanavpoint ::= TIME ( position ) [ NAME ]position ::= LAT, LON, ALT | X, Y, Ztcpdata ::= [ ( trk data ) ] [ ( gs data ) ] [ ( vs data ) ]trk data ::= trk type RADIUS | “EOT”gs data ::= gs type GS_ACCEL | “EGS”vs data ::= vs type VS_ACCEL | “EVS”trk type ::= “BOT” | “EOTBOT”gs type ::= “BGS” | “EGSBGS”trk type ::= “BVS” | “EVSBVS”

Figure 2: EUTL Grammar.

5 Informal Semantics of Position and Velocity Func-tions

In this section we provide an informal introduction to defining position and velocityas functions of time for any point within a trajectory. This section is intended toprovide the high-level mathematical overview, whereas in Section 6 detailed descrip-tions of algorithms that can be used to compute position and velocity are presented.

5.1 Non-accelerating Segments

In non-accelerating segments, the velocity is constant over the segment. Recall thataccelerating sections of a plan begin and end with TCP points. These sections canextend over several segments. Any segments of well-formed plans that do not fallwithin any TCP regions are non-accelerating segments.

In a non-accelerating segment, for all points within the segment, the velocity isconstant. As observed in Section 4.1, the velocity is not explicitly stored, so it mustbe computed. The velocity is defined as follows:

vi =si+1 − siti+1 − ti

when ti < ti+1. Since the velocity is constant over the segment, velocity as a functionof time is defined as

v(t) = vi, for ti ≤ t < ti+1. (1)

In a similar way, for a segment with a constant velocity, the position s(t) at absolutetime t within segment i is given as follows

s(t) = si + (t− ti)vi, for ti ≤ t < ti+1. (2)

13

These definitions are valid when the positions are Euclidean. If the coordinatesare geodesic, then spherical trigonometry must be used instead of conventional vec-tor algebra. In this formulation, aircraft travel in great circle paths. The positions(t) is given by

LET

∆t = ti+1 − tivi = velocity initial(si, si+1,∆t),

d = (t− ti) · gs(vi)

IN

linear initial(si, trk(vi), d)

(3)

assuming, ti ≤ t < ti+1. This definition relies on several other functions, including:

• trk(v) is the track component of velocity v;

• gs(v) is the ground speed component of velocity v;

• velocity_initial is the initial great circle velocity coming out of the initialpoint (see definition in Appendix B); and

• linear_initial is the position starting at the initial point and traveling ddistance along the great circle in the given direction (see definition in Ap-pendix B).

We note that the ground speed and vertical speed components of the velocityare constant (i.e., the same as vi above), but the track will vary over the great circlepath (in essence, over time). The velocity, v(t), at time t assuming, ti ≤ t < ti+1 isgiven by

LET

trk = final course(si, s(t))

IN

(trk, gs(vi), vs(vi))

This definition relies on two other functions:

• vs(v) is the vertical speed component of velocity v; and

• final_course is the final track angle7 going into the given point (see definitionin Appendix B).

7For the purposes of this paper, the navigational concepts of a course angle and a track angleare interchangeable.

14

5.2 Multiple Acceleration Zones

Determining the position and velocity for segments within acceleration zones ismore challenging and quite complicated in the presence of overlapping accelerationregions. Consider the trajectory shown in Figure 3. We want to find the position andvelocity at any arbitrary time t in the plan. If time t falls within segment 3 (indicatedby the dashed arrow), then one must deal with three different accelerations at thesame time. Each of the points contains a 3D position and a time, though in the

BOT

BVS

EOTEVS

t

BGS

EGS

34 5

6

2

1

0

Figure 3: Overlapping Acceleration Zones

figure the altitude profile is not shown. It is clear from the figure that point tfalls within segment 3; however, an algorithm must determine the segment numberby scanning the times at the points. The order of computation is critical whendetermining the position and velocity at time t when there are multiple overlappingacceleration regions in the plan. A straightforward calculation, similar to equation 2is not possible because the position in a turn is based on the path distance, the pathdistance is based on time and ground speed profile, and the ground speed profileis a function of path distance. To break this circular dependency, we start with afunction that computes the circular path distance between the index points, ratherthan at an arbitrary point t. Next, we define a function for path distance by time,based on the initial ground speed at the beginning index point and the given groundspeed acceleration. Combining these two results gives the horizontal position; thevertical position can be overlaid on this position. This method will only work withinthe segment containing the time point of interest. This calculation is described inmore detail in the following sections.

5.3 Path Distance Between Index Points

If the points are straight (i.e., non-turning) segments, then the distance is simplythe Euclidean distance or the great circle distance between two 2D points. If thesegment is a turn segment, the path distance can be calculated as shown in Figure 4.The path distance is di = θR where θ is the angle at the center of the turn. Recallthat the turn radius and center position are stored for each turn. We note that thepositions si and si+1 may be points within a turn and therefore can be points other

15

i

R

R

center

θ

s

s

i

i+1

d

Figure 4: Path Distance of a Turn Segment

than a BOT or EOT.

There are two different notions of radius that arise when dealing with geodesiccoordinates. They are:

• Surface Radius: the along-surface radius that is calculated using the greatcircle distance from the center of the turn to a point on the turn; and

• Chordal Radius: the part of a chord that is in the plane of the turn itself (whichis an arc of a small circle) and hence passes through the sphere’s volume.

For small-radius turns these are approximately the same, but for very large ra-dius turns (on the order of hundreds of nautical miles), there can be a significantdifference between the two values. These are illustrated in Figure 5.

R’

R

θ

Figure 5: Example Surface Radius, R, and Chordal Radius, R′.

The surface radius is labeled R and the chordal radius is labeled R′ in the figure.The turn circle is shown in blue. Note that turn circle is on the surface of the spherebut it is not a great circle (it may be referred to as a small circle). This small circleis also on the same plane as the two R′ segments. Therefore the length (i.e., pathdistance) of the blue turn is θR′.

The radius used in the path distance calculation above should be the chordalradius. Appendix C provides the equations that can be used to convert the surfaceradius to the chordal radius and vice versa.

16

5.4 Interpolating Within Acceleration Zones

Next, we need a means to interpolate within two specified points. This requires thatwe develop a method to translate from distance to time. First we establish a way tocompute the ground speed at each index point, see Section 5.4.1. If the segment isnot within a BGS-EGS region, the speed over this segment is simply the path distancebetween the end points divided by the difference in times at the end points, as inequation 1.

5.4.1 Computing Ground Speeds at Index Points

We begin by recognizing that the ground speed in an EUTL plan is not necessarilycontinuous. In particular, the ground speed can be discontinuous at the segmentboundaries in a linear plan. Therefore, we cannot rely on any ground speed infor-mation outside of the segment of interest. We distinguish between the ground speedat the beginning of the segment, denoted, vgsi , and the ground speed at the end ofthe segment, denoted, vfinali . An example of these is shown in Figure 6. The speedvgsi can be thought of as the speed coming out of segment i and vfinali−1

can bethought of as the speed coming into segment i.

Gro

und

Spee

d

gsv

ifinal

v

time

ti

i

Figure 6: Relationship between Ground Speeds

If we define

Di = horizontal path distance between point i and i+ 1,

∆t = ti+1 − ti, andagsi = ground speed acceleration (possibly 0) over segment i,

then the ground speed at the beginning of segment i is:

vgsi =Di

∆t− 1

2agsi∆t, (4)

and the ground speed at the end of segment i is:

vfinali =Di

∆t+

1

2agsi∆t .

17

These equations are easily obtained by solving for vgsi and vfinali in the fundamentaldistance and velocity kinematic equations:

Di = vgsi∆t +1

2agsi∆

2t ,

vfinali = vgsi + agsi∆t,

where vgsi is the initial velocity and vfinali is the final velocity. In section 6, thesefunctions are given longer, textual names: gsOut(i) and gsIn(i):

gsOut(i) = vgsi ,

gsIn(i) = vfinali−1.

The plan is continuous at index point i if gsOut(i) = gsIn(i).

5.4.2 Determining Distance From a Time Within a Segment

With the ground speed at the start of the segment (see Section 5.4.1), we can definethe path distance d within segment i relative to si as follows

di(t) = vgsi · (t− ti) +1

2agsi · (t− ti)

2, (5)

where vgsi is defined by equation 4. This relative path distance in a segment canbe used to find the final position by moving this distance from si. If time t is notwithin a ground speed acceleration zone, then agsi = 0.

5.4.3 Advancing a Specified Distance Within a Segment

Finding a point within a straight segment by a specified distance is essentially aninterpolation function. In the Euclidean case, linear interpolation accomplishes thetask. In the geodesic case, there are great circle functions that interpolate betweenpoints on a great circle arc. The challenge is to define a function to find a pointfrom a distance in a turn. Consider the turn segment shown in Figure 7. Here thedistance di(t) is the relative path distance, defined by equation 5, from the startof segment i to the point at time t. The angle α is simply di(t)/R

′ and hence thedirection from the center is easily determined. If one then calculates the point thatis R units away from the center in the direction determined by α, then the final pointis obtained. We note that the radius used in the angle calculation is the chordalradius R′, while the distance from the center calculation uses the surface radius, R.See section 6.6.2 for details about this turnByDist method.

5.5 Velocity at a Time

Next, we turn to defining velocity as a function of time. Clearly it should be equal tothe time-derivative at time t. However, we do not calculate it as a formal derivative.Instead we calculate the velocity components separately. That is, we calculate thetrack, ground speed, and vertical speed at point t.

18

di(t)

center

α

s i

ts i+1

R

R

Figure 7: Advancement Within a Turn Segment.

The ground speed at t is derived from the kinematic function for velocity witha constant acceleration. Since we have the ground speed at the start of segment i(see section 5.4.1) the ground speed at time t is defined as:

gsi(t) = vgsi + agsi · (t− ti),

where vgsi is defined by equation 4. Recall that vgsi is based on the current segmentnumber, i, and it is assumed that ti ≤ t < ti+1.

The track at time t is computed differently for the two cases. In straight seg-ments, the final track is defined by the track angle when si is moved linearly bypath distance d. In turn segments, the track angle is defined by the perpendicularto the line from the turn center to the point at t (see Figure 7).

The vertical speed at time t within segment i is given by:

vsi(t) = vvsi + avsi · (t− ti)

where

vvsi =zi+1 − zi

∆t− 1

2avsi∆t

and zi+1 and zi are the altitudes at the segment end points and ∆t = ti+1 − ti. Itis assumed that ti ≤ t < ti+1. If the segment is not a vertical speed accelerationsegment, then the vertical acceleration is zero, i.e., avsi = 0.

5.6 Vertical Component of Position

The definition of position in Section 5.4 only computes the 2D position (x and y orlatitude and longitude). The vertical component of position is computed separatelyfrom the 2D position and then the components are integrated together. Since thevertical component is independent of the horizontal components, the function toperform the vertical calculations can be a linear interpolation. Given a time t

19

within a segment i (i.e., ti ≤ t < ti+1), the altitude at this time is

zi(t) = zi + vvsi · (t− ti) +1

2avsi · (t− ti)2,

where avsi is the vertical acceleration.

5.7 Summary of Calculation Steps

The approach for finding the position and velocity at time t can be summarized asfollows, given a time t:

• find the segment number which contains time t;

• calculate the ground speed at the beginning of the segment and determine thevalue of the ground speed acceleration of this segment (possibly 0);

• using the ground speed data, determine the distance that will be traveled fromthe starting location of the segment;

• advance this distance into the segment to obtain the horizontal 2D position(the two cases are: (1) straight path and (2) circular path);

• calculate the altitude and vertical speed; and

• combine the horizontal and vertical components of position.

6 Operational Semantics

Section 5 provides a high-level, conceptual overview of how position and velocityfunctions are defined. In this section, we provide detailed definitions of these func-tions and thus provide an operational semantics for EUTL plans. By defining thesefunctions in detail, we hope that our readers should be able to produce their ownsoftware implementation in a relatively straightforward manner.

The operational semantics of EUTL has been captured in the PVS formal spec-ification language [10, 11]. We are also in the process of verifying our Java andC++ versions of EUTL against this formal specification using the model animationtechnique [26].

6.1 Notation

The basic syntax for expression definition is typical of functional programming lan-guages and is as follows:

LET

<id_1> = <expression_1>

<id_2> = <expression_2>

.

20

.

.

<id_n> = <expression_n>

IN

<expression>

The <expression> after the keyword IN defines the body of the function. It must bea function of previously defined functions and local values <id_X> that are definedbetween the relevant keywords LET and IN. The following illustrates how this is usedto define a function:

circumference(radius): real =

LET

pi = 3.14159

IN

2.0*pi*radius

In this case the definition of the function circumference(radius) =2.0*3.14159*radius. Additionally, a function may return a tuple value consistingof more than one element:

f(r: real): [real,real] =

LET

a = 100

b = 200

IN

(5*a*r, b*r*r)

Subvalues of a tuple are extracted by implicit functions referring to their positionin the tuple. In this case the value of f(10).first = 5 · 100 · 10 = 5000 andf(1).second = 200 · 1 · 1 = 200.

6.2 Summary of Utility Functions

The algorithms in Chapter 6 depend upon several utility functions whose meaningis straightforward, so only a short description is presented in this section. Morecomplete definitions are given in Appendix A or B.

The set of utility methods in Table 1 retrieve information out of the Plan datastructures.

The set of utility methods in Table 2 check if a point is of a particular TCPtype.

The methods of Table 3 are those that search a plan for points of a particulartype.

The final section of utility functions (Table 4) relate a particular time to thecorresponding segment. All such functions return a negative value if no such segmentexists within the given plan.

21

time(p: Plan, i: int) : real Time of point ipoint(p: Plan, i:int) : NavPoint NavPoint at the given indexsignedRadius(p: Plan, i: int): real Chordal radius of turn, sign

indicates turn directionturnCenter(p: Plan, i: int): Position Center of turn at point igsAccel(p: Plan, i: int): real Ground speed accelerationvsAccel(p: Plan, i: int): real Vertical speed accelerationisLatLon(p: Plan): bool True iff plan is a geodesic plansize(p: Plan): int Number of points in the plan

Table 1: Basic Plan Functions.

isTrkTCP(p:Plan,i:int):bool Is this point a turn change point?isBOT(p:Plan,i:int):bool Is this point a beginning of turn?isEOT(p:Plan,i:int):bool Is this point an ending of turn?isGsTCP(p:Plan,i:int):bool Is this a ground speed change point?isBGS(p:Plan,i:int):bool Is this a beginning of ground speed change pt?isEGS(p:Plan,i:int):bool Is this an ending ground speed change point?isVsTCP(p:Plan,i:int):bool Is this a vertical speed change point?isBVS(p:Plan,i:int):bool Is this a beginning vertical speed change point?isEVS(p:Plan,i:int):bool Is this an ending vertical speed change point?

Table 2: Determining Point Type.

prevBOT(p: Plan, i: int): int Previous BOT strictly before point iprevBGS(p: Plan, i: int): int Previous BGS strictly before point iprevBVS(p: Plan, i: int): int Previous BVS strictly before point i

Table 3: TCP Navigation Functions.

getSegment(p:Plan,t:real):int Return the segment # that contains tinTrkChange(p:Plan,double t):bool True iff time t falls within a BOT-EOTinGsChange(p:Plan,double t):bool True iff time t falls within a BGS-EGSinVsChange(p:Plan,double t):bool True iff time t falls within a BVS-EVS

Table 4: Basic Plan Functions.

22

We note that our algorithms operate on plans defined with either Euclidean orgeodesic coordinates. Although this complicates the implementation of our positionand velocity functions, the resulting flexibility for higher level algorithms more thancompensates for this complexity.

6.3 Calculating Path Distance

Based on the discussion in Section 5.3, there are two cases that must be covered todefine the horizontal path distance, denoted di, between index points: straight pathand circular turn.

6.3.1 Straight Path

The Euclidean distance is given by

pathDistance(i) = ||si+1 − si||.

The geodesic distance is given by

pathDistance(i) = GreatCircle.distance(si, si+1).

The great circle functions are defined in Appendix B. The combined function is:

distanceH(p1: Position, p2: Position): nnreal =

IF isLatLon(p1) THEN

GreatCircle.distance(lla(p1),lla(p2))

ELSE

norm(vect2(p1) - vect2(p2))

ENDIF

6.3.2 Circular Turn

We seek to calculate the horizontal path distance di of the segment shown in Figure4. The path distance is given by:

di = pathDistance(i) = θR′,

where R′ is the chordal radius and θ = angle_between(si, center, si+1) is definedby:

angle_between(p1: Position, p2: Position, p3: Position): real =

IF isLatLon(p1) THEN

GreatCircle.angle_between(lla(p1), lla(p2), lla(p3))

ELSE

LET A = p2.vect2() - p1.vect2()

B = p2.vect2() - p3.vect2()

IN

acos((A*B)/(norm(A)*norm(B)))

ENDIF

23

We note that the geodesic case is handled using the GreatCircle functionangle_between defined in Appendix B.

6.3.3 Combined Function

The function that combines the linear and circular cases is

pathDistance(p: Plan, i:int, linear: bool): real =

IF i < 0 OR i+1 >= size(p) THEN 0

ELSE

IF NOT linear AND inTrkChange(p, time(p,i)) THEN

LET

ixBOT = prevBOT(p, i+1)

center = turnCenter(p, ixBOT)

R’ = signedRadius(p,ixBOT)

theta = angle_between(point(p,i), center, point(p,i+1))

IN

abs(theta * R’)

ELSE

distanceH(point(p,i), point(p,i+1))

ENDIF

ENDIF

The function inTrkChange determines whether this segment is within a turn. SeeAppendix A for its definition. The chordal radius is retrieved using thesignedRadius function.

6.4 Ground Speed Within a Segment

In Section 5.4.1, equation 4, we developed the semantics of ground speed at anindex point. In a full algorithm we must deal with a few technicalities. First, ifi is the last point in a plan, we assume that the future velocity vector is equal tothe previous ground speed in, that is, gsIn(i). Also, an algorithmic implementationmust determine whether the segment is in a ground speed acceleration zone or not(i.e., between a BGS-EGS pair). If the segment is in such a zone, then the accelerationmust be recovered from an earlier BGS point. More complete versions of gsFinaland gsOut are:

gsFinal(p: Plan, i:int, linear: bool): real =

IF i < 0 OR i > size(p)-1 THEN -1

ELSE

LET

dist = pathDistance(p, i, i+1, linear)

dt = time(p,i+1) - time(p,i)

24

a = IF inGsChange(p, time(p,i)) AND NOT linear THEN

gsAccel(p,prevBGS(p,i+1))

ELSE

0.0

ENDIF

IN

dist / dt + 0.5 * a * dt

ENDIF

gsOut(p: Plan, i:int, linear: bool): real =

IF i < 0 OR i > size(p)-1 THEN -1

ELSIF i = size(p) - 1 THEN

gsIn(p, i)

ELSE

LET dist = pathDistance(p, i, i+1, linear)

dt = time(p, i+1) - time(p, i)

a = IF inGsChange(p, time(p, i)) AND NOT linear THEN

gsAccel(p, prevBGS(p,i+1))

ELSE

0

ENDIF

IN

dist / dt - 0.5 * a * dt

ENDIF

We note that numerical inaccuracies may lead to small negative ground speedswhen implementing this function in floating point arithmetic. It may be necessaryto guard against these undesirable return values. For convenience we define GsIn asfollows:

gsIn(p: Plan, i:int, linear: bool): real =

Gsfinal(p,i-1,linear);

6.5 Determining Distance From a Time in a Segment

Based on the discussion in Section 5.4.2, our approach to finding distance within asegment is based upon using path distance within a trajectory. Since we ultimatelywant to find the position and velocity in a plan at a specific time, we need to findthe distance from the start of a segment to that time point. This is accomplishedwith the distFromPointToTime function:

distFromPointToTime(p: Plan, seg: int, t: real, linear: bool):real=

LET gs0 = gsOut(p, seg, linear)

dt = t - time(p, seg)

IN

25

IF inGsChange(p, t) AND NOT linear THEN

LET a = gsAccel(p,prevBGS(p, seg + 1)) IN

gs0 * dt + 0.5 * a * dt * dt

ELSE

gs0 * dt

ENDIF

6.6 Advancing a Calculated Distance Within a Segment

To find a new point d distance from a given point, and based on the discussion inSection 5.4.3, there are two cases that must be covered: the segment is linear, andthe segment is a turn.

6.6.1 Straight Linear Segment

linearDist2D(so: Position, track:real, d: real, gsAt_d: real):

[Position,Velocity] =

IF isLatLon(so) THEN

LET sEnd = GreatCircle.linear_initial(so, track, d)

finalTrk = IF d > minDist THEN

GreatCircle.final_course(so, sEnd)

ELSE

track

ENDIF

vEnd = Velocity.mkTrkGsVs(finalTrk, gsAt_d, 0.0)

IN

(newPositionLLA(sEnd),vEnd)

ELSE

LET sNew = linearByDist2D(so,track,d)

vNew = Velocity.mkTrkGsVs(track,gsAt_d,0.0)

IN

(newPositionXYZ(sNew),vNew)

ENDIF

We note that for small distances d, the GreatCircle computations may produceinaccurate results. We have left out the details of how this is compensated for in theJava and C++ implementations. We also note that the 2D in the name indicatesthat altitude and vertical speed are not computed by this function. These valuesare computed by the interpolateAltVs function. The function linearByDist2D

is defined as follows

linearByDist2D(s : Vect3, track: real, d : real) : Vect3 =

(sx + d · sin(track), sy + d · cos(track), sz).

It calculates the 2D position after moving distance d units in the direction track

and the altitude is not calculated.

26

6.6.2 Turn Segment

The parameters to the turn are:

• so: the position at the start of the turn (i.e., the BOT);

• center: the center of the turn stored in the BOT point;

• dir: the direction of the turn; and

• gsAtd: the ground speed at the end of the turn.

The last parameter gsAtd is passed in as a parameter because it usually has alreadybeen computed and this prevents a redundant calculation. The geodesic turn bypath distance function is:

turnByDist2D(so, center: Position, dir:int, d: real, gsAtd: real):

[Position,Velocity] =

LET R = GreatCircle.distance(so, center)

R’ = GreatCircle.to_chordal_radius(R)

alpha = dir*d/R’

trkFromCenter = GreatCircle.initial_course(center,so)

nTrk = trkFromCenter + alpha

sn = LatLonAlt.mkAlt(GreatCircle.linear_initial(center,

nTrk,R),0)

final_course = GreatCircle.final_course(center,sn)

finalTrk = final_course + dir*PI/2

vn = Velocity.mkTrkGsVs(finalTrk,gsAtd,0.0)

IN

(sn,vn)

It returns a pair containing the final position and velocity. We note that the conver-sion of the radius to a chordal radius is optional, unless high accuracy is necessary.The Euclidean function is:

turnByDist2D(so, center: Vect3, dir: int, d: real, gsAtd: real):

[Vect3, Velocity] =

LET R = distanceH(so, center) IN

IF R = 0 THEN (so, INVALID)

ELSE

LET alpha = dir*d/R

trkFromCenter = track(center, so)

nTrk = trkFromCenter + alpha

sn = mkZ(linearByDist(center, nTrk, R), 0.0)

finalTrk = nTrk + dir*PI/2

vn = Velocity.mkTrkGsVs(finalTrk,gsAtd, 0.0)

IN

27

(sn,vn)

ENDIF

The function track(center, so) returns the track angle from point center toso. The function LatLonAlt.mkAlt(lla,z) returns a geodesic coordinate withlatitude and longitude the same as in lla, but with altitude z. The function mkZ

performs the same operation on a Euclidean coordinate frame.

6.7 Full Position and Velocity Function

positionVelocity(p: Plan, t: real, linear: bool):

[Position, Velocity] =

IF (t < time(p,0)) THEN (INVALID, Velocity.ZEROV)

ELSE

LET seg = getSegment(p,t)

np1 = point(p,seg)

IN

IF (seg + 1 > size(p) - 1) THEN

LET v = finalVelocity(p, seg - 1) IN

(np1, v)

ELSE

LET gs0 = gsOut(p,seg, linear)

gsAt_d = gsAtTime(p, seg, gs0, t, linear)

adv = posVelWithinSeg(p, seg, t, linear, gsAt_d)

altPair = interpolateAltVs(p,seg,t-time(p,seg),linear)

sNew = mkAlt(adv.first, altPair.first)

vNew = Velocity.mkVs(adv.second, altPair.secong)

IN

(sNew, vNew)

ENDIF

ENDIF

This key function relies on two subfunctions: posVelWithinSeg and interpolateAltVs

described below. The function Velocity.mkVs(v,z) returns a velocity with thesame horizontal information as v, but with vertical speed z.

6.8 The posVelWithinSeg Function

The function posVelWithinSeg determines if the horizontal motion is linear or aturn and then calculates the appropriate new 2D position:

posVelWithinSeg(p: Plan, seg:int, t:real, linear:bool, gsAt_d: real):

[Position, Velocity] =

LET np1 = point(p,seg)

so = position(np1)

IN

28

IF NOT linear AND inTrkChange(p,t) THEN

LET ixPrevBOT = prevBOT(p, seg + 1)

center = turnCenter(p, ixPrevBOT)

dir = turnDir(p, ixPrevBOT)

distFromSo = distFromPointToTime(p, seg, t, linear)

IN

turnByDist2D(so, center, dir, distFromSo, gsAt_d)

ELSE

LET np2 = point(p, seg+1)

vo = initialVelocity(np1,np2)

distFromSo = distFromPointToTime(p, seg, t, linear)

IN

linearDist2D(so, trk(vo), distFromSo, gsAt_d)

ENDIF

6.9 The initialVelocity Function

The initialVelocity function calculates the initial velocity between two NavPoints

initialVelocity(s1: NavPoint, s2: NavPoint): Velocity =

LET pp = position(s1)

tt = time(s1)

dt = time(s2) - tt

IN

IF dt = 0 THEN

zero

ELSIF dt > 0 THEN

IF isLatLon(s1) THEN

GreatCircle.velocity_initial(s1, s2, dt)

ELSE

(1/dt)*(s2 - s1)

ENDIF

ELSE

IF isLatLon(s1) THEN

GreatCircle.velocity_initial(s2, s1, -dt)

ELSE

(-1/dt)*(s1 - s2)

ENDIF

ENDIF

6.10 The interpolateAltVs Function

The interpolateAltVs function makes the vertical calculations of altitude andvertical speed:

29

interpolateAltVs(p: Plan, seg: int, dt: real, linear: bool):

[real,real] =

LET tSeg = time(p,seg)

vsAccel_d = IF ( NOT linear AND inVsChange(p, tSeg)) THEN

vsAccel(p, prevBVS(p, seg+1))

ELSE

0.0

ENDIF

alt1 = alt(point(p,seg))

vsInit = vsOut(p,seg,linear)

newAlt = alt1 + vsInit*dt + 0.5 * vsAccel_d*dt*dt

newVs = vsInit + vsAccel_d*dt

IN

(newAlt,newVs)

6.11 Consistent Plans, Revisited

Consistent plans must first be well-formed. Furthermore, all TCP begin and endlocations must be consistent with the acceleration values in order for a plan tobe usable. When the calculations are done using floating point arithmetic, theagreement will not be perfect. Therefore, approximate agreement within boundsis used. This section provides a formal description of plan consistency that wasintroduced in Section 3.3. To allow for floating point implementations, the functionsin this section contain a tolerance parameter distH_Epsilon that specifies howaccurate the calculated positions must be.

6.11.1 Track TCP Constraints

The function isTurnConsistent is applied to a BOT to test whether all the pointsin the turn (until the EOT) are the proper distance from the center of turn. Recallthat the radius of the turn represents the surface distance from the center of theturn to the BOT, or the curved distance over the earth. The mathematical definitionof isTurnConsistent, split over two functions, is:

isTurnConsistent(p:Plan, i:int, distH_Epsilon: double): bool =

IF p.isBOT(i) THEN

LET

center = p.turnCenter(i)

radius = p.getTcpData(i).turnRadius()

IN

isTurnConsistentRec(p,i,distH_Epsilon,radius,center)

ELSE false

ENDIF

30

isTurnConsistentRec(p:Plan, i:int, distH_Epsilon: double,

radius: double, center: Position): bool =

LET

dist = p.point(i).position().distanceH(center)

rtn = abs(dist - radius) > distH_Epsilon

IN

IF i >= p.size() THEN false

ELSIF p.isEOT(i) THEN rtn

ELSE rtn AND

isTurnConsistentRec(p,i+1,distH_Epsilon,radius,center)

ENDIF

6.11.2 Ground Speed TCP Constraints

The function isGsConsistent is applied to a BGS to test whether the ground speedacceleration into the next EGS is properly defined. Its mathematical definition is:

isGsConsistent(p: Plan, ixBGS: int, distEpsilon: double): bool =

IF p.isBGS(ixBGS) THEN

LET BGS = p.point(ixBGS)

ixEGS = p.nextEGS(ixBGS)

EGS = p.point(ixEGS)

gsOutBGS = p.gsOut(ixBGS)

dt = time(EGS) - time(BGS)

a BGS = p.gsAccel(ixBGS)

ds = gsOutBGS*dt + 0.5*a_BGS*dt*dt

distH = p.pathDistance(ixBGS,ixEGS)

absDiff = abs(ds-distH)

IN

absDiff < distEpsilon

ELSE

true

ENDIF

6.11.3 Vertical Speed TCP Constraints

The function isVsConsistent is applied to a BVS to test whether the ground speedacceleration into the next EVS is properly defined. Its mathematical definition is:

isVsConsistent(p: Plan, ixBVS: int, distEpsilon: double): bool =

IF p.isBVS(ixBVS) THEN

LET

ixEVS = p.nextEVS(ixBVS)

VSCBegin = p.point(ixBVS)

VSCEnd = p.point(ixEVS)

a = p.vsAccel(ixBVS)

31

dt = time(VSCEnd) - time(VSCBegin)

ds = p.vsOut(ixBVS)*dt + 0.5*a*dt*dt

deltaAlts = VSCEnd.alt - VSCBegin.alt()

absDiff = abs(ds-deltaAlts)

IN

absDiff <= distEpsilon

ELSE

true

ENDIF

6.12 Velocity-Continuous Plans, Revisited

We define the function isVelocityContinuous:

isVelocityContinuous(p: Plan, i:int): bool =

trkIn(p,i) = trkOut(p,i)

AND gsIn(p,i) = gsOut(p,i)

AND vsIn(p,i) = vsOut(p,i)

which checks for continuity at index i. This function depends upon the followingsubfunctions which have not been defined yet:

trkInTurn(p: Plan, pos:Position, center: Position, dir:int): real =

IF isLatLon(pos) THEN

LET final_course = GreatCircle.final_course(center,pos) IN

final_course + dir*PI/2

ELSE

LET trkFromCenter = track(center, pos)

nTrk = trkFromCenter

IN

nTrk + dir*PI/2

ENDIF

track(p1:Vect3, p2:Vect3): real =

atan2(p2.x-p1.x, p2.y-p1.y)

trkFinal(p: Plan, seg: int, linear: bool): real =

IF seg < 0 OR seg >= size(p) - 1 THEN -1

ELSE

IF inTrkChange(p, time(p,seg)) AND NOT linear THEN

LET ixBOT = prevBOT(p,seg+1)

dir = turnDir(p,ixBOT)

center = turnCenter(p, ixBOT)

IN

trkInTurn(p, point(p,seg+1), center, dir)

ELSE

32

IF isLatLon(p) THEN

GreatCircle.final_course(point(p, seg), point(p,seg+1))

ELSE

trk(finalVelocity(point(p, seg), point(p, seg+1)))

ENDIF

ENDIF

ENDIF

trkOut(p: Plan, seg:int, linear: bool): real =

IF (seg = size(p) - 1) THEN

trkFinal(p, seg-1, linear)

ELSE

IF inTrkChange(p, time(p,seg)) AND NOT linear THEN

LET ixBOT = prevBOT(p, seg + 1)

center = turnCenter(p, ixBOT)

dir = turnDir(p, ixBOT)

IN

trkInTurn(p, point(p, seg), center, dir)

ELSE

IF isLatLon(p) THEN

GreatCircle.initial_course(point(p,seg),point(p,seg+1))

ELSE

trk(initialVelocity(point(p, seg), point(p, seg+1))

ENDIF

ENDIF

ENDIF

trkIn(p: Plan, seg:int): real =

trkFinal(p,seg-1,false);

trkOut(p: Plan, seg:int): real =

trkOut(p,seg,false);

vsFinal(p: Plan, i: int, linear: bool): real =

IF i < 0 OR i > size(p) - 1 THEN -1

ELSE

LET

dist = alt(point(p,i+1)) - alt(point(p,i))

dt = time(p, i+1) - time(p, i)

a = IF inVsChange(p, time(p,i)) AND NOT linear THEN

vsAccel(p, prevBVS(p, i + 1))

ELSE

0.0

ENDIF

33

IN

dist / dt + 0.5 * a * dt

ENDIF

vsFinal(p: Plan, i: int): real = vsFinal(p,i,false)

vsOut(p: Plan, i: int, linear: bool): real =

IF i < 0 OR i >= size(p) - 1 THEN -1

ELSIF i = size(p) - 1 THEN

vsFinal(p, i - 1)

ELSE

LET

dist = alt(point(p,i+1)) - alt(point(p,i))

dt = time(p, i+1) - time(p, i)

a = IF inVsChange(p, time(p, i)) AND NOT linear THEN

vsAccel(p, prevBVS(p,i + 1))

ELSE

0

ENDIF

IN

dist / dt - 0.5 * a * dt

ENDIF

vsIn(p: Plan, i: int): real =

vsFinal(p,i-1,false)

vsOut(p: Plan, i: int): real =

vsOut(p,i,false)

7 TCP Generation

The plan data structure efficiently stores the information needed to retrieve theposition and velocity of a trajectory at any time point t. We have described thisfunctionality in detail. However, we have not yet explained how one creates a well-defined consistent trajectory. A linear trajectory is easy to construct; however, aconsistent and velocity-continuous kinematic plan with multiple TCP regions (pos-sibly overlapping) can be challenging. We have developed two major algorithms fordoing this:

• TrajGen.makeKinematicPlan

• Distplan.makePlan

We note that these algorithms are not used in the operational semantics of theEUTL language. These algorithms produce EUTL trajectories as an output. As

34

these algorithms are outside the scope of this paper, they are only broadly describedhere.

7.1 TrajGen.makeKinematicPlan

The makeKinematicPlan algorithm accepts a linear plan as input and creates aconsistent and velocity-continuous plan from it. This trajectory generator is a low-fidelity generator and does not use aircraft performance data or wind data as input.This is a multi-pass algorithm that first marks significant vertical speed changepoints. It then generates circular turns between non-collinear segments. It nextcalculates areas of horizontal acceleration between segments with different velocities.Because changing ground speed can also alter the vertical profile, it then correctsthe vertical profile to have a similar behavior to the original based on the previouslymarked points. It finally calculates vertical acceleration zones. More details on howthis is achieved can be found in [9].

Consider the horizontal view of a linear plan show in Figure 8.

-72.58 -72.56 -72.54 -72.52 -72.5 -72.48 -72.46 -72.44

Longitude [deg]

41.64

41.65

41.66

41.67

41.68

41.69

41.7

Latit

ude

[deg

]

245 kts

274 kts

Figure 8: Horizontal View of Linear Plan.

Point Latitude (◦) Longitude (◦) Altitude (ft) Time (s)

1 41.690007 -72.573280 5000.0 36130.02 41.641105 -72.547418 6000.0 36176.33 41.678012 -72.441028 6000.0 36245.4

Table 5: Linear Plan Input

This linear plan was generated by the input from Table 5. In this case thegeneration used default acceleration values of 4 m/s horizontal and 2 m/s vertical.The bank angle used to calculate turns was 25 degrees.

35

-72.58 -72.56 -72.54 -72.52 -72.5 -72.48 -72.46 -72.44

Longitude [deg]

41.65

41.655

41.66

41.665

41.67

41.675

41.68

41.685

41.69

41.695

Latit

ude

[deg

] 245 kts

245 kts

245 kts 245 kts 245 kts260 kts

274 kts

START,ENDBOT,EOTBVS,EVSBGS,EGS

Figure 9: Horizontal View of Generated Plan.

The horizontal profile of the generated kinematic plan is show in Figure 9. Theyellow waypoints are the BOT and EOT TCPs. The magenta waypoints are theBGS and EGS TCPs. The red waypoints are the BVS and EVS TCPs. The vertexpoint of the turn has been replaced with a turn section. In this figure, the groundspeed change that occurs at the vertex in the linear plan has been deferred untilafter the completion of the turn. This makes the maneuver a constant bank-angleturn, which may be easier to fly. Alternatively, the generator can make the groundspeed change occur at the mid point of the turn. Note that there are red verticalTCPs within the turn and that the speed values displayed are average speeds ineach segment. The vertical profile of this kinematic plan is show in Figure 10.

3.612 3.614 3.616 3.618 3.62 3.622 3.624

Time [sec] 104

5000

5200

5400

5600

5800

6000

Alti

tude

[ft]

START,ENDBOT,EOTBVS,EVSBGS,EGS

Figure 10: Vertical View of Generated Plan.

36

7.2 DistPlan.makePlan

The TrajGen algorithm is a means of transforming a linear plan into a kinematicplan. In it, speeds are inferred from point times and acceleration values are user-specified. The DistPlan utility synthesizes a kinematic plan from a 2D profile (adistance-indexed speed profile and a distance-indexed altitude profile) using a multi-pass process. With the DistPlan utility, speeds and distances are specified andspeed changes are assumed to be gradual; acceleration values and times are inferred.It is intended to facilitate incorporating non-constant wind data and higher fidelityaircraft dynamic models, allowing these to be abstracted into kinematic plans, suchas presented in Section 8.

More formally, the function DistPlan.makePlan receives three inputs and pro-duces a consistent and velocity-continuous, kinematic plan from them as output.The three inputs are:

• a list of 2D waypoints with radius information (i.e., a route);

• ground speeds as a function of path distance; and

• altitudes as a function of path distance.

The speed profile indicates the boundaries of acceleration zones.The route is transformed into a kinematic plan that describes all turns and

horizontal segments using the standard turn generation algorithm and a defaultground speed. This plan (Plan 1) defines the turns and distances for the finalkinematic plan. This allows us to directly map speed and altitude data to it usingpath distance as a reference.

Each point in the ground speed profile indicates the desired speed at that pathdistance in the route, and it is assumed that between points there is a constant(possibly zero) acceleration. It is required that the first point, at distance 0, isalways assigned an initial speed.

The ground speed profile may be divided into 3 sections representing take-off/climb, cruise, and descent/landing. If this is so, then the various sections arecombined into a single unified profile before it is processed. If the distances areconsistent with the total distance defined by Plan 1 and the sections do not overlap,they are simply concatenated into a single list, indexed from the start of the plan.8

If there is some overlap, then the cruise section is truncated or expanded to allowthe climb and descent portions to fit within Plan 1 exactly.

Vertical profile points are considered “fixed altitude” points, with vertical speedsinferred between them. For greater accuracy, additional points may be included tobetter describe an actual climb or descent profile. Similar to the speed profile, it isassumed that the first point will have a specified altitude.

If the vertical profile is provided in three parts, it is processed in a similar wayto the three-part ground speed profile, though altitudes are indexed against pathdistance. Any major mismatch in altitude between sections is registered as an error.

8For ease of computation, the climb and cruise sections are indexed from the start of the trajec-tory, while the descent portion is initially calculated backwards from the end of the trajectory.

37

During processing, ground speeds are not calculated using the normal trajectorygeneration algorithm. Instead, the unified ground speed profile is applied to Plan1. At each distance a new, marked point is added (if necessary), and the speed ofeach section between marked points is modified to match the profile’s speeds. Thisresults in a Plan 2, with regions of constant speed.

Plan 2 is scanned, searching for speed-marked points. At each of these points,the previous segment speed is compared to the next segment speed. If there is adiscontinuity, then the segments between the previous two speed-marked points isinterpreted as a non-zero acceleration zone and its start and end are marked asBGS and/or EGS, and an appropriate acceleration value is calculated. If there isno change, then the region simply retains the previously defined constant groundspeed. When complete, each segment will have been assigned a constant groundspeed acceleration, possibly zero. This results in a new Plan 3.

Next, the vertical profile is applied. All points in the vertical profile are addedto Plan 3 as “fixed altitude” points. This results in Plan 4. Finally the normalvertical TCP generation algorithm is applied to Plan 4, resulting in the output of afinal consistent kinematic plan.

8 Generation of Medium Fidelity Trajectories

In this section we describe the use of the EUTL within a low- to medium-fidelitytrajectory generator. The purpose of this trajectory generator is to generate rea-sonable, consistent and velocity-continuous trajectories for commercial aircraft giventhe flight plan information, the filed cruise true airspeed (TAS) and cruise altitude,and an aircraft performance model. The trajectory generator uses the DistPlan

utility described in Section 7.2 . These trajectories have been used within theTBO Toolkit for Integrated Air/Ground Research (TBO-TIGAR), which is a toolintended for early-stage TBO concept exploration. We illustrate the trajectory gen-erator using the following flight:

Call Sign: NASA001

Aircraft Type: B712 (Boeing 717)

Flight Plan: KBWI.TERPZ.WONCE.JIMME.ADDEK.HAFNR.GVE.LYH.KELLS

.MAYOS.MAJIC.SUDSY.GIZMO.AMOBE.INNOR.JATAB.KCLT

Cruise TAS: 455 kts

Cruise Altitude: 34000 ft (FL340)

The flight plan defines the origin airport (KBWI), the destination airport (KCLT),and the waypoints that must be sequenced between them. The cruise altitudeand cruise speed provide the target states for the cruise portion of the flight butthe trajectory generator still needs to compute the full vertical speed and altitudeprofiles for this flight. To do so, we make assumptions about how the aircraftwill execute the vertical profile, primarily in terms of indicated airspeeds (IAS)within certain altitude regions. Using a performance model for the B712 aircrafttype, a standard atmosphere table, the nominal range for this flight, and the speed

38

constraints below 10,000 feet, we end up with the climb, cruise, and descent speedprofile in Table 6, in terms of calibrated airspeed (CAS)9 or Mach number.

Table 6: Calibrated/Mach Speed Profile Versus Altitude.

Phase Starting Altitude (ft) Ending Altitude (ft) Target CAS (kts/Mach)

Climb 0.0 10000.0 250.0Climb 10000.0 30160.6 270.0Climb 30160.6 34000.0 0.72Cruise 34000.0 34000.0 0.786

Descent 34000.0 33221.1 0.74Descent 33221.1 10000.0 260.0Descent 10000.0 0.0 250.0

The speed profile shown in Table 6 provides the calibrated airspeed targets withinan altitude region for this flight. These speeds are useful for describing the profilefrom the aircraft operational point-of-view but are not sufficient for generating thefull vertical profile for this flight. Even though the calibrated speed is being heldconstant within these regions, the true airspeed is changing with altitude due tothe changing atmosphere (pressure, density and temperature). Also, as the aircraftclimbs or descends, the climb or descent rate is also variable with altitude. Addi-tionally, the effects of wind will impact the ground speed (GS) of this trajectory.Thus, the next step in this trajectory generation is to compute the vertical speedand altitude profile that takes all of these effects into account.

The calibrated airspeed profile is converted into a ground speed and altitudeprofile as a function of range. We begin with the reference linear plan generatedfrom the flight plan waypoints, as seen in Figure 1110. This reference linear plan isused as a way to query a given wind field for the magnitude and direction of thewind vector at any given location and altitude along this flight plan. The trajectorygenerator computes climb ground speed and altitude profiles in 3000 foot altitudeincrements from the departure airport until reaching the cruise airspeed and cruisealtitude using the following algorithm:

1. determine the target calibrated airspeed based on the current altitude;

2. determine the target true airspeed at the current range given the target cali-brated airspeed and the current range altitude;

3. determine the ground speed at the current range given the true airspeed andthe wind at the current range;

4. determine the climb rate for this aircraft at the current altitude from theperformance data;

9Calibrated airspeed is indicated airspeed that has been corrected for instrumentation error.10The point “$IF” is a virtual point inserted by the trajectory generator that lines up the tra-

jectory with the final approach segment.

39

5. compute the target true airspeed and target altitude at the next altitudeincrement;

6. use the current vertical rate to determine the time required to execute the stepchange in altitude;

7. use the time estimate to determine the range required to execute the stepchange in altitude;

8. update the current range, current altitude, and current true airspeed based onthe step change; and

9. repeat above steps until reaching cruise altitude and cruise airspeed.

Note that the change in indicated airspeed executed at 10,000 feet is done via a shortlevel segment. Also, after crossover altitude, the target speed becomes a constantindicated Mach instead of a constant indicated airspeed.

KCLT

$IF

KBWITERPZ

WONCE

JIMME

ADDEK

HAFNR

GVE

LYH

KELLS

MAYOS

MAJIC

SUDSY

GIZMO

AMOBEINNOR

JATAB

US Map

1dump-test-EUTL-example-linear.txt

Figure 11: Reference Linear Plan Generated from the Flightplan.

The descent profile is computed using the same algorithm as the climb profilegenerator with two exceptions. First, the descent rate is broken up into three ver-tical rate regions; vertical rates above 30,000 feet; vertical rates above 10,000 feet;and vertical rates below 10,000 feet. The vertical rates within these regions target a

40

geometric descent path of roughly 3 degrees, 2.5 degrees, and 2 degrees, respectively.Second, the descent profile is generated in reverse from the destination airport backto cruise altitude in order to properly account for the wind as a function of rangedistance from the destination11. The computed speed and altitude profiles versusrange for the example flight can be seen in Figure 12. When generating a trajec-tory in the presence of winds, the trajectory generator will also generate a groundspeed profile from the end of the climb profile to the start of the descent profile, inincrements of five nautical miles of range, to take into account the winds along theen route portion of the trajectory.

0 20 40 60 80 100 120

Range From Origin Airport [NM]

200225250275300325350375400425450475500

Spe

ed [k

ts]

Climb Speed Profile

IASTASGS

0 20 40 60 80 100 120

Range From Origin Airport [NM]

0

1

2

3

4

Alti

tude

[ft]

104 Climb Altitude Profile

-140 -120 -100 -80 -60 -40 -20 0

Range From Destination Airport [NM]

200225250275300325350375400425450475500

Spe

ed [k

ts]

Descent Speed Profile

IASTASGS

-140 -120 -100 -80 -60 -40 -20 0

Range From Destination Airport [NM]

0

1

2

3

4

Alti

tude

[ft]

104 Descent Altitude Profile

Figure 12: Speed and Altitude Profiles as a Function of Range.

The final step in trajectory generation is to use the DistPlan method describedin Section 7.2 to generate a trajectory in the EUTL Plan format. A 2D Route isgenerated using the linear flight plan and annotated with the turn radii at each

11The top of descent location or range is not known until the full descent profile has been calcu-lated, making it difficult to determine the appropriate wind information to use within the profile;this motivates the reverse computation of the descent profile.

41

waypoint, using the speed and altitude estimates at the range for those waypoints;turn radii are calculated using a default assumed bank angle (25 degrees is used inthis example). The ground speed and altitude profiles as a function of range, alongwith this 2D Route, are used to compute a kinematic plan. The final kinematictrajectory for the example flight can be seen in Figures 13 and 14.

KCLT

KBWITERPZ

WONCE

JIMME

ADDEK

HAFNR

GVE

LYH

KELLS

MAYOS

MAJICSUDSY

GIZMO

AMOBEINNOR

JATAB$IF

US Map

trajectory

TRK TCP

VS TCP

SPD TCP

Figure 13: Kinematic Trajectory Showing the TCP Points.

The resulting altitude, vertical speed, ground speed, and track angle profilesfor this example kinematic trajectory can be seen in Figures 15-18. The headwindexperienced along this plan can also be seen in Figure 19. The textual version ofthe first 17 points of the generated plan is shown in Figure 20 with time in seconds,latitude and longitude in degrees, and altitude in feet. Turn radii are in nauticalmiles and horizontal and vertical accelerations are in meters per second. The totalplan has 95 points.

In future work we hope to document the generation algorithm in more detail.We note that it is also possible to generate lower fidelity trajectories into the EUTLlanguage. The trajectory shown in Figure 21 was created by a simpler trajectorygenerator for the same route. This trajectory has half the number of points in itsPlan.

42

ADDEK

KBWITERPZ

WONCE

JIMME

US Map

trajectoryTRK TCPVS TCPSPD TCP

KCLT

AMOBE

INNOR

JATAB

$IF

US Map

trajectory

TRK TCP

VS TCP

SPD TCP

Figure 14: Kinematic Trajectory Detail for Departure (Left) and Arrival (Right).

0 500 1000 1500 2000 2500 3000 3500 4000

Time [s]

0

0.5

1

1.5

2

2.5

3

3.5

Alti

tude

[ft]

104

Figure 15: Kinematic Trajectory Altitude Profile with Time.

43

0 500 1000 1500 2000 2500 3000 3500 4000

Time [s]

-2000

-1000

0

1000

2000

3000

4000

Ver

tical

Spe

ed [f

t/min

]

Figure 16: Kinematic Trajectory Vertical Speed Profile with Time.

0 500 1000 1500 2000 2500 3000 3500 4000

Time [s]

240

260

280

300

320

340

360

380

400

420

Gro

und

Spe

ed [k

ts]

Figure 17: Kinematic Trajectory Ground Speed Profile with Time (in the Presenceof Wind).

44

0 500 1000 1500 2000 2500 3000 3500 4000

Time [s]

160

180

200

220

240

260

280

300

320

340

360

Tra

ck [d

eg]

Figure 18: Kinematic Trajectory Track Angle Profile with Time.

0 500 1000 1500 2000 2500 3000 3500 4000

Time [s]

-10

0

10

20

30

40

50

60

70

Hea

dwin

d [k

ts]

Figure 19: Headwind Along the Plan’s Altitude versus Plan Range.

45

TIME LATITUDE LONGITUDE ALTITUDE NAME TCP_DATA

------ --------------------------------- ---- --------------

0.00 (39.175361, -76.668333, 146.00) KBWI (BGS 0.097) ;

57.81 (39.187720, -76.754260, 3146.00) (EGSBGS -0.051);

119.51 (39.200960, -76.846841, 6146.00) (EGSBGS 0.084) ;

161.99 (39.210048, -76.910704, 8073.00) (EGSBGS 0.082) ;

179.09 (39.213764, -76.936894, 8812.64) TERPZ (BOT -2.152) ;

181.86 (39.214214, -76.941201, 8932.67) ;

184.63 (39.214349, -76.945543, 9052.49) (EOT) ;

199.94 (39.214216, -76.969703, 9714.78) (BVS -1.000) ;

206.53 (39.214157, -76.980177, 9928.69) (EGSBGS 0.317) ;

213.13 (39.214097, -76.990751, 10000.00) (EVS) ;

230.26 (39.213931, -77.018979, 10000.00) (BVS 1.000) ;

236.53 (39.213867, -77.029584, 10064.55) (EGSBGS 0.099) ;

242.81 (39.213801, -77.040284, 10258.22) (EVS) ;

290.62 (39.213258, -77.123337, 12226.44) WONCE (BOT -2.790) ;

307.14 (39.207625, -77.151425, 12906.38) ;

309.41 (39.206032, -77.154924, 13000.00) (EGSBGS 0.055) ;

323.51 (39.192436, -77.172812, 13534.26) (EOT) ;

388.58 (39.116075, -77.237932, 16000.00) (EGSBGS 0.056) ;

...

Figure 20: Textual Version of Generated Plan.

0 500 1000 1500 2000 2500 3000 3500

Time [sec]

0

0.5

1

1.5

2

2.5

3

3.5

Alti

tude

[ft]

104

trajectoryTRK TCPVS TCPSPD TCP

Figure 21: Vertical Profile of Low Fidelity Trajectory (Altitude versus Time).

46

9 Concluding Remarks

This paper presents a new language for specifying trajectories called the Efficient,Universal Trajectory Language (EUTL). This language is defined for ATM applica-tions where trajectories are communicated between air and ground systems. There-fore, a high priority was placed on efficiently communicating unambiguous trajectorydescriptions. The language defines a trajectory as a sequence of 3D positions andtimes where there is a constant velocity or constant acceleration between each point.The semantics of the language are given in mathematical detail so that position andvelocity are precisely defined for all time points within a plan’s starting and endingtime. The language was also defined in a manner that does not depend upon anyparticular control system or aircraft dynamics model. For this reason we considerit a universal trajectory language.

References

1. Russell A. Paielli. Trajectory specification for high-capacity air traffic control.Journal Of Aerospace Computing, Information, And Communication, 2, Sept2005.

2. Intent project: The transition towards global air and ground collaboration intraffic separation assurance. www.intentproject.org.

3. R.C.J. Ruigrok and M.S.V. Valenti Clari. The impact of aircraft intent in-formation and traffic separation assurance responsibility on en-route airspacecapacity. In 5th FAA/EUROCONTROL ATM R&D Seminar, Jun 2003.

4. Robert A Vivona, Karen T Cate, and Steven M Green. Abstraction techniquesfor capturing and comparing trajectory predictor capabilities and requirements.In AIAA Guidance, Navigation and Control Conference, Honolulu, HI, 2008.

5. Sip Swierstra and Steven Green. Common trajectory prediction capability fordecision support tools. In 5th USA/Eurocontrol ATM R&D Seminar, Budapest,Hungary, 2003.

6. Stephane Mondoloni and Daniel Kirk. Proposed trajectory prediction and ex-change information items for flight information exchange model (fixm). Techni-cal report, MITRE, 2012.

7. Bill Gill and Bob Maddock. Prediction of optimal 4D trajectories in the presenceof time and altitude constraints. Technical Report DOC 97-70-09, PHARE,European Organization For the Safety of Air Navigation, Feb 1997.

8. Ben Musialek, Carmen F. Munafo, Hollis Ryan, and Mike Paglione. Literaturesurvey of trajectory predictor technology. Technical Report DOT/FAA/TC-TN11/1, Federal Aviation Administration William J. Hughes Technical Center,2010.

47

9. George E. Hagen and Ricky W. Butler. Towards a formal semantics of flightplans and trajectories. Technical Memorandum NASA/TM2014-218662, NASA,Dec 2014.

10. S. Owre, J. Rushby, and N. Shankar. PVS: A prototype verification system. InDeepak Kapur, editor, Proc. 11th Int. Conf. on Automated Deduction, volume607 of Lecture Notes in Artificial Intelligence, pages 748–752. Springer-Verlag,June 1992.

11. N. Shankar, S. Owre, and J. M. Rushby. PVS Tutorial. Computer Science Lab-oratory, SRI International, Menlo Park, CA, February 1993. Also appears inTutorial Notes, Formal Methods Europe ’93: Industrial-Strength Formal Meth-ods, pages 357–406, Odense, Denmark, April 1993.

12. United States Air Force Chief Scientist. Technology Horizons: A vision for AirForce science and technology 2010-30. Technical Report AF/ST-TR-10-01-PR,http://www.af.mil/information/technologyhorizons.asp, May 2010.

13. George E. Hagen, Ricky W. Butler, and Jeffrey M. Maddalon. The Stratwayprogram for strategic conflict resolution: Users guide. Technical MemorandumNASA/TM2016-219196, NASA, May 2016.

14. Nelson M. Guerreiro, Ricky W. Butler, George E. Hagen, Jeffrey M. Maddalon,and Timothy A. Lewis. Parametric analysis of surveillance quality and level andquality of intent information and their impact on conflict detection performance.Technical Memorandum NASA/TM-2016-219177, NASA, March 2016.

15. Nelson M. Guerreiro, Ricky W. Butler, Jeffrey M. Maddalon, George E. Hagen,and Timothy A. Lewis. Conflict detection performance analysis for functionallocation using time-shifted recorded traffic data. In 15th AIAA Aviation Tech-nology, Integration, and Operations Conference Dallas, TX, June 22-26 2015.

16. ICAO. Global air traffic management operational concept. Technical Report9854 AN/458, International Civil Aviation Organization, 2005.

17. Samet Ayhan and Hanan Samet. Aircraft trajectory prediction made easy withpredictive analytics. In Proceedings of the 22nd ACM SIGKDD InternationalConference on Knowledge Discovery and Data Mining, August 13-17, 2016.

18. Daniel Delahaye, Stephane Puechmorel, Panagiotis Tsiotras, and Eric Feron.Mathematical models for aircraft trajectory design: A survey. Lecture notes inElectrical Engineering, 10.1007/978-4-431-54475-3:205–247, 2014. hal-00913243.

19. Guillermo Frontera, Juan A. Besada, Ana M. Bernardos, Enrique Casado, andJavier Lopez-Leones. Formal intent-based trajectory description languages.IEEE Transactions On Intelligent Transportation Systems, 15(4), Aug 2014.

48

20. Terence S. Abbott. An overview of a trajectory-based solution for en route andterminal area self-spacing: Seventh revision. Technical Report NASA/CR2015-218794, Stinger Ghaffarian Technologies, Hampton, Virginia, August 2015.

21. Randy Walter. Flight management systems. In Cary R . Spitzer, editor, DigitalAvionics Handbook, Second Edition. CRC Press, 2000.

22. RTCA SC-186. Minimum aviation system performance standards for automaticdependent surveillance broadcast (ADS-B), 2002.

23. J. Lopez-Leones, M. A. Vilaplana, E. Gallo, F. A. Navarro, and C. Querejeta.The aircraft intent description language: A key enabler for air-ground synchro-nization in trajectory-based operations. In 26th IEEE/AIAA Digit. AvionicsSystems Conference, 2007.

24. RTCA Inc. Safety and performance requirements standard for baseline 2 ATSdata communications (baseline 2 spr standard). Technical Report Volume 1,DO-350A, Washington, DC, 2016.

25. RTCA Inc. Interoperability requirements standard for baseline 2 ATS datacommunications (baseline 2 interop standard). Technical Report Volume 1 and2, DO-351A, Washington, DC, 2016.

26. Aaron Dutle, Cesar Munoz, Anthony Narkawicz, and Ricky Butler. Softwarevalidation via model animation. Lecture Notes in Computer Science, 9254:92–108, 2015.

27. Ed Williams. Aviation formulary. http://www.edwilliams.org/avform.htm. Ac-cessed, May 2, 2017.

28. United States Department of Defense. World geodetic system 1984: Its definitionand relationships with local geodetic systems, 2014. NGA.STND.0036 1.0.0 -WGS84.

49

Appendix A

Support Functions

Functions that calculate position and velocity for a specified time are presentedin Section 6. These functions provide the data structure with a tremendous amountof utility and are essential to defining the semantics of the trajectory encoded inthe plan. There are many basic utility functions that were presented but not fullyspecified.

A.1 TCP Functions

The methods of Table 2 check if a point is of a particular TCP type.

isBOT(p: Plan, i: int) : bool =

data(p,i).tcp_trk = BOT OR data(p,i).tcp_trk = EOTBOT

isEOT(p: Plan, i: int) : bool =

data(p,i).tcp_trk = EOT OR data(p,i).tcp_trk = EOTBOT

isGsTCP(p: Plan, i: int) : bool =

data(p,i).tcp_gs /= NONE

isBGS(p: Plan, i: int) : bool =

data(p,i).tcp_gs = BGS OR data(p,i).tcp_gs = EGSBGS

isEGS(p: Plan, i: int) : bool =

data(p,i).tcp_gs = EGS OR data(p,i).tcp_gs = EGSBGS

isVsTCP(p: Plan, i: int) : bool = data(p,i).tcp_vs /= NONE

isBVS(p: Plan, i: int) : bool =

data(p,i).tcp_vs = BVS OR data(p,i).tcp_vs = EVSBVS

isEVS(p: Plan, i: int) : bool =

data(p,i).tcp_vs = EVS OR data(p,i).tcp_vs = EVSBVS

The methods of Table 3 search for previous and subsequent occurrences of TCPtypes:

prevSearch(p: Plan, property:[Plan,int -> bool], i: int): int =

IF (i < 0) THEN -1

ELSE IF (p.point(i).property) THEN i

ELSE prevSearch(p,property, i-1)

ENDIF

50

prevBOT = prevSearch(p,isBOT,i-1)

prevBGS = prevSearch(p,isBGS,i-1)

prevBVS = prevSearch(p,isBVS,i-1)

A.2 The getSegment Function

Informally, getSegment is a function that, for a given plan p and time t, returns aninteger value in the range [−1, size(p)− 1]. It returns the value −1 if the time fallsoutside p’s bounds, or the index in p such that ti ≤ t < ti+1. There are many possibleimplementations for this function, e.g., linear search or binary search. Rather thanpresent a particular search method we specify the output formally. The necessaryconditions for getSegment(t):int for a given plan p are:

getSegment(p, t) < 0 ⇐⇒ t < time(p, 0) ∨ t > time(p, size(t)− 1)

getSegment(p, t) = i ⇐⇒ time(i) ≤ t ∧ t < time(i+ 1)

A.3 In Acceleration Zone Functions

The functions inTrkChange, inGsChange, and inVsChange are true if, for the givenplan p and time t within p, the segment containing time t is in an acceleration zoneof that type. This can be accomplished through the use of the prevBOT functionand a similar nextEOT function (and likewise for horizontal speed and vertical speedaccelerations). The necessary conditions for inTrkChange(p,t):bool for a givenplan p are:

inTrkChange(p, t) ⇐⇒ ∃i∃j∀k : (i ≥ 0) ∧ (j > i) ∧ (i < k) ∧ (k < j)∧isBOT(p, i) ∧ isEOT(p, j) ∧ ¬isBOT(p, k)∧getSegment(p, t) ≥ i ∧ getSegment(p, t) < j

Similarly for inGsChange(p,t):bool and inVsChange(p,t):bool:

inGsChange(p, t) ⇐⇒ ∃i∃j∀k : (i ≥ 0) ∧ (j > i) ∧ (i < k) ∧ (k < j)∧isBGS(p, i) ∧ isEGS(p, j) ∧ ¬isBGS(p, k)∧getSegment(p, t) ≥ i ∧ getSegment(p, t) < j

inVsChange(p, t) ⇐⇒ ∃i∃j∀k : (i ≥ 0) ∧ (j > i) ∧ (i < k) ∧ (k < j)∧isBVS(p, i) ∧ isEVS(p, j) ∧ ¬isBVS(p, k)∧getSegment(p, t) ≥ i ∧ getSegment(p, t) < j

51

Appendix B

Great Circle Functions

The formulae in this section are based on relatively standard developments inspherical trigonometry. Many are based on an excellent summary of key resultsespecially relevant to navigation problems presented by Williams in [27].

B.1 angular distance

The angular_distance function computes the great circle distance between thetwo points in terms of the angle at the center of the sphere. The calculation appliesto any sphere, not just a spherical Earth. This implementation uses the haversineformula.

angular_distance(lat1: real, lon1: real, lat2: real, lon2: real):

nnreal =

asin(sqrt(sq(sin((lat1 - lat2) / 2))

+ cos(lat1)*cos(lat2)* sq(sin((lon1-lon2) / 2)))) * 2.0

Using the LatLonAlt data structure we have:

angular_distance(p1: LatLonAlt, p2: LatLonAlt): nnreal =

angular_distance(lat(p1), lon(p1), lat(p2), lon(p2))

B.2 distance

Compute the great circle distance between the two geodesic points. The calculationassumes the Earth is a sphere. This algorithm ignores the altitudes.

distance(p1: LatLonAlt, p2: LatLonAlt): nnreal =

distance_from_angle(angular_distance(lat(p1),lon(p1),lat(p2),

lon(p2)),0)

distance_from_angle(angle: nnreal, h: nnreal): nnreal =

(spherical_earth_radius + h) * angle

B.3 initial course and final course

The initial true course (course relative to true north) at point p1 on the great circleroute from point p1 to point p2. The value is in internal units of angles (radians),and is a compass angle [0..2π]: clockwise from true north. If point p1 and p2 areclose to each other, then the initial course may become unstable. In the extremecase when point p1 equals point p2, then the initial course is undefined.

52

initial_course(p1: LatLonAlt, p2: LatLonAlt): real =

LET d = angular_distance(lat(p1), lon(p1), lat(p2), lon(p2)) IN

initial_course_impl(p1, p2, d);

final_course(p1: LatLonAlt, p2: LatLonAlt): real =

initial_course(p2, p1) + pi;

initial_course_impl(p1: LatLonAlt, p2: LatLonAlt): real =

LET lat1 = lat(p1)

lon1 = lon(p1)

lat2 = lat(p2)

lon2 = lon(p2)

IN

IF cos(lat1) = 0 THEN % at either pole

IF lat1 > 0 THEN

pi % north pole, all directions are south

ELSE

2.0 * pi % south pole, all directions are north

ENDIF

ELSE

to2pi(atan2(sin(lon2-lon1)*cos(lat2),

cos(lat1)*sin(lat2)

- sin(lat1)*cos(lat2)*cos(lon2-lon1)))

ENDIF

Note that in a floating-point implementation it is necessary to include a small bufferon the test if the first point is at a pole.

B.4 angle between

The angle_between function calculates the angle between two great circles thatintersect at a point b. The first great circle also goes through point a, while thesecond great circle goes through point b. Assuming b is not one of the poles, thisfunction is defined as follows:

angle_between(a:LatLonAlt, b:LatLonAlt, c:LatLonAlt): real =

LET ang1 = initial_course(b,a),

ang2 = initial_course(b,c)

IN

turnDelta(ang1,ang2);

where turnDelta calculates the difference between two angles as follows

53

turnDelta(alpha: real, beta: real): real =

LET a = to2pi(alpha)

b = to2pi(beta)

delta = abs(a-b)

IN

IF (delta<=pi) THEN delta

ELSE 2*pi-delta

ENDIF

and

to2pi(a: real) : real =

LET n = floor(a/(2*pi)) IN

a - 2*n*pi

Note that if the input location b is precisely at one of the poles, an alternate versionof the angle_between function is required:

angle_between(a:LatLonAlt, b:LatLonAlt, c:LatLonAlt): real =

LET

a1 = angular_distance(c,b)

b1 = angular_distance(a,c)

c1 = angular_distance(b,a)

d = sin(c1)*sin(a1)

IN

IF d = 0.0 THEN PI

ELSE

acos( (cos(b1)-cos(c1)*cos(a1)) / d )

ENDIF

This function is based on the spherical law of cosines. It depends upon theangular_distance function.

B.5 velocity initial

The velocity_initial function computes the initial velocity on the great circlefrom point p1 to point p2 with the given amount of time.

velocity_initial(p1:LatLonAlt, p2: LatLonAlt p2, double t):

Velocity =

LET d = angular_distance(p1, p2),

gs = distance_from_angle(d, 0.0) / t

crs = initial_course_impl(p1, p2, d)

IN

Velocity.mkTrkGsVs(crs, gs, (alt(p2) - alt(p1)) / t)

where the function Velocity.mkTrkGsVs returns a Velocity with the given track,ground speed, and vertical speed values. If points p1 and p2 are essentially the same

54

(about 1 meter apart), then a zero vector is returned. Also if the absolute value oftime is less than 1 [ms], then a zero vector is returned. These details have been leftout of the above definition.

B.6 linear initial

The linear_initial function determines a point from the given lat/lon with aninitial angle of track at a distance dist. This calculation follows the great circle.

linear_initial(s: LatLonAlt, track: real, dist: real): LatLonAlt =

linear_initial_impl(s, track, angle_from_distance(dist), 0.0)

where

linear_initial_impl(s: LatLonAlt, track: real, d: real, vert: real):

LatLonAlt =

LET cosd = cos(d)

sind = sin(d)

sinslat = sin(lat(s))

cosslat = cos(lat(s))

lat = asin(sinslat*cosd + cosslat*sind*cos(track))

dlon = atan2(sin(track)*sind*cosslat,

cosd - sinslat*sin(lat))

lon = to_pi(lon(s) + dlon)

IN

LatLonAlt.mk(lat, lon, alt(s) + vert)

The function LatLonAlt.mk is a function that returns a LatLonAlt (geodesic coor-dinate) based on latitude, longitude, and altitude values.

55

Appendix C

Chordal Radius

There are two different notions of radius that arise when dealing with geodesiccoordinates. They are:

• Surface Radius (R): the along-surface radius that is calculated using the greatcircle distance from the center of the turn to a point on the turn.

• Chordal Radius (R′): the part of a chord that is in the plane of the turn itself(which is a small circle) and hence passes through the sphere’s volume.

For small-radius turns these are approximately the same, but for very large radiusturns (on the order of hundreds of nautical miles), there can be a more noticabledifference between the two values. Here are typical differences as a function ofsurface radius R;

R [NM] R−R′ [NM]

1.00 0.000000012.00 0.000000113.00 0.000000384.00 0.000000905.00 0.000001766.00 0.000003057.00 0.000004848.00 0.000007229.00 0.0000102810.00 0.0000141050.00 0.00176281100.00 0.01410206

The chordal radius can be obtained from the surface, great-circle radius usingthe following function:

to_chordal_radius(surface_radius: real): real =

GreatCircle.chord_distance(surface_radius*2)/2

where chord_distance is defined as follows:

chord_distance(surface_dist: real): real =

LET theta = angle_from_distance(surface_dist,0.0) IN

2.0*sin(theta/2.0)*GreatCircle.spherical_earth_radius

C.1 Function chord distance

The function chord_distance returns the straight-line chord distance (through aspherical earth) from two points on the surface of the earth.

56

chord_distance(double lat1, double lon1, double lat2, double lon2):

real =

LET v1 = spherical2xyz(lat1,lon1)

v2 = spherical2xyz(lat2,lon2)

IN

|| v1 - v2 ||

where

spherical2xyz(double lat, double lon): Vect3 =

LET r = GreatCircle.spherical_earth_radius

theta = PI/2 - lat

x = r*sin(theta)*cos(lon)

y = r*sin(theta)*sin(lon)

z = r*cos(theta)

IN

(x,y,z)

and GreatCircle.spherical_earth_radius is computed as follows

spherical_earth_radius: real =

1/ (0.000539957 * pi / (180.0 * 60.0)) = 6366707.019493707 m

This definition of the radius of a spherical earth in meters assumes one nauticalmile is 1852 meters (as defined by various international committees) and that onenautical mile is equal to one minute of arc (traditional definition of a nautical mile)on the Earth’s surface. This value lies between the major and minor axis as definedby the “reference ellipsoid” in WGS84 [28].

57

Appendix D

Ground Speed vs. Airspeed

Because aircraft fly with respect to airspeed, many trajectory definitions havebeen defined with respect to airspeed. However, there is a serious problem withcommunicating trajectories based on airspeed: the future location of the aircraftrelative to the ground and most likely to other aircraft, can not be known unless onehas access to the wind field used by the creator of this trajectory.D1 Consequentlyimportant ATM functions such as conflict detection and resolution cannot be per-formed without first converting the trajectories in terms of airspeed into trajectoriesin terms of ground speed. We believe that the original creator of a trajectory shouldperform this translation rather than the recipients.

Because times are stored in the internal data structures of EUTL, it is natu-ral to focus on times rather than speeds. But, if one’s focus is changed to speedrather than time, then some additional flexibility can be obtained from the EUTLlanguage. With this focus, the trajectory defined in EUTL can be thought of asa two-dimensional path augmented by a speed profile and an altitude profile. Infact, if one suspends the idea of using time in an absolute sense, the speed profilecan be either an airspeed profile or a ground speed profile. Admittedly, this can beawkward, but with care, some useful additional capabilities can be created.

If we let Pas be a plan where the speeds are interpreted as airspeed and Pgs be aplan where the speeds are interpreted as ground speed, then the following conversioncan be accomplished.

Pas +W −→ Pgs

where W is a wind field. This conversion can be accomplished by only modifyingthe times if one makes the assumption that the wind only affects the along-trackposition of an aircraft. This is a reasonable assumption because the control systemand pilot work to maintain lateral conformance to the flight plan. We also notethat W can represent the difference between wind field used to create Pas and thewind field of the recipient Pgs. This is the approach used in the medium fidelitytrajectory generator in TBO-TIGAR, see Section 8.

D1It would, of course, be possible to transmit this data, but this could introduce a significantcommunication bandwidth cost.

58

REPORT DOCUMENTATION PAGE Form ApprovedOMB No. 0704–0188

The 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 collectionof information, including suggestions for reducing this burden, to Department of Defense, Washington Headquarters Services, Directorate for Information Operations and Reports(0704-0188), 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall besubject to any penalty for failing to comply with a collection of information if it does not display a currently valid OMB control number.PLEASE DO NOT RETURN YOUR FORM TO THE ABOVE ADDRESS.

Standard Form 298 (Rev. 8/98)Prescribed by ANSI Std. Z39.18

1. REPORT DATE (DD-MM-YYYY)01-09-2017

2. REPORT TYPE

Technical Memorandum3. DATES COVERED (From - To)

4. TITLE AND SUBTITLE

An Efficient Universal Trajectory Language

5a. CONTRACT NUMBER

5b. GRANT NUMBER

5c. PROGRAM ELEMENT NUMBER

5d. PROJECT NUMBER

5e. TASK NUMBER

5f. WORK UNIT NUMBER

6. AUTHOR(S)

George E. Hagen, Jeffrey M. Maddalon, Nelson M. Guerreiro, Ricky W.Butler,

7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)

NASA Langley Research CenterHampton, Virginia 23681-2199

8. PERFORMING ORGANIZATIONREPORT NUMBER

L–20870

9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)

National Aeronautics and Space AdministrationWashington, DC 20546-0001

10. SPONSOR/MONITOR’S ACRONYM(S)NASA

11. SPONSOR/MONITOR’S REPORTNUMBER(S)

NASA/TM-2017-21966912. DISTRIBUTION/AVAILABILITY STATEMENT

Unclassified-UnlimitedSubject Category 63Availability: NASA STI Program(757) 864-965813. SUPPLEMENTARY NOTES

14. ABSTRACT

The Efficient Universal Trajectory Language (EUTL) is a language for specifying and representing trajectories for Air Traffic Management (ATM)concepts such as Trajectory Based Operations (TBO). In these concepts, the communication of a trajectory between an aircraft and groundautomation is fundamental. Historically, this trajectory exchange has not been done, leading to trajectory definitions that have been centeredaround particular application domains and, therefore, are not well suited for TBO applications. The EUTL trajectory language has been definedin the PVS formal specification language, which provides an operational semantics for the EUTL language. The hope is that EUTL will provide afoundation for mathematically verified algorithms that manipulate trajectories. Additionally, the EUTL language provides well-defined methods tounambiguously determine position and velocity information between the reported trajectory points. In this paper, we present the EUTL trajectorylanguage in mathematical detail.

15. SUBJECT TERMS

air traffic management, trajectory, flight plan, trajectory specification, trajectory-based operations

16. SECURITY CLASSIFICATION OF:

a. REPORT

U

b. ABSTRACT

U

c. THIS PAGE

U

17. LIMITATION OFABSTRACT

UU

18. NUMBEROFPAGES

69

19a. NAME OF RESPONSIBLE PERSON

STI Help Desk (email: help@sti.nasa.gov)

19b. TELEPHONE NUMBER (Include area code)

(757) 864-9658