ISO 15118-9:2022
(Main)Road vehicles — Vehicle to grid communication interface — Part 9: Physical and data link layer conformance test for wireless communication
Road vehicles — Vehicle to grid communication interface — Part 9: Physical and data link layer conformance test for wireless communication
This document specifies conformance tests in the form of an abstract test suite (ATS) for a system under test (SUT) implementing an electric-vehicle or supply-equipment communication controller (EVCC or SECC) with support for WLAN-based high-level communication (HLC) according to ISO 15118‑8 and against the background of ISO 15118-1. These conformance tests specify the testing of capabilities and behaviours of an SUT, as well as checking what is observed against the conformance requirements specified in ISO 15118‑8 and against what the implementer states the SUT implementation's capabilities are. The capability tests within the ATS check that the observable capabilities of the SUT are in accordance with the static conformance requirements defined in ISO 15118‑8. The behaviour tests of the ATS examine an implementation as thoroughly as practical over the full range of dynamic conformance requirements defined in ISO 15118‑8 and within the capabilities of the SUT (see NOTE below). A test architecture is described in correspondence to the ATS. The abstract test cases in this document are described leveraging this test architecture and are specified in descriptive tabular format for the ISO/OSI physical and data link layers (layers 1 and 2). In terms of coverage, this document only covers normative sections and requirements in ISO 15118‑8. This document can additionally refer to specific tests for requirements on referenced standards (e.g. IEEE, or industry consortia standards, like WiFi Alliance) as long as they are relevant in terms of conformance for implementations according to ISO 15118‑8. However, it is explicitly not intended to widen the scope of this conformance specification to such external standards, if it is not technically necessary for the purpose of conformance testing for ISO 15118‑8. Furthermore, the conformance tests specified in this document do not include the assessment of performance nor robustness or reliability of an implementation. They cannot provide judgments on the physical realization of abstract service primitives, how a system is implemented, how it provides any requested service, nor the environment of the protocol implementation. Furthermore, the abstract test cases defined in this document only consider the communication protocol and the system's behaviour defined ISO 15118‑8. The power flow between the EVSE and the EV is not considered. NOTE Practical limitations make it impossible to define an exhaustive test suite, and economic considerations can restrict testing even further. Hence, the purpose of this document is to increase the probability that different implementations are able to interwork. This is achieved by verifying them by means of a protocol test suite, thereby increasing the confidence that each implementation conforms to the protocol specification. However, the specified protocol test suite cannot guarantee conformance to the specification since it detects errors rather than their absence. Thus, conformance to a test suite alone cannot guarantee interworking. Instead, it gives confidence that an implementation has the required capabilities and that its behaviour conforms consistently in representative instances of communication.
Véhicules routiers — Interface de communication entre véhicule et réseau électrique — Partie 9: Essai de conformité relatif à la couche physique et à la couche liaison de données pour la communication sans-fil
Le présent document spécifie les tests de conformité sous la forme d'une suite de tests abstraite (ATS) pour un système sous test (SUT) implémentant un contrôleur de communication de véhicule électrique (CCVE) ou d'infrastructure de recharge (CCIR) qui prend en charge la communication de haut niveau (CHN) basée sur un réseau local sans fil (WLAN) conformément à l'ISO 15118-8 et sur la base de l'ISO 15118-1. Ces tests de conformité spécifient les tests de capacités et de comportements d'un SUT, puis vérifient les résultats obtenus par rapport aux exigences de conformité définies dans l'ISO 15118-8 et aux capacités d'implémentation du SUT définies par l'implémenteur. Les tests de capacités définis dans la suite de tests abstraite (ATS) vérifient que les capacités observables sur le SUT respectent les conditions de conformité statique définies dans l'ISO 15118-8. Les tests de comportement de la suite de tests abstraite (ATS) examinent en détail une implémentation donnée dans l'ensemble des conditions de conformité dynamique définies dans l'ISO 15118-8, ainsi que dans les limites des capacités du SUT (voir NOTE ci-après). Une architecture de test est décrite sur la base de la suite de tests abstraite (ATS). Les tests élémentaires abstraits définis dans le présent document sont décrits sur la base de cette architecture de test et sont spécifiés sous la forme de tableaux descriptifs pour la couche ISO/OSI physique (couche 1) et la couche ISO/OSI liaison de données (couche 2). Le présent document ne couvre que les sections normatives et les exigences de l'ISO 15118-8. Le présent document peut également renvoyer vers des tests spécifiques pour les exigences relatives aux normes citées (par exemple, les normes de l'IEEE ou des normes établies par des consortiums industriels, comme la Wi-Fi Alliance) sous réserve que ces tests présentent un intérêt pour la conformité des implémentations conformément à l'ISO 15118-8. Toutefois, le présent document n'a pas pour objet d'élargir le domaine d'application de cette spécification de conformité à de telles normes externes, si cela n'est pas techniquement nécessaire pour les tests de conformité conformément à l'ISO 15118-8. En outre, les tests de conformité spécifiés dans le présent document n'incluent pas l'évaluation des performances, de la robustesse ou de la fiabilité d'une implémentation. Ces tests ne peuvent pas évaluer l'implémentation physique des primitives de services abstraites, la manière dont est implémenté un système, la manière dont celui-ci fournit un service demandé, ni l'environnement d'implémentation du protocole. Par ailleurs, les tests élémentaires abstraits définis dans le présent document couvrent uniquement le protocole de communication et le comportement du système définis par l'ISO 15118-8. Le flux de puissance transitant entre l'IRVE et le VE n'est pas pris en compte. NOTE En raison de limites techniques, il n'est pas possible de définir une suite de tests exhaustive, à cela s'ajoutent des motifs d'ordre budgétaire qui peuvent également restreindre les tests. Le présent document a donc pour but d'augmenter la probabilité que différentes implémentations puissent fonctionner de manière interopérable. Pour vérifier ces implémentations, une suite de tests de protocole est ainsi spécifiée afin de garantir la conformité de chaque implémentation à la spécification du protocole. Cependant, la suite de tests de protocole spécifiée ne peut pas garantir la conformité d'une implémentation à la spécification, car ces tests visent davantage à détecter les erreurs potentielles que leur absence. La conformité à une seule suite de tests ne permet donc pas de garantir l'interopérabilité des implémentations. Néanmoins, ces tests permettent de s'assurer qu'une implémentation possède les capacités requises et que son comportement est conforme et cohérent dans toutes les instances de communication représentatives des conditions réelles.
General Information
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 15118-9
First edition
2022-11
Road vehicles — Vehicle to grid
communication interface —
Part 9:
Physical and data link layer
conformance test for wireless
communication
Véhicules routiers — Interface de communication entre véhicule et
réseau électrique —
Partie 9: Essai de conformité relatif à la couche physique et à la
couche liaison de données pour la communication sans-fil
Reference number
© ISO 2022
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: +41 22 749 01 11
Email: copyright@iso.org
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 . 2
4 Abbreviated terms . 6
5 Conventions . 7
5.1 Requirement structure . 7
5.2 Test system description . . 8
6 Test architecture reference model . 8
6.1 General information. 8
6.2 Platform adapter interface . 8
6.3 SUT adapter interfaces . 9
6.4 Codecs . . 9
7 Test suite conventions.10
7.1 General information. 10
7.2 Test suite structure (TSS) . 10
7.3 Test profiles . 11
7.3.1 Test configurations .12
7.3.2 Components and ports .12
7.3.3 Protocol implementation conformance statement (PICS) definition . 14
7.3.4 Protocol implementation extra information for testing (PIXIT) definition . 14
7.3.5 Test control . 15
7.4 Test suite identifiers . 15
7.4.1 Module identifiers .15
7.4.2 Test case identifiers . 16
7.4.3 Template identifiers . 16
7.4.4 Function identifiers . 17
7.4.5 Timer identifiers . 18
7.4.6 PICS/PIXIT identifiers . 18
7.4.7 Verdict identifiers . 19
7.5 Test suite coverage . 19
7.6 Test case description .22
8 Test case descriptions for ISO 15118-8 requirements .23
8.1 General information.23
8.2 SECC test cases . 23
8.3 EVCC test cases . 43
Bibliography .72
iii
Foreword
ISO (the International Organization for Standardization) and IEC (the International Electrotechnical
Commission) form the specialized system for worldwide standardization. National bodies that are
members of ISO or IEC participate in the development of International Standards through technical
committees established by the respective organization to deal with particular fields of technical
activity. ISO and IEC technical committees collaborate in fields of mutual interest. Other international
organizations, governmental and non-governmental, in liaison with ISO and IEC, also take part in the
work.
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 document 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 or
www.iec.ch/members_experts/refdocs).
Attention is drawn to the possibility that some of the elements of this document may be the subject
of patent rights. ISO and IEC 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) or the IEC
list of patent declarations received (see https://patents.iec.ch).
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. In the IEC, see www.iec.ch/understanding-standards.
This document was prepared jointly by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC
31, Data communication, and Technical Committee IEC/TC 69, Electrical power/energy transfer systems
for electrically propelled road vehicles and industrial trucks.
A list of all parts in the ISO 15118 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 and
www.iec.ch/national-committees.
iv
Introduction
Resulting from the wireless physical and data link layer requirements defined in ISO 15118-8, a
corresponding set of abstract test cases is necessary to verify the conformance of implementations.
This document, therefore, defines a conformance test suite for the wireless physical and data link layer
protocols in order to derive a common and agreed basis for conformance tests. The resulting test suite
is a prerequisite for downstream interoperability tests. Since interoperability furthermore involves
the actual application logic of an implementation, those tests are beyond the scope of this document.
Hence, this document focuses on the interface aspects and the corresponding requirements given in
ISO 15118-8 only.
v
INTERNATIONAL STANDARD ISO 15118-9:2022(E)
Road vehicles — Vehicle to grid communication
interface —
Part 9:
Physical and data link layer conformance test for wireless
communication
1 Scope
This document specifies conformance tests in the form of an abstract test suite (ATS) for a system under
test (SUT) implementing an electric-vehicle or supply-equipment communication controller (EVCC or
SECC) with support for WLAN-based high-level communication (HLC) according to ISO 15118-8 and
against the background of ISO 15118-1. These conformance tests specify the testing of capabilities and
behaviours of an SUT, as well as checking what is observed against the conformance requirements
specified in ISO 15118-8 and against what the implementer states the SUT implementation's capabilities
are.
The capability tests within the ATS check that the observable capabilities of the SUT are in accordance
with the static conformance requirements defined in ISO 15118-8. The behaviour tests of the ATS
examine an implementation as thoroughly as practical over the full range of dynamic conformance
requirements defined in ISO 15118-8 and within the capabilities of the SUT (see NOTE below).
A test architecture is described in correspondence to the ATS. The abstract test cases in this document
are described leveraging this test architecture and are specified in descriptive tabular format for the
ISO/OSI physical and data link layers (layers 1 and 2).
In terms of coverage, this document only covers normative sections and requirements in ISO 15118-8.
This document can additionally refer to specific tests for requirements on referenced standards (e.g.
IEEE, or industry consortia standards, like WiFi Alliance) as long as they are relevant in terms of
conformance for implementations according to ISO 15118-8. However, it is explicitly not intended to
widen the scope of this conformance specification to such external standards, if it is not technically
necessary for the purpose of conformance testing for ISO 15118-8. Furthermore, the conformance tests
specified in this document do not include the assessment of performance nor robustness or reliability
of an implementation. They cannot provide judgments on the physical realization of abstract service
primitives, how a system is implemented, how it provides any requested service, nor the environment
of the protocol implementation. Furthermore, the abstract test cases defined in this document only
consider the communication protocol and the system's behaviour defined ISO 15118-8. The power flow
between the EVSE and the EV is not considered.
NOTE Practical limitations make it impossible to define an exhaustive test suite, and economic considerations
can restrict testing even further. Hence, the purpose of this document is to increase the probability that different
implementations are able to interwork. This is achieved by verifying them by means of a protocol test suite,
thereby increasing the confidence that each implementation conforms to the protocol specification. However,
the specified protocol test suite cannot guarantee conformance to the specification since it detects errors rather
than their absence. Thus, conformance to a test suite alone cannot guarantee interworking. Instead, it gives
confidence that an implementation has the required capabilities and that its behaviour conforms consistently in
representative instances of communication.
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 15118-1, Road vehicles — Vehicle to grid communication interface — Part 1: General information and
use-case definition
ISO 15118-2, Road vehicles — Vehicle-to-Grid Communication Interface — Part 2: Network and application
protocol requirements
ISO 15118-8:2020, Road vehicles — Vehicle to grid communication interface — Part 8: Physical layer and
data link layer requirements for wireless communication
ISO 15118-20, Road vehicles — Vehicle to grid communication interface — Part 20: 2nd generation network
layer and application layer requirements
1)
ETSI ES 201 873-5 V4.9.1 , Methods for Testing and Specification (MTS) — The Testing and Test Control
Notation version 3 — Part 5: TTCN-3 Runtime Interface (TRI) (April 2022)
2)
ETSI ES 201 873-6 V4.13.1 , Methods for Testing and Specification (MTS) — The Testing and Test Control
Notation version 3 — Part 6: TTCN-3 Control Interface (TCI) (April 2022)
IEEE 802.11-2012, IEEE Standard for Information technology — Telecommunications and information
exchange between systems — Local and metropolitan area networks — specific requirements: Part 11:
Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 15118-1, ISO 15118-2,
ISO 15118-8, ISO 15118-20 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
abstract test case
complete and independent specification of the actions required to achieve a specific test purpose (3.25),
defined at the level of abstraction of a particular abstract test method, starting in a stable testing state
and ending in a stable testing state and optionally involves one or more consecutive or concurrent
connections
Note 1 to entry: The specification should be complete in the sense that it is sufficient to enable a test verdict
(3.29) to be assigned unambiguously to each potentially observable test outcome (i.e. sequence of test events).
Note 2 to entry: The specification should be independent in the sense that it should be possible to execute the
derived executable test case (3.7) in isolation from other such test cases (i.e. the specification should always
include the possibility of starting and finishing in the 'idle' state).
[SOURCE: ITU-T X.290:1995, 3.3.3].
3.2
ATS
abstract test suite
test suite composed of abstract test cases (3.1)
[SOURCE: ITU-T X.290:1995, 3.3.6]
1) Available at https:// www .etsi .org/ deliver/ etsi _es/ 201800 _201899/ 20187305/ 04 .09 .01 _60/ es
_20187305v040901p .pdf.
2) Available at https:// www .etsi .org/ deliver/ etsi _es/ 201800 _201899/ 20187306/ 04 .13 .01 _60/ es
_20187306v041301p .pdf.
3.3
APUT
access point under test
ISO/OSI layer 1 and 2 component of the SECC [system under test (SUT) (3.19)] for establishing a wireless
communication connection
3.4
black box test
method of testing that examines the behaviour of a system under test (SUT) (3.19) without considering
the internal implementation and structure of the SUT, thus relying on the SUT's open interface for
testing
3.5
conformance requirement
conformance of a real system consisting of conformance to each requirement and conformance to the
set
Note 1 to entry: Set of interrelated requirements which together define the behaviour of the system and its
communication. Conformance of a real system will, therefore, be expressed at two levels, conformance to each
individual requirement and conformance to the set. Applicable conformance tests defined in this document,
include requirements and transfer syntax requirements as far as they can be validated by black box tests (3.4).
Note 2 to entry: See also static conformance requirement (3.17) and dynamic conformance requirement (3.6).
3.6
dynamic conformance requirement
one of the requirements which specifies what observable behaviour is permitted by the relevant
specification(s) in instances of communication
Note 1 to entry: The requirements for this conformance specification are defined in ISO 15118-8.
[SOURCE: ITU-T X.290:1995, 3.3.29, modified — Note 1 to entry has been added.]
3.7
executable test case
realization of an abstract test case (3.1)
[SOURCE: ITU-T X.290:1995, 3.3.31]
3.8
expected behaviour
exact response of the system under test (SUT) (3.19) according to the underlying protocol specification
to the stimulus defined in the test behaviour (3.20)
3.9
ICS
implementation conformance statement
statement made by the supplier of an implementation or system claimed to conform to a given
specification, stating which capabilities have been implemented
Note 1 to entry: The given specification for this conformance specification is ISO 15118-8.
[SOURCE: ITU-T X.290:1995, 3.3.39, modified — "The ICS can take several forms: protocol ICS, profile
ICS, profile specific ICS, and information object ICS." has been removed from the definition and Note 1
to entry has been added.]
3.10
IXIT
implementation extra information for testing
statement made by a supplier or implementer of a system under test (SUT) (3.19) which contains or
references all of the information [in addition to that given in the implementation conformance statement
(ICS) (3.9)] related to the SUT and its testing environment, which will enable the test laboratory to run
an appropriate test suite against the SUT
[SOURCE: ITU-T X.290:1995, 3.3.41, modified — "An IXIT can take several forms: protocol IXIT, profile
IXIT, profile specific IXIT, and information object IXIT, TMP implementation statement." removed from
the defintiion and IUT replaced by SUT.]
3.11
MTC
main test component
single test component (3.21) in a test component configuration responsible for creating and controlling
parallel test components (3.12) and computing and assigning the test verdict (3.29)
[SOURCE: ITU-T X.292:2002, 3.6.43]
3.12
parallel test component
PTC
test component (3.21) created by the main test component (3.11)
[SOURCE: ITU-T X.292:2002, 3.6.53]
3.13
post-condition
test steps needed to define the path from the end of the test behaviour (3.20) up to the finishing stable
state for the test case
3.14
pre-condition
test steps needed to define the path from the starting stable state of the test case up to the initial state
from which the test bevaviour (3.20) will start
3.15
PICS
protocol implementation conformance statement
implementation conformance statement (ICS) (3.9) for an implementation or system claimed to conform
to a given protocol specification
Note 1 to entry: The given protocol specification for this conformance specification is ISO 15118-8.
[SOURCE: ITU-T X.290:1995, 3.3.80, modified — Note 1 to entry has been added.]
3.16
PIXIT
protocol implementation extra information for testing
implementation extra information for testing (IXIT) (3.10) related to testing for conformance to a given
protocol specification
Note 1 to entry: The given protocol specification for this conformance specification is ISO 15118-8.
[SOURCE: ITU-T X.290:1995, 3.3.81, modified — Note 1 to entry has been added.]
3.17
static conformance requirement
one of the requirements that specify the limitations on the combinations of implemented capabilities
permitted in a real open system which is claimed to conform to the relevant specification(s)
[SOURCE: ITU-T X.290:1995, 3.3.95]
3.18
STAUT
station under test
ISO/OSI layer 1 and 2 component of the EVCC [system under test (SUT) (3.19)] for establishing a wireless
communication connection
3.19
SUT
system under test
real open system in which the implementation of one or more OSI protocols in an adjacent user/provider
relationship are to be studied by testing.
Note 1 to entry: Adapted from ITU-T X.290:1995, 3.3.103 and 3.3.43.
3.20
test behaviour
set of test steps (test body) which are essential in order to achieve the test purpose (3.25) and assign
verdicts to the possible outcomes
3.21
test component
named subdivision of a concurrent test case capable of being executed in parallel and declared as having
a fixed number of points of control and observation and a fixed or maximal number of co-ordination
points
[SOURCE: ITU-T X.292:2002, 3.6.72, modified — "in parallel with other test components" has been
replaced by "in parallel".]
3.22
TCI
TTCN-3 control interfaces
four interfaces that define the interaction of the TTCN-3 Executable with the test management, the
coding and decoding, the test component (3.21) handling and the logging in a test system (3.27)
[SOURCE: ETSI ES 201 873-6 V4.13.1:2022, 3.1]
3.23
test execution
interpretation or execution of an abstract test suite (3.2)
Note 1 to entry: Conceptually, the test execution can be decomposed into three interacting entities: an executable
test suite, a test framework (3.24) and an optional internal encoding/decoding system entity.
3.24
test framework
entity to perform all actions of test cases or functions
Note 1 to entry: The test framework interacts with the test management, system under test (SUT) (3.19) adaptor
and platform adaptor entities via TTCN-3 control interfaces (TCI) (3.22) and test runtime interface (TRI) (3.26)
and additionally manages the executable test suite and encoding/decoding system entities. It initializes adaptors
as well as executable test suite and encoding/decoding system entities. This entity performs all the actions
necessary to properly start the execution of a test case or function with parameters in the executable test suite
entity. It queries the test management entity for module parameter values required by the executable test suite
and sends logging information to it. It also collects and resolves associated verdicts returned by the executable
test suite entity.
Note 2 to entry: In this document, the TTCN-3 runtime system is used to explain a test framework functionality.
3.25
test purpose
prose description of a well-defined objective of testing, focusing on a single conformance requirement
(3.5) or a set of related conformance requirements as specified in the appropriate OSI specification
EXAMPLE Verifying the support of a specific value of a specific parameter.
[SOURCE: ITU-T X.290:1995, 3.3.118]
3.26
TRI
test runtime interface
two interfaces that define the interaction of the TTCN-3 executable between the system under test (SUT)
(3.19) and the platform adapter (PA) and the system adapter (SA) in a test system (3.27)
[SOURCE: ETSI ES 201 873-5 V4.9.1:2022, 3.1, modified — The term was originally TTCN-3 runtime
interface.]
3.27
test system
real system combining the test framework (3.24), abstract test suite (3.2), test execution (3.23) and
adapters as well as codecs
Note 1 to entry: Typically, also containing a common runtime environment based on an operating system.
3.28
TSI
test system interface
test component (3.21) that provides a mapping of the ports available in the (abstract) TTCN-3 test system
(3.27) to those offered by a real test system
[SOURCE: ETSI ES 201 873-5 V4.9.1:2022, 3.1]
3.29
test verdict
statement of 'pass', 'fail' or 'inconclusive', as specified in an abstract test case (3.1), concerning
conformance of a system under test (SUT) (3.19) with respect to that test case when it is executed
[SOURCE: ITU-T X.290:1995, 3.3.124, modified — IUT was replaced by SUT.]
4 Abbreviated terms
For the purposes of this document, the following abbreviated terms apply:
AP (wireless) access point
APUT access point under test
ATS abstract test suite
EDCA enhanced distributed channel access
ETSI european telecommunications standards institute
EV electric vehicle
EVCC electric vehicle communication controller
EVSE electric vehicle supply equipment
HAL hardware abstraction layer
ICS implementation conformance statement
ITB invalid test behaviour
MAC media access control
MTC main test component
PICS protocol implementation conformance statement
PIXIT protocol implementation extra information for testing
PTC parallel test component
SECC supply equipment communication controller
STA (wireless) station
STAUT station under test
SUT system under test
TC test case
TCI TTCN-3 control interface
TCI-CD TCI-coding and decoding
TE test execution
TRI TTCN-3 runtime interface
TSI TTCN-3 system interface
TSS test suite structure
TTCN-3 testing and test control notation version 3
V2G vehicle-to-grid
VTB valid test behaviour
5 Conventions
5.1 Requirement structure
This document uses unique number identifiers for each individual requirement. This requirement
structure allows for easier requirement tracking and management. The following format is used
throughout this document:
'[V2G'Y'-'XXX']' requirement text
Where:
— 'V2G' represents the ISO 15118 series;
— Y represents the document part of the ISO 15118 series, for this document Y = 9;
— XXX represents the individual requirement number; and
— 'requirement text' includes the actual text of the requirement.
5.2 Test system description
TTCN-3 is used in this document to define/specify the test system architecture and test suite
conventions, where applicable. TTCN-3 is, however, not mandatory for the implementation of a
conformance test system according to this document.
[V2G9-001] The implementers of conformance tests shall verify that the test purposes implemented
in their executable test cases are identical to the abstract test cases described in this
document.
NOTE In this document, test cases are not programmatically specified in TTNC-3 core language. This will be
revisited for the next edition of the document.
6 Test architecture reference model
6.1 General information
Figure 1 provides an overview of the test architecture for this document. The following subclauses
define the interface requirements for platform and SUT adapters (see 6.2, 6.3) as well as the codecs (see
6.4). The test suite is defined in detail in the remainder of this document.
Figure 1 — Test architecture reference model
6.2 Platform adapter interface
The platform adapter within the test system is responsible for timers and external functions. Besides
means for timers, which are typically provided as part of the test framework, no external functions are
defined for this document.
[V2G9-002] The platform adapter of the test system shall implement the TriPlatformPA and the
TriPlatformTE interfaces as defined in ETSI ES 201 873-5 V4.9.1:2022, 6.5.3.
6.3 SUT adapter interfaces
The SUT adapter within the test system adapts the TTCN-3 communication operations to the SUT based
on an abstract test system interface and implements the real test system interface. It is responsible
of propagating message requests and procedure-based calls from the test execution (see Figure 1) to
the SUT, and of notifying the test execution of any received test events by appending them to its port
queues.
[V2G9-003] Any SUT adapter of the test system shall implement the TriCommunicationSA and the
TriCommunicationTE interfaces as defined in ETSI ES 201 873-5 V4.9.1:2022, 6.5.2.
NOTE 1 The actual implementation of these adapters is out of scope of this document.
[V2G9-004] The ISO 15118-8 SUT adapter of the test system shall send/receive the encoded MAC
frame format to/from the SUT as defined in IEEE 802.11-2012, section 8.
NOTE 2 For association support according to ISO 15118-8 the management frames according to IEEE 802.11-
2012, section 8.3.3 are used and embedded in the frame body field of the MAC frame format.
[V2G9-005] The wireless communication module of the ISO 15118-8 SUT adapter of the test system
shall be certified by WiFi Alliance ('Wi-Fi CERTIFIED n').
The majority of requirements in ISO 15118-8 are based on IEEE 802.11n. WiFi Alliance certification is
therefore required for the ISO 15118-8 SUT adapter in order to ensure the test system complies with
IEEE 802.11n.
[V2G9-006] In case SUT is a STAUT, the ISO 15118-8 SUT adapter of the test system shall support
operation at both the 2,4 GHz and 5 GHz frequency bands in parallel (simultaneous dual
band support).
[V2G9-007] The wireless communication module of the ISO 15118-8 SUT adapter of the test system
shall at least support all allowed channels per frequency band that are applicable for
the SUT according to ISO 15118-8:2020, Tables 1, 2, and Annex D.
NOTE 3 Depending on the target market of the SUT, not all the channels listed in ISO 15118-8:2020, Tables 1
and 2 are allowed to be used due to national regulation.
NOTE 4 A collection of national regulations in usage of the U-NII band channels is listed in ISO 15118-8:2020,
Annex D.
[V2G9-008] The ISO 15118-8 SUT adapter of the test system shall support active and passive scan-
ning procedure according to IEEE 802.11-2012.
6.4 Codecs
A codec is responsible for the external encoding and decoding of TTCN-3 values into bit strings suitable
to be sent to the SUT. The test execution (TE) determines which codec shall be used and passes the
TTCN-3 data to the appropriate encoder to obtain the encoded data. Received data is decoded in this
entity by using the appropriate decoder, which translates the received data into TTCN-3 values cf.
ETSI ES 201 873-5 that can be matched against expected values or templates.
[V2G9-009] All codecs in this document shall implement the TCI-CD interface as defined in ETSI ES
201 873-6 V4.13.1:2022, 7.3.2.
NOTE 1 For conformance testing in this document, the IEEE 802.11n codec (see Figure 1) is used to encode or
decode messages consumable by the tester into bit strings consumable by the SUT.
NOTE 2 The exact implementation of the IEEE 802.11n codec is out of scope of this document.
[V2G9-010] The ISO 15118-8 codec shall encode message values of the test system into correspond-
ing MAC frames consumable by the SUT as defined in ISO 15118-8:2020, 7.2.6 and 7.3.5
and IEEE 802.11-2012.
[V2G9-011] The ISO 15118-8 codec shall decode MAC frames as defined in ISO 15118-8:2020, 7.2.6
and 7.3.5 and IEEE 802.11-2012 into message values consumable by the test system.
7 Test suite conventions
7.1 General information
This clause defines all conventions that are relevant for conformance tests of SUTs implementing
ISO 15118-8.
7.2 Test suite structure (TSS)
A test suite is a complete set of test cases, possibly combined into groups or modules, that are necessary
to perform conformance testing for a given SUT.
Each executable test case stimulates the SUT with specific inputs and the reactions are observed
and evaluated. Depending on the test purpose different pre-conditions and post-conditions shall be
considered for the formulation of the test behaviour. The pre-conditions, post-conditions as well as test
behaviours are encapsulated into individual functions and stored within separate modules. Thus, a
complete test case is composed by the actual test behaviour enveloped by pre- and post-conditions. The
corresponding grouping of functions can therefore be assigned to the lowest abstract hierarchical level
(see Figure 2). The test cases are defined on the second level.
Figure 2 — General overview of the test suite structure (TSS)
The test profile is a collection of self-contained test cases as well as PICS (see 7.3.3) and PIXIT (see 7.3.4)
in order to represent a given use case. The selection is based on the use cases of the ISO 15118 series
and its corresponding requirements.
Hence, the test suite structure (TSS) is segmented into subgroups defined according to ISO 15118 use
cases for conformance testing. Table 1 shows these subgroups, which are used for the organization of
the test case specifications as well as for the test suite identifiers (see 7.4 for detail).
Table 1 — Identifiers within the test suite structure (TSS)
Identifiers Values Description
System under test
EVCC Electric vehicle communication controller
SECC Supply equipment communication controller
{fullname} Context (e.g. name of message pattern signal name according to standard)
7.3 Test profiles
This subclause defines test profiles for conformance with ISO 15118-8. A test profile consists of a test
configuration as well as a selection and assignment of PICS/PIXIT. Depending on the test configuration
a set of test components and ports are defined. The test profile furthermore includes a test group
defining the set of relevant test cases and the sequence in which they are executed in order to perform
a conformance test for a given use case.
7.3.1 Test configurations
The test configuration reflects various ISO 15118 scenarios. The main entities for the system under test
(SUT) are:
— electric vehicle communication controller (EVCC),
— supply equipment communication controller (SECC).
The combination of entities and additionally used test components are grouped by test configuration
IDs (CF_Part_ID). Table 2 shows the test configurations for this document.
Table 2 — Test configurations
CF_Part_ID SUT Tester PTCs
CF_09_001 SECC including wireless EVCC with ISO 15118-8 SUT none
LAN interface adapter
CF_09_002 EVCC including wireless SECC with ISO 15118-8 SUT none
LAN interface adapter
Figure 3 and Figure 4 illustrate configurations as defined in Table 2.
Figure 3 — Test configuration CF_09_001 for SUT SECC (APUT)
Figure 4 — Test configuration CF_09_002 for SUT EVCC (STAUT)
7.3.2 Components and ports
In correspondence to the identified set of relevant test configurations, this subclause defines test
components which reflect the main entities needed for stimulation of the SUT with respect to the
ISO 15118 series. Ports are used to connect these components with each other and the SUT. Port types
define what kind of messages can be sent or received by this port. All relevant components and ports
are defined in Table 3 and Table 5 respectively.
Table 3 — Component definitions
Components Description
SECC_Tester (MTC) This component type is the main type for the tests of an SECC.
A WLAN_Port (see Table 4) is assigned to this component type.
TTabablele 3 3 ((ccoonnttiinnueuedd))
Components Description
EVCC_Tester (MTC) This component type is the main type for the tests of an EVCC.
A WLAN_Port (see Table 4) is assigned to this component type.
Table 4 — Port type definitions
Port Type Description
WLAN_Port This port is used to send/receive WLAN MAC Frames defined in ISO 15118-8
and IEEE 802.11-2012 to/from the EVCC/SECC.
These components and ports comprise relevant test configurations for this document. Whether the
type EVCC_Tester or SECC_Tester is to be used as MTC depends on the type of the SUT.
[V2G9-012] If the SUT is an EVCC, the MTC shall use the type EVCC_Tester.
[V2G9-013] If the SUT is an SECC, the MTC shall use the type SECC_Tester.
The MTC always contains a TTCN-3 test configuration and delimits the lifeline during test execution.
Next to using ports for communication purposes, local timers, variables or constants may be assigned
to components to store dynamic information during test case execution.
A test configuration also consists of respective test system interfaces (TSI). An abstract TSI is specified
as a collection of ports. A TSI has no local timers, constants or variables; only ports are assigned to it.
During the test case execution, test components ports can be mapped dynamically to the TSI ports to
establish communication channel to the real test system interface.
In the test configuration the TSI uses the type System_EVCC or System_SECC depending on the type of
the SUT.
— If the SUT is an EVCC, the TSI uses the type System_EVCC.
— If the SUT is an SECC, the TSI uses the type System_SECC.
The test configuration is illustrated in Figure 5. The type of the V2G components and ports (EVCC or
SECC) depends on the SUT type.
Figure 5 — Test configuration of this document
As shown in Figure 5 the port mappings are defined statically as follows:
— the port pt_WLAN_Port of the TSI is always mapped to port pt_WLAN_Port of the MTC.
7.3.3 Protocol implementation conformance statement (PICS) definition
To evaluate the conformance of a particular SUT, it is necessary to have implementation conformance
statements (ICS) of the capabilities and options which have been implemented, and any features
which have been omitted, so that the implementation can be tested for conformance against relevant
requirements, and against those requirements only. Such a statement is called a protocol implementation
conformance statement (PICS), compare to ITU-T X.290.
In this document, no PICS are defined in the ATS.
7.3.4 Protocol implementation extra information for testing (PIXIT) definition
In addition to the ICS, further statements (IXIT) made by a supplier or implementer may be required
related to the SUT and its testing environment to enable the test laboratory to run the test suite against
the SUT. With reference to ISO 15118-8 protocol conformance, the following set of PIXIT is defined in
addition to the PICS in this document.
NOTE Due to the black box test paradigm in this document, it is not defined how to ensure that a
corresponding PIXIT is set on the SUT side for a given test case execution.
All PIXIT defined in the ATS are summarized in Table 5 to Table 7
Table 5 — Selected PIXIT for test system configurations CF_09_001 and CF_09_002 (SUT either
SECC or EVCC)
PIXIT Description
PIXIT_CMN_MACADDR_2_4GHz MAC address of the 2,4 GHz network interface of the SUT
PIXIT_CMN_MACADDR_5GHz MAC address of the 5 GHz network interface of the SUT
PIXIT_CMN_ ETT Indication which energy transfer types are supported by the
SUT
One octet with bitfield according to ISO 15118-8:2020,
Table 4, e.g.:
— 00000011 or 0x3 (→ AC & DC support)
— 00000100 or 0x4 (→ WPT support)
— 00001000 or 0x8 (→ ACD support)
PIXIT_CMN_ADDINF Indication which additional information is provided by the
SUT
Hexbinary according to ISO 15118-8:2020, Table 5
PIXIT_CMN_COUNTRY_CODE Indication for a two-character country code according to ISO
3166-1
PIXIT_CMN_OPERATOR_ID Indication for an operator ID as defined in ISO 15118-2:2014,
Annex H (see also ISO 15118-8:2020, Table 4 for further infor-
mation)
PIXIT_CMN_CHARGING_SITE_ID Indication for a unique identifier of the CS (see also ISO
15118-8:2020, Table 4 for further information)
[V2G9-014] For the purpose of testing the values of country code, operator id and charging site id
should be compatible between the test system and SUT regarding the values of PIXIT_
CMN_COUNTRY_CODE, PIXIT_CMN_OPERATOR_ID, and PIXIT_CMN_CHARGING_SITE_ID.
Table 6 — Selected PIXIT for test system configuration CF_09_001 (SUT equals SECC)
PIXIT Description
PIXIT_SECC_NUMOUTLETS Indication of whether the SECC supports one or multiple
outlets
Choice: i) one, ii) multiple
PIXIT_SECC_SUPPORTED_CHANNEL_LIST List of supported channels in the 2,4 GHz and 5 GHz band
according to ISO 15118-8:2020, Tables 1, 2 and national/re-
gional regulations in ISO 15118-8:2020, Annex D as key value
pairs list
PIXIT_SECC_CHANNEL_SELECTED Selected Channel ID in the either 2,4 GHz or 5 GHz band
Enumeration with reference to Channel IDs according to ISO
15118-8:2020, Tables 1 and 2.
Table 7 — Selected PIXIT for test system configuration CF_09_002 (SUT equals EVCC)
PIXIT Description
PIXIT_EVCC_SCANNING_MODE Indication wheth
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...