**Surface Management System (SMS)**

**General Description**

**January 31, 2002**

**NAS2-98005**

**Technical Research in Advanced Air Transportation Technologies**

**Final**

**General Description**

**Surface Management System (SMS)**

**CDRL Item 5e**

**Prepared under**

**RTO -- 62**

**AATT Operational Concept for ATM -- Year 2002 Update**

**January 31, 2002**

##### Prepared For: NASA Ames Research Center

##### Moffett Field, CA 94035-1000

**Prepared By: Titan Systems Corporation -- SRC Division**

**Billerica, MA 01821-4134**

![](media/image1.jpeg){width="5.416666666666667in" height="0.75in"}

**ACKNOWLEDGEMENT**

The description presented in this document is based primarily on the
information in "Concept Description and Development Plan for the Surface
Management System", Stephen Atkins of NASA Ames Research Center and
Chris Brinton of Metron, Inc., and discussions with Dr. Atkins who
helped review and improve this document.

##### PREFACE

The Surface Management System (SMS) is in the early stages of
development, and as such, there are numerous aspects of its capabilities
and functions that are not well known at this time. NASA is developing a
version of SMS, called SMS Build 1, through TRL 6. There are no specific
plans to go beyond Build 1. This description will describe Build 1, but
will contain what is known about subsequent Builds to give the reader
the benefit of NASA's long range intentions.

Build 1 will be developed in two phases. In Phase 1, two real-time,
controller-in-the-loop simulations will be conducted using the Future
Flight Central (FFC) Air Traffic Control Tower (ATCT) simulation
facility at NASA Ames Research Center. The simulations will use DFW
airport. The first simulation, held in September, 2001, evaluated the
SMS concept, displays, and algorithms. Simulation results are being used
to refine the functionality and user interface for SMS. The second
simulation, in January, 2002, will begin to study interoperation between
SMS and Traffic Management Advisor (TMA). Phase 2 will further refine
the SMS concept and implementation, culminating in an operational use
demonstration at a single field site. User feedback to guide development
cycles will be obtained through several Phase 2 evaluations. Controller
shadow-mode testing will be conducted remotely in October, 2002 and at
the field site in February, 2003. The operational demonstration is
planned for May, 2003. To gain additional experience with its
performance, SMS may be deployed first to an air carrier ramp tower in
the summer of 2002.

As work continues, additional detail will be identified; elements of the
concept may also change, especially as a result of user involvement.
Subsequent descriptions will update the concept and provide additional
details. This effort will also build the foundation for future surface
automation. This initial SMS development will not explore every
opportunity for surface management automation. Subsequent research and
development will add additional capabilities to SMS in phases. For
example, taxi route planning and runway crossing functionalities are
being considered. Furthermore, opportunities exist for automation tools
to interact with SMS to provide additional benefits. Future versions of
SMS will interoperate with Center-TRACON Automation System (CTAS): with
TMA to plan arrival/departure tradeoffs \[Atkins and Hall, 2000\], and
with Final Approach Spacing Tool (FAST) and Expedite Departure Path
(EDP) to provide tactical arrival/departure interoperability (i.e.,
coordinate how individual arrivals and departures share airport
resources).

**Table of Contents**

**1. Description 1**

**2. Operational Concept 1**

> **2.1 Departure Situation Prediction Capabilities 2**
>
> **2.2 Arrival-Departure Tradeoffs 8**
>
> **2.3 System Architecture 9**

**3. Functional Flow 11**

### List of Figures

1.  **TMA timeline display of predicted and scheduled arrival times 3**

2.  **TMA Load Graph display of aggregate demand 5**

3.  **Departure queues for PHL Runway 9L 6**

4.  **DFW departure scenario for an eastbound push during south flow
    operations 7**

5.  **SMS System Architecture 10**

6.  **SMS Functional Flow 12**

**References 13**

**General Description**

**Surface Management System (SMS)**

1.  **Description**

NASA Ames Research Center, in cooperation with the FAA, is studying
automation for aiding surface traffic management. The Surface Management
System (SMS) is a decision support tool that will help controllers and
air carriers collaboratively manage the movements of aircraft on the
surface of busy airports, thereby improving capacity, efficiency, and
flexibility. SMS will provide operational specialists at Air Traffic
Control (ATC) facilities and air carriers with accurate predictions of
the future departure situation (e.g., queuing and delays for individual
aircraft, and aggregate demand, as a function of time, for each runway
or other constrained resource), as well as advisories to help manage
surface movements and departure operations.

