Data Comm Production Summary vs Trials Presented To

Data Comm Production Summary vs. Trials: Presented To: DCIT WGs By: Production Sub-Team Date: March 13, 2014 Federal Aviation Administration

Agenda • IOC/Post-IOC Requirements Approach – Aircraft interoperability issues – Future releases • Production DCL End to End Document – Comments • Next Steps SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 2

Aircraft Interoperability Requirements • Goal: Determine which requirements are must haves for Day 1 (IOC) and which ones are must haves for an In Service Decision – Specific builds may be modified based on developer workload and other factors • Review other requirements that can be handled in later releases if need be SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 3

Production Post-IOC Release Strategy: Summary • Current proposed Tower “Releases”. All dates or contents still TBD. 1. 2015 - S 1 P 1 IOC • Start of Waterfall • Must Have Keysite Fixes/Clean Up 2. 2015 – S 1 P 1 ISD • In Service Decision • Must Have for Operational Decision 3. 2015 – Multiple Clearance Delivery Position Support • End of waterfall • Two Clearance Delivery positions at DFW • Any high priority fixes or enhancements that can be included, e. g. , additional interoperability SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 4

Production Post-IOC Release Strategy: cont’d 4. 2016/2017 - Tower NSDA • Transition to KUSA with changes in connection management to support en route CPDLC in later release • Dependent on ERAM waterfall release • Other enhancements as feasible, e. g. , pilot response sent to AOC 5. 2017/2018 - S 1 P 2 Tower Initial/Final • CHI enhancements • New requirements • Session integration across CONUS SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 5

IOC/ISD Aircraft Interop Requirements (1/2) 1. Local Departure Procedure Adaptation – Ensure Departure Procedure and Route is loadable – Provide accurate DP/Tfix to CAF, UM 79, UM 80 – Automation check of ERAM Departure procedure/Transition Fix against Tower Adapted DP/Fix pairs – Errors displayed to controller and no DCL sent to aircraft 2. Auto-retry of connection request – If TDLS receives a disconnect request in response to a CR 1 or other error cases – Single Retry of a CR 1 to aircraft after an adaptable parameter of time 3. UM 83 Switch – National Switch to disable UM 83 – UM 80 would replace UM 83 SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 6

IOC/ISD Aircraft Interop Requirements (2/2) 4. Airway to Airway Transition – Not allow any Route to be sent to aircraft that does not have a named fix for a transition between airways – Does not apply to CAF 5. UM 79/83 Repeat of POSITION variable – Repeats TO position in route clearance variable in UM 79 and AT position in UM 83, if route would otherwise start/end with an airway (Current requirement is to always repeat TO/AT) 6. Limit of 20 Lat/Lon Route elements – Limits DCL routes to have no more than 20 unnamed Lat/Lon elements in the Route variable – Limit does not apply to Lat/Lon sent as part of a Published Identifier element SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 7

Other Aircraft Interop Requirements • Multi-Clearance Delivery Position Build (End of S 1 P 1 Waterfall) – Arrival Procedure Loadability – Ensure Arrival Procedure/Arrival Fix are loadable in the aircraft • NSDA Build – Improve Session Maintainability – Improve session maintainability on Relogon; improve error processing to allow controller to send more clearances (errors will terminate session in S 1 P 1) – LTV/CDA Confirmation Message – TDLS will send LTV to aircraft. LTV response will not impact DCL (FANS 1/A is allowed) but may impact CPDLC service in En Route (Further discussion is required). LTV would act as CDA confirmation message. (Further discussion is required) • S 1 P 2 (Requires more discussion) – – Multicast (e. g. , altimeter, D-ATIS code, advisories) Automatic Revisions Emergency Message support Runway included in DCL SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 8

Trials & Production Teams Coordination • Trials to Production Handoff – Trials Team uses OPR and PTRs to identify those issues that need coordination with Production Team – OMWG to manage any new operational requirements from Trials or DCIT – Trials Team and Production address promoted issues at regular coordination meetings or as needed • Production Requirements Team – Requirements are managed by existing processes and SE tools. Existing delta spreadsheet used as input into requirement change process – Requirements coming from Trials will be added as a standing agenda item for existing post-IOC requirements work – Summarize Production post-IOC status at future DCITs SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 9

Production DCL End 2 End Summary: • Example Deltas between Production and Trials 1. 2. Users designate DCL and PDC flights via ICAO Flight Plan filing and Subscriber Data Base (SDB); no more FRC DCL in Field 18 REM/ field CPDLC (Connection establishment) only after ATC approves the DCL • 3. NAV Database differences may result in differences for international flights, i. e. , “TO” point for UM 79? • 4. 5. 6. No STANDBY if user logs on early (prior to P-Time-30 min) Production uses ERAM NAV DB; Trials has its own FAA NAV DB UM 83 is currently implemented in Production system; post-initial release to put in a switch Gate Request Message to AOCs is a separate message, sent when controller approves the DCL Fallback from DCL to PDC capability if user designates preference to do so SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 10

