SGN2/8 & WGN/7 (Bangkok, Thailand)
Validation Report for PM-FIS
SGN2-08 WP 8/04
January25th, 2007
WGN-07 WP7/16
January 29th – February 2nd, 2007
AERONAUTICAL COMMUNICATIONS PANEL
(ACP)
WORKING GROUP N (INTERNETWORKING) – 7th MEETING
SUB-GROUP N/2 (A/G APPLICATIONS) – 8th MEETING
CURRENT STATUS OF PM-FIS VALIDATION PROJECT
Prepared byEGIS-Sofréavia for Eurocontrol
Presented by F. Picard
This paper provides information on the status of the Eurocontrol PM-FIS validation project and reports preliminary results.
The WG/N is invited to note the progress of the validation activity performed on the PM-FIS specification.
Subject to the results of this validation activity, it is concluded that the technical provisions for the PM-FIS ATN application Version 1 as expressed in the specification V0.4 have been sufficiently validated for inclusion in ICAO Doc. 9880 Edition 1. However, editorial changes are still to be performed to align the PM-FIS specifications with the rules followed to specify the CPDLC application in Doc 9880.
1Introduction
1.1Scope
This paper provides information on the status of the Eurocontrol PM-FIS validation project and reports preliminary results.
1.2Abbreviations
APDUApplication Protocol Data Unit
ASEApplication Service Element
CHARMEDSNA ATN End System
FISFlight Information Services
PM-FISProtected-Mode FIS
RRI/ASERouter Reference Implementation / Application Service Element
DSNADirection des Services de la Navigation Aérienne
1.3References
[1a] PM-FIS Specification – SGN2/7 WP 7/05a - Version 0.4 – Input SGN2 Brussels Meeting – June
2006.
[1b] PM-FIS Guidance Material – SGN2/7 WP 7/05b - Version 0.4 – Input SGN2 Brussels Meeting – June 2006.
[1c] PM-FIS P/OICS – SGN2/7 WP 7/05c - Version 0.1 – Input SGN2 Brussels Meeting – June 2006.
[2] PM-FIS-CommentTable.doc
1.4Background
The Protected Mode Flight Information Service (PM-FIS) Application defines an alternative FIS protocol for use in air/ground applications that demand a stronger proof against corruption than provided by Standard Mode FIS (as defined in ICAO Doc 9705, Volume II, Part 4). The PM-FIS specification was developed at the initiative of AIRBUS France and reviewed and presented several times at SGN2 and WGN meetings, as summarized in Table 1.
Version Number / Date / Initial draft for distribution on SGN2 mailing listV0.1 / 27/10/2005 / Initial draft for distribution on SGN2 mailing list
V0.2 / 12/12/2005 / Input SGN2/5 Meeting (December 2005, Toulouse - France)
Prop V0.3 / 07/03/2005 / Input SGN2/6 Meeting (March 2006, Atlantic City - USA)
V0.3 / 10/03/2006 / Output SGN2/6 Meeting (March 2006, Atlantic City - USA)
Prop V0.4 / 28/06/2006 / Input SGN2/7 Meeting (June 2006, Brussels - Belgium)
V0.4 / 03/07/2006 / Output SGN2/7 Meeting (June 2006, Brussels - Belgium)
Input WGN/6 Meeting (July 2006, Bruseels - Belgium)
Table 1: Change History
The project launched by Eurocontrol aims at validating this draft specification. It consists in the development of two prototypes implementing the PM-FIS 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 EGIS-Sofréavia End System (RRI/ASE) and the DSNA CHARME End System.
The DSNA, Direction des Services 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.
Results
Two independent implementations of the PM-FIS ASEs have been developed in the scope of the project. This is believed to be the first complete implementations of the PM-FIS 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 FIS. Then, interoperability testing has been performed in the DSNA 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 and tested corrections have been proposed to ACP WG/N SG/N2 for approval. The defect reports are summarized in section 4.2 of this paper.
Prototype implementation
Architecture
Both the CHARME and the RRI/ASE PM-FIS prototypes are implemented to run on DEC workstations, under the UNIX operating system DEC ALPHA 0.4d.
The test of the PM-FIS prototypes focused on the behavior of the PM-FIS air and ground ASEs and users, as described in the draft specifications.
Use for SARPs Validation
The validation activity comprises the following steps:
-Paper analysis of the PM-FIS draft specification,
-Identification of the impacts on the existing FISsoftware code,
-Implementation,
-Development of the associated test tools,
-Stand-alone tests,
-Interoperability tests.
The two implementation teams have worked independently.
The two PM-FIS prototypes come with a software test tool specially developed for the validation of the PM-FIS protocol. This tool has been ported over the PM-FIS application programmatic interfaces (API) provided by the RRI/ASE and the CHARME ATN End Systems. It allows to run all the validation exercises defined for the validation in an automatic manner. The software test tool is based on interpreted command scenarios, each command driving the emission or reception of a PM-FIS service primitive. A specific scenario in mode "listener" allows automatic pre-defined responses to incoming messages.
Thistest tool supports two checksum algorithms: the default ATN 32 bit checksum algorithm and a password based algorithm where a string of characters a priori only known by the communicating parties is passed along with the messages.
Implementation of Defect Resolutions
During the lifetime of the project, several defects have been identified in the draft PM-FIS 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-FIS prototypes for formal validation. The validation results of this report assume the implementation of the defect results.
The defects and associated solutions were presented to ACP WG/N SGN/2 for discussion.
Interoperability test Scenarios
Functions to be tested
Interoperability test scenarios have been defined to cover all the specifics introduced by the PM-FIS mode over the standard FIS mode.
These PM-FIS specific functions are the following:
- Support by the PM-FIS users of the checksum algorithm identification mechanism, the checksum computation procedure and the checksum verification procedure ;
- Detection and notification to the peer PM-FIS user of errors during checksum identification, computation and verification ;
- PER coding and decoding by the PM-FIS-users of the FISoperational messages (e.g. ATIS or METAR Reports) ;
- Detection of decoding error and notificationto the peer PM-FIS users ;
- Coding and decoding by the PM-FIS ASE of the PM-FIS APDUs ;
- Transparent transfer bythe PM-FIS ASEs of the FISoperational messages.
Test scenario description
58 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-FIS functionality were tested by at least one test. The test families are listed below:
- PM-FIS Demand Contract Service scenarios,
- PM-FIS Update Contract Service scenarios,
- PM-FIS Report Service scenarios,
- PM-FIS Cancel Update Contract Service scenarios,
- PM-FIS Cancel Contracts Service scenarios,
- PM-FIS User Abort Service scenarios,
- PM-FIS Provider Abort Service scenarios,
- ASN.1 compilation scenarios,
- Checksum Algorithm change scenarios.
Contribution to Draft SARPS Validation
Draft SARPs Verification
The main contribution of the PM-FIS Validation project to SARPs validation has been to demonstrate that the new PM-FIS functionality are well-defined in the PM-FIS draft specification, i.e. that the requirements are clear, consistent and unambiguous, no specification hole nor redundancy was found.
The results give a high level of confidence in the draft PM-FIS specification.
Defect Identification and Resolution
During the development of the PM-FIS 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. All the technical defects (listed in Annex 1 of this document) have been resolved. Some editorial defects (such as the translation into a Microsoft Word document, or the removal of the “PM” vs “standard” FIS schema is still to be performed). These editorial changes do not impact the validation results.
Both PM-FIS prototypes have been modified according to these defect reports.
The final upgrade of the draft specification including the resolution of the here above Defect Reports was provided to SGN/2 and WGN [see 1] at the Brussels meeting in June 2006.
Analyze of the Validation Objectives
Standard Validation Objectives have been defined by ATNP with the initial versions of the ATN applications. These validation objectives have always been used to assess the validation level of any new specification. Annex 2 of this document explains to what extent the Validation Objectives are met with the PM-FIS Specification.
Current Status
In June 2006, independent test sessions were already performed on each of the two PM-FIS implementations. The interoperability test sessions between the two implementations started on the 24th of June and were completed in August 2006. All the tests have been passed successfully.
Conclusion
The WG/N members are invited to note the progress of the validation activity performed on the PM-FIS specification.
Subject to the results of this validation activity, it is concluded that the technical provisions for the PM-FIS ATN application Version 1 as expressed in the draft specification V0.4 have been sufficiently validated for inclusion in ICAO Doc. 9880 Edition 1. However, editorial changes are still to be performed to align the PM-FIS specification with the rules followed to specify the CPDLC application in Doc 9880.
- 1 -
SGN2/8 & WGN/7 (Bangkok, Thailand)
Validation Report for PM-FIS
ANNEX 1: List of defects
Note1: Yellow rows are closed comments, blank rows are open comments.
Note 2: Defects with source set to SOF/EHQ have been issues within the EUROCONTROL PM-FIS Validation Project.
CORE SARPS
#
/ STATUS / Source/Date / Detected in / Corrected in / SECTION / COMMENT / RESOLUTIONPM-FIS Version 0.3 (inputAtlantic City – March 2006)
PM-FIS Version 0.4 (inputBrussels – June 2006)
Doc 9705 Sub-Volume I
#
/ STATUS / Source/Date / Detected in / Corrected in / SECTION / COMMENT / RESOLUTIONPM-FIS Version 0.3 (inputAtlantic City – March 2006)
PM-FIS Version 0.4 (inputBrussels – June 2006)
PM-FIS Application should not be defined as such (FIS application)
Replace all PM-FIS by FIS
Doc 9705 Sub-Volume II
#
/ STATUS / Source/Date / Detected in / Corrected in / SECTION / COMMENT / RESOLUTIONPM-FISProposed Version 0.3 (inputAtlantic City – March 2006)
CLOSED / GS/Boeing / Proposed V0.3 / V0.3 / 2.5.1 / In 2.5.1 Introduction, the "checksum" must be replace by "application message integrity check" since it might not be a checksum per se. / 2 occurrences replaced.
CLOSE / GS/Boeing / Proposed V0.3 / Annexes 3, 5 and 10 are referenced without amendment number.
CLOSED / GS/Boeing / Proposed V0.3 / V0.3 / Chapters 5 and 7 / The reject reason "FIS Service not available" should be replaced by "Requested FIS service not available" to make clear that the reject applies only to the requested service. / Modification in chapters 5 and 7 wherever this reason appears.
PM-FIS Version 0.3 (outputAtlantic City – March 2006)
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / General / For consistency, all the APDU shall be preceded by ‘FISUplinkAPDU’ or ‘FISDownlinkAPDU’ in order to clearly identify which PM-FIS user is the originator of the APDU.
Example:
…
2.4.5.3.5.3 : FISUplinkAPDU[FISAccept]
2.4.5.3.5.4 : FISUplinkAPDU[FISAccept]
2.4.5.3.5.5 : FISUplinkAPDU[FISReject]
2.4.5.3.5.6 : FISUplinkAPDU[FISReport]
…
2.4.5.3.6.2 : FISDownlinkAPDU[FISRequest]
…
2.4.5.3.7.5 : FISUplinkAPDU[FISAccept]
2.4.5.3.7.6 : FISUplinkAPDU[FISReject]
2.4.5.3.7.7 : FISUplinkAPDU[FISReport]
… / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.3.3.6
2.4.3.4.6 / “Note 1: This parameter contains the value of the required priority, if specified by the FIS-air-user”
This note is ambiguous as the priority is mandatory when opening a dialogue between two ATN End System. The following modification is proposed to reflect this constraint:
“Note 1: This parameter contains the value of the required priority if specifiedset by the FIS-air-user on the first FIS contract” / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.4.2.1 / “ProtectedFISRequestData” definition: for consistency, replace the “protectedFISReportData” attribute name by the “protectedFISRequestData” attribute name. / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.4.2.1 / “FISRejectData” definition: inconsistency with the reason name given in section 2.4.7.7.3.4.b. Should be updateContractFunctionNotSupportedWithReport. / Chapter 7 is modified instead.
CLOSE / SOF/EHQ / V0.3 / - / 2.4.4.2.1 / “FISProviderAbort” definition: doesn’t contain all the abstract values specified in section 2.4.3.9.2.1 / NOK. Some values are locally generated and therefore do not appear in the Provider Abort APDU. No change.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.4.2.1 / “FISService” definition: comma missing after the enumerated value (0). / OK.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.4.2.1 / “FISServiceType” definition: comma missing after the enumerated value (0). / OK.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.4.2.1 / “Time” structure definition not used. To be removed from the PM-FIS ASN.1 definition. / OK.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.5.3.8.2.1.a.4 / For consistency, replace “FISRequestData” by “ProtectedFISRequestData” (use of the name attribute). / OK.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.5.3.8.8.3.c / “enterremain in the UC-G-CANCEL state” / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.5.3.9.1.d / “if the AB module is a ground PM-FIS module, create a FISUplinkAPDU[FISProviderAbort] APDU, … / OK.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.5.3.9.1.e / “request the LI module to send a D-ABORT request with the originator parameter set to the abstract value “provider” and with the created APDU”. / OK.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.5.3.9.2.d / “request the LI module to send a D-ABORT request with the originator parameter set to the abstract value “user” and with the created APDU”. / OK.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.5.3.12.6 / “…and the D-START QOS Routing Class parameter identifies the traffics category “Air Traffic Service Communications (ATSC)” and the D-START Security Requirements parameter is consistent …” / OK.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.5.3.12.8 / “Upon receipt of a D-START confirmation with the result parameter containing the abstract value “rejected” and the RejectSource parameter …” / OK.
CLOSE / SOF/EHQ / V0.3 / - / 2.4.5.3.12.8.1.a / “request the AB module to abort with the originator “provider” and with reason …” / NOK, in 2.4.5.3.9.1, when the AB module is requested to abort, the originator always takes the value “originator”. There is no need for the calling module to specify the value.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.5.3.12.9 / “Upon receipt of a D-START confirmation with the result parameter containing the abstract value “rejected” and the RejectSource parameter …” / OK.
CLOSE / SOF/EHQ / V0.3 / - / 2.4.5.3.12.9.1.a / “request the AB module to abort with the originator “provider” and with reason …” / NOK, in 2.4.5.3.9.1, when the AB module is requested to abort, the originator always takes the value “originator”. There is no need for the calling module to specify the value.
CLOSE / SOF/EHQ / V0.3 / - / 2.4.5.3.12.17.1.a / “request the AB module to abort with the originator “provider” and with reason …” / NOK, in 2.4.5.3.9.1, when the AB module is requested to abort, the originator always takes the value “originator”. There is no need for the calling module to specify the value.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.2.3.1 / Paragraph numbering. / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.5 / Each PM-FIS user has no visibility about their remote PM-FIS users as the PM-FIS protocol is not connection oriented. Then, the complete re-initialization of a PM-FIS user and then, the loss of the contexts (including the Protected Mode Checksum algorithms used for downlink and uplink PM-FIS exchanges) can be not detected by the other PM-FIS users
In this case, it is proposed to manage the Protected Mode Checksum algorithm for each contract. / OK, !!! Change guidance material accordingly !!!
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.5.1.2 / -Further to Defect 24-
Each downlink PM-FIS message contains a contract request. Then, this requirement is relevant for all the received downlink PM-FIS messages (and not the first one only).
“On receipt of the first downlink Protected FIS message, …” / NO, the proposed changed in comment 28 is applied here.
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.5.1.3 / -Further to Defect 24-
The requirement is not relevant any more and shall be deleted. / NO, , the proposed changed in comment 28 is applied here with a note indicating that the requirement is not applicable to the current types of contract ‘only one downlink with an AMIC).
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.5.1.6 / Incorrect references : “… specified in 2.5.7.6 and 2.5.7.8 …” instead of “… specified in 2.4.7.6 and 2.4.7.8 …” / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.5.2.2 / -Further to Defect 24-
“On receipt of the first uplink Protected FIS message on a given contract, the …” / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.5.2.3 / -Further to Defect 24-
“On receipt of a subsequent uplink Protected FIS message on a given contract, the …” / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.5.2.6 / Incorrect references : “… specified in 2.5.7.6 and 2.5.7.7 …” instead of “… specified in 2.4.7.6 and 2.4.7.7 …” / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.7.3.4.b / In this case, the reject reason is “update contract function not supported with report”. / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.11.2.1 / Remove some tabulations to align the SEQUENCE and ENUMERATED definitions. / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.11.2.1 / “ConditionsAndActions” definition: move the runwaySlipperyIndication attribute before the Extension tag. / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.11.3.1 / Remove some tabulations to align the SEQUENCE and ENUMERATED definitions. / OK
CLOSE / SOF/EHQ / V0.3 / Proposed V0.4 / 2.4.7.7.3.4 / The case “update function not supported” with no report available is not described. / OK, case c) is added to cover this case.
PM-FISProposed Version 0.4 (inputBrussels – June 2006)
PM-FIS Version 0.4 (inputBrussels – June 2006)
Translate the Word Perfect document to a MS Word document.
Apply all editorial changes as performed by ACP Secretariat on PM-CPDLC (see Doc 9880), such as replacing all “PM-FIS” by “FIS”, or replacing “Protected Mode” by “FISI/C”
Doc 9705 Sub-Volume IX
#
/ STATUS / Source/Date / Detected in / Corrected in / SECTION / COMMENT / RESOLUTION- 1 -