Initial key milestones include real-time, controller-in-the-loop
simulations using the Future Flight Central ATC tower simulation
facility at NASA Ames Research Center. Memphis International Airport is
the proposed field site for an operational demonstration in 2003.

SMS will predict departure demand over a time horizon similar to that
over which the Center-TRACON Automation System (CTAS) Traffic Management
Advisor (TMA) supports arrival management \[Erzberger et al., 1993 and
Swenson et al., 1997\], using surface surveillance, surface trajectory
synthesis algorithms that are functionally equivalent to the CTAS
airborne trajectory modeling algorithms, and air carrier predictions of
when each flight will want to push back. SMS will provide near-term
predictions of departure sequences, times, queues, and delays for
runways or other resources to support tactical control of surface
operations, and longer time-horizon forecasts of aggregate departure
demand (i.e., total demand per intervals of time) to support strategic
surface planning. Initially, SMS will display this information in the
ATC tower (ATCT) and air carrier ramp towers. In the future, SMS may
also display information in the TRACON Traffic Management Unit (TMU),
Center TMU, and Airline Operations Centers (AOCs). Displays similar to
TMA timelines and load graphs may be used, depending on the
recommendations from human factors studies.

SMS will also use its ability to predict the future state of the airport
surface to support departure management decisions. For example, SMS will
aid the ATCT in constructing departure sequences that efficiently
satisfy various departure restrictions (e.g., Miles-in-Trail (MIT) and
Expected Departure Clearance Times (EDCTs)). Subsequent development
efforts will extend SMS to interoperate with arrival and departure
traffic management decision support tools (e.g., the CTAS Final Approach
Spacing Tool (FAST), TMA, and Expedite Departure Path (EDP) tool) to
provide additional benefits (e.g., coordination of arrival/departure
interactions).

2.  **Operational Concept**

The foundation of SMS is its capability to predict how future departure
demand will play out on the surface. These predictions will be provided
as products themselves, as discussed in the next section. Furthermore,
the ability to predict how the state of the airport surface will evolve
enables SMS to evaluate the effect of various traffic management
decisions in advance of implementing them. The subsequent section
discusses the departure planning capabilities and advisories that are
being considered.

1.  **Departure Situation Prediction Capabilities**

A primary function of SMS is to create shared awareness of the current
and future departure situation among the ATCT, TRACON TMU, Center TMU,
and air carriers by providing information about expected departure
demand and how the surface situation will evolve under that demand. To
achieve this, SMS will provide information, either using dedicated SMS
displays or by adding the information onto the displays of other
systems, to the ATCT and ramp towers, as well as, possibly, the TRACON
and Center TMUs and the AOCs. Within the ATCT, SMS will provide
information to some or all of: the Local Controllers, Ground
Controllers, Clearance Delivery/Flight Data Controller, and
Supervisors/Traffic Management Coordinator (TMC).

1.  **Near-Term Departure Demand**

SMS will provide both near-term and longer-horizon predictions of the
departure situation. Near-term predictions will consist of, for example,
the expected queue lengths at each runway for the next 15 to 30 minutes,
the predicted takeoff sequence, and the resulting takeoff times and
delays for individual aircraft. To predict the state of the surface over
the next 15 to 30 minutes, depending on taxi-out times, SMS will use
real-time surface surveillance information that includes aircraft
identity, from ASDE-X or another similarly capable system, and a surface
trajectory synthesis algorithm that accurately predicts the movement of
aircraft on the airport surface. The surface trajectory synthesis
algorithm is functionally similar to that used by CTAS to predict the
trajectories of airborne aircraft. To accurately model the evolution of
the surface situation, the automation must consider how controllers
assign departure runways and taxi routes, how they sequence departures,
how they use multiple queues to feed departure runways, and how arrival
traffic affects departures. The automation must also consider
inter-departure restrictions, including downstream constraints.

