Federal Aviation Administration Data Comm Production Summary vs. Trials: Presented To: DCIT WGs By:...

Federal AviationAdministrationData Comm

Production Summary vs. Trials:

Presented To: DCIT WGs

By: Production Sub-Team

Date: March 13, 2014

SE Production Sub-Team

DCIT#31, 13 March 20142Federal Aviation

Administration

Agenda

• IOC/Post-IOC Requirements Approach– Aircraft interoperability issues– Future releases

• Production DCL End to End Document– Comments

• Next Steps



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



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



Administration

Production Post-IOC Release Strategy: cont’d4. 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



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



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



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



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



Administration

Production DCL End2End Summary:

• Example Deltas between Production and Trials1. Users designate DCL and PDC flights via ICAO Flight Plan filing and

Subscriber Data Base (SDB); no more FRC DCL in Field 18 REM/ field2. 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



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 ([email protected]), Bruce

Notley ([email protected]) and Rob Mead ([email protected])



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



Administration

Questions?



Administration

BACK UP



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.



Administration

IOC/ISD Requirements (1 of 4)ID Title

Source/Interest Group Notes WSSD Changes

1Local 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


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

3DCL Message & Field Format content


Updates to the message formats in accordance with Trials lessons learned. Format for TDLS will match DTAP release 7.2 TDLS 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)


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 WSSDThe SYSTEM shall retry establishment of a connection with an aircraft a single time when the aircraft rejects a connection request.

New WSSDThe 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.



Administration



5 UM83 SwitchAircraft Interopability

Send a UM80 if a UM83 would normally be sent if UM83 switch is set to off. National level switchDCIT 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.


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 WSSDWhen 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



Administration



7

Entrance/Exit Fixes and Airways; Double TO


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 airwaysOpen 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


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



Administration



9

TDLS to Display all WILCO's including initials Controller

Result of Scenario work runup to trials. Request from EWR and NATCA. Note: Rogers are converted to WILCO's No new WSSD Requirements

10TDLS to Display Revision Numbers Controller

Revision # in processed tab, editor window, pick list. See Thin Spec 1.1 No 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

Controller SLC 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

ControllerAircraft Interoperability

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



Administration

Multiple CD Position BuildID Title


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 S1P2 ERAM required to send additional info

16 Multiple CD positions Controller

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.

Changes1. 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.



Administration

NSDA BuildID Title Source/Interest

GroupNotes

17

Relogon – Improve sessions that can be maintained

All Improve sessions to be maintained (or restarted) due to relogon by aircraft. Some sessions are restarted in S1P1.

17

Latency Time Value 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 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 search Controller 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

20 Improved Session Indicator Controller

21 Improved info on Session tab Controller add DP or Assigned ALT to the session window 22 NSDA implementation - WSSD System

Engineering

23 NSDA implementation - ERAM-TDLS IRD System Engineering

1.ERAM and TDLS versions (KUSA or KMEM)–Add field to VER message (MHP management message) at ICD level2.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



Administration

S1P2 InitialID Title

Source/Interest Group Notes

24

Indicator of “XXX” in the flight plan (could be combined with Editing in Editor window?) All

25

Emergency Message Support All

DM 55,56 and othersAdd Emergency Session flag to TEDC (set/Remove)

26 Dumping of Initials would not terminate CPDLC services. Decouple dump and session terminate Controller

27

Error Reason Codes available for display in Pick list Controller 28

Mouse click once for selection Controller 29

Expand info sent to FOC FOC

CC of all messages sent to ACAllow Pilot responses to be sent to FOCAllow Pilot requests to be sent to FOCIs this a requirement and when? – ERAM may not do it?



Administration

S1P2 FinalID Title Source/Interest Group Notes30

Matching Departure procedure and departure runway to make them loadable Aircraft Interoperability

Have to change the procedure in the tower? Make it a TFDM requirement?

31Include Runway Assignment in DCL Aircraft Interoperability

32Multicast - ATIS Code All

631-7… or as a serial message to individual aircraft

33Multicast - Stuck Mic All


34Multicast - TFM Advisories All


35Multicast - Altimeter Settings All


36 Automode for Revised Initials All 37 Automode for trajectory changing Revisions All38 Automode for non-trajectory changing All 39

Editing in the DCL Editor Window (e.g. flight plan amendments from DCL window) - FDIO/DCL Integration Controller

Change to Low? Make this a TFDM requirement?

40

3rd Column in Process View Controller

currently cannot fit 3rd column due to "Awaiting Airline ACK" and "Not-Participating"

41

Session Status display on more than the session tab Controller

Review with NATCA. Get more data from S1P1Is this required earlier?

Federal Aviation Administration Data Comm Production Summary vs. Trials: Presented To: DCIT WGs By:...

Documents

Transcript of Federal Aviation Administration Data Comm Production Summary vs. Trials: Presented To: DCIT WGs By:...