NATCA Bookshelf

A PDC contains information that is cut and pasted off of a flight strip along with the information that the controller selects in the option fields. The TDLS system formats flight plan information and appends controller selections from the option fields. When a PDC is sent, the pilot will eventually see the same information that a controller did. This includes any truncation of routing or remarks. When the flight plan prints, the system will look to see if the call sign is in the subscriber database, if it is, it will put the flight ID onto the Pick List for controller processing. Once the controller selects the information from the option fields and presses send, the PDC is sent through Rockwell Collins (formerly known as ARINC) and then forwarded on to the Communication Service Provider (CSP). In many cases the CSP is actually the Airlines Operations Center (AOC). Once the AOC receives the message, they will respond back to TDLS with a gate response message. This message advises the controller that the aircraft will participate in PDC or are Not Participating. Again the response you see is not from the pilot, but from the AOC. The AOC then decides how to get this clearance to the pilot. It can be delivered in many ways. The message can be delivered to the flight deck via ACARS, it can be delivered to the gate printer, and in some cases it is picked up at the operations center. There are even new companies that are forming to send a PDC in an email to pilots. The reason that the TDLS system can only send the initial clearances and not revisions is because of the lack of information available to be sent from a regular flight strip and also because there is no way for the AOC's to ensure delivery to pilots. ENROUTE AUTOMATION MODERNIZATION (ERAM): Julio Henriques (ZNY) leads the ERAM efforts for NATCA. This update is provided by Dan Mullen (ZID): ERAM 8-1-1 Tabletop site visits have been ongoing and this month the national team held the exercise at ZME and ZKC. The purpose of these meetings is to make sure the site teams are aware of the resources available when there is a problem with ERAM that could disrupt services. The Help Desk at the Tech Center, Second Level Engineering, Lockheed Martin and the ERAM National Air Traffic reps are all-available to help resolve issues. The tabletop exercise uses actual scenarios to lead the local team to develop SOPs for dealing with outages. These meetings have been completed at 7 of the 20 ARTCCs. The National Packaging Team has just about finished determining the contents of the nest two major ERAM releases. There is still a little time and budget left for smaller fixes, but all of the large fixes are set. The Contingency Flight Data Manager (CFDM) emergency flight data tool has been deferred until after EAD700, which is due in the first half of next year, to allow more time to define the requirements and develop the tool. The ERAM EAD510 release Site Test has begun this week at ZSE and ZLC. This is a smaller "delta" release containing fixes for Airborne Re-Route (ABRR) and Datacomm. Assuming testing goes well at the keysites, it will be available nationally in early September. We held meetings the week of July 11 to update the ERAM 8-1-1 document, and held an SRM involving the document changes for the Multiple Flight Plan issue. I also attended a demo of Path Stretch along with TBFM SMEs and some Facility Tech Reps. Path Stretch is an advanced metering tool in the early stages of development. The national ERAM team has been working closely with other tech programs to help their integration into ERAM. We met at length last week with the Pre-Departure and Airborne Re-route (PDRR/ABRR) team, the Datacomm workgroup and AJV-7 (Requirements). These groups are at different stages of developing and deploying new functionality, so we've been working with them regularly to make sure all the teams are aligned.

• Cover