June 2013 

NASA/TM−2013-216534 

Precision Departure Release Capability (PDRC) 

Concept of Operations 

Shawn A. Engelland 

Ames Research Center, Moffett Field, California 

Alan Capps and Kevin Day 

Mosaic ATM, Leesburg, Virginia 
NASA STI Program . . . in Profile

 Since its founding, NASA has been dedicated to 

the advancement of aeronautics and space science. 

The NASA scientific and technical information (STI) 

program plays a key part in helping NASA maintain 

this important role. 

 The NASA STI program operates under the 

auspices of the Agency Chief Information Officer. It 

collects, organizes, provides for archiving, and 

disseminates NASA’s STI. The NASA STI program 

provides access to the NASA Aeronautics and Space 

Database and its public interface, the NASA Technical 

Report Server, thus providing one of the largest 

collections of aeronautical and space science STI in 

the world. Results are published in both non-NASA 

channels and by NASA in the NASA STI Report 

Series, which includes the following report types: 

• TECHNICAL PUBLICATION. Reports of 

completed research or a major significant phase 

of research that present the results of NASA 

programs and include extensive data or 

theoretical analysis. Includes compilations of 

significant scientific and technical data and 

information deemed to be of continuing 

reference value. NASA counterpart of peerreviewed formal professional papers, but having 

less stringent limitations on manuscript length 

and extent of graphic presentations. 

• TECHNICAL MEMORANDUM. Scientific 

and technical findings that are preliminary or of 

specialized interest, e.g., quick release reports, 

working papers, and bibliographies that contain 

minimal annotation. Does not contain extensive 

analysis. 

• CONTRACTOR REPORT. Scientific and 

technical findings by NASA-sponsored 

contractors and grantees. 

• CONFERENCE PUBLICATION. Collected 

papers from scientific and technical 

conferences, symposia, seminars, or other 

meetings sponsored or co-sponsored by NASA. 

• SPECIAL PUBLICATION. Scientific, 

technical, or historical information from NASA 

programs, projects, and missions, often 

concerned with subjects having substantial 

public interest. 

• TECHNICAL TRANSLATION. Englishlanguage translations of foreign scientific and 

technical material pertinent to NASA’s mission. 

 Specialized services also include creating custom 

thesauri, building customized databases, and 

organizing and publishing research results. 

 For more information about the NASA STI 

program, see the following: 

• Access the NASA STI program home page at 

http://www.sti.nasa.gov

• E-mail your question via the Internet to 

help@sti.nasa.gov

• Fax your question to the NASA STI Help Desk 

at 443-757-5803 

• Phone the NASA STI Help Desk at 

443-757-5802 

• Write to: 

 NASA STI Help Desk 

 NASA Center for AeroSpace Information 

 7115 Standard Drive 

 Hanover, MD 21076-1320 
National Aeronautics and 

Space Administration 

Ames Research Center 

Moffett Field, California 94035-1000 

June 2013 

NASA/TM−2013-216534 

Precision Departure Release Capability (PDRC) 

Concept of Operations 

Shawn A. Engelland 

Ames Research Center, Moffett Field, California 

Alan Capps and Kevin Day 

Mosaic ATM, Leesburg, Virginia 
Available from: 

NASA Center for AeroSpace Information National Technical Information Service 

7115 Standard Drive 5301 Shawnee Road 

Hanover, MD 21076-1320 Alexandria, VA 22312 

This report is also available in electronic form at 

http://www.aviationsystemsdivision.arc.nasa.gov/ 
 i 

Table of Contents 

1 INTRODUCTION .................................................................................................................. 1

1.1 SCOPE ............................................................................................................................................... 1

1.2 IDENTIFICATION .............................................................................................................................. 2

1.3 DOCUMENT OVERVIEW ................................................................................................................... 2

1.4 SYSTEM OVERVIEW ......................................................................................................................... 3

2 REFERENCE DOCUMENTS ............................................................................................... 6

3 CURRENT SYSTEM ............................................................................................................. 6

3.1 BACKGROUND, OBJECTIVES, AND SCOPE ..................................................................................... 10

3.1.1 Tactical versus strategic departure scheduling .......................................................................... 10

3.1.2 Prevalence of tactical departure scheduling in the NAS ........................................................... 11

3.2 OPERATIONAL POLICIES AND CONSTRAINTS ............................................................................... 12

3.3 DESCRIPTION OF THE CURRENT SYSTEM ..................................................................................... 13

3.3.1 Inbound tactical departure scheduling capability ...................................................................... 13

3.3.2 Outbound tactical departure scheduling capability ................................................................... 14

3.3.3 Clarifying inbound vs. outbound tactical departure scheduling ................................................ 16

3.3.4 Current tactical departure scheduling process ........................................................................... 17

3.4 MODES OF OPERATION FOR THE CURRENT SYSTEM ................................................................... 17

3.5 USER CLASSES AND OTHER INVOLVED PERSONNEL .................................................................... 18

3.6 SUPPORT ENVIRONMENT ............................................................................................................... 18

4 JUSTIFICATION FOR AND NATURE OF CHANGES ................................................. 19

4.1 JUSTIFICATION FOR CHANGES ...................................................................................................... 19

4.2 DESCRIPTION OF DESIRED CHANGES ............................................................................................ 20

4.3 PRIORITIES AMONGST CHANGES .................................................................................................. 21

4.4 CHANGES CONSIDERED BUT NOT INCLUDED ................................................................................ 21

4.5 ASSUMPTIONS AND CONSTRAINTS ................................................................................................ 23

5 CONCEPTS FOR THE PROPOSED SYSTEM ................................................................ 24

5.1 BACKGROUND, OBJECTIVES, AND SCOPE ..................................................................................... 24

5.2 OPERATIONAL POLICIES AND CONSTRAINTS ............................................................................... 24

5.3 DESCRIPTION OF THE PROPOSED SYSTEM ................................................................................... 24

5.3.1 PDRC applied to tactical departure scheduling ......................................................................... 24

5.3.2 PDRC prototype software .......................................................................................................... 25

5.4 MODES OF OPERATION FOR THE PROPOSED SYSTEM .................................................................. 26

5.5 USER CLASSES AND OTHER INVOLVED PERSONNEL .................................................................... 26

5.6 SUPPORT ENVIRONMENT ............................................................................................................... 27

6 OPERATIONAL SCENARIOS .......................................................................................... 28

6.1 CFR PROCEDURE OVERVIEW ........................................................................................................ 28

6.2 CFR EVALUATION SCENARIO STEPS ............................................................................................. 29

6.2.1 CFR restriction notification ....................................................................................................... 29
ii 

6.2.2 CFR activation in SDSS ............................................................................................................ 30

6.2.3 Request for Release Time (RFRT) ............................................................................................ 30

6.2.4 Response to the Request for Release Time (RFRT) .................................................................. 32

6.2.5 Response to Scheduled Departure Time (SDT) ........................................................................ 36

6.2.6 Departure release management .................................................................................................. 38

6.2.7 Merge into overhead .................................................................................................................. 39

7 SUMMARY OF IMPACTS ................................................................................................. 41

7.1 OPERATIONAL IMPACTS ................................................................................................................ 41

7.2 ORGANIZATIONAL IMPACTS ......................................................................................................... 41

7.3 IMPACTS DURING DEVELOPMENT ................................................................................................. 41

8 ANALYSIS OF THE PROPOSED SYSTEM .................................................................... 42

8.1 SUMMARY OF IMPROVEMENTS ..................................................................................................... 42

8.2 DISADVANTAGES AND LIMITATIONS ............................................................................................. 42

8.3 ALTERNATIVES AND TRADE-OFFS CONSIDERED .......................................................................... 43

9 NOTES ................................................................................................................................... 45

APPENDIX A: RELATED NEXTGEN INITIATIVES ......................................................... 46

A.1 INTEGRATED ARRIVAL/DEPARTURE/SURFACE CONCEPT ......................................................... 46

A.2 TERMINAL FLIGHT DATA MANAGER (TFDM) ........................................................................... 46

A.3 TIME BASED FLOW MANAGEMENT (TBFM) .............................................................................. 46

A.4 INTEGRATED DEPARTURE ARRIVAL CAPABILITY (IDAC) ........................................................ 46

A.5 DEPARTURE FLOW MANAGEMENT (DFM) PROTOTYPE ............................................................ 47

A.6 SURFACE COLLABORATIVE DECISION MAKING (SURFACE CDM) ........................................... 48

A.7 COLLABORATIVE DEPARTURE QUEUE MANAGEMENT (CDQM) ............................................. 48

A.8 SPOT AND RUNWAY DEPARTURE ADVISOR (SARDA) ............................................................... 49

GLOSSARY ................................................................................................................................ 50
 iii 

List of Figures 

Figure 1:1 – PDRC supports IADS tactical departure scheduling. ................................................. 1

Figure 1:2 – Precision Departure Release Capability (PDRC) system overview. .......................... 4

Figure 3:1 – Strategic and tactical departure scheduling for January 2011. ................................. 11

Figure 3:2 – Centers using inbound tactical departure scheduling in January 2011. ................... 12

Figure 3:3 – A typical inbound tactical departure scheduling situation. ...................................... 14

Figure 3:4 – A typical outbound tactical departure scheduling situation. .................................... 15

Figure 3:5 – Clarifying “inbound” and “outbound” labels for TMA tactical departure scheduling.

....................................................................................................................................................... 16

Figure 4:1 – Tactical departure scheduling – the problem. .......................................................... 19

Figure 4:2 – Example of TMA Flow Program into Atlanta. ......................................................... 20

Figure 5:1 – PDRC applied to tactical departure scheduling. ....................................................... 25

Figure 5:2 – PDRC prototype software overview diagram. ......................................................... 26

Figure 6:1 – Center and Tower tactical departure scheduling actions with PDRC to implement 

the CFR procedure. ....................................................................................................................... 29

Figure 6:2 – Tower TMC uses SDSS user interface to request release time for AAL1001 during 

the PDRC Block 1 field evaluation. .............................................................................................. 31

Figure 6:3 – SDSS user interface indicating a pending release time request for AAL1001 during 

the PDRC Block 1 field evaluation. .............................................................................................. 32

Figure 6:4 – rTMA user interface indicating a pending release time request for AAL1001 during 

the PDRC Block 1 field evaluation. .............................................................................................. 33

Figure 6:5 – rTMA departure scheduling panel prior to Center scheduling for AAL1001 during 

the PDRC Block 1 field evaluation. .............................................................................................. 34

Figure 6:6 – rTMA departure scheduling panel after Center scheduling for AAL1001 during the 

PDRC Block 1 field evaluation. .................................................................................................... 35

Figure 6:7 – rTMA user interface after Center scheduling for AAL1001 during the PDRC Block 

1 field evaluation. .......................................................................................................................... 36

Figure 6:8 – SDSS user interface after receipt of Scheduled Departure Time from rTMA for 

AAL1001 during the PDRC Block 1 field evaluation. ................................................................. 37

Figure 6:9 – SDSS user interface 1 minute before scheduled departure time for AAL1001 during 

the PDRC Block 1 field evaluation. .............................................................................................. 39

Figure 6:10 – rTMA planview display showing overhead stream merge for AAL1001 during the 

PDRC Block 1 field evaluation. .................................................................................................... 40

List of Tables 

No table of figures entries found.

 
iv 

This page intentionally left blank. 

 
 1 

1 Introduction 

This section provides context for the PDRC-IADS research activity, a high-level overview of the 

PDRC concept and an overview of the material presented in this document. 

1.1 Scope 

Future air traffic demands are expected to require a greater degree of integration among the 

automation systems used to manage arrival, departure and surface traffic. The next generation air 

transportation system (NextGen) envisions Integrated Arrival/Departure/Surface (IADS) 

operations as described in the JPDO Integrated Work Plan [38] and in the FAA's NextGen MidTerm Concept of Operations [35]. Various NextGen concepts [28, 31, 32] describe IADS 

operations that feature a greater degree of automated coordination as traffic flows from one 

control domain to the next in the tactical air traffic control environment. 

A logical step towards the NextGen vision of fully-integrated arrival/departure/surface 

operations is to automate tactical scheduling of departure traffic that will join a constrained en 

route traffic flow as depicted in Figure 1:1, which is based on Figure 1-1 of Reference 28. 

A commonly used tactical Traffic Management Initiative (TMI) is the Call For Release (CFR) 

procedure, which is also known as the Approval Request (APREQ) procedure. CFR procedures 