Production End to End DCL • Draft is based on Trials End 2 End, modified for how Production system will implement • Walkthrough – Body of the document – Deltas in Appendix E if time • Feedback appreciated – Any comments to Carol Burr (cburr@mitre. org), Bruce Notley (Bruce. Notley@faa. gov) and Rob Mead (rob. mead@boeing. com) SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 11

Next Steps • Continue to coordinate with DCIT and Trials for any updated capabilities or issues – Attending OMWG telecons for operational issues – Capturing any new requirements from DCIT, e. g. , DCL via Push rather than Pull • Production expects to provide briefings at April DCIT – More detailed view of coordination process, including tracing approach – Preliminary approach on NSDA – Update on Production, aka TDLS, DCL releases SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 12

Questions? SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 13

BACK UP SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 14

Production Post-IOC Release Strategy • Overall Approach – Functionality in future builds need to be coordinated with other FAA automation systems, e. g. , ERAM, if solutions involve cross-domain requirements – Identify high priority fixes, e. g. , operational requirements, and “low-hanging fruit” for each build – Cost/benefit analysis as applicable due to limited funds and bandwidth • Spring 2013 IOC Requirements Cut-Off – Reviewed deltas with Trials team prior to “April 15” IOC requirements cut-off • Earlier items captured in SE tracking tool, e. g. , NAV database and Initial UM 79 • Known differences identified; future fixes tagged • Currently working on IOC must haves and post-IOC requirements – Minimum of two builds for initial deployment • Day 1 – Initial Operational Capability • In Service Decision (ISD) – Necessary for successful in service decision – Current working list is spreadsheet, with tentative build allocations – Includes format changes and departure procedure changes coming from Trials and DCIT – Includes priorities from operational teams, e. g. , defining what needs to go in builds that represent the first waterfall drop, versus what can wait until last waterfall drop or a future release. SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 15

IOC/ISD Requirements (1 of 4) Source/Inte rest Group Notes WSSD Changes Linkages between departure procedure/transition and other locally adapted fields includes transition fix text. For each transition associated with a Departure Procedure (DP) the user shall be able to define locally Local Departure Procedure Aircraft adaptable fields for each DP 1 Adaptation Interopability. Transition pair. DP/Transition checked as flight plans are delivered to TDLS from ERAM. Errors will be provided in the PICK list. Reason text will be included in the editor window. Error check ERAM supplied DP/Transition Fix against TDLS DP adaptation. When a DPTransition pair received from ERAM does not match any locally adapted DP-Transition pairs, the system shall Error check ERAM supplied display the flight ID to the controller DP/Transition Fix against TDLS DP Aircraft with an error indicator. Flight is 2 adaptation Interopabilityinelgible for DCL Updates to the message formats in accordance with Trials lessons DCL Message & Field Format Aircraft learned. Format for TDLS will match 3 content Interopability. DTAP release 7. 2 TDLS Format V 2. 2 New WSSD The SYSTEM shall retry establishment of a connection with an aircraft a single time When TDLS receives a disconnect when the aircraft rejects a connection request in response to a CR 1 or other request. error cases (CR 1 timeout) the ground New WSSD system will retry a single time. SE Production Sub-Team Federal Aviation Planned for an adaptable timer for a The SYSTEM shall have an adaptable 16 Administration Automatic retry of connection request time parameter for sending a retry of a single retry -- 30 seconds to 2 DCIT#31, 13 March 2014 when TDLS receives a disconnect minutes connection request in the event of an ID Title

IOC/ISD Requirements (2 of 4) ID Title Source/Interest Group Notes WSSD Changes Aircraft Interopability Send a UM 80 if a UM 83 would normally be sent if UM 83 switch is set to off. National level switch. The SYSTEM shall provide a national capability to control the use DCIT asking about switches for of the UM 83. all messages. **** If national adaptation prohibits use of the UM 83, the SYSTEM DCIT asking about switches for shall send a complete UM 80 as a replacement if a UM 83 would be all messages. otherwise be constructed. Ensure no route is sent in a UM 79/80/83 that includes Airway-Airway without a named fix between them. NON- Aircraft 6 CAF flights only. Interopability NEW WSSD Upon reciept and processing of a route containing sequential airway route elements for flights not eligible for a CLEARED AS FILED or THEN AS FILED clearance, the SYSTEM shall (a) Prohibit the controller from composing any departure clearance messages for that flight; (b) Prevent the generation of any departure clearance messages for that flight; Creates a discontinuity or a (c) Prohibit the establishment of any CPDLC sessions with that partial load? aircraft; Provide identified fix when airway (c) Respond to all received downlink messages that require a to airway is filed by the user and response for that flight with an uplink message containing only UM 162 SERVICE UNAVAILABLE; a UM 79/80/83 is sent by the controller. (Controller overrides (d) Terminate any existing CPDLC session for that flight; (e) Ignore all downlink messages for that flight that cannot be CAF) associated with an open transaction TDLS to reject airway-airway NEW WSSD routes. When the controller attempts to override a system generated ERAM adaptation may be changed to provide fix between Cleared As Filed DCL with a UM 80 CLEARED (routeclearance) airways. This fix will be sent in a DCL or a UM 79 if a UM 80 cannot be generated and the route DCL if provided by ERAM. contains sequential airway route elements, the system shall Does not apply to CAF provide an indication to the controller that a non-CAF DCL cannot be created 5 UM 83 Switch SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 17

