ISO 15118-2:2014

Road vehicles - Vehicle-to-Grid Communication Interface - Part 2: Network and application protocol requirements

ISO 15118-2:2014 specifies the communication between battery electric vehicles (BEV) or plug-in hybrid electric vehicles (PHEV) and the Electric Vehicle Supply Equipment. The application layer message set defined in ISO 15118-2:2014 is designed to support the energy transfer from an EVSE to an EV. ISO 15118-1 contains additional use case elements describing the bidirectional energy transfer. The implementation of these use cases requires enhancements of the application layer message set defined herein. The purpose of ISO 15118-2:2014 is to detail the communication between an EV (BEV or a PHEV) and an EVSE. Aspects are specified to detect a vehicle in a communication network and enable an Internet Protocol (IP) based communication between EVCC and SECC. ISO 15118-2:2014 defines messages, data model, XML/EXI based data representation format, usage of V2GTP, TLS, TCP and IPv6. In addition, it describes how data link layer services can be accessed from a layer 3 perspective. The Data Link Layer and Physical Layer functionality is described in ISO 15118-3.

Véhicules routiers — Interface de communication entre véhicule et réseau électrique — Partie 2: Exigences du protocole d'application et du réseau

Le présent document spécifie la communication entre les véhicules électriques à batterie (VEB) ou les véhicules électriques hybrides rechargeables (VEHR) et l'infrastructure de recharge pour véhicules électriques. L'ensemble de messages de la couche application défini dans le présent document est conçu pour prendre en charge le transfert d'énergie entre une IRVE et un VE. L'ISO 15118-1 contient des éléments de cas d'utilisation supplémentaires (ID des éléments de cas d'utilisation de la Partie 1 : F4 et F5) décrivant le transfert d'énergie bidirectionnel. L'implémentation de ces cas d'utilisation nécessite des améliorations de l'ensemble de messages de la couche application défini dans le présent document. Les définitions de ces exigences supplémentaires feront l'objet de la prochaine révision du présent document. Le présent document a pour but de décrire de manière détaillée la communication entre un VE (VEB ou VEHR) et une IRVE. Les aspects spécifiés permettent de détecter un véhicule dans un réseau de communication, et de permettre une communication basée sur le protocole Internet (IP) entre le contrôleur de communication du véhicule électrique (EVCC) et le contrôleur de communication de l'infrastructure de recharge (SECC). Le présent document définit les messages, le modèle de données, le format de représentation de données basé sur XML/EXI, l'utilisation de V2GTP, TLS, TCP et IPv6. De plus, il décrit comment accéder aux services de la couche liaison de données à partir de la couche 3. La fonctionnalité de la couche liaison de données et de la couche physique est décrite dans l'ISO 15118-3.

General Information

• Status: Published
• Publication Date: 30-Mar-2014
• ICS: 43.120 - Electric road vehicles
• Technical Committee: ISO/TC 22/SC 31 - Data communication
• Drafting Committee: ISO/TC 22/SC 31/JWG 1 - Joint ISO/TC 22/SC 31 - IEC/TC 69 WG: Vehicle to grid communication interface (V2G CI)
• Current Stage: 9092 - International Standard to be revised
• Start Date: 21-Jan-2025
• Completion Date: 30-Oct-2025

Overview

ISO 15118-2:2014 - "Road vehicles - Vehicle-to-Grid Communication Interface - Part 2" defines the network and application protocol requirements for secure, IP-based communication between an electric vehicle (BEV or PHEV) and Electric Vehicle Supply Equipment (EVSE). The part details the application-layer message set, data model and representation (XML / EXI), the V2G Transfer Protocol (V2GTP), and use of standard Internet protocols such as IPv6, TCP and TLS to enable reliable and secure charging sessions. Physical and data link functions are covered separately in ISO 15118-3; Part 1 provides general use cases (including bidirectional energy transfer).

Key technical topics and requirements

• Application-layer message set and data model: Defines message types, sequencing, timing, error handling and complex data types to support charging sessions and identification modes (e.g., Plug & Charge).
• Data representation: XML and Efficient XML Interchange (EXI) formats for compact, interoperable message encoding.
• Network protocols: Specification of IPv6 addressing, TCP transport and the V2G Transfer Protocol (V2GTP) for EVCC–SECC communication.
• Security and certificates: Use of TLS (RFC-based, TLS 1.2 referenced), XML Signatures, X.509 certificate profiles, OCSP and related cryptographic profiles to authenticate parties, protect message integrity and support secure billing/contract verification.
• Layered architecture & data link access: Defines how layer‑3 IP services access data link layer functionality and outlines V2G communication states and timers (e.g., session setup and data-link setup).
• Normative references and compliance: Integrates multiple IETF, W3C, NIST and IEC normative references (e.g., RFCs for IPv6, TCP, TLS; EXI and XML Signature standards; IEC 61851 charging interfaces).

Practical applications and who uses this standard

ISO 15118-2 is essential for:

• EV manufacturers (OEMs) implementing EV communication controllers (EVCC) and Plug & Charge features.
• EVSE and charging-station manufacturers implementing SECC stacks and secure onboarding.
• Charging network operators and utilities integrating secure authentication, billing and energy-management functions.
• Software developers & system integrators building V2G-compliant middleware, back-end servers and certificate management systems.
• Security engineers and conformance testers validating TLS, XML signatures, certificate profiles and message sequencing. Practical uses include secure automated charging (Plug & Charge), optimized charging schedules, integration with smart grids and future vehicle-to-grid services (bidirectional charging requires extensions described in Part 1 and future revisions).

Related standards

• ISO 15118-1: General information and use-case definitions (includes bidirectional use cases)
• ISO 15118-3: Physical and data link layer requirements
• IEC 61851 and IEC 62196: Charging system and connector standards
• Relevant IETF/W3C/NIST documents (IPv6, TLS, EXI, XML Signature, X.509/OCSP)

Keywords: ISO 15118-2, vehicle-to-grid, V2G, EVSE, EVCC, SECC, Plug and Charge, V2GTP, XML/EXI, TLS, IPv6, charging session, certificate profile.

Standards Content (Sample)

DRAFT INTERNATIONAL STANDARD ISO/IEC DIS 15118-2
ISO/IEC TC 22/SC3 Secretariat: DIN

Voting begins on Voting terminates on
2012-05-18 2012-10-18
INTERNATIONAL ORGANIZATION FOR STANDARDIZATION  МЕЖДУНАРОДНАЯ ОРГАНИЗАЦИЯ ПО СТАНДАРТИЗАЦИИ  ORGANISATION INTERNATIONALE DE NORMALISATION
INTERNATIONAL ELECTROTECHNICAL COMMISSION  МЕЖДУНАРОДНАЯ ЭЛЕКТРОТЕХНИЧЕСКАЯ КОММИСИЯ  COMMISSION ÉLECTROTECHNIQUE INTERNATIONALE

Road vehicles — Vehicle to grid communication interface —
Part 2:
Network and application protocol requirements
Véhicules routiers — Interface de communication entre véhicule et réseau électrique —
Partie 2: Exigences du protocole d'application et du réseau

ICS 43.120
To expedite distribution, this document is circulated as received from the committee
secretariat. ISO Central Secretariat work of editing and text composition will be undertaken at
publication stage.
Pour accélérer la distribution, le présent document est distribué tel qu'il est parvenu du
secrétariat du comité. Le travail de rédaction et de composition de texte sera effectué au
Secrétariat central de l'ISO au stade de publication.

THIS DOCUMENT IS A DRAFT CIRCULATED FOR COMMENT AND APPROVAL. IT IS THEREFORE SUBJECT TO CHANGE AND MAY NOT BE
REFERRED TO AS AN INTERNATIONAL STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS BEING ACCEPTABLE FOR INDUSTRIAL, TECHNOLOGICAL, COMMERCIAL AND USER PURPOSES,
DRAFT INTERNATIONAL STANDARDS MAY ON OCCASION HAVE TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL TO BECOME
STANDARDS TO WHICH REFERENCE MAY BE MADE IN NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT, WITH THEIR COMMENTS, NOTIFICATION OF ANY RELEVANT PATENT RIGHTS OF WHICH
THEY ARE AWARE AND TO PROVIDE SUPPORTING DOCUMENTATION.
International Organization for Standardization, 2012
©
International Electrotechnical Commission, 2012

ISO/IEC DIS 15118-2
Copyright notice
This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as permitted
under the applicable laws of the user's country, neither this ISO draft nor any extract from it may be
reproduced, stored in a retrieval system or transmitted in any form or by any means, electronic,
photocopying, recording or otherwise, without prior written permission being secured.
Requests for permission to reproduce should be addressed to either ISO at the address below or ISO's
member body in the country of the requester.
ISO copyright office
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO/IEC 2012 — All rights reserved

ISO/IEC DIS 15118-2
Contents Page
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 3
4 Symbols and abbreviated terms . 5
5 Conventions . 7
5.1 Definition of OSI based services . 7
5.2 Requirement structure . 7
5.3 Usage of RFC references . 7
5.4 Notation used for XML schema diagrams . 7
6 Document overview . 7
7 Basic requirements for V2G Communication . 9
7.1 General information . 9
7.2 Service primitive concept of OSI layered architecture . 9
7.3 Security concept . 10
7.4 V2G communication states . 16
7.5 Data Link Layer . 19
7.6 Network Layer . 20
7.7 Transport Layer . 22
7.8 V2G Transfer Protocol . 26
7.9 Presentation Layer . 29
7.10 Application Layer . 36
8 Application Layer messages . 44
8.1 General information and definitions . 44
8.2 Protocol handshake definition . 45
8.3 V2G Message Definition . 48
8.4 BodyElement Definitions . 51
8.5 Complex Data Types . 85
8.6 Identification modes and message set definitions . 114
8.7 V2G Communication Timing . 142
8.8 Message Sequencing and Error Handling . 149
8.9 Request-Response Message Sequence Examples . 171
Annex A (informative) Mapping of Part 1 use case elements . 180
A.1 Relation of Identification modes and Use Case Elements . 180
Annex B (informative) Mapping of ISO/IEC 15118 message element names to SAE J2847-2 terms . 186
B.1 SAE J2847-2 Status Codes . 186
B.2 SAE J2847-2 Energy Transfer Types . 187
B.3 SAE J2847-2 Signals . 188
Annex C (normative) Schema definition . 191
C.1 Overview . 191
C.2 V2G_CI_AppProtocol.xsd . 191
C.3 V2G_CI_MsgDef.xsd . 192
C.4 V2G_CI_MsgHeader.xsd . 193
C.5 V2G_CI_MsgBody.xsd . 193
C.6 V2G_CI_MsgDataTypes.xsd . 200
C.7 xmldsig-core-schema.xsd . 209
Annex D (informative) Message examples . 214
D.1 Value Added Service selection . 214
D.2 EXI encoded message examples . 216
© ISO/IEC 2012 – All rights reserved iii

ISO/IEC DIS 15118-2
D.3 Schedules and Tariff Information. 218
Annex E (informative) Application of certificates . 226
E.1 General . 226
E.2 Requirements of the OEM . 226
E.3 Requirements of the Secondary Actors . 227
E.4 Decisions . 228
E.5 Overview of the resulting Certificate Structure . 229
Annex F (informative) Security appliances and their associated certificates . 231
Annex G (informative) Simplified Certificate Management in Trusted Environment . 233
G.1 Overview (Motivation) . 233
G.2 Solution for private environments . 233
Annex H (informative) Certificate profiles . 236
Annex I (normative) Using Contract Certificates for XML encryption .1
I.1 Overview .1
I.2 Proposal .2
Annex J (informative) Use of OEM Provisioning Certificates .5
Annex K (informative) Summary of Requirements .8

iv © ISO/IEC 2012 – All rights reserved

ISO/IEC DIS 15118-2
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.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
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.
ISO/IEC 15118-2 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,
Electrical and electronique equipment.
ISO/IEC 15118 consists of the following parts, under the general title Road vehicles — Vehicle-to-Grid
Communication Interface:
 Part 1: General information and use-case definition
 Part 2: Network and application protocol requirements
 Part 3: Physical layer and Data Link layer requirements
© ISO/IEC 2012 – All rights reserved v

ISO/IEC DIS 15118-2
Introduction
The pending energy crisis and necessity to reduce greenhouse gas emissions has led the vehicle
manufacturers to a very significant effort to reduce the energy consumption of their vehicles. They are
presently developing vehicles partly or completed propelled by electric energy. Those vehicles will reduce the
dependency on oil, improve the global energy efficiency and reduce the total CO emissions for road
transportation if the electricity is produced from renewable sources. To charge the batteries of such vehicles,
specific charging infra-structure is required.
Much of the standardization work on dimensional and electrical specifications of the charging infrastructure
and the vehicle interface is already treated in the relevant ISO or IEC groups. However the question of
information transfer between the EV and the EVSE has not been treated sufficiently.
Such communication is necessary for the optimization of energy resources and energy production systems so
that vehicles can recharge in the most economic or most energy efficient way. It is also 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.
vi © ISO/IEC 2012 – All rights reserved

DRAFT INTERNATIONAL STANDARD ISO/IEC DIS 15118-2

