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

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

3. SE Production Sub-Team DCIT#31, 13 March 2014 3 Federal Aviation Administration 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

4. SE Production Sub-Team DCIT#31, 13 March 2014 4 Federal Aviation Administration Production Post-IOC Release Strategy: Summary Current proposed Tower “Releases”. All dates or contents still TBD. 1.2015 - S1P1 IOC Start of Waterfall Must Have Keysite Fixes/Clean Up 2.2015 – S1P1 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

5. SE Production Sub-Team DCIT#31, 13 March 2014 5 Federal Aviation Administration 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 - S1P2 Tower Initial/Final CHI enhancements New requirements Session integration across CONUS

6. SE Production Sub-Team DCIT#31, 13 March 2014 6 Federal Aviation Administration 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, UM79, UM80 –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 CR1 or other error cases –Single Retry of a CR1 to aircraft after an adaptable parameter of time 3.UM83 Switch –National Switch to disable UM83 –UM80 would replace UM83

7. SE Production Sub-Team DCIT#31, 13 March 2014 7 Federal Aviation Administration 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.UM79/83 Repeat of POSITION variable –Repeats TO position in route clearance variable in UM79 and AT position in UM83, 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

8. SE Production Sub-Team DCIT#31, 13 March 2014 8 Federal Aviation Administration Other Aircraft Interop Requirements Multi-Clearance Delivery Position Build (End of S1P1 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 S1P1) –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) S1P2 (Requires more discussion) –Multicast (e.g., altimeter, D-ATIS code, advisories) –Automatic Revisions –Emergency Message support –Runway included in DCL

9. SE Production Sub-Team DCIT#31, 13 March 2014 9 Federal Aviation Administration 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

10. SE Production Sub-Team DCIT#31, 13 March 2014 10 Federal Aviation Administration Production DCL End2End Summary: Example Deltas between Production and Trials 1.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 2.CPDLC (Connection establishment) only after ATC approves the DCL No STANDBY if user logs on early (prior to P-Time-30 min) 3.NAV Database differences may result in differences for international flights, i.e., “TO” point for UM79? Production uses ERAM NAV DB; Trials has its own FAA NAV DB 4.UM83 is currently implemented in Production system; post-initial release to put in a switch 5.Gate Request Message to AOCs is a separate message, sent when controller approves the DCL 6.Fallback from DCL to PDC capability if user designates preference to do so

11. SE Production Sub-Team DCIT#31, 13 March 2014 11 Federal Aviation Administration Production End to End DCL Draft is based on Trials End2End, 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)cburr@mitre.orgBruce.Notley@faa.govrob.mead@boeing.com

12. SE Production Sub-Team DCIT#31, 13 March 2014 12 Federal Aviation Administration 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

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

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

15. SE Production Sub-Team DCIT#31, 13 March 2014 15 Federal Aviation Administration 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 UM79 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.

16. SE Production Sub-Team DCIT#31, 13 March 2014 16 Federal Aviation Administration IOC/ISD Requirements (1 of 4) IDTitle Source/Inte rest GroupNotesWSSD Changes 1 Local Departure Procedure Adaptation Aircraft Interopability 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 adaptable fields for each DP- Transition pair. 2 Error check ERAM supplied DP/Transition Fix against TDLS DP adaptation Aircraft Interopability 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 DP- Transition pair received from ERAM does not match any locally adapted DP-Transition pairs, the system shall display the flight ID to the controller with an error indicator. Flight is inelgible for DCL 3 DCL Message & Field Format content Aircraft Interopability Updates to the message formats in accordance with Trials lessons learned. Format for TDLS will match DTAP release 7.2TDLS Format V2.2 4 Automatic retry of connection request when TDLS receives a disconnect request in response to a CR1 or other error cases (CR1 timeout) Aircraft Interopability When TDLS receives a disconnect request in response to a CR1 or other error cases (CR1 timeout) the ground system will retry a single time. Planned for an adaptable timer for a single retry -- 30 seconds to 2 minutes New WSSD The SYSTEM shall retry establishment of a connection with an aircraft a single time when the aircraft rejects a connection request. New WSSD The SYSTEM shall have an adaptable time parameter for sending a retry of a connection request in the event of an error or an aircraft reject of the initial connection request.

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

18. SE Production Sub-Team DCIT#31, 13 March 2014 18 Federal Aviation Administration IOC/ISD Requirements (3 of 4) ID Title Source/Intere st GroupNotesWSSD Changes 7 Entrance/Exit Fixes and Airways; Double TO Aircraft Interopability Repeats TO position to route clearance variable in UM79 and UM83 for only those points that are airway exit/entrance points. Constrain the repeat of “TO”/”AT” position variable to only those that are exit or entrance points to/from airways Open Issue: Can TDLS derive from existing schema using AWY? Assume yes. WSSD Changes: ID: WSSD15461 From: The (position) in a UM79 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 UM79 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 routeclearance variable. ID: WSSD15462 From: The (position) in a UM83 AT (position) VIA (routeclearance) shall be repeated as the first element in variable [8], routeinformation of the routeclearance variable. To: When the position element in a UM83 AT (position) VIA (routeclearance) is also an airway entry point for an airway that is the first element in the routeinformation field, the SYSTEM shall repeat the position element as the first element in the in the routeinformation variable of the routeclearance variable. 8 Limit of 20 Lat/Lon elements in a Route clearnce Aircraft Interopability 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. Add termination stuff.. e.g. airway-airway termination rules

