AOC/FOC Interface for Data Comm Production System To: Data Comm DCIT AOC WG From: Data Comm Production Sub-Team Date: 04/18/12

Agenda Production System AOC Interface Overview Purpose/Scope Today and Tomorrow Departure Clearance Summary  Data Exchange Summary Questions/Issues Next Steps

Purpose/Scope Review FAA automation for initial implementation Discuss questions/issues concerning Data Comm Production System interface with users Data Comm Trials is a separate activity, architecture and time frame Augment DCIT discussions Scope New DCL Courtesy Copies Gate/Surface Location Subscriber Information Data Exchange New Web-based service

Data Exchange Summary/Subscriber Data : AOC to TIMS Data Link Services Delivery Mechanism Preferences Subscription Mechanism for delivery of departure clearance. Preliminary values are: None PDC DCL DCL/PDC* Needs discussion. *DCL/PDC indicates DCL will be used unless service is unavailable, in which case PDC will be generated if possible. Note that evolution expected to involve flight plan codes. Courtesy Copy Preferences Subscription (Web SDB) Preliminary values are: Initial DCL Revised DCL Initial and Revised DCL Initial DCL fields Revised DCL fields Assume AOCs want everything, so this may end up being deleted as separate data element Gate ID Preferences PDC/DCL CC response Gate ID Request message response  

Data Exchange Summary/DCL Courtesy Copy: TIMS to AOC Departure Clearance Courtesy Copy Header (M) Explicit caveat that this is CC, not a clearance COURTESY COPY – NOT AN ATC CLEARANCE Departure Airport (?) ICAO airport for which this copy of clearance applies Good to have to ensure we are dealing with same flight. Does it need to be mandatory? Departure Clearance Information (M) Copy of contents of DCL sent to aircraft, minus the beacon code Details will be provided in appendices of Functional Description Document and IRD.  

Data Exchange Summary/Gate ID Data : AOC to TIMS System Acknowledgement/ Response (C1*) System response that message was received Includes both acks and nacks in response to DCL copy sent from TDLS to User Automation. Not required unless this is the mechanism chosen for how to provide Gate ID. Note that system ack is required for legacy PDC. Departure Gate/Surface Location (C2*) Location from which aircraft is requesting departure clearance. Used by FAA for tower operations. Clarify that this can be locations other than gate/stand, e.g., hangar or other surface locations for GA or corporate flights. NOTE: Current legacy PDC combines gate ID and system ack to the PDC. Expect this to be retained and use the same paradigm for DCL copies, but may be refined to address revisions. Also, could be sent as totally separate response to Gate ID Request message (TBD). *C1 – Conditional, based on Gate ID data exchange mechanism *C2 – Conditional. If currently providing, then mandatory but mechanism is flexible

Questions/Issues DCL Courtesy Copy (CC) Format (ARINC 620 flavor) being refined. Approach is to make CC as similar to existing PDC format on assumption this is less impact on AOC automation? Confirm that AOCs want something that looks like a PDC rather than starting fresh. Confirm that AOC want data fields in PDC format, even if not sent in DCL, e.g. CID, frequency.  Confirm no route sent to AOC when aircraft gets CAF for initial DCL, since no route sent to aircrew.) Current approach is to send CC for all revisions and include all changed fields (e.g., what was sent to aircraft) Timing of when to send CC (Tower controller need for gate ID when approved DCL vs AOC desire only when pilot picks up, revisions prior to initial DCL delivery) System ack optional (desired, but not required unless this is the choice of how to provide Gate ID to FAA)

Questions/Issues – cont’d Separate Gate ID/Surface Location Message Evolution is to decouple Gate ID from PDC and DCL Courtesy Copy and provide separate “message” to exchange Gate ID/Surface Location to support taxi clearance generation Is there any AOC desire or support for this in near-term? Clarify Optional/Mandatory (If user is currently providing, then need to keep providing. Desirable if AOC can make available even if not currently providing. Operational benefit is to expedite taxi clearance by identifying surface location.) Mechanism  As response to DCL Courtesy Copy (Similar to current PDC response, versus other options)   Request Message (Option for a separate message, e.g., start clean?)

Questions/Issues – cont’d   User Preferences   a. Subscriber Data Base (Default list via CSP, dynamic updates, Web-based option) b. ICAO FPL option (Equipment capability versus preferences, PDC vs FANS DCL) c. Fallback option (Do users want to revert to PDC if marked as DCL but service is not available?) In addition, we still need to figure out how to get feedback from other airlines who are not participating in DCIT.

Data Exchange Summary Subsystem A Messages Direction Subsystem B User Automation Subscription Create, Delete, Update A  B TDLS/TIMS Subscription Response A  B Subscriber List (Legacy) N/A - FAA TDLS Program Legacy PDC DCL Courtesy Copy PDC or DCL CC ack (system) Gate ID Request Gate ID

Next Steps FAA Production System approach has been briefed at DLUF and DCIT, moving forward with defined capabilities DCIT AOC WG is designated forum for identifying any user issues Need users to identify automation POCs to work the details, e.g., specific mechanisms and protocols

Questions?

Back Up