vary from facility to facility; however, they generally require the Air Traffic Control Tower 

(Tower) to request approval from the Air Route Traffic Control Center (Center) prior to releasing 

departures headed to specified destinations. Earlier research [20, 21] at NASA Ames focused on 

automating inter-facility coordination during CFR procedures. An FAA-led effort built on this 

work to develop and evaluate the Departure Flow Management prototype [13]. 

Figure 1:1 – PDRC supports IADS tactical departure scheduling. 
2 

Presently, en route tactical departure scheduling to meet CFR restrictions is often accomplished 

with the Traffic Management Advisor (TMA) decision support tool. Tactical departure 

scheduling with TMA is thoroughly described in Section 0 of this document. 

The Precision Departure Release Capability (PDRC) combines the automated coordination 

demonstrated in the previous research [13, 20, 21] with the use of surface trajectory-based 

takeoff (OFF) time predictions and runway assignments to improve en route tactical departure 

scheduling during CFR procedures. 

PDRC is intended to inform development of mid-term NextGen concepts and technologies, but 

PDRC evaluations were conducted in the present-day National Airspace System (NAS) 

environment at a specific location. The scope for this document will be limited to the immediate 

PDRC-IADS research activity as follows: 

System: PDRC research software system developed for evaluations. 

Environment: North Texas (NTX) Research Station and associated FAA facilities: Fort 

Worth Center (ZFW), DFW TRACON (D10), and DFW Towers. 

Time frame: 2010–2014 for development, evaluation and transition. 

This document includes notes and comments on extending the PDRC concept to other NAS 

environments. 

1.2 Identification 

The PDRC-IADS research activity is an element of the Systems Analysis Integration and 

Evaluation (SAIE) Project of NASA’s Airspace Systems Program. The Aviation Systems 

Division at NASA Ames Research Center is conducting the PDRC-IADS research activity based 

out of NTX. Some of this research activity is being accomplished under a NASA Research 

Announcement contract (NNA11AC17C), which was awarded on 23 Sep 2011. Mosaic ATM, 

Inc. is the prime contractor for this work and CSC and Veracity Engineering are subcontractors. 

This document is a joint effort between NASA and contractor personnel. 

NASA and the FAA are coordinating NextGen technology transfer via Research Transition 

Teams (RTTs). The RTTs have defined Research Transition Products (RTPs), consisting of 

distinct concept and/or technology elements that can be transferred as a package. PDRC is one 

of four RTPs currently being coordinated by the IADS RTT. NASA delivered an initial PDRC 

RTP package to the FAA in July 2012. Formal delivery of the core PDRC RTP package is slated 

for the summer of 2013. This ConOps document will be one element of the PDRC RTP 

package. The FAA has identified the Time Based Flow Management (TBFM) Program and the 

Terminal Flight Data Manager (TFDM) Program as recipients of the PDRC RTP. 

1.3 Document overview 

This document describes the PDRC Concept of Operations. Companion documents describe the 

technology that has been developed [2] and the evaluation and analytical results [3]. 

The audience for this document includes the following: 

• The NASA PDRC-IADS team that will use this document to refine the concept 

throughout the research activity. 

• The NASA/FAA IADS RTT, which is facilitating the research transition process. 
 3 

• Other NASA NextGen researchers who may use this ConOps to coordinate research 

within NASA and with external research partners. 

• FAA NextGen implementers who may use this ConOps (and other PDRC research 

products) to inform development of IADS elements of the NextGen enterprise 

architecture. 

This document strictly follows the IEEE 1362-1998 standard [52] for concept of operations 

(ConOps) documents. IEEE 1362 was selected because it is very similar to the ConOps formats 

described in the FAA’s NAS System Engineering Manual [53] and NASA’s System Engineering 

Handbook [54]. The standard format facilitates review and use of this ConOps by both NASA 

and FAA personnel. 

The FAA’s NAS System Engineering Manual identifies three levels of concept documents (see 

section 4.4.5.2. of Reference 53) that are differentiated by scope and level of detail. Since this 

ConOps is narrowly focused on the PDRC system, it will likely be considered a concept of use 

(CONUSE) document by the FAA. 

This document is organized as follows: 

Section 1 of the document provides programmatic context, an overview of the ConOps 

document, and an overview of the proposed system. 

Section 2 of the document lists reference documents that relate to the PDRC initiative. 

Section 3 of the document describes the current system. 

Section 4 of the document provides justification for changing the current system, and a 

description of the proposed changes. 

Section 5 of the document describes the proposed system. 

Section 6 of the document details scenarios intended to demonstrate the operation of the 

proposed system and illustrate how the proposed system improves upon the current system. 

Section 7 of the document details operational and organization impacts associated with the new 

system. 

Section 8 of the document presents analyses conducted to quantify the benefits associated with 

implementing the proposed changes. It also presents those options considered and discarded. 

Section 9 of the document presents additional notes. 

Appendix A of the document describes other NextGen research and development initiatives that 

are related to PDRC. 

The Glossary at the end of the document presents a list of acronyms, and their definitions, that 

are used within the ConOps. 

1.4 System overview 

Figure 1:2 provides a high-level overview of the PDRC operational concept. This figure is 

applicable to both the outbound and inbound tactical departure scheduling situations described in 
4 

Section 3 of this document. The right side of the figure depicts departure traffic operating under 

the CFR procedure where departures must be merged into constrained en route traffic flows. The 

left side of the figure shows the PDRC decision support tools used for tactical departure 

scheduling. 

The upper portion of the figure depicts a traffic stream in the en route domain that is under a 

CFR constraint. PDRC builds on an existing tactical departure scheduling decision support tool 

used by the Center to schedule departures into this constrained overhead stream. Ascent 

modeling in the en route decision support tool enables precise time-based scheduling and deconfliction at the meter point. The modeled ascent trajectory is illustrated by the gold line in 

Figure 1:2. 

The lower portion of Figure 1:2 depicts the Tower environment where a NextGen surface 

trajectory-based decision support tool is in use. NextGen surface trajectory-based operations are 

enabled by a surface surveillance system and air carrier data sharing that provides intent and 

status information (e.g., gate assignments, estimated and actual pushback times). The surface 

trajectories computed and used by this decision support tool are represented by the blue and red 

lines in this figure. 

PDRC focuses on the automated communication and use of surface trajectory-based OFF time 

predictions and runway assignments for tactical departure scheduling in CFR situations. In 

present-day operations, OFF time prediction and communication is manual. Automated PDRC 

Figure 1:2 – Precision Departure Release Capability (PDRC) system overview. 
 5 

communication is illustrated by the double-headed arrow on the left side of Figure 1:2. The 

Center decision support tool uses surface trajectory-based OFF time predictions for departure 

scheduling and coordinates release times with the Tower surface trajectory-based decision 

support tool. The Tower tool predicts OFF times and runway assignments for use by the Center 

tool in tactical departure scheduling and coordinates release times with the Center decision tool. 

The focal point for PDRC is the OFF event in Figure 1:2 where the red trajectory joins with the 

gold trajectory on the departure runway. The Tower decision support tool computes surface 

trajectories to this point to develop OFF time estimates. The Center decision support tool 

computes ascent trajectories from this point to the merge point in the overhead stream for tactical 

departure scheduling. 
6 

2 Reference documents 

This section provides a list of references, applicable documents, and related research for the 

PDRC-IADS research activity. To facilitate document tracking, identical reference lists are 

being maintained across the PDRC-IADS document family [1, 2, and 3]. Consequently, this list 

should be treated as a bibliography of relevant documents instead of a strict list of references. 

Documents are listed by category rather than in order of citation, and some documents in the 

bibliography may not be directly referenced in this document. 

PDRC documents: 

1. Engelland, S.A., Capps, A., and Day, K., “Precision Departure Release Capability 

(PDRC) Concept of Operations,” NASA/TM-2013-216534, June 2013. 

2. Engelland, S.A., Capps, A., Day, K., Robinson, C., and Null, J.R., “Precision Departure 

Release Capability (PDRC) Technology Description,” NASA/TM-2013-216531, June 

2013. 

3. Engelland, S.A., Capps, A., Day, K., Kistler, M., Gaither, F., and Juro, G., “Precision 

Departure Release Capability (PDRC) Final Report,” NASA/TM-2013-216533, June 

2013. 

4. Engelland, S.A. and Capps, A., “Trajectory-Based Takeoff Time Predictions Applied to 

Tactical Departure Scheduling: Concept Description, System Design, and Initial 

Observations,” AIAA-2011-6875, 11th AIAA Aviation Technology, Integration, and 

Operations (ATIO) Conference, Virginia Beach, VA, September 20–22, 2011. 

5. Capps, A. and Engelland, S.A., “Characterization of Tactical Departure Scheduling in the 

National Airspace System,” AIAA-2011-6835, 11th AIAA Aviation Technology, 

Integration, and Operations (ATIO) Conference, Virginia Beach, VA, September 20–22, 

2011. 

6. Capps, A., Day, K., Walenciak, E., and Engelland, S.A., “Impact of Departure Prediction 

Uncertainty on Tactical Departure Scheduling System Performance,” AIAA-2012-5674, 

12th AIAA Aviation Technology, Integration, and Operations (ATIO) Conference, 

Indianapolis, IN, September 17–19, 2012. 

Research and technical papers: 

7. Atkins, S., Jung, Y., Brinton, C., Stell, L., and Rogowski, S., “Surface Management 

System Field Trial Results,” AIAA 2004-6241, 4th AIAA Aviation Technology, 

Integration, and Operations (ATIO) Forum, Chicago, Illinois, September 20–22, 2004. 

8. Brinton, C., Lent, S., and Provan, C., “Field Test Results of Collaborative Departure 

Queue Management,” 29th Digital Avionics Systems Conference, Salt Lake City, Utah, 

October 3–7, 2010. 

9. Cook, L., Atkins, S., and Jung Y., “Improved Prediction of Gate Departure Times Using 

Pre-Departure Events,” AIAA 2008-8919, 26th Congress of International Council of the 

Aeronautical Sciences (ICAS) including the 8th AIAA Aviation Technology, Integration, 

and Operations (ATIO) Conference, Anchorage, AK, September 14–19, 2008. 

10. Coppenbarger, R., Dyer, G., Hayashi, M., Lanier, R., Stell, L., Sweet, D., “Development 

and Testing of Automation for Efficient Arrivals in Constrained Airspace,” 27th 
 7 

International Congress of the Aeronautical Sciences (ICAS), Nice, France, September 

19–24, 2010. 

11. de Jonge, H., Tuinstra, E., and Seljée, R., “Outbound Punctuality Sequencing by 

Collaborative Departure Planning,” 6th USA/Europe ATM 2005 Seminar, Baltimore, 

Maryland, June 2005. 

12. de Jonge, H., Tuinstra, E., and Seljée, R., “Outbound Punctuality Sequencing by 

Collaborative Planning,” NLR-TP-2005-013, National Aerospace Laboratory of the 

Netherlands (NLR), July 2005. 

13. Doble, N., Timmerman, J., Carniol, T., Klopfenstein, M., Tanino, M., and Sud, V., 

“Linking Traffic Management to the Airport Surface: Departure Flow Management and 

Beyond,” Eighth USA/Europe Air Traffic Management Research and Development 

Seminar (ATM2009), Napa, CA, June 29 – July 2, 2009. 

14. Farley, T. C., Landry, S. J., Hoang, T., Nickelson, M., Levin, K. M., Rowe, D., and 

Welch, J. D., "Multi-Center Traffic Management Advisor: Operational Test Results," 

AIAA-2005-7300, 5th AIAA Aviation Technology, Integration, and Operations (ATIO) 

Conference, Arlington, VA, September 26–28, 2005. 

15. Futato, S., McMillan, K., Callon, S., “TMA En Route Departure Capability Jacksonville 

ARTCC and Orlando ATCT Usage Data”, April 8, 2008. 

16. Grabbe, S., “Traffic Management Advisor Flow Programs: an Atlanta Case Study”, AIAA 

Guidance, Navigation, and Control Conference, Portland, Oregon, August 8–11, 2011. 

17. Hoang, T., Jung, Y., Holbrook, J., and Malik, W., “Tower Controllers’ Assessment of the 

Spot and Runway Departure Advisor (SARDA) Concept,” 9th USA/Europe ATM R&D 

Seminar (ATM2011), Berlin, Germany, June 14–17, 2011. 