Developing displays that ATCT controllers and supervisors/TMCs accept
and use will be a major challenge. Although the necessary human factors
work has not yet been performed to identify an appropriate user
interface, a TMA Timeline Graphical User Interface (TGUI) is a useful
framework in which to conceptualize the type of information that SMS
will be able to provide. Timelines may be referenced to any physical
point, including runways, spots, and departure fixes. Figure 1 shows TMA
timelines; the left two show when aircraft will cross the arrival meter
fixes and the right-most shows when aircraft will reach the runway
threshold. The information SMS will present will depend on who will use
it and what task it will aid. For example, a timeline referenced to the
departure runways showing the predicted departure times and an advised
sequence is being studied as a display for the Local Controller. A
timeline referenced to the hand-off spots is being considered to aid the
Ground Controller in the task of accepting aircraft from ramp hand-off
spots in an efficient and user-preferred sequence.

Timelines offer several other display dimensions to encode additional
information. Timelines are able to provide trend information "at a
glance" by color-coding the aircraft. SMS will use color to distinguish
to which departure gate a flight is filed. Additional information, such
as the aircraft's departure fix, will be included in the data block.
Bars can be added to aircraft data tags to show the periods of time that
the aircraft will occupy the runway (or other constrained resource). In
this way, timelines are capable of depicting the separation between
arrival, departure, and crossing operations on a runway.

> ![](media/image2.png){width="5.081944444444445in"
> height="2.1597222222222223in"}

**Figure 1. TMA timeline display of predicted and scheduled arrival
times**

By providing information which is not currently available, SMS is
anticipated to improve controllers' ability to manage surface traffic
efficiently and maximize departure throughput. Moreover, having a common
awareness of the near-term departure situation may facilitate the ATCT
and air carriers in collaboratively managing departure queues and
surface movements (e.g., manually sequencing departures to improve
departure throughput). Takeoff time predictions may benefit air carrier
decision making. Information about current and predicted departure
queues displayed in the TRACON TMU may allow better coordination of
runway use without explicit communication between the ATCT and TRACON.
For example, the TRACON would know when a departure queue exists at a
runway and could stop sending arrivals to that runway, without the ATCT
Supervisor/TMC needing to call the TRACON TMU. Similarly, if the TRACON
TMU had information about queues trying to cross an arrival runway, the
TRACON could adjust the gaps between arrivals to facilitate crossing
without the ATCT needing to call to ask the TRACON to slow the arrival
rate. Finally, the algorithmic and display developments required to
provide this near-term departure information are a necessary step toward
SMS providing advisories to help with the management of surface and
departure operations.

Given parking gate information, SMS will also calculate accurate taxi
time estimates for arrivals. Better predictions of IN (i.e., gate
arrival) times will improve air carrier decision making about gate and
ground resource management. Where CTAS (TMA or FAST) is available, SMS
will use the CTAS arrival time estimates. Otherwise, SMS will use radar
surveillance to calculate arrival time predictions.

Ground Controllers use knowledge of an aircraft's parking gate (or the
hand-off *spot* at which the aircraft transitions from ATCT to ramp
tower control) to plan a taxi route for the aircraft. In addition,
TRACON Arrival Controllers sometimes use this information for arrival
runway assignments. SMS will convey this information with less workload
than is currently required. Currently, the ramp tower (or the air
carrier's *station* at airports where the air carrier does not have a
ramp tower) tells pilots their gate or spot when they call "in range."
At Dallas/Fort Worth (DFW), for example, the pilot then relays this
information to the Ground Controller. During night operations at Memphis
(MEM), the pilot relays this information to the TRACON Arrival
Controller, who enters it into the ARTS scratch pad. The Ground
Controller then copies the ramp entry spot from the Digital Bright Radar
Indicator Equipment (DBRITE -- the repeater of the TRACON radar display
located in the ATCT). SMS, which will receive the arrival gate from the
air carrier, will provide this, as well as a recommended spot, to the
ATCT earlier and with less radio communication.

2.  **Longer-Horizon Departure Demand**

SMS will also forecast aggregate demand (i.e., total number of aircraft
in a period of time, without identifying individual flights) for each
runway, or other constrained resource, over a longer time horizon,
similar to that over which TMA predicts and manages arrival demand. To
predict departure demand further in advance (i.e., prior to aircraft
pushback), SMS will use airline-provided information about when each
aircraft will want to push back. By providing information about the
future departure demand, SMS will allow the ATCT, air carriers, TRACON,
and Center to coordinate traffic management decisions (e.g., what
restrictions to place on departures and, in concert with information
about future arrival demand, arrival-departure tradeoffs) based on a
common situation awareness. SMS-provided information about future
departure demand is expected to be most helpful during irregular
operations, when controllers cannot use knowledge of daily schedules
gained through experience to predict the timing of future demand.