19. SE Production Sub-Team DCIT#31, 13 March 2014 19 Federal Aviation Administration IOC/ISD Requirements (4 of 4) ID Title Source/Inter est GroupNotesWSSD Changes 9 TDLS to Display all WILCO's including initialsController Result of Scenario work runup to trials. Request from EWR and NATCA. Note: Rogers are converted to WILCO'sNo new WSSD Requirements 10 TDLS to Display Revision NumbersController Revision # in processed tab, editor window, pick list. See Thin Spec 1.1No new WSSD Requirements 11 Tower facility control of WILCO displays.Controller Requirement for facility control of display of WILCO's. New Thin Spec Requirement: The SYSTEM shall provide the local facility the ability to control display of WILCO responses to initial clearances. Note: This does not include revised initial clearances. Current Requirement: WSSD 3417 -- (CHI) The SYSTEM shall make available for display to the controller all responses from an aircraft in response to a Departure Clearance. 12 Allow CAF/Automode for only adding a SID ControllerSLC center adds a SID and will need to be discussed for roll-out -- Contingent on changing CAF criteria Modify current CAF rules, if only the SID/Tranisition is changed by ERAM it is still eligible for CAF only applies to initials. Only applies they are added when no SID was filed. 13 Mandatory controller display fields: Climb Via/ALT; Expect ALT; Dep Freq Controller Aircraft Interoperabili ty No blank choices in SID (NO SID would be displayed) 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 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. 14 TDLS system requirement cleanup. Defintion of Editable in WSSD System Engineering "Editable" is meant to mean that the controller can select various options. But in older TDLS documentation "Editable" means that the controller can create their own free text messages. Current direction is to not allow controllers any ability to enter text.IFCET will provide a definition

20. SE Production Sub-Team DCIT#31, 13 March 2014 20 Federal Aviation Administration Multiple CD Position Build ID Title Source/Interest GroupNotesWSSD Changes 15 Arrival Procedures/Transition/ Route Loading Aircraft Interoperability 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 S1P2ERAM required to send additional info 16 Multiple CD positionsController Must be in place prior to deployment of CPDLC to DFW WSSD240 (WSSD 3.0) 3.4.2.1.1 For each TDLS airport, the SYSTEM shall support at least 1 clearance delivery position. Changes 1. WSSD240: 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.

21. SE Production Sub-Team DCIT#31, 13 March 2014 21 Federal Aviation Administration NSDA Build IDTitleSource/Interest Group Notes 17 Relogon – Improve sessions that can be maintained AllImprove sessions to be maintained (or restarted) due to relogon by aircraft. Some sessions are restarted in S1P1. 17 Latency Time ValueAllLTV was a requirement for en route airspace. Tower will send an LTV to the aircraft once per session. Will not hold up any DM25 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. 19 Improve multiple indicator and searchControllerCheck 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 20 Improved Session IndicatorController 21 Improved info on Session tabControlleradd DP or Assigned ALT to the session window 22 NSDA implementation - WSSDSystem Engineering 23 NSDA implementation - ERAM-TDLS IRDSystem Engineering 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

22. SE Production Sub-Team DCIT#31, 13 March 2014 22 Federal Aviation Administration S1P2 Initial IDTitle Source/Interest GroupNotes 24 Indicator of “XXX” in the flight plan (could be combined with Editing in Editor window?)All 25 Emergency Message SupportAll DM 55,56 and others Add Emergency Session flag to TEDC (set/Remove) 26 Dumping of Initials would not terminate CPDLC services. Decouple dump and session terminateController 27 Error Reason Codes available for display in Pick listController 28 Mouse click once for selectionController 29 Expand info sent to FOCFOC 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?

23. SE Production Sub-Team DCIT#31, 13 March 2014 23 Federal Aviation Administration S1P2 Final IDTitleSource/Interest GroupNotes 30 Matching Departure procedure and departure runway to make them loadableAircraft Interoperability Have to change the procedure in the tower? Make it a TFDM requirement? 31 Include Runway Assignment in DCLAircraft Interoperability 32 Multicast - ATIS CodeAll 631-7… or as a serial message to individual aircraft 33 Multicast - Stuck MicAll 631-7… or as a serial message to individual aircraft 34 Multicast - TFM AdvisoriesAll 631-7… or as a serial message to individual aircraft 35 Multicast - Altimeter SettingsAll 631-7… or as a serial message to individual aircraft 36 Automode for Revised InitialsAll 37 Automode for trajectory changing RevisionsAll 38 Automode for non-trajectory changingAll 39 Editing in the DCL Editor Window (e.g. flight plan amendments from DCL window) - FDIO/DCL IntegrationController Change to Low? Make this a TFDM requirement? 40 3rd Column in Process ViewController currently cannot fit 3rd column due to "Awaiting Airline ACK" and "Not-Participating" 41 Session Status display on more than the session tabController Review with NATCA. Get more data from S1P1 Is this required earlier?