ISO 21111-11:2021

Road vehicles - In-vehicle Ethernet - Part 11: Application layer to session layer conformance test plans

This document specifies in-vehicle Ethernet application layer, presentation layer, and session layer conformance test plans (CTP) for electronic control units (ECUs). This document is a collection of all conformance test cases which are recommended to be considered for automotive use and should be referred by car manufacturers within their quality control processes. The document specifies the scalable Service-Oriented MiddlewarE over Internet Protocol (SOME/IP) and Dynamic Host Configuration Protocol (DHCP) version 4 conformance test cases.

Véhicules routiers — Ethernet embarqué — Partie 11: Plans de test de conformité des couches application et session

General Information

• Status: Published
• Publication Date: 01-Dec-2021
• ICS: 43.040.10 - Electrical and electronic equipment
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/WG 3 - In-vehicle networks
• Current Stage: 6060 - International Standard published
• Start Date: 02-Dec-2021
• Due Date: 23-Nov-2023
• Completion Date: 02-Dec-2021

Overview

ISO 21111-11:2021 - "Road vehicles - In-vehicle Ethernet - Part 11" - defines application, presentation, and session layer conformance test plans (CTP) for electronic control units (ECUs) used in automotive in-vehicle Ethernet networks. It is a consolidated collection of conformance test cases (CTCs) recommended for automotive quality control. The document specifically addresses conformance for SOME/IP (Service-Oriented MiddlewarE over IP) and DHCPv4 (Dynamic Host Configuration Protocol version 4).

Key topics and requirements

• Scope and purpose: Collection of conformance test cases for OSI layers 7–5 (application to session) targeted at ECUs and systems in vehicles.
• SOME/IP conformance: Test cases and server/ETS (Enhanced Testability Service) testing procedures covering service interfaces, methods, events, serialization, and service discovery.
• DHCPv4 client conformance: DHCP client test topologies, parameters, and client-specific CTCs (address allocation, lease-related behaviors).
• Test system setup: Definitions of test topologies, point-of-control-and-observation (PCO), and instructions for configuring test environments and related parameters.
• Test stubs and primitives: TCP/IP TestStub and SOME/IP TestStub methods, events, fields and result codes required by the Implementation Under Test (IUT).
• Parameters and constants: Standardized parameter files and timeouts (e.g., listen, processing, lease times) used across test cases for repeatability.
• Conformance framework: Aligned with ISO/IEC 9646-1 conformance testing methodology and the ISO 21111 series structure.

Practical applications and users

Who uses ISO 21111-11:

• Car manufacturers - integrate these CTPs into production and pre-production quality control to ensure ECUs meet expected protocol behavior.
• ECU and middleware suppliers - validate SOME/IP and DHCPv4 implementations against automotive test cases to ensure interoperability.
• Test labs and certification bodies - execute standardized CTCs for device conformance reports.
• System integrators and QA engineers - use the test plans to reproduce, debug, and document protocol-level issues in in-vehicle Ethernet systems.

How it is applied:

• Verifying SOME/IP service discovery, method invocation, and event handling in automotive middleware.
• Ensuring DHCPv4 client behavior (address acquisition and lease handling) is robust in vehicle networks.
• Integrating conformance checks into CI/validation pipelines and supplier acceptance testing.

Related standards

• ISO 21111 series (other parts covering physical, data link, transport layers)
• ISO 21111-1 (general information and definitions)
• ISO/IEC 9646-1 (conformance testing methodology)
• ISO/IEC/IEEE 8802-3 (Ethernet physical and MAC layer standards)

Keywords: ISO 21111-11, in-vehicle Ethernet, SOME/IP, DHCPv4, conformance test plans, ECU testing, automotive networking, CTC, CTP, test stubs.

Standards Content (Sample)

