Road vehicles - Vehicle to grid communication interface - Part 4: Network and application protocol conformance test

ISO 15118-4:2018 specifies conformance tests in the form of an Abstract Test Suite (ATS) for a System Under Test (SUT) implementing an EVCC or SECC according to ISO 15118-2. These conformance tests specify the testing of capabilities and behaviors of an SUT as well as checking what is observed against the conformance requirements specified in ISO 15118-2 and against what the supplier 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-2. The behavior tests of the ATS examine an implementation as thoroughly as is practical over the full range of dynamic conformance requirements defined in ISO 15118-2 and within the capabilities of the SUT (see NOTE).
A test architecture is described in correspondence to the ATS. The conformance test cases in this document are described leveraging this test architecture and are specified in TTCN-3 Core Language for ISO/OSI Network Layer (Layer 3) and above. The conformance test cases for the Data Link Layer (Layer 2) and Physical Layer (Layer 1) are described in ISO 15118-5. Test cases with overlapping scopes are explicitly detailed.
This document does not include specific tests of other standards referenced within ISO 15118-2, e.g. IETF RFCs. 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 test cases defined in this document only consider the communication protocol defined ISO 15118-2. Power flow between the EVSE and the EV is not considered.
NOTE 1 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. What it does do is give confidence that an implementation has the required capabilities and that its behavior conforms consistently in representative instances of communication.
NOTE 2 This document has some interdependencies to the conformance tests defined in ISO 15118-5 which result from ISO/OSI cross layer dependencies in the underlying protocol specification (e.g. for sleep mode)

General Information

Status
Published
Publication Date
06-Mar-2018
Current Stage
PPUB - Publication issued
Start Date
08-Mar-2018
Completion Date
14-May-2018
Ref Project
Standard
ISO 15118-4:2018 - Road vehicles - Vehicle to grid communication interface - Part 4: Network and application protocol conformance test
English language
1459 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


INTERNATIONAL ISO
STANDARD 15118-4
First edition
2018-02
Road vehicles — Vehicle to grid
communication interface —
Part 4:
Network and application protocol
conformance test
Véhicules routiers — Interface de communication entre véhicule et
réseau électrique —
Partie 4: Essai de conformité du protocole d'application et du réseau
Reference number
©
ISO 2018
© ISO 2018
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
Fax: +41 22 749 09 47
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii © ISO 2018 – All rights reserved

Contents Page
Foreword . vii
Introduction . viii
1  Scope . 1
2  Normative references . 2
3  Terms and definitions . 2
4  Symbols (and abbreviated terms) . 7
5  Conventions . 8
5.1  Requirement structure . 8
5.2  Test system description . 9
6  Test architecture reference model . 9
6.1  General information . 9
6.2  Platform adapter interface . 10
6.3  SUT adapter interfaces . 10
6.4  Codecs . 11
7  Test suite conventions . 11
7.1  General information . 11
7.2  Test suite structure (TSS) . 11
7.3  Test profiles . 13
7.4  Test suite identifiers . 62
7.5  Test suite coverage . 67
7.6  Test case description . 184
7.7  Test case specification . 185
8  Test case descriptions for 15118-2 V2GTP . 198
8.1  General information . 198
8.2  SECC test cases . 198
8.3  EVCC test cases . 202
9  Test case descriptions for 15118-2 SDP messages . 208
9.1  General information . 208
9.2  SECC test cases . 208
9.3  EVCC test cases . 211
10  Test case descriptions for 15118-2 V2G application layer messages . 236
10.1  General information . 236
10.2  SECC test cases . 236
10.3  EVCC test cases . 405
Annex A (normative) Configuration specifications . 671
A.1  Timer configuration . 671
A.2  PICS configuration . 671
iii
© ISO 2018 ‐ All rights reserved