Road vehicles — Vehicle-to-Grid Communication Interface —
Part 2: Network and application protocol requirements
1 Scope
This International Standard specifies the communication between battery electric vehicles (BEV) or plug-in
hybrid electric vehicles (PHEV) and the Electric Vehicle Supply Equipment. The application layer message set
defined in this Part of ISO/IEC 15118 is designed to support the energy transfer from an EVSE to an EV.
Part 1 contains additional use case elements (Part 1 Use Case Element IDs: F4 and F5) describing the
bidirectional energy transfer. The implementation of these use cases requires enhancements of the
application layer message set defined herein. The definitions of these additional requirements will be subject
of the next revision of this standard.
The purpose of this Part of ISO/IEC 15118 is to detail the communication between an EV (BEV or a PHEV)
and an EVSE. Aspects are specified to detect a vehicle in a communication network and enable an Internet
Protocol (IP) based communication between EVCC and SECC.
1 2
Communication Controller of Communication Controller of
Secondary Actor (SA)
Electric Vehicle (EVCC) Supply Equipment (SECC)

Key
1 Scope of this Part of ISO/IEC DIS 15118-2
2 Message definition considers use cases defined for communication between SECC to SA
Figure 1 — Communication relationship between EVCC SECC, and Secondary Actor
This part defines messages, data model, XML/EXI based data representation format, usage of V2GTP, TLS,
TCP and IPv6. In addition the document describes how data link layer services can be accessed from a layer
3 perspective. The Data Link Layer and Physical Layer functionality is described in Part 3 of this standard.
2 Normative references
The following referenced documents are required for the application 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, Electric vehicle conductive charging system ― Part 1: General requirements
SAE J1772, SAE Electric Vehicle and Plug in Hybrid Electric Vehicle Conductive Charge Coupler
IEC 62196, Plugs, socket-outlets, vehicle connectors and vehicle inlets - Conductive charging of electric
vehicles
DIN 91286, Electric mobility –Schemes of identifiers for E-Roaming –Contract ID and Electric Vehicle Supply
Equipment ID
W3C EXI 1.0, Efficient XML Interchange (EXI) Format 1.0, W3C Recommendation (March 2011)
IETF RFC 768, User Datagram Protocol (August 1980)
© ISO/IEC 2012 – All rights reserved 1

ISO/IEC DIS 15118-2
IETF RFC 793, Transmission Control Protocol - DARPA Internet Program - Protocol Specification (September
1981)
IETF RFC 1323, TCP Extensions for High Performance (Mai 1992)
IETF RFC 1624, Computation of the Internet Checksum via Incremental Update (Mai 1994)
IETF RFC 1981, Path MTU Discovery for IP version 6 (August 1996)
IETF RFC 2018, TCP Selective Acknowledgment Options (October 1996)
IETF RFC 2460, Internet Protocol, Version 6 (IPv6) Specification (December 1998)
IETF RFC 2560, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (June
1999)
IETF RFC 3122, Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (June 2001)
IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (July 2003)
IETF RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6) (February 2003)
IETF RFC 3782, The NewReno Modification to TCP's Fast Recovery Algorithm (April 2004)
IETF RFC 4291, IP Version 6 Addressing Architecture (February 2006)
IETF RFC 4429, Optimistic Duplicate Address Detection (DAD) for IPv6 (April 2006)
IETF RFC 4443, Internet Control Message Protocol (ICMP v6) for the Internet Protocol version 6 (IPv6)
specification (March 2006)
IETF RFC 4861, Neighbor Discovery for IP version 6 (IPv6) (September 2007)
IETF RFC 4862, IPv6 Stateless Address Autoconfiguration (September 2007)
IETF RFC 5095, Deprecation of Type 0 Routing Headers in IPv6 (December 2007)
IETF RFC 5116, An Interface and Algorithms for Authenticated Encryption (January 2008)
IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2 (August 2008)
IETF RFC 5289, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
(August 2008)
IETF RFC 5482, TCP User Timeout Option (March 2009)
IETF RFC 5681, TCP Congestion Control (September 2009)
IETF RFC 5722, Handling of Overlapping IPv6 Fragments (December 2009)
IETF RFC 6066, Transport Layer Security (TLS) Extensions: Extension Definitions (January 2011)
IETF RFC 6106, IPv6 Router Advertisement Options for DNS Configuration (November 2010)
IETF RFC 6298, Computing TCP's Retransmission Timer (June 2011)
IETF RFC 6335, Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service
Name and Transfer Protocol Port Number Registry (August 2011)
ISO/IEC DIS 15118-2
IANA Service&PortRegistry, Service Name and Transport Protocol Port Number Registry [viewed 2011-01-
16], Available from: numbers.xml>
3 Terms and definitions
For the purpose of this document, the following terms and definitions apply in addition to the terms and
definitions given in Part 1.
3.1
Communication Setup Timer
A Timer monitoring the time from plug-in until the Session Setup message.
3.2
Contract Certificate
Certificate issued to EVCC either by V2G Root CA or by Sub CA, which is used in XML Signatures in
application layer so that SECC or Secondary Actor can verify the Contract issued to the EVCC and signatures
issued by the EVCC.
3.3
Credentials
anything that provides the basis for confidence, belief, credit, etc.
EXAMPLE Examples include certificates, passwords, user names and so on
3.4
DER/PEM
DER (Distinguished Encoding Rules = ASN-1 encoding rule) is a method for encoding a data object, such as
an X.509 certificate, to be digitally signed or to have its signature verified. X.509 certificate files encode in
DER are binary files, which can not be used with XML unless they are Base64 encoded.
PEM (Privacy Enhanced Mail) Encoding (Base64 encoding) is a commonly used encoding schema for X.509
certificate files. The full specification of DER/PEM is in IETF RFC 1421.
3.5
Global address
IP address with unlimited scope
3.6
Link-local address
IP address with link-only scope that can be used to reach neighboring nodes attached to the same link
3.7
(IP)-Address
IP-layer identifier for an interface or a set of interfaces
3.8
Maximum Transfer Unit (MTU)
maximum size of the Data Link Layer that can be used for the IP Layer
3.9
Message Set
A set of mandatory V2G messages and parameters for the EVCC or SECC covering one or multiple use case
elements
3.10
Message Timer
A Timer monitoring the exchange of a Request-Response-Pair.
© ISO/IEC 2012 – All rights reserved 3

ISO/IEC DIS 15118-2
3.11
Network segment
collection of devices that can exchange data on Data Link Layer level directly via Data Link Addresses
EXAMPLE Ethernet: all devices which can see each other via MAC adresses.
3.12
node
a device that implements IPv6
3.13
Performance Time
A non-functional timing requirement defining the time a V2G Entity shall not exceed when executing or
processing certain functionality. This is a fixed time value.
3.14
Profile
A group of mandatory and optional Message Sets covering a set of similar charging scenarios for a specific
identification means.
3.15
Ready to Charge Timer
A Timer monitoring the time from plug-in until the first Power Delivery message.
3.16
Ready to Charge Time
A device or piece of software used in an implementation for measuring time. Depending on the specific use
case a timer is used to trigger certain system events as well.
3.17
Request-Response Message Pair
A request message and the corresponding response message.
3.18
Request-Response Message Sequence
A Sequence of multiple Request-Response Message Pairs.
3.19
SDP Client
A V2G entity that uses the SDP server to get configuration information about the SECC to be able to access
the SECC.
3.20
SDP Server
A V2G entity providing configuration information for accessing the SECC.
3.21
SECC Certificate
Certificate issued to SECC either by V2G Root CA or by Sub CA, which is used in TLS so that EVCC can
verify the authenticity of EVCC.
3.22
Sequence Timer
A Timer monitoring a Request-Response Message Sequence
3.23
Sub-CA
Subordinate certificate authority who issues SECC certificates and/or Contract certificates on behalf of the
V2G Root CA.
ISO/IEC DIS 15118-2
NOTE The ability of issuing the certificates are delegated from V2G Root CA, and V2G Root CA can revoke the sub
CA at any time.
3.24
Sub CA Certificate
Certificate issued to Sub CA.
3.25
TCP_DATA
Socket/interface for data transfer based on TCP conncetion
3.26
Timeout
A timing requirement defining the time a V2G Entity monitors the communication system for a certain event to
occur. If the specified time is exceeded the respective V2G Entity initiates the related error handling. This is a
fixed time value.
3.27
Timer
A device or piece of software used in an implementation for measuring time. Depending on the specific use
case a timer is used to trigger certain system events as well.
3.28
Trusted Environment
Closed user group (e. g. members of car sharing system) with some pre-distributed token for access to the
SECC charging service (e.g. key to home garage, RFID token for car sharing). Trusted environment is
something where a person or instance is responsible for. Responsibility lies for example (not limited to) at a
person with its home garage, a car sharing operator or a taxi operator.
3.29
V2G Communication Session
association of two specific V2G entities for exchanging V2G messages
3.30
V2G Entity
primary actor participating in the V2G communication using a mandatory or optional transmission protocol
defined by this part of ISO/IEC 15118
3.31
V2G Message
message exchanged on application layer (refer to clause 8 Application Layer messages)
3.32
V2GTP Entity
V2G entity supporting the V2G Transfer Protocol
3.33
V2GTP Root CA
Certificate Authority (CA) who issues Contract Certificates and/or SECC Certificates, or who delegates ability
to issue such Certificates to Sub CA.
4 Symbols and abbreviated terms
For the purposes of this document, the following abbreviations apply:
BEV Battery Electric Vehicle
CA Certificate Authority
© ISO/IEC 2012 – All rights reserved 5

ISO/IEC DIS 15118-2
CRL Certificate Revocation List
DH Diffie Hellman
DER Distinguished Encoding Rules
ECDSA Elliptic Curve Digital Signature Algorithm
EV Electric Vehicle
EVCC Electric Vehicle Communication Controller
EVSE Electric Vehicle Supply Equipment
EXI Efficient XML Interchange
OCSP Online Certificate Status Protocol
OEM Original Equipment Manufacturer
NACK Negative Acknowledgement
PDU Protocol Data Unit
PEM Privacy Enhanced Mail
PHEV Plug-in Hybrid Vehicle
PKI Public Key Infrastructure
PLC Power Line Communication
PnC Plug and Charge
SA Secondary Actor
SAML Security Assertions Markup Language
SDP SECC Discovery Protocol
SDU Service Data Unit
SECC Supply Equipment Communication Controller
TCP Transmission Control Protocol
V2G Vehicle to Grid Communication
V2G CI Vehicle-to-Grid Communication Interface
V2GTP V2G Transfer Protocol
V2GTPPT_EXI V2G Transfer Protocol Payload Type for EXI messages
UDP User Datagram Protocol
UML Unified Modeling Language
XML Extensible Markup Language
ISO/IEC DIS 15118-2
5 Conventions
5.1 Definition of OSI based services
ISO/IEC°15118-2 is based on the conventions discussed in the OSI Service Conventions (refer to ISO 10731)
as they apply for the individual layers specified in this document.
This part of ISO/IEC°15118-2 describes requirements applicable to layer 3-7 according to the OSI layered
architecture.
5.2 Requirement structure
This document uses a requirement structure i.e. a unique number identifies each individual requirement
included in this document. This requirement structure allows for easier requirement tracking and test case
specification. The following format is used:
"[V2G"Y"-"XXX"]" requirement text Where:
 "V2G" represents the ISO/IEC°15118 set of standards,
 Y represents the document part of the ISO/IEC°15118 document set
 XXX represents the individual requirement number and
 "requirement text" includes the actual text of the requirement.
EXAMPLE [V2G2-000] This shall be an example requirement.
5.3 Usage of RFC references
When RFCs are referenced all “must/ must not” requirements are mandatory.
[V2G2-001] In this document, if a referenced RFC has been updated by one or several RFC, the update is
fully applicable.
[V2G2-002] If an update or part of an update applicable to an RFC referenced herein is not compatible with
the original RFC or the implementation described by this standard the update shall not apply.
[V2G2-003] All published Errata, for the ISO/IEC°15118 referenced RFCs, are fully applicable in this
standard.
5.4 Notation used for XML schema diagrams
This standard make use of XML as a description format for V2G messages. For details with regards to the
XML schema diagram notation used in this document refer to Altova XMLSpy Manual.
Allowing for an easy way to distinguish the types used for the XML schema definitions in this standard
following naming conventions apply:
 complex type use capitalized first letters
 simple types use non capitalized first letters
6 Document overview
Figure 2 describes the organization of the different ISO/IEC°15118 documents and the usage of the
subclauses , according to the OSI layered architecture.
© ISO/IEC 2012 – All rights reserved 7

ISO/IEC DIS 15118-2
As indicated by the blue coloured shapes this Part of ISO/IEC°15118 defines requirements applicable to
layers 3-7 according to the OSI layered archictecture. Layer 1 and 2 requirements including the V2G
Standardized Service Primitive Interface are specified in Part 3 of this standard.
Vehicle to Grid Communication
ISO/IEC 15118-1
General information
and
use-case definition
Application Layer Messages (8)
OSI Layer 7
SDP(7.10.1)
Application
EXI (7.9)
OSI Layer 6
Presentation
ISO/IEC 15118-2
Technical
Protocol
description and
V2GTP (7.8)
OSI Layer 5
Open Systems
Session
Interconnections
(OSI) layer
requirements
TCP,UDP,TLS (7.7)
OSI Layer 4
Transport
IP,ICMP,SLAAC (7.6)
OSI Layer 3
Network
V2G Standardized Service Primitive Interface
OSI Layer 2
Data Link
ISO/IEC 15118-3
Physical layer and Data link layer requirements
OSI Layer 1
Physical
Key
OSI Layers and applicable requirements described in this Part of ISO/IEC°15118

