ETSI TR 103 099 V1.2.1 (2014-05)

Intelligent Transport Systems (ITS); Architecture of conformance validation framework

RTR/ITS-00340

General Information

• Status: Published
• Publication Date: 18-May-2014
• Technical Committee: ITS WG3 - Transport and Network
• Current Stage: 12 - Completion
• Due Date: 16-Jun-2014
• Completion Date: 19-May-2014

Standards Content (Sample)

ETSI TR 103 099 V1.2.1 (2014-05)






Technical Report
Intelligent Transport Systems (ITS);
Architecture of conformance validation framework

---------------------- Page: 1 ----------------------
2 ETSI TR 103 099 V1.2.1 (2014-05)



Reference
RTR/ITS-00340
Keywords
architecture, conformance, ITS, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org
The 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 only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
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
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No 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.

© European Telecommunications Standards Institute 2014.
All rights reserved.

TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI

---------------------- Page: 2 ----------------------
3 ETSI TR 103 099 V1.2.1 (2014-05)
Contents
Intellectual Property Rights . 5
Foreword . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Abbreviations . 7
4 Test platform overview . 8
4.1 Constraints and requirements . 8
4.2 General architecture . 8
5 Hardware equipment . 9
5.1 PC . 9
5.2 G5 adapter box . 10
6 Codecs . 10
6.1 Introduction . 10
6.2 Advanced details of implementation . 11
7 Test Adapter . 12
7.1 Introduction . 12
7.2 Lower Tester . 13
7.2.1 Overview . 13
7.2.2 Advanced details of implementation . 15
7.2.3 Extensibility of the test adapter. 17
7.2.4 Adapter Control primitives . 17
7.3 Platform Adapter . 17
7.4 Upper Tester . 17
Annex A: Codecs Source Code . 19
Annex B: Test Adapter Source Code . 20
Annex C: Upper Tester Message Format. 21
C.1 Common Upper Tester Primitives . 21
C.1.1 UtInitialize . 21
C.1.2 ChangePosition . 22
C.2 CAM Upper Tester Primitives . 23
C.2.1 ChangeCurvature . 23
C.2.2 ChangeSpeed . 23
C.2.3 SetAccelerationControlStatus. 24
C.2.4 SetExteriorLightsStatus . 25
C.2.5 ChangeHeading . 26
C.2.6 SetDriveDirection . 26
C.2.7 ChangeYawRate . 27
C.2.8 CamEventIndication . 27
C.2.9 SetStationType . 27
C.2.10 SetVehicleRole . 28
C.2.11 SetEmbarkationStatus . 29
C.2.12 SetPtActi vatio n . 29
C.2.13 SetDangerousGoods . 30
C.2.14 SetDangerousGoodsExtended . 31
C.2.15 SetLightBarSiren . 31
ETSI

---------------------- Page: 3 ----------------------
4 ETSI TR 103 099 V1.2.1 (2014-05)
C.3 DENM Upper Tester Primitives . 32
C.3.1 GenerateDenmEvent . 32
C.3.2 UpdateDenmEvent . 34
C.3.3 TerminateDenmEvent . 35
C.3.4 DenmEventIndication . 35
C.4 GeoNetworking Upper Tester Primitives . 36
C.4.1 GenerateGeoUnicast . 36
C.4.2 GenerateGeoBroadcast . 36
C.4.3 GenerateGeoAnycast . 37
C.4.4 GenerateSHB . 38
C.4.5 GenerateTSB . 38
C.4.6 GnEventIndication. 39
C.5 IPv6OverGeoNetworking Upper Tester Primitives . 39
C.5.1 SendIPv6Message . 39
C.5.2 GetInterfaceInfos . 40
C.5.3 Gn6EventIndication. 40
C.6 BTP Upper Tester Primitives . 41
C.6.1 GenerateBtpA . 41
C.6.2 GenerateBtpB . 41
C.6.3 BtpEventIndication . 42
Annex D: Example of Test Platform implementation . 43
Annex E: Complete Test Adapter class diagram . 47
Annex F: Bibliography . 48
History . 50

