WP SGN2 4/6
IP WGN 4/xx
WP SGN2 4/6
IP WGN 5/07
13/05/05
ACP – WGN – SGN2 4th meeting
ACP – WGN – 4th meeting
Results from Eurocontrol PM-CPDLC SARPs Validation
Prepared by: F. Picard (Sofréavia) for Eurocontrol
Summary
This document reports on the validation results of the Eurocontrol PM-CPDLC Validation project.
The project has demonstrated that the PM-CPDLC draft specifications (sub-volumes II and IV) produced by ACP WGN SG/N2 are sufficiently complete and unambiguous to allow implementations to be produced.
SGN2 and WG/N members are invited to review these results and to consider them as inputs to the overall Validation Report for PM-CPDLC to be presented to ICAO
1Introduction
1.1Scope
This paper reports the validation results of the Eurocontrol PM-CPDLC validation project.
1.2Abbreviations
ASEApplication Service Element
CHARMESTNA ATN End System
PM-CPDLCProtected-Mode CPDLC
RRI/ASERouter Reference Implementation / Application Service Element
STNAService Technique de la Navigation Aérienne
1.3Background
The Protected Mode Controller Pilot Data Link Communication (PM-CPDLC) application defines an alternative CPDLC protocol for use in air/ground applications that demand a stronger proof against mis-delivery than provided by Standard Mode CPDLC (as defined in ICAO Doc 9705, Volume II, Part 3). An initial version of the PM-CPDLC specification was made available at the WGN/4 New-Orleans meeting (9th of November 2004).
The project launched by Eurocontrol aimed at validating this draft specification. It consisted in the development of two prototypes implementing the PM-CPDLC specification and the accomplishment of inter-operability tests between both prototypes.
To ensure the confidence of the inter-operability tests, the two prototypes were to be developed by two independent teams and from two independent SARPs V1 compliant ATN End Systems, namely the Sofréavia End System (RRI/ASE) and the STNA CHARME End System.
The STNA, Service Technique de la Navigation Aérienne, was involved in the validation activity by providing access to the source of the CHARME End System and allowing the use of its ATN Laboratory for performing the inter-operability tests.
1.4Results
Two independent implementations of the PM-CPDLC ASEs have been developed in the scope of the project. This is believed to be the first complete implementations of the PM-CPDLC ATN application.
A two-step approach was followed. First locally in each development site, the CHARME and RRI/ASE implementations acting each as both air and ground systems have run the validation test scenarios. The scenarios were defined in order to cover all the new aspects introduced by the protected mode in CPDLC. Then, interoperability testing has been performed in the STNA ATN laboratory with a dual configuration where the CHARME and the RRI/ASE end systems inter-operate.
A number of specification defects have been identified during the lifetime of the project, and tested corrections are proposed to ACP WG/N SG/N2 for approval. The defect reports are summarized in section 4.2 of this paper.
The project has demonstrated that the PM-CPDLC draft specifications (sub-volume II and IV) produced by ACP WGN SG/N2 are sufficiently complete and unambiguous to allow implementations to be produced.
2Prototype implementation
2.1Architecture
Both the CHARME and the RRI/ASE PM-CPDLC prototypes are implemented to run on DEC workstations, under the UNIX operating system DEC ALPHA 0.4d.
The test of the PM-CPDLC prototypes focused on the behavior of the PM-CPDLC air and ground ASEs and users, as described in the draft specifications.
The following was considered outside the scope of the validity activity:
-the ground/ground PM-CPDLC forward service and associated protocol,
-the changes to the ULCS to support the PM-CPDLC naming (AE-qualifier "22" for PM-CPDLC),
-the ground dual configuration supporting both standard and protected mode CPDLC applications,
-the use of PM-CPDLC in an operational ATS context.
2.2Use for SARPs Validation
The validation activity comprises the following steps:
-Paper analysis of the PM-CPDLC draft specification,
-Identification of the impacts on the existing CPDLC code,
-Implementation,
-Development of the associated test tools,
-Stand-alone tests,
-Interoperability tests.
The two implementation teams have worked independently.
The CHARME PM-CPDLC prototype implements interactive HMI tools with a friendly interface allowing an operator to establish PM-CPDLC or PM-DSC connections and exchange PM-CPDLC messages over them. Bottoms allow an operator to select the version number, the class of communication, the security requirements and the behaviour options: LACK requested or not, positive or negative response to CPDLC-start and CPDLC-end indication, inclusion or not of a CPDLC message in the CPDLC-start and CPDLC-end request and response. These tools allow to simulate most of the functionality defined for the PM-CPDLC-users in chapter 7 of the draft SARPs, including checksum algorithm identification, checksum computation in emission and checksum verification in reception.
The RRI/ASE PM-CPDLC prototype comes with a test software tool specially developed for the validation of the PM-CPDLC protocol. This tool uses the PM-CPDLC application programmatic interface (API) provided by the RRI/ASE ATN End system. It allows to run all the validation exercises defined for the validation. The test software tool is based on interpreted command scenarios, each command driving the emission or reception of a PM-CPDLC service primitive. A specific scenario in mode "listener" allows automatic pre-defined responses to incoming messages.
The both tools support two checksum procedures: the default ATN 32 bit checksum algorithm and the password algorithm where a string of characters is passed along the messages.
2.3Implementation of Defect Resolutions
During the lifetime of the project, several defects have been identified in the draft SARPs specification.
A project forum using internet means has been set up to discuss each of these defects and to decide of the best technical approach to fix them. When an agreement was found, the defect resolution was implemented in the PM-CPDLC prototypes for formal validation. The validation results of this report assume the implementation of the defect results.
The defects and associated solutions are being presented to ACP WG/N SGN/2 for discussion.
3Interoperability test Scenarios
3.1Functions to be tested
Interoperability test scenarios have been defined to cover all the specifics introduced by the PM-CPDLC mode over the standard CPDLC mode. These variants are the following:
- Support by the PM-CPDLC users of the checksum algorithm identification mechanism, the checksum computation procedure and the checksum verification procedure ;
- Notification to the peer PM-CPDLC user of errors during checksum identification, computation and verification ;
- Coding and decoding by the PM-CPDLC-user of both the CPDLC and the PM-CPDLC messages ;
- Detection of decoding error and notification to the peer PM-CPDLC users ;
- Coding and decoding by the PM-CPDLC ASE of the PM protocol data units ;
- Transparent transfer by the PM-CPDLC ASEs of the CPDLC messages.
- Inclusion of a CPDLC message (LACK) in the CPDLC-start response.
3.2Test scenario description
64 test scenarios have been defined and are spread over 9 families. A coverage matrix was built to check that all the requirements impacted by the PM-CPDLC functionality were tested by at least one test. The test families are listed below:
- PM-CPDLC link establishment,
- PM-DSC link establishment,
- Message transfer over a PM-CPDLC or PM-DSC link,
- PM-CPDLC link termination,
- PM-DSC link termination,
- PM-CPDLC or PM-DSC link user abort,
- PM-CPDLC or PM-DSC link provider abort,
- ASN.1 compilation, and
- Checksum Algorithm management.
The family for the PM-CPDLC forward was considered out of scope.
3.3Validation test report
PM-CPDLC link establishment
The "PM-CPDLC link establishment" family was successfully run. This show the capability of the system to establish a PM-CPDLC link, to negotiate a checksum algorithm and check validity of the connect and the response messages. Three options were exercised:
-link establishment by the air or by the ground system,
-acceptance or refusal of the link establishment by the called system,
-a CPDLC message or none sent along with the request and the response.
The modification of the SARPs on the CPDLC response primitive (allowing a CPDLC message to be sent back) was validated. Finally, the requirement put on the initiator PM-CPDLC-user to check the validity of the CPDLC message in the CPDLC-start response was tested.
PM-CPDLC link establishment
The "PM-DSC link establishment" family runs the same tests than above, except that only the air system is allowed to initiate the request. No problem is to be reported for this test session.
PM-CPDLC message transfer
The "PM-CPDLC message transfer" family validates the sending over an established CPDLC or DSC link of a protected CPDLC message. A ground initiated transaction (UM request + DM LACK, DM response + UM lack) followed by the air initiated transaction (DM request + UM LACK, UM response + DM lack) show how checksum are added to all exchanged messages. A test was added to verify the correct behavior of the systems when a PM-CPDLC message is received with no CPDLC message included.
PM-CPDLC link termination
The "PM-CPDLC link termination" family demonstrates the correct behavior of the PM-CPDLC ASEs and users when the link is properly terminated. Possible options are acceptance or reject of the termination and sending or not of CPDLC messages during the termination transaction.
PM-DSC link termination
The "PM-DSC link termination" family runs the same tests than those defined for the PM-CPDLC link termination family. All tests have been passed successfully.
PM-CPDLC user abort
The "PM-CPDLC user abort" family demonstrates what the PM-CPDLC is designed for. When a mismatch between the information used to compute the checksum differ in the peer end systems, or when the message is corrupted between end-users, an error is detected and the connection is aborted. This was what happens whenever a different flight identification, ground facility designator, 24 bit address, ASE version number or CPDLC message was used in each end system.
PM-CPDLC provider abort
The "PM-CPDLC provider abort" family was originally specified to verify that even with the changes made to the ASE state machine to support the PM-CPDLC function did not disturb their capacity to detect internal errors, such as protocol error, timeout, missing PDUs, etc… Unfortunately, the two ES used did not permit to create the condition required to experience the error situation. This explains why the status of all tests in this family have been set to "out of scope".
ASN.1 compilation
The tests of the "ASN.1 compilation" family were performed very early during the software development phase to verify the correctness of the ASN.1 modules, as specified in the draft specification. Two independent ASN.1 compilers (ATOS PLC409© and ELIBEL available at provide the evidence that the 3 ASN.1 modules are syntaxically correct.
Checksum Algorithm Management
The "checksum algorithm management" family demonstrates the capability to negotiate and use an alternate checksum algorithm (the one used is a password know a priori by the communicating systems), and the possibility to use a different algorithm for uplink messages and for downlink messages. Finally, the detection by the PM-CPDLC user of the attempt by the peer user to switch to another checksum algorithm during the data transfer phase was tested.
4Contribution to Draft SARPS Validation
4.1Draft SARPs Verification
The main contribution of the PM-CPDLC Validation project to SARPs validation has been to demonstrate that the new PM-CPDLC functionality are well-defined in the PM-CPDLC draft specification, i.e. that the requirements are clear, consistent and unambiguous, no specification hole nor redundancy was found.
It was also verified that the original objective of the ICAO WG/N SGN/2 when producing the draft PM-CPDLC specification is fully met: to disturb as less as possible the standard CPDLC specification in order to ease implementation of PM-CPDLC from existing CPDLC software.
The results give a high level of confidence in the draft PM-CPDLC specification.
4.2Defect Identification and Resolution
During the development of the PM-CPDLC prototypes, technical questions have been raised on, the draft SARPs. Some of those have caused the generation of defect reports (DR) sent for consideration to WG/N SGN/2.
The defect reports are briefly described below:
- DR_000: more than one hundred typos and editorial errors have been reported in this defect report.
- DR_001: This defect report proposes that the exhaustive list of CPDLC messages allowed to be sent on the CPDLC-start response be given in the specification.
- DR_002: This defect report identifies the sections in the PM-CPDLC specification that need to be deleted or modified, if it is decided to not give PM-CPDLC the function to mitigate out-of-sequence message delivery.
- DR_003: PM-CPDLC allows a PDU to be carried on the D-START confirmation APDU. This defect report identifies and proposes corrections to the specification errors on the way this PDU shall be handled by the ASEs.
- DR_004: The simplification made on the top-level ASN.1 structure has created ambiguity when identifying the different APDU element. This DR proposes an extension to the APDU element naming in resolve the issue.
- DR_005: This report identifies a clear defect in the draft specification which allows during the transfer phase the sending of a protected PM-CPDLC message with no CPDLC message included.
- DR_006: This defect report points to an inconsistency in the draft specification, in that on one hand the sender could indicates the use of the atn-default algorithm by only one way (no algorithm identifier), and on the other hand the receiver detects the use of it by two ways (no algorithm identifier and algorithm identifier explicitly set to the atn-default algorithm OID).
- DR_007: This defect states that the capability for a PM-CPDLC user to switch during the data transfer phase from one algorithm to another one (as described in the draft specification) was not operationally justified and should be not allowed.
Both PM-CPDLC prototypes have been modified according to these eight defect reports.
An upgrade of the draft specification including the resolution of the here above Defect Reports is provided to SGN/2 for review.
5Conclusion
The two first implementations of the PM-CPDLC ATN application (air/ground) have been successfully developed and interoperability has been proven by operating all CPDLC service between them.
This paper has presented validation results from the Eurocontrol PM-CPDLC Validation project.
The WG/N is invited to review these results and to consider them as inputs to the overall Validation Report to be presented to ICAO.
*** END OF DOCUMENT ***
1 13/05/05