OSI Layers and applicable requirements defined in other Parts of ISO/IEC°15118

Figure 2 — Vehicle to Grid Communication document overview
ISO/IEC DIS 15118-2
7 Basic requirements for V2G Communication
7.1 General information
This Part of ISO/IEC 15118 describes the realization of the V2G use cases elements defined by Part 1 of this
standard.
7.2 Service primitive concept of OSI layered architecture
7.2.1 Overview
This subclause explains how the OSI layered architecture is applied for the purpose of this document. It is
intended to provide simple means for describing the interfaces between the individual communication protocol
layers required by this document and furthermore allows for defining timing requirements more precisely.
Services are specified by describing the service primitives and parameters that characterize a service. This is
an abstract definition of services and does not force a particular implementation.
Figure 3 depicts a simplified view of OSI layer interaction sufficient to understand the OSI layered architecture
principles for the context of this document.
V2G entity m V2G entity m+1
Layer i+1 Layer i+1
Layer i+1 Layer i+1
request request
response response
data data
m m
data data
m+1 m+1
I-DATA.indication(i-SDU )
m
I-DATA.request(i-SDU )
m
Data
I-DATA.confirmation(i-SDU ) transmission I-DATA.response(i-SDU )
m+1 m+1
between peer
entities
i-PDU
m
i-PDU
m
i-PDU
m
[i-PCI+i-SDU]
[i-PCI+i-SDU]
i-PDU i-PDU
m+1 m+1
i-PDU
m+1
[i-PCI+i-SDU] [i-PCI+i-SDU]
Key
PDUX: Protocol Data Unit of network entity x
PCI: Protocol Control Information
SDU : Service Data Unit of network entity x
X
Figure 3 — OSI layered architecture principles
When a layer i+1 instance of V2G entity m exchanges data with a layer i+1 instance of V2G entity m+1 each
instance uses services of an instance of layer i. A service is defined as a set of service primitives.
7.2.2 Syntax of service primitives
Service primitives are described with the following syntax:
© ISO/IEC 2012 – All rights reserved 9

Layer i Layer i+1
ISO/IEC DIS 15118-2
[Initial of layer]-[NAME].[primitive type](parameter list)
 whereas [initial of layer] is one out of the following seven:
[Physical, Data Link, Network, Transport, Session, Presentation, Application]
 whereas [NAME] is the name of the primitive
EXAMPLE Typical examples for [Name] are CONNECT, DISCONNECT, DATA; other names are used in this Part
and Part 3 of this standard.
 whereas [primitive type] is one out of the following four:
[request, indication, response, confirmation]
 whereas (parameter list) includes a list of parameters separated by comma the user of the service is
supposed to provide when using the respective service primitive; optional parameters are marked with
brackets "[.]".
NOTE In this document, the primitive type ".indication" always indicates an event asynchronously to the upper layer.
7.3 Security concept
7.3.1 Call Flows (Flow Charts)
The following two figures (Figure 4 and Figure 5) depict the principal approach for the semi-online and the
online case from a security point of view, showing the necessary security services applied as well as an
abstract view on the different data necessary for the operation.
The full data flow / sequence charts can be found in subclause 8.8 of this document. In these overview figures
only the security relevant information shall be highlighted.
The security concept provides a basic transport based protection mechanism. For certain scenarios, the
usage of Transport Layer Security (TLS) for the transport communication between EVCC and SECC is
mandated. For some other scenarios, the usage of TLS is optional. Specific messages are protected on
application layer (XML-messages), if data has to be protected on the way from or to a secondary actor, or if
the protection has to last longer than the existence of the TLS channel. Also the concept is independent from
any further protection mechanisms on lower levels than layer 3 in the OSI layer model.
Figure 4 shows an example usecase for a semi-online connection for a plug-n-charge scenario:
In this Plug-and-Charge example, all TCP/IP based communication is protected using a unilateral
authenticated TLS channel between the two peers. (Note: TLS is not mandatory for certain Identification
modes other than the Plug-and-Charge Identification mode). All communication is terminated at the SECC.
The meter reading is cyclically signed by the vehicle to provide an agreement on the amount of electricity
delivered. This information may be used for billing if local regulations permit it. The EVSE provides the
charging records, containing the signed meter reading to the backend for further processing.
NOTE 1 The communication between SECC and SA in Figure 4 is shown for informational purpose only and not
intended to specify a particular message sequence.
ISO/IEC DIS 15118-2
EVCC SECC Secondary Actor (SA)
(semi-) offline exchange of security
credentials in advance
seq Begin of charging process
e.g. OCSP Responses, CRLs, certificates
(not in the scope of this specification)
seq Communication Setup
seq Establish IP-based Connection
seq Establish TLS Session
Client Hello()
Server Hello()
TLS Client Key /
Certificate needed
… continue according to subclause 7.7.3
TLS Root Certificate
needed
supportedAppProtocolReq()
supportedAppProtocolRes()
… continue according to subclause 8.8
seq Identification, Authentication and Authorization
PaymentDetailsReq()
Contract Signing Cert-
Chain needed
PaymentDetailsRes()
ContractAuthenticationReq()
Contract Signing - Key /
ContractAuthenticationRes()
Certificate needed Contract Root Certificate
needed
seq Target Setting and Charge Scheduling
… continue according to subclause 8.8
loop Charge control and Re-scheduling
ChargingStatusReq()
ChargingStatusRes()
opt Metering
MeteringReceiptReq()
Contract Signing Key /
MeteringReceiptRes()
Certificate needed
seq End of charging process
… finish according to subclause 8.8
seq Forward Receipt (PnC only)
Contract
Root
(semi-) offline exchange of signed
Certificate
meter receipt data for Plug'n Charge profile
needed
(outside scope of this specification)

Figure 4 — Example for semi-online communication (1 of 2)
© ISO/IEC 2012 – All rights reserved 11

ISO/IEC DIS 15118-2
Figure 5 shows an example for an online plug’n charge usecase:
As in the semi-online case, in this Plug-and-Charge example, all TCP/IP based communication is protected
using a unilateral authenticated TLS channel between the two peers. (Note: TLS is not mandatory for certain
identification modes other than the Plug-and-Charge identification mode). Some of the information provided by
the vehicle may need to be sent to the SA for further processing, like the contractID or the vehicles credentials
to be able so sign the tarif information. The EVCC calculates a charging profile (refer to subclause 8.4.1.9.2)
and sends it to the SECC. The SECC may send it to SA systems like Smart Grid or Demand Clearing House.
The further process is similar to the semi-online case with the exception, that the final charging data can be
directly submitted to the SA. It is assumed that the SECC will also use a secure transport connection to the
SA, although the security of the vehicle communication to the SA is secured on application layer.
NOTE 2 The communication between SECC and SA in Figure 5 is shown for informational purpose only and not
intended to specify a particular message sequence.
ISO/IEC DIS 15118-2
EVCC SECC Secondary Actor (SA)
seq Begin of charging process
seq Communication Setup
seq Establish IP-based Connection
seq Establish TLS Session
Client Hello()
Server Hello()
TLS Client Key /
... continue according to subclause 7.7.3 Certificate needed
TLS Root Certificate
needed
supportedAppProtocolReq()
supportedAppProtocolRes()
... continue according to subclause 8.8
seq Identification, Authentication and Authorization
Contract Signing Cert-
PaymentDetailsReq()
Chain needed
PaymentDetailsRes()
Contract Signing - Key /
ContractAuthenticationReq()
Certificate needed Contract Root Certificate
ContractAuthenticationRes() needed
seq Target Setting and Charge Scheduling
seq Request individual tariff tables
ChargeParameterDiscoveryReq()
Contract
Signature
ChargeParameterDiscoveryRes()
Certificate
Online request for individual tariff
tables for ContractID
... continue according to subclause 8.8
(outside socpe of this specification)
loop Charge control and Re-scheduling
ChargingStatusReq()
ChargingStatusRes()
opt Metering
MeteringReceiptReq()
MeteringReceiptRes()
Contract Signing Key /
Certificate needed
seq End of charging process
... finish according to subclause 8.8
seq Forward Receipt (PnC only)
Contract
Root
online exchange of signed
Certificate
meter receipt data for Plug'n Charge profile
needed
(outside scope of this specification)

Figure 5 — Example for online communication
© ISO/IEC 2012 – All rights reserved 13

ISO/IEC DIS 15118-2
There are further usecases where security mechanism are needed on application layer. These are the initial
enrollment of contract keys and certificate as well as the update of the certificate. In this case vehicle specific
OEM keys are used. Those mechanisms are described in Annex E. An overview on all needed certificates can
be found in Annex H.
7.3.2 Certificate and key management
The call flows shown in clause 7.3.1 require the existence of multiple certificates to be applied for the different
security layers. There are SECC certificates used in the TLS layer for EVCC to authenticate SECC.There are
Contract certificates used in the application layer for SECC and secondary actor to authenticate the contract
related to SECC. There are V2G root certificates and possibly sub certificates which certify SECC certificates
and Contract certificates.
Separate from above certificates, OEM may have OEM root certificates and OEM provisioning certificates to
be used for installing and updating Contract Certificates.
[V2G2-004] Each V2G entity shall use X.509v3 certificates due to the need of extensions for storing EC-
parameters. For details please refer to IETF RFC 5280.
Table 1 shows what fields a X.503v3-certificate consists of:
Table 1 — Basic Certificate Fields
Certificate field Description
Version Version of certificate (for 15118 shall be v3 = 0x2)
Serial number Unique number of certificate (within the domain of the issuer)
Signature algorithm Used signature algorithm
Issuer Entity, who has issued and signed the certificate
Validity period Time period, in which the certificate is valid
Subject Entity, to which the certificate is issued
Public key Public key corresponding to a private key
Issuer UID Optional issuer unique identifier
Subject UID Optional subject unique identifier
Extensions Optional (see Table 2)
Signature Signature of the certificate generated by the issuer

NOTE 1 For those not familiar with the various fields please refer to IETF RFC 5280.
Depending on the use case additional information may be included using so called certificate extensions.
Table 2 summarizes common certificate extensions.
ISO/IEC DIS 15118-2
Table 2 — Certificate extension examples
Certificate extensions Description
Usage of the corresponding private key (e.g. Digital Signature,
Key usage
Non-Repudiation, Key Encipherment, …)
Further specification of key usage using OIDs, e.g.:
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Note, sometimes here also the following values are encoded:
Netscape SGC (1.3.6.1.4.1.311.10.3.3)
Extended Key Usage
Microsoft SGC (2.16.840.1.113730.4.1)
SGC stands for Server Gated Crypto and indicated that the server
may also use strong cryptography for the connection with the
client’s browser. This extension was used at the time of strong
crypto export control to enable financial web site to provide
appropriate protection of the data transfer.
CRL distribution point Location to retrieve certificate revocation lists
OCSP Location to retrieve OCSP response (exists only for SubCA
certificates). Refer to IETF RFC 2560 for details.
Authority information Additional authorization information
Subject alternative name Alternative names of the entity
Basic constraint = CA True if the certificate is V2G Root Certificate or SubCA certificate.

NOTE 2 For those not familiar with OIDs, e.g 1.3.6.1.5.5.7.3.1, please refer to: Object Identifier (OID) Repository.
[V2G2-005] Each V2G entity shall support Hash-operation SHA-256 (signature process) according to NIST
FIPS PUB 180-3 (for Part 1 Use Case Element ID: F1).
[V2G2-006] For each V2G entity the Signature-operation shall be ECC-based using elliptic curves
(secp256r1[SECG notation]) with signature algorithm ECDSA (for Part 1 Use Case Element
ID: F1).
[V2G2-007] The Key length for ECC based asymmetric cryptography each V2G entity shall be 256 bit.
NOTE 3 For the time being ECC algorithms are not supported by the W3C XML digital signature specification. It is
expected that ECC will be supported for the FDIS of this standard. If final standard won’t be available, the latest re
...

INTERNATIONAL ISO
STANDARD 15118-2
First edition
2014-04-01
Road vehicles — Vehicle-to-Grid
Communication Interface —
Part 2:
Network and application protocol
requirements
Véhicules routiers — Interface de communication entre véhicule et
réseau électrique —
Partie 2: Exigences du protocole d'application et du réseau

Reference number
©
ISO 2014
©  ISO 2014
All rights reserved. Unless otherwise specified, 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
Case postale 56  CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Published in Switzerland
ii © ISO 2014 – All rights reserved