ETSI

---------------------- Page: 4 ----------------------
5 ETSI TR 103 099 V1.2.1 (2014-05)
Intellectual Property Rights
IPRs essential or potentially essential to the present document 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 (http://ipr.etsi.org).
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.
Foreword
This Technical Report (TR) has been produced by ETSI Technical Committee Intelligent Transport Systems (ITS).
Introduction
In response to EC mandate M/453 [i.14], ETSI Technical Committee (TC) ITS has standardized base and test
specifications for ITS protocols. In a next step a prototype TTCN-3 test system was built and validated. The present
document and its related TR 103 061 series [i.3] to [i.7], describe the design and validation of the prototype TTCN-3
test system.
The action described in the present document has supported the implementation of ITS standards by:
• Making available validated and standardized test specifications and thus enabling the application of reliable
certification schemes.
• Executing conformance validation framework against real Implementations Under Test (IUTs) from industry
and thus providing these companies a conformance assessment of their implementations. During the lifetime
of this action, the conformance validation framework was as well provided at ITS Cooperative Mobility
Services Interoperability events.
• Releasing all software as open source and thus allowing industry to build and run their own conformance
validation framework.
ETSI

---------------------- Page: 5 ----------------------
6 ETSI TR 103 099 V1.2.1 (2014-05)
1 Scope
The present document provides a description of the architecture of the ITS conformance validation framework,
including definition of the test environment, codec and test adapter. It provides, as well, all the necessary source code to
build and run the ITS conformance validation framework.
The ITS conformance validation framework integrates the test suites TS 102 871-3 [i.9], TS 102 868-3 [i.10],
TS 102 869-3 [i.11], TS 102 870-3 [i.12] and TS 102 859-3 [i.13]. The results of the validation are described in the
TR 103 061 series [i.3] to [i.7].
2 References
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
Not applicable.
2.2 Informative references
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] ETSI ES 201 873-5 (V4.5.1): "Methods for Testing and Specification (MTS); The Testing and
Test Control Notation version 3; Part 5: TTCN-3 Runtime Interface (TRI)".
[i.2] ETSI EG 201 015 (V2.1.1): "Methods for Testing and Specification (MTS); Standards engineering
process; A handbook of validation methods".
[i.3] ETSI TR 103 061-1 (V1.2.1): "Intelligent Transport Systems (ITS); Testing; Part 1: Conformance
test specifications for Co-operative Awareness Messages (CAM); CAM validation report".
[i.4] ETSI TR 103 061-2 (V1.2.1): "Intelligent Transport Systems (ITS); Testing; Part 2: Conformance
test specifications for Decentralized Environmental Notification basic Service Messages (DENM);
DENM validation report".
[i.5] ETSI TR 103 061-3 (V1.2.1): "Intelligent Transport Systems (ITS); Testing; Part 3: Conformance
test specifications for Geographical addressing and forwarding for point-to-point and point-to-
multipoint communications; GeoNetworking validation report".
[i.6] ETSI TR 103 061-4 (V1.1.1): "Intelligent Transport Systems (ITS); Testing; Part 4: Conformance
test specification for GeoNetworking Basic Transport Protocol (BTP); GeoNetworking BTP
validation report".
[i.7] ETSI TR 103 061-5 (V1.1.1): "Intelligent Transport Systems (ITS); Testing; Part 5: IPv6 over
GeoNetworking validation report".
ETSI