A.3  PIXIT configuration . 673
Annex B (normative) Control part specification . 675
B.1  SECC control parts . 675
B.1.1  AC specific control parts . 675
B.1.2  DC specific control parts . 675
B.2  EVCC control parts . 688
B.2.1  AC specific control parts . 702
B.2.2  DC specific control parts . 702
Annex C (normative) Test-case specifications for 15118-2 V2GTP . 745
C.1  SECC test cases . 745
C.2  EVCC test cases . 745
Annex D (normative) Test-case specifications for 15118-2 SDP messages . 752
D.1  SECC test cases . 752
D.2  EVCC test cases . 752
Annex E (normative) Test-case specifications for 15118-2 V2G application layer messages . 773
E.1  SECC test cases . 773
E.1.1  V2G protocol handshake . 773
E.1.1.1 SECC test cases for SupportedAppProtocol . 773
E.1.2  V2G messages . 773
E.1.2.1 SECC test cases for SessionSetup . 775
E.1.2.2 SECC test cases for ServiceDiscovery . 775
E.1.2.3 SECC test cases for ServiceDetail . 782
E.1.2.4 SECC test cases for PaymentServiceSelection . 784
E.1.2.5 SECC test cases for PaymentDetails . 788
E.1.2.6 SECC test cases for Authorization . 794
E.1.2.7 SECC test cases for ChargeParameterDiscovery . 794
E.1.2.8 SECC test cases for PowerDelivery . 799
E.1.2.9 SECC test cases for CertificateUpdat e . 824
E.1.2.10  SECC test cases for CertificateInstallation . 839
E.1.2.11  SECC test cases for SessionStop . 839
E.1.2.12  SECC test cases for ChargingStatus . 842
E.1.2.13  SECC test cases for MeteringReceipt . 846
E.1.2.14  SECC test cases for CableCheck . 848
E.1.2.15  SECC test cases for PreCharge . 852
E.1.2.16  SECC test cases for CurrentDemand . 855
E.1.2.17  SECC test cases for WeldingDetection . 859
E.2  EVCC test cases . 860
Annex F (normative) Function specifications for supporting test execution . 1009
iv
© ISO 2018 ‐ All rights reserved

F.1  Configuration functions . 1009
F.2  Pre-condition functions . 1009
F.2.1  SECC functi ons . 1011
F.2.2  EVCC functions . 1027
F.3  Post-condition functions . 1027
F.3.1  SECC functi ons . 1038
F.3.2  EVCC functions . 1038
F.4  Common behavior functions . 1039
F.4.1  SECC functi ons . 1040
F.4.2  EVCC functions . 1042
F.5  Library functions . 1044
Annex G (normative) Function specifications for 15118-2 V2GTP . 1051
G.1  SECC functi ons . 1051
G.2  EVCC functions . 1053
Annex H (normative) Function specifications for 15118-2 SDP messages . 1056
H.1  SECC functi ons . 1056
H.2  EVCC functions . 1057
Annex I (normative) Function specifications for 15118-2 V2G application layer messages . 1061
I.1  SECC functi ons . 1061
I.1.1  V2G protocol handshake . 1061
I.1.1.1  SECC functions for SupportedAppProtocol . 1061
I.1.2  V2G messages . 1063
I.1.2.1  SECC functions for SessionSetup . 1063
I.1.2.2  SECC functions for ServiceDiscovery . 1064
I.1.2.3  SECC functions for ServiceDetail . 1072
I.1.2.4  SECC functions for PaymentServiceSelection . 1080
I.1.2.5  SECC functions for PaymentDetails . 1087
I.1.2.6  SECC functions for Authorization . 1091
I.1.2.7  SECC functions for ChargeParameterDiscovery . 1104
I.1.2.8  SECC functions for PowerDelivery . 1140
I.1.2.9  SECC functions for CertificateUpdate . 1154
I.1.2.10  SECC functions for CertificateInstallation . 1167
I.1.2.11  SECC functions for SessionStop . 1176
I.1.2.12  SECC functions for ChargingStatus . 1176
I.1.2.13  SECC functions for MeteringReceipt . 1185
I.1.2.14  SECC functions for CableCheck . 1197
I.1.2.15  SECC functions for PreCharge . 1203
I.1.2.16  SECC functions for CurrentDemand . 1207
v
© ISO 2018 ‐ All rights reserved