Contents Page
Foreword . v
Introduction . vi
1  Scope . 1
2  Normative references . 1
3  Terms and definitions . 3
4  Symbols and abbreviated terms . 7
5  Conventions . 8
5.1  Definition of OSI based services . 8
5.2  Requirement structure . 8
5.3  Usage of RFC references . 8
5.4  Notation used for XML schema diagrams . 9
6  Document overview . 9
7  Basic requirements for V2G communication . 11
7.1  General information . 11
7.2  Service primitive concept of OSI layered architecture . 11
7.3  Security concept . 12
7.4  V2G communication states and data link handling . 21
7.5  Data Link Layer . 26
7.6  Network Layer . 26
7.7  Transport Layer . 28
7.8  V2G Transfer Protocol . 32
7.9  Presentation Layer . 36
7.10  Application Layer . 46
8  Application Layer messages . 55
8.1  General information and definitions . 55
8.2  Protocol handshake definition . 56
8.3  V2G Message Definition . 60
8.4  V2G Communication Session and BodyElement Definitions . 62
8.5  Complex data types . 104
8.6  Identification Modes and Message Set definitions . 137
8.7  V2G communication timing . 170
8.8  Message sequencing and error handling . 184
8.9  Request-Response Message Sequence examples . 206
Annex A (informative) Mapping of Part 1 use case elements . 214
Annex B (informative) Mapping of ISO 15118 message element names to SAE J2847/2 terms . 250
Annex C (normative) Schema definition . 254
Annex D (informative) Message examples . 278
Annex E (informative) Application of certificates . 299
Annex F (normative) Certificate profiles . 313
Annex G (informative) Encryption for the Distribution of Secret Keys . 321
Annex H (normative) Specification of Identifiers . 323
Annex I (informative) Message sequencing for renegotiation . 326
Annex J (informative) Overview on XML Signatures . 330
Annex K (informative) Summary of requirements . 334
Bibliography . 341

iv © ISO 2014 – 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 meaning of ISO specific terms and expressions related to conformity assessment,
as well as information about ISO's adherence to the WTO principles in the Technical Barriers to Trade (TBT)
see the following URL: Foreword - Supplementary information
The committee responsible for this document is ISO/TC 22, Road vehicles, Subcommittee SC 3, Electrical
and electronic equipment.
ISO 15118-2 was developed in conjunction with IEC TC 69, Electric road vehicles and electric industrial
trucks.
ISO 15118 consists of the following parts, under the general title Road vehicles — Vehicle-to-Grid
Communication Interface:
 Part 1: General information and use-case definition
 Part 2: Network and application protocol requirements
 Part 3: Physical and data link layer requirements

To be published.
Introduction
The pending energy crisis and necessity to reduce greenhouse gas emissions has led the vehicle
manufacturers to a very significant effort to reduce the energy consumption of their vehicles. They are
presently developing vehicles partly or completely propelled by electric energy. Those vehicles will reduce the
dependency on oil, improve the global energy efficiency and reduce the total CO emissions for road
transportation if the electricity is produced from renewable sources. To charge the batteries of such vehicles,
specific charging infra-structure is required.
Much of the standardization work on dimensional and electrical specifications of the charging infrastructure
and the vehicle interface is already treated in the relevant ISO or IEC groups. However the question of
information transfer between the EV and the EVSE has not been treated sufficiently.
Such communication is necessary for the optimization of energy resources and energy production systems so
that vehicles can recharge in the most economical or most energy efficient way. It is also 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.
vi © ISO 2014 – All rights reserved

INTERNATIONAL STANDARD ISO 15118-2:2014(E)

Road vehicles — Vehicle-to-Grid Communication Interface —
Part 2: Network and application protocol requirements
1 Scope
This part of ISO 15118 specifies the communication between battery electric vehicles (BEV) or plug-in hybrid
electric vehicles (PHEV) and the Electric Vehicle Supply Equipment. The application layer message set
defined in this part of ISO 15118 is designed to support the energy transfer from an EVSE to an EV. ISO
15118-1 contains additional use case elements (Part 1 Use Case Element IDs: F4 and F5) describing the
bidirectional energy transfer. The implementation of these use cases requires enhancements of the
application layer message set defined herein. The definitions of these additional requirements will be subject
of the next revision of this International Standard.
The purpose of this part of ISO 15118 is to detail the communication between an EV (BEV or a PHEV) and an
EVSE. Aspects are specified to detect a vehicle in a communication network and enable an Internet Protocol
(IP) based communication between EVCC and SECC.

Key
1 Scope of ISO/IEC FDIS 15118-2:2013(E)
2 Message definition considers use cases defined for communication between SECC to SA
Figure 1 — Communication relationship among EVCC, SECC and secondary actor
This part of ISO 15118 defines messages, data model, XML/EXI based data representation format, usage of
V2GTP, TLS, TCP and IPv6. In addition, it describes how data link layer services can be accessed from a
layer 3 perspective. The Data Link Layer and Physical Layer functionality is described in ISO 15118-3.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions ― Part 1: Country
codes
ISO 15118-1, Road vehicles ― Vehicle to grid communication interface ― Part 1: General information and
use-case definition
IEC 61851-1, Electric vehicle conductive charging system ― Part 1: General requirements (Ed 2.0 2010)
IEC 61851-22, Electric vehicle conductive charging system - Part 22: AC electric vehicle charging station
IEC CDV 61851-23, Electric vehicle conductive charging system - Part 23: D.C. electric vehicle charging
station (Ed 1.0 2012)
IEC 62196, Plugs, socket-outlets, vehicle connectors and vehicle inlets - Conductive charging of electric
vehicles
W3C EXI 1.0, Efficient XML Interchange (EXI) Format 1.0, W3C Recommendation (March 2011)
W3C XML Signature Syntax and Processing Version 1.1, - W3C Recommendation (April 2013)
IETF RFC 768, User Datagram Protocol (August 1980)
IETF RFC 793, Transmission Control Protocol - DARPA Internet Program - Protocol Specification (September
1981)
IETF RFC 1981, Path MTU Discovery for IP version 6 (August 1996)
IETF RFC 2460, Internet Protocol, Version 6 (IPv6) Specification (December 1998)
IETF RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (June
2013)
IETF RFC 3122, Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (June 2001)
IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (July 2003)
IETF RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6) (February 2003)
IETF RFC 6582, The NewReno Modification to TCP's Fast Recovery Algorithm (April 2012)
IETF RFC 4291, IP Version 6 Addressing Architecture (February 2006)
IETF RFC 4429, Optimistic Duplicate Address Detection (DAD) for IPv6 (April 2006)
IETF RFC 4443, Internet Control Message Protocol (ICMP v6) for the Internet Protocol version 6 (IPv6)
specification (March 2006)
IETF RFC 4861, Neighbor Discovery for IP version 6 (IPv6) (September 2007)
IETF RFC 4862, IPv6 Stateless Address Autoconfiguration (September 2007)
IETF RFC 5095, Deprecation of Type 0 Routing Headers in IPv6 (December 2007)
IETF RFC 5116, An Interface and Algorithms for Authenticated Encryption (January 2008)
IETF RFC 5234, Augmented BNF for Syntax Specifications: ABNF (January 2008)
IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2 (August 2008)
IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile (May 2008)
IETF RFC 5289, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
(August 2008)
IETF RFC 5480, Elliptic Curve Cryptography Subject Public Key Information (March 2009)
IETF RFC 5722, Handling of Overlapping IPv6 Fragments (December 2009)
IETF RFC 6066, Transport Layer Security (TLS) Extensions: Extension Definitions (January 2011)
IETF RFC 6106, IPv6 Router Advertisement Options for DNS Configuration (November 2010)
IETF RFC 6961, The Transport Layer Security (TLS) Multiple Certificate Status Request Extension (June
2013)
2 © ISO 2014 – All rights reserved

IANA Service&PortRegistry, Service Name and Transport Protocol Port Number Registry [viewed 2011-01-
16], Available from: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-
numbers.xml
NIST FIPS PUB 180-4: Secure Hash Standard (SHS) (March 2012)
NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography (Revised) (March 2007)
NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation - Methods and
Techniques (2001)
3 Terms and definitions
For the purposes of this document, the terms in ISO 15118-1 and the following apply.
3.1
Basic Charging
BC
charging phase during a charging session controlled by IEC 61851-1 only
3.2
charging limits
set of physical constraints (e.g. voltage, current, energy, power) that is negotiated during a V2G
Communication Session for a charging session
3.3
Communication Setup Timer
Timer monitoring the time from plug-in until the Session Setup message
3.4
Contract Certificate
certificate issued to EVCC either by V2G Root CA or by Sub-CA, which is used in XML Signatures in
application layer so that SECC or secondary actor can verify the Contract issued to the EVCC and signatures
issued by the EVCC
3.5
CP State
Control Pilot (Vehicle) State according to IEC 61851-1 signalled on Control Pilot Line
3.6
credentials
anything that provides the basis for confidence, belief, credit, etc.
EXAMPLE Examples include certificates, passwords, user names etc.
3.7
Data Link Setup
setup phase for establishing the data link
Note 1 to entry: Entry Condition: Any valid control pilot signal according to IEC 61851-1; Exit Condition: D-
LINK_READY.indication(DLINKSTATUS=LinkEstablished).
3.8
Distinguished Encoding Rules = ASN-1 encoding rule
DER
method for encoding a data object, such as an X.509 certificate, to be digitally signed or to have its signature
verified
3.9
global address
IP address with unlimited scope
3.10
High Level Communication Charging
HLC-C
charging phase during a charging session controlled by ISO 15118
3.11
link-local address
IP address with link-only scope that can be used to reach neighbouring interfaces attached to the same link
3.12
Identification Mode
mandatory and optional messages and parameters with respect to charging scenarios using External
Identification Means (EIM) and charging scenarios using Plug and Charge (PnC) for identification
Note 1 to entry: An Identification Mode covers a set of similar charging scenarios for a specific identification means.
3.13
(IP) address
IP-layer identifier for an interface or a set of interfaces
3.14
Maximum Transfer Unit
MTU
maximum size (in bytes) of the largest protocol data unit that the Data Link Layer that can be pass onwards
3.15
Message Set
set of mandatory V2G messages and parameters for the EVCC or SECC covering one or multiple use case
elements
3.16
Message Timer
Timer monitoring the exchange of a Request-Response-Pair
3.17
network segment
collection of devices that can exchange data on Data Link Layer level directly via Data Link Addresses
EXAMPLE Ethernet: all devices which can see each other via MAC addresses.
3.18
node
device that implements IPv6
3.19
OEM Provisioning Certificate
certificate issued to the EVCC, so that a Contract Certificate can be securely requested and received from a
secondary actor
3.20
Performance Time
non-functional timing requirement defining the time a V2G Entity shall not exceed when executing or
processing certain functionality
Note 1 to entry: This is a fixed time value.
4 © ISO 2014 – All rights reserved

3.21
private environment
area with (physical) access limited to a small number of vehicles (EVs), which may be a private parking
garage or a garage / parking lot of a company with its own EV fleet, where one or several private wall-box(es)
are used instead of public charging stations as EVSE, and where in order to keep the private wall-box simple
and cheap in production and operation it is allowed to stay offline permanently, which allows a private wall-box
to use leaf certificates with a longer maximum validity than allowed for public charging stations and using a
private root certificate which is different to the V2G root certificates and which has to be installed into each EV
that is allowed to charge within this specific private environment, resulting in a limited number of EVs
belonging to one private environment, the difference to a “trusted environment” being that in a (pure; i.e. not
additionally “trusted”) private environment TLS and the corresponding data encryption at connection level is
always used, and solely certificate handling is simplified for the private wall-box (EVSE) since it may stay
offline permanently, resulting in unrestricted certificate validity periods, shorter certificate chain length, omitting
OCSP, and an additional “pairing mode”
3.22
Identification Mode
group of mandatory and optional Message Sets covering a set of similar charging scenarios for a specific
identification means
3.23
renegotiation
messaging for updating the agreement on the charging schedule between EV and EVSE during a V2G
Communication Session by retransmitting the parameters SASchedule and ChargingProfile
3.24
Request-Response Message Pair
request message and the corresponding response message
3.25
Request-Response Message Sequence
predefined sequence of Request-Response Message Pairs
3.26
SDP Client
V2G Entity that uses the SDP server to get configuration information about the SECC to be able to access the
SECC
3.27
SDP Server
V2G Entity providing configuration information for accessing the SECC
3.28
SECC Certificate
certificate issued to SECC either by V2G Root CA or by Sub-CA, which is used in TLS so that the EVCC can
verify the authenticity of the SECC
3.29
Sequence Timer
Timer monitoring a Request-Response Message Sequence
3.30
Sub-CA
subordinate certificate authority who issues SECC Certificates and/or Contract Certificates on behalf of the
V2G Root CA
Note 1 to entry: The ability of issuing the certificates are delegated from V2G Root CA, and V2G Root CA can revoke the
Sub-CA at any time.
3.31
Sub-CA Certificate
certificate issued to Sub-CA
3.32
TCP_DATA
socket/interface for data transfer based on TCP connection
3.33
Timeout
timing requirement defining the time a V2G Entity monitors the communication system for a certain event to
occur
Note 1 to entry: If the specified time is exceeded the respective V2G Entity initiates the related error handling. This is a
fixed time value.
3.34
Timer
device or piece of software used in an implementation for measuring time.
Note 1 to entry: Depending on the specific use case a timer is used to trigger certain system events as well.
3.35
Trusted Environment
closed user group (e. g. members of car sharing system) with some pre-distributed token for access to the
SECC charging service (e.g. key to home garage, RFID token for car sharing), which is something where a
person or instance is responsible for, for example (not limited to) a person with its home garage, a car sharing
operator or a taxi operator
3.36
V2G Charging Loop
V2G messaging phase for controlling the charging process by ISO 15118
3.37
V2G Communication Session
association of two specific V2G Entities for exchanging V2G messages
3.38
V2G Entity
primary actor participating in the V2G communication using a mandatory or optional transmission protocol
defined by ISO 15118-2
3.39
V2G Message
message exchanged on application layer
Note 1 to entry: Refer to Clause 8 Application Layer messages.
3.40
V2G Setup
setup phase for V2G messaging
Note 1 to entry: Entry Condition: D-LINK_READY.indication(DLINKSTATUS=LinkEstablished); Exit Condition:
PowerDeliveryReq with ChargeProgress equals Start or Stop.
3.41
V2G Transfer Protocol
communication protocol to transfer V2G messages between two V2GTP entities
6 © ISO 2014 – All rights reserved