IOC/ISD Requirements (3 of 4) ID 7 Title Source/Intere st Group Notes Entrance/Exit Fixes and Airways; Double Aircraft TO Interopability WSSD Changes: ID: WSSD 15461 From: The (position) in a UM 79 CLEARED TO (position) VIA (routeclearance) shall be repeated as the last element in variable [8], routeinformation of the routeclearance variable. To: When the position element in a UM 79 CLEARED TO (position) VIA (routeclearance) is also an airway termination point for an airway that is the last element in the routeinformation field, the SYSTEM shall repeat the position element variable in the routeinformation variable of the Repeats TO position to routeclearance variable. clearance variable in UM 79 and ID: WSSD 15462 UM 83 for only those points that From: are airway exit/entrance points. The (position) in a UM 83 AT (position) VIA (routeclearance) shall be repeated as the first element in variable [8], routeinformation of the routeclearance variable. Constrain the repeat of “TO”/”AT” position variable to To: When the position element in a UM 83 AT (position) VIA (routeclearance) is only those that are exit or entrance points to/from airways also an airway entry point for an airway that is the first element in the Open Issue: Can TDLS derive routeinformation field, the SYSTEM shall repeat the position element as the from existing schema using first element in the routeinformation variable of the routeclearance AWY? Assume yes. variable. Restricts any DCL to max of 20. New WSSD: The System shall prohibit the generation of a DCL clearance with more than 20 unnamed lat/lon elements in the route. Derivation Guidance: Unnamed lat/lons are not adapted waypoints in the standard NAV database, e. g. , Jeppesen. 8 Limit of 20 Lat/Lon elements in a Route clearnce Aircraft Interopability SE Production Sub-Team DCIT#31, 13 March 2014 Add termination stuff. . e. g. airway-airway termination rules Federal Aviation Administration 18

IOC/ISD Requirements (4 of 4) Source/Inter ID Title est Group Notes TDLS to Display Result of Scenario work runup to trials. all WILCO's Request from EWR and NATCA. Note: 9 including initials Controller Rogers are converted to WILCO's TDLS to Display 10 Revision Numbers Controller Tower facility control of WILCO 11 displays. Controller Allow Controller CAF/Automode for only adding a SID 12 WSSD Changes No new WSSD Requirements Revision # in processed tab, editor window, pick list. See Thin Spec 1. 1 No new WSSD Requirements Requirement for facility control of display of WILCO's. New Thin Spec Requirement: The SYSTEM Current Requirement: WSSD 3417 -- (CHI) The SYSTEM shall provide the local facility the ability to control shall make available for display to the controller all display of WILCO responses to initial clearances. responses from an aircraft in response to a Departure Note: This does not include revised initial Clearance. clearances. SLC center adds a SID and will need to be Modify current CAF rules, if only the SID/Tranisition is discussed for roll-out -- Contingent on changing changed by ERAM it is still eligible for CAF only applies to CAF criteria initials. Only applies they are added when no SID was filed. IFCET to rewrite: The following parameters shall be mandatory for all initial or revised initial departure clearances: a. Climb Via Parameter or Maintain ALT parameter b. Expect Altitude Parameter (includes XX NM/MIN after departure) c. Departure Frequency Parameter Mandatory controller display fields: Climb Via/ALT; Expect 13 ALT; Dep Freq Controller Aircraft Interoperabili No blank choices in SID (NO SID would be ty displayed) TDLS system requirement SE Production Sub-Team cleanup. Defintion of System DCIT#31, 13 March 2014 14 Editable in WSSD Engineering Note: The Departure Procedure field shall have a "NO SID" as an adaptation option and not allow a blank field on the CHI. Nothing would be sent in this case for a DCL but No SID would be provided in a PDC. "Editable" is meant to mean that the controller can select various options. But in older TDLS documentation "Editable" means that the Federal Aviation controller can create their own free text messages. Current direction is to not allow Administration controllers any ability to enter text. IFCET will provide a definition 19