I.1.2.17  SECC functions for WeldingDetection . 1213
I.2  EVCC functions . 1217
Annex J (normative) Template specifications for V2G TCP/TLS Port Control . 1373
Annex K (normative) Template specifications for 15118-2 V2GTP . 1375
K.1  Common templates . 1375
Annex L (normative) Template specifications for 15118-2 SDP messages . 1376
L.1  Common templates . 1376
Annex M (normative) Template specifications for 15118-2 V2G application layer messages 1377
M.1  Common templates . 1377
M.1.1  V2G protocol handshake . 1378
M.1.1.1  CMN templates for SupportedAppProtocol . 1378
M.1.2  V2G messages . 1378
M.1.2.1  CMN templates for SessionSetup . 1378
M.1.2.2  CMN templates for ServiceDiscovery . 1378
M.1.2.3  CMN templates for Authorization . 1381
M.1.2.4  CMN templates for PowerDelivery . 1381
M.1.2.5  CMN templates for SessionStop . 1383
M.1.2.6  CMN templates for ChargingStatus . 1384
M.1.2.7  CMN templates for CableCheck . 1384
M.1.2.8  CMN templates for PreCharge . 1385
M.1.2.9  CMN templates for CurrentDemand . 1385
M.1.2.10  CMN templates for WeldingDetection . 1387
M.2  SECC templates . 1387
M.3  EVCC templates . 1397
Annex N (normative) Template specifications for Security . 1430
N.1  Common templates . 1430
Annex O (normative) Data type definitions . 1434
O.1  Data types for PICS . 1434
O.2  Data types for PIXIT . 1434
O.3  Data types for V2G TCP/TLS Port Control . 1436
O.4  Data types for V2GTP . 1437
O.5  Data types for SDP messages . 1438
O.6  Data types for V2G messages . 1438
O.7  Data types for Security . 1457
vi
© ISO 2018 ‐ All rights reserved

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 on 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 the following
URL: www.iso.org/iso/foreword.html
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31,
Electrical and electronic equipment, and Technical Committee IEC/TC 69 Electric road vehicles and
electric industrial trucks. The draft was circulated for voting to the national bodies of both ISO and IEC.
A list of all parts in the ISO 15118 series can be found on the ISO website.
vii
© ISO 2018 ‐ All rights reserved

Introduction
The first three parts of ISO 15118 describe the use cases and the technical specification of the Vehicle‐
to‐Grid Communication Interface which is intended for the optimized use of energy resources so that
electric road vehicles can recharge in the most economic or most energy efficient way. It is furthermore
required to develop efficient and convenient billing systems in order to cover the resulting micro‐
payments. The necessary communication channel may serve in the future to contribute to the
stabilization of the electrical grid as well as to support additional information services required to
operate electric vehicles efficiently and economically.
The complexity resulting from the network and application protocol requirements defined in the
second part of the standard requires a considerable amount of testing in order to enable
interoperability between independent implementations. This document therefore defines a
conformance test suite for the network and application layer protocols in order to derive a common and
agreed basis for conformance tests. The resulting test suite is a necessary 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 part two only.
viii
© ISO 2018 ‐ All rights reserved