3.42
V2GTP Entity
V2G Entity supporting the V2G Transfer Protocol
3.43
V2G Root CA
certificate Authority (CA) who issues Contract Certificates and/or SECC Certificates, or who delegates ability
to issue such Certificates to Sub-CA
3.44
V2G Root Certificate
certificate issued to V2G Root CA
4 Symbols and abbreviated terms
For the purposes of this document, the following abbreviated terms apply:
BEV Battery Electric Vehicle
CA Certificate Authority
CRL Certificate Revocation List
DH Diffie Hellman
DER Distinguished Encoding Rules
ECDSA Elliptic Curve Digital Signature Algorithm
EMAID E-Mobility Account Identifier
EMOCH E-Mobility Operator Clearing House (see also 15118-1, [12])
EV Electric Vehicle
EVCC Electric Vehicle Communication Controller
EVSE Electric Vehicle Supply Equipment
EXI Efficient XML Interchange
OCSP Online Certificate Status Protocol
OEM Original Equipment Manufacturer
NACK Negative Acknowledgement
PDU Protocol Data Unit
PHEV Plug-in Hybrid Electric Vehicle
PKI Public Key Infrastructure
PLC Power Line Communication
PnC Plug and Charge
SA secondary actor
SDP SECC Discovery Protocol
SDU Service Data Unit
SECC Supply Equipment Communication Controller
TCP Transmission Control Protocol
V2G Vehicle to Grid Communication
V2G CI Vehicle-to-Grid Communication Interface
V2GTP V2G Transfer Protocol
UDP User Datagram Protocol
XML Extensible Markup Language
5 Conventions
5.1 Definition of OSI based services
ISO 15118-2 is based on the conventions discussed in the OSI Service Conventions (refer to ISO 10731) as
they apply for the individual layers specified in this document.
This part of ISO 15118-2 describes requirements applicable to layer 3-7 according to the OSI layered
architecture.
5.2 Requirement structure
This document uses a requirement structure i.e. a unique number identifies each individual requirement
included in this document. This requirement structure allows for easier requirement tracking and test case
specification. The following format is used:
"[V2G"Y"-"XXX"]" requirement text Where:
 "V2G" represents the ISO 15118 set of standards,
 Y represents the document part of the ISO 15118 document set
 XXX represents the individual requirement number and
 "requirement text" includes the actual text of the requirement.
EXAMPLE [V2G2-000] This shall be an example requirement.
5.3 Usage of RFC references
When RFCs are referenced all “shall/ shall not” requirements are mandatory.
[V2G2-001] In this document, if a referenced RFC has been updated by one or several RFC, the update is
fully applicable.
[V2G2-002] If an update or part of an update applicable to an RFC referenced herein is not compatible with
the original RFC or the implementation described by this standard the update shall not apply.
[V2G2-003] All published Errata, for the ISO 15118 referenced RFCs, are fully applicable in this standard.
8 © ISO 2014 – All rights reserved

5.4 Notation used for XML schema diagrams
This standard makes use of XML as a description format for V2G messages. For details with regards to the
XML schema diagram notation used in this document refer to Altova XMLSpy Manual.
Allowing for an easy way to distinguish the types used for the XML schema definitions in this standard
following naming conventions apply:
 complex type use capitalized first letters
 simple types use non capitalized first letters
6 Document overview
Figure 2 describes the organization of the different ISO 15118 documents and the usage of the subclauses ,
according to the OSI layered architecture.
As indicated by the bold framed shapes this Part of ISO 15118 defines requirements applicable to layers 3-7
according to the OSI layered architecture. Layer 1 and 2 requirements including the V2G Standardized
Service Primitive Interface are specified in Part 3 of this standard.
Vehicle to Grid Communication
ISO/IEC 15118-1
Application Layer Messages (8)
OSI Layer 7
SDP(7.10.1)
Application
EXI (7.9)
OSI Layer 6
Presentation
ISO/IEC 15118-2
V2GTP (7.8)
OSI Layer 5
Session
TCP,UDP,TLS (7.7)
OSI Layer 4
Transport
IP,ICMP,SLAAC (7.6)
OSI Layer 3
Network
V2G Standardized Service Primitive Interface
OSI Layer 2
Data Link
ISO/IEC 15118-3
OSI Layer 1
Physical
Key
OSI Layers and applicable requirements described in this Part of ISO 15118
OSI Layers and applicable requirements defined in other Parts of ISO 15118
Figure 2 — Vehicle to Grid Communication document overview
10 © ISO 2014 – All rights reserved

7 Basic requirements for V2G communication
7.1 General information
This Part of ISO 15118 describes the realization of the V2G use cases elements defined by Part 1 of this
standard.
7.2 Service primitive concept of OSI layered architecture
7.2.1 Overview
This subclause explains how the OSI layered architecture is applied for the purpose of this document. It is
intended to provide simple means for describing the interfaces between the individual communication protocol
layers required by this document and furthermore allows for defining timing requirements more precisely.
Services are specified by describing the service primitives and parameters that characterize a service. This is
an abstract definition of services and does not force a particular implementation.
Figure 3 depicts a simplified view of OSI layer interaction sufficient to understand the OSI layered architecture
principles for the context of this document.

Key
PDUX: Protocol Data Unit of network entity x
PCI: Protocol Control Information
SDU : Service Data Unit of network entity x
X
Figure 3 — OSI layered architecture principles
When a layer i+1 instance of V2G Entity m exchanges data with a layer i+1 instance of V2G Entity m+1 each
instance uses services of an instance of layer i. A service is defined as a set of service primitives.
7.2.2 Syntax of service primitives
Service primitives are described with the following syntax:
[Initial of layer]-[NAME].[primitive type](parameter list)
 whereas [initial of layer] is one out of the following seven:
[Physical, Data Link, Network, Transport, Session, Presentation, Application]
 whereas [NAME] is the name of the primitive
EXAMPLE Typical examples for [Name] are CONNECT, DISCONNECT, DATA; other names are used in this Part
and Part 3 of this standard.
 whereas [primitive type] is one out of the following four:
[request, indication, response, confirmation]
 whereas (parameter list) includes a list of parameters separated by comma the user of the service is
supposed to provide when using the respective service primitive; optional parameters are marked with
brackets "[.]".
NOTE In this document, the primitive type ".indication" always indicates an event asynchronously to the upper layer.
7.3 Security concept
7.3.1 Call Flows (Flow Charts)
The following two figures (Figure 4 and Figure 5) depict the principal approach for the semi-online and the
online case from a security point of view, showing the necessary security services applied as well as an
abstract view on the different data necessary for the operation.
The full data flow / sequence charts can be found in subclause 8.8 of this document. In these overview figures
only the security relevant information shall be highlighted.
The security concept provides a basic transport based protection mechanism. For certain scenarios, the
usage of Transport Layer Security (TLS) for the transport communication between EVCC and SECC is
mandated. For some other scenarios, the usage of TLS is optional. Specific messages are protected on
application layer (XML-messages), if data has to be protected on the way from or to a secondary actor, or if
the protection has to last longer than the existence of the TLS channel. Also the concept is independent from
any further protection mechanisms on lower levels than layer 3 in the OSI layer model.
Figure 4 shows an example use case for a semi-online connection for a Plug and Charge scenario:
In this Plug-and-Charge example, all TCP/IP based communication is protected using a unilaterally
authenticated TLS channel between the two peers. (Note: TLS is not mandatory for certain Identification
Modes other than the Plug-and-Charge Identification Mode). All communication is terminated at the SECC.
The meter reading is cyclically signed by the vehicle to support the billing process (refer to 8.4.3.13.1). This
information may be used for billing if local regulations permit it. The EVSE provides the charging records,
containing the signed meter reading to the backend for further processing.
NOTE 1 The communication between SECC and SA in Figure 4 is shown for informational purpose only and not
intended to specify a particular message sequence.
12 © ISO 2014 – All rights reserved

Figure 4 — Example for semi-online communication (1 of 2)
Figure 5 shows an example for an online Plug and Charge use case:
As in the semi-online case, in this Plug-and-Charge example, all TCP/IP based communication is protected
using a unilaterally authenticated TLS channel between the two peers. (Note: TLS is not mandatory for certain
Identification Modes other than the Plug-and-Charge Identification Mode). Some of the information provided
by the vehicle may need to be sent to the SA for further processing, like the eMAID or the vehicles credentials
to be able so sign the tariff information. The EVCC calculates a charging profile (refer to subclause 8.4.3.9.2)
and sends it to the SECC. The SECC may send it to SA systems like Smart Grid or Demand Clearing House.
The further process is similar to the semi-online case with the exception, that the final charging data can be
directly submitted to the SA. It is assumed that the SECC will also use a secure transport connection to the
SA, although the security of the vehicle communication to the SA is secured on application layer.
NOTE 2 The communication between SECC and SA in Figure 5 is shown for informational purpose only and not
intended to specify a particular message sequence.
14 © ISO 2014 – All rights reserved

EVCC SECC Secondary Actor (SA)
seq Begin of charging process
seq Communication Setup
seq Establish IP-based Connection
seq Establish TLS Session
Client Hello()
Server Hello()
EVSE Certificate with
V2G Root Certificate
key and chain needed
needed to verify EVSE
... continue according to subclause 7.7.3
certificate as TLS server
supportedAppProtocolReq()
supportedAppProtocolRes()
... continue according to subclause 8.8
seq Identification, Authentication and Authorization
PaymentDetailsReq()
Contract Certificate with key
PaymentDetailsRes()
and chain needed
AuthorizationReq()
V2G Root Certificate
AuthorizationRes() needed
seq Target Setting and Charge Scheduling
seq Request individual tariff tables
ChargeParameterDiscoveryReq()
MO Sub-CA 2 Certificate
ChargeParameterDiscoveryRes()
with key needed
Online request for individual tariff
tables for EMAID
... continue according to subclause 8.8
(outside socpe of this specification)
loop Charge control and Re-scheduling
ChargingStatusReq()
ChargingStatusRes()
opt Metering
MeteringReceiptReq()
MeteringReceiptRes()
Contract Certificate with key
needed
seq End of charging process
... finish according to subclause 8.8
seq Forward Receipt (PnC only)
online exchange of signed V2G Root Certificate
needed
meter receipt data for Plug'n Charge profile
(outside scope of this standard)

Figure 5 — Example for online communication
There are further use cases where security mechanism are needed on application layer. These are the initial
enrolment of contract keys and certificate as well as the update of the certificate. In this case vehicle specific
OEM keys are used. Those mechanisms are described in Annex 0. An overview on all needed certificates can
be found in Annex F.
7.3.2 Certificate and key management
The call flows shown in subclause 7.3.1 require the existence of multiple certificates to be applied for the
different security layers. There are SECC Certificates used in the TLS layer for EVCC to authenticate SECC.
There are Contract Certificates used at the application layer to authenticate against an SECC and/or
secondary actor. There are V2G Root Certificates and possibly Sub-CA Certificates which certify SECC
Certificates and Contract Certificates.
Separate from above certificates, there may be OEM Root Certificates and OEM Provisioning Certificates to
be used for installing and updating Contract Certificates.
For an overview over all possible certificate profiles, see Annex F.
[V2G2-004] Each V2G Entity shall use X.509v3 certificates due to the need of extensions for storing EC-
parameters. For details refer to IETF RFC 5280.
Table 1 shows what fields a X.509v3-certificate consists of:
Table 1 — Basic Certificate Fields
Certificate field Description
Version Version of certificate (for 15118 shall be v3 = 0x2)
Serial number Unique number of certificate (within the domain of the issuer)
Signature algorithm Used signature algorithm
Issuer Entity, who has issued and signed the certificate
Validity period Time period, in which the certificate is valid
Subject Entity, to which the certificate is issued
Public key Public key corresponding to a private key
Issuer UID Optional issuer unique identifier
Subject UID Optional subject unique identifier
Extensions Optional (see Table 2)
Signature Signature of the certificate generated by the issuer
NOTE 1 For those not familiar with the various fields refer to IETF RFC 5280.
Depending on the use case additional information may be included using so called certificate extensions.
Table 2 summarizes common certificate extensions.
16 © ISO 2014 – All rights reserved