Although the necessary human factors work has not yet been conducted to
identify an appropriate user interface, a TMA Load Graph, shown in
Figure 2, is useful for describing the type of information that SMS will
provide. Load graphs are capable of showing both predicted (i.e.,
without traffic management intervention) and scheduled profiles. In
addition, load graphs can show multiple predictions for alternative
traffic management decisions, to provide a "what if" capability. Like
the near-term predictions, aggregate demand forecasts may be referenced
to a variety of constrained resources other than the runways, such as
departure fixes or parking gates/spots. What aggregate information will
be presented will depend on who will use it and what task it will aid,
and will be determined as the research progresses. As examples, SMS will
display load graphs of the future demand for each departure gate to the
Ground Controller and Supervisor/TMC to aid runway balancing decisions.
SMS will also display load graphs of the delay at each runway under the
current and alternative departure scenarios.

> ![](media/image3.png){width="3.7576388888888888in"
> height="3.4784722222222224in"}

##### Figure 2. TMA Load Graph display of aggregate demand

3.  **Departure Planning Concepts**

SMS users may not have the necessary information or time to plan beyond
immediate aircraft movements, especially during busy periods. The
ability to predict the future departure situation enables SMS to aid
users by advising how to manage some aspects of surface operations to
best achieve strategic goals. SMS's departure planning attempts to
increase airport throughput (i.e., peak capacity rate), increase the
efficiency of surface operations (i.e., minimize the cost of unavoidable
delays and their environmental impact), and improve user flexibility
(i.e., minimize the impact of delays on air carrier business
objectives), without increasing user workload. SMS will continually
update its advisories to react to the current situation and controller
actions and will be collaborative between the ATCT and the air carriers.
Exactly what information or advisories will be displayed to which
controllers or air carrier personnel will be determined as part of the
research; the following describes the initial research focus.

SMS will plan and recommend a departure sequence for each runway that
maximizes runway throughput subject to wake vortex and downstream
traffic management restrictions. An additional objective of departure
sequencing will be to incorporate air carrier priorities to enhance user
flexibility without compromising fairness or throughput. At some
airports, such as DFW, the taxiway geometry allows the ATCT to construct
efficient departure sequences after aircraft enter the active movement
area. However, at other airports, the ATCT has limited ability to
sequence departures once aircraft have pushed back from their gates. For
example, when Philadelphia airport (PHL) operates in an east flow
configuration, the ATCT has almost no opportunity to sequence departures
off Runway 9L, since the US Airways ramp tower controls taxiway Juliet
almost to the departure end of the runway and the ATCT does not know
which flights are in this queue (Figure 3). The ATCT controls parallel
taxiway Kilo which also feeds 9L. In this case, SMS could help the ramp
tower sequence departures on taxiway Juliet, and help the ramp tower and
ATCT coordinate which aircraft should queue on taxiway Juliet and which
should be handed off to the ATCT (and at which spot) to queue on Kilo.
Note that to provide many of the planned capabilities, SMS will need
ASDE-X to provide surveillance of the ramp areas (which the FAA has not
currently specified as a requirement in the ASDE-X program) as well as
the active movement area.

> ![](media/image4.wmf){width="3.908333333333333in"
> height="1.2583333333333333in"}

##### Figure 3. Departure queues for PHL Runway 9L

SMS will also help manage Approval Request (APREQ) flights. When calling
the Departure Controller for a release time for a flight, the ATCT needs
to know when the flight would be able to reach the departure runway. SMS
will predict the earliest departure time, accounting for surface
traffic, and then advise queue assignments (where multiple queues feed a
runway) and a departure sequence to meet the assigned APREQ time window.
SMS will similarly support controllers in meeting EDCTs for flights with
ground holds.

4.  **Departure Runway Balancing**

SMS will provide decision support for runway assignment decisions, with
the goal of increasing airport capacity by maintaining balanced
departure runways. Removing a few aircraft from a queue (and reassigning
them to a different runway) at the beginning of a departure rush can
reduce the delays incurred by every subsequent departure. Current
procedures assign departures to a runway according to a one-to-one
mapping from departure fixes to departure runways. The purpose of these
runway assignment rules is to assure that the airborne trajectories of
aircraft that takeoff from different runways does not cross. The
different mappings of departure fixes to departure runways are referred
to as *departure scenarios*. For example, Figure 4 shows the departure
scenario DFW typically uses during an eastbound push in south flow
operations. The ATCT selects the departure scenario to balance the
demand on each of multiple departure runways.