Summary: AOC Interface Today and late 2012 What/When Subscriber list data - manual (email/phone) e.g., which users want PDC at which airports. Airline coordinates with FAA separately with updates as needed (aggregate not flight-specific); non-airline users provide lists bi-monthly. Legacy PDC (pre-departure route clearance) from TDLS to AOC Host approx. 30 min before P-Time (filed flight plan “pushback” time) AOC sends Gate ID (from relevant users as result of coordination with FAA) along with sys ack from AOC or CSP How Via CSP (ARINC, SITA) from TDLS in Tower; Transparent to AOC that they are getting from TDLS since they only see CSP Soon (2012, pre-Data Comm) – also available from FAA automation (TDLS and TIMS) to any users, via open TCP/IP Who No direct interface between FAA and dispatchers or ramp towers Practice is for no revisions by dispatchers - usually re-file flight plan

Current FAA-AOC and Aircraft Interfaces AMSRP - ATIS Message Storage and Retrieval Processor AFEPS - ACARS Front-End Processing System

FAA-AOC and Aircraft Interfaces 2012 – TDLS version 10 FAA-AOC and Aircraft Interfaces 2012 – TDLS version 10.09 – Equal Access

AOC Interface with Data Comm (2015/2016) What/When Legacy Subscriber List migrated to new Web-based Subscriber Data Base Legacy PDC from TDLS to AOC retained CPDLC DCL Courtesy Copies of clearances, including revisions, sent directly to CSP/AOC by FAA automation How PDC and DCL Courtesy Copy Via CSP (ARINC, SITA) or other CSPs or any users via open TCP/IP from TIMS Server in SLC or ATL New Data Comm Web-based Subscriber Data Base at TIMS ADM Server (subscriber information only) Who Same as today Assumption: Any SDB list is only of tail numbers that are capable of DCL, as well as this is preferred mode. Airlines: PDC Only Legacy PDC still supported since IFCET will use existing information to pre-load SDB for PDC on airport/airline basis For DCLs IF airlines send IFCET a list of default tail numbers and delivery mechanisms, IFCET will pre-load SDB with flight specific information (upload a file, bimonthly) Airlines can do themselves using SDB (per flight) for both initial and updates For updates, must use SDB (timely, pre-60 min for guarantee) Non-airlines (GA and Biz) Already provide flight-specifics AIDs on bimonthly. IFCET will preload For updates, must use SDB

Data Comm TDLS/TIMS-AOC and Aircraft Interfaces Existing CSP Path from FAA to AOC and aircraft via ACARS New CPDLC Path from FAA to aircraft via new DCNS 1 2 1 2 1

Web-Based TIMS SDB High Level Architecture CSP/AOC to FAA Subscriber Web Interface Connect via TCP/IP and FAA’s FTI network TIMS operational servers/DBs at SLC and ATL TIMS admin server at OKC (FAA TDLS Team) Subscriber Preference Data Whether specific flight is getting PDC or DCL at this departure airport Other TBD AOC preferences, such as which fields in DCL Courtesy Copy Initial design is one-way only from user to FAA

Departure Clearance (DCL) – (Key Differences from PDC in red): 1/3 Subscriber Information for PDC and DCL (flight specific) User provides preferences using Web based TIMS Subscriber service Specifies AIDs (and/or tail number/REG) which are getting DCLs and which are getting PDC, at the specific airport None - voice PDC only DCL only DCL primary, PDC secondary. – If DCL service is unavailable, FAA automation may “fall back” to PDC. If user wants a previous DCL flight to get a PDC and it is still possible (prior to P-Time – approx. 30 min), then user needs to define preference accordingly DCL Courtesy Copy preferences, if applicable (TBD) What fields in CC (Current approach is to mimic PDC format), without beacon code All revisions or only trajectory-changing? FAA needs 60 min prior to P-time, e.g., prior to when flight strip prints and controller has acted on departure clearance, to ensure it is applied Later updates may not be acted on if system or controller has already processed the flight

Departure Clearance –(Key Differences from PDC): 2/3 PDC/DCL CC When controller approves the clearance and per subscriber information , FAA automation sends following via existing CSP interface PDC, as done today DCL Courtesy Copy (CC) and/or Gate ID Request FOC automation responds (within 2 min) via CSP System/application ack to above (mandatory) PDC Y - flight is eligible to receive a PDC that day N – not eligible to receive a PDC Initial DCL Courtesy Copy Same (Y,N) responses are OK FAA does not NEED anything but will accept Gate ID –response to PDC, DCL CC or Gate ID Request Message optional but is required at certain airports, per coordination with FAA May be appended to system ack to PDC or DCL CC, or as explicit response to a Gate ID Request message

Departure Clearance–(Key Differences from PDC): 3/3 TDLS stores Gate ID from FOC. Enables timely response to taxi clearance request. At some point, Pilot requests DCL via DCL Request downlink. TDLS sends stored DCL to aircraft Pilot responds and response returned to TDLS Revised clearance PDC – Voice clearance DCL – Revised DCL Revised clearance (DCL) sent to pilot Revised Courtesy Copy sent to AOC

Documents Existing FAA-CSP ICD Predeparture Clearance Application Segment Specification, ARINC, 12889 Rev H, Sept 1999 FAA Draft Functional Interface Description Document, TDLS/TIMS-AOC Automation, V0.2, April 2012 [in progress] FAA Draft IRD for Subscriber Data Base Communications Service Provider (CSP) To Tower Data Link Services Subscriber Database (TDLS-SDB) IRD, May 2011, DRAFT V1.0 Available on DCIT Website, http://www.faa.gov/about/office_org/headquarters_offices/ato/service_units/techops/atc_comms_services/dcit/dcit_current_documents/media/CSP_to_TDLS-SDB_IRD_draft_v1.0.pdf