Table 2 — Certificate extension examples
Certificate extensions Description
Usage of the corresponding private key (e.g. Digital Signature,
Key usage
Non-Repudiation, Key Encipherment, …)
Further specification of key usage using OIDs, e.g.:
Server Authentication (1.3.6.1.5.5.7.3.1)
Client Authentication (1.3.6.1.5.5.7.3.2)
Note, sometimes here also the following values are encoded:
Netscape SGC (1.3.6.1.4.1.311.10.3.3)
Extended Key Usage
Microsoft SGC (2.16.840.1.113730.4.1)
SGC stands for Server Gated Crypto and indicated that the server
may also use strong cryptography for the connection with the
client’s browser. This extension was used at the time of strong
crypto export control to enable financial web site to provide
appropriate protection of the data transfer.
CRL distribution point Location to retrieve certificate revocation lists
OCSP Location to retrieve OCSP response (exists only for SubCA
certificates). Refer to IETF RFC 6960 for details.
Authority information Additional authorization information
Subject alternative name Alternative names of the entity
Basic constraint = CA True if the certificate is V2G Root Certificate or SubCA certificate.
NOTE 2 For those not familiar with OIDs, e.g. 1.3.6.1.5.5.7.3.1, refer to: Object Identifier (OID) Repository.
[V2G2-005] Each V2G Entity shall support Hash-operation SHA-256 (signature process) according to NIST
FIPS PUB 180-4 (for Part 1 Use Case Element ID: F1).
[V2G2-006] For each V2G Entity the signature operation shall be ECC-based using elliptic curves
(secp256r1[SECG notation]) with signature algorithm ECDSA (for Part 1 Use Case Element
ID: F1).
[V2G2-007] The key length for ECC based asymmetric cryptography each V2G Entity uses shall be 256 bit.
[V2G2-885] All certificate validations shall be carried out in conformance with RFC 5280. The EVCC and
the SECC may cache certificate validation results during one charging session.
[V2G2-926] The certificate extensions mentioned in Annex F shall be supported. Deviations are specified
wher
e necessary.
[V2G2-925] A leaf certificate shall be treated as invalid, if the trust anchor at the end of the chain does not
match the specific root certificate required for a certain use, or if the required Domain
Component value is not present.
[V2G2-910] The EVCC should implement a mechanism to check the validity periods of certificates and
OCSP responses.
[V2G2-886] The EVCC may choose the accuracy of its time source at its own discretion, but it shall respect
the chosen accuracy when using the time source. The accuracy should be at least one day.
NOTE 3 This requirement theoretically even allows for precisions of e.g. one year. The implementer should carefully
weigh the security consequences of such a decision.
NOTE 4 If a TLS connection is built up successfully, the EVCC might use the time from a EVSETimeStamp field sent
from the SECC through said connection for synchronization of its internal clock, however the implementer should carefully
weigh the security consequences of such a decision.
[V2G2-887] The SECC shall ensure that at any point in time it has a certificate for itself, which is valid for at
least one more hour.
7.3.3 Number of root certificates and root validity, certificate depth and size
[V2G2-008] Each EVCC shall support at least one V2G Root Certificate.
[V2G2-877] Each SECC shall support the storage of at least 10 V2G Root Certificates.
NOTE 1 Due to overlapping validity periods, up to 10 concurrently valid certificates may exist. See V2G2-012
NOTE 2 A number of five (5) V2G Root Certificates is strongly recommended. However, just one is mandatory. Having
less than 5 or just 1 certificate brings a risk to the OEM. Having just 1 V2G Root Certificate allows the car to charge just in
that one region. The OEM will need to state in the manual and during offering the car to customers, that this car charges
only in its "home" region. If an OEM is afraid, that 5 V2G Root Certificates are not sufficient to cover the "usage radius" of
its cars, OEM is free to provide more root certificate storage locations.
NOTE 3 It is assumed that the V2G Root Certificates applied on OSI layer 4 are also used on OSI layer
...

NORME ISO
INTERNATIONALE 15118-2
Première édition
2014-04-01
Véhicules routiers — Interface de
communication entre véhicule et
réseau électrique —
Partie 2:
Exigences du protocole d'application
et du réseau
Road vehicles — Vehicle-to-Grid Communication Interface —
Part 2: Network and application protocol requirements
Numéro de référence
©
ISO 2014
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2014, Publié en Suisse
Droits de reproduction réservés. Sauf indication contraire, aucune partie de cette publication ne peut être reproduite ni utilisée
sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique, y compris la photocopie, l’affichage sur
l’internet ou sur un Intranet, sans autorisation écrite préalable. Les demandes d’autorisation peuvent être adressées à l’ISO à
l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Ch. de Blandonnet 8 • CP 401
CH-1214 Vernier, Geneva, Switzerland
Tel. [phone]
Fax [phone]
[e-mail]
www.iso.org
ii © ISO 2014 – Tous droits réservés

Sommaire Page
Avant-propos . v
Introduction . vi
1 Domaine d'application .1
2 Références normatives .1
3 Termes et définitions .3
4 Symboles et abréviations .8
5 Conventions .9
5.1 Définition des services basés sur le modèle OSI.9
5.2 Structure des exigences .9
5.3 Utilisation de références RFC . 10
5.4 Notation utilisée pour les diagrammes de schéma XML . 10
6 Aperçu général du document . 10
7 Exigences de base pour la communication V2G . 12
7.1 Informations générales . 12
7.2 Concept de primitive de service de l'architecture en couches OSI . 12
7.3 Concept de sécurité . 13
7.4 Traitement des états de communication V2G et de la liaison de données . 24
7.5 Couche liaison de données . 31
7.6 Couche réseau . 31
7.7 Couche transport . 33
7.8 Protocole de transfert V2G . 38
7.9 Couche présentation . 43
7.10 Couche application . 54
8 Messages de la couche application . 63
8.1 Informations générales et définitions . 63
8.2 Définition de la prise de contact de protocole . 64
8.3 Définition des messages V2G . 68
8.4 Définitions d'une session de communication V2G et de BodyElement . 70
8.5 Types de données complexes . 117
8.6 Modes d'identification et définitions des ensembles de messages . 152
8.7 Temporisation des communications V2G . 186
8.8 Enchaînement des messages et traitement des erreurs . 201
8.9 Exemples de séquence de messages demande-réponse . 228
(informative) Correspondance avec les éléments de cas d'utilisation de la
Partie 1 . 237
(informative) Correspondance entre les noms des éléments de messages de
l'ISO 15118 et les termes de la norme SAE J2847/2 . 274
(normative) Définition de schéma . 278
(informative) Exemples de messages . 302
(informative) Application de certificats. 323
(normative) Profils de certificat . 338
(informative) Chiffrement pour la distribution de clés secrètes . 346
iii
(normative) Spécification des identificateurs . 348
(informative) Enchaînement des messages pour une renégociation . 351
(informative) Aperçu général des signatures XML . 355
(informative) Récapitulatif des exigences . 360
Bibliographie . 367
iv
Avant-propos
L'ISO (Organisation internationale de normalisation) est une fédération mondiale d'organismes
nationaux de normalisation (comités membres de l'ISO). L'élaboration des Normes internationales est en
général confiée aux comités techniques de l'ISO. Chaque comité membre intéressé par une étude a le droit
de faire partie du comité technique créé à cet effet. Les organisations internationales, gouvernementales
et non gouvernementales, en liaison avec l'ISO participent également aux travaux. L'ISO collabore
étroitement avec la Commission électrotechnique internationale (IEC) en ce qui concerne la
normalisation électrotechnique.
Les procédures utilisées pour élaborer le présent document et celles destinées à sa mise à jour sont
décrites dans les Directives ISO/IEC, Partie 1. Il convient, en particulier de prendre note des différents
critères d'approbation requis pour les différents types de documents ISO. Le présent document a été
rédigé conformément aux règles de rédaction données dans les Directives ISO/IEC, Partie 2

(voir www.iso.org/directives).
L'attention est appelée sur le fait que certains des éléments du présent document peuvent faire l'objet de
droits de propriété intellectuelle ou de droits analogues. L'ISO ne saurait être tenue pour responsable de
ne pas avoir identifié de tels droits de propriété et averti de leur existence. Les détails concernant les
références aux droits de propriété intellectuelle ou autres droits analogues identifiés lors de l'élaboration
du document sont indiqués dans l'Introduction et/ou dans la liste des déclarations de brevets reçues par
l’ISO (voir www.iso.org/brevets).
Les appellations commerciales éventuellement mentionnées dans le présent document sont données
pour information, par souci de commodité à l'intention des utilisateurs et ne sauraient constituer un
engagement.
Pour une explication de la signification des termes et expressions spécifiques de l'ISO liés à l'évaluation
de la conformité, ou pour toute information au sujet de l'adhésion de l'ISO aux principes de l'Organisation
mondiale du commerce (OMC) concernant les obstacles techniques au commerce (OTC) voir le lien
suivant: www.iso.org/iso/fr/foreword.html.
Le comité chargé de l'élaboration du présent document est l'ISO/TC 22, Véhicules routiers, sous-comité
SC 3, Équipements électrique et électronique.
L'ISO 15118-2 a été élaboré conjointement avec IEC/TC 69 Véhicules électriques destinés à circuler sur la
voie publique et chariots de manutention électriques.
L'ISO 15118 comprend les parties suivantes, présentées sous le titre général Véhicules routiers —
Interface de communication entre véhicule et réseau électrique :
 Partie 1 : Informations générales et définition de cas d'utilisation
 Partie 2 : Exigences du protocole d'application et du réseau
 Partie 3 : Exigences relatives à la couche physique et à la couche liaison de données
v
Introduction
La crise énergétique imminente et la nécessité de réduire les émissions de gaz à effet de serre ont conduit
les constructeurs de véhicules à déployer des efforts considérables pour réduire la consommation
d'énergie de leurs véhicules. Ils développent actuellement des véhicules partiellement ou entièrement
propulsés à l'énergie électrique. Ces véhicules réduiront la dépendance au pétrole, amélioreront
l'efficacité énergétique globale et réduiront les émissions totales de CO associées au transport routier si
l'électricité est produite à partir de sources renouvelables. Pour recharger les batteries de tels véhicules,
une infrastructure de recharge spécifique est requise.
Une grande partie des travaux de normalisation concernant les spécifications dimensionnelles et
électriques de l'infrastructure de recharge et de l'interface avec le véhicule est déjà traitée dans les
groupes ISO ou IEC pertinents. Toutefois, la question du transfert d'informations entre le véhicule
électrique (VE) et l'infrastructure de recharge pour véhicules électriques (IRVE) n'a pas été suffisamment
traitée.
Une telle communication est nécessaire pour l'optimisation des ressources énergétiques et des systèmes
de production d'énergie, afin que les véhicules puissent être rechargés de la manière la plus économique
ou la plus efficace en termes d'énergie. Il est également nécessaire de développer des systèmes de
facturation efficaces et pratiques afin de couvrir les micro-paiements qui en résultent. Le canal de
communication nécessaire pourra servir dans le futur à contribuer à la stabilisation du réseau électrique,
ainsi qu'à prendre en charge les services d'information supplémentaires requis pour exploiter les
véhicules électriques de manière efficace et économique.

vi
NORME INTERNATIONALE ISO 15118-2:2014(F)

Véhicules routiers — Interface de communication entre
véhicule et réseau électrique —
Partie 2:
Exigences du protocole d'application et du réseau
1 Domaine d'application
Le présent document spécifie la communication entre les véhicules électriques à batterie (VEB) ou les
véhicules électriques hybrides rechargeables (VEHR) et l'infrastructure de recharge pour véhicules
électriques. L'ensemble de messages de la couche application défini dans le présent document est conçu
pour prendre en charge le transfert d'énergie entre une IRVE et un VE. L'ISO 15118-1 contient des
éléments de cas d'utilisation supplémentaires (ID des éléments de cas d'utilisation de la Partie 1 : F4 et
F5) décrivant le transfert d'énergie bidirectionnel. L'implémentation de ces cas d'utilisation nécessite des
améliorations de l'ensemble de messages de la couche application défini dans le présent document. Les
définitions de ces exigences supplémentaires feront l'objet de la prochaine révision du présent document.
Le présent document a pour but de décrire de manière détaillée la communication entre un VE (VEB ou
VEHR) et une IRVE. Les aspects spécifiés permettent de détecter un véhicule dans un réseau de
communication, et de permettre une communication basée sur le protocole Internet (IP) entre le
contrôleur de communication du véhicule électrique (EVCC) et le contrôleur de communication de
l'infrastructure de recharge (SECC).

