Workshop zur ISO 15118 · cle inlets Conductive charging of electric vehicles, Geneva, ... J....

1 SURPRISINGLY SIMPLEwww.chargepartner.com

Workshop zur ISO 15118 | Dr.-Ing. Marc Mültin

Frankfurt am Main | 1.10.2015

Workshop zur ISO 15118Im Rahmen des Schaufensterprogramms Elektromobilität

Dr.-Ing. Marc Mültin

ERFREULICH EINFACHwww.chargepartner.com

E-Mobilität einfach gestalten

Mit der Systemlösung von Chargepartner



Workshops and trainings on request

09.10.15

The information given in this slideset is only a subset of the original workshop presentation.

Interested in further in-depth workshops andtrainings about ISO 15118?

Contact

[email protected]



Agenda

09.10.15

§ Protocols applied on ISO/OSI layers§ Message sets and sequences on application layer§ Renegotiation of a charging profile§ Guidance through the ISO 15118-2 document

§ Security in ISO 15118: Confidentiality, integrity, authenticity (CIA)§ Certificate handling

§ International application, testivals, User Group§ Available software to get you started§ Online resources for further information

General technical introduction

Security aspects

Information to get started and contribute



But First ...

A Few Words AboutChargepartner

09.10.15



Our product: A multi-client capable Software-as-a-Service Platform for:§ Charge Point Operators§ eMobility Service Providers (holding user contracts)§ Employers, Corporate Car Fleets, Parking Lot and Garage Operators

Core functions:§ Real-time monitoring of charging infrastructure§ Authentication, authorization and billing of charge events§ Easy to use hardware- and user-management§ Load-management to avoid local grid overloads

Who we are:§ Continuous development since first project „Future Fleet“ in 2008 (with SAP)§ 8 dedicated and enthusiastic professionals working in Walldorf near Heidelberg

09.10.15



Our USPs and happy customers

09.10.15

(WinJet, Beijing)

Multi-client Capability

Independence

Open System Architecture

High Scalability

Customizable

And many more…



Protocols Applied on ISO/OSI Layers

09.10.15



ISO/OSI Layers and related protocols

09.10.15

Messages and data formats(Finite state machines)

Data representation as binaryXML files (Codec)

V2G Transfer Protocol (Session-Handling)

Standard transport protocols(Client/Server)



§ Vehicle-to-Grid Transfer Protocol (V2GTP) = standard transfer protocol betweenEVCC and SECC

§ Based on TCP/TLS: source and destination IP Address and port to establish andidentify a connection for bidirectional exchange of byte streams

09.10.15

Session layer: Session handling via V2GTP

Header(8 Bytes)

Payload (Application layer messages)(0 - 4294967295 Bytes)

1 2 3 4 5 6 7 8

Protocol Version

Inverse Protocol Version

Payload Type (how to decode

payload)Payload Length

§ EXI-encodedV2G message§ SDP request / response message§ Reserved / manufacturer specific use

Byte no.

Header field


Workshop zur ISO 15118 | Dr.-Ing. Marc Mültin09.10.15

Session layer: V2G communication session handling

time

Data Link Data Link

TCP/TLS connection TCP/TLS connection

Pausing

Charging Session

Plug-in Plug-out

V2G Communication Session 1

(SessionID = 23)

SessionSetupReq(SessionID=0)/Res(SessionID=23)

SessionStopReq(ChargingSession=Pause)/Res

SessionSetupReq(SessionID=23)/Res(SessionID=23)

V2G Communication Session 2

(SessionID = 23)

SessionStopReq(ChargingSession=Terminate)/Res



§ Efficient XML Interchange (EXI) = binary representation of XML-based messages

• EXI-Grammar more efficient than parsing schema information of XSD file• Speeds up message processing on embedded controllers

§ Coding efficiency of EXI format (based on EXIficient library) compared to XML

Request messages: 10% (average compression rate)Response messages: 5,5 % (average compression rate)

