Terminal Sequencing and Spacing (TSS) Simulation-1 September 10-13, 2012

Transcription

1 Terminal Sequencing and Spacing (TSS) Simulation-1 September 10-13, /28/2012 Danny Vincent Michael Prichard Jessica Ciotti

2 I. Introduction This paper describes the simulation design, and preliminary results and recommendations from a human in-the-loop simulation of Terminal Radar Approach Control (TRACON) controller advisory tools known as TSS tools. The objectives of the simulation were to assess the feasibility and to evaluate the performance of the National Aeronautics and Space Administration (NASA) Air Traffic Management Technology Demonstration-1 (ATD-1) controller advisory tools for the near-term National Airspace System (NAS). The simulation incorporated advanced performance based navigation procedures, specifically Required Navigation Performance-Authorization Required (RNP-AR) terminal arrival procedures and constant radius-to-fix (RF) legs for the Los Angeles airport (LAX) operation. The preliminary results and recommendations are derived from comments and feedback from participants during simulation debriefs as well as from observation, and future results will include controller feedback from questionnaires and objective data such as throughput, delay distribution, arrival time, off-route time, and route conformance. II. TSS Controller Advisory Tools TSS tools assist the TRACON controllers in delivering aircraft as close as possible to the merge points or runway threshold at the scheduled time of arrival (STA) to achieve maximum throughput on capacityconstrained runways. The TSS tools provide information such as speed advisories, early or late indications, scheduling information, and spatial targets (shown in Figure 1). Five tools evaluated during this simulation were: Timelines o Provide a graphical depiction of the relationship between the estimated time of arrival (ETA) and the STA. If the ETA is ahead of the STA, the aircraft requires delay. If the STA is ahead of the ETA, the aircraft needs to be advanced o Enable the controller to assess the aircraft s schedule conformance by comparing its ETA to its STA o Available to both the feeder and final positions o Displayed for each merge point or runway threshold Early/Late Indicators o Represent the numerical difference between the ETA and STA to the next merge point or to the runway threshold as displayed on the timeline o Generated when a single speed advisory cannot be calculated to resolve schedule conformance with a 10 knot (kt) discrimination and the difference between the ETA and STA is greater than or equal to five seconds o Displayed as minutes and seconds if the difference between the ETA and STA is less than two minutes. If the difference between the ETA and STA is greater than two minutes, the minutes are displayed as whole numbers 2

3 o o Available to both the feeder and final positions Located on the third line of the flight data block (FDB) Slot Markers o Are spatial circular targets on the display to indicate where an aircraft should be at a given time if it were to fly the adapted route through the forecasted wind field, meet all published speed and altitude restrictions, and arrive at its STA on time to the merge point or to the runway threshold o Dwelling on a FDB or a callsign on the timeline will highlight the corresponding aircraft s slot marker o Display the slot speed or current indicated airspeed (IAS) next to the slot marker and the current aircraft s IAS next to the sector symbol o Represents 15 seconds of flying time in diameter, and increases/decreases in diameter with the charted speed o Available to both the feeder and final positions Speed Advisories o Displayed as air speeds when an aircraft s ETA exceeds five seconds from its STA and only if the predicted speed will resolve the difference between the ETA and STA, otherwise, the early/late indicator will be displayed o Available to both the feeder and final positions o Located on the third line of the FDB Sequence Numbers o Represent the aircraft s order to the runway o Displayed at the final controller s position o Displayed on the first line of the FDB adjacent to the runway assignment Aircraft Speed Slot Speed Sequence Number = 25L 6 Slot Marker Runway Assignment Speed Advisory Early/Late Indicator RNP/AR Capable = B733/W Figure 1. TSS Controller Advisory Tools 3