Légende
1 Domaine d'application du présent document
2 La définition des messages tient compte des cas d'usage définis pour la communication entre le SECC et un acteur
secondaire (AS).
Figure 1 — Relations de communication entre EVCC, SECC et acteur secondaire
Le présent document définit les messages, le modèle de données, le format de représentation de données
basé sur XML/EXI, l'utilisation de V2GTP, TLS, TCP et IPv6. De plus, il décrit comment accéder aux
services de la couche liaison de données à partir de la couche 3. La fonctionnalité de la couche liaison de
données et de la couche physique est décrite dans l'ISO 15118-3.
2 Références normatives
Les documents suivants, en tout ou partie, sont référencés de façon normative dans le présent document
et sont indispensables à son application. Pour les références datées, seule l'édition citée s'applique. Pour
les références non datées, la dernière édition du document de référence s'applique (y compris les
éventuels amendements).
ISO 3166-1, Codes pour la représentation des noms de pays et de leurs subdivisions ― Partie 1 : Codes de
pays
ISO 15118-1, Véhicules routiers — Interface de communication entre véhicule et réseau électrique —
Partie 1 : Informations générales et définition de cas d'utilisation
IEC 61851-1, Système de charge conductive pour véhicules électriques — Partie 1 : Règles générales (Ed 2.0
2010)
IEC 61851-22, Système de charge conductive pour véhicules électriques — Partie 22 : Bornes de charge
conductive en courant alternatif pour véhicules électriques
IEC CDV 61851-23, Système de charge conductive pour véhicules électriques — Partie 23 : Borne de charge
en courant continu pour véhicules électriques (Ed 1.0 2012)
IEC 62196, Fiches, socles de prise de courant, prises mobiles et socles de connecteur de véhicule — Charge
conductive des véhicules électriques
W3C EXI 1.0, Efficient XML Interchange (EXI) Format 1.0, W3C Recommendation (March 2011)
W3C XML Signature Syntax and Processing Version 1.1, - W3C Recommendation (April 2013)
IETF RFC 768, User Datagram Protocol (August 1980)
IETF RFC 793, Transmission Control Protocol - DARPA Internet Program - Protocol Specification
(September 1981)
IETF RFC 1981, Path MTU Discovery for IP version 6 (August 1996)
IETF RFC 2460, Internet Protocol, Version 6 (IPv6) Specification (December 1998)
IETF RFC 6960, X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (June
2013)
IETF RFC 3122, Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification (June 2001)
IETF RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6) (July 2003)
IETF RFC 3484, Default Address Selection for Internet Protocol version 6 (IPv6) (February 2003)
IETF RFC 6582, The NewReno Modification to TCP's Fast Recovery Algorithm (April 2012)
IETF RFC 4291, IP Version 6 Addressing Architecture (February 2006)
IETF RFC 4429, Optimistic Duplicate Address Detection (DAD) for IPv6 (April 2006)
IETF RFC 4443, Internet Control Message Protocol (ICMP v6) for the Internet Protocol version 6 (IPv6)
specification (March 2006)
IETF RFC 4861, Neighbor Discovery for IP version 6 (IPv6) (September 2007)
IETF RFC 4862, IPv6 Stateless Address Autoconfiguration (September 2007)
IETF RFC 5095, Deprecation of Type 0 Routing Headers in IPv6 (December 2007)
IETF RFC 5116, An Interface and Algorithms for Authenticated Encryption (January 2008)
2 © ISO 2014 – Tous droits réservés

IETF RFC 5234, Augmented BNF for Syntax Specifications: ABNF (January 2008)
IETF RFC 5246, The Transport Layer Security (TLS) Protocol Version 1.2 (August 2008)
IETF RFC 5280, Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)
Profile (May 2008)
IETF RFC 5289, TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)
(August 2008)
IETF RFC 5480, Elliptic Curve Cryptography Subject Public Key Information (March 2009)
IETF RFC 5722, Handling of Overlapping IPv6 Fragments (December 2009)
IETF RFC 6066, Transport Layer Security (TLS) Extensions: Extension Definitions (January 2011)
IETF RFC 6106, IPv6 Router Advertisement Options for DNS Configuration (November 2010)
IETF RFC 6961, The Transport Layer Security (TLS) Multiple Certificate Status Request Extension (June
2013)
IANA Service&PortRegistry, Service Name and Transport Protocol Port Number Registry [consulté le
2011-01-16], disponible sous : http://www.iana.org/assignments/service-names-port-
numbers/service-names-port-numbers.xml
NIST FIPS PUB 180-4: Secure Hash Standard (SHS) (March 2012)
NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using
Discrete Logarithm Cryptography (Revised) (March 2007)
NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation - Methods and
Techniques (2001)
3 Termes et définitions
Pour les besoins du présent document, les termes et définitions donnés dans l’ISO 15118-1 ainsi que les
suivants s'appliquent.
3.1
recharge de base
RB
au cours d'une session de recharge, phase de recharge contrôlée uniquement par l'IEC 61851-1
3.2
limites de charge
ensemble de contraintes physiques (par exemple tension, courant, énergie, puissance) qui est négocié
pendant une session de communication V2G en vue d'une session de recharge
3.3
temporisateur de configuration de la communication
temporisateur surveillant le temps qui s'écoule entre le branchement et le message de configuration de
la session
3.4
certificat de contrat
certificat fourni à l’EVCC par une autorité de certification racine (AC Racine) V2G ou par une sous-autorité
de certification (sous-AC), qui est utilisé dans des signatures XML dans la couche application afin que le
SECC ou l'acteur secondaire puisse vérifier le contrat transmis à l’EVCC et les signatures fournies par
l’EVCC
3.5
état du PC
état du pilote de contrôle (véhicule), conformément à l'IEC 61851-1, signalé sur la ligne pilote de contrôle
3.6
authentifiant
tout ce qui sert de base de confiance, conviction, crédit, etc.
EXEMPLE Les exemples comprennent les certificats, les mots de passe, les noms d'utilisateur, etc.
3.7
configuration de la liaison de données
phase de la configuration permettant d'établir la liaison de données
Note 1 à l'article : Condition d'entrée : tout signal pilote de contrôle valide conformément à l'IEC 61851-1 ;
conditions de sortie : D-LINK_READY.indication(DLINKSTATUS=LinkEstablished).
3.8
règles de codage distinctives = règle de codage ASN-1
DER
méthode de codage d'un objet de données, tel qu'un certificat X.509, devant être signé numériquement
ou dont la signature doit être vérifiée
3.9
adresse globale
adresse IP de portée illimitée
3.10
recharge contrôlée par une communication de haut niveau
R-CHN
au cours d'une session de recharge, phase de recharge contrôlée par l'ISO 15118
3.11
adresse locale de liaison
adresse IP avec portée limitée à la liaison qui peut être utilisée pour atteindre des interfaces voisines
connectées à la même liaison
3.12
mode d'identification
messages et paramètres obligatoires et facultatifs en relation avec les scénarios de recharge utilisant un
moyen d'identification externe (MIE) et les scénarios de recharge utilisant Plug and Charge (PnC) pour
l'identification
Note 1 à l'article : Un mode d'identification couvre un ensemble de scénarios de recharge similaires pour un moyen
d'identification spécifique.
3.13
adresse (IP)
identificateur de couche IP pour une interface ou un ensemble d'interfaces
4 © ISO 2014 – Tous droits réservés

3.14
unité de transfert maximale
MTU
taille maximale (en octets) de la plus grande unité de données de protocole que la couche liaison de
données peut transmettre
3.15
ensemble de messages
ensemble de messages et de paramètres V2G obligatoires pour l’EVCC ou le SECC, couvrant un ou
plusieurs éléments de cas d'usage
3.16
temporisateur de message
temporisateur surveillant l'échange d'une paire demande-réponse
3.17
segment de réseau
ensemble de dispositifs pouvant échanger des données directement au niveau de la couche liaison de
données via des adresses de liaison de données
EXEMPLE Ethernet : tous les dispositifs qui peuvent se voir mutuellement via des adresses MAC.
3.18
nœud
dispositif qui implémente IPv6
3.19
certificat de fourniture du FEO
certificat transmis à l’EVCC afin qu'un certificat de contrat puisse être demandé et reçu en toute sécurité
par un acteur secondaire
3.20
temps d'exécution
exigence non fonctionnelle de délai définissant le temps qu'une entité V2G ne doit pas dépasser lors de
l'exécution ou du traitement d'une fonctionnalité donnée
Note 1 à l'article : Il s'agit d'une valeur de temps fixe.
3.21
environnement privé
zone avec un accès (physique) limité à un petit nombre de véhicules (VE), qui peut être un garage privé
ou un parc de stationnement d'une entreprise ayant son propre parc de VE, où un ou plusieurs boîtiers
muraux privés sont utilisés à la place des bornes de recharge publiques comme IRVE et où, pour que la
production et le fonctionnement du boîtier mural privé restent simples et économiques, il est permis de
rester hors ligne en permanence. Cela permet à un boîtier mural privé d'utiliser des certificats feuille
ayant une période de validité maximale plus longue que celle autorisée pour des bornes de recharge
publiques, et d'utiliser un certificat racine privé qui est différent des certificats racine V2G et qui doit être
installé dans chaque VE autorisé à se recharger dans cet environnement privé spécifique. Ainsi, un
nombre limité de VE appartient à un environnement privé ; la différence par rapport à un
« environnement de confiance » est que dans un environnement privé (pur ; c'est-à-dire sans
« confiance » supplémentaire), TLS et le chiffrement des données correspondant au niveau de la
connexion sont toujours utilisés. De plus, seul le traitement des certificats est simplifié pour le boîtier
mural privé (IRVE) car il peut rester hors ligne en permanence, ce qui se traduit par des périodes de
validité des certificats illimitées, une plus courte longueur de chaîne des certificats, l'omission du
protocole OCSP et un « mode d'appariement » supplémentaire
3.22
mode d'identification
groupe d'ensembles de messages obligatoires et facultatifs couvrant un ensemble de scénarios de
recharge similaires pour un moyen d'identification spécifique
3.23
renégociation
échange de message permettant de mettre à jour l'accord relatif au programme de recharge entre un VE
et une IRVE au cours d'une session de communication V2G par retransmission des paramètres
SASchedule et ChargingProfile
3.24
paire de messages demande-réponse
message de demande et message de réponse correspondant
3.25
séquence de messages demande-réponse
séquence prédéfinie de paires de messages demande-réponse
3.26
client SDP
entité V2G qui utilise le serveur SDP pour obtenir des informations de configuration sur le SECC afin de
pouvoir y accéder
3.27
serveur SDP
entité V2G fournissant des informations de configuration pour accéder au SECC
3.28
certificat SECC
certificat fourni au SECC par une autorité de certification racine (AC racine) V2G ou par une sous-autorité
de certification (sous-AC), qui est utilisé dans le TLS afin que l’EVCC puisse vérifier l'authenticité du SECC
3.29
temporisateur de séquence
temporisateur surveillant une séquence de messages demande-réponse
3.30
sous-autorité de certification
sous-AC
autorité de certification subordonnée qui délivre des certificats SECC et/ou des certificats de contrat au
nom de l'autorité de certification racine V2G
Note 1 à l'article : L'aptitude à délivrer les certificats est déléguée par l'autorité de certification racine V2G et cette
dernière peut révoquer la sous-autorité de certification à tout moment.
3.31
certificat de sous-AC
certificat délivré à une sous-AC
6 © ISO 2014 – Tous droits réservés