18. Jung, Y. C., and Isaacson, D. R., "Design Concept and Development Plan of the Expedite 

Departure Path (EDP)," AIAA Aircraft Technology, Integration, and Operations (ATIO) 

Conference, Los Angeles, CA, October 1–3, 2002. 

19. Jung, Y., and Monroe, G., “Development of Surface Management System Integrated with 

CTAS Arrival Tool,” AIAA 2005-7334, 5th AIAA Aviation Technology, Integration, and 

Operations (ATIO) Conference, Arlington, Virginia, September 26–28, 2005. 

20. Kopardekar, P., Green, S., Brinkman, C., Thompson, P., Evans, M., and Davis, D., 

“Making Internal Departure Release Operations More Efficient,” AIAA 2004-6346, 4th

AIAA Aircraft Technology, Integration, and Operations (ATIO) Forum, Chicago, Illinois, 

September 20–22, 2004. 

21. Kopardekar, P., Green, S., and Thompson, P. “Improving Efficiency of Departure 

Release Communications for En Route Overhead Traffic Flow Management,” 23rd

Digital Avionics Systems Conference, Salt Lake City, Utah, October 24–28, 2004. 

22. Krozel, J., Rosman, D., and Grabbe, S., “Analysis Of En Route Sector Demand Error 

Sources”, AIAA-2002-5016, AIAA Guidance, Navigation, and Control Conference and 

Exhibit, Monterey, California, August 5–8, 2002. 

23. Landry, S. J., and Villanueva, A., AIAA-2007-7713, “Mitigating the Effect of Demand 

Uncertainty Due to Departures in a National Time-Based Metering System”. 7th AIAA 

Aviation Technology, Integration, and Operations (ATIO) Technical Forum, Belfast, 

Northern Ireland, September 18–20, 2007. 
8 

24. Palopo, K., Lee, H, and Chatterji, G., “Benefit Assessment of the Precision Departure 

Release Capability Concept”, 11th AIAA Aviation Technology, Integration, and 

Operations (ATIO) Conference, Virginia Beach, VA., September 20–22, 2011. 

25. Stein, B., Ceniccola, D., and Vincent, D., “TBFM Coupled Scheduling,” 56th Annual 

ATCA Conference and Exposition, National Harbor, Maryland, October 2–5, 2011. 

26. Swenson, H. N., Hoang, T., Engelland, S., Vincent, D., Sanders, T., Sanford, B., and 

Heere, K., “Design and Operational Evaluation of the Traffic Management Advisor at the 

Ft. Worth Air Route Traffic Control Center,” First USA/Europe Air Traffic Management 

R&D Seminar, Saclay, France, June 1997. 

27. Thipphavong, J., and Landry, S. J., “Effects of the uncertainty of departures on multicenter traffic management advisor scheduling.”, AIAA-2005-7301, 5th AIAA Aviation 

Technology, Integration, and Operations (ATIO) Technical Forum, Arlington, VA., 

September 26–28, 2005. 

Related NextGen initiatives: 

28. MITRE CAASD MTR110240R1 A Concept for Integrated Arrival, Departure, and 

Surface (IADS) Operations for the Mid-Term, January 2012. 

29. MITRE CAASD MTR100349R1 A Functional Analysis of Integrated Arrival, Departure, 

and Surface (IADS) Operations, March 2012. 

30. MITRE CAASD MTR110156R1 Integrated Arrival, Departure, and Surface (IADS): 

Research Gaps and Recommendations, January 2012. 

31. MITRE CAASD MP090230 Surface Trajectory-Based Operations (STBO) Mid-Term 

Concept of Operations Overview and Scenarios, September 2009. 

32. MITRE CAASD MP090169 A Mid-Term Concept of Operations for a Tower Flight Data 

Manager (TFDM), September 2009. 

33. FAA ATO System Operations Services, Operational Concept for Departure Flow 

Management, June 29, 2007. 

34. FAA ATO Surface Operations Office, U.S. Airport Surface Collaborative Decision 

Making (CDM) Concept of Operations (ConOps) in the Near-Term – Application of 

Surface CDM at United States Airports, June 15, 2012. 

35. FAA, “NextGen Mid-Term Concept of Operations for the National Airspace System,” 

version 2.1, September 2010. 

36. DFM System Requirements, Version 1.0, September 15, 2008. 

37. FAA System Wide Information Management (SWIM) http://www.swim.gov/ 

38. JPDO, “Integrated Work Plan for the Next Generation Air Transportation System,” 

version FY13, http://jpe.jpdo.gov/ee/request/home

Software documents, specifications and standards: 

39. FAA NOTICE N JO 7110.612 amends FAA Order JO 7110.65 concerning Traffic 

Management Advisor (TMA) Departure Restrictions, Clearance Void Times, Hold for 

Release, and Release Times, January 30, 2013, 

http://www.faa.gov/documentLibrary/media/Notice/N7110.612.pdf 

40. TMA/EDC System/Subsystem Design Description, September 2008. 
 9 

41. Computer Sciences Corporation, “Traffic Management Advisor (TMA) Interface Control 

Document (ICD) for the TMA Collaborative Arrival Planning (CAP) Tool,” Contract No. 

DTFA03-02-D-00001, May 31, 2007. 

42. FAA ICD NAS-IC-82392403-04, TMA CAP to Volpe's TMA Collector ICD. 

43. VNTSC-TFM-07-01, ICD: Flow of TMA Data from Volpe to CDM Participants, V1.6 

Draft A. 

44. Raytheon, “CTO-05 Surface Management System, CTOD 5-24-1 Final Report,” 2004. 

45. Louisville SMS User’s Guide, Version 7.0, October 16, 2006. 

46. FAA IRD NAS-IR-XXXXX, NextGen Surface Prototype System (NSPS) Tactical 

Surface Data Exchange (TSDE) Interface Requirements Document (IRD), draft version 

5.1, January 3, 2013. 

47. FAA ConUse, Flight Operator Surface Application (FOSA) Concept of Use, version 1.0, 

November 30, 2010, draft. 

48. FOSA API Overview, Version 1.0, undated. 

49. Surface Operations Data Analysis and Adaptation (SODAA) User’s Guide, Version 

2.10.0, April 30, 2013. 

50. ISO 8601, Data Elements and Interchange Formats - Representation of Dates and Times, 

2004. 

51. RFC 2616, Hypertext Transport Protocol -- HTTP/1.1, June 1999. 

52. IEEE-STD 1362-1998, Guide for Information Technology, System Definition – Concept 

of Operations, 1998. 

53. FAA, National Airspace System (NAS) System Engineering Manual, Version 3.1, June 6, 

2006. 

54. NASA SP-2007-6105, Systems Engineering Handbook, Rev 1, December 2007. 
10 

3 Current system 

The PDRC system addresses shortfalls in present-day tactical departure scheduling situations. 

This section defines tactical departure scheduling and describes how it is accomplished today in 

the NAS. 

3.1 Background, objectives, and scope 

Tactical departure scheduling is a process used by Traffic Management Coordinators (TMCs) to 

regulate air traffic flow to eliminate local demand/capacity imbalances and meet requirements of 

local traffic management initiatives (TMIs). Tactical departure scheduling is not required during 

normal NAS operations, as the airspace into which the flight is being released generally has 

sufficient capacity to accommodate the departure. However, during periods of high demand or 

low capacity for the airspace being scheduled into, tactical departure scheduling may then be 

utilized. 

3.1.1 Tactical versus strategic departure scheduling 

While a significant amount of literature exists on strategic departure scheduling in the NAS, 

information on the tactical departure scheduling process is quite limited. Thus, a NAS-wide 

analysis of departure scheduling operations [5] was first performed by the PDRC research team. 

Tactical and strategic departure scheduling processes are distinct from one another and are 

currently not directly integrated. Tactical departure scheduling is distinguished from strategic 

departure scheduling based upon scope (both temporal and geographic), precision requirements, 

and the decision support tools used [5]. Strategic departure scheduling primarily uses the Traffic 

Flow Management (TFM) tool suite, while tactical departure scheduling is typically 

accomplished with the Traffic Management Advisor (TMA) decision support tool [26]. 

A significant difference between tactical and strategic departure scheduling is the scope of the 

initiative. Strategic departure scheduling is focused on correcting large demand/capacity 

imbalances that exist in the NAS, usually due to convective weather or high demand. This often 

requires significant delays over an extended period of time, which may be assigned hours in 

advance of the affected aircraft’s departure time. In contrast, tactical departure scheduling 

focuses on a specific air traffic flow that is subject to a local traffic management initiative (like 

Miles in Trail or Adjacent Center Metering), and generally introduces small delays to specific 

aircraft on an as-needed basis. Tactical departure schedules are able to consider the latest 

airspace conditions minutes before takeoff. 

Tactical departure scheduling system delays are approximately 4 minutes per aircraft, on 

average, with a median of 1 minute. This delay is significantly lower than TFM delays, with 

approximately a 66 minute average and a 52 minute median delay. These statistics are derived 

from January 2011 NAS operational data [5]. 

The study of January 2011 NAS operational data also examined the relative frequency of tactical 

and strategic departure scheduling. Figure 3:1 uses the large gray ellipse to depict the entire set 

of domestic flights in the NAS (more than 1 million) for that month. Departures subject to 

strategic traffic management initiatives are shown in the orange ellipse. Tactical departures are 

shown in the 3 green ellipses. There were approximately 3.5 times as many tactical departures as 

strategic departures in January 2011. 
 11 

The results shown in Figure 3:1 distinguish between inbound and outbound tactical departures. 

These two types of tactical departure scheduling are described in detail in Section 3.3. Inbound 

is associated with TMA arrival metering and outbound is associated with TMA’s En Route 

Departure Capability (EDC) function. 

For this analysis, an aircraft was counted as being tactically scheduled only if the aircraft was 

both scheduled and ‘accepted’ or ‘frozen’ into the TMA Arrival or EDC system. A significant 

number of aircraft (approximately 18,489 during January, 2011) were initially scheduled in the 

TMA system, but the scheduling process was not finalized by either “accepting” or “freezing” it. 

This suggests an even larger pool of tactical departure operations may exist. 

It is worth noting that inbound tactical departure scheduling occurred about five times more 

frequently than outbound tactical departure scheduling in January 2011 operations. 

3.1.2 Prevalence of tactical departure scheduling in the NAS 

Analysis of NAS operational data also provided insights into the prevalence of tactical departure 

scheduling. Reference 5 notes that TMA’s EDC function is deployed to all 20 Centers. Data 

presented in Figure 4 of that paper indicate that EDC is commonly used for outbound tactical 

departure scheduling at about half of the Centers. 

As described in Reference 4, inbound tactical departure scheduling is largely dependent on TMA 

adjacent center metering infrastructure. Figure 3:2 presents an overview of inbound tactical 

departure scheduling operations. The base image, courtesy of the FAA, depicts TMA adjacent 

center metering installations in the NAS as of March 2010. The base image shows the 20 Centers 

as green “puzzle piece” polygons. 

Figure 3:1 – Strategic and tactical departure scheduling for January 2011. 
12 

Operational TMA data were analyzed [5] to identify sites where inbound tactical departure 

scheduling operations occur. The survey results are plotted in Figure 3:2 as overlay symbols. 

The Centers conducting inbound tactical departure scheduling have been labeled with round 

yellow “O” and square orange “D” symbols. The “O” label indicates Centers that schedule their 

departures into the arrival TMA system of one or more adjacent Centers. The “D” label identifies 

Centers that permit adjacent facilities to schedule departures into their arrival TMA system. The 

one “O” label in the northeast that is not associated with a Center represents the inbound tactical 

departure scheduling from Nav Canada to New York Center (ZNY). Figure 3:2 shows that 18 

Centers (plus Nav Canada) schedule departures into another Center’s TMA system, while 10 

Centers receive inbound tactical departure schedules from other facilities. 

3.2 Operational policies and constraints 

Tactical departure scheduling is not required during normal NAS operations. It is predominantly 

used when tactical restrictions on the airspace have been imposed. A common TMI requires the 

use of the CFR procedure, also known as the Approval Request (APREQ) procedure. CFR 

procedures are used to address local demand/capacity imbalances and ensure local traffic 

management initiatives are satisfied. Note that the locally implemented CFR procedure may be 

in response to a constraint that is propagated from elsewhere in the NAS. 

CFR procedures vary from facility to facility; however, they generally require the Tower 