> ![](media/image5.wmf){width="4.611111111111111in"
> height="3.0590277777777777in"}

##### Figure 4. DFW departure scenario for an eastbound push during south flow operations

SMS will evaluate two approaches for aiding departure runway balancing:
supporting the selection of the departure scenario schedule and advising
runway assignments for specific flights that are exceptions to the
departure scenario. SMS will support the ATCT's selection of the
departure scenario by providing information about the demand, as a
function of time, for each of the departure fixes. This information is
not currently available. Although currently controllers can scan all of
the flight strips for the proposed flights to determine the demand for
each departure fix, the time at which each flight will want to depart is
not known reliably. During normal operations, controllers know
approximately when each flight departs from experience. However, during
irregular operations, flights will not depart at their typical times.
SMS-provided information would allow the ATCT to select an efficient
departure scenario and to plan when to change the scenario. In this way,
the departure scenario may be adjusted more frequently, and the timing
of changes may better match the time-varying demand. Alternatively, SMS
will consider calculating and advising an optimal schedule for the
departure scenario.

The flight-specific runway advisory function will search to determine
whether one or two departure runway assignments (per rush) that are
exceptions to the current departure scenario could provide a significant
reduction in total departure delays. Since these runway assignments
would violate the active departure scenario, which procedurally assures
that there will be no airborne conflicts between departures off
different runways, the search for beneficial alternate runway
assignments is further constrained by the requirement that the suggested
runway assignments cannot cause airborne conflicts. Airborne departure
conflicts would represent a safety concern and create high controller
workload. To ensure conflict-free departure trajectories, SMS will
perform a conflict probe to ensure that the advised departure sequence
(and resulting departure times) and the departure runways do not result
in a conflict in departure airspace. In Build 1, this conflict probe
will be the application of the procedural rules that are currently used
to assure that flight paths do not cross.

Note that controllers currently do this manually when workload permits.
Although the aircraft will be flying to the same departure fix as is in
its flight plan, since the aircraft will be departing off a different
runway, the ATCT must coordinate with the affected Departure Controllers
to assure that airborne separation will be maintainable with acceptable
workload. The aircraft will be displayed on the radar scope of the
Departure Controller assigned to the filed departure fix, but will be
coming off a different runway than the other aircraft that controller
handles. This is most easily done at the beginning of a departure push,
before the airspace gets busy. By automating the search for feasible and
beneficial runway assignments that are exceptions to the current
departure scenario, and by simplifying the necessary coordination, SMS
may allow more frequent use of the technique during busy periods, when
it will have the most benefit.

Alternatively, SMS will recommend changing a flight's flight plan to use
a different departure fix so that the flight would be assigned to a
different departure runway without violating the rules of the active
departure scenario. In this case, the aircraft would rejoin its original
route in Center airspace. The purpose of using an alternate departure
runway for a particular flight could be either to help balance the
departure runways or to help that flight takeoff earlier. Due to its
effect on fuel requirements or business objectives, the flight's
dispatcher/AOC may need to approve a flight plan change. Therefore, SMS
will recommend the departure fix change to the AOC or ramp tower, in
accordance with Coded Departure Routes which will facilitate the
communication and coordination of departure routes. Rather than advising
a flight plan change for a particular flight, displaying the predicted
delays for each departure fix would allow the AOC to evaluate which
flight to reroute. Depending on the timing, the associated flight strip
may need to be returned to the Clearance Delivery (CD) Controller from
the Ground Controller's bay of flight strips. Currently, the ATCT will
occasionally initiate flight plan changes to balance departure runways.
At DFW, for example, this is typically done by the CD Controller when
issuing the Pre-departure Clearance (PDC). However, it may be done after
the aircraft has pushed back and is waiting at a spot. SMS will automate
the search for candidate flights and the necessary coordination.

2.  **Arrival-Departure Tradeoffs**