3.32
TCP_DATA
socle/interface pour un transfert de données basé sur une connexion TCP
3.33
temporisation
exigence de délai définissant le temps pendant lequel une entité V2G surveille le système de
communication dans l'attente qu'un événement donné se produise
Note 1 à l'article : Si le délai spécifié est dépassé, l'entité V2G correspondante lance le traitement d'erreur associé.
Il s'agit d'une valeur de temps fixe.
3.34
temporisateur
dispositif ou logiciel utilisé dans une implémentation pour mesurer le temps
Note 1 à l'article : Selon le cas d'utilisation spécifique, un temporisateur est également employé pour déclencher
certains événements système.
3.35
environnement de confiance
groupe fermé d'utilisateurs (par exemple membres d'un système de partage de véhicule) avec un jeton
pré-distribué pour accéder au service de recharge SECC (par exemple une clé pour un garage privé, un
jeton RFID pour le partage de véhicule), dont une personne ou une instance est responsable, par exemple
(cette liste n'étant pas limitative) une personne avec son garage privé, un opérateur de partage de
véhicules ou un exploitant de taxis
3.36
boucle de recharge V2G
phase d’échange de messages V2G pour contrôler le processus de recharge par l'ISO 15118
3.37
session de communication V2G
association de deux entités V2G spécifiques pour l'échange de messages V2G
3.38
entité V2G
acteur primaire participant à la communication V2G en utilisant un protocole de transmission obligatoire
ou facultatif défini par le présent document
3.39
message V2G
message échangé sur la couche application
Note 1 à l'article : Se reporter à l'Article 8 Messages de la couche application.
3.40
configuration V2G
phase de configuration pour l’échange de messages V2G
Note 1 à l'article : Condition d'entrée : D-LINK_READY.indication(DLINKSTATUS=LinkEstablished) ; condition de
sortie : PowerDeliveryReq avec ChargeProgress égal à Start ou Stop.
3.41
protocole de transfert V2G
protocole de communication pour transférer des messages V2G entre deux entités V2GTP
3.42
entité V2GTP
entité V2G prenant en charge le protocole de transfert V2G
3.43
autorité de certification racine V2G
AC racine V2G
autorité de certification (AC) qui délivre des certificats de contrat et/ou des certificats SECC, ou qui
délègue l'aptitude à délivrer de tels certificats à une sous-AC
3.44
certificat racine V2G
certificat délivré à une AC racine V2G
4 Symboles et abréviations
Pour les besoins du présent document, les abréviations suivantes s’appliquent.
VEB Véhicule électrique à batterie
AC Autorité de certification
CRL Liste de révocation de certificats
DH Diffie Hellman
DER Règles de codage distinctives
ECDSA Algorithme de signature numérique par courbes elliptiques
EMAID Identificateur de compte de mobilité électrique
CCOME Chambre de compensation de l'opérateur de mobilité électrique (voir aussi
l'ISO 15118-1, [12])
VE Véhicule électrique
EVCC Contrôleur de communication de véhicule électrique
IRVE Infrastructure de recharge pour véhicules électriques
EXI Échange XML efficace
OCSP Protocole de statut de certificat en ligne
FEO Fabricant de l'équipement d'origine
NACK Accusé de réception négatif
PDU Unité de données de protocole
VEHR Véhicule électrique hybride rechargeable
8 © ISO 2014 – Tous droits réservés

PKI Infrastructure de clé publique
PLC Communication par courant porteur
PnC Brancher et recharger (Plug and Charge)
AS Acteur secondaire
SDP Protocole de découverte du SECC
SDU Unité de données de service
SECC Contrôleur de communication de l'infrastructure de recharge
TCP Protocole de contrôle de transmission
V2G Communication entre véhicule et réseau électrique
IC V2G Interface de communication entre véhicule et réseau électrique
V2GTP Protocole de transfert V2G
UDP Protocole de datagramme utilisateur
XML Langage de balisage extensible
5 Conventions
5.1 Définition des services basés sur le modèle OSI
Le présent document est basé sur les conventions discutées dans les conventions de service OSI (se
reporter à l'ISO 10731) car elles s'appliquent aux couches individuelles spécifiées dans le présent
document.
Il décrit les exigences applicables aux couches 3 à 7 selon l'architecture en couches OSI.
5.2 Structure des exigences
Le présent document utilise une structure d'exigences, c’est-à-dire qu'un nombre unique identifie chaque
exigence individuelle incluse dans le présent document. Cette structure d'exigences permet de suivre plus
facilement les exigences et de spécifier des cas de test. Le format suivant est utilisé :
« [V2G"Y"-"XXX"] » Formulation de l’exigence, où :
 « V2G » représente l'ensemble de normes ISO 15118,
 Y représente la partie dans l'ensemble de documents ISO 15118,
 « XXX » représente le numéro de l'exigence individuelle et,
 « Formulation de l'exigence » contient la formulation réelle de l'exigence.
EXEMPLE [V2G2-000] Ceci doit être un exemple d'exigence.
5.3 Utilisation de références RFC
Lorsque des RFC sont cités en référence, toutes les exigences « doit/ne doit pas » sont obligatoires.
[V2G2-001] Dans le présent document, si un RFC cité a été mis à jour par un ou plusieurs RFC, la mise à
jour est entièrement applicable.
[V2G2-002] Si une mise à jour ou une partie d'une mise à jour applicable à un RFC cité dans le présent
document n'est pas compatible avec le RFC d'origine ou l'implémentation décrite dans le
présent document, la mise à jour ne s'applique pas.
[V2G2-003] Tous les errata publiés, pour les RFC cités dans l’ISO 15118, sont entièrement applicables
dans le présent document.
5.4 Notation utilisée pour les diagrammes de schéma XML
Le présent document utilise XML comme format de description pour les messages V2G. Pour de plus
amples détails concernant la notation des diagrammes de schéma XML utilisée dans le présent document,
se porter au manuel Altova XMLSpy Manual.
Pour distinguer facilement les types utilisés pour les définitions de schéma XML dans le présent
document, les conventions de dénomination suivantes s'appliquent :
 un type complexe utilise les premières lettres majuscules ;
 des types simples utilisent les premières lettres minuscules.
6 Aperçu général du document
La Figure 2 décrit l'organisation des différents documents ISO 15118 et l'utilisation des paragraphes, en
fonction de l'architecture en couches OSI.
Comme indiqué par les cadres en gras, le présent document définit les exigences applicables aux
couches 3 à 7 de l’architecture en couches OSI. Les exigences relatives aux couches 1 et 2, y compris
l'interface normalisée V2G par primitives de service, sont spécifiées dans l’ISO 15118-3.
10 © ISO 2014 – Tous droits réservés

Légende
Couches OSI et exigences applicables décrites dans le présent document

Couches OSI et exigences applicables définies dans d'autres parties de l'ISO 15118

Figure 2 — Aperçu général des documents relatifs à la communication entre véhicule et réseau
électrique
7 Exigences de base pour la communication V2G
7.1 Informations générales
Le présent document décrit la réalisation des éléments de cas d'utilisation V2G définis dans l’ISO 15118-
1.
7.2 Concept de primitive de service de l'architecture en couches OSI
7.2.1 Aperçu général
Le présent paragraphe explique comment l'architecture en couches OSI est appliquée pour les besoins du
présent document. Il est destiné à fournir un moyen simple de décrire les interfaces entre les couches
protocole de communication individuelles requises par le présent document et permet par ailleurs de
définir plus précisément des exigences de délai.
Les services sont spécifiés en décrivant les primitives de service et les paramètres qui caractérisent un
service. Il s'agit d'une définition abstraite des services qui n'impose pas d'implémentation particulière.
La Figure 3 donne une vue simplifiée de l'interaction entre les couches OSI, suffisante pour comprendre
les principes de l'architecture en couches OSI dans le contexte du présent document.

Légende
PDUX : Unité de données de protocole de l’entité de réseau x
PCI : Informations de contrôle de protocole
SDUX : Unité de données de service de l’entité de réseau x
Figure 3 — Principes de l'architecture en couches OSI
12 © ISO 2014 – Tous droits réservés

Lorsqu'une instance de couche i+1 de l'entité V2G m échange des données avec une instance de couche
i+1 de l'entité V2G m+1, chaque instance utilise les services d'une instance de couche i. Un service est
défini comme un ensemble de primitives de service.
7.2.2 Syntaxe des primitives de service
Les primitives de service sont décrites avec la syntaxe suivante :
[Initiale de la couche]-[NOM].[type de primitive](liste de paramètres)
 où [initiale de la couche] est choisie parmi les sept suivantes :
[Physical, Data Link, Network, Transport, Session, Presentation, Application]
 où [NOM] est le nom de la primitive,
EXEMPLE Les exemples types de [Nom] sont CONNECT, DISCONNECT, DATA ; d'autres noms sont utilisés dans
le présent document et dans l’ISO 15118-3.
 où [type de primitive] est choisi parmi les quatre suivants :
[request, indication, response, confirmation]
 où (liste de paramètres) inclut une liste de paramètres séparés par une virgule, que l'utilisateur du
service est supposé fournir lorsqu'il utilise la primitive de service correspondante ; les paramètres
facultatifs sont indiqués entre crochets « [.] ».
NOTE Dans le présent document, le type de primitive « .indication » indique toujours un événement
asynchrone par rapport à la couche supérieure.
7.3 Concept de sécurité
7.3.1 Flux d'appels (organigrammes)
Les deux figures suivantes (Figure 4 et Figure 5) illustrent l'approche principale pour le cas semi-en ligne
et le cas en ligne du point de vue de la sécurité, en montrant les services de sécurité nécessaires appliqués
ainsi qu'une vue abstraite des différentes données nécessaires pour l'opération.
Les flux de données/diagrammes séquentiels complets sont donnés au paragraphe 8.8 du présent
document. Dans ces figures générales, seules les informations relatives à la sécurité doivent être mises
en évidence.
Le concept de sécurité fournit un mécanisme basique de protection basé sur le transport. Pour certains
scénarios, l'utilisation du protocole Transport Layer Security (TLS) pour la communication sur la couche
transport entre l’EVCC et le SECC est obligatoire. Pour d'autres scénarios, l'utilisation du protocole TLS
est facultative. Les messages spécifiques sont protégés sur la couche application (messages XML) si les
données doivent être protégées sur le trajet depuis ou vers un acteur secondaire, ou si la durée de
protection doit être supérieure à la durée d'existence du canal TLS. Le concept est également indépendant
de tout autre mécanisme de protection à des niveaux inférieurs à la couche 3 du modèle de couches OSI.
La Figure 4 montre un exemple de cas d'utilisation d'une connexion semi-en ligne pour un scénario Plug-
and-Charge.
Dans cet exemple de scénario Plug-and-Charge, toute communication basée sur le protocole TCP/IP est
protégée en utilisant un canal TLS authentifié de manière unilatérale entre les deux homologues. (Note :
TLS n'est pas obligatoire pour certains modes d'identification autres que le mode d'identification Plug-
and-Charge). Il est mis fin à toute communication au niveau du SECC. Le relevé du compteur est signé de
manière cyclique par le véhicule pour appuyer le processus de facturation (voir 8.4.3.13.1). Cette
information peut être utilisée pour la facturation si les réglementations locales l'autorisent. L'IRVE
transmet au serveur les enregistrements de recharge, contenant le relevé de compteur signé, en vue d'un
traitement ultérieur.
NOTE 1 Dans la Figure 4, la communication entre le SECC et un AS est représentée à titre d'information
uniquement et non pour spécifier une séquence de messages particulière.
14 © ISO 2014 – Tous droits réservés

Figure 4 — Exemple de communication semi-en ligne (1 sur 2)
La Figure 5 illustre un exemple de cas d'utilisation Plug-and-Charge en ligne.
Comme dans le cas semi-en ligne, dans cet exemple de scénario Plug-and-Charge, toute communication
basée sur le protocole TCP/IP est protégée en utilisant un canal TLS authentifié de manière unilatérale
entre les deux homologues. (Note : TLS n'est pas obligatoire pour certains modes d'identification autres
que le mode d'identification Plug-and-Charge). Il se peut que certaines des informations fournies par le
véhicule doivent être transmises à l'acteur secondaire (AS) en vue d'un traitement ultérieur, comme
l'EMAID ou les authentifiants des véhicules permettant de signer les informations tarifaires. L’EVCC
calcule un profil de recharge (voir 8.4.3.9.2) et le transmet au SECC. Le SECC peut le transmettre à des
systèmes AS tels qu'un réseau intelligent ou une chambre de compensation de la demande. Le processus
ultérieur est similaire au cas semi-en ligne, excepté que les données finales de recharge peuvent être
soumises directement à l'AS. Il est supposé que le SECC utilisera également une connexion de transport
sécurisée avec l'AS, bien que la sécurité de la communication du véhicule avec l'AS soit assurée dans la
couche application.
NOTE 2 Dans la Figure 5, la communication entre le SECC et un AS est représentée à titre d'information
uniquement et non pour spécifier une séquence de messages particulière.
16 © ISO 2014 – Tous droits réservés

Figure 5 — Exemple de communication en ligne
Il existe d'autres cas d'utilisation pour lesquels des mécanismes de sécurité sont nécessaires dans la
couche application. Il s'agit de l'inscription initiale des clés et du certificat de contrat ainsi que de la mise
à jour du certificat. Dans ce cas, les clés du FEO spécifiques au véhicule sont utilisées. Ces mécanismes
sont décrits dans l'Annexe E. Un aperçu général de tous les certificats nécessaires est donné dans
l’Annexe F.
7.3.2 Gestion des certificats et des clés
Les flux d'appels présentés en 7.3.1 exigent l'existence de multiples certificats devant être appliqués pour
les différentes couches de sécurité. Il y a les certificats de SECC utilisés dans la couche TLS pour que l’EVCC
authentifie le SECC. Il y a les certificats de contrat utilisés dans la couche application pour une
authentification par rapport à un SECC et/ou un acteur secondaire. Il y a les certificats racine V2G et
éventuellement les certificats des sous-AC qui certifient les certificats de SECC et les certificats de contrat.
Outre les certificats ci-dessus, il peut y avoir des certificats racine de FEO et des certificats de fourniture
de FEO à utiliser pour l'installation et la mise à jour des certificats de contrat.
Pour un aperçu général de tous les profils de certificat possibles, voir l'Annexe F.
[V2G2-004] Chaque entité V2G doit utiliser des certificats X.509v3 en raison de la nécessité d'extensions
pour le stockage des paramètres EC. Pour de plus amples détails, se reporter à
l’IETF RFC 5280.
Le Tableau 1 indique les champs contenus dans un certificat X.509v3 :
Tableau 1 — Champs d'un certificat de base
Champ du certificat Description
Version du certificat (pour 15118, il doit être v3 = 0x2)
Version
Serial number (Numéro de
Numéro unique du certificat (dans le domaine de l'émetteur)
série)
Signature algorithm
Algorithme de signature utilisé
(Algorithme de signature)
Entité qui a émis et signé le certificat
Issuer (Émetteur)
Validity period (Période de
Période pendant laquelle le certificat est valide
validité)
Subject (Sujet) Entité à laquelle est délivré le certificat
Public key (Clé publique) Clé publique correspondant à une clé privée
Issuer UID (UID de
Identificateur unique facultatif de l'émetteur
l'émetteur)
Identificateur unique facultatif du sujet
Subject UID (UID du sujet)
Facultatif (voir Tableau 2)
Extensions
Signature Signature du certificat généré par l'émetteur
NOTE 1 Pour ceux qui ne sont pas familiarisés avec les différents champs, se reporter à l’IETF RFC 5280.
Selon le cas d'utilisation, des informations supplémentaires peuvent être incluses en utilisant des
extensions de certificat. Le Tableau 2 récapitule les extensions de certificat courantes.
18 © ISO 2014 – Tous droits réservés

Tableau 2 — Exemples d'extensions de certificat
Extensions de certificat Description
Utilisation de la clé privée correspondante (par exemple
Key usage (Utilisation de la
signature numérique, non répudiation, chiffrement de clé,
c
...