Title: CPDLC - Route Clearance PDR Reference: 97100039 Originator Reference: Size SARPs Document Reference: CPDLC SARPs, Section 2.3.4.2.1 Status: ADOPTED PDR Revision Date: 29/95/97 (alignment to ICAO 2.2 SARPs - see PDR 98050019) 16/12/97 (PROPOSED -> RESOLVED) 10/12/97 (amendment to the proposed change To take into account the Forward PDU) 09/12/97 (ACCEPTED -> PROPOSED) 29/10/97 (SUBMITTED -> ACCEPTED) 18/12/97 (RESOLVED) PDR Submission Date: 29/10/97 Submitting State/Organization: Aerospatiale Submitting Author Name: Camus, P Submitting Author E-mail Address: teuchos.mp@wanadoo.fr Submitting Author Supplemental Contact Information: Teuchos 20 Chemin Laporte 31300 Toulouse tel. 33.(0)5.61.30.90.46 fax. 33.(0)5.61.30.90.33 SARPs Date: IV1.1, March 97 SARPs Language: English Summary of Defect: Any given CPDLC message can contain from 1 to 5 message elements. Although there are some operational requirements (constraints) imposed on the CPDLC user (SARPs section 2.3.7) concerning the composition of CPDLC messages, these constraints are not similarly imposed on the ASN.1 definitions (SARPs section 2.3.4). In particular the operational requirements restrict a user from providing more than two message elements containing a route clearance in any given CPDLC message. However, the ASN.1 does not contain a similar constraint, nor does the receiving ASE check this. Thus if an ASE receives a CPDLC message with more than 2 route clearance message elements, having no other instructions, the ASE must pass this message to its user. The route clearance message element can be very large when decoded. Requiring a CPDLC implementor to provide a capability to receive a CPDLC message with 5 route clearance message elements, since this can technically happen, when operationally this scenario is not valid, is unacceptable. Therefore, it is proposed to reflect in the ASN.1 the constraint of two route clearance message elements in a CPDLC message. Detailed Analysis of the Defect: The amendment proposed in this PDR is not only an evolution or an enhancement of the SARPs, but it is a major change that, if implemented after the first ICAO version of the SARPs, would affect backward compatibility. It is therefore essential that, whatever the solution is, it is taken into account before endorsement of the SARPs by ICAO. The main issues raised by this PDR are the following: . Sizing requirements are based on ASN.1 requirements of SARPs section 2.3.4. The implementation of the CPDLC SARPs has highlighted an unforeseen drawback of the ASN.1 message data structure. In fact,with the tools currently available on the market, the ASN.1 compilation is done according to the type 'ATCDownlink/UplinkMsgElementId'. Since the 'ATCDownlink/UplinkMsgElementId' is present five times inthe message structure, the compiler reserves five times the memory space corresponding to this type which is well above the operational requirements. . The current ASN.1 definition is not optimised and requires a large amount of memory compared to other usual airborne specifications.The ASN.1 proposed in this PDR reduces drastically the size of the encoding/decoding structures (about unused 90K). This ASN.1 was evaluated and meet the expected objectives. . Dynamic resource allocation was considered but does not solve the issue of memory size. The dimensioning case is still the 5 message elements. In addition, DO-178B, in an example of forbidden structures, mentions 'dynamic objects'. For certification reason, the use ofdynamic resource allocation is very restricted and controlled in the airborne environment. The CPDLC message size issue is typically an environment dependent issue. . Airframe manufacturers have specific constraints related to the airborne environment (ruled by DO-160). Growth potential has to be preserved while making best effort to reduce size and consumption of airborne equipment with aim to reduce costs to airlines. However, the prime concern remains the cost of the equipment to airlines. . Automatic code generators offer industrial advantages such as: time, cost, safety, repeatability, adaptability to changes, which are beneficial to operators and therefore are incentives to migration towards ATN. However, this choice is in no way specific to the present issue. Would one have not used those tools, one would still maintain this PDR, which solves an inherent problem of the SARPs. Note: Certification of the airborne communication system is carried out in compliance with requirements from airworthiness authorities (FAA/JAA), particularly DO-178B level C for software. Logically, ground developers should also adopt this position. According to ATNP WOW/WP 2-2 (3-7 Nov 97), DO-178B requirements must be applied to the ground end system. Therefore, ground developers could have to meet the same constraints than airframe manufacturers: methodology, restriction in dynamic allocation, etc. . The ASN.1 provides a formal specification of data structures. An ASN.1 specification is self-sufficient and therefore self-controlled. Its very definition ensures detection of interoperability deviations and errors. To offer those safety, integrity and interoperability benefits, ASN.1 must be implemented as specified (it happens that the use of automatic code generators allows to strictly complying with ASN.1 without deviations). . During implementation, mixing decoding of ASN.1 with manual mechanisms or algorithms reflecting User Requirements deviates from ASN.1 formal specification purpose and is bad practice. This results in an ambiguity: an implementor cannot be ASN.1 compliant (5 route clearances per message) and SARPs compliant (only 2 routes clearances per message). We will end up with different implementation strategies that could jeopardise safety. . Therefore, in a system implementing the SARPs, ASN.1 interoperability and error detection checks have to take place when a message is decoded from PER, preliminary to any other processing. Only after this first stage, interoperability checks required by User Requirements (specific algorithms) can be carried out. These specific algorithms must be implemented at a different level because they are not part of the ASN.1 (ideally these requirements should be embedded within the ASN.1 as proposed by this PDR for the route clearance). It is the interest of the industry to amend today's SARPs, in order to avoid the penalty of implementing a message data structure that doesnot reflect the operational need. SME comments: The issue raised in this PDR was discussed by an extended SME2 Team comprising experts from CCB, ATNP/WG3, ATNP/WG3/SG2, industry and certification authorities. The proposed SARPs amendment reflects the view of most experts of this team. The complete set of messages exchanged on this topic is available on request. It was agreed that the user requirements stated in chapter 7 should not be reflected in extenso in the ASN.1 description of chapter 4. The rationale developed above showed that the route clearance problem was not a local implementation issue only and should be corrected in version 1 of the CPDLC application. The "do-nothing" solution prevents from doing something later with keeping backward compatibility and jeopardises the current implementations in airborne environments. The proposed SARPs modification allows to take into account the current implementation constraints and will allow in the future to cope with new CPDLC message elements with similar constraints. It does not change fundamentally the current structure of the CPDLC messages nor the message composition rules but defines an exception for the Route Clearance message element. Proposed SARPs amendment: 1/ Replace: ATCUplinkMessage ::= SEQUENCE { header ATCMessageHeader, elementIds SEQUENCE SIZE (1..5) OF ATCUplinkMsgElementId } with : ATCUplinkMessage ::= SEQUENCE { header ATCMessageHeader, messageData ATCUplinkMessageData } ATCUplinkMessageData ::= SEQUENCE { elementIds SEQUENCE SIZE (1..5) OF ATCUplinkMsgElementId, constrainedData SEQUENCE { routeClearanceData SEQUENCE SIZE (1..2) OF RouteClearance OPTIONAL, ... } OPTIONAL } 2/ Replace: ATCDownlinkMessage ::= SEQUENCE { header ATCMessageHeader, elementIds SEQUENCE SIZE (1..5) OF ATCDownlinkMsgElementId } with : ATCDownlinkMessage ::= SEQUENCE { header ATCMessageHeader, messageData ATCDownlinkMessageData } ATCDownlinkMessageData ::= SEQUENCE{ elementIds SEQUENCE SIZE (1..5) OF ATCDownlinkMsgElementId, constrainedData SEQUENCE { routeClearanceData SEQUENCE SIZE (1..2) OF RouteClearance OPTIONAL, ... } OPTIONAL } 3/ Replace: ForwardMessage ::= CHOICE { upElementIDs [0] SEQUENCE SIZE (1..5) OF ATCUplinkMsgElementId, downElementIDs [1] SEQUENCE SIZE (1..5) OF ATCDownlinkMsgElementId } by: ForwardMessage ::= CHOICE { upElementIDs [0] ATCUplinkMessageData, downElementIDs [1] ATCDownlinkMessageData } 4/ In ATCUplinkMsgElementId, replace the definition of the following message element from: uM79PositionRouteClearance [79] PositionRouteClearance, uM80RouteClearance [80] RouteClearance, uM83PositionRouteClearance [83] PositionRouteClearance, uM85RouteClearance [85] RouteClearance, uM86PositionRouteClearance [86] PositionRouteClearance, to: uM79PositionRouteClearance [79] PositionRouteClearanceIndex, uM80RouteClearance [80] RouteClearanceIndex, uM83PositionRouteClearance [83] PositionRouteClearanceIndex, uM85RouteClearance [85] RouteClearanceIndex, uM86PositionRouteClearance [86] PositionRouteClearanceIndex, 5/ In ATCDownlinkMsgElementId, replace the definition of the following message element from: dM24RouteClearance [24] RouteClearance, dM26PositionRouteClearance [26] PositionRouteClearance, dM40RouteClearance [40] RouteClearance, dM59PositionRouteClearance [59] PositionRouteClearance, to: dM24RouteClearance [24] RouteClearanceIndex, dM26PositionRouteClearance [26] PositionRouteClearanceIndex, dM40RouteClearance [40] RouteClearanceIndex, dM59PositionRouteClearance [59] PositionRouteClearanceIndex, 6/ Change the ASN.1 type 'PositionRouteClearance' definition from: PositionRouteClearance ::= SEQUENCE { position Position, routeClearanceIndex RouteClearance } to: PositionRouteClearanceIndex ::= SEQUENCE { position Position, routeClearanceIndex RouteClearanceIndex } 7/ Add the following ASN.1 definition: RouteClearanceIndex ::= INTEGER (1..2) -- RouteClearanceIndex identifies the position of the Route Clearance -- data in the ASN.1 type ATC(Up/Down)linkMessage -- .constrainedData.routeClearanceData 8/ Add in the CPDLC Guidance Material explanations on the use of the 'constrainedData' data structure and modify the ASN. Variables hierarchy accordingly with the new CPDLC structure. Assigned SME: Sub-Volume II SME SME Recommendation to CCB: RESOLVED CCB Decision: CCB-3: ACCEPTED atnp_ccb_chair: PROPOSED (09/12/97) CCB-4: RESOLVED (16/12/97 - Montreal)