At airports where arrival and departure capacities are interdependent,
due to interactions between the two types of operations, arrival and
departure management must be interoperable. TMA-provided information
about future arrival demand, in conjunction with the shared awareness of
future departure demand that SMS will create, may enable the ATCT,
TRACON, and Center to coordinate traffic management decisions, such as
arrival-departure tradeoffs, with less workload and better use of
limited resources. Additional efficiencies may be achieved by adjusting
the arrival and departure rates more dynamically to track the
time-varying demands. Note that if TMA is not available to provide
flight arrival time estimates, SMS can generate estimated arrival times,
although SMS's predictions are expected to be less accurate than TMA's.

The second SMS simulation in NASA's FFC facility will study strategic
arrival-departure interoperability. In addition to providing raw
information, SMS will advise a schedule of coordinated arrival and
departure capacities that match the time-varying demands for the two
types of operations. SMS is able to include considerations such as the
potential for surface gridlock if arrivals are favored when departures
are late. In this case, for example, when arrival gates are not
available, SMS would advise favoring departures. A trial-planning
capability, in which SMS will predict the delays that would result from
a traffic management decision that is being considered, will also be
studied.

To achieve the planned arrival-departure mixture, the simulated Center
TMU will manually adjust the airport acceptance rate (AAR) to which TMA
schedules arrivals, and the ATCT will manage departures,
opportunistically using available departure capacity. However, to
achieve the planned departure rate, the TRACON may need to impose
additional constraints on arrivals to create gaps in the traffic stream
in which departures efficiently fit. To what extent individual aircraft
must be managed (i.e., tactical arrival-departure interoperability) to
achieve the arrival and departure rates (i.e., strategic
arrival-departure interoperability) will be addressed in the research.
This capability will not be included in the initial version of SMS that
will be demonstrated at a field site.

1.  **Queue Length Management**

Managing the rate at which aircraft enter the taxiway system has the
potential to reduce the environmental and operating costs associated
with long departure queues while maintaining maximum departure
throughput. By maintaining shorter runway queues, aircraft are running
their engines for less time on the surface. SMS may help the ATCT and
ramp tower to collaboratively manage departure queue lengths by advising
aircraft pushback or taxi-start times. Pushback management must be done
collaboratively with the air carriers so that the solution allows the
air carriers to manage their gates, and fairly so that gate-held flights
do not lose their place in the virtual departure queue. Eventually, SMS
may fairly allocate departure capacity to air carriers, much as the
Collaborative Decision Making (CDM) Flight Schedule Monitor (FSM) tool
allocates an airport's arrival capacity when ground holds are imposed on
departures to that airport. In this case, the air carriers could make
decisions about which departure to operate in each slot to best achieve
their business objectives.

Queue length management also has application during de-icing operations.
To determine when to start de-icing a flight the departure delay that
the flight will incur must be estimated. SMS would predict the queue
lengths and delays both at the runway and the de-icing operation. To do
this, SMS would need the airport authority, which is responsible for
clearing the runways, to provide information about when each runway will
be closed.

3.  **System Architecture**

Figure 5 shows the system architecture for SMS, with shaded boxes
representing elements that will be part of SMS and outlined boxes
representing possible deployment locations. SMS displays will present
information and advisories in the ATCT and the air carrier's ramp
towers. In addition, SMS displays may operate in the TRACON TMU, Center
TMU, and AOCs. The physical location of the SMS display in each tower
will be determined as part of the research.

SMS is being designed to use real-time location and identity information
about aircraft on the airport surface, although some SMS capabilities
will function without this input. The ASDE-X system, currently being
developed by the FAA, will combine either an existing ASDE-3 (Airport
Surface Detection Equipment) or a new x-band primary radar, an Airport
Traffic Information Display System (ATIDS, which is a transponder-based
multilateration surveillance system), Automatic Dependent Surveillance
-- Broadcast (ADS-B) transmissions from aircraft, and ARTS information
to produce a coherent picture of aircraft moving on the airport surface.
Some of SMS's functions will require that ASDE-X coverage include the
ramp areas. NASA has proposed to test SMS at Memphis, where the FAA's
Safe Flight 21 program has developed a prototype surface surveillance
system which is functionally equivalent to ASDE-X. It combines ARTS ,
ADS B and multilateration to achieve comprehensive coverage on the
airport surface. Note that the Safe Flight 21 system at Memphis has been
enhanced to include coverage of the ramp areas. SMS may also get limited
ARTS airborne surveillance information from the Safe
![](media/image6.wmf){width="5.995138888888889in"
height="4.910416666666666in"}Flight 21 system which it will use in the
prediction of landing times for the arrivals.

