EUROCAE WG-78 / RTCA SC-214 Plenary #19 Koln, Germany 26-30 August 2013

1. EUROCAE WG-78 / RTCA SC-214 Plenary #19 Koln, Germany 26-30 August 2013 CSG Progress Report Meeting Objectives Work Organisation Jane HAMELINK , (THANE) RTCA CSG Co-Chair Thierry LELIEVRE, (ALTRAN) EUROCAE CSG Co-Chair

2. SC214/WG78 CSG Meetings and Webex (sincePlenary #16, Washington DC, December 2012) Sub-Group Meeting Barcelona June 2013 SPR / INTEROP Version L 29 July 2013 Sub-Group Meeting Melbourne, March 2013 SC214/WG78 InternalReview [1/04 – 31/05] SPR/INTEROP Editors Meeting, Lansing, July 2013 937 Comments • SC217/WG44 Coordination on Airport Mapping Data Base to support D-TAXI Graphical display based on D-TAXI Clearance. • Weekly OSA Webex Weekly CSG Webex

3. Overview of SPR/INTEROP Comment Resolution • 976 Comments • 127 Comments remain Open • 52 are OPA related • 25 are OSA related • Resolution is under progress • 70 Comments remain Working • CSG assessment is required • 34 PDRs created against version K

4. Overview of some of open issues (1/5) • ADS-C / Aircraft ADS-C Connection Priority Allocation for ADS-C Reporting • See Airbus/Showstopper #429 - Addressed in Barcelona. • Consider introducing mechanisms to ensure proper priority is given to concurrent event reports when similar event contracts are in place on different connections. Simplest solution (addressing most of the cases) might be to give priority to CDA. • As per Barcelona minutes, two solutions for allocation of priority to ADS-C connections have to be assessed: • Adding a Priority flag in each ADS-C Request • Last ADS-C connection established, First ADS-C Connection served • Action to Members: Each solution has to be assessed in more details in order to deem if it reduces the performance impact and its feasibility notably impact on system (ground and air). • CSG Webex [21August2013 ], THALES raised a concern about the two solutions. Both are bringing complexity (and implementation cost) in the management of ADS-C Connections. THALES is not in favor of having such priority allocation in the standard.

5. Overview of some of open issues (2/5) • How to handleLevel/Speed/Heading confirmation with R-ATSU duringtransfer? • Position Paper presented in Barcelona by Eurocontrol, Maastricht MUACC. • As per the CSG agreement’s in Barcelona, SPR/INTEROP Editors presented the proposed changes to the CONTACT instructions in order to [optionally] advise the pilot to report via voice his assigned Level, heading and/or speed to the next ATSU during the contact. • After the Barcelona’s meeting, FAA confirmed that such a changes shall be also applicable to the MONITOR Instructions allowing the aircraft to send via datalink [automatically or not], the assigned Level, heading and/or speed report to the next ATSU. • During CSG Webex [10July2013], BOEING and some manufacturers put an design/implementation issue forward as an argument: • against sending the report via datalink to the next ATSU. Current cockpit design does not allow to send a report without being requested by the ground; • against changing the current CONTACT Instruction to allow different combination of variables in order to meet the operational needs. BOEING recommends to add new messages and to not change current CONTACT Messages. • CSG proposed another solution to solve the issue and to satisfy the operational need: • When it is required, the receiving ATSU will request [automatically] the Heading and/or Speed (as already done for the assigned Level in ACM operating method tables) .  Advantages are No change on current avionic behaviors and No changes on current CONTACT/MONITOR Instructions. It requires only new uplink messages and new downlink messages for  CONFIRM/REPORT ASSIGNED Heading.  The ones for the level and Speed already exist (UM135/DM38 and UM136/DM39). • Minor change in ACM Operating Method Tables is also required (adding for the receiving ATSU the confirm assigned speed and/or heading in addition to the confirm assigned level). • Action CSG to assess acceptability of this solution with Maastricht and FAA and with the rest of the group.

6. Overview of some of open issues (3/5) • Proposal to eliminateCPLDC/ADS-C Duplication (prepared by BOEING / AIRBUS) • Position Paper presented in Barcelona => To be considered at Plenary#19 for coordination with OPLINK. • The size and complexity of the CPDLC and ADS message sets in the standard being developed by WG-78/SC-214 will drive the cost of implementing it, both on the ground and in the airborne systems. • There are a number of areas of duplication between the ADS-C application and the CPDLC application that would drive unnecessary cost. This paper examines the potential for minimizing the duplication, and making it more affordable. • CSG agreed that this proposal has to be presented to next OPLINK (next October) for approval before changes would be made to the SC214/WG78 SPR/INTEROP. Thus, no change will be made to the SPR/INTEROP for FRAC. If OPLINK approves the proposal this will be considered as part of the FRAC Comments. • Action to AIRBUS/BOEING: To prepare a position paper for Plenary#19 (August 2013) for approval to be proposed as an input for next OPLINK meeting. • Action SPR/INTEROP Editors: To assess the impact on SPR/INTEROP and especially on FANS Accommodation (PU-30) and ATN B1 Backward compatibility (PU-70).

7. Overview of some of open issues (4/5) • Promote the “CM Server Concept” prepared by AIRBUS • Position Paper presented in Barcelona • Barcelona decision: CSG recognized the issue pertaining to a ground CM server in this paper and CSG agreed with reinforcing in B2 Standards capabilities that support the optimization of the airborne CM Database.   • Action to AIRBUS: to propose B2 Standards modifications in order to reinforce capabilities that support CM Server solution for ATN connection initiation. • Coordination is on-going with Arinc and Sita to adopt a common “position” on the CM server concept. • A coordination meeting between Airbus/Arinc/Sita is planned in September.  • So there is a risk that the necessary changes won’t be taken into account in the FRAC version • Issues on Annex H – EPP data provision • The « 29 July » Version posted on the website contains what was agreed on during the Barcelona meeting; • As agreed during the Barcelona meeting, Gordon provided the figures to illustrate the expected EPP contents. See e-mail from Joachim last Thursday. • As Gordon and Joachim were going back and forth on them, they determined that some additions/changes are required to the lateral- and vertical-type in order to concisely describe the predicted trajectory. • To be assessed during the CSG Session

8. Overview of some of open issues (5/5) • Editorial - References to IM and ITP SPR in section 3 • See comment#383 : Agreed to add ref FIM and ITP SPR when known. • To be discussed at next plenary how to handle such references. • Editorial - Annex H EPP Data Provision and Annex I Rules for FMS Loading • Shall it be part of SPR or INTEROP? • OPA Issues • Discuss Showstopper Cmt #173 (Airbus): AC-timing for RSP120 • Agree on CSG resolutions for Showstoppers #112, 147, 169 and 170 (Airbus) and redlined Annex D, E, F of version M. • Discuss Wim’s resolution to comment #xx (change RCP120 to RCP130) and redlined updates to Annex E of version M. • Discuss Wim’s comment #xx on removal DCL-RCP from the global perf tables • Review other open comments (Airbus) • OSA Issues • To be completed with Thomas

9. 1 Position Paper • DSC Removal prepared by BOEING / AIRBUS • This position paper highlights the significant impacts, both operational and technical, associated with the implementation of the DownStream Clearance (DSC) capability as part of Baseline 2 packages. The technical impacts would induce significant cost to the avionics. This paper also introduces the potential options that could be made available when Baseline 2 operations are deployed to provide similar operational intent. • While the convergence towards a common Data Comm solution should remain the overarching objective of SC214/WG78, Airbus and Boeing support a pragmatic and global approach that would balance the operational needs (considering potential workarounds or alternative operational procedures) with the associated costs. • Proposed Action:WG-78/SC-214 is invited to consider the proposal to remove DSC capability from Baseline 2 SPR & Interop release, and if approved, take appropriate actions (ToRs revision and update of standards before FRAC/Open Consultation).

10. Meeting Objective Complete the SPR/INTEROP Comment Resolution • To address major Issues listed • To address resolution of Open/Working Comments • To review and assess the Position Paper • What else? To deliver for FRAC in due time

11. CSG SESSION organisation

12. Remark ? Comment ? Proposal? 12

13. Spareslides 13

14. SPR/INTEROP Document Status (Not considering the Open/Workingcomments) • PU-10 SPR • Section 1 – Introduction • Section 2 – ATS Functions : • OSA/OPA Chapter references to be updated • RCP Values to be updated according to OPA results • Missing values for Non Data communication assumption (e.g. RNP xx for CDP) • Section 3 – Service Description • Section 4 – CM Application • Section 5 – CPLDC • Section 6 – ADS-C • New format for ADS-C Variable, Range and Resolution Table to be done • OSA/OPA Results to be integrated • OSA Annexes • ADS-C OSA under development • OPA Annexes • Annex H - EPP Data Provision • Still under development • Annex I – Rules for FMS Loading • To check consistency with Section 5 • PU-20 Baseline 2 INTEROP • Update of CPLDC PI/OCS under progress • PU-30 FANS/Baseline 2 INTEROP • Update of ADS-C under progress • PU-40 PM ADS-C • PU-70 Baseline 2 with B1 BC INTEROP

15. Overview of some of open issues (2/6) • Proposed changes in Route Clearance Parameters and Messages • Some CPDLC ORs are restricting the provision of departure or arrival information in the [route clearanceR] parameter depending if it is used in UM79, UM80, UM83. • Instead of having such ORs and associated Error cases, Editors propose to constraint the use of departure and arrival information at ASN-1 level: • Removal of dep/arr information from [route clearanceR] parameter; • Definition of new [departure dataO] and [arrival approach dataO] parameters containing respectively the departure and arrival information; • Modify the message containing route clearanceR parameter as follow: • UM79 CLEARED TO [positionR] VIA [departure dataO][ [route clearanceR] • UM80 CLEARED [departure dataO] [route clearanceR][arrival approach data] • UM83 AT [position ATW] CLEARED [route clearanceR] [arrival approach data] • DM24 REQUEST CLEARANCE [departure dataO][route clearanceR][arrival approach dataO] • DM40 ASSIGNED ROUTE [departure dataO][route clearanceR][arrival approach dataO]   • Group approval is required • CPLDC / UM293 VERIFY MONITORING FREQUENCY [frequencyR]seems Useless/Ambiguous • Indeed, the ground controller expects that the flight crew will check if the specified frequency is being monitored, and if it is not the case, he expects the flight crew to change the monitored frequency to the appropriate value and to contact the ground controller. • Besides, UM117 seems to suit with the expected operational intent without needing to add a new message. • Action JH: To check with FAA (Gregg, Jerry / Flight Standard) if they need it. If required then the intent as to be clarified according to the operational use.