Volpe Report To the CDM Working Group (Rick Oiesen’s Part)

1. Volpe ReportTo the CDM Working Group(Rick Oiesen’s Part) 5-6 June 2001

2. Runway Visual Range (RVR) Data • The RVR data is available to the airlines in two forms. • Tables and graphs on the Volpe web site. • A digital stream of data. • Real-time RVR data is now available from 26 airports. • By the end of August, data should be available from 45 airports. • Additional airports will come on line as the New Generation RVR system is installed at additional airports. • A telcon or meeting needs to be scheduled so that airlines can make suggestions for changes to the RVR web site to make it more useful or easier to use. When? • The RVR page will in June be moved to the Command Center web page.

4. RVR: A Problem at DFW • The Problem • There are two independent RVR systems at DFW. One cover the east runways, the other the west runways. • This was discovered during installation and came as a surprise to Volpe. • This cannot be handled in a completely satisfactory way by the current software. • There is currently no way to combine the data from the two systems into one report. • The current pick list on the web site only handle three-letter IDs. • RVR data from DFW is not being distributed pending resolution of this problem.

5. RVR: Possible Solutions to the DFW Problem • Short Run • Use dummy IDs for the two systems, e.g., DFA and DFB, or DF1 and DF2, or DFE and DFW. Or expand to four-letter IDs in the pick list and use DFWE and DFWW. • Pro: Can be quickly done. • Con: This makes DFW different from the other airports. There is a training issue. • Long Run • Combine the data from both systems into a single report using DFW as the ID. • Pro: This makes DFW almost the same as other airports. • Con: This not only requires significant software development but also rethinking of the approach. • Volpe will write a memo outlining possible solutions and giving the pros and cons of each.

6. Daily Download • The Original Goal • To provide airlines with a way to correct errors in the OAG. • The Revised Goal • To provide airlines with a way to correct any errors in the ETMS database of flight data.

7. Daily Download: Two Pieces • Daily Download (in the strict sense) • The basic idea: Each airline sends a message to ETMS on each of its flights well in advance of operation. • Status • The work on the Volpe end is complete. • Some but not all airlines do the daily download. • Check and Correct • The basic idea: An airline requests the data on its flights in the ETMS database, checks for errors, and sends in CDM messages to correct errors. • This would allow an airline to correct any error in the ETMS database that occurred for any reason. • Status • Definition is in draft form. The system requirements document distributed on May 24 needs to be reviewed. • There is no agreement within the CDM working group that the benefit is worth the cost.

8. Airlines Apparently Doing a Daily Download • Majors: AAL, AWE, COA, DAL, FDX, SWA, TWA, UPS, USA. • Others: ALO, AMW, ASH, CAA, CDL, CJC, CHQ, COM, EGF, JBU, JIA, MES, PDT, PRT, SKW, UCA.

9. Should Check-and-Correct Capability Be a Requirement? • Pros • This capability would allow an airline to correct any errors in the ETMS flight data from whatever source. • Software development to fix specific problems might not be needed if check-and-correct can be used to deal with those problems. • Cons • Development would be needed not only by Volpe but also by each airline. • The Issue • Is the benefit of check-and-correct enough to justify the cost? Should the FAA and airlines commit to developing this capability?

10. Remove Capability • The Problem: Sometimes a bogus flight appears in the ETMS database and gets a slot in a ground delay program. There is currently no way to take this slot away. • The Solution: Provide the capability to totally remove a flight from the ADL so it does not receive a slot in a ground delay program. • TSD command that a traffic manager or CSA can use. • CDM message that an airline can use. • Status • Requirements need to be written. • To be deployed in ETMS 7.3.

11. Feed of CTAS Data from DFW • NASA is providing a feed of CTAS data from DFW. This feed will include: • Projected runway. • Estimated touchdown time. • Position updates as rapidly as every 12 seconds. • An air carrier needs to sign a MOA with the FAA to get the data. • AAL has signed a MOA. The feed is now going to an AAL contractor. • Carriers need to make sure that they have the needed bandwidth. Between 11 and 33 Kbps is required, depending on the update rate chosen by the airline.

12. Diversion Recovery Page • This page shows the flights that are currently considered to be diversion recovery flights. • Version 1.4 of this page has been running on the DataGate since last August so it could be evaluated by the FAA and airlines. • A new version of the page, which contains all the required changes, is perhaps two weeks away from being deployed on the Command Center web site. • For ETMS 7.3, the capability will be added for an airline to use a CDM message to inform ETMS that a flight is a diversion recovery flight.

