|
|
|
||||||||||||||||||||||||||||||||||||||||
Surface Management System Simulations in NASA's FutureFlight Central |
||||||||||||||||||||||||||||||||||||||||||
|
Susan M. Lockwood Stephen C. Atkins, Ph.D. Nancy Dorighi AbstractThe Surface Management System (SMS) is a decision support tool that will help controllers and airlines to manage surface traffic at busy airports, thus improving capacity, efficiency, flexibility, and safety. A virtual reality air traffic control tower at NASA Ames Research Center called FutureFlight Central (FFC) recently supported a two-phase test of SMS. During five months of testing at FutureFlight, developers obtained feedback and performance metrics from end users as if the technology had been installed in the real working environment at one of the nation"s busiest airports. This paper details the lifecycle of the simulation experiments from design to execution. Nomenclature
IntroductionThe Advanced Air Transportation Technologies (AATT) project at NASA Ames Research Center, the FAA, and industry are actively pursuing the development of decision support tools to aid air traffic controllers in the safe and expeditious handling of traffic throughout the National Airspace System (NAS). Oftentimes the ideal testing environment for new tools is “ground zero,” the site of the problem the tool is designed to mitigate. However, for reasons of safety and efficiency it is not always possible to conduct tests in an operational environment; it is undesirable, for instance, to ask a tower controller to divide her attention between the traffic for which she is responsible and a new, unfamiliar graphical representation of that traffic. NASA Ames' FutureFlight Central facility was developed with this need for an as-good-as-real testing ground in mind. A full virtual reality, configurable air traffic control tower cab simulator, FFC is capable of recreating the look and feel of any airport. FFC engineers not only recreate the out-the-window view of the airfield from the tower, but also help design traffic flow scenarios that mimic the airport's day-to-day operations, both on the surface and in the terminal area. In this way, new concepts for a particular airport or for the NAS in general can be tested in an environment that mirrors reality to a high degree of fidelity without compromising operational safety or efficiency. The Surface Management System, currently under development at NASA Ames Research Center, leveraged FFC's high fidelity, no-risk capability for testing new decision support tools to evaluate its initial display and algorithm designs. SMS is designed to help controllers manage traffic on the surface of busy airports. Using input from surface surveillance radar, the airlines, and other sources, SMS will enhance coordination between the various organizations involved in the management of airport surface operations. Two SMS simulations were conducted at FFC over a five-month period, the first in September of 2001 and the second in January of 2002. FFC engineers recreated Dallas/Ft. Worth International Airport (DFW) for the experiments, and DFW controllers attended the simulations to work traffic and offer feedback about SMS' decision support capabilities and graphical interfaces. This paper follows the development lifecycle of the two SMS experiments and explores the issues involved with preparing the FFC facility to interface with SMS and with the Center-TRACON Automation System's Traffic Management Advisor (TMA) tool. FFC was the first environment in which the concept of combining TMA's arrival metering functionality with SMS' departure metering capabilities was tested in an operational context; this paper will describe how that demonstration was accomplished. A brief introduction to the FutureFlight Central facility is provided, along with an overview of the Surface Management System. Overview of FutureFlight CentralLocated at the NASA Ames Research Center, Moffett Field, California, FutureFlight Central uses twelve rear-projection screens and computer generated imagery to create a 360-degree “out-the-window” representation of an airfield and its environs as seen from the tower cab. FFC's image generator is an SGI, Incorporated Onyx 2 Reality Monster computer configured with six graphics engines and 16 processors that provide a nominal 30Hz update rate. FFC's lower floor Operations Center is comprised of three main areas: the Pseudo-pilot Room, Test Engineer Room, and the Operations/Ramp Control Room. The Pseudo-Pilot Room hosts thirteen pilot stations, each with a 2-D map display of the airport surface on a 21-inch, color high-resolution monitor. This display is the pilot's interface to the aircraft in his or her area of responsibility; from here, the pilot controls aircraft speed, heading, taxi routing, gate operation (push-back, taxi-in), runway operation, departure profile, and arrival routing, among other parameters. A flight may be moved to any position on the airport surface that has been defined for the operation, and fine adjustments to the aircraft position are possible. A pilot is able, for example, to comply with a controller's direction to exit the runway at a given high-speed taxiway, taxi forward for maximum spacing, and hold short of the active parallel. The pilot communicates with tower and/or ramp controllers via voice communications system (VCS) located at the station. The VCS emulates standard radio communication; each pseudo-pilot has the ability to transmit and receive on appropriate frequencies (ramp, ground, local, departure) as the flight progresses through the area of positive control. Frequency values match those of the airport that is currently being simulated. The Test Engineer's Room is the control center for all of the facility's audio/visual and simulation systems, and the facility's data collection and reduction equipment is located here as well. The Test Engineer is connected via VCS to all other participants in the simulation, and is responsible for starting and stopping the simulation software. The Operations/Ramp Control Room can be configured to simulate an airline ramp control operations center. Since there was no requirement to include ramp operations for the SMS experiments, this room was instead used as the control center for SMS-FFC interaction. The SMS kernel software and the SMS-FFC interface software were located on a Sun workstation in this area, and SMS engineers monitored the software's performance from workstations and laptop computers arranged around the room. The upper floor of the FFC facility accommodates the projection display system and the air traffic control tower cab. The tower cab is modular and can be configured to match the layout of the airport tower being simulated. Recessed into the perimeter console are 16-inch, flat panel touch screens on which radar equipment, wind indicators, clocks, and altimeters are simulated. Flight progress strips and container banks are provided, along with Digital Bright Radar Indicator Tower Equipment (D-BRITE) monitors, and multiple VCS plug panels at each station. Figure 1 is a view of the inside of the FFC tower cab.
Figure 1: The FFC Virtual Tower Overview of the Surface Management SystemThe Surface Management System is a decision support tool that predicts the impact of expected departure demand on surface traffic flow, offering both near-term tactical predictions and farther-term strategic forecasts to the airport's air traffic service providers (ATSPs) and the airlines. SMS acts as a “controller's assistant,” displaying information about future departure demand, allowing controllers to trial-plan solutions before implementing them, and generating advisories based on current conditions and controller input. Information may be displayed on dedicated SMS terminals or shown as a supplement to information on existing systems. Inputs to SMS include airport surface surveillance radar data for aircraft position and identification information; in-trail and metering restrictions from the National Log Program; Enhanced Traffic Management System (ETMS) inputs such as flight plans, push-back times, and Expect Departure Clearance Times; and information from the airlines such as gate occupancy data and flight priority designations. At the time of this writing SMS is intended for use by tower personnel and airline ramp tower controllers; future versions may also provide information to the TRACON and Center Traffic Management Units and the ATC System Command Center. Future versions of the tool will also interoperate with traffic management decision support tools such as NASA's CTAS, as demonstrated during Simulation 2 of the SMS experiments at FutureFlight Central. SMS has been implemented in the Java programming language and was run on the Solaris 5.8 and Red Hat Linux 6.1 operating systems during Simulation 1 and Simulation 2, respectively. Further description of SMS appears in reference 1. SMS-FFC Integration via HLAIn the field SMS will receive real-time aircraft position updates from a radar feed as described above. For the FFC experiments, SMS engineers built a software module designed to emulate this radar feed by passing flights from the FFC's simulation kernel to SMS. Through this SMS-FFC interface, SMS received the aircraft identification and position reports necessary for its algorithms and airport map display in a format identical to that of the actual radar feed it will have in the field. None of the other inputs to SMS were simulated by FFC for the experiments. The SMS tests provided the first opportunity to connect FFC to an external software system for experiment purposes. To accomplish radar emulation, the SMS-FFC interface made use of FFC's High Level Architecture (HLA) functionality. Developed under the leadership of the Defense Modeling and Simulation Office (DMSO), HLA is an open standard, general purpose architecture that ties simulators together by creating an abstraction called a “federation,” a sort of playing ground common all the participants, or “federates.” The HLA Applications Programmer Interface provides methods by which a federate may join an active federation or, if desired, create a federation for others to join; send and receive updates on a publish/subscribe basis; resign from the federation; and destroy the federation when the exercise is complete. The FFC simulation software creates and initializes a federation for federates to join. Representing itself as SMSFederate, SMS joined the federation and received updates to each aircraft's latitude, longitude, indicated airspeed, heading, and turn rate. These updates were streamed to SMS through the SMS-FFC interface designed for this purpose, in radar feed format and at a nominal 1Hz update rate. Recreating DFW for FFCSeveral candidate airports were considered for the SMS experiments, including Los Angeles International, Memphis International, and San Francisco International. Dallas/Ft. Worth International was chosen for its traffic volume and for the fact that CTAS tools are deployed at the airport and TRACON facilities. CTAS' Traffic Management Advisor has already been adapted for DFW airspace; this fact was a key consideration in the selection DFW over other possible sites because of the Simulation 2's requirement to demonstrate SMS-TMA interoperability. FFC could only simulate one of the two control towers that operate at DFW (the airfield has a total of three towers, two of which are in regular use). However, it was not necessary to model the entire DFW airport for the purposes of the SMS experiments. Since three of the airport's four gate clusters are located on the east side of the field, and since the east side of the airport typically sees the balance of surface traffic demand, the west side of the field was not recreated for the experiments. '“DFW for FFC” then, was a recreation of all of the runways, taxiways, gate structures, airport buildings, roadways, and navigational aids visible from the airport's east tower; no visual representation of the west side runway and taxiway geometry was modeled. Horizon features (buildings, freeways, etc.) were modeled for realism and visual orientation. Although air traffic associated with the Dallas/Ft. Worth area's other airports is often visible from the east tower, no overflights were simulated. Ground vehicle traffic movement was not simulated, with the exception of aircraft tugs for pushback operations. Refer to Figure 2 for an airport and traffic flow diagram.
Controller Staffing and Responsibilities in the FFC TowerSMS and FFC engineers visited DFW in the summer of 2001 to study the layout of DFW's east tower and record information about controller staffing, the type and positions of various tower tools, and the physical placement of controller positions relative to the out-the-window view of the airfield. Using this information, the FFC tower was configured to recreate a scaled-down representation of DFW"s east tower, modified as necessary to meet the goals of the SMS experiments. Observations about traffic flow and surface congestion points were used to determine pseudo-pilot staffing requirements and responsibilities for the tests. Normal staffing for DFW's east tower includes one local controller for runways 17C and 17R (Local East One), a local controller for runways 13L and 17L (Local East Two), two ground controllers (Ground East One and Two), a clearance delivery specialist, and a Traffic Management Coordinator (TMC). During peak arrival/departure pushes an additional controller assists at the Local East One position. Five Full Performance Level controllers currently on staff at DFW attended the simulation dry runs and experiment dates to rotate through the Local East One, Ground East One and Two, and TMC positions for the tests. A retired air traffic controller on the SMS team filled the Local East One Assist position. Since operations on runway 17L were automated and restricted to arrivals only, and since runway 13L was closed for the purposes of the SMS experiments, the Local East Two position normally staffed at DFW was not staffed in the virtual tower. Instead, the controller assisting at Local East One notified his controller when automated flights reached the hold-short point of runway 17C. This notification replaced the communication that the Local East One controller would normally receive from Local East Two about flights wishing to cross runways 17C and 17R on their way to the ramp areas. In the FFC tower, two SMS displays were provided at each controller station, one showing a 2-D representation of the airport's runways, taxiways, spots, and gate structures, and another showing SMS timelines and load graph displays. At all times during the experiment runs the SMS 2-D map was available for the controllers' use; the other display was activated during certain test conditions and unavailable for others. See Figure 3 for a diagram of controller positions and equipment placement in the virtual tower.
Figure 3: Controller Positions and Equipment in the Virtual Tower Figure 4 is an example display of the SMS 2-D surface map showing position markers and data blocks for flights at the American Airlines A terminal and northeast hold pad area. The display has an inset feature which allows the controller to enlarge a section of the map for clarity; the detail shown here was configured by the Local East One controller to highlight activity on the northeast hold pad.
Figure 4: SMS 2-D Map Display Scenario DesignKey to the success of the experiments was the design of realistic and challenging traffic scenarios which presented controllers with problems identical to those they solve on a daily basis at DFW: runway crossing restrictions, wake turbulence delays, heavy taxi-in/taxi-out delays, long departure queues, and the like. Three traffic scenarios were designed for the experiments with these considerations in mind. To facilitate the experiments' goals and to allow test engineers to more easily manipulate runway demand, runway 17R was designated an arrival-only runway, 17C allowed mixed operations, and 17L was a fully-automated (no landing clearances requested or issued) arrival-only runway. Also, mixed prop and jet operations were permitted on runways 17C and 17R, a nonstandard procedure for DFW but necessary for the purposes of the SMS experiments. Each one-hour scenario was representative of actual traffic operations at DFW and was generated using ETMS data for July 1, 2001. The scenarios were drawn from the 0800, 1130, and 1300 local time arrival/departure rushes to simulate south flow, day visual flight rules operations. Each scenario was adjusted to begin at 1130Z in order to minimize the chances of a controller basing decisions on previous experience with a particular named scenario. The three scenarios were identified as 1130_a, 1130_b, and 1130_c, respectively. The mix of traffic included flights from American, American Eagle, Delta, Northwest, Atlantic Southeast Airways, AeroMexico, and Air France air carriers. FFC visual database engineers provided liveries and aircraft type models appropriate to each airline's fleet. As many as 121 flights were active in the simulation during a given scenario. Gate assignments for flights were determined through the use of Flight Information Display System (FIDS) data, which identified allowable gate assignments based on airline and aircraft type information. This FIDS data was combined with information provided by both American and Delta airlines about gate usage, and with observations made by experiment engineers on site at DFW to provide a comprehensive, realistic gate assignment rationale for the airport. The scenarios were modified to resolve data inconsistencies and to meet the objectives of the experiments, which required the flow of traffic to migrate from a heavy departure push to a heavy arrival push over the course of an hour, with a period of mixed operations in between. This design was intended to produce a runway imbalance at the start of the hour - very high departure demand on runway 17R, proportionally lower arrival demand on runway 17C - which would require controllers to consult SMS in order to plan potential tradeoffs associated with arrival/departure dependencies. Important to the successful execution of the simulation scenarios was training the pseudo-pilots to become comfortable with the controllers' rapid speech delivery and shorthand clearances. Having DFW controllers attend dry run sessions before the actual experiment dates was helpful in this regard. Simulation 1The purpose of Simulation 1 was to allow DFW controllers to explore SMS' decision support capabilities for tasks such as managing departure queues, allocating runways, determining optimum taxiway routing, and sequencing aircraft at various locations on the airport surface. Under particular consideration was the use of SMS to support runway balancing. Another key objective of Simulation 1 was to complete an initial assessment of the SMS graphical user interface under realistic operational scenarios and conditions. Due to extraordinary national events, the simulation schedule for the week of September 10th, 2001, was reduced from four test days to one. Controllers attended an off-site SMS training session on Wednesday, September 12th, and conducted operational tests in FFC on Thursday. They participated in experiment dry runs before the actual tests and provided feedback to SMS designers which was incorporated into later versions of the tool. SMS engineers designed three experiment conditions for the Thursday tests, each one based on a different traffic scenario (1130_a, 1130_b, or 1130_c) and each offering increasing levels of SMS functionality for the controllers' use and evaluation. In Condition 1 (baseline SMS condition, 1130_a scenario), the controllers were shown the SMS map display with expanded flight data blocks containing some combination of flight ID, aircraft type, gate and spot information, departure fix, and runway assignment. The content of the expanded data block was configured by each controller to meet his or her needs and preferences; at a minimum, the block showed the aircraft callsign. However, none of the other SMS decision support tools (timelines, load graphs, and runway assignment suggestions, or “advisories”) were made available to aid the controller's decision making process. Condition 2 (expanded SMS capabilities, 1130_b scenario) included Condition 1's map display functionality but also offered the controllers timeline information and runway advisories. Condition 3 (full SMS capabilities, 1130_c scenario) provided controllers with timelines, load graphs, runway advisories for each flight, and the 2-D representation of the airfield. In each condition, controllers worked traffic as demand migrated from a heavy departure push to a heavy arrival push, consulting SMS as appropriate. Pseudo-pilots communicated with controllers on DFW-standard frequencies using standard ATC phraseology. In addition to standard phraseology, controllers were able to issue the “shorthand” standard taxi clearances which they have developed with the airlines at DFW. The pseudo-pilots had been trained, for example, to recognize “American 467 heavy, KEG to 17 right” as a clearance to proceed to runway 17R via taxiways Kilo, Echo, and Golf in succession. These shorthand clearances were used in Simulation 2 as well. After each test run, the controllers were asked to complete usability, suitability, and acceptability questionnaires about the individual SMS feature(s) to which they had been exposed. Feedback from the controllers about the design of the traffic scenarios and the visual representation of the field proved that FFC and SMS engineers had been successful in recreating realistic DFW conditions. Controllers reported becoming involved in the problem at hand, working traffic and making sequencing decisions as if the aircraft out the window were real. Simulation 2The primary objective of Simulation 2 was to demonstrate interoperability between SMS and CTAS' TMA software. Now fielding nationally under the FAA's Free Flight Phase 1 project[2], TMA is a decision support tool that helps controllers manage the flow of arrivals into busy TRACON and terminal airspace. Simulation 2 facilitated this interoperability demonstration (an AAATT milestone), and further evaluated the SMS concept and performance. No additional software connection between SMS, FFC, and TMA was developed for Simulation 2. Instead, TMA script files were built to exactly match the initial conditions of the SMS scenario files which served as input to FFC's simulation software. As the simulation progressed, adjustments were made to TMA at the direction of the tower TMC to emulate TRACON controller manipulation of airport arrival rate; these adjustments were then mirrored in the simulation software in the manner described below. Flights in the FFC's simulation database are started automatically based on a pre-programmed start time in the script file. Once a flight has been activated in FFC, its speed, course, and heading may all be adjusted by the Test Engineer or the pseudo-pilot assigned to the flight. If the flight has not yet been activated, its scheduled time of arrival and runway assignment may be altered by the Test Engineer. The ability to re-program flights not yet activated by the system was leveraged in real time as the experiment run progressed and flights were delayed or assigned to new runways according to TMA's scheduling algorithms. Refer to Figure 5 for a diagram of SMS-TMA-FFC linkage.
Figure 5: Figure 5: SMS-TMA-FFC Interaction As in Simulation 1, representatives from the FAA and several airlines attended Simulation 2 to monitor the experiments and provide feedback about the SMS concept. Each controller was shadowed by a human factors engineer who recorded metrics such as heads-up/heads-down time, controller interaction, number and type of clearances issued, and controller"s use of SMS where appropriate. The SMS team designed a matrix of three test runs per day for each of four experiment days in order to cover all test conditions. Controllers were exposed to three different conditions for each scenario: a baseline condition, in which the SMS map display was used for reference but none of the SMS decision support tools (timelines, load graphs, runway advisories) were available to aid the controllers' decision making process; the SMS condition, in which controllers were provided expanded data blocks, trend information, and runway advisories by SMS; and the SMS-TMA condition, in which additional SMS information was available to the tower TMC to aid in making the arrival/departure tradeoff decision. Two Sun workstations (Solaris 2.6 O.S.) were installed in the Test Engineer's Room to host TMA and its requisite peer processes. The system was monitored by an SMS engineer in VCS communication with the FFC Simulation Coordinator in the virtual tower. At the start of an SMS-TMA condition run, TMA was initialized and its simulation clock manually adjusted to match FFC's clock to within plus or minus five seconds “wall clock” time. At this time, both the SMS scenario scripts running in the simulator and TMA's scenario scripts running on a separate computer were in agreement as to scheduled times of arrivals and runway assignments for all arrivals in the test run. In fact, if no alterations were made to start times over the course of the experiment, the Test Engineer monitoring both FFC and TMA would see arrivals crossing the “virtual DFW” threshold at the precise moment displayed on the TMA runway arrival time line within a delta of five seconds. Upstairs in the FFC tower cab, the TMC consulted an SMS display of arrival/departure demand for runways 17C, 17R, and 17L for the coming hour. Alerted by SMS that the high departure demand predicted for the next twenty minutes could not be efficiently handled on the one available departure runway (17R), the TMC then used SMS advisories to help determine the optimal time at which to close 17C to arrivals, and the length of time this restriction should be maintained. During this “blocked interval,” all arrivals bound for 17C were off-loaded to 17L, and departures were free to use both 17R and 17C. Having observed the TMC's decision, the Simulation Coordinator communicated the 17C blocked interval to the TMA Test Engineer downstairs, who then began the process of manually adjusting start times and runway assignments for flights in the scenario. Using scheduling tools provided by TMA, the Test Engineer entered a blocked interval on the 17C TMA timeline. TMA then shifted all arrivals to 17L and generated new scheduled times of arrivals for the flights. The Test Engineer relayed new start times and runway assignments to the FFC engineer monitoring the simulation software, who made the appropriate changes to the flights in the simulation software. The modified flights were automatically started according to these new parameters and appeared in the virtual tower environment as scheduled, lined up for the proper runway. Successful and timely execution of this manual rescheduling technique ensured that the fact that TMA and SMS and FFC were not programmatically linked was transparent to the controllers in the tower and the subsequent analysis of airport delays. TMA output files were captured for post-simulation analysis. As with Simulation 1, controllers were asked to complete usability, suitability, and acceptability questionnaires about the individual SMS feature(s) after each test run. New to Simulation 2 was the tower TMC's evaluation of SMS' interoperability with TMA and the efficacy of SMS' advisories in regards to constraining the airport arrival rate. The results of these assessments will be published separately. ConclusionsThe Surface Management System simulations were the first use of FutureFlight Central to evaluate a new decision support tool. FFC proved to be an ideal environment for a safe, zero-impact initial test of SMS' algorithms, decision support capabilities, and graphical user interface. The DFW environment was modeled to such a high degree of fidelity that controllers reported becoming absorbed in the problem at hand, working traffic and making decisions as if the aircraft out the window were real. This familiarity fostered an atmosphere in which controllers could focus on SMS and evaluate ways in which the new decision support tool could be integrated into their traffic management rationale. FutureFlight Central was the first operational environment in which the potential benefits of combining the CTAS Traffic Management Advisor"s arrival metering capabilities with SMS' departure metering capabilities was explored. Though no software interface was implemented between the two decision support tools, SMS engineers" strategy for manually adjusting flights in the FFC simulator according to TMA's scheduling decisions enabled demonstration of the SMS-TMA interoperability concept. References
American Institute of Aeronautics and Astronautics
|
||||||||||||||||||||||||||||||||||||||||||
Home |
Site Map |
Contact Us |
Latest News |
Links |
About Us Updated: 03/21/2005 Curator: Kathleen Starmer Responsible Official: Wayne Momii
|
||||||||||||||||||||||||||||||||||||||||||
![[photo of Figure 1 is a view of the inside of the FutureFlight Central tower cab.]](images/tower_cab.jpg)
![[Graph of Dallas Fort Worth International Airfield Layout and Traffic Flow for FutureFlight Central]](images_sms/image005.gif)
![[Graph of Controller Positions and Equipment in the Virtual Tower]](images_sms/image009.gif)
![[ Graph of SMS 2-D Map Display]](images_sms/image007.gif)
![[Graph of SMA-TMA-FFC Interaction]](images_sms/image014.gif)