INTERNATIONAL STANDARD ISO 15118-4:2018(E)
Road vehicles — Vehicle to grid communication interface —
Part 4: Network and application protocol conformance test
1 Scope
This document specifies conformance tests in the form of an Abstract Test Suite (ATS) for a System
Under Test (SUT) implementing an EVCC or SECC according to ISO 15118‐2. These conformance tests
specify the testing of capabilities and behaviors of an SUT as well as checking what is observed against
the conformance requirements specified in ISO 15118‐2 and against what the supplier 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‐2. The behavior tests of the ATS
examine an implementation as thoroughly as is practical over the full range of dynamic conformance
requirements defined in ISO 15118‐2 and within the capabilities of the SUT (see NOTE).
A test architecture is described in correspondence to the ATS. The conformance test cases in this
document are described leveraging this test architecture and are specified in TTCN‐3 Core Language for
ISO/OSI Network Layer (Layer 3) and above. The conformance test cases for the Data Link Layer (Layer
2) and Physical Layer (Layer 1) are described in ISO 15118‐5. Test cases with overlapping scopes are
explicitly detailed.
This document does not include specific tests of other standards referenced within ISO 15118‐2, e.g.
IETF RFCs. 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 test cases defined in this document only consider the communication protocol defined ISO 15118‐2.
Power flow between the EVSE and the EV is not considered.
NOTE 1 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. What it does do is give
confidence that an implementation has the required capabilities and that its behavior conforms consistently in
representative instances of communication.
NOTE 2 This document has some interdependencies to the conformance tests defined in ISO 15118‐5 which
result from ISO/OSI cross layer dependencies in the underlying protocol specification (e.g. for sleep mode)
© ISO 2018 ‐ All rights reserved

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.
IEC 61851‐1:2017, Electric vehicle conductive charging system — Part 1: General requirements
ISO 15118‐1:2013, Road vehicles — Vehicle to grid communication interface — Part 1: General
information and use-case definition
ISO 15118‐2:2014, Road vehicles — Vehicle-to-Grid Communication Interface — Part 2: Network and
application protocol requirements
ISO 15118‐3:2015, Road vehicles — Vehicle-to-Grid Communication Interface — Part 3: Physical and data
link layer requirements
ETSI ES 201 873‐5 V4.6.1, TTCN-3: TTCN-3 Runtime Interface (June 2014)
ETSI ES 201 873‐6 V4.6.1, TTCN-3: TTCN-3 Control Interface (June 2014)
NOTE 1 Even though the technical specification ISO 15118‐2:2014, which is the baseline for this conformance
test document, explicitly references IEC 61851‐1:2011, this document references IEC 61851‐1:2017 because of
applicability on the market.
3 Terms and definitions
For the purpose of this document, the terms and definitions given in ISO 15118‐1, ISO 15118‐2,
ISO 15118‐3 and the following apply.
ISO and IEC maintain terminological databases for use in standardization at the following addresses:
— IEC Electropedia: available at http://www.electropedia.org/
— ISO Online browsing platform: available at https://www.iso.org/obp
3.1
abstract test case
complete and independent specification of the actions required to achieve a specific test purpose
Note 1 to entry: This specification is 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 may involve one or more consecutive or
concurrent connections.
Note 2 to entry: The specification should be complete in the sense that it is sufficient to enable a test verdict to be
assigned unambiguously to each potentially observable test outcome (i.e. sequence of test events).
Note 3 to entry: The specification should be independent in the sense that it should be possible to execute the
derived executable test case in isolation from other such test cases (i.e. the specification should always include the
possibility of starting and finishing in the “idle” state).
Note 4 to entry: Compare with ITU‐T X.290.
3.2
abstract test suite
ATS
test suite composed of abstract test cases
Note 1 to entry: Compare with ITU‐T X.290.
© ISO 2018 ‐ All rights reserved

3.3
black box testing
method of testing that examines the behavior of an SUT without considering the internal
implementation and structure of the SUT, thus relying on the SUT's open interface for testing
3.4
conformance requirements
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 behavior 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 ISO 15118‐4 conformance tests include
requirements and transfer syntax requirements as far as they can be validated by black box testing.
Note 2 to entry: See also static conformance requirements and dynamic conformance requirements.
3.5
conforming implementation
IUT which satisfies both static and dynamic conformance requirements, consistent with the capabilities
stated in the PICS(s)
Note 1 to entry: Compare with ITU‐T X.290.
3.6
dynamic conformance requirements
one of the requirements which specifies what observable behavior 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‐2.
Note 2 to entry: Compare with ITU‐T X.290.
3.7
executable test case
realization of an abstract test case
Note 1 to entry: Compare with ITU‐T X.290.
3.8
expected behavior
exact response of the SUT according to the underlying protocol specification to the stimulus defined in
the test behavior
3.9
implementation conformance statement
ICS
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‐2.
Note 2 to entry: Compare with ITU‐T X.290.
3.10
implementation extra information for testing
IXIT
© ISO 2018 ‐ All rights reserved