09.10.15

Presentation layer: Advantage of EXI over plain XML

MessagePattern

XML schema informed

EXI schema informed

EXI strict byte pkd

EXI strict bit pkd

Compr. Factor

Compr. Rate

MessagePattern

XML schema informed

EXI schema informed

EXI strict byte pkd

EXI strict bit pkd

Compr. Factor

Compr. Rate

SessionSetupReq 637 69 72 67 9,5 10,52% SessionSetupRes 792 42 52 37 21,4 4,67%ServiceDiscoveryReq 781 278 281 276 2,8 35,34% ServiceDiscoveryRes 1013 83 89 77 13,2 7,60%

S&PSelectionReq 813 64 68 60 13,6 7,38% S&PSelectionRes 563 33 35 31 18,2 5,51%PaymentDetailsReq 556 46 52 44 12,6 7,91% PaymentDetailsRes 545 33 35 31 17,6 5,69%PowerDiscoveryReq 1127 61 69 53 21,3 4,70% PowerDiscoveryRes 2773 138 166 115 24,1 4,15%

LineLockReq 643 34 37 31 20,7 4,82% LineLockRes 778 37 41 32 24,3 4,11%PowerDeliveryReq 1172 50 58 43 27,3 3,67% PowerDeliveryRes 543 33 35 31 17,5 5,71%

MeteringStatusReq 490 32 34 30 16,3 6,12% MeteringStatusRes 1338 94 114 84 15,9 6,28%MeteringReceiptReq 1025 114 123 108 9,5 10,54% MeteringReceiptRes 547 33 35 31 17,6 5,67%

Arithmetic Mean 805 83 88 79 10,2 10,11% Arithmetic Mean 988 58 67 52 19,0 5,49%Max 1172 278 281 276 27,3 35,34% Max 2773 138 166 115 24,3 7,60%Min 490 32 34 30 2,8 3,67% Min 543 33 35 31 13,2 4,11%

a) b)

Fig. 7. Quantitative Overview of V2G Request (a) and Response (b) Message Sizes in XML and various EXI modes

a) b)

0

200

400

600

800

1000

1200XML schema informed EXI strict byte pkd EXI strict bit pkd

0

500

1000

1500

2000

2500

3000XML schema informed EXI strict byte pkd EXI strict bit pkd

byte

byte

Fig. 8. Comparison of V2G Request (a) and Response (b) Message Sizes in XML schema-informed and EXI strict mode (byte packed & bit packed)

negotiations, interoperability and usability. The investigationson the application layer protocol provide first results in termsof data encoding efficiency. The results show that utilizing EXIfor data encoding limits the maximum number of transferedbytes to less than 300bytes for the worst case message pattern.Moreover, the RAM allocation needed for the in- and outputmessage buffers are decreased to only 23.4% and 4.2% of thesize for the equivalent XML based approach. The analysis alsoprovides means to quantitatively identify protocol specificationflaws targeting at efficient memory utilization for highlyembedded devices.

ACKNOWLEDGMENT

The authors would like to thank Siemens Corporate Tech-nology and the project partners RWE, SAP Research, Ewald& Guenter, TU-Berlin and TU-Dortmund for collaborationin standardization efforts and fruitful discussions during theresearch project e-mobility. The work in this paper was partlyfunded by the German Federal Ministry of Economics andTechnology (BMWi) as part of the e-mobility project withreference number 01ME09012.

REFERENCES

[1] National Institute of Standards and Technology, Framework andRoadmap for Smart Grid Interoperability Standards, Release 1.0. NISTSpecial Publication 1108, January 2010.

[2] IEC TC/SC 23 62196-x, Plugs, socket-outlets, vehicle couplers and vehi-cle inlets Conductive charging of electric vehicles, Geneva, Switzerland.

[3] IEC TC/SC 69 61851-x, Electric vehicle conductive charging system,Geneva, Switzerland.