personnel to call the Center for a scheduled departure time, prior to releasing the aircraft for 

departure. The CFR procedure is applied to departing aircraft in order to ensure the demand 

Figure 3:2 – Centers using inbound tactical departure scheduling in January 2011. 
 13 

placed on local airspace resources en route to or at the destination airport does not exceed the 

available capacity. The CFR procedure may be applied in both the outbound and inbound tactical 

departure scheduling modes. 

In a CFR scenario, it may or may not be necessary to delay the aircraft based upon the latest 

information available on the constrained flow at the time that an aircraft is ready to depart. The 

improved departure time compliance associated with the CFR procedure provides more accurate 

schedule predictions than are available via the aircraft’s filed flight plan departure time (also 

known as Predicted Departure Time, or PTIME), or via Expect Departure Clearance Times 

(EDCTs). EDCTs are generated by TFM as a part of the strategic departure scheduling system 

and are not intended for tactical use. Aircraft PTIMEs represent a starting point from which the 

departure planning process can begin, but are historically prone to OFF time uncertainty [23, 27]. 

The required departure compliance window for CFR aircraft has also varied somewhat by 

facility. Many facilities, including ZFW and DFW, have employed a –2/+1 minute compliance 

window for CFR operations. A recent FAA Notice [39] has established the –2/+1 window as a 

national standard for TMA operations by amending FAA 7110.65 standing order to read “when 

CFR is in effect, release aircraft so they are airborne within a window that extends from 2 

minutes prior and ends 1 minute after the assigned time, unless otherwise coordinated.” The 

compliance window is biased to favor early departures because it is easier to slow an early 

departure to fit into a slot than it is to accelerate a late departure. 

3.3 Description of the current system 

As noted above, the TMA decision support tool includes two distinct modes for tactical 

departure scheduling: inbound scheduling of departures into an arrival stream of a TMA-metered 

airport, and outbound scheduling of departures from an airport within the departure Center to a 

remote Center. 

Examples of inbound and outbound tactical departure scheduling situations are presented in the 

following subsections. These descriptions use real-world situations to illustrate how the tactical 

departure scheduling modes are implemented today. The examples feature ZFW and DFW 

because this is the locale for the initial PDRC field evaluations. However, these situations are 

representative of current tactical departure scheduling situations found throughout the NAS. 

3.3.1 Inbound tactical departure scheduling capability 

Inbound tactical departure scheduling uses the TMA arrival metering “internal departure” 

function to schedule departures into the inbound arrival streams of a TMA-metered airport. 

These inbound departures may originate from the TMA system’s home Center, another Center, 

or even other countries (e.g., Canadian flights scheduled into New York Center’s TMA system 

via the international TFM interface). 

Figure 3:3 shows an example of an inbound tactical departure scheduling situation. In this case, 

the green arrows show various traffic streams destined to Houston’s George Bush 

Intercontinental Airport (IAH). These streams pass through ZFW airspace and converge at the 

TORNN meter arc (73nm radial distance northwest from the RIICE fix), which is situated at the 

southern boundary of ZFW. In TMA terminology, the TORNN arc is an “outer metering arc.” 

TMA distributes the delay an aircraft must absorb to various meter reference points (i.e., 

metering arcs and fixes) situated along the arrival path. Metering at the TORNN arc is actually 

performed by ZFW controllers prior to departure, using information provided by the ZHU TMA 
14 

system via the adjacent center metering infrastructure. As part of the scheduling process, a 

release time is computed for the DFW departure and communicated to the Tower via the CFR 

procedure. Given that DFW resides within the IAH metering freeze horizon and there is limited 

airspace available to maneuver after departure prior to the outer meter arc, a high level of 

departure prediction accuracy is required. 

Note that not all inbound tactical departure scheduling is from an adjacent center. For instance, 

Indianapolis Center schedules into New York Center, although the two Centers do not share a 

boundary. Another unique case occurs when aircraft departing Canadian airspace are managed 

via CFR into New York Center airspace. 

3.3.2 Outbound tactical departure scheduling capability 

Outbound tactical departure scheduling uses TMA’s EDC function to tactically schedule flights 

departing from airports within the TMA system’s home Center outbound into constrained enroute streams or airspace. Whether the flight’s destination is in the adjacent Center or across the 

country, this situation is considered tactical because EDC is being used to address local 

demand/capacity imbalances and because scheduling is to a meter point in the home Center. 

The EDC system design re-uses a number of common components of the arrival TMA system, 

such as its adaptation data structure, route processing algorithms, and trajectory generation 

functions. While many of the core components of TMA have been leveraged to provide EDC 

capability, there are notable differences between arrival TMA and the EDC system. 

The EDC system serves a different traffic management objective than the arrival TMA system. 

EDC’s focus is outbound tactical departures leaving from one or more of the airports within a 

Center that are destined to a remote Center facility. In contrast, the tactical departure scheduling 

Figure 3:3 – A typical inbound tactical departure scheduling situation. 
 15 

capability in the arrival TMA system is only focused on aircraft that are scheduled into its 

metered airports. EDC is commonly used to assist in the application of miles in trail restrictions 

between facilities, especially when the airspace being scheduled into is highly constrained or has 

multiple miles in trail initiatives to satisfy. An additional use of EDC is to assist in regulating 

departures into sectors that are experiencing high demand. In contrast, arrival TMA use is 

primarily motivated by the traffic volume in the arrival streams entering the metered airport 

rather than by sector loading considerations. 

Figure 3:4 shows an example of an outbound tactical departure scheduling situation. The figure 

depicts the southeastern portion of the United States. State boundaries are shown in grey while 

Center boundaries are shown in purple. The green arrows depict a cross-country, overhead traffic 

stream destined to Atlanta’s Hartsfield-Jackson International Airport (ATL). The overhead 

stream transits ZFW airspace, crossing directly over DFW, and continues to ATL via the 

Meridian (MEI) fix. The gold arrow depicts the ascending flight of a DFW departure that must 

merge with the overhead stream of ATL-bound traffic. 

The DFW departures merge with the overhead stream at the MEI arc (155 nmi radial distance 

west from the MEI fix) located on the extreme eastern edge of ZFW. This arc serves as a meter 

reference point for TMA’s EDC function. TMA EDC uses four-dimensional (4D) trajectory 

synthesis, including aircraft performance models and current forecast winds, to calculate an OFF 

time that will enable the aircraft to rendezvous with the identified slot at the meter point. 

The ATL flow shown here represents a fairly common CFR situation for ZFW. However, ZFW 

uses EDC for outbound tactical departure scheduling to Houston-area airports approximately 

four times more often than for ATL. 

Figure 3:4 – A typical outbound tactical departure scheduling situation. 
16 

3.3.3 Clarifying inbound vs. outbound tactical departure scheduling 

The inbound and outbound labels were coined to address confusion associated with the two 

distinct departure scheduling functions in TMA. The TMA EDC function is clearly identified as 

a departure capability; however, it is currently used about 5 times less frequently than arrival 

TMA’s “internal departure” scheduling function. The situation is even more confusing when one 

considers that arrival TMA “internal departures” are now frequently external to the home Center 

with the widespread deployment of adjacent center metering. 

The inbound and outbound labels are referenced to the TMA system being used for departure 

scheduling. Thus, it is important to have a clear mental picture how TMA is used for tactical 

departure scheduling in the present-day NAS. Figure 3:5 depicts both inbound and outbound

tactical departure scheduling applied to the same constrained overhead stream. 

Figure 3:5 shares common image elements with Figure 1:2, Figure 3:3, and Figure 3:4. The 

tactical departure trajectory is shown in gold and joins the constrained overhead flow at a meter 

point shown in red. The departure airport is on the left located inside the departure Center shown 

in blue. The arrival airport is on the right, located inside the arrival Center, shown in green. 

The constrained overhead stream is shown flowing from left to right from the blue Center to the 

green Center, where the stream becomes an arrival flow to the airport on the right side of the 

figure. Two separate TMA systems are depicted by timeline user interface icons with “Center 

DST” labels. 

Consider first the outbound tactical departure scenario. In this case traffic managers at the blue 

Center would use the blue TMA/EDC system to schedule CFR departures from the airport on the 

left into the constrained overhead stream. The traffic managers are using their own TMA/EDC 

system to schedule traffic outbound from their own Center. In this case, the constrained 

overhead flow happens to be an arrival stream for an airport in the adjacent Center, but it is 

treated like any other outbound flow for scheduling purposes. 

Figure 3:5 – Clarifying “inbound” and “outbound” labels for TMA tactical

departure scheduling. 
 17 

Now consider the inbound tactical departure scenario. In this case, the departure from the 

airport on the left is scheduled into the green TMA system, which is being used by the green 

Center to meter the arrival stream to the airport on the right. The CFR call and tactical departure 

scheduling action is most likely being performed by traffic managers in the blue Center using an 

interface to the green Center TMA system. Thus, the blue Center traffic managers are using the 

green Center TMA system to schedule traffic inbound to the airport on the right. 

The situation depicted in Figure 3:5 is a common occurrence. Consider the blue Center to be 

ZFW and the green Center to be ZHU with the arrival airport on the right being IAH. Some days 

ZHU will meter arrival flows to IAH and ZFW traffic managers will follow the inbound tactical 

departure scheduling process for those flow. On other days, ZHU will use a MIT restriction on 

the IAH flows and ZFW traffic managers will manage departures with the outbound process. 

3.3.4 Current tactical departure scheduling process 

Current tactical departure scheduling procedures in place at DFW during a Call for Release 

restriction require increased communication/coordination between the controllers. The process is 

as follows: 

1. Center calls the Towers to notify of the Call For Release restriction. 

