ETSI TR 103 099 V1.1.1 (2012-11)

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

DTR/ITS-0030038

General Information

• Status: Published
• Publication Date: 05-Nov-2012
• Technical Committee: ITS WG3 - Transport and Network
• Current Stage: 12 - Completion
• Due Date: 20-Nov-2012
• Completion Date: 06-Nov-2012

Standards Content (Sample)

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

�
2 ETSI TR 103 099 V1.1.1 (2012-11)

Reference
DTR/ITS-0030038
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
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the 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 except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2012.
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
3 ETSI TR 103 099 V1.1.1 (2012-11)
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 Advanced details of implementation . 12
7 Test Adapter . 12
7.1 Lower Tester . 13
7.1.1 Overview . 13
7.1.2 Advanced details of implementation . 15
7.1.3 Extensibility of the test adapter. 17
7.1.4 Adapter Control primitives . 17
7.2 Platform Adapter . 17
7.3 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 CAM Upper Tester Primitives . 21
C.1.1 CamInitialize . 21
C.1.2 ChangeHeading . 22
C.1.3 ChangePosition . 22
C.1.4 ChangeSpeed . 22
C.1.5 SetCrashSignal . 23
C.1.6 SetDangerousGoodsStatus . 23
C.1.7 SetLengthWidthPrecision . 23
C.1.8 SetDistanceToStopLine . 23
C.1.9 SetTurnAdvice . 24
C.1.10 SetCurvature . 24
C.1.11 SetOccupancy . 24
C.1.12 SetDoorStatus . 25
C.1.13 SetLightBarStatus . 25
C.1.14 SetSireneStatus . 25
C.1.15 SetTrafficLightPriority . 26
C.1.16 SetScheduleDeviation . 26
C.1.17 SetPtLineDescription. 26
C.1.18 SetExteriorLightsStatus . 27
C.1.19 CheckCam . 27
C.2 DENM Upper Tester Primitives . 27
ETSI
4 ETSI TR 103 099 V1.1.1 (2012-11)
C.2.1 DenmInitialize . 27
C.2.2 GenerateDenmEvent . 28
C.2.3 CancelDenmEvent . 28
C.2.4 NegateDenmEvent. 29
C.2.5 UpdateDenmEvent . 29
C.2.6 CheckDenm . 29
C.3 GeoNetworking Upper Tester Primitives . 30
C.3.1 GnInitialize . 30
C.3.2 GenerateGeoUnicast . 30
C.3.3 GenerateGeoAnycast . 30
C.3.4 GenerateGeoBroadcast . 31
C.3.5 GenerateSHB . 31
C.3.6 GenerateTSB . 32
C.3.7 CheckPacket . 32
Annex D: MK2 bridge application . 33
Annex E: Example of Test Platform implementation . 34
Annex F: Complete Test Adapter class diagram . 38
Annex G: Validated ATS in TTCN-3 and ASN.1 modules . 39
Annex H: Bibliography . 40
History . 42