[4] ISO/IEC 15118-x, Vehicle to grid communication interface, Geneva,Switzerland.

[5] S. Kaebisch, A. Schmitt, M. Winter, and J. Heuer, “Interconnectionsand communications of electric vehicles and smart grids,” in SmartGrid Communications (SmartGridComm), 2010 First IEEE InternationalConference on, 2010, pp. 161 –166.

[6] IEC TC/SC 57 61850-7-420, Communication networks and systems forpower utility automation - Part 7-420, Geneva, Switzerland, 2009.

[7] IEC TC/SC 57 61850-7-2, Basic communication structure for substa-tion and feeder equipment - Abstract communication service interface(ACSI), Geneva, Switzerland, 2003.

[8] J. Schneider and T. Kamiya, “Efficient XML Interchange (EXI)Format 1.0,” W3C, Tech. Rep., December 2009. [Online]. Available:http://www.w3.org/TR/2009/CR-exi-20091208/

[9] G. Moritz, “DPWS for 6LoWPAN,” IETF Internet Draft, Tech. Rep.,June 2010. [Online]. Available: http://tools.ietf.org/html/draft-moritz-6lowapp-dpws-enhancements-01

[10] D. Sturek, Z. Shelby, D. Lohman, M. G. Stuber, and S. Ashton, “SmartEnergy Requirements for 6LowApp,” IETF Internet Draft, Tech. Rep.,October 2009. [Online]. Available: http://tools.ietf.org/html/draft-sturek-6lowapp-smartenergy-00

[11] Z. Shelby, M. Luimula, and D. Peintner, “ Efficient XML Encoding and6LowApp,” IETF Internet Draft, Tech. Rep., October 2009. [Online].Available: http://tools.ietf.org/html/draft-shelby-6lowapp-encoding-00

[12] ZigBee Alliance and HomePlug Powerline Alliance liason, “SmartEnergy Profile 2.0 Application Protocol Specification (Draft 0.7),” Tech.Rep., April 2010.

[13] S. Kaebisch, D. Peintner, J. Heuer, and H. Kosch, “Efficient andFlexible XML-Based Data-Exchange in Microcontroller-Based SensorActor Networks,” International Conference on Advanced InformationNetworking and Applications Workshops, vol. 0, pp. 508–513, 2010.

125

J. Schmutzler, C. Wietfeld: Analysis of message sequences andencodingefficiency for electric vehicle to grid interconnections. In: VehicularNetworking Conference (VNC), 2010 IEEE, 2010, S. 118–125



§ EVCC uses SECC Discovery Protocol (SDP) to get IP address and port of SECC

§ Multicast messages on local link (to any SDP server (SECC) on local network)

§ UDP (User Datagram Protocol)-based protocol– simple connectionless transmission of data (no handshaking mechanism like in TCP/TLS, thus no guarantee of delivery, ordering, duplicate protection)

09.10.15

Application layer: SECC discovery via SDP

1 2 1 - 16 17 18 19 20

SecurityTrans-port

ProtocolSECC IP Address

Trans-port

ProtocolSecuritySECC Port

Request Response

If TCP orTLS connection is wanted

If desired security level is offered/accepted



Message Sets And SequencesOn Application Layer

09.10.15



Client/Server-based communication protocol

ESHL

PLC

Requests

Responses

§ EVCC (Client) always sends request messages, SECC (server) responds within giventimeout (between 2s and 5s, depending on message type)

§ SECC can trigger certain request messages by setting a flag in response message(e.g. for renegotiation of charge schedule)

Every 60s at the latest

2 – 5s after incoming request



The fantastic four (message sets)

§ Four message sets to be applied depending on identification mode and charging mode

External Identification Means (EIM)(e.g. RFID, NFC, cash payment)

Plug and Charge (PnC)(authentication & authorisation via charge cord)

AC ChargingEIM

DC ChargingEIM

Optional

Value Added

Services(VAS)

Optional

Value Added

Services(VAS)