statement made by a supplier or implementer of an IUT which contains or references all of the
information (in addition to that given in the ICS) related to the IUT and its testing environment, which
will enable the test laboratory to run an appropriate test suite against the IUT
Note 1 to entry: Compare with ITU‐T X.290.
3.11
implementation under test
IUT
implementation of one or more OSI protocols in an adjacent user/provider relationship, being that part
of a real open system which is to be studied by testing
Note 1 to entry: Compare with ITU‐T X.290.
3.12
main test component
MTC
single test component in a test component configuration responsible for creating and controlling
parallel test components and computing and assigning the test verdict
Note 1 to entry: Compare with ITU‐T X.290.
3.13
parallel test component
PTC
test component created by the main test component
Note 1 to entry: Compare with ITU‐T X.292.
3.14
post-condition
test steps needed to define the path from the end of the test behavior up to the finishing stable state for
the test case
Note 1 to entry: See also Test behavior.
3.15
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 bevavior will start
Note 1 to entry: See also Test behavior.
3.16
protocol implementation conformance statements
PICS
ICS 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‐2.
Note 2 to entry: Compare with ITU‐T X.290.
3.17
protocol implementation extra information for testing
PIXIT
IXIT related to testing for conformance to a given protocol specification
© ISO 2018 ‐ All rights reserved

Note 1 to entry: The given protocol specification for this conformance specification is ISO 15118‐2.
Note 2 to entry: Compare with ITU‐T X.290.
3.18
runtime environment
environment that describes the operating system and corresponding platform requirements of a system
EXAMPLE Test system.
3.19
semantically invalid test behavior
SemITB
test steps where the test system sends stimuli to the SUT that are semantically invalid according to the
protocol requirements
Note 1 to entry: This type of test behavior is defined in this conformance standard and explicitly includes
requirements which define the appropriate error handling of the SUT.
3.20
static conformance requirements
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)
Note 1 to entry: Compare with ITU‐T X.290.
3.21
system under test
SUT
real open system in which the IUT resides
Note 1 to entry: Compare with ITU‐T X.290.
3.22
syntactically invalid test behavior
SynITB
test steps where the test system sends stimuli to the SUT that are syntactically invalid according to the
protocol requirements
Note 1 to entry: This type of test behavior is not defined in this conformance standard, see codec requirements.
3.23
test behavior
set of test steps (test body) which are essential in order to achieve the test purpose and assign verdicts
to the possible outcomes
3.24
test execution
interpretation or execution of an abstract test suite
Note 1 to entry: Conceptually, the TE can be decomposed into three interacting entities: an Executable Test Suite
(ETS), a Test Framework (TFW) and an optional internal Encoding/Decoding System (EDS) entity.
Note 2 to entry: See also ETSI ES 201 873‐5 V4.6.1.
3.25
test framework
TFW
© ISO 2018 ‐ All rights reserved

