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.3 (2020-12)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 _Toc58252227 \h 5Foreword PAGEREF _Toc58252228 \h 5Modal verbs terminology PAGEREF _Toc58252229 \h 5Executive summary PAGEREF _Toc58252230 \h 5Introduction PAGEREF _Toc58252231 \h 51Scope PAGEREF _Toc58252232 \h 72References PAGEREF _Toc58252233 \h 82.1Normative references PAGEREF _Toc58252234 \h 82.2Informative references PAGEREF _Toc58252235 \h 83Definition of terms, symbols and abbreviations PAGEREF _Toc58252236 \h 83.1Terms PAGEREF _Toc58252237 \h 83.2Symbols PAGEREF _Toc58252238 \h 83.3Abbreviations PAGEREF _Toc58252239 \h 84Description of the IUT PAGEREF _Toc58252240 \h 94.1IUT internal structure PAGEREF _Toc58252241 \h 94.2IUT external interfaces PAGEREF _Toc58252242 \h 105The testing environment PAGEREF _Toc58252243 \h 115.1Lightweight testing box PAGEREF _Toc58252244 \h 115.2The CISE testing network PAGEREF _Toc58252245 \h 116Conformance testing PAGEREF _Toc58252246 \h 116.1Functional requirements to be tested PAGEREF _Toc58252247 \h 116.2Test Purposes (TP) and Test Suite Specification (TSS) PAGEREF _Toc58252248 \h 127Interoperability testing PAGEREF _Toc58252249 \h 127.1Functional requirements to be tested PAGEREF _Toc58252250 \h 127.2The Qualified Equipment PAGEREF _Toc58252251 \h 137.3Protocol to be tested PAGEREF _Toc58252252 \h 138Final Recommendations PAGEREF _Toc58252253 \h 139Conclusions and outlook PAGEREF _Toc58252254 \h 13Annex A: Installing the “Lightweight testing box” PAGEREF _Toc58252255 \h 14A.1Downloading CISESIM VM PAGEREF _Toc58252256 \h 14A.2Checking VM behaviour PAGEREF _Toc58252257 \h 14A.2.1Process status PAGEREF _Toc58252258 \h 14A.2.2Sending and receiving messages from command line PAGEREF _Toc58252259 \h 15Annex B: CDM PICS pro forma example PAGEREF _Toc58252260 \h 17B.1Partial cancellation of copyright PAGEREF _Toc58252261 \h 17B.2Guidance for completing the PICS pro forma PAGEREF _Toc58252262 \h 17B.2.1Purposes and structure PAGEREF _Toc58252263 \h 17B.2.2Abbreviations and conventions PAGEREF _Toc58252264 \h 17B.2.3Instructions for completing the PICS pro forma PAGEREF _Toc58252265 \h 19B.3Identification of the implementation PAGEREF _Toc58252266 \h 19B.3.1Introduction PAGEREF _Toc58252267 \h 19B.3.2Date of the statement PAGEREF _Toc58252268 \h 19B.3.3Implementation Under Test (IUT) identification PAGEREF _Toc58252269 \h 19B.3.4System Under Test (SUT) identification PAGEREF _Toc58252270 \h 20B.3.5Product supplier PAGEREF _Toc58252271 \h 20B.3.6Client (if different from product supplier) PAGEREF _Toc58252272 \h 20B.3.7PICS contact person PAGEREF _Toc58252273 \h 21B.4Identification of the protocol PAGEREF _Toc58252274 \h 21B.5Global statement of conformance PAGEREF _Toc58252275 \h 21B.6Tables PAGEREF _Toc58252276 \h 22Annex C: CDM Test Case example PAGEREF _Toc58252277 \h 22C.1Message Format PAGEREF _Toc58252278 \h 22C.2Message Payload PAGEREF _Toc58252279 \h 23Annex D: CDM Test Events PAGEREF _Toc58252280 \h 24D.1Message Format PAGEREF _Toc58252281 \h 24Annex E: Bibliography PAGEREF _Toc58252282 \h 24Annex : Change History PAGEREF _Toc58252283 \h 25History PAGEREF _Toc58252284 \h 26Intellectual 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 summarytbdIntroductionAs from the Conformance Testing guide [ETS 300 406], 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:Figure SEQ Figure \* ARABIC 1: How to design a testing system for conformance testing using ETSI formal methodology.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 Suite (ATS)In this report we assume to be able to rely on a comprehensive set of Base Standards so that it will be possible to technically define the IUT and its interfaces. We will therefore provide enough information to the interested companies and public bodies to deliver the full documentation stated above. We will also include a description of the target testing network that will be used to check the interoperability [ETSI EG 202 810] of the IUT with a qualified equipment (see REF _Ref57971287 \h REF _Ref57971295 \h Figure 2).Figure SEQ Figure \* ARABIC 2: How to design a testing network for interoperability.The 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 SEQ Figure \* ARABIC 3: The CISE peer-to-peer architecture.The CISE instance to be tested is called Implementation Under Test (IUT) and overlaps with the “Node” functional block including eventual adaptors, pictorially shown in REF _Ref53504490 \h Figure 2:Figure SEQ Figure \* ARABIC 4: The CISE network with two Nodes locally connected to Legacy Systems.The minimal set of functions to be considered in the IUT along with its external interfaces are described in Section XX.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 instance complying with CDM standards and capable of interoperating with other standard instances implemented by other organizations.In each Chapter after a high-level description of the standardized specifications we will provide a recommendation to properly address the testing specification activity. 2References2.1Normative referencesNormative references are not applicable in the present document.2.2Informative referencesInformative references include the set of ?Base Standards? representing the minimum requirements a certain implementation must satisfy. In our case:(GS CDM 002) CDM System Requirements(GS CDM 003) CDM Acrhitecture (Including Common&Core Services)(GS CDM 004) Specifications on protocol (Service Model included); (GS CDM 005) CDM Data ModelReferences 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]?etc.3Definition of terms, symbols and abbreviations3.1TermsFor the purposes of the present document, the [following] terms [given in ... and the following] apply: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 interconnected in a Local Network 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 Figure XX:Figure SEQ Figure \* ARABIC 5: A possible configuration of the CISE node behind a firewall.The Business Logic functionalities are described in [CDM3] 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.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 future work will need to select this subset according to the following recommendations:The Auditing Services limited to the logging service as described in Section 5.3.1.1 [CDM3]The Application Security Services limited to Authorization Service (what service??) subscription (Pull request) as described in Section 5.3.1.2.2 [CDM3];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 [CDM3];…4.2IUT external interfacesFigure SEQ Figure \* ARABIC 6: 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 Service Types, say Vessel Service and CargoService;it is required to test a Discover, a Pull and a Push request.5The testing environmentThe implementer providing a CISE 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 format) 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 applicationIt will be possible to use the CISE Sim application for sending and receiving CISE messages to/from CISE Nodes, adaptors or other CISE Sim’s. The messages managed by the CISE simulator follow the data model standardized in GS CDM-004 and the protocol standardized in GS CDM-005.The CISE Sim features the following functionality:send CISE messages using a template receive 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 model described in Sec. 6.2.A practical how-to is included in Appendix 1.5.2The CISE testing networkIn this clause we will describe the (new) testing infrastructure instantiated in a private cloud.6Conformance testing6.1Functional requirements to be testedThe target is to make available a certain number of 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 an example related to the logging service 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).The Future Work will therefore fill in the table below defining a menomic for each implemented function to be tested and putting reference to the PICS item in the relevant table.Table 1: Mnemonics for PICS referenceMnemonicPICS itemPICS_CORE_AUDIT_LOGGINGA.XXPICS_CORE_APPLICATION_AUTHORIZATION_SUBSCRIPTION_<SERVICE1>A.XXPICS_CORE_NET_SERVICE-MANAGER_PUBLISHA.XXPICS_CORE_NET_SERVICE-MANAGER_DELETEA.XX… other core servicesA.XXPICS_COMMON_SERVICE_DISCOVERA.XXPICS_COMMON_SERVICE_PULL_ CARGO_-<SERVICE1>A.XXPICS_COMMON_SERVICE_PUSH_ VESSEL_-<SERVICE1>A.XX6.2Test Purposes (TP) and Test Suite Specification (TSS)As the set of PICS is let available from the Future Work the supplier will be provided by an actual Test Suite. An example for a VesselService Push is reported in Annex C.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 maintainer of the Qualified Equipment (see Figure XX and Section 7.2).Figure SEQ Figure \* ARABIC 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.Test messages and expected feedback are included in Annex D.7.2The Qualified EquipmentIn this clause we will describe (with the help of EMSA) the node installed in EMSA network and how to connect to it via VPN.7.3Protocol to be testedSOAP/REST8Final Recommendationscompletion of mandatory/optional features of CISE nodesdevelopment of a testing platform: connecting Simulator and Adaptors, connecting with the Pre-operational Networktesting eventsa convener (ETSI) and some implementers all together providing implementation under test(more than 2 or 3 companies)9Conclusions and outlookAnnex 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 SEQ Figure \* ARABIC 8: An example of CISE Simulator for a Windows host.In REF _Ref57014661 \h Figure 7 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.xmlAnnex 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 ETSI GS 003 [XX] 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 ETSI GS 003 [XX];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 REF_ISOIEC9646_7 \h \* MERGEFORMAT i.2].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 REF_ISOIEC9646_7 \h \* MERGEFORMAT i.2], 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 ETSI GS 003 [XX], 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 REF_ISOIEC9646_7 \h \* MERGEFORMAT i.2], 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 i.2], 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: 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 003?[ REF REF_EN302637_3 \h \* MERGEFORMAT 1].Table B.SEQ table1: IUT roleItemTypeReferenceStatusSupport1Node XXXXm2Adaptor YY YYo3Table B.SEQ table2: FunctionsItemTypeReferenceStatusSupport1log (Log json)5.3.1.1c.example 2345678c.example if B.SEQ table StationType 1/1 or B.SEQ table StationType 1/3 then m else n/aTable B.SEQ table3: Security mode (if any)ItemTypeReferenceStatusSupport1X.509 certificateXXXmAnnex C:CDM Test Case exampleC.1Message Format In Table XX an example of the case 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.TP IdTP/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 an 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 parsed 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>Annex D:CDM Test EventsD.1Message Example Annex E:BibliographyHistoryDocument 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.Latest changes made on 2020-12-07 ................
................

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

Google Online Preview   Download