Download
1 / 23
230 likes | 384 Views
Data Comm Production Summary vs. Trials:. Presented To: DCIT WGs By: Production Sub-Team Date: March 13, 2014. Agenda. IOC/Post-IOC Requirements Approach Aircraft interoperability issues Future releases Production DCL End to End Document Comments Next Steps.
E N D
Data Comm Production Summary vs. Trials: Presented To: DCIT WGs By: Production Sub-Team Date: March 13, 2014
Agenda • IOC/Post-IOC Requirements Approach • Aircraft interoperability issues • Future releases • Production DCL End to End Document • Comments • Next Steps
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
Production Post-IOC Release Strategy: Summary • Current proposed Tower “Releases”. All dates or contents still TBD. • 2015 - S1P1 IOC • Start of Waterfall • Must Have Keysite Fixes/Clean Up • 2015 – S1P1 ISD • In Service Decision • Must Have for Operational Decision • 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
Production Post-IOC Release Strategy: cont’d • 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 • 2017/2018 - S1P2 Tower Initial/Final • CHI enhancements • New requirements • Session integration across CONUS
IOC/ISD Aircraft Interop Requirements (1/2) • 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 • 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 • UM83 Switch • National Switch to disable UM83 • UM80 would replace UM83
IOC/ISD Aircraft Interop Requirements (2/2) • 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 • 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) • 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
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
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
Production DCL End2End Summary: • Example Deltas between Production and Trials • 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 • No STANDBY if user logs on early (prior to P-Time-30 min) • 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 • UM83 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
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)
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
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.