entity to perform all actions of test cases or functions
Note 1 to entry: The Test Framework interacts with the Test Management (TM), SUT Adaptor (SA) and Platform
Adaptor (PA) entities via Test Control Interface (TCI) and Test Runtime Interface (TRI) and additionally manages
the Executable Test Suite (ETS) and Encoding/Decoding System (EDS) entities. It initializes adaptors as well as
ETS and EDS entities. This entity performs all the actions necessary to properly start the execution of a test case or
function with parameters in the ETS entity. It queries the TM entity for module parameter values required by the
ETS and sends logging information to it. It also collects and resolves associated verdicts returned by the ETS
entity.
Note 2 to entry: See also ETSI ES 201 873‐5 V4.6.1.
Note 3 to entry: In this document, the Test Framework TTCN‐3 Runtime System (T3RTS) is used to explain a Test
Framework functionality.
3.26
test purpose
prose description of a well‐defined objective of testing, focusing on a single conformance requirement
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
Note 1 to entry: Compare with ITU‐T X.290.
3.27
test system
real system combining the test framework, abstract test suite, test execution and adapters as well as
codecs
Note 1 to entry: Typically also containing a common runtime environment based on an operating system.
3.28
test control interface
TCI
four interfaces that define the interaction of the TTCN‐3 Executable with the test management, the
coding and decoding, the test component handling and the logging in a test system
Note 1 to entry: Compare with ETSI ES 201 873‐6 V4.6.1.
3.29
test runtime interface
TRI
two interfaces that define the interaction of the TTCN‐3 Executable between the SUT and the Platform
Adapter (PA) and the System Adapter (SA) in a test system
Note 1 to entry: Compare with ETSI ES 201 873‐5 V4.6.1.
3.30
test system interface
TSI
test component that provides a mapping of the ports available in the (abstract) TTCN‐3 test system to
those offered by a real test system
Note 1 to entry: Compare with ETSI ES 201 873‐6 V4.6.1.
3.31
valid test behavior
VTB
© ISO 2018 ‐ All rights reserved

test steps where the test system sends stimuli to the SUT that are valid (syntactically and semantically)
according to the protocol requirements
Note 1 to entry: This type of test behavior is defined in this conformance document.
Note 2 to entry: The protocol requirements for this conformance specification are defined in ISO 15118‐2.
3.32
verdict
test verdict
statement of “pass”, “fail” or “inconclusive”, as specified in an abstract test case, concerning
conformance of an IUT with respect to that test case when it is executed
Note 1 to entry: Compare with ITU‐T X.290.
4 Symbols and abbreviated terms
For the purpose of this document, the following abbreviations apply.
ALM Application Layer Message
ATS Abstract Test Suite
BEV Battery Electric Vehicle
CA Certificate Authority
CPL Control Pilot Line
CRL Certificate Revocation List
DH Diffie Hellman
DER Distinguished Encoding Rules
ECDSA Elliptic Curve Digital Signature Algorithm
EDS Encoding/Decoding System
EIM External Identification Means
EMAID E‐Mobility Account Identifier
ETS Executable Test Suite
EV Electric Vehicle
EVCC Electric Vehicle Communication Controller
EVSE Electric Vehicle Supply Equipment
EXI Efficient XML Interchange
HAL Hardware Abstraction Layer
ICS Implementation Conformance Statement
ID(s) Identifier(s)
ITB Invalid Test Behavior
IUT Implementation under Test
IXIT Implementation eXtra Information for Testing
OCSP Online Certificate Status Protocol
OEM Original Equipment Manufacturer
© ISO 2018 ‐ All rights reserved

MTC Main Test Component
NACK Negative Acknowledgement
PDU Protocol Data Unit
PICS Protocol Implementation Conformance Statement
PIXIT Protocol Implementation eXtra Information for Testing
PKI Public Key Infrastructure
PLC Power Line Communication
PnC Plug and Charge
PTC Parallel Test Component
PWM Pulse‐Width Modulation
SA Secondary Actor
SDP SECC Discovery Protocol
SECC Supply Equipment Communication Controller
SLAC Signal Level Attenuation Characterization
SUT System Under Test
TC Test Case
TCI Test Control Interface
TCP Transmission Control Protocol
TE Test Execution
TFW Test Framework
TP Test Purpose
TRI Test Runtime Interface
TSI Test System Interface
TSS Test Suite Structure
TTCN‐3 Testing and Test Control Notation version 3
V2G Vehicle‐to‐Grid
V2G CI V2G Communication Interface
V2GTP V2G Transfer Proto
...

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...