1 / 27

EUROCAE WG-78 / RTCA SC-214 Plenary #14 / Configuration Sub-Group Washington DC 5–9 December 2011

EUROCAE WG-78 / RTCA SC-214 Plenary #14 / Configuration Sub-Group Washington DC 5–9 December 2011. CSG Progress Report Next Steps. Jane HAMELINK , (THANE) RTCA CSG Co-Chair Thierry LELIEVRE , (ALTRAN) EUROCAE CSG Co-Chair. Overview of CSG Session work.

koko
Télécharger la présentation

EUROCAE WG-78 / RTCA SC-214 Plenary #14 / Configuration Sub-Group Washington DC 5–9 December 2011

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. EUROCAE WG-78 / RTCA SC-214 Plenary #14 / Configuration Sub-Group Washington DC 5–9 December 2011 CSG Progress Report Next Steps Jane HAMELINK , (THANE) RTCA CSG Co-Chair Thierry LELIEVRE, (ALTRAN) EUROCAE CSG Co-Chair

  2. Overview of CSG Session work • 10 Showstoppers have been resolved • 4 Interop PDRs • Review of Route Clearance Handling (white paperfrom Boeing/Airbus) • Proposal for Conditions for FMS Integration • Improvement of CPDLC Message Intents • Review and Improvement/optimisation of ERROR Case Tables

  3. Overview of 10 SPR Showstoppers • DCL OSD • To allow the provision of the part of the route that was modified in a Departure Clearance revision using UM#79R or UM#83R (instead of sending the whole route) • It will be much better from operational standpoint as it will be consistent with the way routeClearance messages loading into FMS Flight Plan is specified in §5 CSG agreed : • To remove route data information from UM#73R (as proposed by BOEING / AIRBUS in white paper on route clearance handling); • To use UM#80R for the provision of the whole route and UM#79R or UM#83R for the provision of the partial route; • UM#80R can be used for initial DCL • When Revision, the UM#325 REVISED [revision reason] is concatenated to UM#79R, UM#80R, or UM#83R • Action: To ensure that new UM73#R encompasses all the necessary data (e.g. Departure time,…) • PR OSD • To ensureconsistency and to avoid duplication of Requirements/Recommendationsbetween GOLD and SPR • SPR and GOLD should complement each other. Any duplication would lead to confusion and complexity. CSG agreed :to be done off line

  4. Overview of 10 SPR Showstoppers • 4DTRAD OSD • A lot of requirements are dealing with ground-ground capabilities. To Turn ORs or Orecs for Ground-Ground capabilities into assumptions (Note or explanatry text might be sufficient in this section). • Ground-ground capabilities are key enablers for 4DTRAD service and shall be tracked in the document. But they are more likely to be assumptions. Indeed, neither SPR nor Interop will provide any operational definition, Safety or Performance assessment for these functions. • Another SPR section should provide a clear list of all assumptions called out in the operational, Safety or Performance assessments of the services CSG agreed : • To get rid of Ground-Ground related Ors/Rec in 4DTRAD; • When required, to create Ground-Ground assumptions as part of the OSA • To add groudn-ground assumptions as part of the Non datalink assumption s for the ATS function 4 Dimension Trajectory Based Operations (4D TBO) • OCL OSD • Flight Crew should not be involved in DSC connection establishment. Flight Crew will request an OCL to a given OCEANIC ATSU. CPDLC connection management and DSC link establishment should be kept transparent from them • Remove UM364 and the requirement for the D-ATSU system to send it CSG agreed : to Remove UM364 and the the Flight Crew involvment in the DSC Connection establishment

  5. Overview of 10 SPR Showstoppers • DLIC / CM OSD • Current Airbus implementations never provide the DLIC Departure Time Field. In the cockpit, it is assumed to be a moving data, which evolves according to the latest constraints. If filled in by Flight Crew based on latest information and sent as part of the LogonRequest, it is very likely that it is not the same as the one in the filed Flight Plan. This would make it useless, or even worse detrimental, for flight plan correlation in ground systems, as it is unrealistic that a new Flight Plan is filed each time EOBT evolves • Consider adding a requirement to avoid including DLIC Departure Time Field in the Logon Request. CSG agreed : To avoid including DLIC Departure Time Field in the Logon Request; • CPDLC OSD / DM9 and DM10 REQUEST CLIMB/DESCEND TO [level] • Operational need covered by DM6 REQUEST [level] . In service experience raised a Human Factor issue with the use of active form "CLIMB TO" and "DESCEND TO" in a request (misunderstanding and inadequate actions from outdated messages in Message Record) • Remove DM9 & 10 from message set CSG agreed : To remove DM9 & 10 from message set ;

  6. Overview of 10 SPR Showstoppers • CPDLC OSD / UM134 REPORT [speed type] [speed type] [speed type] SPEED and DM113 [speed type] [speed type] [speed type] SPEED [speed] • Giving so many possibilities in the type of speed requested makes the message ambiguous. It would be better to define a message that would have an operational justification and that would have a chance to be integrated in the cockpit (e.g. providing automated response to the crew). • Modify UM134 to be REPORT [speedType] SPEED, with [speedType] being a choice between [indicated], [mach], or [noneSpecified]. Modify DM113 accoridngly. CSG agreed : to simplfy UM134 (and DM133). Proposal in under investigation. • CPC-OR-65 impliesthateachreceived messages shallbedisplayed to the Flight Crew • It was agreed that the requirement should not apply for SMM message elements. • Update CPC-65 to exclude SMM messages from this message display requirement. CSG agreed : • To exclude SMM message from messages from this message display requirement • List of “SMM” Messages have been assessed.

  7. Overview of 10 SPR Showstoppers • CPDLC OSD / UM134 REPORT [speed type] [speed type] [speed type] SPEED and DM113 [speed type] [speed type] [speed type] SPEED [speed] • Giving so many possibilities in the type of speed requested makes the message ambiguous. It would be better to define a message that would have an operational justification and that would have a chance to be integrated in the cockpit (e.g. providing automated response to the crew). • Modify UM134 to be REPORT [speedType] SPEED, with [speedType] being a choice between [indicated], [mach], or [noneSpecified]. Modify DM113 accoridngly. CSG agree : to simplfy UM134 (and DM133). Proposal in under investigation. • CPC-OR-65 impliesthateachreceived messages shallbedisplayed to the Flight Crew • It was agreed that the requirement should not apply for SMM message elements. • Update CPC-65 to exclude SMM messages from this message display requirement. CSG agree : • To exclude SMM message from messages from this message display requirement • List of “SMM” Messages have been assessed.

  8. Overview of 10 SPR Showstoppers • CPDLC / At the operationallevel, no more than one message elementwith [route clearance enhanced] parameter in a CPLDC message • Limitation to support no more than two message elements with the [route clearance enhanced] variable is considered at the Interop level. • At the operational level, there is no reason why an uplink should contain more than one [route clearance enhanced] variable.. • Update CPC-OR-72 as follows: A CPDLC message shall contain no more than one message element with the [route clearance enhanced] variable. CSG agreed : to allow CPDLC message containing no more than one message element with the [route clearance enhanced] variable. • ADS-C / Clarification on ADS-C Report generation time CSG agreed : • With the principle to define a generic ADS-C Report generation time that will be applicable for each type of contract and for each type of data block including EPP. Definition of different ADS-C report generation for ADS-C report conatining prediction data or ADS-C report not containing prediction data is not required. • Consistency with ADS-C OPA shall be ensured.

  9. RSTP TRN RSTP RSP Overview of 10 SPR Showstoppers AIRCRAFT ATSU ACSP Controller ATSU System Comm. service Aircraft System FMS (Initiator) ADS-C Request (Demand/Periodic/Event) Initial Response time ADS-C Generation Time Positive Ack Single/1st Periodic/ Baseline report Event occurrence or Period time out ADS-C Generation Time RSP=TRN Next Periodic/ Event Report N+1

  10. SC214/WG78 Document Management COMMENT: It would be highly beneficial for community to rely on unambiguous designators for each document comprised in WG78/SC214 deliverables (as it was done for example with "PU40" for Mixed Interop that became ED154/DO305 in the end). SUGGESTED CHANGE TO DOCUMENT: Define temporary designators for : - PUxx - Safety and Performance Requirements for Advanced ATS Data Communications - PUyy - Interop for Converged ATS Data Communications - PUzz - Mixed Interop for Converged ATS Data Communications COMMENT: Title of SPR should allow to unambiguously identify scope of document and differentiate it with preceding SPRs. SUGGESTED CHANGE TO DOCUMENT: Change Title to "Safety and Performance Requirements for Advanced ATS Data Communications". • CSG Proposal: - PU10 - Safety and Performance Requirements for Advanced ATS Data Communications - PU20 - Interop for Advanced ATS Data Communications - PU30 - Mixed Interop for Advanced ATS Data Communications

  11. Review of the Route Clearance White paper • CSG reviewed the paper and agreed on the following • To getrid of the route data information from UM#73R (use of UM80, UM79, UM83 for the provision of route information) • To delete placeBearingPlaceBearing from routeInformations • To delete interceptCourseFroms from routeInformationAdditional • To delete reportingpoints from routeInformationAdditional • To remove the choice between fixname and navaid for the publishedidentifier parameter • To replace the choices of navaid, fixname and airport for position with a single choice of “published identifier” • To include CR/LF as allowed characters in the freetext parameter • => Action: SPR section will be updated according to the content of this paper.

  12. Conditions for FMS Integration • CSG reviewed and agrred on the following minimum Conditions for requiring FMS Autoloading: • XXXXXXXX • => Action CSG: CPDLC / ADS-C Ors have to be created accordingly in respectivelly section 5 and 6. CSG Proposal: · a clearance where the route of flight contains more than one waypoint. · a clearance where the route of flight contains one waypoint specified by latitude/longitude with a resolution smaller tha whole degrees or place-bearing-distance.

  13. VP17- FAA Tech Center Validation CSG Result Consolidation • 3 documents provided to VSG / CSG • ATS INTEROP Test Report – Version 1.4 • ATS INTEROP Test Cases – Version 1.4 • ATS INTEROP TraceabilityMatrix – Version 1.4

  14. VP 17 – FAA Tech Center Validation Project • VH INTEROP Validation Results • Part 1 – Converged Applications • 72% validated by test or analysis • 15% modified through 6 PDRs • Part 3 – Backwards Compatibility • 100% out of scope • Part 2 – ATS Services • 78% validated by test or analysis • Parts 4/5 – ASN.1 • CM/CPDLC 100% validated • ADS-C/FIS out of scope

  15. PDR #314 - [DLIC] Processing the Ground Facility Designator received in the CM Logon Request • DLIC-Irec 6 • “In the case that designated facility is other than the facility responding to the logon request, the DLIC ATSU System should forward the aircraft logon information to the designated facility.” • There are 2 issues with the INTEROP statement: 1) this must be a "shall" requirement, not a “should”. 2) the action in case the forward is not possible is not specified.

  16. PDR #314 - [DLIC] Processing the Ground Facility Designator received in the CM Logon Request Proposal: modify DLIC-Irec 6 and DLIC-IR 25 • DLIC-IRec 6 • In the case that designated facility is other than the facility responding to the logon request, the DLIC ATSU System should forward the aircraft logon information to the designated facility. • to: DLIC-NIR 3 • In the case that designated facility is other than the facility responding to the logon request, the DLIC ATSU System shall forward the aircraft logon information to the designated facility. • DLIC-IR 25 • In the case that the designated facility is other than the facility responding to the logon request, the DLIC ATSU System shall include in the CM-logon response either : • […] • • no information if application information of the designated facility is not known. • to • • no information if application information of the designated facility is not known or if it failed to forward the received Logon information to the designated facility.

  17. PDR #313 – Error Handling • GEN-IR 4 “When a message or application service primitive of the ATS application defined in ICAO Document 9880 and Document [PM-FIS] is not supported in the implementation, then the ATSU System and Aircraft System shall provide appropriate indication to the user's), e.g. UM162 MESSAGE NOT SUPPORTED BY THIS ATS UNIT; or DM62 ERROR [error information]” • There are 2 issues with the INTEROP statement: 1) The IR is too general to be tested 2) it is redundant with CPC-IR 36 and CPC-IR 37 CPC-IR 36: When the ATSU System receives a CPDLC message with  a message element that is not operationally supported, the ATSU System shall discard the received message and send a CPDLC message containing message element UM162 MESSAGE NOT SUPPORTED BY THIS ATS UNIT. CPC-IR 37: When the Aircraft System receives a CPDLC message with at least one message element that it does not support, it shall discard the received message and send a CPDLC downlink message containing the concatenation of message element DM62 (ERROR (error information)) with the choice (4) followed by message element DM98 (MESSAGE NOT SUPPORTED BY THIS AIRCRAFT). • Proposal: delete GEN-IR 4

  18. PDR #298 – [INTEROP][CPDLC] Re-writting of "indirect" requirements • CPC-IR 11 “When the ATSU System receives a CPDLC message (except for emergency messages), and discards the message because CPDLC is not in use, then the ATSU System shall send a CPDLC uplink message containing the concatenation of message element UM159 (ERROR (error information)) with the choice (2) followed by message element UM183 (CPDLC NOT IN USE AT THIS TIME - USE VOICE). ” • Issue: requirement needs to be re-written, as it implies the existence of another, unknown requirement. Proposal: re-write CPC-IR 11 and all similar ERROR management IRs When the ATSU System receives a CPDLC message (except for emergency messages ) and CPDLC is not in use, then the ATSU System shall discard the message and send a CPDLC uplink message containing the concatenation of message element UM159 (ERROR (error information)) with the choice (2) followed by message element UM183 (CPDLC NOT IN USE AT THIS TIME - USE VOICE).

  19. PDR #313 – Error Handling • CPC-IR 17 “When a CPDLC message is received that results in an error not defined in the ICAO Document 9880 and not defined explicitly elsewhere in this document, the Aircraft System shall discard the received message and send a CPDLC downlink message containing the concatenation of message element DM62 (ERROR (error information)) with the choice (0) or choice (2) followed by message element DM98  composed of the fixed text “Undefined ERROR” plus optionally a user-defined free text.” • CPC-IR 18 “When a CPDLC message is received that results in an error, that is not already covered in ICAO Document 9880, and not defined explicitly elsewhere in this document, the ATSU System shall discard the message and send a CPDLC uplink message containing the message element UM159  (ERROR (error information)) with the choice (0) or choice (2) followed by message element UM183 composed of the fixed text “Undefined ERROR” plus optionally a user-defined free text.” Issue: Requirements very broad; requires listing all errors in 9880 and in the SPR, then formulating an uplink message that will result in an error that is not in either list. Degree of difficulty depends on number of errors listed and ability to search document. • Proposal: This "requirement" is intended for implementors in case they identify during system design some error cases that are not specified in the standard. These req are more guideline for writing specifications than real requirements on the ground or air system. Propose to move this requirement into a "note".

  20. PDR #313 – Error Handling • Issues: • CPC-IR 35 “When the ATSU System receives a concatenated downlink CPDLC message that it does not support (invalid element combination), it shall discard the received CPDLC message and send a CPDLC uplink message containing the concatenation of message element UM159 (ERROR (error information)) with the choice (3) followed by message element UM183  (ELEMENT COMBINATION REJECTED - USE VOICE). Issue: requirement is valid but should be re-written for clarity; i.e., "When the ATSU System receives a concatenated downlink CPDLC message that contains a message element combination that it does not support (e.g. XXXX combined with XXXX), it shall discard..." Recommend adding a note to clarify the reasons an element combination may be invalid; e.g. - some element combinations are invalid anywhere (for example, an uplink with "CLIMB TO XXXX" and "DESCEND TO YYYY"), whereas some may be unimplemented by the current version, prohibited by SARPs or other requirements, and finally some may be prohibited by local rules/preferences..

  21. PDR #311 – [CPDLC] Management of duplicate CPDLC messages • Issues: • CPC-IR 62 “Except when performing backwards compatibility, the ATSU System and the aircraft system shall be prohibited from sending the message elements containing the [time] parameter. Note 1: The equivalent messages element containing the [timesec] parameter can be used instead. Issue: CPC-IR 62 requires implementations to not use "old" version 1 (time) messages when new version 2(timesec) messages have been defined. The requirement should be extended to apply to all xxR (replacement messages) • Proposal: CPC-IR 62 Except when performing backwards compatibility, when the version 2 CPDLC message to be sent is a replacement of a version 1 CPDLC message, the CPDLC ATSU System and the Aircraft System shall be prohibited from sending the version 1 CPDLC message. Note 1: This is applicable for instance to new version 2 CPDLC messages defined to include the [timesec] parameter replacing a version 1 CPDLC message with the [time] parameter.

  22. PDR #312 – [CPDLC] Management of duplicate CPDLC messages (THALES finding) • Issues: The ambiguity stems from the specification document ICAO 9880 Part 1 for the Integrity Check procedure: two different implementations are described, characterized by the possibility (or lack thereof) for the first and third byte of the checksum to be equal to 0xFF. The standard reads: 2.3.16.2.2.1 Addition shall be performed in one of the two following modes: a) modulo 255, or b) ones complement arithmetic. 2.3.16.2.2.2 In the ones complement mode, if any of the variables has the value minus zero (i.e. 0xFFFF), it shall be regarded as though it were plus zero (i.e. 0). The ambiguity stems from the expected behavior during the computation of x0 and x2 when (C0+C1+C2+C3) and (C2+3*C3) are equal to 0x00. Two interpretations can be discussed: • The opposite of 0x00 is 0xFF and since para 2.3.16.2.2.1 only applies to addition operations, x0 or x2 is equal to 0xFF, or • The opposite of 0x00 is 0xFF and in accordance with para 2.3.16.2.2.1, x0 or x2 is equal to 0x00. • Proposal: To indicate in the standard which interpretation is correct To find examples of messages that can led to two checksum depending on the reading of the standard, coordinate with air and ground existing implementations and include the right encoding as an example in the SC-214 INTEROP document.

  23. PM Message Examples • First message CPDLC • Message type : dM0 • Date: 2010-12-06 @ 09:40:14, MessageID: 2, Lack required : no • Constrained Data : no • AircraftFlightIdentification : BAW70 • AircraftAddress (Hexa): 414558 • FacilityDesignation: TOUL • Checksum with correction : 5D5DFF10 • Checksum without correction : 5D5D0010 • Second message CPDLC • Message type : dM0 • Date: 2010-12-06 @ 09:40:14, MessageID: 2, Lack required : no • Constrained Data : no • AircraftFlightIdentification : BAW72 • AircraftAddress (Hexa): 414559 • FacilityDesignation: TOUL • Checksum with correction : 3551FF3E • Checksum without correction : 3551003E

  24. PDR #??? – CPDLC Inhibited State (THALES finding) • Issues: CPC-IR 7: The aircraft equipment shall be in (or revert to) the CPDLC inhibited state: • After a change of the flight identification, • after the end of a flight, • after a cold start, or • when CPDLC is turned off by the pilot. CPC-IR 9 When the aircraft is in the CPDLC inhibited state and the Aircraft System receives a CPDLC-start indication, the Aircraft System shall reject the CPDLC-start request, the CPDLC-start response shall include a CPDLC message containing the concatenation of message element DM62 (ERROR (error information)) with the choice (2) followed by message element DM98 (FLIGHT CREW HAS INHIBITED CPDLC). In the RTCA SC214 INTEROP vH document, the inhibited mode is used: • In case of CPDLC inhibition by the pilot, and • For the synchronization of the CPDLC application with other datalink applications (e.g. CM) and with the operational environment. The behavior specified in the requirement CPC-IR-9 is irrelevant when the CPDLC state is modified to inhibited following for example a change of flight ID (CM not logged on with the ground). • Proposal: The CPDLC inhibited mode could be split into two distinct modes: • CPDLC inhibited mode when CM is not logged or when some parameters required for proper CPDLC operation are not available (e.g. time); in this mode, CPDLC start requests are ignored. • CPDLC terminated mode controlled by the pilot

  25. Consolidation of CPLDC Message Set • CSG started consolidation of each CPLDC Message Intentorder to makethem consistent with the CPDLC Message text and itsopertaional use. • => Work in Progress ! • Excel Sheetwillbe no longer maintained. • DOC 4444 Redline • SPR • INTEROP • CSG Proposal: To provide OPLINK with changes in Range and Resoltuion (as part of Doc4444 red-line).

  26. Our CSG Priorities and next steps • SPR/INTEROP next release isexpected to bedelivered by MidJanuary 2012 • Resolution of Open PDRs • Consolidation of CPLDC Message Set • Resolution of Comments • Integration of Route Clearance Handling Section • Integration of OSA / OPA Results • Consolidation of FMS IntegrationRequirements • OPA / OSA Updates ? Progress throughdedicated Webex Weekly Webex – everyWednesday 4pm EU Time / 10am US Eastern time Dedicated Webex whenrequired

  27. « The final sprint for SPR/INTEROP Version I release » 27

More Related