SKELETON



DisclaimerThe present document has been produced and approved by the <long ISGname> (<short ISGname>) ETSI Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.It does not necessarily represent the views of the entire ETSI membership.Draft ETSI GR CDM 006 0.0.5 (2021-01)Group REPORTCommon Information sharing environment service and Data Model (CDM);Analysis for the specifications of a testing suite for the Common Information Sharing Environment (CISE);Preliminary Analysissymbol 60 \f "Wingdings" \s 16<Reference<Workitem>Keywords<keywords>ETSI650 Route des LuciolesF-06921 Sophia Antipolis Cedex - FRANCETel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16Siret N° 348 623 562 00017 - NAF 742 CAssociation à but non lucratif enregistrée à laSous-préfecture de Grasse (06) N° 7803/88Important noticeThe present document can be downloaded from: present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI deliverable is the one made publicly available in PDF format at deliver.Users of the present document should be aware that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at you find errors in the present document, please send your comment to one of the following services:HYPERLINK "" Copyright NotificationNo part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI.The content of the PDF version shall not be modified without the written authorization of ETSI.The copyright and the foregoing restriction extend to reproduction in all media.? ETSI yyyy.All rights reserved.DECTTM, PLUGTESTSTM, UMTSTM and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.3GPPTM and LTETM are trademarks of ETSI registered for the benefit of its Members andof the 3GPP Organizational Partners.oneM2M? logo is a trademark of ETSI registered for the benefit of its Members andof the oneM2M Partners.GSM? and the GSM logo are trademarks registered and owned by the GSM Association.Contents TOC \o \w "1-9"Intellectual Property Rights PAGEREF _Toc61433720 \h 5Foreword PAGEREF _Toc61433721 \h 5Modal verbs terminology PAGEREF _Toc61433722 \h 5Executive summary PAGEREF _Toc61433723 \h 5Introduction PAGEREF _Toc61433724 \h 51Scope PAGEREF _Toc61433725 \h 72References PAGEREF _Toc61433726 \h 72.1Normative references PAGEREF _Toc61433727 \h 72.2Informative references PAGEREF _Toc61433728 \h 73Definition of terms, symbols and abbreviations PAGEREF _Toc61433729 \h 83.1Terms PAGEREF _Toc61433730 \h 83.2Symbols PAGEREF _Toc61433731 \h 83.3Abbreviations PAGEREF _Toc61433732 \h 84Description of the IUT PAGEREF _Toc61433733 \h 84.1IUT internal structure PAGEREF _Toc61433734 \h 94.2IUT external interfaces PAGEREF _Toc61433735 \h 105The testing environment PAGEREF _Toc61433736 \h 105.1Lightweight testing box PAGEREF _Toc61433737 \h 105.2The ETSI CDM testing platform PAGEREF _Toc61433738 \h 116Conformance testing PAGEREF _Toc61433739 \h 126.1Functional requirements to be tested PAGEREF _Toc61433740 \h 126.2Test Suite Structure (TSS) and Test Purposes (TP) PAGEREF _Toc61433741 \h 126.3Abstract Test Methodology (ATM) and Test Generation PAGEREF _Toc61433742 \h 137Interoperability testing PAGEREF _Toc61433743 \h 147.1Functional requirements to be tested PAGEREF _Toc61433744 \h 147.2Protocols to be tested PAGEREF _Toc61433745 \h 158Final Recommendations PAGEREF _Toc61433746 \h 169Conclusions and outlook PAGEREF _Toc61433747 \h 16Annex A: Installing the “Lightweight testing box” PAGEREF _Toc61433748 \h 16A.1Downloading CISESIM VM PAGEREF _Toc61433749 \h 16A.2Checking VM behaviour PAGEREF _Toc61433750 \h 17A.2.1Process status PAGEREF _Toc61433751 \h 17A.2.2Sending and receiving messages from command line PAGEREF _Toc61433752 \h 18A.2.3Sending and receiving messages from the AIS adaptor PAGEREF _Toc61433753 \h 19Annex B: CDM PICS pro forma example PAGEREF _Toc61433754 \h 19B.1Partial cancellation of copyright PAGEREF _Toc61433755 \h 19B.2Guidance for completing the PICS pro forma PAGEREF _Toc61433756 \h 20B.2.1Purposes and structure PAGEREF _Toc61433757 \h 20B.2.2Abbreviations and conventions PAGEREF _Toc61433758 \h 20B.2.3Instructions for completing the PICS pro forma PAGEREF _Toc61433759 \h 22B.3Identification of the implementation PAGEREF _Toc61433760 \h 22B.3.1Introduction PAGEREF _Toc61433761 \h 22B.3.2Date of the statement PAGEREF _Toc61433762 \h 22B.3.3Implementation Under Test (IUT) identification PAGEREF _Toc61433763 \h 22B.3.4System Under Test (SUT) identification PAGEREF _Toc61433764 \h 22B.3.5Product supplier PAGEREF _Toc61433765 \h 23B.3.6Client (if different from product supplier) PAGEREF _Toc61433766 \h 23B.3.7PICS contact person PAGEREF _Toc61433767 \h 24B.4Identification of the protocol PAGEREF _Toc61433768 \h 24B.5Global statement of conformance PAGEREF _Toc61433769 \h 24B.6Tables PAGEREF _Toc61433770 \h 24Annex C: CDM Test Purpose example PAGEREF _Toc61433771 \h 26C.1Message Format PAGEREF _Toc61433772 \h 26C.2Message Payload PAGEREF _Toc61433773 \h 26History PAGEREF _Toc61433774 \h 28Intellectual Property RightsEssential patents IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI?SR?000?314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server ().Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI?SR?000?314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.TrademarksThe present document may include trademarks and/or tradenames which are asserted and/or registered by their owners. ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.ForewordThis Group Report (GR) has been produced by ETSI Industry Specification Group “european Common information sharing environment service and Data Model (CDM)”.Modal verbs terminologyIn the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions)."must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.Executive summarytbdIntroductionThe CISE network is a Peer-to-Peer architecture connecting public authorities and their (legacy) IT systems responsible for maritime surveillance. The adaptor role is to connect seamlessly the Legacy System to the CISE network. Figure 1: The CISE peer-to-peer architecture.ETSI ISG CDM has accomplished an initial standardization of all specifications needed to implement a CISE node and a set of adaptors connecting with legacy systems maintained at the level of Member States. All informative references are included in this document.To properly qualify a certain implementation of the CISE node based on the specifications coming from ETSI ISG CDM set of standards it is necessary to refer to ETSI documents published by the Methods for Testing and Specification (MTS) technical committee.As from the Conformance Testing REF _Ref60993213 \r \h \* MERGEFORMAT [i.1] it is necessary to define the boundaries for testing so that we properly separate the Implementation Under Test (IUT) from the Test System as pictorially shown in REF _Ref60996557 \h \* MERGEFORMAT Figure 2.The points where the tester controls and observes the IUT are called the Points of Control and Observation (PCO).Figure 2: How to design a testing system for conformance testing using ETSI formal methodology (from REF _Ref60993213 \r \h [i.1] .The product tests are performed on open standardised interfaces in order to let the Test System correctly interact with the Product. A comprehensive testing methodology consists of three complementary parts:Test requirements and Protocol Implementation Conformance Statement (PICS) pro-forma; Test Suite Structure and Test Purposes (TSS & TP); Abstract Test Methodology (ATM) and Test Cases (TC)Generation.As pictorially shown in the fFigure 2, we assume to rely on a comprehensive set of Base Standards so that it will be possible to technically define the IUT and its interfaces. The Implementation Under Test (IUT) overlaps with the “Node” functional block including eventual interfaces with adaptors. We will therefore pave the way to deliver the comprehensive testing blocks as result of a Future Work. We will also include a description of the target testing network that will be used to check the interoperability REF _Ref60997726 \r \h \* MERGEFORMAT [i.2] of the IUT with other implementations and with a qualified equipment. (see REF _Ref57971295 \h \* MERGEFORMAT Figure 3).Figure SEQ Figure \* ARABIC 3: How to design a testing network for interoperability (from REF _Ref60997726 \r \h \* MERGEFORMAT [i.2]) .1ScopeIn this report ETSI ISG CDM provides a preliminary study to properly undertake a full specification of a testing suite aimed at validating a CISE node instance complying with CDM standards and capable of interoperating with other CISE standard instances implemented by other organizationsindependently.In each Chapter clause after a high-level description of the standardized specifications we will provide a recommendation to properly address the testing specification activity is given including the recommended implementation of the ETSI CDM Testing Platform. 2References2.1Normative referencesNormative references are not applicable in the present document.2.2Informative referencesReferences are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.NOTE:While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee their long term validity.The following referenced documents are not necessary for the application of the present document but they assist the user with regard to a particular subject area.[i.1]<Standard Organization acronym> <document number><version number/date of publication>: "<Title>".[i.2]?rmative references include the set of ?Base Standards? representing the minimum requirements a certain implementation must satisfy. In our case:ETSI ETS 300 406 (April 1995): “Methods for Testing and Specification (MTS); Protocol and profile conformance testing specifications; Standardization methodology”.(ETS 300 406) Protocol and profile conformance testing specifications; Standardization methodology.ETSI EG 202 810 (v1.1.1): “Methods for Testing and Specification (MTS); Automated Interoperability Testing; Methodology and Framework”(ETSI EG 202 810) Automated Interoperability Testing; Methodology and FrameworkETSI (GS CDM 002 (vXXX): Common Information sharing environment service and Data Model (CDM);CDM System RequirementsETSI (GS CDM 003) (vXXX): Common Information sharing environment service and Data Model (CDM); CDM Arccrhitecture (Including Common & Core Services)ETSI (GS CDM 004 (vXXX): Common Information sharing environment service and Data Model (CDM);) Protocol - Service ModelSpecifications on protocol (Service Model included); ETSI (GS CDM 005) (vXXX): Common Information sharing environment service and Data Model (CDM); CDM Data ModelISO/IEC 9646-1: "Information technology -- Open Systems Interconnection -- Conformance testing methodology and framework -- Part 1: General concepts"ISO/IEC 9646-2: "Information technology -- Open Systems Interconnection -- Conformance testing methodology and framework -- Part 2: Abstract Test Suite Specification"ISO/IEC 9646-7: "Information technology -- Open Systems Interconnection -- Conformance testing methodology and framework -- Part 7: Implementation Conformance Statements"ETSI ES 201 873-1: “Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 1: TTCN-3 Core Language”ETSI ES 201 873-5: “Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)”ETSI ES 201 873-6: “Methods for Testing and Specification (MTS); The Testing and Test Control Notation version 3; Part 6: TTCN-3 Control Interfaces (TCI)”3Definition of terms, symbols and abbreviations3.1TermsFor the purposes of the present document, the [following] terms [given in ... and the following] apply:Future Work:The comprehensive development of the Test Suite and the CDM Testing PlatformCISE Testing Network: …CISE (pre-)operational network: ….3.2SymbolsFor the purposes of the present document, the [following] symbols [given in ... and the following] apply:3.3AbbreviationsFor the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:4Description of the IUTThe CISE node is organized in a set of VM interconnecteda distributed system in a Local Network protected behind a firewall. Apart from CISE specific services the node relies on generic (like Network Adaptation via proxy, PKI, DB, Firewall, etc.) and admin services as shown in REF _Ref61247572 \h Figure 3Figure XX:Figure 3: A possible configuration of the CISE node behind a firewall.The Business Logic functionalities are described in REF _Ref60658897 \r \h \* MERGEFORMAT [i.4] and can be classified into Core and Common services:Core services provide common facilities and enable the connection of the Participants through the Network;Common services include capabilities to exchange information in the network using the CISE Data and Service models.The IUT consists in a set of core and common services as described in the following sub-clauses.4.1IUT internal structureNode core services include:Auditing Services:Logging, Monitoring and Accounting.Application Security Services:Identification, Authentication and Authorization;Network and Secure Communication Services:Service Manager and Network;Administration User Console;Collaboration tools.A node is fully functional when a certain subset of these services is enabled. The task of selecting this subset has not been fully accomplished by the CISE2020 collaborative project nor by the ISG CDM standardization activity.To properly define the IUT structure the Ffuture Wwork will need to select this subset according to select the following recommendationsservices (see Section 5.3 in [i.4]):The Auditing Services limited to accounting limited to the logging service as described in Section 5.3.1.1 [i.2];The Application Security Services; limited to Authorization Service (what service??) subscription (Pull request) as described in Section 5.3.1.2.2 REF _Ref60658897 \r \h \* MERGEFORMAT [i.4] ;The Network and Secure Communication Services .limited to the Service Manager publish (delete) a new (existing) service as described in Section 5.3.1.3.1 REF _Ref60658897 \r \h \* MERGEFORMAT [i.4] ;…4.2IUT external interfacesFigure 4: The IUT external interfaces to be used for testing.The Common Services are organized in Consumer/Provider functional blocks supporting the following business functions:Push;Push to unknown;Pull (Pull Request and Pull Response);Pull to unknown;Publish/Subscribe;Discover;Get subscribers.As for the case of the IUT internal structure, the node is fully functional when a certain subset of these services is enabled. The task of selecting this subset has not been fully accomplished by the CISE2020 collaborative project nor by the ISG CDM standardization activity. To properly define the IUT structure the future work will need to select this subset according to the following recommendations:it is required to select at least two one Service Types, say e.g. Vessel Service and or CargoIncident Service;it is required to test at least one among the following patterns: Discover, Publish/Subscribe, a Pull, and a Push request.The output of testing can be that of qualifying the IUT just for a subset of exchange patterns and service types (e.g. Publish/Subscribe of Incident Services).5The testing environmentThe implementer providing a CISE candidate node will be asked to retrieve the testing environment described in Section 5.1 and to connect to the testing network described in Section 5.2.5.1Lightweight testing boxThe purpose of setting up the “Lightweight testing box” is to check the compliance of the IUT against the specifications detailed in Sec. 2.2.The testing box is expected to be shaped as a VM (in multiple formats) and maintained by ETSI for upgrades and error fixes. It basically features:GNU/Linux operative systemJava 11 VMDocker version 19 or newer docker-compose version 1.25 or newer the CISE Sim applicationa sample adaptor for the AIS serviceIt will be possible to use the CISE Sim application for sending and receiving CISE messages to/from newly developed CISE Nodes, adaptors (the appointed IUT described in Section 4) or other CISE Sim’s. The messages managed by the CISE simulator follow the data model standardized in GS REF _Ref60658899 \r \h \* MERGEFORMAT [i.5] and the protocol standardized in REF _Ref60658902 \r \h \* MERGEFORMAT [i.6] .The CISE Sim features the following functionality:send CISE messages using a template (from a node)send specific VesselService messages from the AIS adaptorreceive CISE messagesvalidate the CISE messages according to the CISE Data and Service models.store sent/received messagesdisplay the message history and the message threads (messages chains) discover CISE services from a CISE Node Through this tool it is possible to check the compliance with the specifications listed in Sec. 2.2 following the provisions described in Sec. 6.A practical how-to is included in Appendix 1.5.2The ETSI CDM testing platformThe CISE collaboration has succeeded in the full implementation and validation of a reference node, complying with the specifications described in REF _Ref60658894 \r \h \* MERGEFORMAT [i.1] REF _Ref60658897 \r \h \* MERGEFORMAT [i.4] REF _Ref60658899 \r \h \* MERGEFORMAT [i.5] REF _Ref60658902 \r \h \* MERGEFORMAT [i.6] So far 10 CISE nodes have been deployed by 9 EEA Member States: Finland, Germany, Norway, Portugal, Bulgaria, France, Greece, Italy and Spain (2) making use of 19 adaptors connecting a set of 17 national legacy systems in total. This network is considered as pre-operational.As from April 2019, EMSA is engaged in setting up and enabling, in close coordination with the Member States, the Transitional Phase, ensuring a coherent evolution of the CISE network and to achieve an operational CISE. Recently the CISE Stakeholder Group (CSG) has recommended to set up a CISE testing network to qualify candidate CISE nodes under test before releasing and installing them into the “pre”-operational network. In this work we recommend to design and implement a complementary testing platform (ETSI CDM testing platform in the following) open to companies (IUT providers). This allows to connect their candidate IUT and validate them against the compliance and interoperability requirements discussed in Sections 6 and 7. Through a firewall it will be possible to connect the IUT with the CISE testing network setting up a (set of )site-to-site VPN connections (see REF _Ref60934319 \h Figure 5) Figure 7).Figure 5: A conceptual scheme of the ETSI CDM testing platform.[…]The intention is that of allowing candidate nodes having passed the tests to enter the CISE Testing Network. Adopting the prescriptions in force in CISE this node will be finally deployed in the CISE (pre)-operational network finalizing the qualification process supervised by ETSI (for compliance and interoperability) and EU (for the regulatory framework).6Conformance testing6.1Functional requirements to be tested (The Future Work in our case)The Protocol Implementation Conformance Statement (PICS) pro-forma is a questionnaire designed by the conformance test suite specifier ( REF _Ref61359031 \r \h [i.7] . The target isof the Future Work will be that of to make making available a certain number of one or more Pro-forma Implementation Conformance Statements (PICS) related to the IUT internal and external structure described in Sections 4.1 and 4.2.More specifically, as the Future Work succeeds in the task of finding the target Core and Common Services, it is required to produce a comprehensive set of PICS as aAn example related to the logging accounting service is reported in Annex B. The PICS is subdivided into subclauses for the following categories of information:guidance for completing the ICS proforma; identification of the implementation; identification of the base standard; global statement of conformance;subclauses (depending on the considered feature).6.2Test Suite Structure (TSS) and Test Purposes (TP) A Test Purpose (TP) is a text description of a well-defined objective of testing. Applying to conformance testing, it focuses on a single conformance requirement or a set of related conformance requirements from the base standards, formalized in the PICS. The organization of the test purposes in groups is named "Test Suite Structure". The development of the test purposes follows the analysis of the conformance requirements, clearly expressed in the base standards.As at the time being the set of features to be tested is not yet defined an actual TSS is beyond the scope of this document. Nonetheless we suggest to follow the recommendations given in Clause 4 and to prepare a rank-2 tree (root/group/category) with the root defined as NODE. The groups will be those mapping the IUT internal structure described in Section 4.1 whereas the category of tests will follow the classification in REF _Ref61359031 \r \h \* MERGEFORMAT [i.7] . It will be possible to adopt a naming scheme as the one reported in REF _Ref61373219 \h Table 1. As a matter of example the types of testing suggested therein are about Behavioural and Basic Interconnection tests.Table 1: TP naming conventionIdentifier:TP/<root>/<gr>/<x>/<nn>/<v><root> = rootNODE<gr> = groupGR1…GRXTest X related to Accounting, Core, or Common functionality………GN<x> = type of testingBVBehaviour: Valid event testsBOBehaviour: Inopportune event testsBITBasic Interconnection Tests<nn> = sequential number01 to 99<v> = variant01 to 99To avoid an update of all TPs when the PICS document is changed, REF _Ref61373242 \h \* MERGEFORMAT Table 2 REF _Ref61373219 \h \* MERGEFORMAT Table 1 introduces mnemonics name and the correspondence with the real PICS item number. What will be mentioned in the TP will be the mnemonics name.Table 2: Mnemonics for PICS referenceMnemonicPICS itemPICS_CORE_AUDIT_LOGGINGBA.XXPICS_CORE_APPLICATION_AUTHORIZATION_SUBSCRIPTION_<SERVICE1>BA.XXPICS_CORE_NET_SERVICE-MANAGER_PUBLISHBA.XXPICS_CORE_NET_SERVICE-MANAGER_DELETEBA.XX… other core servicesBA.XXPICS_COMMON_SERVICE_DISCOVERBA.XXPICS_COMMON_SERVICE_PULL_ CARGO_-<SERVICE1>BA.XXPICS_COMMON_SERVICE_PUSH_ VESSEL_-<SERVICE1>BA.XX… other common servicesB.XXAn example of TP for a VesselService Push is reported in Annex C.The Future Work will target the definition of certain number of TPs organized in accordance with the adopted TSS assuring an acceptable coverage of the IUT features mapped to the PICS.6.3Abstract Test Methodology (ATM) and Test Generation Starting from the actual set of TPs last step is the derivation of an abstract test case for each TP. In this step a choice is made for a particular test method, and the restrictions implied by the environment in which esting will be carried out are taken into account. The Future Work will therefore consider the testing environment presented in Section 5.The preparation of an Abstract Test Methodology requires to connect the IUT with the POC. If the Adaptor and the Network Endpoint are selected, they can be seen as the Upper Tester (UT) and Lower Tester (LT) defined in REF _Ref61429255 \r \h [i.8] and a simple testing topology like the “Local Single-Layer” test method can be adopted as shown in REF _Ref61430789 \h Figure 6.Figure SEQ Figure \* ARABIC 6: A proposal for testing the IUT using the LS-method.It is left to the Future Work the selection of the ATM together with the adoption of a test notation. Following the best practices in ETSI, Tree and Tabular Combined Notation (TTCN) REF _Ref61431946 \r \h [i.10] REF _Ref61431953 \r \h [i.11] REF _Ref61431954 \r \h [i.12] is considered the default choice although a more straightforward notation is also acceptable. As TTCN permits to import and use external data types (e.g. ASN.1 , IDL, XML, JSON), it is a versatile and effective instrument for test notation.7Interoperability testing7.1Functional requirements to be testedThe target is to make an instance of node interoperable with others. Interoperability tests will be done among suppliers and between a supplier and the Qualified Node installed in the CISE testing network (see REF _Ref60934327 \h \* MERGEFORMAT Figure 7 and Section 5.2).Figure 7: Configuration for interoperability tests.More specifically, as the Future Work succeeds in the task of finding the target Common Services, the node is required to check coherence between Requests and Responses:Example: for a Vessel Service, test if the vessel provided corresponds to the one requested.Suppliers can schedule one-to-one interoperability tests.The CISE Qualified Node installed in the CISE Testing Network consists in the full implementation of the requirements described in REF _Ref60658894 \r \h \* MERGEFORMAT [i.1] . The CISE Qualified Node can be reached from the ETSI Testing Platform to test interoperability.This interaction will be disciplined by ETSI convenors (leasing VPN certificates) during the testing campaigns.7.2Protocols to be testedThe Adaptor communicates with the CISE Network (and vice versa) through the “CISE Message Service Interface” of the Node (see REF _Ref60936461 \h \* MERGEFORMAT Figure 4) using a SOAP or REST protocol. The Node supports both SOAP and REST protocols for the communication with the Adaptor (see specifications in provision 5.2 of REF _Ref60658897 \r \h \* MERGEFORMAT [i.4] ).The topology to be used for these tests is reported in REF _Ref60937319 \h \* MERGEFORMAT Figure 8.Figure 8: Peer to peer interoperability test internally to the ETSI platform.In the Future Work the protocols to be tested will be further investigated. We recommend to consider REST as mandatory and consider SOAP for comprehensive tests. It will be possible to interoperate with the CISE qualified network passing through the firewall and connecting the Tenant-X to the CISE Testing Network via VPN.8Final RecommendationsAs already dicussed in the Introduction this work is preliminary and requires to be finalized with more effort and resources. Prior to the definition of the actual Test Cases it is requested to properly address the topic of distinguishing mandatory from optional features offered by the CISE node implemented from the specifications by ETSI ISG CDM.Once the Conformance Tests are finalized and a Testing Network is implemented we recommend to support companies engaged in the node development announcing public test sessions like Plugtests?.It is moreover recommended to appoint real testbeds already active in the maritime domain to host the testing campaigns.9Conclusions and outlooktbdAnnex A:Installing the “Lightweight testing box”A.1Downloading CISESIM VM ETSI has published a VM (Ubuntu guest OS) for public use at the following address: VM is configured to map ports to localhost (127.0.0.1) as :2222 ssh (login XXXX/XXXX)NODE-DOCKER (CISESIM on docker image) 8200 CISESIM GUI, 8201 CISESIM MangementNODE1 (CISESIM on filesystem) 8300 CISESIM GUI, 8301 CISESIM MangementTo enter the “NODE-DOCKER”, an alias is provided cisesh (‘alias cisesh='docker exec -ti cise_cise-sim_1 /bin/bash'’); to enter the “node1” just move to ~/cise1.To let the VM listen from the network, the default configuration has to be slightly changed.FolderFolder in DockerDescription~/cise1/conf/srv/cise-simulator/confConfiguration files~/cise1/logs/srv/cise-simulator/logsLogs~/cise1/msghistory/srv/cise-simulator/ msghistorySent/received CISE messagesA.2Checking VM behaviour A.2.1Process status The two simulators are already installed and running in the VM distributed by ETSI.XXXX@cisetest:~/cise1$ ./sim status/home/XXXX/cise1/tmp/sim.pid[ok] sim is runningThe CISE Sim will run in background (using nohup) even if the terminal session is closed. The application log will be stored in the file ``logs/sim.log``.XXXX@cisetest:~/cise1$ ./simUsage: sim COMMANDsim server lifecycle manager (starting, stopping, debugging).COMMAND start starts the simulator in a detached shell using nohup command. run starts the simulator in foreground. stop stops the simulator running in background. restart restart the simulator running in background. debug-start starts the simulator in a detached shell launching the application in debug mode (port 9999). debug-run starts the simulator in foreground launching the application in debug mode (port 9999). status show the current status the simulator (started or stopped). send send a message from an xml fileFigure 9: An example of CISE Simulator for a Windows host.In REF _Ref57014661 \h Figure 9 an example of simulation set-up is illustrated featuring (3) a VM manager, (2) a text terminal, and (1-4) two GUIs showing the status of the built-in simulation engine (labeled as “NODE-DOCKER”) and a second simulator (labelled as “NODE1”). Using this setup it is possible to send and receive messages in the same host.A.2.2Sending and receiving messages from command line As the CISE Sim exposes the following endpoints:EndpointDescription interface (for web browsers) interface (to **receive** CISE messages from other adaptors/nodes/CISE Sim) interface (to **receive** CISE messages from other adaptors/nodes/CISE Sim)The CISE Sim can receive CISE messages from the REST and the SOAP endpoints at the same time.With the command ./sim send 'filename' is possible to send a message contained in a xml file.The destination is the same configured for cise-sim and message sent and ack received will be stored in the cise-sim repository directory.Each message is stored in a single XML file, whose filename follows this pattern: Timestamp_TypeName_Direction_UuidParameterDescription TimestampTimestamp when the message was processed,following the format : yyyyMMdd-HHmmssSSSTypeNameType of the message (i.e. PULLREQUEST, FORWARD, etc.) For the Acknowledge messages, SYNC are the ones received/sent synchronously after the message was sent/receivedDirectionRECV for message received, or SENT for message sentUuidUnique identifier (UUID)Examples: 20201118-154611819_PUSH_SENT_376cb27e-6613-4421-b8b4-c5b6f2c57a7c.xml20201118-154611853_SYNCACK_RECV_40d0e627-4e2b-4e4a-816a-213a4b46c156.xml20201118-172335244_PUSH_RECV_371f69f4-87f6-40a5-b8e4-c83115b27719.xml20201118-172335278_SYNCACK_SENT_29970f33-1a66-40e4-a9a0-228c307e387b.xml20201118-172928467_PULLREQUEST_RECV_5fc38a29-efd6-43b6-b411-d092f27c53c5.xml20201118-172928469_SYNCACK_SENT_973270ca-e05c-4dc4-9892-bfa24b9da453.xml20201118-173008196_GETSUBSCRIBERS_SENT_5e1ba713-7510-4f9b-aa49-6b2ae14fde47.xml20201118-173008200_SYNCACK_RECV_9bb2e9b4-4081-41cc-989b-47423fd41be4.xml20201118-180624920_PULLREQUEST_SENT_360e6c93-7c3d-46a3-b410-a27aba6dbb93.xml20201118-180624922_SYNCACK_RECV_326c18a7-119f-4bab-88b3-71fdec188739.xmlA.2.3Sending and receiving messages from the AIS adaptortbd Annex B:CDM PICS pro forma exampleB.1Partial cancellation of copyrightNotwithstanding the provisions of the copyright clause related to the text of the present document, ETSI grants that users of the present document may freely reproduce the PICS pro forma in this annex so that it can be used for its intended purposes and may further publish the completed PICS pro forma.B.2Guidance for completing the PICS pro formaB.2.1Purposes and structureThe purpose of this PICS pro forma is to provide a mechanism whereby a supplier of an implementation of the requirements defined in REF _Ref60658897 \r \h [i.4] may provide information about the implementation in a standardized manner.The PICS pro forma is subdivided into clauses for the following categories of information:guidance for completing the PICS pro forma;identification of the implementation;identification of the service in [i.4];global statement of conformance;PICS pro forma tables.B.2.2Abbreviations and conventionsThe PICS pro forma contained in this annex is comprised of information in tabular form in accordance with the guidelines presented in ISO/IEC?96467? REF _Ref61359981 \r \h [i.9] [REF REF_ISOIEC9646_7 \h \* MERGEFORMAT Error! Reference source not found.].Item columnThe item column contains a number which identifies the item in the table.Item description columnThe item description column describes in free text each respective item (e.g. parameters, timers, etc.). It implicitly means "is <item description> supported by the implementation?".Status columnThe following notations, defined in ISO/IEC?96467? REF _Ref61359981 \r \h [i.9] [REF REF_ISOIEC9646_7 \h \* MERGEFORMAT Error! Reference source not found.], are used for the status column:mmandatory - the capability is required to be supported.ooptional - the capability may be supported or not.n/anot applicable - in the given context, it is impossible to use the capability.xprohibited (excluded) - there is a requirement not to use this capability in the given context.o.iqualified optional - for mutually exclusive or selectable options from a set. "i" is an integer which identifies an unique group of related optional items and the logic of their selection which is defined immediately following the table.c.iconditional - the requirement on the capability ("m", "o", "x" or "n/a") depends on the support of other optional or conditional items. "i" is an integer identifying an unique conditional status expression which is defined immediately following the table.iirrelevant (out-of-scope) - capability outside the scope of the reference specification. No answer is requested from the supplier.NOTE 1:This use of "i" status is not to be confused with the suffix "i" to the "o" and "c" statuses above.Reference columnThe reference column makes reference to [i.4], except where explicitly stated otherwise.Support columnThe support column shall be filled in by the supplier of the implementation. The following common notations, defined in ISO/IEC?96467? REF _Ref61359981 \r \h [i.9] [REF REF_ISOIEC9646_7 \h \* MERGEFORMAT Error! Reference source not found.], are used for the support column:Y or ysupported by the implementation.N or nnot supported by the implementation.N/A, n/a or no answer required (allowed only if the status is n/a, directly or after evaluation of a conditional status).NOTE 2:As stated in ISO/IEC?96467?[REF REF_ISOIEC9646_7 \h \* MERGEFORMAT Error! Reference source not found.] REF _Ref61359981 \r \h [i.9] , support for a received PDU requires the ability to parse all valid parameters of that PDU. Supporting a PDU while having no ability to parse a valid parameter is nonconformant. Support for a parameter on a PDU means that the semantics of that parameter are supported.Values allowed columnThe values allowed column contains the type, the list, the range, or the length of values allowed. The following notations are used:-range of values:<min value> .. <max value>example: 5 .. 20-list of values:<value1>, <value2>, ..., <valueN>example: 2, 4, 6, 8, 9example:'1101'B, '1011'B, '1111'Bexample:'0A'H, '34'H, '2F'H-list of named values:<name1>(<val1>), <name2>(<val2>), ..., <nameN>(<valN>)example:reject(1), accept(2)-length:size (<min size> .. <max size>)example:size (1 .. 8)Values supported columnThe values supported column shall be filled in by the supplier of the implementation. In this column, the values or the ranges of values supported by the implementation shall be indicated.References to itemsFor each possible item answer (answer in the support column) within the PICS pro forma a unique reference exists, used, for example, in the conditional expressions. It is defined as the table identifier, followed by a solidus character "/", followed by the item number in the table. If there is more than one support column in a table, the columns are discriminated by letters (a, b, etc.), respectively.EXAMPLE 1:A.5/4 is the reference to the answer of item?4 in table?5 of annex?A.EXAMPLE 2:A.6/3b is the reference to the second answer (i.e. in the second support column) of item?3 in table?6 of annex?A.Prerequisite lineA prerequisite line takes the form: Prerequisite: <predicate>.A prerequisite line after a clause or table title indicates that the whole clause or the whole table is not required to be completed if the predicate is FALSE.B.2.3Instructions for completing the PICS pro formaThe supplier of the implementation shall complete the PICS pro forma in each of the spaces provided. In particular, an explicit answer shall be entered, in each of the support or supported column boxes provided.If necessary, the supplier may provide additional comments in space at the bottom of the tables or separately.More detailed instructions are given at the beginning of the different clauses of the PICS pro forma.B.3Identification of the implementationB.3.1IntroductionIdentification of the Implementation Under Test (IUT) and the system in which it resides (the System Under Test (SUT)) shall be filled in so as to provide as much detail as possible regarding version numbers and configuration options.The product supplier information and client information shall both be filled in if they are different.A person who can answer queries regarding information supplied in the PICS shall be named as the contact person.B.3.2Date of the statementB.3.3Implementation Under Test (IUT) identificationIUT name:IUT version:B.3.4System Under Test (SUT) identificationSUT name:Hardware configuration:Operating system:B.3.5Product supplierName:Address:Telephone number:Facsimile number:E-mail address:Additional information:B.3.6Client (if different from product supplier)Name:Address:Telephone number:Facsimile number:E-mail address:Additional information:B.3.7PICS contact person(A person to contact if there are any queries concerning the content of the PICS)Name:Telephone number:Facsimile number:E-mail address:Additional information:B.4Identification of the protocolThis PICS pro forma applies to the following standard REF _Ref61360094 \r \h [i.5] : ETSI GS [XX].B.5Global statement of conformanceAre all mandatory capabilities implemented? (Yes/No)NOTE:Answering "No" to this question indicates nonconformance to the CDM standard specification. Nonsupported mandatory capabilities are to be identified in the PICS, with an explanation of why the implementation is nonconforming, on pages attached to the PICS pro forma.B.6TablesUnless stated otherwise, the column references of all tables below indicates the clause numbers of ETSI GS 003in? REF _Ref61359820 \r \h [i.4] [ REF REF_EN302637_3 \h \* MERGEFORMAT Error! Reference source not found.].Table B.SEQ table3: IUT roleItemTypeReferenceStatusSupport1Node XXXXm2Adaptor YY YYo3Table B.SEQ table4: FunctionsItemTypeReferenceStatusSupport1Accounting REST Service (interface: AuditServiceWS)log (Log json)5.3.1.1c.example 2345678c.example if B.SEQ table StationType 3/1 then m else n/aTable B.SEQ table5: Security mode (if any)ItemTypeReferenceStatusSupport1X.509 certificateXXXmAnnex C:CDM Test Purpose exampleC.1Message Format In REF _Ref61423265 \h Table 6 Table XX an example of Test Purpose with header, reference to the Base Standard and the PICS is described.The test objective allows to check that sender Information in the payload are those previously set.Table SEQ Table \* ARABIC 6: An example of TPTP IdTP/NODE/COMMON/VESSEL-SERVICE/01Test objectiveCheck that sender Information in the payload are those previously set ReferenceETSI GS 004, clause XXPICS SelectionPICS_COMMON_SERVICE_PUSH_ VESSEL_-<SERVICE1>Initial conditionswith {the IUT being in the "operational state"}Expected behaviourensure that {when {the IUT receives a COMMON_SERVICE_PUSH_ VESSEL_-<SERVICE1>_Trigger request from the adaptor}then {the IUT sends a valid service messagecontaining PDU headercontaining ServerOperationindicating value “Push”and containing ServiceTypeindicating value “VesselService”}The actual message being produced by the IUT CISE Simulator is appended in the next section.C.2Message Payload<?xml version="1.0" encoding="UTF-8" standalone="yes"?><ns4:Push xmlns:ns2="" xmlns:ns4="" xmlns:ns3=""><CorrelationID>08facb59-e4b9-4563-86f3-ff340239f3b5 </CorrelationID><CreationDateTime>2020-11-18T17:17:16.872+01:00 </CreationDateTime> <MessageID>08facb59-e4b9-4563-86f3-ff340239f3b5</MessageID> <Priority>Low</Priority> <RequiresAck>false</RequiresAck> <Sender> <SeaBasin>NorthSea</SeaBasin> <ServiceID>de.sim1-node01.vessel.push.provider</ServiceID> <ServiceOperation>Push</ServiceOperation> <ServiceRole>Provider</ServiceRole> <ServiceStatus>Online</ServiceStatus> <ServiceType>VesselService</ServiceType> </Sender> <Recipient> <SeaBasin>NorthSea</SeaBasin> <ServiceID>de.sim2-node01.vessel.push.consumer</ServiceID> <ServiceOperation>Push</ServiceOperation> <ServiceRole>Consumer</ServiceRole> <ServiceStatus>Online</ServiceStatus> <ServiceType>VesselService</ServiceType> </Recipient> <Payload xsi:type="ns4:XmlEntityPayload" xmlns:xsi= ""> <InformationSecurityLevel>NonClassified</InformationSecurityLevel> <InformationSensitivity>Green</InformationSensitivity> <IsPersonalData>false</IsPersonalData> <Purpose>NonSpecified</Purpose> <EnsureEncryption>false</EnsureEncryption> <Vessel> <IMONumber>7710525</IMONumber> </Vessel> </Payload> <Signature xmlns="">signature discarded </Signature></ns4:Push>HistoryDocument history<Version><Date><Milestone>0.01Oct 13th, 2020Initial draft with preliminary Outline, References, Description of the IUT0.02Nov. 23rd, 2020Initial description of the testing environment with “Lightweight testing box”. Appendix A about practical how-to for simulator installation included.0.03Dec. 7th, 2020Full description of the IUT. Sections about Conformance and Interoperability tests drafted. Annexes with examples included.0.04Jan. 8th, 2021All sections with initial text are included. Ready to be shared with the other experts in ETSI CDM.0.05Jan. 13th, 2021More information about Conformance Testing. Fixes and updates in all sections. Annex D and E placeholders removed. Informative references formatted following the ETSI style. ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download