4 III. Existing Operational Tools Used During the Simulation Spacing Cones o Give visual indication of the required minimum wake vortex separation between aircraft o Displayed as a cone and extends forward from the aircraft target o Can be enabled or disabled for all aircraft or for one specific aircraft J-Rings o o Are indicators in the form of a circle around the aircraft target that assist in assessing the spacing between aircraft The radius of a J-Ring is determined by the controller. For example, he or she can choose a 3 or 5 nautical mile (nm) radius IV. Simulation Overview This simulation was conducted to assess how controllers used the TSS tools for merging, sequencing and spacing of mixed-equipage aircraft in different forecasted wind conditions on Area Navigation (RNAV)/RNP routes. The following sections describe the simulation in more detail. Note: Mixedequipage in the context of this paper means that while all aircraft were RNAV capable, not all were RNP- AR equipped) V. Simulation Run Description This simulation took place over three days and was composed of training and data collection runs. The simulation runs consisted of four training runs (T#) on day one, and ten data collection runs (D#) over a two-day period. For example, the T1 run consisted of the no winds condition and used standard operating procedures (SOPs/ no tools) and the D2 run incorporated winds and the TSS tools. Each data run lasted approximately 60 minutes with a participant questionnaire administered after each run, followed by a break and debrief. The data compiled from the controller input to the questionnaires will help to refine the TSS tools by improving their accuracy and fidelity, and enhancing their accompanying procedures and phraseology as the research and development of these TSS tools continues. Winds from the Southwest were incorporated into the simulation to determine the effects of the wind forecast on the TSS tools. Table 1 depicts the traffic demand, run description (training vs. data collection run), wind condition, tool condition, runway threshold buffer and the day each run was conducted. Refer to Section XI Simulation and Participant Guidelines for more details regarding the runway threshold buffer. Note: Run 7 was conducted on Day 2. Table 1. TSS Simulation Run Conditions Demand Run Winds Tools Runway Day Threshold Buffer 1.1 T1 No Winds SOP T2 Winds SOP.3 1 4

5 1.1 T3 Winds TSS T4 No Winds SOP D1 Winds SOP D2 Winds TSS D3 No Winds TSS D4 No Winds SOP D5 Mismatched Winds TSS D6 Mismatched Winds TSS D7 No Winds SOP D8 No Winds TSS D9 Winds SOP D10 Winds TSS.3 3 VI. LAX Airspace and RNAV/RNP Approach Routes The simulation airspace (modified from current operational airspace) contained three feeder sectors: ZUMA, South Feeder, and EAST Feeder, plus two final sectors, STADIUM 24R and DOWNE 25L. See Figure 2. RNAV and RNP approach routes were utilized and all aircraft had RNAV capability. Altitude restrictions (in red), route speeds (within arrows), meter fixes, merge points, and airspace sectors are labeled in Figure 3. Figure 2. LAX Airspace 5

6 Figure 3. LAX RNAV and RNP Arrivals Below are the routes from the South Feeder, ZUMA Feeder, and EAST Feeder positions to runways 24R and 25L: South Feeder: RNP: DARTS.SPAR6.SPAR7.PFAF3.LAX24R RNP: SLI.VPLF7.DODG7.REEDR.PFAF6.LAX25L RNAV: DARTS.PURMS.NEIL6.NEIL7.NEIL8. TAFEL.PFAF3.LAX24R RNAV: SLI.SNOLL.BRICH.REEDR.PFAF6.LAX25L ZUMA Feeder: RNP: SMO.ZANA6.ZANA7.PFAF3.LAX24R RNAV: SMO.NEIL6.NEIL7.NEIL8.TAFEL.PFAF3.LAX24R EAST Feeder: GRAM7.JAPT7.CADN7.MINZ7.MERC7. TAFEL. SPAR7.ZANA7.PFAF3.LAX24R GRAM7.JAPT7.CADN7.UOZO7.GATE7.BIRCH.REEDER.PFAF6.LAX25L MINT7.CARA7.CIVE7.MINZ7.ROYL7.MERC7.TAFEL.SPAR7.ZANA7.PFAF3.LAX24R MINT7.CARA7.CIVE7.UOZO7.WUJE7.GATE7.BIRCH.REEDER.PFAF6.LAX25L KONZL.CATAW.LAHB7.GATE7. TAFEL. SPAR7.ZANA7.PFAF3.LAX24R KONZL.CATAW.LAHB7.GATE7.BIRCH. REEDER.PFAF6.LAX25L 6

7 VII. Simulation Participants There were a total of eight controllers that participated in this TSS simulation; four of which are fully certified professional controllers (CPCs) from TRACONs across the NAS. The Enroute positions were staffed with retired Los Angeles ARTCC (ZLA) controllers. The positions included ZLA West, ZLA South, and ZLA East. The three TRACON feeder positions were staffed with one retired Southern California TRACON (SCT) controller working the South feeder (South and North feeder were combined) and two current Federal Aviation Administration (FAA) CPCs working the ZUMA and EAST feeder positions. The TRACON final positions were staffed with two current FAA CPCs, one working DOWNE 25L and one working STADIUM 24R. VIII. Scenarios The same traffic scenario was run for every training and data run. NASA had expected to run three to four different scenarios; however, due to schedule constraints that affected scenario development, only one scenario was run. IX. Simulation Environment The TSS controller advisory tools were evaluated using the Multi-Aircraft Control System (MACS). MACS was adapted to simulate ZLA ARTCC and the Southern California TRACON (SCT) airspace and operations; specifically simulating the LAX arrivals in a West configuration landing on runway 24R and runway 25L. The air traffic lab layout consisted of five TRACON positions (three feeder positions and two final positions) and three ARTCC positions. The evaluation focused on the feeder and final controllers using the TSS tools to deliver the aircraft as close as possible to the STA, to the merge points and runway threshold. The feeder and final positions were also able to display timeline information associated with the merge points or runway threshold. Figure 4 depicts the ATC lab configuration. Figure 4. ATC Lab Configuration 7

8 X. Roles and Responsibilities of Controllers The ARTCC controller tasks were to clear the aircraft for an optimized profile descent (OPD) and expected runway (e.g., phraseology- descend-via VISTA8 arrival, expect runway 25L) and to absorb delay in order to meet the STA at the meter fix. The feeder controller tasks were to use the slot marker and speed advisories as tools to adjust an aircraft s speed to meet its STA, to assign arrival runways and to ensure proper spacing to the final controller. The final controller tasks were to clear the aircraft for the RNAV/RNP approach, to use the TSS tools to issue speeds if appropriate, to use normal approach procedures, to issue final approach clearance, and to ensure adequate spacing on the final approach. XI. Simulation and Participant Guidelines The controllers were advised of the following simulation and participant guidelines on day one of the simulation: Simulation Guidelines All aircraft have RNAV capability Aircraft on side-by-side turns to final at the same altitude are considered separated as long as they are established on the RNAV or RNP approach The TSS schedule builds in wake vortex separation and an additional three tenths of a mile buffer at the runway threshold. (The runway threshold buffer was modified during the simulation) Participant Guidelines TSS tools should be utilized during the runs with a tool-condition Instead of vectoring an aircraft, speed control is the preferred method for an aircraft to achieve its STA Speed advisories given by TSS tools should be used unless unrealistic* If aircraft are out of sequence (according to the sequence numbers displayed next to the runway assignment on the FDB) the controller can vector the aircraft, but is advised to avoid extreme measures that would compromise the scenario* Once the aircraft begins the RNP-AR procedure, it can only be slowed; A speed increase or vector command will terminate the procedure and the aircraft will have to be vectored to the instrument landing system (ILS) ARTCC controllers are advised not to swap aircraft* Aircraft are controlled by the controller on handoff Preference RNP aircraft in the arrival sequence unless there is a safety issue* There are no missed approaches; fly the runway heading If an aircraft overshoots the final approach segment, correct within the amount of operational time the controller would allow to fix the issue. Otherwise, the aircraft will be deleted in the scenario* Controller-controller coordination should be accomplished by radio communication 8

9 During the data collection runs, the participants were requested to only ask questions to and interact with their trainers. This eliminated extraneous conversations that were occurring during the training runs and provided a more focused simulation *Denotes additional simulation guidelines given throughout the week. Although the guidelines were given during the simulation in-brief, they were not reinforced throughout the week. For future simulations, it is recommended to reinforce the guidelines. Guidelines were also modified throughout the week due to controller, NASA, and subject matter expert (SME) discussions during the runs or debriefs. For example, the speed advisories were initially briefed to be only used as guides when issuing speeds, but then changed to issue the advised speeds unless unrealistic. Also, swapping in ARTCC airspace added an extra level of complexity to the basic scenarios; therefore, the ARTCC controllers were advised not to swap aircraft. XII. Data Collection From each control position, keyboard inputs into the system, schedule information, aircraft information, and responses to the post-run questionnaire were recorded. Voice-to-voice communication between pilots and controllers were also recorded. During the data runs, trainers and observers were stationed at each position to capture additional data. For example, they captured the time of the run, position observed, type of run (winds vs. no winds, tools vs. no tools), and any issues, problems, and resolutions. These observation sheets were handed in at the end of each run for post-run analysis. Debriefs usually occurred after each run, at the end of each day, and one final debrief occurred on the last day of the simulation. Once all participants completed their post run questionnaire, the participants, researchers, SMEs, and observers would gather in the ATC lab. Each position would give feedback on the run, how well the tools worked, any issues, resolutions and questions. The researchers would describe any system changes made to that specific run such as modifying the runway threshold buffer. All data is currently being analyzed. Additional results based on the controller surveys and system recordings will be provided in the upcoming weeks. Refer to section XV Results. XIII. Training A training briefing package was created and distributed to the controllers prior to the simulation. Training was divided up into two parts. The first part discussed the background and motivation to conduct this simulation. A screen shot and a description of each of the TSS tools was also included in the package. The second part of the training included four training runs on the first day of the simulation. SMEs and confederate controllers were available as trainers and proved to be very beneficial throughout the week answering operational and technical questions. A. Challenges of Implementing Training Due to schedule constraints the controllers were trained in one day on the LAX airspace, RNAV/RNP routes and procedures, phraseology, wind characteristics, display capabilities and the simulation system with and without the TSS tool advisories. In future simulations, allowing additional training and 9

10 familiarization time prior to the start of the data runs will help minimize collection of data that do not focus primarily on the tools capabilities. It is also recommended that a consistent group of current FAA air traffic controller subject matter experts (SMEs) be used to reduce the time spent training and allow for a greater number of simulation runs that would concentrate on defining the requirements needed to support an operational demonstration of TSS. The scenarios were simplistic in order to direct controller focus on the tools; therefore they did not reflect true traffic situations. As the simulations continue, increasing complexity and including a more realistic complement of traffic situations (e.g., mixed equipage aircraft) will provide a more realistic view of current actual operations. Refer to section XVII Observations and Discussions for additional information regarding mixed equipage. XIV. XV. Roles and Responsibilities of Trainers and Observers Trainers instructed the controllers on airspace, operations, phraseology, TSS tools and answered any questions posed by the controllers. If the question could not be answered, it was discussed during the following debrief. The observers documented controller feedback and observations, both positive and negative. See Section XI Data Collection for additional information regarding the responsibilities of the trainers and observers. Results As described in Section XII Data Collection, each control position, keyboard inputs into the system, schedule information, aircraft information, and responses to the post-run questionnaire, were recorded. Voice-to-voice communication between pilots and controllers was also recorded. The following variables will be analyzed for each of the ten runs: throughput, delay distribution, arrival time, off-route time, and route conformance. For example, Figure 5 and Figure 6 show the Throughput/Extra Spacing data for runs D1 and D10. Note: Additional results/graphs can be found in the TSS-1_run-10 PowerPoint, created by NASA. Figure 5. Throughput Data/Excess Spacing Data for TSS Simulation Run D1 10

11 Figure 6. Throughput/Excess Spacing Data for TSS Simulation Run D10 Below are planview display snapshots showing the overlay of all aircraft trajectories for data runs D1 and D10. As you can see in comparing Figure 7 and Figure 8, the amount of vectoring during run D1 exceeds the amount of vectoring during D10. D1 used no tools (SOP) during wind conditions and D10 used the TSS tools during wind conditions. Figure 9 and Figure 10 show the amount of vectoring during D1 and D10 in ARTCC airspace prior to TRACON handoff. Table 2 describes the simulation run conditions for both scenarios. Table 2. Simulation Run Conditions for Runs D1 and D10 Demand Run Winds Tools Runway Threshold Day Buffer 1.1 D1 Winds SOP D10 Winds TSS.3 3 Figure 7. Aircraft Trajectories in TRACON Airspace for Run D1 (No Tools and Wind Conditions) 11

12 Figure 8. Aircraft Trajectories in TRACON Airspace for Run D10 (with TSS Tools and Wind Conditions) Figure 9. Aircraft Trajectories in ARTCC Airspace for Run D1 Figure 10. Aircraft Trajectories in ARTCC Airspace for Run D10 12

13 XVI. Simulation Shakedown The following system setup characteristics, issues, guidelines and resolutions were identified during the shakedown and are captured in Table 3 for use in future simulations. This is not an all encompassing list. Table 3. System Shakedown System Setup Characteristics and Issues Sector colors are different Runway assignments were displayed during a no-tools condition Aircraft speed displayed during a notools condition Filed Route displayed during a no-tools condition Heavy Jet indicator missing Not all aircraft indicators used in this simulation are consistent with current operational indicators Aircraft speed is displayed in 3 digits instead of 2 digits Not all keystrokes used in this simulation are consistent with current operations. For example, keying range rings and handoffs. FDB does not flash for handoff. Only the sector indicator. ARTCC/TRACON airspace was rotated by 15 degrees to the right ZUMA and South Feeder flashed a sector B handoff in the FDB Slot jumps Guideline/Resolution All sectors should be a consistent color Remove runway assignments during a no-tools condition Remove display of aircraft speed in a notools condition Filed route should be displayed during a- no tools condition (Training) Indicator added Training Training Training Training Modify airspace configuration by rotating airspace 15 degrees to the left Sector B changed to correct indicator Software integration into the FAA baseline is still in transition. There was not enough time due to schedule constraints to flush out the system. XVII. Observations/Discussions During the final debrief, controllers were concerned over losing their skills or ability to scan traffic when using the TSS tools. NASA agreed that losing the scan pattern was a concern and it was made clear that these tools do not replace the controller but assist the controller in managing the merging, sequencing and spacing of traffic. In addition, CPCs voiced concern that new controllers will never achieve the needed basic skills to manage traffic if the software was to fail or conditions were such that the software was no longer usable. During the discussion it was agreed that not only will the basic controller skill set still be needed, but, basic pilot skills will still be needed when these tools are operational. 13

14 A. Timelines The timelines were available at both the feeder and final position. Based on observations, while the final controllers may have displayed the timelines, final controllers stated that the timelines were useless at the final position because meeting the schedule was no longer a concern. It was observed that the timelines were used more frequently at the feeder position than at the final position. Based on observer comments and controller feedback, the timelines were used to compare the ETA and STA to each fix, in some cases even to try and determine an upcoming slot jump. At the end of the simulation one controller stated he/she was not entirely sure how to use the timelines. It is recommended that additional training be given to controllers on the use of the timelines prior to the data runs in future simulations. B. Early/Late Indicators Observers documented and controllers commented that during multiple runs neither the early/late indicator nor a speed advisory was issued for several aircraft (over multiple runs) even though the timeline clearly showed that the aircraft s ETA and STA were not equal. The early/late indicator also seemed less useful on the final approach as there is limited airspace to make any adjustments to the aircraft. Controllers and SMEs commented that when given an early/late indicator, it was difficult to judge how much time or distance was needed to achieve an aircraft s STA and at which meter point/fix the aircraft would meet its STA. It is recommended that some type of indication, whether distancebased or fix-based, be given with the early/late indicator. This will allow the controller to know exactly at which point he or she is trying to achieve an on-time STA based on the early late indicator, or the amount of distance the controller has to maneuver the aircraft to achieve an on-time STA based on the early/late indicator. C. Slot Markers The jump in the slot markers was frustrating to controllers because they would adjust the aircraft using the speed advisories, the aircraft and slot marker would align, and then the slot marker would jump. The aircraft would then, be behind or ahead of the slot marker, despite the adjustments made by the controller before the jump. These jumps were due to the recent software integration and improvements that were made to the adaptation during the week to improve the performance of slot markers but the issue was not completely resolved. At the ZUMA position, the slot marker either jumped forward or backward on the display at VTU, SMO, FIM and SADDE fixes. A controller said he/she began to anticipate the slot jump and would either slow or accelerate an aircraft prior to the fix in order for the aircraft to meet the slot once the slot jumped. The slot jump size, however, was unpredictable and therefore, trying to adjust the speed of the aircraft to hit the slot marker, was unrealistic. As the system continues to be updated and debugged, the jump in the slot markers should subside. If this is not the case, the controllers should be made aware of the slot jumps prior to the simulation. 14

15 D. Speed Advisories At the beginning of the simulation, the controllers were advised to use the speed advisories as recommendations or guidelines only. However, that guideline was changed during the simulation and the controllers were asked to use the advised speeds unless they were unrealistic. Based on observations and feedback from controllers, the speed advisories issued were very confusing. Controllers stated that the speed advisories were erroneous as they were continually calculated and updated for the controller to communicate to the pilot. For example, the speed of the SWA4000 aircraft changed from 320kt, to 270kt, to 260kt and back to 270kt. At first the changes in the speed were not issued to the pilot, instead the controller chose the speed for the aircraft based on experience. One controller said, These same number of speed changes would never be issued in the real world. Instead the controller would issue a speed and watch the aircraft run. Later in the simulation, controllers would warn their pseudo pilot, saying, I plan to issue whatever speed the system tells me. It is going to be erratic. That being said, the number of speed advisories needs to be reduced to lessen the chance of communication errors and to help with frequency congestion, which relates to controller workload. It is recommended that only one speed advisory per aircraft be given in the en-route environment and one speed advisory be given per aircraft inside the TRACON. Controllers and the flight crew expressed concern when a speed was issued that it did not have an associated fix or merge point where the aircraft should fly the advised speed. This led to confusion because the controllers and pilots did not know when to transition to the published speed from the advised speed. It is recommended that when a speed advisory is issued, it should include a fix or merge point where the pilot is expected to resume normal speed or to begin complying with the published speeds on the Performance-Based Navigation (PBN) procedure. Controllers also stated that unrealistic speed advisories were given. For example, the SWA4000 aircraft showed a speed advisory of 270kt at 10,000 ft. Based on published procedures, an aircraft cannot be above 250kt below 10,000 ft. Two questions were continually posed by the controllers. The first question was, Why is a faster speed advised if the slot marker is trailing the aircraft? For example, the speed advisory was 260kt, the aircraft s speed was 250kt and the slot marker was trailing behind the aircraft at 280kt. The second question asked was, If the aircraft is already flying the advised speed, why is a speed issued? Unless these issues are resolved, these same questions will likely appear during the next simulation. E. RNAV/RNP Approach Routes This simulation used a traffic mix of RNP and RNAV-equipped aircraft, but did not include classic or nonequipped aircraft. Although it was important to test the technology of all RNAV equipped aircraft on defined routes, the traffic mix seemed unrealistic to the controllers and may have contributed to some of the negative comments regarding controller skills not being used. In a true mixed-equipage 15

16 environment, controller skills are going to be as important as they are today. It may have been more beneficial from an acceptance point of view to do an RNAV and non-equipped simulation prior to an RNAV/RNP simulation. Depending on the level of experience of the next controller set, it is recommended that non-equipped aircraft be entered into the scenario or have RNAV procedures that end prior to runway sequencing portions of the route. This would give a more realistic view on near term implementation strategies. F. Phraseology Phraseology cards were provided to the ZUMA feeder and EAST feeder. However, based on controller and pilot feedback as well as observations by observers and SMEs there were voice-to-voice communication errors and misunderstandings between pilots and controllers. It is recommended that additional training be given to controllers and pilots on the phraseology prior to the data runs in future simulations. G. Computer Human Interface (CHI) One of the recommendations received from the controllers was to change the color of the equipment suffix for those aircraft on RNP procedures. For this simulation, the indicator, /w was displayed to the right of the aircraft type identifying RNP/AR capable aircraft. Also, there were times when the data associated with the aircraft (in the FDB) and the slot marker overlapped and were difficult to read. It was recommended by the SMEs to manually move the FDB leader line to another location around the slot marker. The overall CHI needs to be vetted through a user team. For example, the /w indicator is a place holder for what the actual RNP/AR capable aircraft identifier will be. Without a CHI that has been accepted by the user team, it will be difficult to conduct a field demonstration with the controllers knowing that the CHI of these tools may change. Once the CHI of the RNP/AR capable aircraft is determined, procedures will need to be developed so the controllers know how to work the aircraft. It is recommended due to the timeframe involved in making changes to Enroute Automation Modernization (ERAM) and Standard Terminal Automation Replacement System (STARS) interfaces that the CHI portion of the TSS tools needs to be reviewed by a user team and accepted by the stakeholders. To continue down a path without the buy-in of the stakeholders would lead to a setback in the development of these TSS tools. H. Automated Terminal Proximity Alert (ATPA) Advisory/ TSS Speed Advisory Once an aircraft enters the ATPA region on final, the ATPA advisories are displayed on the third line of the FDB. With the current TSS tool CHI, the speed advisories are displayed on the third line of the FDB. There will need to be research dedicated to the interoperability of ATPA and TSS. Since the ATPA advisory is a safety function, the ATPA advisory may override the TSS speed advisory. However, the ATPA advisory and TSS speed advisory would need to be clearly distinct so it does not lead to controller 16

17 confusion. According to a researcher at NASA, Another huge advantage of TSS working with ATPA is that TSS could provide the planned sequence significantly before the turn to final such that the cones could be at a proper Wake Vortex length for the aircraft that they will meet on final and displayed earlier on downwind or extended base. NASA has actually run this way a few times and the final controllers really like it. XVIII. Conclusion The objective of the TSS simulation was to assess the feasibility and to evaluate the performance of the TSS controller advisory tools for the near-term NAS. Specifically, this simulation evaluated how TRACON controllers used the TSS tools to merge, sequence and space mixed-equipage aircraft in different forecasted wind conditions on RNAV/RNP-AR routes. Preliminary results based on a subset of data available from this simulation indicate that the TSS tools reduce the amount of excessive spacing on the final approach and the amount of vectoring within the TRACON airspace. By reducing the excess spacing on the final approach, there is inherently an increase in capacity and efficiency to the airport. Refer to section XV Results. By reducing the amount of vectoring within the TRACON, the noise footprint around airports, fuel consumption and green house gas emissions can also be reduced. As the research and development of these TSS tools continues, unresolved issues will be addressed, modifications will be made, and the ability to discern in greater detail the effectiveness of the TSS tools will become more apparent. Research does show a dependency on this type of technology to assist controllers with managing aircraft on PBN procedures. Without these tools, controllers will have to intervene more to maintain proper sequencing and spacing between aircraft which reduces any savings gain by the PBN procedure. XIX. Acknowledgments The authors would like to thank Michael Downs, University of California Santa Cruz and Paul MacWilliams, MITRE, for their technical contributions to the task completion report. XX. References Kupfer, M., Callantine, T., Martin, L., Mercer, J., Palmer, E., Controller Support Tools for Schedule-Based Terminal Area Operations, Ninth USA/Europe Air Traffic Management Research and Development Seminar (ATM 2011), Moffett Field, CA, Swenson, H. N., Thipphavong, J., Sadovsky, A., Chen, L., Sullivan, C., Martin, L., Design and Evaluation of the Terminal Area Precision Scheduling and Spacing System, Ninth USA/Europe Air Traffic Management Research and Development Seminar (ATM 2011), Moffett Field, CA,