13. Pathfinder Web Page • Problem: Airlines need a way to inform the FAA of flights that are able to serve as pathfinders. • 1 March 2001: The Collaborative Routing Workshop decided that the best solution is for there to be a Pathfinder Web Page that will run on the ATCSCC web site. • 11 May 2001: After e-mail discussion, Chris Pear of UAL provided Volpe with a list of data fields to be on the page. • 13 May 2001: Volpe distributed a draft system requirements document.

14. Characteristics of the Pathfinder Page • The page will look much like the Diversion Recovery Page. • The only way that a flight will only get on the page is if an airline manually enters it. • Any updates to the data for a flight must be made manually. ETMS will not provide updates, e.g., to the ETD. • Two conditions will cause a flight to be removed from this page. • Flight is manually deleted. • Flight times out four hours after ETD. Note: The original thinking was that a flight would be removed when it took off. This greatly complicates the page, so it is proposed that this initially not be implemented.

15. Data on the Pathfinder Page for Each Flight • Call sign • Aircraft type • Origin airport • Estimated time of departure • Departure fix/gate (not on Diversion Recovery Page) • Route (not on Diversion Recovery Page) • Destination airport • Estimated time en route • Origin Center • Destination Center • Priority • Altitude (not on Diversion Recovery Page) • Comments

16. Pathfinder Page Issues • Should a NAS user be able to indicate in Field 11 that a flight is a pathfinder? (Tentative: No.) • Which of the data fields should be required and which optional? What error-checking should be done? • Should adding and deleting be restricted to the aircraft operator and the FAA? (Tentative: Yes) • Should a flight be automatically removed from this page when it takes off? (Tentative: No, at least initially, since this will complicate and slow the development.) • Should every user be able to see every flight, or should there be filtering so that a NAS user sees only its own flights? (Tentative: Every user should see every flight.) • What categories of priorities should there be, and what should be the default priority?

17. Pathfinder Page Issues (continued) • Should the Pathfinder Page treat comments in the same way as the Diversion Recovery Page? (Tentative: Yes.) • Should the Pathfinder Page provide the same sorting capabilities as the Diversion Recovery Page? (Tentative: Yes.) • Should the Pathfinder Page provide the same airline filtering capabilities as the Diversion Recovery Page? (Tentative: Yes.) Would it be more useful if filtering was by origin airport rather than airline? (Tentative: No.) • Should the Pathfinder Page treat the status (active or inactive) in the same way as the Diversion Recovery Page? (Tentative: Yes.) • Should the Pathfinder Page have a Counts page that shows the number of pathfinder flights by origin and destination airports? (Tentative: No.)

25. Common Constraint Situation Display (CCSD) • Purpose: To achieve common situational awareness, the CCSD will provide the airlines with a plan view, geographic display that shows constraint information. • Initially, the CCSD will be provided to CDM participating airlines. • It is web-based. • Initially, it is only available over CDMnet. • It will be hosted on the Command Center web site.

28. The CCSD Strategy • Volpe is developing a tool for the FAA called the Web-based Situation Display (WSD). • The WSD is for FAA sites. • The WSD will have access to exactly the same data as the Traffic Situation Display. • As time passes, the WSD will approach the TSD in functionality. • The CCSD is exactly the same as the WSD except that it will not have the functionality and data that are deemed unsuitable for the NAS users.

29. Common Constraint Situation Display:What It Will and Will Not Show • Flights • The CCSD will not show flight icons. • The CCSD will show textual lists of flight data. • Weather • Because of licensing issues, the CCSD will not show the WSI weather that the TSD uses, e.g., precipitation, tops, lightning, jet stream. • A later release of the CCSD will show the Collaborative Convective Forecast Product (CCFP). • Alerts and Overlays: The CCSD will show exactly what the TSD and WSD show. • Other functionality will be added to the CCSD as it is added to the WSD.

30. CCSD Schedule • June 2001: Version 1.0 will include • Monitor Alert Data (red and yellow icons, timelines, lists of detailed data) • TSD static overlays (airports, fixes, sectors, navaids, airways, SUAs, TRACONs) with optional labels • Standard plan-view display commands (move/zoom, range rings) • To be scheduled is a version that will display public flow-constrained areas and show lists of flights that intersect them. • Additional versions are to be defined and scheduled. • As new versions of the WSD are released, corresponding versions of the CCSD will also be released.

31. Do You Have Enough Bandwidth? • Changes in the pipeline that require bandwidth. • One-minute TZs in the ASDI feed (Now). • RVR (Now). • Common Constraint Situation Display (June 2001). • CTAS from DFW (Now). • ITWS (2002). • Other great stuff. • Consult with your vendor to determine if you have enough bandwidth.