AC ChargingPnC

DC ChargingPnC

Optional

Value Added

Services(VAS)

Optional

Value Added

Services(VAS)

Identification mode Message set

Optional

CertificateUpdate

Optional

CertificateInstall

Optional

CertificateUpdate

Optional

CertificateInstall



Parameter-based selection of message set

09.10.15

ISO 15118-2 document: Figure 97 – Selectionof Message Sets



ISO/OSI Layers and related protocols

09.10.15

( (



V2G message definition on application layer

Header(8 Bytes)

Payload (Application layer messages)(0 - 4294967295 Bytes)

§ Remember the V2GTP (V2G Transfer Protocol) structure?

§ Each application layer message (after SDP is finished) is a V2GMessage

V2GMessage

Header Body

§ SessionID: unique identifier of V2G comm. session§ Notification: used by SECC in case of error situation§ Signature: used if certainV2G messages requires to

be signed

§ Body: A request or response message of a chosen message set



In-depth slides aboutapplication layer messages in ISO 15118

available via workshop/training on request



Guidance Through TheISO 15118-2 Document

09.10.15



Requirement structure

§ ISO 15118-2: 350 pages

§ Around 850 requirements in total

§ Some topics (such as security aspects) not encapsulated in single chapter but spreadacross several chapters

[V2GY-XXX] the requirement textRepresents the ISO 15118 set of standards

Individual requirementnumber

Document part of the ISO 15118 document set (1 – 8)



ISO 15118-2 document: Figure 35 – Schema Diagram -ChargeParameterDiscoveryReq

1 Schema diagram

09.10.15

ChargeParameterDiscovery request: Schema diagram

Optional parameter

Message setdependant subtypes

§ When implementing a certain message, have a look at§ 1) schema diagram, 2) table for semantics, 3) related requirements§ 4) XSD file (in case of ambiguity)



ChargeParameterDiscovery request: Semantics table


ISO 15118-2 document: Table 38 – Semantics and type definition forChargeParameterDiscoveryReq

2 Semantics table

Optional

Simple type / complex type



ChargeParameterDiscovery request: Requirements


ISO 15118-2 document: Excerpt from requirements related to ChargeParameterDiscoveryReq message

3 Related requirements



ChargeParameterDiscovery request: XSD definition


ISO 15118-2 document: Excerpt fromAnnex C.6 V2G_CI_MsgDataTypes.xsd

4 XSD file



ChargeParameterDiscovery request: XSD definition


ISO 15118-2 document: Excerpt fromAnnex C.6 V2G_CI_MsgDataTypes.xsd

4 XSD file



Further guidance to the ISO 15118-2 document

§ Response Codes: see Table 112 on page 194

§ State machine for AC and DC messages with respective requirements: see Figure 101 on page 200 (ff.)

§ Schema definitions: see Annex C on page 260 (ff.)

§ SAScheduleListType: see 8.5.2.12 on page 119 (ff.)

§ Message examples: see Annex D on page 284 (ff.)e.g. „Time of Use-based SalesTariffs includingrelativePricePercentage“ on page 295 (ff.)

§ Application and implementation of certificates: see Annex E, page 305 (ff.) andAnnex F, page 319 (ff.)

§ EVSE-ID and contract ID semantics: see Annex H, page 329

§ Signature implementation: see Annex J, page 336 (ff.)

Pleaseread the standard

thoroughly and ask theISO 15118 user group

if questions arise!



Security in ISO 15118:Confidentiality, Integrity and Authenticity

09.10.15



The 3 main aspects of security

§ ConfidentialityA message‘s content may only be read by the intended recipients, but not by unauthorised third parties

Encryption and decryption by means of asymmetric/symmetric cryptography

§ IntegrityAn unauthorized modification of the sent message must be avoided or at least bedetected

Creation and verification of digital, XML-based signatures

§ AuthenticityIt must be verifiable if the communicating parties really are the ones which theyclaim to be