ETSI
5 ETSI TR 103 099 V1.1.1 (2012-11)
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 System (ITS).
Introduction
In response to EC mandate M/453, 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, 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
6 ETSI TR 103 099 V1.1.1 (2012-11)
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 CAM, DENM, BTP and GeoNetworking abstract test suites
(ATS) ([i.10] to [i.13]). The results of the validation are described in the TR 103 061 series [i.4] to [i.8].
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.2.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 ES 201 873-6 (V4.2.1): "Methods for Testing and Specification (MTS); The Testing and
Test Control Notation version 3; Part 6: TTCN-3 Control Interface (TCI)".
[i.3] ETSI EG 201 015 (V2.1.1): "Methods for Testing and Specification (MTS); Standards engineering
process; A handbook of validation methods".
[i.4] ETSI TR 103 061-1 (V1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specification for Co-operative Awareness Messages (CAM); CAM validation report".
[i.5] ETSI TR 103 061-2 (V1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specification for Decentralized Environmental Notification basic Service Message (DENM);
DENM validation report".
[i.6] ETSI TR 103 061-3 (V1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specification for Geographical addressing and forwarding for point-to-point and point-to-
multipoint communications; GeoNetworking validation report".
[i.7] ETSI TR 103 061-4 (V1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specification for GeoNetworking Basic Transport Protocol (BTP); GeoNetworking BTP validation
report".
[i.8] ETSI TR 103 061-5 (V1.1.1): "Intelligent Transport Systems (ITS); Testing; IPv6 over
GeoNetworking validation report".
ETSI
7 ETSI TR 103 099 V1.1.1 (2012-11)
[i.9] 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.10] ETSI TS 102 859-3 (V.1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specification for Transmission of IP packets over GeoNetworking; Part 3: Abstract Test Suite
(ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.11] ETSI TS 102 868-3 (V.1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specification for Co-operative Awareness Messages (CAM); Part 3: Abstract Test Suite (ATS) and
Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.12] ETSI TS 102 869-3 (V.1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specification for Of Decentralized Environmental Notification basic Service (DENM); Part 3:
Abstract Test Suite (ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)".
[i.13] 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)".
3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AC Adapter Control
API Application Programming Interface
ASN Abstract Syntax Notation
ATS Abstract Test Suite
BTP Basic Transport Protocol
CAM Cooperative Awareness Message
CT Causer Type
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
LB Low Beam
LDM Local Dynamic Map
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
RT Right Turn
SHB Single Hop Broadcast
SUT System Under Test
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
ETSI
8 ETSI TR 103 099 V1.1.1 (2012-11)
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.3]);
• 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
9 ETSI TR 103 099 V1.1.1 (2012-11)
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
The ITS test platform is composed of two hardware equipments, a standard PC and a G5 adapter box.
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 synchronisation between the SUT and the test system.
• Test system processes (especially the test adapter) have to be granted unrestricted control to
telecommunication hardware.
Time synchronisation 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
10 ETSI TR 103 099 V1.1.1 (2012-11)

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.9] 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. The source code of this
program and its configuration file are provided in annex D.
6 Codecs
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 simplify implementation and to ease the maintenance, coding and decoding tasks are handled by several
codecs:
• One independent codec per ITS protocol.
• One codec 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
(GeoNetworkingInd, GeoNetworkingReq, etc.).
For protocol messages defined in ASN.1 (CAM and DENM protocols), usage of dedicated commercial ASN.1 tools is
recommended.
ETSI
11 ETSI TR 103 099 V1.1.1 (2012-11)

Figure 4: Codec package organisation
Selection of correct codec for encoding a message at runtime is dictated by means of the "with encode" statement within
TTCN-3 modules. For instance the following statement:
with {
encode "LibItsGeoNetworking_TypesAndValues"
}
will cause org.etsi.its.codec.ttcn.LibItsGeoNetworking_TypesAndValuesCodec to be invoked.
ETSI
12 ETSI TR 103 099 V1.1.1 (2012-11)
6.1 Advanced details of implementation
Figure 5 gives an overview of the relations between the different java classes implementing the codec. The structure is
relatively simple. Connection with the tool-dependent classes is realized through the ICodec interface and is not
depicted in figure 5.
Figure 5: Codec class diagram
Each codec implements the standard TCI interface TciCDProvided as described in ES 201 873-6 [i.2]. In addition
codecs have to implement the ICodec interface, which is providing a tool-independent instantiation API to TTCN-3
tools.
The BaseCodecImpl class implements the minimal functionalities of a codec and is used as a base class for further
codec development. For extensibility purpose, this class is not ITS-specific, and it can be used as-is in other platform
projects.
The ItsCodecImpl class directly extends BaseCodecImpl and provides ITS common codec functionalities. Each ITS
codec derives from this class.
7 Test Adapter
The test adapter conceptually splits into three parts:
• a lower test adapter;
• a TTCN-3 platform adapter implementing timers;
• an upper test adapter.
ETSI
13 ETSI TR 103 099 V1.1.1 (2012-11)
7.1 Lower Tester
7.1.1 Overview
TTCN-3 test suites are usually focusing on a single protocol layer and designed to be executed against real
implementations (IUT). However it is unusual to find standalone implementations as they are commonly integrated as
an internal component of a physical device (SUT).
The purpose of a lower test adapter is to prepare and adapt the protocol messages used by TTCN-3 test suites so that
they can be transmitted successfully to the SUT. One way to achieve this goal is for example to implement lower layers
and encapsulate protocol messages accordingly. For instance, CAM and DENM messages need to be encapsulated in
BTP datagrams, themselves encapsulated into GeoNetworking packets, and transmitted over G5 radio link. The higher
up the IUT is located in the OSI stack, the more complex is the test adapter.
TTCN-3 test suites send and receive protocol messages via TTCN-3 communication ports. For each of these ports
defined in the test suites, a corresponding port entity needs to be implemented in the test adapter using standardised TRI
interface (ES 201 873-5 [i.1]). To provide maximum flexibility and allow for extensibility, the test adapter ports of the
ITS test platform have been designed with the following constraints:
• For each port family, the lower stack can be configured using test adapter parameters (see annex E). As a
consequence it is possible to dynamically define what will be the lower layers used to communicate with SUT,
and how protocol messages will be encapsulated.
• All the instances of ports are independent.
• Behaviour of ports and lower layers can be dynamically modified by using predefined AC (Adapter Control)
primitives directly sent from TTCN-3 script using dedicated port AcPort. For example the AC primitive
'startBeaconing' requests the test adapter to start sending beacons.
The test adapter implementation mainly features Port and Layer objects. The relationship and interactions between
these objects will be further detailed in the next section, but it is important to notice the main differences between these
objects, as misunderstanding their roles can lead to confusion:
• Port objects are the counterpart of TTCN-3 communication ports.
• Layer objects implement the minimal functionalities of a protocol layer and provide facilities for
encapsulating or decapsulating packets.
• Port objects are configured with a lower stack composed of cascading Layer objects.
• For a same protocol layer, Layer objects usually implement more functionalities than Port objects.
Figures 6 and 7 show an example of interactions between these objects respectively when sending and receiving a
message. The port described in this example is a CAM port configured with a BTP/GN/G5 lower stack.
ETSI
14 ETSI TR 103 099 V1.1.1 (2012-11)

Figure 6: Message sending sequence diagram

Figure 7: Message reception sequence diagram
ETSI
15 ETSI TR 103 099 V1.1.1 (2012-11)
7.1.2 Advanced details of implementation
Figure 8 presents the simplified class diagram of the test adapter. For better readability, auxiliary classes such as
factories are not represented. The complete class diagram, also featuring design pattern indications, can be found in
annex F.
Figure 8: Test Adapter class diagram
The main class of this implementation is the TestAdapter class. It implements the standardised interface
TriCommunicationSA and uses the ITERequired interface implemented by test tool providers. These interfaces
are part of the TRI API defined in ES 201 873-5 [i.1]. All other classes of this implementation are completely
TRI-agnostic. The main purpose of the TestAdapter class is to instantiate and manage the different ports.
ETSI
16 ETSI TR 103 099 V1.1.1 (2012-11)
There are two different kinds of ports:
• Protocol ports realising communication between TTCN-3 and SUT.
• Adapter ports which are used for test adapter configuration and upper tester communication.
Upon protocol port initialisation, lower layers are instanciated in cascade and chained as depicted in figure 9, base on
lower stack description. This picture also illustrate the usage of "Factory" design patterns for instanciating Layer and
Port objects. Each Layer is responsible for encapsulating/decapsulating packets and transmitting result to
lower/upper layer using send()/receive() methods.

Figure 9: Port initialisation sequence diagram
Currently the following layers have been implemented:
• GnLayer: basic functionalities of GeoNetworking layer, including beaconing.
• BtpLayer.
• EthernetLayer. Important: this class requires the usage of the external library JnetPcap for capturing and
injecting Ethernet frames.
ETSI
17 ETSI TR 103 099 V1.1.1 (2012-11)
• G5Layer.
The Management class, implementing IManagementTA and IManagementLayers interfaces is used for
handling the dynamic configuration of Layer objects. It is directly linked to the AdapterControlPort and implements the
AC primitives defined in the TTCN-3 test suites. "It is important to notice that this class is implemented using a
"Multiton or Multiple Singleton" design pattern: one single instance of this class can be instanciated per TTCN-3
component.
7.1.3 Extensibility of the test adapter
The test adapter can be extended in several ways. The first option is to add new protocol layers by adding new classes
inheriting from the Layer class. These new layers have then to be assigned a short name and registered in the
LayerFactory.
It is also possible to define new protocol ports. To do so, it is necessary to implement new classes inheriting from the
ProtocolPort class. These new ports have then to be assigned a short name and registered in the
ProtocolPortFactory.
Furthermore it is also possible to extend AC primitives. This requires to enrich IManagementLayers and
IManagementTA interfaces and to implement new functionalities in the Management class.
7.1.4 Adapter Control primitives
The following AC primitives are used to control the dynamic configuration of the various layers:
AC Primitive Description
startBeaconing
Requests Test Adapter to start sending periodic beacons for the current
component
stopBeaconing Requests Test Adapter to stop sending periodic beacons for the current
component
startEnqueueingBeacons
Requests Test Adapter to start enqueueing beacon messages on the current
component GN port
stopEnqueueingBeacons
Requests Test Adapter to stop enqueueing beacon messages on the current
component GN port
startMultipleBeaconing
Requests Test Adapter to start simulating neighbour presence by sending multiple
periodic beacons for the current component
stopMultipleBeaconing
Requests Test Adapter to stop simulating neighbour presence
getLongPositionVector
Gets the long position vector of a neighbour given its GN_Address

7.2 Platform Adapter
All TTCN-3 commercial tools provide generic Platform Adapter implementations for managing TTCN-3 timers. These
implementations are well tested and usually accurate enough for most usages. In the case of ITS protocols, e.g. DENM
re-broadcasting, GN beacon interval etc., the protocol timer value is in the order of magnitude of hundreds of
milliseconds. This order of magnitude can be handled well with the built in test system timers. As a consequence no
specific development is required for this component.
7.3 Upper Tester
The upper tester is used to interact with the upper interface of the implementation under test (IUT). It is typically
implemented as an upper tester module executing in the test adapter and as a small module executing on the SUT and
acts as an upper layer for the IUT. It is particularly useful for:
• Triggering events in SUT.
• Triggering messages.
• Checking that payload are transmitted correctly to upper layers.
ETSI
18 ETSI TR 103 099 V1.1.1 (2012-11)
The communication between the two upper tester module is performed in accordance with the upper tester message
format described in annex C.
As it interacts with potentially proprietary APIs, it is usually the responsibility of IUT vendors to implement module
located within SUT.
Figure 10: Upper Tester architecture
The ITS test platform is provided with three different test system side implementations. The different implementations
can be selected by setting item 7 of table E.1 to the following values:
• Yes: This upper tester module does not require any counterpart running on SUT. It will report all upper tester
calls to be successful without performing any action. This upper tester module is only useful for debugging
purposes.
• Operator: This upper tester module does not require any counterpart running on SUT. For each upper tester
call it will display action information in a dialog box so that the test operator can manipulate the SUT.
• Generic: This upper tester module implements the upper tester message based API described in annex C.
The source code of the test system side of the upper tester modules is provided in annex B as part of the test adapter
source code.
ETSI
19 ETSI TR 103 099 V1.1.1 (2012-11)
Annex A:
Codecs source code
The software modules are contained in archive AnnexA_Codec.zip which is included in archive
tr_103099v010101p0.zip which accompanies the present document.
ETSI
20 ETSI TR 103 099 V1.1.1 (2012-11)
Annex B:
Test Adapter source code
The software modules are contained in archive AnnexB_Adapter.zip which is included in archive
tr_103099v010101p0.zip which accompanies the present document.
ETSI
21 ETSI TR 103 099 V1.1.1 (2012-11)
Annex C:
Upper Tester message format
The messages defined in the present annex are exchanged between the Test System and Upper Tester using a UDP
connection.
All integer values are encoded in big-endian byte order (most significant byte first).
The message exchange always occurs as described below:
TestSystem UT
UpperTester primitive
==============================>

UtResult
<===============================

Message exchange is always initiated by TestSystem. Upper Tester always replies to UpperTester primitives by sending
an UpperTesterResult message indicating Success or Failure of the request.
Format of UtResult:
0    1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x24 Result
Name Length Value
MessageType 1 byte 0x24
Result 1 byte 0x00: Failure
0x01: Success
C.1 CAM Upper Tester Primitives
C.1.1 CamInitialize
This message is used to request initialization of CAM implementation.
0 1 2 3 4 5 6 7
MessageType = 0x2E
Name Length Value
MessageType 1 byte 0x2E
ETSI
22 ETSI TR 103 099 V1.1.1 (2012-11)
C.1.2 ChangeHeading
This message is used to change the heading of the ITS station. The new heading of the ITS station is reflect Direction
parameter.
0    1    2
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x70 Direction
Name Length Value
MessageType 1 byte 0x70
Direction 2 bytes Integer value from 0 to 28 799
0: North
7 200: East
14 400: South
21 600: West
C.1.3 ChangePosition
This message is used to change the position of the ITS station. The new position of the ITS station is at 'Distance'
meters of previous position.
0    1    2    3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x71 Distance
Name Length Value
MessageType 1 byte 0x71
Distance 4 bytes Position offset in meters

C.1.4 ChangeSpeed
This message is used to change the speed of the ITS station. The vehicle speed is increased by the value of
'SpeedVariation' field.
For instance, if the current speed of the ITS station is 10 m/s and received SpeedVariation is +300, then the new vehicle
speed will be 10 + 0,01 × 300 = 13 m/s.
0    1    2    3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x72 SpeedVariation

Name Length Value
MessageType 1 byte 0x72
SpeedVariation 4 bytes Speed variation in units of 0,01 m/s

ETSI
23 ETSI TR 103 099 V1.1.1 (2012-11)
C.1.5 SetCrashSignal
This message is used to set the crash signal of the ITS station.
0    1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x73 CrashStatus

Name Length Value
MessageType 1 byte 0x73
CrashStatus 1 byte 0x00: False
0x01: True
Other values are forbidden
C.1.6 SetDangerousGoodsStatus
This message is used to set the dangerous goods status of the ITS station.
0    1    2
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x74 DangerousGoodsStatus

Name Length Value
MessageType 1 byte 0x74
DangerousGoodsStatus 2 bytes Integer value from 0 to 8 191
0: no dangerous goods
C.1.7 SetLengthWidthPrecision
This message is used to set the length and width precision of the ITS station.
0    1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x75 Precision
Name Length Value
MessageType 1 byte 0x75
Precision 1 byte 0x00: Length/Width precision is not precisely determined
0x01: Length/Width precision is precisely determined
Other values are forbidden
C.1.8 SetDistanceToStopLine
This message is used to set the distance to next stop line of the ITS station.
0    1    2
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x76 Distance
Name Length Value
MessageType 1 byte 0x76
Distance 2 bytes Distance in units of 1 meter
From 0 to 65 535
ETSI
24 ETSI TR 103 099 V1.1.1 (2012-11)
C.1.9 SetTurnAdvice
This message is used to set the turn advice of the ITS station.
0    1    2    3
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x77 Direction Distance

Name Length Value
MessageType 1 byte 0x77
Direction 1 byte 0: uTurn
1: sharpRight
2: right
3: slightRight
4: straight
5: slightLeft
6: left
7: sharpLeft
Distance 2 bytes Distance in units of 1 meter
From 0 to 65 535
C.1.10 SetCurvature
This message is used to set the curvature of the ITS station.
0    1    2
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x78 Curvature
Name Length Value
MessageType 1 byte 0x78
Curvature 2 bytes Signed integer. Curvature change from -1 023 to 1 023

C.1.11 SetOccupancy
This message is used to set the ITS station occupancy.
0    1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x79 Occupancy
Name Length Value
MessageType 1 byte 0x79
Occupancy 1 byte Occupancy value from 0 to 255

ETSI
25 ETSI TR 103 099 V1.1.1 (2012-11)
C.1.12 SetDoorStatus
This message is used to set the door status of the ITS station.
0    1
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
MessageType = 0x7A Reserved D P M L

Name Length Value
MessageType 1 byte 0x7A
Reserved 4 bits Set to 0
D 1 bit 0: driver door closed
1: driver door opened
P 1 bit 0: passenger door closed
1: passenger door opened
M 1 bit 0: maintenance door closed
1: maintenance door opened
L 1 bit 0: luggage door closed
1: luggage door opened
C.1.13 SetLight
...