INTERNATIONAL ISO
STANDARD 21111-11
First edition
2021-12
Road vehicles — In-vehicle Ethernet —
Part 11:
Application layer to session layer
conformance test plans
Véhicules routiers — Ethernet embarqué —
Partie 11: Plans de test de conformité des couches application et
session
Reference number
© ISO 2021
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Symbols and abbreviated terms.1
4.1 Symbols . 1
4.2 Abbreviated terms . 2
5 Conventions . 3
6 CTP test system set-up and CTC structure . 3
6.1 General . 3
6.2 Test system set-up . 3
6.3 CTC definition . 4
6.4 Terminology used in CTCs . 5
6.5 IUT prerequisites – TCP/IP TestStub . 6
6.5.1 General . 6
6.5.2 TCP/IP TestStub methods (service primitives) . 6
6.5.3 Result codes . 6
6.6 IUT prerequisites – SOME/IP TestStub . 7
6.6.1 General . 7
6.6.2 SOME/IP TestStub methods . 7
6.6.3 SOME/IP TestStub events and fields. . 14
6.6.4 ETS service interface description . 16
7 Application, presentation, and session layers CTCs .20
7.1 AL – SOME/IP . 20
7.1.1 General .20
7.1.2 Referenced specification . 20
7.1.3 Test system topology – AL – SOME/IP, serialisation, and service discovery .20
7.1.4 Test system topology and related CTC configuration . 21
7.1.5 SOME/IP parameters used in CTCs . 21
7.1.6 SOME/IP server CTCs . 23
7.1.7 SOME/IP ETS CTCs .128
7.2 SL – Dynamic host configuration protocol version 4 (DHCPv4) client .213
7.2.1 General .213
7.2.2 Referenced specification .213
7.2.3 Test system topology – SL – DHCPv4 client .213
7.2.4 Test system topology with two interfaces in the IUT. 214
7.2.5 Test system topology and related CTC configuration .215
7.2.6 DHCPv4 parameters and constants used in CTCs .215
7.2.7 DHCPv4 client CTCs . 217
Bibliography . 255
iii
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and
expressions related to conformity assessment, as well as information about ISO's adherence to
the World Trade Organization (WTO) principles in the Technical Barriers to Trade (TBT), see
www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Data communication.
A list of all parts in the ISO 21111 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.
iv
Introduction
The ISO 21111 series includes in-vehicle Ethernet requirements and test plans that are disseminated in
other International Standards and complements them with additional test methods and requirements.
The resulting requirement and test plans are structured in different documents following the Open
Systems Interconnection (OSI) reference model and grouping the documents that depend on the
physical media and bit rate used.
In general, the Ethernet requirements are specified in ISO/IEC/IEEE 8802-3. The ISO 21111 series
provides supplemental specifications (e.g. wake-up, I/O functionality), which are required for in-vehicle
Ethernet applications. In road vehicles, Ethernet networks are used for different purposes requiring
different bit-rates. Currently, the ISO 21111 series specifies the 1-Gbit/s optical and 100-Mbit/s
electrical physical layer.
The ISO 21111 series contains requirement specifications and test methods related to the in-vehicle
Ethernet. This includes requirement specifications for physical layer entity (e.g. connectors, physical
layer implementations) providers, device (e.g. electronic control units, gateway units) suppliers, and
system (e.g. network systems) designers. Additionally, there are test methods specified for conformance
testing and for interoperability testing.
Safety (electrical safety, protection, fire, etc.) and electromagnetic compatibility (EMC) requirements
are out of the scope of the ISO 21111 series.
The structure of the specifications given in the ISO 21111 series complies with the Open Systems
[1] [4]
Interconnection (OSI) reference model specified in ISO/IEC 7498-1 and ISO/IEC 10731 .
ISO 21111-1 defines the terms which are used in this series of standards and provides an overview of
[2]
the standards for in-vehicle Ethernet including the complementary relations to ISO/IEC/IEEE 8802-3 ,
the document structure, type of physical entities, in-vehicle Ethernet specific functionalities and so on.
ISO 21111-2 specifies the interface between reconciliation sublayer and physical entity including
reduced gigabit media independent interface (RGMII), and the common physical entity wake-up and
synchronized link sleep functionalities, independent from physical media and bit rate.
ISO 21111-3 specifies supplemental requirements to a physical layer capable of transmitting
1-Gbit/s over plastic optical fibre compliant with ISO/IEC/IEEE 8802-3, with specific application to
communications inside road vehicles, and a test plan for physical entity conformance testing.
ISO 21111-4 specifies the optical components requirements and test methods for 1-Gbit/s optical
invehicle Ethernet.
ISO 21111-5 specifies, for 1-Gbit/s optical in-vehicle Ethernet, requirements on the physical layer at
system level, requirements on the interoperability test set-ups, the interoperability test plan that checks
the requirements for the physical layer at system level, requirements on the device-level physical layer
conformance test set-ups, and device-level physical layer conformance test plan that checks a set of
requirements for the OSI physical layer that are relevant for device vendors.
ISO 21111-6 specifies advanced features of an ISO/IEC/IEEE 8802-3 in-vehicle Ethernet physical layer
(often also called transceiver), e.g. for diagnostic purposes for in-vehicle Ethernet physical layers. It
specifies advanced physical layer features, wake-up and sleep features, physical layer test suite,
physical layer control requirements and conformance test plan, physical sublayers test suite and
physical sublayers requirements and conformance test plan.
ISO 21111-7 specifies the implementation for ISO/IEC/IEEE 8802-3, which defines the interface
implementation for automotive applications together with requirements on components used to realize
this Bus Interface Network (BIN). ISO 21111-7 also defines further testing and system requirements
for systems implemented according to the system specification. In addition, ISO 21111-7 defines
the channels for tests of transceivers with a test wiring harness that simulates various electrical
communication channels.
v
ISO 21111-8 specifies the transmission media, the channel performance and the tests for
ISO/IEC/IEEE 8802-3 in-vehicle Ethernet.
ISO 21111-9 specifies the data link layer requirements and conformance test plan. It specifies the
requirements and test plan for devices and systems with bridge functionality.
ISO 21111-10 specifies the transport to network layer requirements and conformance test plans. It
specifies the requirements and conformance test plan for devices and systems that include functionality
related with OSI layers from 4 and 3.
This document specifies the application to session layer requirements and conformance test plans. It
specifies the requirements and conformance test plan for devices and systems that include functionality
related with OSI layers from 7 to 5.
Figure 1 shows the parts of the ISO 21111 series and the document structure.
Figure 1 — In-vehicle Ethernet documents reference according to OSI model
vi
INTERNATIONAL STANDARD ISO 21111-11:2021(E)
Road vehicles — In-vehicle Ethernet —
Part 11:
Application layer to session layer conformance test plans
1 Scope
This document specifies in-vehicle Ethernet application layer, presentation layer, and session layer
conformance test plans (CTP) for electronic control units (ECUs). This document is a collection of all
conformance test cases which are recommended to be considered for automotive use and should be
referred by car manufacturers within their quality control processes.
The document specifies the scalable Service-Oriented MiddlewarE over Internet Protocol (SOME/IP)
and Dynamic Host Configuration Protocol (DHCP) version 4 conformance test cases.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements of this document. For dated references, only the edition cited applies. For
undated references, the latest edition of the referenced document (including any amendments) applies.
ISO/IEC 9646-1, Information technology — Open Systems Interconnection — Conformance testing
methodology and framework — Part 1: General concepts
ISO 21111-1, Road vehicles — In-vehicle Ethernet — Part 1: General information and definitions
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 21111-1, ISO/IEC 9646-1 and
the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
PORT1
port number of the upper tester used for UDP communication
3.2
service interface description
description of the implemented SOME/IP services of a IUT including, e.g. all methods, events, and
method parameters
4 Symbols and abbreviated terms
4.1 Symbols
--- empty table cell or feature undefined
V voltage of the battery
BAT
X feature in table cell selected
t
Param-Tolerance-Time
tolerance time taken from parameter file
t
Client-Listen-Time listen time used by ANVL taken from parameter file
t
Param-Process-Time amount of time the test system Host-1 waits for the IUT to process the PDU
t
Param-Lease-Time
value of DHCP IP address lease time in seconds which is offered to the IUT
t
Duration-Of-Lease
lease time in seconds
t
High-Lease-Time lease time in seconds set to high value
4.2 Abbreviated terms
ACK acknowlege
ADDR address
AL application layer
ANVL Automated Network Validation Library
ARP address resolution protocol
BOM byte order mark
CTC conformance test case
CTP conformance test plan
DHCP Dynamic Host Configuration Protocol
EMC electromagnetic compatibility
ETS enhanced testability service
FIN finish
ICMP internet control message protocol
IUT implementation under test
MSL maximum segment lifetime
MSS maximum segment size
PCO point of control and observation
PHY physical layer
PRS protocol requirement specification
PSH push
QOS qualitiy of service and audio/video bridging
RPC remote procedure call
SL session layer
SOME/IP Service-Oriented MiddlewarE over Internet Protocol
SUT system under test
SYN synchonise
TCP transmission control protocol
TIME time synchronisation
TTL Time-To-Live
UDP user datagram protocol
5 Conventions
[4]
This document is based on OSI service conventions as specified in ISO/IEC 10731 .
6 CTP test system set-up and CTC structure
6.1 General
This document specifies a CTP according to the requirements as specified in the ISO/IEC 9646 series. A
CTP does not provide qualification of test results but expected responses of the IUT. A CTP is used by a
test house to develop a conformance test plan specific for the test system used in their lab environment.
The CTCs specified in this document are organized in such a manner as to simplify the identification
of information related to a test and to facilitate in the actual testing process. CTCs are organized into
groups, primarily in order to reduce set-up time in the lab environment. The different groups typically
also tend to focus on specific aspects of device functionality.
A CTC reference name, for example, "CTC_SOMEIP_ETS_07 – EchoBitfields" is used to organize the CTC
name, where the following is included:
— "CTC" which indicates that this is a conformance test case;
— name/subject of CTC;
— supplemental name, for example, ETS, which is enhanced test system;
— CTC number;
— after the hyphen a descriptive name of the CTC follows.
The CTC definitions themselves are intended to provide a high-level description of the purpose,
references, prerequisite, steps/procedures, expected responses, remarks, and methodologies pertinent
to each test (see 6.3).
6.2 Test system set-up
The test system topology follows ISO/IEC 9646-1:1994 and consists of a test set-up which consists
of a test system and a system under test (SUT) connected via the physical medium. The test system
implements an UT and an LT. The UT uses the test control protocol (Figure 2, key 2) to control the LT.
The LT supports the functionality required to test the OSI layer (Figure 2, key 5, key 6, and key 7) of the
IUT. The test system uses IUT-specific set-up parameters (Figure 2, key 1) for testing the communication
with the IUT.
The control and measurement functionality is provided by direct logical access to the service interface
(dashed line) (Figure 2, key 3) and the associated parameters of the OSI layer. The UT in the IUT
(Figure 2, key 4) supports an equivalent part of the abstract service interface (ASPs, PCO) (dashed line)
(Figure 2, key 3) and the associated parameters to control and measure the state(s) of the IUT.
The UT conformance test controller in the test system manipulates the service primitive interface
parameters in the IUT via the ASPs (ETSs) and PCO of the OSI layers to fulfil the purpose of each CTC.
Key
1 set-up parameters (node's electronic data sheet)
2 test control protocol
3 PCO and ASPs based on ETS
4 UT application with ETS interface
5 OSI layer 7 to 5 protocol
6 OSI layer 4 to 3 protocol
7 OSI layer 2 protocol
Figure 2 — Test system set-up
6.3 CTC definition
CTCs are independent of one another. Each CTC checks the behaviour of the IUT for a particular purpose
of this document. CTCs, which require variations of individual parameters, shall be repeated for each
value of the parameter. Each CTC is specified according to a common CTC structure as shown in Table 1.
Table 1 — CTC structure
Item Content
CTC # – Title CTC_x.y.z-a – CTC structure
Table 1 (continued)
Item Content
Purpose The purpose is a brief statement outlining what the test attempts are to achieve. The test is
written at the functional level. It is recommended to begin the description of purpose with
"This CTC verifies …".
Reference The purpose of reference is to specify source material external to the test suite, including any
other references that can be helpful in understanding the test methodology and/or test results.
External sources are always referenced by number when mentioned in the test description.
Any other references not specified by number are stated with respect to the test suite docu-
ment itself.
EXAMPLE AUTOSAR SOME/IP Example of a Serialization Protocol V1.1.0 R4.1 rev 3: PRS_
SOMEIP_00042, PRS_SOMEIP_00099, …
Prerequisite The purpose of prerequisites is to specify the test hardware and/or software needed to per-
form the CTC. This is generally expressed in terms of minimum requirements. In some cases,
specific equipment manufacturer/model information may be provided.
EXAMPLE The IUT is running and offering the enhanced testability service.
Set-up The purpose of set-up is to describe the initial configuration of the test environment. Small
changes in the configuration should not be included here and are generally covered in the test
procedure below.
EXAMPLE The test system set-up shall be in accordance with Figure 2.
Step The test procedure includes the test description, which contains the systematic instructions
for carrying out the test. It provides a cookbook approach to testing and may be interspersed
with observable results. Each test step shall have a numeric number in ascending order.
1. Configure the IUT as master or as slave.
2. Establish a valid link with the IUT.
3. Monitor the transmissions from the IUT and cause the management to request a PMA
reset while simultaneously ceasing transmissions from the test system.
Iteration The purpose of test iterations is to include test procedure definitions, which are repeated more
than once.
a) REPEAT step 2 to step 3 with the IUT configured as master, 1 time.
b) REPEAT step 2 to step 3 with the IUT configured as slave, 1 time.
Expected The purpose of expected response is to describe the expected results to be examined by the
response test system Host-1 in order to verify that the IUT is operating. When multiple values for an
observable are possible, this description provides a short discussion on how to interpret them.
The determination of a pass or fail outcome for a particular test is generally based on the suc-
cessful (or unsuccessful) detection of a specific observable.
After iteration a): The IUT stops transmitting with tx_mode = SEND_N and starts trans-
mitting with tx_mode = SEND_I for 1 iteration a). The IUT sets link_status = FAIL.
After iteration b): The IUT stops transmitting for 1 iteration b). The IUT sets link_status
= FAIL.
Remark The purpose of remarks is to describe known issues with the test procedure, which can affect
test results in certain situations. It can also refer the reader to test suite annexes and/or white
papers that can provide more detail regarding these issues.
6.4 Terminology used in CTCs
Table 2 specifies the terminology used in CTCs.
Table 2 — Terminology used in CTCs
Name Content
Upper tester (UT) Entity which is responsible for controlling the LT via the test control protocol and the
IUT UT enhanced testability services (ETS) via the abstract service primitives (ASPs).
Lower tester (LT) Entity which is responsible for validating the implementation under test (IUT).
IUT_CONFIGURE This entry causes the IUT to configure/execute various commands for clearing cache,
adding static address, send echo request, etc.
IUT Implementation under test in the SUT.
CLEANUP This is a command, which causes the IUT to remove the static entry from its ARP
cache.
6.5 IUT prerequisites – TCP/IP TestStub
6.5.1 General
The TCP/IP TestStub defines interfaces required to test TCP/IP communication stack functionality. This
is an enabler for generic test tools and conformance test cases (CTCs).
The protocol parts covered by the TCP/IP TestStub include:
— UDP and TCP – socket connection establishment and termination;
— UDP and TCP – message transmission and reception.
The TCP/IP TestStub is specified in Reference [12] (AUTOSAR). This document references a subset of
the AUTOSAR specification.
6.5.2 TCP/IP TestStub methods (service primitives)
Table 3 references AUTOSAR Testability Protocol and Service Primitives, TC Release 1.2.0, '6.10 Service
[12]
Primitives' and indicates the service primitives which are applicable.
Table 3 — TCP/IP TestStub methods (service primitives)
Method name (service primitive) Identifier General UDP TCP
GET_VERSION 1 optional --- ---
START_TEST 2 mandatory --- ---
END_TEST 3 mandatory --- ---
CLOSE_SOCKET 0 --- mandatory mandatory
CREATE_AND_BIND 1 --- mandatory mandatory
SEND_DATA 2 --- mandatory mandatory
RECEIVE_AND_FORWARD 3 --- mandatory mandatory
LISTEN_AND_ACCEPT 4 --- --- mandatory
CONNECT 5 --- --- mandatory
SHUTDOWN 7 --- --- optional
6.5.3 Result codes
Due to different stack implementations there is no generic way to retrieve specific result codes. Only
generic result codes are accepted. The referenced TestStub methods are changed as follows.
The TestStub methods in Table 4 have no specific result codes, only generic result codes (E_OK / E_
NOK) are allowed.
Table 4 — Result codes
Chapter in Reference [12]” TestStub method (service primitive)
6.10.4 CLOSE_SOCKET
6.10.5 CREATE_AND_BIND
6.10.6 SEND_DATA
6.10.7 RECEIVE_AND_FORWARD
6.10.8 LISTEN_AND_ACCEPT
6.10.9 CONNECT
6.11.1 SHUTDOWN
6.6 IUT prerequisites – SOME/IP TestStub
6.6.1 General
[12]
The SOME/IP TestStub enhanced testability service (ETS) defines interfaces required to test SOME/
IP functionality. This is an enabler for generic test tools and conformance test cases (CTCs).
The protocol parts covered by the SOME/IP TestStub includes:
— SOME/IP Stack – Service discovery;
— SOME/IP Stack – Serialisation;
— SOME/IP Stack – Remote procedure call;
— SOME/IP Stack – Publish/Subscribe.
6.6.2 SOME/IP TestStub methods
6.6.2.1 Overview about methods
Table 5 specifies the list of SOME/IP TestStub methods.
Table 5 — List of SOME/IP TestStub methods
SOME/IP TestStub method name Method-Id Fire and forget
checkByteOrder() 1F ---
clientServiceActivate() 2F X
clientServiceDeactivate() 30 X
clientServiceSubscribe-Event-Group() 32 X
echoCommonDatatypes() 23 ---
echoENUM() 17 ---
echoFLOAT64() 12 ---
echoINT8() 0E ---
echoStaticUINT8Array() 36 ---
echoUINT8() 08 ---
echoUINT8Array() 09 ---
echoUINT8Array8BitLength() 3E ---
Key
--- empty cell/undefined
X method supported
Table 5 (continued)
SOME/IP TestStub method name Method-Id Fire and forget
echoUINT8Array16BitLength() 3F ---
echoUINT8Array2Dim() 35 ---
echoUINT8ArrayMinSize() 37 ---
echoUINT8E2E() 0B ---
echoUINT8RELIABLE() 0A ---
echoUNION() 19 ---
echoUTF16DYNAMIC() 16 ---
echoUTF16FIXED() 14 ---
echoUTF8DYNAMIC() 15 ---
echoUTF8FIXED() 13 ---
resetInterface() 01 X
suspendInterface() 02 X
triggerEventUINT8() 03 X
triggerEventUINT8Array() 04 X
triggerEventUINT8E2E() 06 X
triggerEventUINT8Reliable() 05 X
triggerEventUINT8Multicast() 3A X
clientServiceGetLastValueOfEventTCP() 3B ---
clientServiceGetLastValueOfEventUDPUnicast() 3C ---
clientServiceGetLastValueOfEventUDPMulticast() 3D ---
echoBitfields() 41 ---
Key
--- empty cell/undefined
X method supported
6.6.2.2 SOME/IP service discovery (SOME/IP-SD) control methods
6.6.2.2.1 SOME/IP-SD – State machine of testing methods
Several methods of the SOME/IP TestStub are used to test SOME/IP-SD. Figure 3 shows the SOME/IP-
SD– State machine of testing methods.
Figure 3 — SOME/IP-SD– State machine of testing methods
6.6.2.2.2 SOME/IP-SD – Method resetInterface()
Table 6 defines the method resetInterface().
Table 6 — Method resetInterface()
Method name Method content Method-Id
resetInterface() This method resets the interface to default values. 01
Figure 4 shows the method resetInterface().
Figure 4 — Method resetInterface()
6.6.2.2.3 SOME/IP-SD – Method suspendInterface()
Table 7 defines the method suspendInterface().
Table 7 — Method suspendInterface()
Method name Method content Method-Id
suspendInterface() This method allows to suspend the SOME/IP TestStub; thus, forcing the 02
IUT to stop offering the service and start to reoffer the service after a
given time.
The input parameters include:
— delay – wait time in seconds before the service shall be stopped;
— duration – wait time in seconds during between stopping the service
and reoffering it again.
Figure 5 shows the method suspendInterface().
Figure 5 — Method suspendInterface()
6.6.2.3 SOME/IP-SD – Client interaction methods
In order to test the correct function as a client, the SOME/IP TestStub shall support the methods as
defined in Table 8.
Table 8 — Testing client interaction methods
Method name Method content Method-Id
clientServiceActivate() The commands clientServiceActivate() and 2F
clientServiceDeactivate() shall instruct the
IUT if it shall start its SOME/IP client; thus,
they control when the system shall start find-
clientServiceDeactivate() 30
ing the ETS with the configurable instance
identifier (e.g. 00F4 ).
The clientServiceSubscribe-Event-Group shall
clientServiceSubscribe-Event-Group() trigger the subscription behaviour in service 32
discovery.
clientServiceGetLastValueOfEventTCP() These methods return the last received value 3B
of TestEventUINT8Reliable, TestEventUINT8,
clientServiceGetLastValueOfEventUDPUnicast() 3C
and TestEventUINT8Multicast respectively.
clientServiceGetLastValueOfEventUDPMulti-
cast() 3D
6.6.2.4 SOME/IP serialisation verification methods
6.6.2.4.1 Check byte order method
Table 9 defines the method checkByteOrder().
Table 9 — Method checkByteOrder()
Method name Method content Method-Id
checkByteOrder() This method is used to test the correct handling of the byte 1F
order.
The input parameters include a uint8 and a big endian uint16,
which shall be added and returned as output parameter in
UINT32 big endian.
Figure 6 shows the method checkByteOrder().
Figure 6 — Method checkByteOrder()
6.6.2.4.2 Echo data types methods
Table 10 defines the methods for echoing data types.
Table 10 — Method echoing data types
Method name Method content Method-Id
echoCommonDatatypes()() This method can be used to test the common data types. The 23
input parameters shall be echoed back in reversed order. The
service interface description (6.6.4) describes this in detail.
echoENUM() The echo-routines echo back the parameters, partly in anoth- 17
er order as the parameters coming in. The service interface
echoFLOAT64() 12
description (6.6.4) describes this in detail.
echoINT8() 0E
echoStaticUINT8Array() 36
echoUINT8() 08
echoUINT8Array() 09
echoUINT8Array8 BitLength() 3E
echoUINT8Array16 BitLength() 3F
echoUINT8Array2Dim() 35
echoUINT8ArrayMinSize() 37
echoUINT8E2E() 0B
echoUINT8RELIABLE() This method uses TCP as OSI layer 4 transport protocol. 0A
Table 10 (continued)
Method name Method content Method-Id
echoUNION() The echo-routines echo back the parameters, partly in anoth- 19
er order as the parameters coming in. The service interface
echoUTF16DYNAMIC() 16
description (6.6.4) describes this in detail.
echoUTF16FIXED() 14
echoUTF8DYNAMIC() 15
echoUTF8FIXED() 13
echoBitfields() 41
Three examples are shown in the diagram below.
Figure 7 shows the methods echoUINT8(), echoUINT8reliable(), echoUINT8E2E().
Figure 7 — Methods echoUINT8(), echoUINT8reliable(), echoUINT8E2E()
6.6.3 SOME/IP TestStub events and fields.
6.6.3.1 Event and field types
Table 11 specifies the SOME/IP TestStub events and fields.
Table 11 — List of SOME/IP TestStub events and fields
Type SOME/IP TestStub event/field name Event-Id/Field-Id Event-Group-Id
0002 0005 0006
16 16 16
Event TestEventUINT8 8001 X X ---
Event TestEventUINT8Array 8002 X X ---
Event TestEventUINT8E2E 8004 X X ---
Event TestEventUINT8Reliable 8003 X --- ---
Event TestEventUINT8Multicast 800B X X X
Field InterfaceVersion 8005 (notify) X X ---
0025 (getter) X X ---
Field TestFieldUINT8 8006 (notify) X X ---
0026 (getter) X X ---
0027 (setter) X X ---
Field TestFieldUINT8Array 8007 (notify) X X ---
0028 (getter) X X ---
0029 (setter) X X ---
Field TestFieldUINT8Reliable 8008 (notify) X --- ---
002A (getter) X --- ---
002B (setter) X --- ---
Key
--- empty cell/undefined
X feature in table cell selected
6.6.3.2 Event trigger methods
Table 12 defines the event trigger methods.
Table 12 — Event trigger methods
Method name Method content Method-Id
triggerEventUINT8() After the method triggerEventUINT8() (delay, duration, de- 03
bounceTime) was invoked, the ETS waits t seconds and
delay
triggers a periodical event TestEventUINT8(UINT8Value) with
the passed duration and debounce time. The service interface
description (6.6.4) describes this in detail. The transport proto-
col of the event message is UDP.
triggerEventUINT8Array() After the method triggerEventUINT8Array()(delay, duration, 04
debounceTime) was invoked, the ETS waits t seconds and
delay
triggers a periodical event TestEventUINT8Array(UINT8Array-
Value) with the passed duration and debounce time. The service
interface description (6.6.4) describes this in detail. The trans-
port protocol of the event message is UDP.
Table 12 (continued)
Method name Method content Method-Id
triggerEventUINT8E2E() After the method triggerEventUINT8E2E()(delay, duration, 06
debounceTime) was invoked, the ETS waits t seconds and
delay
triggers a periodical event TestEventUINT8E2E(UINT8E2EVal-
ue) with the passed duration and debounce time. The service in-
terface description (6.6.4) describes this in detail. The transport
protocol of the event message is UDP.
triggerEventUINT8Reliable() After the method triggerEventUINT8Reliable()(delay, duration, 05
debounceTime) was invoked, the ETS waits t seconds and
delay
triggers a periodical event TestEventUINT8Reliable(UINT8Val-
ue) with the passed duration and debounce time. The service in-
terface description (6.6.4) describes this in detail. The transport
protocol of the event message is TCP.
triggerEventUINT8Multicast() After the method triggerEventUINT8Multicast()(delay, duration, 3A
debounceTime) was invoked, the ETS waits t seconds and
delay
triggers a periodical event TestEventUINT8Multicast(UINT8Val-
ue) with the passed duration and debounce time. The event is
sent to a multicast address. The service interface description
(6.6.4) describes this in detail. The transport protocol of the
event message is UDP.
6.6.3.3 Field methods (getter, setter, notifier)
Table 13 specifies the field methods.
Table 13 — Field methods
Field Method name Parameter Data type Meth-
od-Id
InterfaceVersion testFieldUINT8_Getter --- --- 25
testFieldUINT8_Notifier testFieldUINT8_Notifier_Arg1 Uint8 8005
(majorVersion)
Uint32
testFieldUINT8_Notifier_Arg2
(minorVersion)
TestFieldUINT8 testFieldUINT8_Getter --- --- 26
testFieldUINT8_Setter testFieldUINT8_Setter_Arg1 Uint8 27
testFieldUINT8_Notifier testFieldUINT8_Notifier_Arg1 Uint8 8006
TestFieldUINT8Array testFieldUINT8Array_Getter --- --- 28
testFieldUINT8Array_Setter testFieldUINT8Array_Set- Uint8 29
ter_Arg1 (array len)
Array of
testFieldUINT8Array_Set- Uint8 ele-
ter_Arg2 (array) ments
testFieldUINT8Array_Notifier testFieldUINT8Array_Notifi- Uint8 8007
er_Arg1 (array len)
Array of
testFieldUINT8Array_Notifi- Uint8 ele-
er_Arg2 (array) ments
TestFieldUINT8Reli- testFieldUINT8Reliable_Getter --- --- 2A
able
testFieldUINT8Reliable_Setter testFieldUINT8Reliable_Set- Uint8 2B
ter_Arg1
testFieldUINT8Reliable_Notifier testFieldUINT8Reliable_Noti- Uint8 8008
fier_Arg1
6.6.4 ETS service interface description
The SOME/IP TestStub service interface description reflects the requirements to be supported by the
IUT. Therefore, the manufacturer of the IUT provides the service interface description in case an IUT-
specific service interface description is not available. Table 14 specifies the default SOME/IP TestStub
interface description to be used.
Table 14 — Default SOME/IP TestStub interface description
Method name Default parameter Data type Comment
checkByteOrder_Req checkByteOrder_ReqArg1 Uint8 ResArg1 = sum of ReqA-
rg1+ ReqArg2
checkByteOrder_ReqArg2 Uint16
checkByteOrder_Res checkByteOrder_ResArg1 Uint32
clientServiceActivate_Req clientServiceActivate_ReqArg1 (delay) Uint8 Message Type is REQ_
NO_RETURN
clientServiceDeactivate_Req clientServiceDeactivate_ReqArg1 (delay) Uint8 Message Type is REQ_
NO_RETURN
clientServiceSub- clientServiceSubscribe-Event-Group_Req Uint32 Message Type is REQ_
scribe-Event-Group_Req Arg1 (delay) NO_RETURN
Uint32
clientServiceSubscribe-Event-Group_Req
Arg2 (duration)
echoCommonDatatypes_Req echoCommonDatatypes_ReqArg1 Boolean echoCommonDa-
tatypes_ReqArg1
echoCommonDatatypes_ReqArg2 uint8
= echoCommonDa-
echoCommonDatatypes_ReqArg3 uint16 tatypes_ResArg9
echoCommonDatatypes_ReqArg4 uint32 echoCommonDa-
tatypes_ReqArg2
echoCommonDatatypes_ReqArg5 int8
= echoCommonDa-
echoCommonDatatypes_ReqArg6 int16 tatypes_ResArg8
etc.
echoCommonDatatypes_ReqArg7 int32
echoCommonDatatypes_ReqArg8 float32
echoCommonDatatypes_ReqArg9 float64
echoCommonDatatypes_Res echoCommonDatatypes_ResArg1 float64
echoCommonDatatypes_ResArg2 float32
echoCommonDatatypes_ResArg3 int32
echoCommonDatatypes_ResArg4 int16
echoCommonDatatypes_ResArg5 int8
echoCommonDatatypes_ResArg6 uint32
echoCommonDatatypes_ResArg7 uint16
echoCommonDatatypes_ResArg8 uint8
echoCommonDatatypes_ResArg9 Boolean
echoENUM_Req echoENUM_ReqArg1 Uint8 echoENUM_ReqArg1 =
echoENUM_ResArg1
echoENUM_Res echoENUM_ResArg1 Uint8
echoFLOAT64_Req echoFLOAT64_ReqArg1 Float64 echoFLOAT64_ReqArg1
= echoFLOAT64_Re-
echoFLOAT64_Res echoFLOAT64_ResArg1 Float64
sArg1
echoINT8_Req echoINT8_ReqArg1 Sint8 echoINT8_ReqArg1 =
echoINT8_ResArg1
echoINT8_Res echoINT8_Res_Arg1 Sint8
Table 14 (continued)
Method name Default parameter Data type Comment
echoStaticUINT8Array_Req echoStaticUINT8Array_ReqArg1 Array Static array of 5 Uint8
elements (without array
echoStaticUINT8Array_Res echoStaticUINT8Array_ResArg1 Array
lenght field)
echoStaticUINT8Array_
ReqArg1 = echoStaticU-
INT8Array_ResArg1
echoUINT8_Req echoUINT8_ReqArg1 Uint8 echoUINT8_Req =
echoUINT8_Res
echoUINT8_Res echoUINT8_ResArg1 Uint8
echoUINT8Array_Req echoUINT8Array_ReqArg1 (array len) Uint32 Dynamic array of n
Uint8 elements
echoUINT8Array_ReqArg2 (array) Array
echoUINT8Array_ReqA-
echoUINT8Array_Res echoUINT8Array_ResArg1 (array len) Uint32
rg1 = echoUINT8Ar-
echoUINT8Array_ResArg2 (array) Array
ray_ResArg1, echoUIN-
T8Array_ReqArg2 =
echoUINT8Array_Re-
sArg2
echoUINT8Array8BitLe- echoUINT8Array8BitLength_ReqArg1 Uint8 Dynamic array of n
ngth_Req (array len) Uint8 elements
Array
echoUINT8Array8BitLength_ReqArg2 echoUINT8Array-
(array) 8BitLength_ReqArg1
= echoUINT8Array-
echoUINT8Array8BitLe- echoUINT8Array8BitLength_ResArg1 Uint8
8BitLength_ResArg1,
ngth_Res (array len)
Array
echoUINT8Array8Bi-
echoUINT8Array8BitLength_ResArg2
tLength_ReqArg2 =
(array)
echoUINT8Array8Bi-
tLength_ResArg2
echoUINT8Array16BitLe- echoUINT8Array16BitLength_ReqArg1 Uint16 Dynamic array of n
ngth_Req (array len) Uint8 elements
Array
echoUINT8Array16BitLength_ReqArg2 echoUINT8Array16Bi-
(array) tLength_ReqArg1 =
echoUINT8Array16Bi-
echoUINT8Array16BitLe- echoUINT8Array16BitLength_ResArg1 Uint16
tLength_ResArg1,
ngth_Res (array len)
Array
echoUINT8Array16Bi-
echoUINT8Array16BitLength_ResArg2
tLength_ReqArg2 =
(array)
echoUINT8Array16Bi-
tLength_ResArg2
echoUINT8Array2Dim_Req echoUINT8Array2Dim_ReqArg1 (array Uint32 Uint8array:
len)
Array of Len (Uint32)
echoUINT8Array2Dim_ReqArg2 (array arrays
Array of n Uint8 ele-
of arrays)
ments
echoUINT8Array2Dim_Res echoUINT8Array2Dim_ResArg1 (array Uint32
echoUINT8Array2Dim_
len)
Array
...