Creation and verification of digital, XML-based signatures



Usage of a hybrid cryptographical system

Hybrid crypto system

Asymmetric crypto system Symmetric crypto system

§ Different keys (public / secret) for en- and decryption

§ Secure exchange of shared secret overunsecure channel possible

§ Expensive (CPU power)

§ Identical key for en- and decryption§ Secure exchange of this key needs

to be taken care of§ Less CPU power needed

(compared to asymmetric systems)

Used for calculation andexchange of a shared secret

Used for en-/decryption of sessionmessages with shared secret(session key)



Random number

09.10.15

The essentials of security shortly explained

Secret key

Public key

Generation of keys

§ Usage of key pairs in asymmetric cryptography (1 key pair / communicating party)

For decryption &creation of signatures(enabling authentication)

For encryption &verification of signatures(and thus authentication)




Secret key

Public key

§ Encyption with public key and decryption with private keyusing asymmetric cryptography

Advantage: communicating parties don‘t have the hassle to secretly exchangethe same key for en-/decryption before communication starts

Plain text Encrypted text




Secret key

Public key

§ Signing with private key and verifying with public keyusing asymmetric cryptography

Signature Plain text



Security parameters used in ISO 15118-2

§ ECDH (Elliptic Curve Diffie-Hellman) key exchange

§ Key length of asymmetric keys: 256 Bit

§ Symmetric crypto system AES-CBC-128

§ SHA 256 hash algorithm

§ Elliptic Curve Digital Signature Algorithm (ECDSA)

§ X.509 v3 certificates

§ PKCS#12 container for certificate chains and keys



In-depth slides aboutcryptography in ISO 15118




DKE Arbeitskreis fokussiert Zertifikatshandling

§ DKE/AK STD_1911.11.5 / AK 353.0.8 „Informationssicherheit für Elektromobilität“

§ Ziel: Erstellung einer Anwendungsregel für die Applikation geeigneter Zertifikate (und entsprechender PKI) durch sämtliche beteiligte Marktakteure im Rahmen der ISO 15118

§ Ansprechpartner: Andreas Harner (DKE)



TLS protocol allows for application of security concept

§ The Transport Layer Security (TLS) protocol allows for several standardized„cipher suites“

§ Allowed cipher suite in ISO 15118-2:

TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256

TLS protocol

Asymmetrickey exchangeusing ECDH

Signaturealgorithm ECDSA

Symmetric cryptosystemAES

AES with 128 Bitkey length in CBC mode

Hash algorithmSHA 256



Certificate Handling

09.10.15



Certificate types and PKI hierarchy concept

09.10.15

ISO/FDIS 15118-2:2013(E)

© ISO/IEC 2013 – All rights reserved 305

E.1.5 Overview of the resulting certificate structure

Figure E.1 — Overview certificate structure

Figure E.1 provides a visual overview of the resulting certificate structure and relevant validity periods.