2. The Tower enters the restriction in the currently available coordination tool (e.g., 

Integrated Display System #5) 

3. Tower TMC and/or other personnel (e.g., frontline manager) monitor all flights as they 

become ready for departure to determine if they are subject to the call for release 

restriction. 

4. When an aircraft subject to Call For Release becomes ready for departure, the TMC calls 

the Center and requests a release time. 

5. Center types the manually communicated time in their automation tool, which provides a 

departure time that incorporates any required delay to fit into the overhead stream. The 

resulting time is communicated back to the Tower TMC in the form of a Call For Release 

window. 

6. Tower evaluates the situation on the airport surface and determines if the Call For 

Release time can or cannot be met. If the TMC believes the time is feasible then it is 

communicated to local controller. If not, then a new time is negotiated between Center 

and the Tower. 

Any holding of the flight due to the CFR will occur in the departure queue or at the runway 

threshold. 

3.4 Modes of operation for the current system 

The NASA PDRC-IADS research team has observed the FAA operational tactical departure 

scheduling system operating in the following modes: 

• Operational (i.e., operational system nominal use) 

• Maintenance (i.e., support string utilization) 
18 

3.5 User classes and other involved personnel 

The scope of this ConOps is specifically limited to the field evaluation environment for the 

PDRC-IADS research activity (i.e., NTX, ZFW, D10, and DFW). FAA recipients of this 

ConOps should be able to extrapolate the comments to other operational environments. 

Users of the current system include 

• ZFW Center TMCs and STMCs 

• D10 TRACON TMCs and STMCs 

• DFW Tower TMCs, STMCs and FLMs 

3.6 Support environment 

The NASA PDRC-IADS research team has observed the following support environment 

elements for the FAA operational tactical departure scheduling system: 

• ZFW TMA support string hardware in use 

• ZFW TMCs and STMCs testing new releases and modifying system configuration 

• ZFW, D10, and DFW TechOps personnel providing hardware support 

• ZFW AOS personnel providing adaptation support 

• WJHTC second level support personnel providing various support 

• TMA National Team providing oversight and support 
 19 

4 Justification for and nature of changes 

This section describes the shortcomings of present-day tactical departure scheduling operations 

and describes the desired changes. 

4.1 Justification for changes 

The underlying problem that motivates this research is that of an aircraft departing from the 

airport surface into a constrained flow, like that illustrated in Figure 4:1. The primary challenge 

associated with present-day tactical departure scheduling is that OFF time predictions used in 

this process are manually estimated and coordinated. 

The anticipated PDRC benefits include 

• Reduced tactical departure scheduling uncertainty, which will result in 

o More reliable departure meter point times 

o More efficient departure metering operations 

o Fewer missed and/or spoiled departure slots 

o Tighter tolerances for departure scheduling 

• Ready identification of aircraft that require no action to meet CFR constraints, thus 

reducing inter-facility coordination requirements 

• Dynamic alerts providing advance notice when aircraft will be unable to meet scheduled 

OFF time due to changes in the surface traffic situation 

• Reduced workload due to automatic computation of OFF time predictions and automatic 

communication between surface and en route automation systems 

Analysis of the current system’s performance indicates that significant room for improvement 

exists by reducing departure time uncertainty and manual coordination. NAS-wide operational 

Figure 4:1 – Tactical departure scheduling – the problem. 
20 

data analysis for January 2011[5] showed nearly 6,800 inbound tactically scheduled aircraft and 

more than 1,900 outbound tactically scheduled aircraft that are estimated to have missed the 

airspace slot they were scheduled into because of departure time prediction uncertainty. The 

effect to the NAS of a missed scheduled departure slot often leads directly to lost capacity, most 

notably in the case in which an aircraft is scheduled as frozen into an arrival TMA slot but does 

not meet its expected departure time window. Measuring the impact to the NAS of a missed 

departure slot is not straight forward, as some ability to recover the airspace resource exists, but 

generally at a cost. 

An additional shortfall of the current inbound system occurs when the tactical departure delays 

become very large. This situation may require Air Traffic Control System Command Center 

(ATCSCC) involvement. When high, tactically-assigned ground delay occurs in the NAS, the 

ATCSCC may choose to implement an Airspace Flow Program (AFP) to regulate the flow of 

aircraft into the destination airport, with the objective of reducing the TMA-assigned surface 

delays. The AFP scheduling scenario used for this purpose is unique in that it is designed to work 

in conjunction with the arrival TMA system; hence, it is called a TMA Flow Program (TFP). 

The objectives of a TFP are to pre-condition the arrival stream such that TMA can utilize 

available space in the stream for tactical departure scheduling purposes. The boundaries of the 

TFP are set to be roughly contiguous with the arrival metering system’s freeze horizon and any 

airport with departures inside of this boundary are exempt from the program. Using a TFP, the 

TFM suite of tools assigns a ground delay to aircraft bound for the metered airport that are 

located outside of the red circle shown in Figure 4:2, while TMA assigns a tactical ground delay 

(and potentially airborne delay, depending on the TMC selection) for those aircraft bound to the 

metered airport located within the red circle [16]. 

4.2 Description of desired changes 

The following changes were required for the PDRC field evaluations: 

Figure 4:2 – Example of TMA Flow Program into Atlanta. 
 21 

• Develop a research version of the operational FAA TMA/EDC system (called Research 

TMA [rTMA]) 

• Update NASA’s Surface Management System (SMS) research tool to incorporate the 

latest FAA SDSS enhancements 

• Develop a two-way interface and enhance rTMA and SDSS to enable automatic 

communication and use of SDSS trajectory-based OFF time predictions in rTMA 

departure schedule computations 

• Integrate PDRC components (rTMA and SDSS) in the NTX environment 

All of these changes have been accomplished, and the components utilized during shadow and 

operational evaluations. A detailed description of the required changes can be found in the 

companion Technology Description document [2]. 

4.3 Priorities amongst changes 

Essential changes required to the system to enact the change in operations described are 

explained in detail in the program level requirements in the Technology Description document 

[2], as well as how the PDRC team met those requirements. 

Determining priorities amongst optional features is likely best left to FAA personnel that will 

implement these changes in their native systems (e.g., TBFM and TFDM). As an example, user 

interface improvements were lower priority to the PDRC research team than ensuring the core 

data interfaces and algorithms were properly functioning. However, the FAA may have a 

different priority amongst changes. 

4.4 Changes considered but not included 

This section summarizes ideas that have been considered but not included in the PDRC system. 

A number of potential capabilities for PDRC were not pursued due to the emphasis on realizing 

near-term benefits. Other capabilities were not considered due to resource limitations or the 

relative immaturity of certain research areas. Some of the potential changes are already planned 

for implementation in PDRC follow-on research. Changes that could fit into the near-term scope 

of PDRC that were considered but not included were as follows: 

• Initiate a call for release from the TMA/EDC data that is being passed to the surface 

system rather than requiring the surface user to enter it manually 

• Re-evaluate the use of color coding of surface flight status on minutes-level precision 

now that seconds-level precision is in use 

• Allow for an APREQ and/or EDCT aircraft to be placed on the timeline at their 

scheduled time rather than un-delayed OFF time 

• Improve communication and setup of APREQs in the surface system to address 

situations where turboprops should be included (inbound scenario) versus situations 

where turboprops should be excluded (outbound scenario) 

• Handle ‘flight stubbing’ data from carrier so that these flights match filed flight plans 
22 

• Pass along the route 10b information available to rTMA and process it within the 

surface system to allow for improved departure fix mapping 

• Limit the runways available for selection on the surface system to those in the current 

airport configuration 

• Allow more options for color coding aircraft on the surface display based upon flight 

characteristics (e.g., aircraft has APREQ) 

• Change aircraft symbol on surface display (FAA request) 

• Dynamically change an aircraft's data tag values as the flight progresses; for example, 

initially show the parking gate while parked, then switch to the estimated spot after 

OUT, then switch to the estimated RWY after entering the AMA, and then, after OFF, 

switch to the departure fix (FAA request) 

• Provide a “what if” capability that allows the user to adjust the state for an individual 

aircraft and then elect to either apply the new state or reset back to the saved state (FAA 

request) 

• Enable a “Bulk Move,” a bulk aircraft runway swap capability. Aircraft destined for 

particular, multiple selectable, departure fixes could be selected in addition to a 

particular runway. For example using the D10 south gate, aircraft destined to be over 

NELYN, JASPA, ARDIA, could be moved while leaving DARTZ aircraft alone. These 

moves would be temporally selected. It was also suggested that when moving aircraft 

from one side to the other that default east/west runways be set (by flow direction) so as 

to further simplify the move. (FAA request) 

• Enable Drag and Drop. This enhancement, requested by a D10/DFW STMC, would 

make it possible to drag and drop aircraft on a timeline. This came up in the context of 

airport runway balancing using SDSS as a pre-departure planning tool. In addition, 

enable drag and drop on rTMA with surface data (FAA request) 

• Display TMA data on SDSS timelines; this is part of a general request to allow greater 

visibility of TMA’s predictions in the overhead stream on the surface display 

• Enable airline interface ‘daisy chain’ ability 

• Improve PDRC’s data feed robustness 

• Improve handling of an aircraft with both an APREQ and EDCT 

• Improve ‘suspend’ logic handling 

• Obtain and use cancellation indicator from airline interface (Note: already in secondary 

interface) 

• Improve handling of surface time updates while Center user is in the process of 

scheduling (FAA request) 

• Verify that multiple surface interfaces can be handled by rTMA 

• Update the rTMA status message for surface flights to be automatically removed when 

associated work is done (FAA request) 
 23 

• Improve filtering of surface flights panel (Shift-F4 panel) 

4.5 Assumptions and constraints 

The following are assumptions used in the development of this Concept of Operations: 

• A surface system will exist in the National Airspace system that is capable of providing 

OFF time predictions and runway assignments to the en route system similar to those 

provided by SDSS in PDRC 

• An en route system will exist in the National Airspace System that is capable of receiving 

surface information and providing coordinated release times similar to those provided by 

the rTMA system in PDRC 

• The surface and en route system will have access to data inputs similar to those used in 

PDRC (e.g., gates assignments, surface surveillance, en route surveillance, weather, flight 

planning data) 

• The system used to automate coordination during CFR events must perform at least as 

well as (preferably better than) the current manual process in use today. Failure to do so 

could lead to local personnel refusing to utilize the automation. 

• Some ability for site-specific adaptation related to surface/en route automation will exist. 

The desire is to keep site specific adaptation to a minimum 

• Adequate training for changes proposed will be provided to end users 
24 

5 Concepts for the proposed system 

This section describes the PDRC system that has been developed to address shortfalls in presentday tactical departure scheduling. 

5.1 Background, objectives, and scope 

The PDRC-IADS research activity combines the automated coordination demonstrated in 

previous research [13, 20, 21]with the use of surface trajectory-based OFF time predictions to 

improve en-route tactical departure scheduling during CFR procedures. PDRC-IADS 

background, objectives, and scope are presented in Section 1. 

5.2 Operational policies and constraints 

Per the statement in Section 1, the scope of this ConOps is specifically limited to the field 

evaluation environment for the PDRC-IADS research activity (i.e., NTX, ZFW, D10, and DFW). 

FAA recipients of this ConOps should be able to extrapolate the comments to other operational 

environments. 

The PDRC operational evaluations [3] were conducted within the standard CFR procedures 

followed by ZFW and DFW. In other words, the TMCs have not been asked to modify 

procedures other than to use the PDRC research system. 

The PDRC operational evaluations were conducted only in the ZFW outbound (i.e., TMA/EDC) 

tactical departure scheduling scenario. Operational evaluations of the inbound scenario were not 

possible due to challenges of using rTMA for operational arrival metering at ZHU. See Section 

5.4 of the Final Report [3] for a discussion of inbound scenario field evaluation challenges. 

5.3 Description of the proposed system 

A high-level overview of the proposed system is provided in Section 1.4. That overview and the 

accompanying figure presented the double-headed arrow as the essence of PDRC. The arrow 

represents the automatic communication and coordination of OFF times between the en route 

tactical departure scheduling system and a trajectory-based surface automation system. 

5.3.1 PDRC applied to tactical departure scheduling 

Section 3.3 provided examples of inbound and outbound tactical departure scheduling situations 

and described how TMA’s departure scheduling functions were used in these situations. This 

section uses a revised version of Figure 3:5 to illustrate how PDRC is applied to tactical 

departure scheduling. 

Figure 5:1 shows a NextGen trajectory-based surface automation system communicating with 

the TMA systems via the PDRC double-headed arrow. As described in the Section 1.4 

overview, the surface system delivers OFF time predictions and runway assignments to TMA to 

improve tactical departure scheduling. The double arrow is also used to automatically 

communicate the TMA-computed release time back to the surface system for use by the Tower 

controller team. 
 25 

As shown in Figure 5:1, PDRC has been developed for both the inbound and outbound cases. 

The prototype software supports both cases, although the operational evaluation only evaluated 

the outbound case. 

5.3.2 PDRC prototype software 

The PDRC research activity strives to be implementation neutral, meaning that the research 

results will be generally applicable, regardless of which specific surface or en-route tools are 

used. PDRC performance will, however, be affected by the prediction and scheduling accuracy 

of the component systems that are used. The PDRC Technology Description document [2] 

includes requirements for the two component systems as well as information exchange 

requirements. The prototype software used for development and evaluation may not reflect 

eventual implementation systems. 

A high-level overview of the prototype software used for the PDRC concept testing is illustrated 

in Figure 5:2. The upper portion of this figure shows the Center tactical departure scheduling 

decision support tool. The PDRC prototype utilizes rTMA for this component. The lower portion 

of this figure shows the Tower decision support tool. The PDRC prototype uses SDSS for this 

component. Complete details regarding the PDRC prototype software are provided in the 

Technology Description companion document [2]. 

Figure 5:1 – PDRC applied to tactical departure scheduling. 
26 

5.4 Modes of operation for the proposed system 

The PDRC research prototype system has been operated in the following modes: 

• Production (i.e., operational field evaluation) 

• Training (i.e., on-the-job training for TMCs prior to field evaluation) 

• Degraded (e.g., single center Host data when multi-center unavailable) 

This ConOps considers both nominal and off-nominal modes of operation. 

5.5 User classes and other involved personnel 

Per the statement in Section 1, the scope of this ConOps is specifically limited to the field 

evaluation environment for the PDRC-IADS research activity (i.e., NTX, ZFW, D10, and DFW). 

FAA recipients of this ConOps should be able to extrapolate the comments to other operational 

environments. 

Subject-matter expert participation in the PDRC operational evaluations has included traffic 

managers (TMCs and STMCs) at ZFW Center, D10 TRACON, and DFW Towers, as well as 

frontline managers (FLMs) at DFW. Test participants will be generically identified as TMCs in 

the discussion that follows. 

Figure 5:2 – PDRC prototype software overview diagram. 
 27 

5.6 Support environment 

Per the statement in Section 1, the scope of this ConOps is specifically limited to the field 

evaluation environment for the PDRC-IADS research activity (i.e., NTX, ZFW, D10, and DFW). 

FAA recipients of this ConOps should be able to extrapolate the comments to other operational 

environments. 

The PDRC prototype system is entirely supported by the PDRC-IADS research team at the 

NASA North Texas (NTX) Research Station for the duration of the development and evaluation 

period. 
28 

6 Operational scenarios 

The primary scenario for the PDRC Block 1 field evaluation is the Call for Release (CFR) traffic 

management procedure applied to DFW departures and implemented with the outbound tactical 

departure scheduling (i.e., TMA/EDC). 

6.1 CFR procedure overview 

The CFR procedure is a collaborative effort between the Center traffic management unit 

responsible for meeting the overhead stream constraints and the Tower controllers responsible 

for releasing departing aircraft. The PDRC concept automates portions of this collaborative 

departure scheduling effort. Specifically, PDRC’s SDSS component automatically predicts the 

earliest achievable OFF times for all departure flights. For flights subject to CFR restrictions, the 

SDSS OFF time predictions are automatically communicated to rTMA for use in tactical 

departure scheduling functions. The PDRC two-way interface facilitates inter-facility 

coordination required to establish an agreed upon release time. 

As described in Section 3.2, a recent FAA Notice [39] has established the –2/+1 CFR 

compliance window as a national standard for TMA operations by amending FAA 7110.65 

standing order to read “when CFR is in effect, release aircraft so they are airborne within a 

window that extends from 2 minutes prior and ends 1 minute after the assigned time, unless 

otherwise coordinated.” The compliance window is “biased” towards being early because it is 

easier to slow an early departure to fit into a slot than it is to accelerate a late departure. Tactical 

CFR precision requirements are significantly higher than for strategic TMIs [5]. Even so, the 

three-minute window is rather imprecise when one considers that this equates to a 21 to 24 mile 

slot at the en route meter point. 

Rather than prescribe a window that the surface controller must meet, PDRC communicates the 

target time of departure at seconds-level granularity to the Traffic Manager in the tower. 

Communicating this time at seconds-level granularity removes any rounding of the data that 

would be done by the Center system or personnel, ensuring the exact target time is known by the 

traffic manager in the tower. PDRC also has the ability to adjust the time passed from the Center 

automation if necessary to bias the time to achieve the objective. The TMC then uses the 

electronically communicated time in seconds-level precision and rounds this value, as 

appropriate, before passing it along to the local controller. The local controller then works to 

meet the time as closely as possible with the understanding that it is better to be early than late. 

It should be noted that application of PDRC automation does not fundamentally alter the CFR 

procedure. Center and Tower roles and responsibilities may remain the same, and CFR 

operations may be conducted per existing inter-facility Letters of Agreement. TMA is widely 

used for tactical departure scheduling to meet CFR restrictions, and TMC interactions with the 

TMA departure scheduling functions are essentially unchanged with the PDRC system. Thus, 

only the SDSS-related portions of the following scenario represent material changes to the 

present-day CFR procedure. 

Figure 6:1 presents an overview of the Tower and Center interactions involved in tactical 

departure scheduling with PDRC to implement the CFR procedure. The left side of the figure 

shows the Center TMC interacting with the rTMA user interface. The right side of the figure 
 29 

shows the Tower TMC interacting with the SDSS user interface. Center and Tower TMC 

actions are listed in the center portion of the figure. 

The tactical departure scheduling actions summarized in Figure 6:1 are described in detail in the 

following subsection. 

6.2 CFR evaluation scenario steps 

This section details tactical departure scheduling with PDRC to implement the CFR traffic 

management procedure. The steps are illustrated with actual screenshots from Tower and Center 

displays taken during the Block 1 PDRC field evaluation. The PDRC scheduling event shown in 

these screenshots is for AAL1001 on 18 June 2012. This was a DFW departure joining an IAHbound stream with outbound tactical departure scheduling (i.e., TMA EDC scheduling) to the 

TNV meter arc, which is situated at the southern boundary of Fort Worth Center very near the 

TORNN arc shown in Figure 3:3. 

As shown in Figure 6:1, the actors in the PDRC operational concept scenario are (nominally) two 

TMCs. One TMC is located in the Center TMU and the other is located in the Tower. For 

simplicity, these TMCs are identified as Center and Tower in the following discussion. 

6.2.1 CFR restriction notification 

The modified CFR notification process will continue to vary by facility. At ZFW, the Center will 

still notify the D10 TRACON, which, in turn, notifies each affected airport Tower that CFR 

Figure 6:1 – Center and Tower tactical departure scheduling actions with PDRC to

implement the CFR procedure. 
30 

restrictions have been implemented for a given destination and time range. Notifications are done 

via inter-facility voice calls. After the initial notification via D10 TRACON, an individual Tower 

usually communicates directly with the Center when making CFR requests, but multiple towers 

may coordinate through D10. Both ZFW and D10 will continue to enter the CFR restrictions in 

their electronic logging systems. 

6.2.2 CFR activation in SDSS 

In response to receiving notification of a CFR restriction, the Tower will use the SDSS 

“Add/Remove APREQ Schedule” dialog to enter a new CFR. The CFR will include the 

destination airport or jet route and the time range that is used to determine which flights are 

subject to the CFR restriction. Flights subject to the CFR restriction are entered into a list used 

by rTMA and SDSS to track the flights being actively coordinated. 

The results of CFR activation in SDSS for the AAL1001 example are shown in Figure 6:2. The 

timeline data tag for this flight has been colored white with an APREQ label and APREQ 

appears for AAL1001 in the flights table. 

6.2.3 Request for Release Time (RFRT) 

As an affected flight becomes ready for departure, the Tower will select "Request Release Time" 

from the SDSS “Flight Properties” menu (accessed for a specific flight from the timeline or 

flights table). This causes SDSS to send a Request For Release Time (RFRT) to rTMA. The 

request will include time projections for both Undelayed Coordinated OFF Times (UCOT) and 

Predicted Coordinated OFF Times (PCOT) times. The undelayed time represents when the flight 

could be at the runway assuming no other traffic on the surface, while the predicted time 

incorporates constraints imposed by other aircraft. The flight’s PDRC status is updated, and an 

indication is provided to the Tower on both the timeline and the flights table that the release time 

has been “Requested.” The Center also receives a “Release Requested” indicator on the rTMA 

display as well as an audible alert. 

The SDSS screenshot in Figure 6:2 was captured at 21:14:37 just as the Tower was selecting 

“Request Release Time” for AAL1001. The PDRC predicted OFF time (i.e., PCOT) is shown in 

the flights table to be 21:19:31. The surface situation display shows that AAL1001 was just 

beyond the spot when Tower requested the release time. 
 31 

The results of the Request Release Time entry are shown in Figure 6:3, which is an SDSS screen 

shot taken a few seconds after the one in Figure 6:2. The timeline data tag and flights table entry 

for AAL1001 have been updated to indicate a pending release time request. The figure also 

shows that the PDRC predicted OFF time is continuously updated – the flights table PCOT value 

for AAL1001 is now 21:19:32. This PCOT value was communicated to rTMA along with the 

release time request. 

Figure 6:3 also illustrates a motivation for using trajectory-based OFF time predictions from a 

surface management system for tactical departure scheduling. AAL1001 is scheduled to depart 

from runway 17R on the east side of DFW. At the time of this screenshot, the 17R departure 

queue is completely empty, and the taxiway from AAL1001’s position to the departure is also 

vacant. However, the screenshot shows a train of three American Eagle flights currently headed 

to runway 17R along the northernmost bridge (Taxiway Z). In the manual CFR scenario, the 

Tower would have to mentally compute ETAs to the 17R hold pad from these flights on the 

bridge and estimate the departure queue sequence before providing the Center with a predicted 

OFF time for AAL1001. Experienced Tower personnel are adept at these predictions, but the 

extra workload can be eliminated through use of a trajectory-based surface management system. 

Figure 6:2 – Tower TMC uses SDSS user interface to request release time for

AAL1001 during the PDRC Block 1 field evaluation. 
32 

6.2.4 Response to the Request for Release Time (RFRT) 

The Center will respond to RFRT requests using rTMA’s “Schedule a Departure” dialog, which 

has been enhanced to display SDSS scheduling information. The Center will select one of the 

following actions: 

• SCHEDULE USING SURFACE TIME, which causes rTMA to schedule the flight for 

departure at the earliest time that is equal to, or later than, the predicted OFF time. If 

the Center FREEZES or ACCEPTS the Suggested Departure Time via the dialog, or 

manually schedules via timeline actions, then rTMA forwards the Scheduled 

Departure Time (SDT) to SDSS. At that point, the flight will be assigned a PDRC 

status of “SDT SENT.” 

• SCHEDULE USING HOST TIME, which allows the TMC to over-ride the surface 

provided OFF time in favor of the ‘now time’ or PTIME default that is adapted in 

TMA. This will also allow the TMC to write in free form text any time they choose. 

• FREE RELEASE, which tells the Tower that the flight may be released at their 

discretion. 

Figure 6:4 is a screenshot of the Center’s rTMA Timeline Graphical User Interface (TGUI) taken 

2 seconds after the SDSS screenshot shown in Figure 6:3. The two left timelines in this figure 

are of interest. The middle timeline has been configured to show IAH-bound traffic that Fort 

Worth Center is managing to satisfy a miles-in-trail (MIT) restriction imposed by Houston 

Figure 6:3 – SDSS user interface indicating a pending release time request for

AAL1001 during the PDRC Block 1 field evaluation. 
 33 

Center. Fort Worth Center is seeking to satisfy the MIT restriction for this stream at the TNV 

arc near the boundary between the Centers. The middle timeline is referenced to the TNV arc. 

This timeline represents the constrained overhead stream for this example of the PDRC 

operational scenario. 

The far left timeline in Figure 6:4 shows departures from various airports that Fort Worth Center 

must merge into the constrained IAH-bound stream. The CFR procedure has been implemented 

to manage these departures. This timeline is referenced to the runway OFF point for each of the 

various airports. 

AAL1001 is shown at approximately 21:34 on the left side of the middle timeline. This is the 

time that rTMA estimates AAL1001 could arrive at the TNV arc without consideration for other 

traffic. This ETA is based on rTMA trajectory-based computations that begin with the SDSSprovided OFF time prediction. One can see that AAL1001 directly competes with UAL1258, 

which is currently airborne (indicated by leader line and data tag with the same color). 

On the far left timeline AAL1001 is shown with a white data tag indicating that the Tower has 

requested a release time via PDRC. The blue “delay” value shown to the left of the AAL1001 

Figure 6:4 – rTMA user interface indicating a pending release

time request for AAL1001 during the PDRC Block 1 field

evaluation. 
34 

data tag provides the Center with an indication of unassigned surface delay that this flight is 

expected to experience due to surface congestion. This value is the difference between PDRC’s 

PCOT and UCOT OFF time predictions. UCOT is computed without consideration of other 

surface traffic while PCOT accounts for other surface traffic. 

The rTMA TGUI screenshot in Figure 6:5 was taken 11 seconds after the screenshot in Figure 

6:4. The Center has been notified (via PDRC audible alert) of the pending request for release 

time and activated the Schedule a Departure dialog by double clicking on AAL1001’s timeline 

data tag. 

As noted in the discussion of Figure 6:3, SDSS has predicted an OFF time of 21:19:32 for 

AAL1001. This OFF time prediction is reflected in Figure 6:5 by AAL1001’s data tag position 

on the far left timeline and has been automatically loaded into the Aircraft Ready Time field in 

the Schedule a Departure dialog. During the PDRC operational evaluations, rTMA followed 

current TMA practice of displaying only minutes-level precision in the scheduling dialog boxes. 

The rTMA TGUI screenshot in Figure 6:6 was taken 27 seconds after the screenshot in Figure 

6:5. The Center has just clicked on the Schedule button. The “Desired STA” of 21:34 

Figure 6:5 – rTMA departure scheduling panel prior to Center

scheduling for AAL1001 during the PDRC Block 1 field

evaluation. 
 35 

corresponds to rTMA's original estimate of when AAL1001 could reach the TNV arc without 

consideration for other traffic. After the Center scheduling action the Schedule a Departure 

dialog shows the “Closest Available STA to be 21:35 and suggests a departure time of 21:21, 

which corresponds to a 2 minute delay compared to the SDSS prediction (truncated) of 21:19. 

After evaluating the scheduling results, the Center will click the Accept button, which closes the 

Schedule a Departure dialog box and communicates the Scheduled Departure time back to the 

SDSS system at the Tower. The rTMA TGUI screenshot in Figure 6:7 was taken a few seconds 

after the screenshot in Figure 6:6 and shows the results of this tactical departure scheduling 

operation for AAL1001. Scheduling has now placed AAL1001’s data tag on the right side of the 

middle timeline. AAL1001 now has a 2 minute delay as a consequence of being sequenced 

behind UAL1258. The AAL1001 data tag on the far left timeline also shows the two minute 

delay and the data tag is positioned at the Scheduled Departure Time of 21:21. 

Figure 6:6 – rTMA departure scheduling panel after Center

scheduling for AAL1001 during the PDRC Block 1 field

evaluation. 
36 

This completes the Center’s response to the Tower’s request for release time. 

6.2.5 Response to Scheduled Departure Time (SDT) 

When a Scheduled Departure Time (SDT) is sent to SDSS, the Tower determines if the rTMAsupplied SDT is acceptable, and will select one of the following actions: 

• SDT is acceptable, which will prompt notification to the Center and an update of the 

flight’s PDRC status to “SDT ACCEPTED.” On the SDSS display, this will cause the 

timeline data block text to include “APRQ:hh:mm:ss,” where the “hh” is the hour of 

the release, “mm” is the minute, and “ss” is the seconds. The data block highlighting 

will indicate whether the flight's current predicted OFF Time is before, after, or within 

a configurable tolerance of the SDT. 

• SDT is not acceptable, which will prompt notification to the Center and an update of 

the flight’s PDRC status to “SDT REJECTED.” In this case, the Tower and Center 

generally resolve the situation via voice communications, however a number of 

automated options exist to resolve this electronically within PDRC. After this 

Figure 6:7 – rTMA user interface after Center scheduling for

AAL1001 during the PDRC Block 1 field evaluation. 
 37 

Tower/Center coordination, the Center may reschedule the flight, unschedule the 

flight, ‘reset’ the flight, or remove the flight from active SDSS/rTMA coordination. 

• Do nothing. This option was developed during the PDRC Block 1 field evaluation. 

Tower TMCs suggested that explicit acceptance was superfluous. The subject was 

discussed at a field evaluation “how goes it” meeting and Center and Tower personnel 

agreed that this step would be optional. Acceptance of the SDT delivered by rTMA is 

now implied unless the SDT is explicitly rejected. 

The SDSS screenshot shown in Figure 6:8 was taken a few seconds after the rTMA screenshot 

shown in Figure 6:7and slightly more than a minute after the Tower requested a release time for 

AAL1001. 

Figure 6:8 shows that AAL1001 is now proceeding north along taxiway L to runway 17R. The 

SDT computed by rTMA and delivered via the PDRC interface is shown in both the timeline 

data tag and the flights table. The SDT is displayed with seconds-level precision: 21:21:02. The 

timeline data tag is highlighted in yellow indicating that AAL1001 must be delayed two minutes 

to meet the SDT. 

As described above, the Tower has the option of explicitly accepting the SDT via a right click on 

the timeline data tag. This acceptance would alter the data tag highlight and send a message 

back to rTMA. 

Figure 6:8 – SDSS user interface after receipt of Scheduled Departure Time from

rTMA for AAL1001 during the PDRC Block 1 field evaluation. 
38 

6.2.6 Departure release management 

Tower traffic control tactics for CFR flights are determined by the Center’s response to the 

RFRT: 

• If a Free Release has been sent from rTMA to SDSS, then the flight’s timeline tag 

reverts to normal text display and “APRQ:FREE” is displayed in the tag. The Tower 

can then manage that flight's departure as if no CFR restriction were in place. 

• If a SDT has been provided and accepted, then the Tower performs tasks to meet the 

rTMA SDT. These may include: flight strip marking and manipulation procedures; 

ATC control of aircraft surface movements, arrivals, and departures; and monitoring 

SDSS’s continuously updated projections of departure time estimates. 

Note that, at any time, rTMA can cancel a RFRT for a particular aircraft via a message to SDSS. 

This will cause SDSS to also cancel the request in a message to rTMA and return the flight to the 

initial state of “APRQ.” The user may then initiate a new request. Note also that at any time 

after a "Request Departure Time" has been initiated, the user may cancel the request. This will 

cause SDSS to send a request cancelation message to rTMA and return the flight to the initial 

state of “APRQ.” 

The SDSS screenshot in Figure 6:9 was taken one minute before the scheduled departure time 

for AAL1001. The aircraft target can be seen in the runway 17R departure queue. AAL1001 is 

next for departure behind EGF3383, which is currently at the 17R threshold. Green highlighting 

for AAL1001’s timeline data tag indicates the flight is on track to meet the scheduled departure 

time. Near the top of the timeline in Figure 6:9 the data tag for SKW5169 is colored white with 

an “APRQ” label indicating to the Tower that this is the next flight subject to the CFR procedure. 
 39 

6.2.7 Merge into overhead 

The final step in the tactical departure scheduling scenario involves the merge into the overhead 

stream. This step differs between the inbound and outbound case. For the inbound case, 

scheduled time of arrival and sequence information regarding the merge is communicated to the 

Center sector controller via TMA arrival metering functions. The outbound tactical departure 

scheduling case currently operates in an open loop fashion with no information from TMA EDC 

being communicated to the Center sector controller. For the outbound case, Center TMCs 

carefully monitor the overhead stream merges to identify any traffic management adjustments 

that may be required given current traffic conditions. 

In a similar manner, monitoring of the overhead stream merge is an important performance 

measure for the PDRC field evaluation. Figure 6:10 shows a screenshot of the rTMA Planview 

Graphical User Interface (pGUI) as AAL1001 merged into the IAH-bound overhead stream at 

the TNV meter arc. DFW airport is shown near the top of the screenshot. AAL1001 exited D10 

TRACON at the DARTZ fix shown near the middle of the diagram. As noted in Section 6.2.4, 

rTMA assigned AAL1001 a two-minute surface delay to resolve a slot contention situation with 

UAL1258. Figure 6:10 shows AAL1001 crossing the TNV arc immediately behind UAL1258 as 

scheduled by rTMA. 

Figure 6:9 – SDSS user interface 1 minute before scheduled departure time for

AAL1001 during the PDRC Block 1 field evaluation. 
40 

Figure 6:10 – rTMA planview display showing overhead stream merge for

AAL1001 during the PDRC Block 1 field evaluation. 
 41 

7 Summary of impacts 

The following sections discuss the operational impacts of this change to system users. 

7.1 Operational impacts 

The change in controller procedures is seen as minimal. The most significant change to current 

operations is incorporating greater precision OFF times into the Tower local controller’s 

workflow. The local controller role is known for having a ‘rhythm’ and during the PDRC 

evaluations there was some concern that a highly precise target OFF time might affect this 

rhythm. DFW STMCs prepared briefings on PDRC evaluation procedures presented to all DFW 

Tower controllers. Feedback from the DFW STMCs and TMCs throughout the two operational 

evaluations indicated that these educational efforts were mostly effective, although some 

refresher briefings were required. 

Another procedural change was that phone calls were no longer received by the ZFW Center 

TMU to request for release times. Instead, the Center TMU asked for an audible alert when the 

request for release time arrived from the surface system. The same audible alert option was 

available to DFW Tower personnel for notification of any/all Center events, but they did not feel 

it was needed at this time. 

7.2 Organizational impacts 

Training of system users on the electronic request and scheduling will be required. PDRC 

benefited from the fact that the changes to the Center interface were minimal given the decision 

to utilize rTMA from the FAA’s TMA/EDC system. Even so, training was required to note all 

the differences between TMA and rTMA. The SDSS decision support tool was new to DFW, so 

more extensive training was required for the Tower TMCs. Tower TMCs also had to be trained 

on communication of target times to the local controllers as described in the preceding section. 

7.3 Impacts during development 

The inbound case described earlier in this document has the potential to impact systems outside 

the target facility’s system boundary. For instance, departures being released from DFW into a 

metered arrival flow into IAH would require a receiving TMA system in ZHU. Given that some 

testing of this remote center interface would be necessary prior to production use, and that the 

resulting times would be displayed on operational controllers’ scopes, as they are today for 

manually input times, this requires multi-center coordination. 
42 

8 Analysis of the proposed system 

The PDRC research activity will assess the value of using surface trajectory-based OFF time 

predictions and runway assignments to compute en route departure schedules during Call For 

Release situations. As the research progresses, results will be documented in this section. Please 

refer to Section 4 for a summary of the anticipated benefits. 

8.1 Summary of improvements 

NASA conducted two operational evaluations of PDRC. The evaluations were based at NASA’s 

NTX Research Station and involved TMCs and FLMs at Fort Worth Center and DFW’s East and 

West Towers. Complete evaluation results are provided in the PDRC Final Report [3]. Specific 

improvements noted the PDRC operational evaluation include the following: 

• The evaluations ran for a total of 29 weeks in 2012 and early 2013. During these 

evaluations more than 230 flights were scheduled with the PDRC prototype. Positive 

subject-matter expert feedback was received throughout the evaluation and significant 

improvements in tactical departure OFF time compliance were demonstrated. 

• OFF time compliance (OTC) is defined as the error between the actual OFF time and the 

coordinated release time agreed to by the Center and Tower TMCs. OTC results from the 

two PDRC evaluations were compared against a year-long sample of baseline data. Since 

the goal is to reduce uncertainty, key OTC metrics are the standard deviation and the 

absolute average error. PDRC showed a 43% improvement over the baseline standard 

deviation and a 43% improvement in absolute average error. 

• A key feature of the PDRC concept is coordination and communication based on a single 

target release time rather than a release window. The PDRC target time (with secondslevel resolution) is used throughout the process and a single time (with appropriate 

rounding) is communicated by the Tower TMC/FLM to the local controller. When 

comparing PDRC evaluation results against a present-day standard –2/+1 OFF time 

compliance window we find that 54% of the baseline flights met the –2/+1 window (note 

that outliers were removed from the baseline data set). PDRC Block 1 data exhibited 

74% compliance against the standard window while Block 2 had 83% compliance. By 

this performance measure, PDRC Block 2 exhibited approximately 53% improvement 

over baseline compliance with the standard window. 

• Leveraged surface-provided runway assignments along with more detailed TRACON 

routing to improve en route departure prediction to TRACON departure fix. These 

improvements reduced average TRACON time-to-fly prediction errors by up to a factor 

of 6 (i.e., average errors of 176 seconds reduced to 28 seconds) depending on departure 

runway and departure fix combination. 

8.2 Disadvantages and limitations 

A remaining challenge with surface/en route automation is determining how the processes and 

procedures will differ for equipped sites that have surface automation, versus lesser equipped 

sites that do not. During the PDRC evaluation the EDC system was used for both DFW and non-
 43 

equipped satellite airports scheduling into the overhead stream. This led Center personnel to 

request seconds-level precision for manual communication to non-surface automation airports. It 

also caused some challenges for the Center due to the less-equipped satellite airports adhering to 

a three minute window while DFW achieved a much higher OFF time compliance than was 

possible without PDRC. 

8.3 Alternatives and trade-offs considered 

Operational alternatives considered during the PDRC evaluation were as follows: 

• Use of a TMA/EDC timeline in the tower. This was considered due to the desire to allow 

greater visibility into the overhead stream for tower personnel. However, after better 

understanding of the complexities of configuring the EDC system for a particular flow 

and the training difficulties associated with that, other options were pursued. 

• Pre-departure conditioning view of surface. A number of alternatives were considered 

with regard to configuring the surface timeline display to make it useful for the TMC in 

his/her everyday work on the airport surface. This entailed a number of GUI changes and 

evaluating a number of options with the TMC in order to arrive at a display that is now 

called ‘pre-departure conditioning.’ This name reflects the TMC use of the surface 

display to perform pre-tactical loading of the runway via assigning aircraft from specific 

departure fixes to one side or the other of the airport. 

• Auto-scheduling. The ability to automatically assign and accept release requests from a 

surface system was implemented in the PDRC system. However, the Center users felt 

that this would not lessen their workload unless D10 TRACON also took over all other 

D10 departures in addition to DFW departures. Therefore, this system option has not 

been fully explored to this point during the PDRC evaluations. 

• Center system or Surface system the primary server. PDRC began with the Center 

system as the primary server of data and the surface system attaching to it later. Over 

time the architecture changed so that the surface system was the server with the Center 

system attaching to it. This seemed more natural to the developers working closely with 

the data. There are no known operational impacts to this architecture change although 

the expected start/stop and uptimes of each system will need to be evaluated as the 

capability is deployed into the NAS. Today, the TMA system can run many days without 

restarting. Restarts in TMA are generally only done when a new adaptation or new 

system software needs to be loaded. The restart policy of the future surface system was 

unknown during PDRC development. 

• Drag and drop for Surface times on TMA. Drag and drop capability is an option 

available for scheduling departures in TMA/EDC today in the NAS. However, use of 

this capability for an aircraft with a surface time would mean that the user is over-riding 

the surface provided time. Consequently, in the PDRC implementation it was decided 

that this capability would not be available. After user feedback on the subject it has 

become apparent that this is a desired feature. 

• Seconds-level precision on the TMA scheduling graphical interface. Center personnel 

requested seconds-level precision on the Schedule a Departure Dialog (SADD) panel. 
44 

Today the SADD panel always truncates the value to minutes-level granularity. 

However, this variable could not be changed without impacting several areas of the 

source code and due to available resources this change was not made to TMA. 

• Route 10B information passed to the surface system. TMA has logic that considers and 

applies changes to the flight’s expected route using flight plan information from the 10B 

field of the NAS flight plan. This information would be useful in the surface system in 

order to properly assign departure fixes. The PDRC system would have benefited from 

this information, resulting in fewer departure fix mismatches. 

• Activating a Call For Release electronically from the TGUI. The only phone call that 

still remained in PDRC was to initialize the CFR. This too could be removed by 

allowing the TGUI to create and send this constraint electronically. A reasonable place 

to add this constraint may be on the same panel that is used to assign Miles in Trail. 

• Drag and drop on surface timeline. The ability to drag and drop a flight from one time to 

another on the surface timeline was requested by Tower personnel at DFW. This was not 

implemented due to resource constraints. 
 45 

9 Notes 

See the Technology Description [2] and Final Report [3] for substantial additional information 

that will aid in the understanding of this document. 
46 

Appendix A: Related NextGen Initiatives

This appendix discusses NextGen initiatives that are related to the PDRC-IADS research 

activity. 

A.1 Integrated Arrival/Departure/Surface Concept 

The FAA NextGen organization is leading an effort to refine the concept [28] and functional 

requirements [29] for Integrated Arrival, Departure, and Surface (IADS) operations. The IADS 

concept is a collection of integrated capabilities designed to assist the air navigation service 

provider, user community, and other stakeholders to efficiently plan for and execute the 

movement of aircraft into and out of congested terminal environments to optimize the use of all 

arrival, departure, and surface capacity. This concept description focuses on how these currently 

separate and independent capabilities will be integrated to operate in a synergistic manner. 

Relationship to PDRC: PDRC seeks to contribute to the development of this concept by 

addressing a portion of the research gaps [30] identified by the FAA NextGen organization. 

A.2 Terminal Flight Data Manager (TFDM) 

The FAA Terminal Flight Data Manager (TFDM) Program is conducting concept engineering 

and requirements analyses to support procurement of a Tower automation system that 

implements the TFDM concept [32]. 

Relationship to PDRC: The NASA/FAA IADS RTT has identified the TFDM program as one 

recipient of the PDRC research transition product (RTP). The TBFM and TFDM Programs will 

use these products to inform development of the Integrated Departure Arrival Capability 

(IDAC), which features linkages between the TBFM and TFDM automation systems. The 

PDRC RTP will be used in TFDM’s Core Work Package. 

A.3 Time Based Flow Management (TBFM) 

The FAA Time Based Flow Management (TBFM) Program provides for continued support and 

development of the Traffic Management Advisor (TMA) decision support tool. 

Relationship to PDRC: The NASA/FAA IADS RTT has identified the TBFM program as one 

recipient of the PDRC research transition product (RTP). The TBFM and TFDM Programs will 

use these products to inform development of the Integrated Departure Arrival Capability 

(IDAC), which features linkages between the TBFM and TFDM automation systems. The 

PDRC RTP will be used in TBFM’s Work Package #3. 

A.4 Integrated Departure Arrival Capability (IDAC) 

The IDAC concept was formerly known as the Departure Flow Management (DFM) concept. 

This can lead to confusion with the recent DFM prototype demonstration and evaluation activity. 
 47 

This section addresses the IDAC concept, while the following section addresses the DFM 

prototype. 

The objective of IDAC is to increase NAS efficiency and reduce delays by providing decisionmaking support capabilities for departure flows. IDAC automates the process of monitoring 

departure demand and identifying departure slots. 

IDAC coordinates the departure times between airports and provides situational awareness to Air 

Traffic Control Towers (ATCT) so that they can select from available departure times in their 

planning. IDAC seeks to leverage and build upon the best of the available FAA departure 

scheduling systems. 

Relationship to PDRC: As described in Section A.3, the PDRC RTP is intended to support 

TBFM’s development and implementation of IDAC. 

A.5 Departure Flow Management (DFM) prototype 

The DFM prototype has been evaluated in field trials at several FAA facilities. Evaluation 

results are presented in Reference 13, which includes the following description of DFM: 

Departure Flow Management (DFM) is a capability seeking to increase departure flow efficiency 

by automating the coordination of departures from multiple airports over shared and congested 

NAS resources via improved decision support capabilities and web-based, electronic 

communications. Traffic managers in the Center monitor departure and en route demand, initiate 

DFM departure procedures, and monitor the traffic flow. DFM allocates departure times to the 

affected airports, and traffic managers at the airports assign these times to the departures at their 

facilities. Compared to the current APREQ process, the automated calculation, communication, 

and assignment of departure times reduce workload and increase departure flow efficiency. The 

DFM concept builds upon previous NASA research into automation of the APREQ process [20]. 

The DFM prototype, developed by Metron Aviation, was based upon a subset of DFM concept 

requirements that originated from the FAA’s Departure Flow Management Workgroup. The 

goal of the initial operational capability of the Departure Flow Management (DFM) system was 

to satisfy the following principal functions: 

• Allow Center TMCs to electronically submit DFM TMIs 

• Automatically calculate available release times to satisfy TMIs 

• Allow Tower controllers to electronically assign release times 

• Provide a communication protocol to support the automated communication process 

The general concept of the DFM System is outlined as follows (Note: The language below is 

taken directly from the DFM requirements document [36]): 

1. The DFM System receives flow evaluation area and flight data from ETMS 

2. The Center TMC enters TMIs into DFM 

3. DFM identifies all gaps and release times in the restricted flows 

4. The Center TMC makes and approves release time assignments, and monitors the 

integrity of the flows 
48 

5. The Tower controller identifies restricted flights and makes release time 

assignments and requests for those flights 

6. The system logs data for post analysis 

7. The Help Desk technician supports Center and Tower users of DFM 

8. The System Administrator user monitors the health of the system and 

troubleshoots any problems 

Relationship to PDRC: As indicated by item 3 above, DFM calculates release times for an 

aircraft in the restricted flows it is managing. However, like the TMA/EDC, DFM has no 

knowledge of the surface situation upon which to base OFF time estimates. PDRC is intended to 

complement the DFM prototype by demonstrating the value of surface trajectory-based OFF 

time predictions and runway assignments for en route tactical departure scheduling. 

A.6 Surface Collaborative Decision Making (Surface CDM) 

The Collaborative Decision Making (CDM) organization has established a working group to 

develop concepts and requirements for Surface CDM [34]. The Surface CDM activity is being 

supported by the FAA’s Surface Office. The Surface CDM working group includes 

representatives from the FAA, air carriers and airport operators. 

Relationship to PDRC: The PDRC-IADS research activity is identifying requirements for twoway communications between air carrier systems and the surface and en route components of the 

PDRC concept. The PDRC-IADS research team intends to coordinate with the Surface CDM 

working group to harmonize the concepts and requirements as they continue to be developed. 

A.7 Collaborative Departure Queue Management (CDQM) 

Collaborative Departure Queue Management (CDQM) is one of the capabilities envisioned by 

the FAA’s STBO [31] and TFDM [32] concept of operations. 

CDQM is a technique to manage the length of departure queues at each runway of an airport by 

metering entrance into the airport movement area during times when departure demand exceeds 

available capacity. This metering is accomplished by allocating a “fair share” of the available 

departure capacity to each flight operator based on anticipated demand during a specified 

interval. In addition to equitable capacity allocation among flight operators, there is also 

equitable distribution of delay. In CDQM, aircraft experience minimal physical queuing while 

surface movement management ensures the runway is fully used. Delay can be taken at the gate 

with engines running. 

Relationship to PDRC: PDRC does not directly involve surface traffic management. PDRC is 

narrowly focused on developing a methodology for and demonstrating the benefits of automatic 

communication of trajectory-based OFF time predictions and departure schedules between 

surface and departure management systems. PDRC research products will inform the 

development of advanced surface management capabilities like CDQM. 
 49 

A.8 Spot and Runway Departure Advisor (SARDA) 

NASA’s Safe and Efficient Surface Operations (SESO) research focus area is developing several 

surface optimization capabilities including Spot Release Planner, Runway Scheduler, and 

Taxiway Scheduler. These capabilities are being implemented in NASA’s Surface Management 

System (SMS) research platform for development and evaluation. These optimization functions 

have been evaluated together in a series of Spot and Runway Departure Advisor (SARDA) 

human-in-the-loop simulation experiments at NASA Ames [17]. 

Relationship to PDRC: The PDRC and SESO/SARDA teams are collaborating closely on 

SMS/SDSS software development. PDRC will likely benefit from SMS modeling and trajectory 

synthesis improvements developed for the SESO/SARDA. The PDRC and SARDA research 

teams are working to further integrate the two concepts. For example, PDRC will use SARDAprovided estimated pushback times in computing predicted OFF times and SARDA will use 

PDRC coordinated release times as a constraint for spot and runway scheduling. 
50 

Glossary

This section provides a list of acronyms and terms relevant to the PDRC-IADS research activity. 

Identical glossaries are being maintained across the PDRC-IADS document family [1, 2, 3]. 

ADIF ARTS Data Interface 

APREQ Approval Request – see CFR 

ARTCC Air Route Traffic Control Center – one of twenty FAA facilities responsible for 

En Route ATC in the NAS 

ATC Air Traffic Control 

ATCT Air Traffic Control Tower 

CAP Collaborative Arrival Planning 

CDIF CAP Data Interface 

CDQM Collaborative Departure Queue Management 

CFR Call For Release – a TMI used to regulate the flow of departures into a 

constrained overhead stream (also known as APREQ). 

ConOps Concept of Operations 

CRT Coordinated Release Time – the target release time negotiated between Tower 

and Center during CFR operations (see SDT). 

CTD Concept and Technology Development (NASA Project) 

DFM Departure Flow Management 

EDC En Route Departure Capability 

EDIF ETMS Data Interface 

ETMS Enhanced Traffic Management System – see TFMS 

FLM Frontline Manager 

FOSA Flight Operator Surface Application – see TSDE 

GUI Graphical User Interface 

HDIF Host Data Interface 

IADS Integrated Arrival/Departure/Surface 

NAS National Airspace System 

NextGen The next generation air transportation system 

OFF Aircraft takeoff time 

OTC OFF Time Compliance 

PCOT Predicted Coordinated OFF Time 
 51 

PDRC Precision Departure Release Capability 

PGUI Planview GUI 

RFRT Request For Release Time 

RMP Research Management Plan 

rTMA Research TMA 

RTT Research Transition Team – a joint NASA/FAA activity to facilitate NextGen 

technology transfer 

SADD Schedule a Departure Dialog 

SAIE System Analysis Integration and Evaluation (NASA Project) 

SDIF Surface Data Interface 

SDSS Surface Decision Support System – often used interchangeably with the original 

SMS name. Recently, the FAA STBO Project Office has begun referring to 

SDSS as the NextGen Surface Prototype System (NSPS). 

SDT Scheduled Departure Time – proposed Coordinated Release Time (see CRT) 

computed by TMA and communicated to SDSS by PDRC. 

SMS Surface Management System – see SDSS 

STBO Surface Trajectory-Based Operations 

TBFM Time Based Flow Management 

TFMS Traffic Flow Management System – replaces ETMS 

TGUI Timeline GUI 

TMA Traffic Management Advisor 

TMC Traffic Management Coordinator 

TMI Traffic Management Initiative 

TMU Traffic Management Unit 

TRACON Terminal RADAR Approach Control 

TSDE Tactical Surface Data Exchange – replaces FOSA