1 / 29

AOC/FOC Interface for Data Comm Production System

AOC/FOC Interface for Data Comm Production System. To: DCIT AOC WG From: Data Comm Production Sub-Team Date: 2/1/13. Agenda. Recap for Production System (2016) DCL Dispatch Message Gate Request Message ICAO 2012 FP Web Access Subscriber Data Base Discussion Topics/Issues

todd-coffey
Download Presentation

AOC/FOC Interface for Data Comm Production System

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. AOC/FOC Interface for Data Comm Production System To: DCIT AOC WG From: Data Comm Production Sub-Team Date: 2/1/13

  2. Agenda • Recap for Production System (2016) • DCL Dispatch Message • Gate Request Message • ICAO 2012 FP • Web Access Subscriber Data Base • Discussion Topics/Issues • Gate Request Message Filtering • Pilot Response/Dispatch Message • 24-bit Aircraft Address

  3. DCL Dispatch Message: Summary • Content • Contains content of DCL that is sent to pilot for initial and any revised DCL • Includes a caveat that this is not an ATC clearance, and does NOT include a beacon code • For Initial DCL, whether Cleared as Filed, Initial UM79 or UM80, includes a separate full route string even if this was not sent to pilot (e.g., for CAF and Initial UM79 cases) • Format same as for DTAP Systems Integration Description Document (SIDD v1.1, Nov. 2012); • Distribution/Timing • Sent to AOC only when a DCL clearance uplink is sent to flight deck • Initial DCL as response to request by flight deck via DM25 • Revised DCL upon controller approval of the revision • Users have option to tailor Dispatch message preferences via Subscriber Data Base (not required; default is all types to all users) • Copy of initial DCL only • Copy of initial DCL and revisions (as sent to pilot) • Copy of initial DCL and revisions (entire content) • None

  4. DCL Dispatch Message Response: Summary • Content • Format same as for DTAP Systems Integration Description Document (SIDD v1.1, Nov. 2012) except no gate assignment (handled by separate Gate Request message) • {Flight ID *A} { Sequence Number} {Tail Number} {Departure time} • Contains Departure time field from legacy PDC response to minimize software impact, per SIDD • Distribution/Timing • Sent by AOC to FAA in response to DCL Dispatch Message • Expect within 2 min, similar to PDC and DTAP

  5. Initial Departure Clearance : Gate ID and DCL Dispatch messages Tower Controller Pilot Avionics Data Comm Flight Data AOC/FOC Automation 1. Flight Plan Circa P-Time- 60 min 2. Flight Data 3. Flight Strip Circa P-Time- 30 min 4. Clearance for approval 5. Approved Departure Clearance 6. Session Start Circa P-Time- 20 min 7. Gate Request Pilot will request DCL x minutes before departure 8. Gate Request Response 9. Departure Clearance Request 10. Departure Clearance 13. DCL Dispatch (CC) 14. DCL Dispatch Ack 15. Departure Clearance Response

  6. Gate Request Message: Summary • Content • Gate Request data exchange is designed to provide same functionality as AOC provides in current response to a PDC • Provide gate/surface location at sites that require it operationally; initial implementation is gate ID • Format in DTAP SIDD, v1.1 • Distribution/Timing • Gate Request is now a separate message exchange between TDLS and AOC • Gate Request sent to AOC when controller/system first approves DCL, e.g., similar to time when a PDC goes to AOC at approx. 20-25 min prior to P-Time • No explicit controller involvement in actual message to AOC • One-time request message; any subsequent gate changes will be handled procedurally • Users have option to opt out of Gate Request via Subscriber Data Base when not operationally required (Discussion topic)

  7. Gate Request Message Response: Summary • Content • {Flight ID *A} { Sequence Number} {Tail Number} { Airport Departure} {Gate Assignment} • Gate Number, if known • “G” if gate is unknown • Format in DTAP SIDD, v1.1 • Distribution/Timing • Sent by AOC to FAA in response to Gate Request Message • Expect response from AOC within 2 min, similar to PDC response

  8. ICAO 2012 FP Update: Coordination • Coordination with Users • Data Comm Implementation Team (DCIT), including members participating in Data Comm Trials • Continue to address any feedback from users • Coordination within FAA • FAA ICAO 2012 FP Program Office • FAA beginning transition to ICAO 2012 FPL • Presented at ICAO Flight Plan Filers Telecon Nov. 7 • Coordination with other ANSPs • Avoid unintended consequences; determine if any potential overlaps for Fld10a or Fld 18 DAT/ usage • Plan to present at DLUF in Feb 2013 • Circulate a notice to prevent duplicate usage of Field 18 codes

  9. ICAO 2012 FP Codes for Data Comm: Summary • ICAO 2012 Flight Plan is now operational in the NAS • Proposed Data Comm “codes” in Field 18/DAT are a mechanism for user to notify FAA automation to generate DCL or PDC for 2016 • Assumes FANS 1/A and FANS 1/A+ support • ICAO FP codes take precedence over any other user preference mechanism • Proposed codes include an optional “Fallback” Hierarchy if DCL service is not available

  10. Fld 18/DAT – Proposed Codes for Data Comm * No ICAO FP change required if user currently gets PDC and does not want DCL. Current PDC designation will be the default.

  11. Fld 18/DAT – Proposed Codes for Data Comm - cont’d

  12. ICAO 2012 FP Codes for Data Comm: Summary – cont’d • “Fallback” Hierarchy and Concepts • Open question on notification of service unavailability to AOCs and flight deck • At Sept DCIT, WG deferred considering this for inclusion in DTAP and for working Fallback questions to Spring 2013 • Production system currently plans to implement hierarchy as follows • Fallback only occurs if AOC/User has designated PDC as the secondary clearance type preference • If flight has been “processed” as DCL, even if not picked up by pilot, no PDC will be sent, e.g., if past normal “drop” time, flights will go to voice if DCL service becomes unavailable • New flights or those earlier than “drop” time, will get PDCs if user has indicated this via ICAO flight plan codes or other user preference mechanism

  13. Subscriber Database (SDB) SDB is already in operation in TDLS Historically, access was provided to IFCET (TDLS Team at OKC) only CSPs emailed updates to IFCET IFCET manually updated the SDB via direct access SDB currently contains, at a minimum, the destination ADNS address for PDCs Provides a method to: Determine where to send PDCs and DCL Dispatch Messages Determine whether to send Gate Request Messages Accommodate user preferences, e.g., specify the primary and secondary clearance preference type or tailor Dispatch messages Allow ATO Safety to declare an entity ineligible to receive a clearance (Lock out) Allow ATO Safety to specify the sites where an airline can receive a PDC (and DCL, if subscriber sites follow the same rules as PDC sites)

  14. Web Access to the SDB Web Access provides a new, secure method for accessing the SDB AOC/CSP can directly manipulate their subscriber data Portal access is limited to their data AOC/CSP may not need to access the SDB after initial set up Concept of Operation CSP/AOC logs in to Web Access SDB CSP/AOC creates/modifies a record to specify clearance type(s), Dispatch message options, Gate Request preference, and CSP/AOC address CSP/AOC only accesses SDB when changes are required The enhanced SDB will include various flight specific and AOC/user data elements Flight id (tail number, call sign, Airline ID, etc.) ADNS address for PDCs and DCL Dispatch messages Primary and secondary clearance preference types (PDC, DCL) Other User Preferences, e.g., type of DCL Dispatch/Courtesy Copy(CC) airline will receive (initial, revision, all), Gate Request message Other PDC and CPDLC management information, as applicable

  15. Discussion topics

  16. Revised Departure Clearance : DCL Dispatch message Tower Controller Pilot Avionics Data Comm Flight Data AOC/FOC Automation May come from FAA automation or user Pilot has already picked up initial DCL. 1. Revised Flight Plan 2. Rev Flight Data 3. Rev Flight Strip (opt) 4. Revised Clearance for approval 5. Approved Departure Clearance 6. Revised Departure Clearance 7.a. Rev DCL Dispatch 7.b. DCL CC Ack 8. Departure Clearance Response Send DCL CC to AOC in parallel to step 6

  17. Discussion Topic: Gate Request Message Filtering • Previous DCIT proposed that Gate Request message will be sent only to those users who currently supply gate in PDC response • Specific mechanism for determining which airports and which users require the Gate Request message was TBD • Minimize impact to AOCs and ATC operations, while providing desired data element • Production system requirements need to be finalized • Current planned implementation • Ground system will send Gate Request Message to all AOCs • Users opt out via Web-based access to Subscriber Data Base, which is same mechanism as for providing ADNS addresses • SDB Web Access allows other user default preferences • If any issues with ATC for specific airport or users, adjust accordingly

  18. Discussion Topic: Pilot Response/DCL Dispatch Message • Problem: • Previous DCIT discussion over having pilot response (WILCO, UNABLE, STANDBY) provided to AOC in DCL Dispatch Message • Currently, ground system sends Dispatch Message to AOC when initial or revised DCL is sent to cockpit, without waiting for any pilot response • Discussion: • Determine if two messages or one? Would AOC want one message when sent and an update when pilot response received OR wait until response is received (could be 5 min) and then send everything in one? • Anything different for STANDBY or UNABLE response? • Anything different for CAF and non-route revisions? • Consider as a user “preference” via Production Web-Access Subscriber Data Base? • Production SDB could provide flexibility for AOCs to tailor getting pilot response in Dispatch Message • SDB already to be used for user preferred ADNS addresses • SDB optional for delivery type, e.g., PDC or DCL

  19. Discussion Topic – 24-bit Aircraft Address • DTAP Problem: • DTAP PTR#1: The ICAO 24 bit aircraft identifier is not being correlated correctly. This results in the aircraft being rejected during logon. • At least one aircraft type sends the ICAO 24 bits in reversed order, and existing logic uses it as a criterion for flight plan correlation • Short Term Solution: • DTAP: Remove 24-bit address from DTAP flight plan correlation logic. • Production System: Ensure 24-bit address is not used by logon (ERAM) or DCL (TDLS) • Discussion: • Need longer term solution for S1P2 En Route services • Solution would have to work with LINK also. Global impact, with other possible impacts, including ADS-B • Next Steps?

  20. Questions?

  21. Back Up

  22. DCL Dispatch Message: Initial

  23. DCL Dispatch Message: Revised

  24. DCL Dispatch Message Response Notes: 1. Production message format for response does not include Gate Assignment, which is provided via Gate Request message response

  25. Gate Request Message

  26. Gate Request Message Response

  27. Data Comm and ICAO FP: Summary • Implementation Approach • Data Comm Trials system will use “FRC DCL” in Field 18/RMK field of current and 2012 ICAO Flight Plan • Data Comm Production system (IOC 2016) will use ICAO 2012 FPL • Field 10a (Equipage) used to identify aircraft capabilities • Field 18 (Other Information) DAT/Codes used to identify flights getting DCL or PDC • Field 18 DAT/ Codes will include a primary/secondary hierarchy • “1”xxx designates preferred departure clearance delivery mechanism • “2”xxx designates “back up” delivery mechanism • ICAO FPL preferences take priority over any other sources

  28. DCL Service Fallback Concept: Recap • If CPDLC service for DCL is not available, FAA automation will “fall back” to PDC • AOC/User must tell FAA they want this to occur; system-wide, not per airport • Can be done in ICAO FP preferences in Field 18/DAT • An additional option is for AOC/user to provide this fallback preference via Web Access portal • Fallback preferences can be stored in the SDB in TDLS automation and used when applicable • Fallback only occurs if AOC/User has designated PDC as the secondary clearance type preference

  29. Web Access SDB and ICAO FP • ICAO Flight Plan Content • Optionally specifies the clearance type (DCL/PDC/Both) • Does not provide the address for the Courtesy Copies, Gate ID Request message or a PDC. This information is needed in the SDB but not available in the flight plan • Hierarchy for Information from ICAO FP and SDB • ICAO FP will take precedence over Web Access. ICAO FP is checked for Clearance Type first • IF Clearance preference is available in FP • Types of Courtesy Copies are retrieved from the SDB • ADNS address for CC is retrieved from the SDB • No clearance preference available • Clearance preference is retrieved from the SDB • Types of Courtesy Copies are retrieved from the SDB • ADNS address for CC is retrieved from the SDB • Voice clearance is issued if the clearance type (DCL, PDC) is NOT specified in the ICAO flight plan or SDB

More Related