As one can see, the OEM Provisioning Certificates are independent from the PKI of the secondary actors below the (global) root certificates. The root certificate of an OEM Provisioning Certificate is created by the OEM itself. Therefore, there is no need to have a (longer) certificate chain. (For an explanation of the usage of the OEM Root Certificate and the OEM Provisioning Certificate refer to Annex 0. It is, however, allowed to reuse a V2G Root as a Mobility Operator Root Certificate or an OEM Root Cert ificate (suggested with dotted lines)

All certificate chains have a maximum length of 3; i.e. including the root certificate 4 certificates are involved.

The certificate chain of an SECC is transmitted to the EVCC to enable an authenticity check of the SE CC before a TLS connection is established (cf. above: in order to avoid man-in-the-middle attacks).

The certificate chain of a Contract Certificate is transmitted into the EVCC without a Root CA. This limits the transmission to 3 certificates, but this also means, that the vehicle cannot verify its own Contract Certificate.

E.2 provides an example of simplified certificate management in private environments.

ISO 15118-2 document: Figure E.1 – Overview certificate structure



In-depth slides aboutcertificate handling in ISO 15118




Value Added Services

09.10.15



Value Added Services (VAS)

§ Certificate installation/update is a VAS, many more are possible§ Reservation of charge points§ Downloading updated POI/navigation data§ Multimedia (audio/video)§ .....



International Application, Testivals & User Group

09.10.15



Internat. conformance and interoperability test events

§ Already four ISO 15118 test events (testivals) taken place§ 3 of 4 on international level (Dortmund, Tokyo, Chicago)



ISO 15118 User Group

§ Purpose§ Platform to exchange and discuss questions & answers regarding the

implementation of ISO 15118 standard requirements§ Get a common understanding and ensure interoperability

§ Access§ Visit http://extmgmt.kn.e-technik.tu-dortmund.de/§ For an account, mail to: [email protected]



Available SoftwareTo Get You Started

09.10.15



OpenV2G project – Open source implementation in C

§ Licensed under the GNU LGPL v3§ First open source project on EV charge communication, initiated by Siemens

CT in cooperation with TU Dortmund, CNI)§ Addresses EXI-based V2G encoding/decoding (proof-of-concept)§ Supports EXI codec for both ISO 15118 (AC/DC) and DIN 70121 (DC)

§ Project page: http://openv2g.sourceforge.net/§ Sourceforge code: http://sourceforge.net/projects/openv2g/files/



eNterop Open Source - Reference implemenation in C

§ Funded by the BMWi during the eNterop research project§ Reference implementation of EVCC side (only EIM)§ Uses OpenV2G for message encoding/decoding

§ Sourceforge code: http://sourceforge.net/p/enterop/code/ci/master/tree/ReferenceImplementation/



RISE V2G – Open source implementation in Java

§ Licensed under the Eclipse Public License v1.0§ First complete reference implemenation of ISO 15118-2

§ AC and DC§ EIM and PnC (including security aspects)

§ Intellectual property (IP) due diligence done by Eclipse Foundation§ Safe for use in commercial software (if license requirements are followed)

§ Feel free to join me and contribute on GitHub: https://github.com/eclipse/risev2g



EXI codecs

§ EXIficient (written in Java)§ Implementation of the W3C Efficient XML Interchange (EXI) format

specification§ Project page: http://exificient.sourceforge.net/§ Licensed under the GNU GPL v2.0§ Not applicable in commercial products (because of copy-left license type), but

good to get started

§ OpenEXI (written in Java)§ Implementation of the W3C Efficient XML Interchange (EXI) format

specification§ Project page: http://openexi.sourceforge.net/§ Licensed under the Apache License, Version 2.0 § Compatible with Eclipse License project RISE V2G uses OpenEXI



Online RessourcesFor Further Information

09.10.15



Online ressources for further information

§ ISO 15118-1 standardisation document (Use Cases)(http://www.beuth.de/de/norm/iso-15118-1/187351349)

§ ISO 15118-2 standardisation document (Network and application protocol)(http://www.beuth.de/de/norm/iso-15118-2/205494624)

§ ISO 15118 User Group (http://extmgmt.kn.e-technik.tu-dortmund.de)

§ Dissertation (http://digbib.ubka.uni-karlsruhe.de/volltexte/1000042102) on:„Das Elektrofahrzeug als flexibler Verbraucher und Energiespeicher im Smart Home“ („The electric vehicle as a flexible load and energy storage device in a smart home“)

§ Der Insider-Blog zur Elektromobilität (www.smart-v2g.info/blog)

§ Normungsroadmap Elektromobilität (https://www.dke.de/de/std/e-mobility/Seiten/E-Mobility.aspx)



Date post:	28-Sep-2018
Category:	Documents
Upload:	dothu
View:	242 times
Download:	10 times

Workshop zur ISO 15118 · cle inlets Conductive charging of electric vehicles, Geneva, ... J....

Documents