---------------------- Page: 6 ----------------------
7 ETSI TR 103 099 V1.2.1 (2014-05)
[i.8] IEEE 802.11p: "IEEE Standard for Local and Metropolitan Area Networks - Specific
requirements; Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications; Amendment 6: Wireless Access in Vehicular Environments".
[i.9] ETSI TS 102 871-3(V.1.2.1): " Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for GeoNetworking ITS-G5; Part 3: Abstract Test Suite (ATS) and Protocol
Implementation eXtra Information for Testing (PIXIT)".
[i.10] ETSI TS 102 868-3 (V.1.2.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for Co-operative Awareness Messages (CAM); Part 3: Abstract Test Suite (ATS)
and Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.11] ETSI TS 102 869-3 (V.1.3.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for Decentralized Environmental Notification Messages (DENM); Part 3: Abstract
Test Suite (ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.12] ETSI TS 102 870-3 (V.1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for Geonetworking Basic Transport Protocol (BTP); Part 3: Abstract Test Suite
(ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.13] ETSI TS 102 859-3 (V.1.2.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specifications for Transmission of IP packets over Geonetworking; Part 3: Abstract Test Suite
(ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.14] EC mandate M/453: "Standardisation mandate addressed to CEN, CENELEC and ETSI in the
field of Information and Communication Technologies to support the interoperability of co-
operative systems for Intelligent Transport in the European Community".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AC Adapter Control
ACC Adaptive Cruise Control
API Application Programming Interface
ASN Abstract Syntax Notation
ATS Abstract Test Suite
BTP Basic Transport Protocol
CAM Cooperative Awareness Message
CC Cruise Control
DENM Decentralized Environmental Notification Message
ETH Ethernet
GN GeoNetworking
HB High Beam
IP Internet Protocol
ITS Intelligent Transportation Systems
IUT Implementation Under Test
JDK Java™ Development Kit
KAF Keep Alive Functionality
LB Low Beam
LT Left Turn
MAC Media Access Control
OS Operating System
OSI Open Systems Interconnection model
PC Personal Computer
Pcap Packet Capture
PDU Protocol Data Unit
PICS Protocol Implementation Conformance Statement
RT Right Turn
SHB Single Hop Broadcast
SUT System Under Test
ETSI

---------------------- Page: 7 ----------------------
8 ETSI TR 103 099 V1.2.1 (2014-05)
TA Test Adapter
TC Test Cases
TCI TTCN-3 Control Interface
TP Test Purposes
TRI TTCN-3 Runtime Interface
TSB Topology Scoped Broadcast
TTCN-3 Testing and Test Control Notation 3
UDP User Datagram Protocol
UT Upper Tester
4 Test platform overview
4.1 Constraints and requirements
The purpose of the ITS test platform is to provide a reliable set of software and hardware equipments that can be used to
validate TTCN-3 abstract test suites (ATS) developed in ETSI.
The architecture of this test platform has been designed with respect to the following constraints:
• to be compatible with the requirements expressed in the validation handbook (EG 201 015 [i.2]);
• to be independent of the platform used to implement the test system;
• to be independent of the TTCN-3 tool provider;
• to be configurable and customizable;
• to provide tools and well defined interfaces to system under test (SUT), allowing test automation;
• to be easily extensible for future ITS protocols;
• to provide generic components that can be reused in other test platforms.
In order to ensure independence of hardware platforms, all software pieces running on the test platform have been
implemented using Java™ language, using generic and widely used libraries.
Test tool independence has been achieved by isolating the tool specific interfaces from core functionalities of the
platform. Adapting the current platform to a different test tool would only require the implementation of a very simple
piece of software mapping tool-specific functions to generic functions defined in this project.
In addition, great care has been taken to separate ITS specific functionalities from generic test platform tasks in order to
provide a maximum number of reusable components for future test platforms.
4.2 General architecture
Typically a TTCN-3 test platform is composed of four different components:
• The TTCN-3 test tool providing necessary software to execute the abstract test suites.
• The hardware equipment supporting TTCN-3 test execution and adaptation to SUTs.
• The codecs which convert protocol messages into their abstract TTCN-3 representation.
• The Test Adapter (TA) implementing interfaces with the device under test.
The interaction of these components is described in figure 1.
ETSI

---------------------- Page: 8 ----------------------
9 ETSI TR 103 099 V1.2.1 (2014-05)
c
e
d
o
C

Figure 1: General architecture
The TTCN-3 test tools are usually provided by commercial companies and their description is out of the scope of the
present document. The implementation details of the other components are described in the following clauses.
5 Hardware equipment
5.1 PC
The main hardware component of the ITS test platform is a standard PC. Its role is to host the execution of the test
suites using a commercial TTCN-3 test tool.
Whatever operating system is installed on the computer, it is necessary to ensure that the following points are taken into
account:
• No firewall interference with traffic generated by the Test System and/or SUT.
• Excellent time synchronization between the SUT and the test system.
• Test system processes (especially the test adapter) have to be granted unrestricted control to
telecommunication hardware.
Time synchronization is maybe the most critical point to be checked before starting any test session, as it can be the
source of strange SUT behaviour and generate incoherent results. Indeed, most ITS protocol messages feature a time tag
used by the receiver to determine if the information it carries is still valid; if the test system is ahead in time, all
messages it sends will be considered either as coming from the future or from a very old date, and be discarded.
This PC is equipped with two network cards, one being used for ITS communication with SUT (lower layers link), the
other one being used for exchanging upper tester messages (upper tester transport link). Separating these two
communications on different hardware interfaces is not an absolute necessity, but it is a good practice and it ensures that
there will be no interaction between the flows.
The communication between the SUT and the test system is achieved through Ethernet if the SUT supports it or using a
G5 adaptation box.
ETSI

---------------------- Page: 9 ----------------------
10 ETSI TR 103 099 V1.2.1 (2014-05)

Figure 2: Communication via G5 adaptation box

Figure 3: Communication via Ethernet
5.2 G5 adapter box
The ITS protocol stack makes use of G5 radio protocol in order to establish communication between ITS devices. To
achieve G5 connectivity, a dedicated hardware equipment needs to be added to the test platform. The role of this
adaptation box is to handle all radio-related tasks transparently and to act as a bridge for the test system.
TM
Cohda Wireless MK2 has been chosen to fulfil this task. This device is fully IEEE 802.11p [i.8] compliant and
provides as well an Ethernet interface so that it can be used as a transparent bridge between the test system and the
SUT, as depicted in figure 2.
To transfer frames received on the Ethernet interface to the radio interface and vice versa, it is necessary to install and
execute a small bridge application on the MK2. Only the frame featuring a specific ethertype (0x0707 by default) will
be transferred from one interface to the other, so that only desired traffic will cross the bridge.
6 Codecs
6.1 Introduction
The codec entity is responsible for the encoding and decoding of TTCN-3 abstract values into bitstrings suitable to be
sent to the System Under Test (SUT).
In order to simplify implementation and to ease the maintenance, coding and decoding tasks are handled by several
codecs:
• One independent codec package per tested protocol;
• One codec package for TTCN-3 types that do not correspond to real protocol messages. It includes for
example all auxiliary types used to carry information to/from Test Adapter, like the ones defined in
TestSystem modules (CoapInd, CoapReq, etc.);
• One generic codec package available for handling default codec operation non related to any specific protocol.
Theses codecs will be used if no protocol-specific codec exists for one type.
ETSI

---------------------- Page: 10 ----------------------
11 ETSI TR 103 099 V1.2.1 (2014-05)
6.2 Advanced details of implementation
Figure 4 gives an overview of the relations between the different Java™ classes implementing the codecs. Connection
with the tool-dependent classes is realized through the ITERquired interface and the associated factory class.
Each codec is responsible for correctly encoding and decoding one specific type and implements the ICodec interface.
Selection of correct codec for encoding or decoding a message at runtime is managed by the CodecFactory class, via the
getCodec() method. This method will select the appropriate codec based on three parameters:
• the type name;
• the encoding as specified in TTCN-3 modules using "with encode" statements;
• the type class (record, union, etc.).
The rules for selecting the correct codec are the following:
1) If a codec is registered for type name in the package corresponding to encoding, then select this codec
and call encode() or decode() method;
2) Otherwise, if a codec is registered for type class in the package corresponding to encoding, then select
this codec and call encode() or decode() method;
3) Otherwise, use codec corresponding to type class in generic package.
This design provides both flexibility and easy extensibility. For most protocols, the "generic" codec package will handle
most of the encoding and decoding operations. Specific encoding processes can be handled case by
...