**Figure 5. SMS System Architecture**

SMS will receive flight plan information, as well as surveillance
information for arrivals outside the terminal area, from the Enhanced
Traffic Management System (ETMS). SMS will receive the air carrier's
planned departure times for each flight from the Aggregate Demand List
(ADL), an element of CDM hosted as part of ETMS. The sufficiency of this
information for this application is not yet known. This research will
help identify the requirements for the accuracy of knowledge about
departure demand to perform various levels of departure planning. Ramp
towers currently have better knowledge about when each flight will want
to push back than the AOCs. The SMS project will work with the air
carriers to encourage them to communicate their best available intent
information to the AOC systems that provide demand predictions into the
ADL. This approach avoids the need to interface to every air carrier's
ramp tower automation system.

To predict taxi-in times as well as surface conflicts between arrivals
and departures, SMS will need to know at what gates the arrivals will be
parking. If this information cannot be added to the ADL data stream,
then, as an interim approach, SMS will get it from the ramp towers,
either through manual entries or connections to the air cariers'
automation systems. SMS will also incorporate air carrier priorities in
its departure planning; these preferences will either be inferred from
the air carrier's schedule or entered manually by the ramp tower or AOC.

To correctly model inter-departure times and plan efficient sequences,
SMS must know what downstream restrictions are in effect. The National
Log Program will provide miles-in-trail (MIT) restrictions. EDCTs for
aircraft affected by ground holds are available from ETMS. The current
airport configuration, planned configuration changes, and APREQ times
are the only information that the ATCT controllers will be required to
enter.

**3. Functional Flow**

Figure 6 is an expansion of Figure 5, showing the currently planned SMS
elements as well as the future ones. All of the known inputs and outputs
of the SMS are shown, as well as four of the required functions (Surface
Trajectory Synthesis, Construct Departure Queues, Trial Planning, and
Conflict Prediction). Shown within the central SMS box are all of the
parameters that SMS will eventually calculate and send to the various
elements shown on the diagram. The exact flow of information, as SMS
evolves, is not known at this time. This diagram will be updated as SMS
plans and designs become firmer.

##### 

![](media/image7.wmf){width="7.625in" height="4.909027777777778in"}

**Figure 6. SMS Functional Flow**

### BIBLIOGRAPHY

1.  **Atkins, S. and Brinton, C.,** "Concept Description and Development
    Plan for the Surface Management System," submitted to the *Air
    Traffic Control Quarterly.*

2.  **Anagnostakis, I., Idris, H., Clarke, J.-P., Feron, E., Hansman, R.
    J., Odoni, A., and Hall, W.** (2000), "A Conceptual Design of a
    Departure Planner Decision Aid," *3'rd USA/Europe ATM R&D Seminar*,
    Napoli, Italy.

3.  **Atkins, S. and Hall, W.** (2000), "A Case for Integrating the CTAS
    Traffic Management Advisor and the Surface Management System," *AIAA
    Guidance, Navigation, and Control Conference*, Denver, CO, August.

4.  **Erzberger, H., Davis, T., and Green, S**. (1993), \"Design of
    Center-TRACON Automation System,\" *AGARD Meeting on Machine
    Intelligence in Air Traffic Management*, Berlin, Germany, May.

5.  **Glass, B.** (1997), "Automated Data Exchange and Fusion for
    Airport Surface Traffic Management," *AIAA Guidance, Navigation and
    Control Conference*, AIAA-97-3679.

6.  RTCA Select Committee for Free Flight Implementation (2000),
    *National Airspace System Concept of Operations Addendum 4: Free
    Flight Phase 2*.

7.  **Swenson, H., Hoang, T., Engelland, S., Vincent, D., Sanders, T.,
    Sanford, B., and Heere, K.** (1997), \"Design and Operational
    Evaluation of the Traffic Management Advisor at the Fort Worth Air
    Route Traffic Control Center,\" *1st USA/Europe Air Traffic
    Management R&D Seminar*, Saclay, France, June.

8.  **Welch, J., Bussolari, S., and Atkins, S.** (2001), "Using Surface
    Surveillance to Help Reduce Taxi Delays," *AIAA Guidance,
    Navigation, and Control Conference*, Montreal, Canada, August.