Multiple CD Position Build ID 15 Title Source/Interest Group Notes Arrival Procedures/Transition/ Aircraft Route Loading Interoperability WSSD Changes Facilitate loadability in FMS. ERAM may have to have rules to only allow published transitions onto arr procedure. Will need coordination with ERAM to ensure common fix for S 1 P 2 ERAM required to send additional info WSSD 240 (WSSD 3. 0) 3. 4. 2. 1. 1 For each TDLS airport, the SYSTEM shall support at least 1 clearance delivery position. 16 Multiple CD positions SE Production Sub-Team DCIT#31, 13 March 2014 Controller Must be in place prior to deployment of CPDLC to DFW Changes 1. WSSD 240: The system shall support PDC and CPDLC services for at least two positions at an airport. Note: These position could be within a single tower or at multiple towers supporting a single airport. 2. New WSSD: The system shall prevent an Aircraft ID (ACID) editing window from being opened while the entry for that ACID is open at a different position. Post-meeting from Craig: "The system shall allow only one position at a time to open the editor window for a flight (ACID). " Derivation Guidance: Only one position can view/edit a clearance at a time from any list or tab. There are different design approaches, e. g. , locking a database. Lower level details are TBD, such as a pop-up NOT YOUR CONTROL or graying out. The derivations also need to cover revisions by other positions. Highlighting would not impact, only selection/clicking. Federal Aviation Administration 20

NSDA Build ID Title Relogon – Improve sessions that can be maintained 17 Latency Time Value Source/Interest Notes Group All Improve sessions to be maintained (or restarted) due to relogon by aircraft. Some sessions are restarted in S 1 P 1. All LTV was a requirement for en route airspace. Tower will send an LTV to the aircraft once per session. Will not hold up any DM 25 or DCL uplink while waiting for LTV response. No dependency. One retry if LTV is not successful. Lack of Roger does not cause session termination by TDLS. ERAM will try the LTV again. If ERAM cannot get a Roger to LTV, then ERAM will terminate session. Eligibility is not assigned prior to Roger. 17 19 Improve multiple indicator and search Controller 20 Improved Session Indicator Controller 21 22 Improved info on Session tab NSDA implementation - WSSD 23 NSDA implementation - ERAM-TDLS IRD Controller System Engineering SE Production Sub-Team DCIT#31, 13 March 2014 Check against other flight plans with an adaptable timer. ERAM to provide indicator to TDLS that multiple flight plans exist for that AID. Tail number may also be used to find duplicates add DP or Assigned ALT to the session window 1. ERAM and TDLS versions (KUSA or KMEM) –Add field to VER message (MHP management message) at ICD level 2. Session Termination by TDLS –Manual session terminations by CD or pilot or system terminations (timeout, remove strip, error conditions) –Add to existing UF/SU any Message ID Number that does not have a closure response when TDLS passes back the LDA token Federal Aviation Administration 21

S 1 P 2 Initial Title Source/Interest Group Notes Indicator of “XXX” in the flight plan (could be combined with Editing in Editor window? ) All Emergency Message Support All DM 55, 56 and others Add Emergency Session flag to TEDC (set/Remove) Dumping of Initials would not terminate CPDLC services. Decouple dump and session terminate Controller Error Reason Codes available for display in Pick list ID 24 Controller Mouse click once for selection Controller FOC CC of all messages sent to AC Allow Pilot responses to be sent to FOC Allow Pilot requests to be sent to FOC Is this a requirement and when? – ERAM may not do it? 25 26 27 28 29 Expand info sent to FOC SE Production Sub-Team DCIT#31, 13 March 2014 Federal Aviation Administration 22

S 1 P 2 Final ID 30 Matching Departure procedure and departure runway to make them loadable Source/Interest Group Notes Have to change the procedure in the tower? Make it a TFDM Aircraft Interoperability requirement? Include Runway Assignment in DCL Aircraft Interoperability Multicast - ATIS Code All Multicast - Stuck Mic All Multicast - TFM Advisories 31 Title All Multicast - Altimeter Settings Automode for Revised Initials Automode for trajectory changing Revisions Automode for non-trajectory changing All All Editing in the DCL Editor Window (e. g. flight plan amendments from DCL window) - FDIO/DCL Integration Controller 32 33 34 35 36 37 38 39 40 3 rd Column in Process View Controller Session Status display on more than the session tab Controller 41 SE Production Sub-Team DCIT#31, 13 March 2014 631 -7… or as a serial message to individual aircraft Change to Low? Make this a TFDM requirement? currently cannot fit 3 rd column due to "Awaiting Airline ACK" and "Not-Participating" Review with NATCA. Get more data from S 1 P 1 Is this required earlier? Federal Aviation Administration 23