EVS27Barcelona, Spain, November 17 - 20, 2013

Evaluation of OCPP and IEC 61850for Smart Charging Electric Vehicles

Jens Schmutzler1, Claus Amtrup Andersen2, Christian Wietfeld1

1Dortmund University of Technology, Communication Networks Institute, Dortmund, Germany,EMails: jens.schmutzler@tu-dortmund.de, christian.wietfeld@tu-dortmund.de

2EURISCO Research & Development, Odense, Denmark, EMails: caa@eurisco.dk

Abstract

Interoperability of charging infrastructures is a key success factor for E-Mobility. Standards likeISO/IEC 15118 and IEC 61851-1 are developed to ensure base level interoperability of front-end com-munication and signaling processes for smart charging between electric vehicles and charge spots. Withthe Open Charge Point Protocol (OCPP) a forum of European industry members also moves towardsa common back-end protocol for charge spots intending to reduce and secure overall investment costs.However, in the current form OCPP lacks means for enabling grid services based on smart charging.In this paper the authors provide a review of today’s state of the art in ISO/IEC standardization of theV2G Interface and furthermore detail how OCPP could leverage existing standardization efforts for gridautomation from IEC 61850 in order to overcome its shortcomings.

Keywords: Smart Charging, OCPP, IEC 61850, ISO/IEC 15118, Vehicle-to-Grid Communication Interface, V2G

1 Introduction

With the introduction of EVs certain challengesarise for the power grid since it was deployedat times, when such additional loads were notyet considered. Assuming mass market adop-tion of EVs this inevitably comes along with highchances for concurrent charging processes andtherefore overload of low voltage grid segments.In order to address these issues and ensure inter-operability between charging infrastructures ofvarious vendors, standardization bodies like ISOand IEC are busy defining corresponding stan-dards for E-Mobility. As of today, core effortswere spent in front-end issues of E-Mobility, likeplugs, in- & outlets, electrical and safety require-ments, as well as the front-end communicationinterface in order to ensure common access to EVcharging infrastructures. Back-end and grid inte-gration approaches were developed individuallyas part of research and pilot projects leading toproprietary solutions reflecting the situation ontoday’s market. However, in terms of operationalaspects as well as for securing the industry’s in-vestments in charging infrastructures it may be

beneficial to standardize back-end integration as-pects of charging infrastructures in the long term.According to the European Commission’s cli-mate and energy targets set in 2007 as well asfollowing directives like 2009/28/EC [1] on theuse of energy from renewable sources, EVs areconsidered to provide their share reducing CO2emissions in the transport sector. Being shiftableloads as well as regularly available energy stor-ages in the low-voltage grid, they are furthermoresupposed to provide a certain benefit to grid sta-bility in conjunction with increased penetrationof renewable energy sources. In that sense theintegration of EVs and charging infrastructuresneed to be extended beyond the current scopeof purely operational aspects being covered bytoday’s solutions. In order to integrate seam-lessly in tomorrow’s grid infrastructures a lookinto the IEC standardization roadmap [2] is nec-essary. They define IEC 61850 as core standardfor grid automation and consider it as the coredriver of Smart Grid development in the mid- andlong-term.Hence this work analyzes the alignment of theOpen Charge Point Protocol (OCPP) - today’s

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 1

most commonly used and openly available back-end communication protocol for charging infras-tructures - and IEC 61850 in order to overcometoday’s lack of grid integration for charging in-frastructures of EVs. In sections 3 and 4 bothapproaches for back-end integration are evalu-ated and differentiated from each other. In sec-tion 5 the authors summarize the lessons learnedand provide an outlook on smart charging us-ing OCPP and IEC 61850. But before go-ing into such detail, some background on op-erational aspects of charging infrastructures andhow plugged-in EVs can be characterized as gridassets is needed. Hence, the following sectionprovides an overview on current state of the artconsidering the E-Mobility V2G Interface.

2 Standardization Landscape ofthe E-Mobility V2G Interface

Standardization for the V2G Interface in E-Mobility already has a long history which latelyexperienced major increase of interest and de-velopment. The global interest in reducing CO2emissions in the transport sector and its result-ing economical interests impacting two of theworlds largest industrial domains (utilities andautomotive) led to extensive industrial support inresearch and development. The resulting stan-dardization landscape of E-Mobility can be clas-sified in the following four domains:

1. Plugs (in- & outlets)

2. Charging Topologies

3. Communication

4. Security

5. Safety

The remainder of this section will walkthrough each domain highlighting correspondingISO/IEC standardization work. An overview ofthe landscape is shown in Figure 1.

Electric Vehicle

2

3

1

5

Plugs, In- & Outlets

Charging Topology

Safety

IEC 62196-1

IEC 62196-2

IEC 62196-3

IEC 61851-22

IEC 61851-1

IEC 61851-24

IEC 61851-23

IEC 61851-21

IEC 61439-1

IEC 61140

IEC 62040

IEC 60529

IEC 60364-7-722

ISO 6469-3

ISO 17409

IEC 61980-1

IEC 61439-7

IEC 61980-2

IEC 61980-3

ISO/IEC 27000

IEC 62351

4 Security

Communication

IEC 61850ISO/IEC 15118

Figure 1: Digest of main ISO/IEC standards for thescope of the E-Mobility V2G Interface based on [3]

2.1 Plugs (in- & outlets)The IEC 62196 standards series is defined inTC23/SC23 and currently comprises three parts.The first part defines general requirements fordedicated plugs, socket outlets, vehicle connec-tors and vehicle inlets for interfacing a dedicatedcharging equipment with an EV. The current ver-sion was released end of 2011 and representsthe second edition of this standard. However,work on the third edition has already started inthe meantime. The second part defines the di-mensional compatibility and interchangeabilityrequirements for AC plugs (in- & outlets). Thestandards defines three different types of connec-tors, type 1 for single phase charging supportingcharging rates of up to 7.4kW. Whereas type 2supports single and three phase charging, the lat-ter with rates of up to 44kW. In January 2013 theEuropean Commission declared the type 2 con-nector as a common basis for charging infras-tructures and EVs in the European Union. Partthree of the standard defines dimensional com-patibility and interchangeability requirements forDC plugs (in- & outlets) as well as Combo Plugs(combined AC & DC plugs and in- & outlets).Until today this part is still work in progress andnot yet published as an international standard.The relevance of IEC 62196 regarding interoper-ability of the V2G interface is limited to physicalspecifications in terms of signaling pins and con-nector compatibility (physical layout & dimen-sions).

2.2 Charging TopologiesDifferent charging topologies need to be con-sidered for conductive AC- and DC-based ded-icated charging equipments. Such EV charg-ing equipments are defined in the IEC 61851standards series. The first part describes gen-eral requirements for conductive charging sys-tems. It applies to on-board and off-board ACand DC charging equipment and also to any ad-ditional services on the vehicle which may re-quire electrical power when connected to thesupply network. It defines four different charg-ing modes starting from slow charging usinghousehold-type socket outlets to fast charging us-ing an external charger. It also defines char-acteristics and operating conditions of the sup-ply device and the connection to the vehicle aswell as the operator’s and third party’s electri-cal safety. IEC 61851-1 specifically defines asafety-related low level signalling process basedon a Pulse Width Modulation (PWM) signal in-dicating various EV connection states, supportedcharge currents and communication means. ThePWM signal provides means for handling time-critical state changes, some of them even withrespect to individual safety. Hence, IEC 61851-1is a cross-cutting standard in terms of the pre-viously mentioned domains, dealing with charg-ing topologies, safety and communication (on asignalling level). The second edition was re-leased end of 2010 but work is already ongoingfor the third edition of this standard. The secondpart IEC 61851-21 describes technical require-

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 2

ments relevant for EVs being connected to AC orDC EVSEs. Two further sub-parts of this stan-dard detail the EMC requirements of on-board(IEC 61851-21-1) or off-board (IEC 61851-21-2)chargers. The following parts IEC 61851-22 andIEC 61851-23 detail specific requirements forAC- or DC-based EVSEs, respectively. Part 24of IEC 61851 is described in section 2.3.The charging topologies and relevant technicalrequirements for inductive charging equipmentsare defined in IEC 61980-1 where specific re-quirements on the magnetic field power transfersystems are detailed in IEC 61980-3.General rules and definitions for service condi-tions and technical characteristics as well as con-struction and verification requirements for low-voltage switch- and controlgear assemblies aredefined in IEC 61439-1. However, this part ofthe standard cannot be used alone to specify anassembly or for the purpose of determining con-formity because such compliance can only beachieved in combination with an additional rel-evant part of the IEC 61439 detailing a spe-cific type of assembly; such being specified inParts 2 onwards. For dedicated charging equip-ments IEC 61439-7 is foreseen but still work inprogress.

2.3 CommunicationIn order to define the V2G Communication Inter-face the ISO/IEC 15118 Joint Working Group 1(JWG1) was formed in 2009. Its purpose is to de-fine a bidirectional IP-based communication pro-tocol complementary to the low level signallingdefined in IEC 61851-1. JWG1 started definingthe first three parts in 2009. ISO/IEC 15118-1defines all relevant terms for the V2G Interfaceand provides basic definitions and use cases be-ing considered as part of the specification. It wasreleased in early 2013. The technical specifica-tions of the standard for conductive charging aredefined in ISO/IEC 15118-2 and ISO/IEC 15118-3 and are still work in progress. Part 2 definesthe IP binding process, complete message flowsand data types for AC and DC charging between

Legend

PnC: Plug & Charge

EV Controller EVSE Controller

Application Prot. Handshake

Service & Payment Selection

Payment Details (PnC)

Contract Authentication

Charge Parameter Discovery

Session Setup

Service Discovery

Service Details (opt.)

Certificate Inst. / Upd. (opt., PnC)

Session Stop

Contactor ONContactor OFF

......

loop ChargeControl

Power Delivery

Charging Status

Metering Receipt (opt., PnC)

Power Delivery......

AC specific Messages

DC specific Messages

loop CableCheckCable Check

Pre-Charge

Power Delivery

Current Demand

...

Power Delivery

Welding Detection

loop PreCharge

loop ChargeControl

...

AC / DC specific Messages

Setup

Charge

Finalization

Figure 2: DIS ISO/IEC 15118-2 V2G Message Flows

communication controllers in EVs (EVCC) andcharge spots (SECC) as shown in Figure 2. Part3 defines the physical and data link layer require-ments of the powerline communication basedcarrier technology including the association pro-cess. The envisioned high level communicationprotocol will allow for advanced interaction be-tween the grid and connected EVs for authenti-cation & authorization, accounting, load level-ing management and further added-value ser-vices. The primary scope of the standard is lim-ited to the communication between the EVCCand SECC as illustrated in Figure 3.

SA Service Impl.InterfaceSA Service Impl.Interface

Backend Comm.Frontend Comm.

Charge Spot

Secondary Actors

Electric Vehicle

Service

Providers

Spot

Operators

s

EVCC

Service Impl.Interface

SECC

Service

Impl.

Interface Interface

IN scope of ISO/IEC 15118:

Complete technical

specification for Front-End

Communication Interface

between EVCC and SECC

NOT in scope of ISO/IEC 15118:

Backend Communication

Interfaces to Secondary Actors

Electric Vehicle

Primary Actors

IN scope of ISO/IEC 15118:

Specification of trustworthy End-to-

End (EV to Backend) Data Sets,

e.g. Auth. Credentials, Tariffs,

Schedules etc.)

Interface SA Service Impl.

Figure 3: Scope of ISO/IEC 15118

Subsequently to the first three parts, the jointworking group started new projects in 2012 todefine conformance tests of the technical spec-ifications as part of ISO/IEC 15118-4 (part 2conformance tests) and ISO/IEC 15118-5 (part3 conformance tests). Further work was alsostarted for the definition of wireless physical anddata link layers of the V2G Communication In-terface in ISO/IEC 15118-8. Next to commu-nication means for inductive charging scenarios,such an alternative carrier will also bring alongnew use cases even for conductive charging sce-narios. A complementary set of use cases suit-able for wireless carriers are therefore defined inISO/IEC 15118-6. An additional alignment spec-ification targeting document ISO/IEC 15118-7will introduce all differences and new messagesets compared to the core message specification(ISO/IEC 15118-2) in powerline communicationbased scenarios. However, all these parts are invery early stages of the standardization process.IEC 61851-24 defines the digital communicationbetween a DC charging equipment and an EV forthe control of the charging process. The standardis still work in progress and currently details var-ious different technical approaches in its annex.One approach represents the CHAdeMO charg-ing systems [4] which employs a CAN interfacebetween the EV and the charging equipment.Another annex references the technical detailsdefined in ISO/IEC 15118-2 and ISO/IEC 15118-3 without changing or extending the specifica-tion in any way. The same applies for the pro-posed work in IEC 61980-2 for inductive charg-ing which is supposed to be referencing the up-coming parts 7 and 8 of the ISO/IEC 15118 se-ries. However, at this time all standardizationefforts regarding wireless communication for ei-ther inductive or conductive charging of EVs arein very early stages.

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 3

Today, the IEC standards landscape does notcover a specific back-end protocol for EV charg-ing infrastructures. One potential candidate maybe IEC 61850 which focuses on grid automationfor various types of grid assets. Its latest ad-vancements in the direction of automation in thecontext of Distributed Energy Resources (DER)is particularly interesting for the E-Mobility do-main. However, the scope of IEC 61850 is muchbroader and originates from the substation au-tomation domain. The standards comprises morethan ten parts where those of relevance for thiswork will be more closely discussed in section 4.

2.4 SecurityDue to the extended amount of Machine-to-Machine (M2M) communication in the contextof E-Mobility as introduced in 2.3, there is sub-stantial need for information and communicationsecurity in the context of smart charging EVs.In contrast to conventional road vehicles, EVsregularly connect to public and heterogeneousinfrastructures and exchange partly confidentialinformation. For the OEM domain this is afairly new use case scenario with special require-ments in terms of information security as wellas privacy. Hence, information security playsa key role in the definition of ISO/IEC 15118-2. Next to securing the communication chan-nel between the EVCC and the SECC throughthe establishment of a TLS channel, some end-to-end security requirements are addressed be-tween the EVCC and secondary actors, likecharge spot operators, service providers, etc. (seeFigure 3). Most dependencies on such exter-nal secondary actors are limited to authentica-tion/authorization for service consumption, tar-iffing/billing issues or grid operation purposeslike negotiation of dynamic grid limits. Messageelements of ISO/IEC 15118-2 with relevance re-garding these aspects are handled through end-to-end security by XML security, particularlyXML Signature [5] and XML Encryption [6] inthe application layer.IEC 61850 does not provide its own securitymechanisms. It refers to IEC 62351 which con-solidates security aspects for all communicationstandards within TC57. The security aspects be-ing covered by IEC 62351 start at security poli-cies and procedures like Role Based Access Con-trol (RBAC), but also include message and trans-port security as well as network- and media se-curity. A very important aspect being required inIEC 61850 is RBAC on data objects and corre-sponding measures for intrusion detection. Suchmeasures are defined as part of the Generic Se-curity Application (GSAL) logical node whereasIEC 62351-8 defines corresponding roles of ac-cess and the underlying RBAC architecture. Sim-ilarly to ISO/IEC 15118, message and trans-port layer security include authentication of dataaccess and transfer for routable network trafficbased on SSL/TLS with digital signatures ensur-ing the prevention of eavesdropping, playbackand spoofing.ISO/IEC 27000 is typically referenced as com-mon denominator for terminology in the scope of

information security. The standard’s series wasstarted as a joint effort between ISO & IEC defin-ing the scope of Information Security Manage-ment Systems, not only for power systems.

2.5 SafetyIn terms of safety requirements for EV charginginfrastructures, IEC 61140 defines common as-pects for the installation and equipment of elec-trical assemblies in order to ensure protectionof persons and animals against electric shocks.It is intended to provide the fundamental prin-ciples and requirements which are common toelectrical installations, systems and equipmentor necessary for their co-ordination. Closely re-lated to IEC 61140, IEC 60529 defines the de-grees of protection which must be provided byenclosures of electric equipments. Extending thescope of these rather general safety standards,IEC 60364-7-722 particularly defines safety re-quirements for supply equipments of EVs in lowvoltage electrical installations. It furthermorealso covers safety requirement for reverse energyflow from the EV back to public grid infrastruc-tures. The work on this part of the standard isstill in progress.Related to maintenance work and also reverseenergy flow, IEC 62040 is also in the scope ofsafety requirements for E-Mobility. It definesgeneral and safety requirements for Uninterrupt-ible Power Systems (UPS) with an electrical en-ergy storage device in the DC link. The scopeof the standard is applicable to movable UPS inlow-voltage distribution systems which are fur-thermore intended to be installed in any operatoraccessible area or in restricted access locations.It specifies requirements to ensure safety for theoperator, service personnel and any layman whomay come into contact with the equipment.On the EV side, ISO 6469-3 published in 2011defines the safety specifications for EVs in orderto ensure protection of persons inside and outsidethe vehicle against electric shocks. In this scopeit details the specific requirements for electricpropulsion systems and, if appropriate, conduc-tively connected auxiliary electric systems. Fur-thermore, ISO 17409 defines safety requirementsfor the connection of an EV to an external elec-tric power supply. This standard is still work inprogress and only applies to on-board chargingcircuits. It is complementary to the definitionsin the IEC 61851 series and focuses on the roadvehicle’s side.

2.6 Back-End CommunicationRelevance

The review of the E-Mobility standardizationlandscape from previous subsections allows usto assess the relevance of each domain regard-ing front- and back-end communication. Table 1summarizes the result of this assessment accord-ing to the following scale: (- -) not relevant, (-)marginal relevance, (o) neutral, (+) relevant, (++)substantial.

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 4

Domain Front-EndComm.

Back-EndComm.

Plugs (In- & Outlets) (+) (-)Charging Topologies (++) (+)Communication (++) (++)Security (++) (++)Safety (+) (-)

Table 1: Relevance of E-Mobility StandardizationDomains for V2G Front- & Back-End Comm.

3 Open Charge Point ProtocolWith the Open Charge Point Protocol (OCPP)a forum of European industry members wasformed to define an open back-end protocol forcharge spots which was initially started by e-laadin 2009 for their back-end system. The OCPP fo-rum today has many members who agreed upona common basis for their back-end protocol aim-ing at reducing overall integration and investmentcosts for charge spot development and operation.The initiative started with basic functionality likestarting or stopping a charging transaction as wellas basic asset management functionality for re-mote access & configuration means, diagnostics,firmware updates etc.

3.1 Technical Principals of OCPPVersion 1.5 of OCPP specifies operations be-tween a charge spot and a central system, typi-cally operated by one charge spot operator. Cer-tain operations are defined to be invoked on thecharge spot whereas others are considered for in-vocation at the central system only. In order toallow such bidirectional service invocation, twoservices are defined: Charge Point Service (CPS)and Central System Service (CSS). Figure 4 il-lustrates the overall concept of OCPP 1.5.The OCPP specification only allows Request-Response Message Exchange Patterns (MEP) be-tween both services. Other MEPs like One-Way, Notification or Solicit-Response are not de-fined. Both OCPP services are based on WebServices paradigms adopting the SOAP 1.2 mes-sage framework. The interface description forthese services is based on a WSDL which is pub-lished on the OCPP website. According to thespecification the communication channel shouldbe secured by HTTPS over SSL/TLS. In Figure 5the complete OCPP 1.5 protocol stack is shown.

OCPP Charge BoxOCPP Central System

Central System Client Central System Service

ChargeBox.Req(Msg Parameters)

Charge Box Client Charge Box Service

CentralSystem.Req(Msg Parameters)

ChargeBox.Resp(Msg Parameters)

CentralSystem.Resp(Msg Parameters)

Figure 4: OCPP 1.5 Architecture and MEPs

Application Process

TCP/IPLayers

L5 Application

Transport

Network

Data Link

Physical

L4

L3

L2

L1

HTTPS 1.1

IPv4 (RFC 791) / IPv6 (RFC 2460)

TLS

TCP (RFC 1006)

SOAP 1.2

Not in Scope of Specification

(e.g. GPRS, UMTS, HSPA)

Information &

Message Binding

(WSDL 1.1)

Information Model

(XML Schema 1.0)

FTPS

WS-Addressing, WS-Policy

XML 1.0

Figure 5: OCPP 1.5 Protocol Stack

The OCPP specification currently defines the fol-lowing list of largely self explanatory messagesets which are shown in Table 2.All these messages are defined in the WSDLdescription and describe atomic operations be-tween the invoking client and its correspondingservice. Other than WS-based message transac-tions, OCPP also defines FTP file transfers (seeFigure 5) as part of the firmware update process(FTP download triggered by Update Firmware)and for diagnostic purposes (FTP upload trig-gered by Get Diagnostics).

Service Supported OperationsOCCP CentralSystem Service(CSS)

AuthorizeBoot NotificationData Transfer (Vendor-specific)Diagnostics Status NotificationFirmware Status NotificationHeartbeatMeter ValuesStart / Stop TransactionStatus Notification

OCCP ChargePoint Service(CPS)

Cancel ReservationChange AvailabilityChange ConfigurationClear CacheData TransferGet ConfigurationGet DiagnosticsGet Local List VersionRemote Start / Stop TransactionReserve NowResetSend Local ListUnlock ConnectorUpdate Firmware

Table 2: Supported Operations in OCPP 1.5

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 5

Figure 6: Screenshot of EURISCO OCPP Test Bench Software with SOAP Messaging Log

3.2 Evaluation of OCPP 1.5Based upon the experience the authors gatheredduring the implementation process of OCPP 1.5clients and services we provide our lessonslearned from following three perspectives: Func-tional scope/limitations of OCPP, issues anddrawbacks from an operational / technical pointof view, and maturity of the OCPP 1.5 specifica-tion.

3.2.1 Functional Scope and Limitations

Starting with the functional scope of OCPP 1.5we found in section 3.1 that in its current formOCPP is highly tailored towards the charge spotoperator’s business. It fulfills all main require-ments regarding the charge process, such as au-thentication and authorization, transaction han-dling, metering, reservation of a charge spot. Italso supports maintenance tasks like status no-tifications, configuration and firmware handling,diagnostics, and internal support functions likeresets, clearing of caches etc. It provides meansfor vendor-specific and therefore proprietary ex-tensions for an operator’s internal use. However,grid-related services, e.g. demand managementby utilizing the functionality of ISO/IEC 15118are currently missing. Smart charging of EVs inthe sense of a grid service is therefore not yetconsidered in OCPP 1.5. The specification fur-thermore does not consider Role Based AccessControl (RBAC) which might become essentialin the future.

3.2.2 Technical Issues and Drawbacks

The use of SOAP-over-HTTP has many advan-tages in terms of the software development pro-cess for charge points due rich tool support, as

well as out of the box syntactic interface con-formance based upon the provided WSDL def-inition. However, the use of SOAP-over-HTTPalso leads to huge message overheads which maybe an issue for some operators and could be op-timized without loosing out on convenience ofWeb Services. Particularly in case of wirelessback-end communication links like cellular ra-dio access and in case of large scale charginginfrastructures, this issue might lead to ratherexpensive maintenance costs for operators. Byutilizing presentation layer formats like EfficientXML Interchange (EXI) these issues could be al-leviated. As the authors already showed in [8]using EXI provides a compression rate of up to5-10% for the message payload size of V2G mes-sages in ISO/IEC 15118. Similar improvementwould be feasible in case of using EXI for OCPP.Further improvement could be yield by optingfor ICMP ping-like heartbeat messages instead ofusing a SOAP-based Request-Response MEP.

3.2.3 Specification Maturity

Based upon our own experience with implement-ing OCPP we rate the maturity of the specifica-tion as average. Requirements should be clearlyidentified by a numbering scheme in order to al-low for requirement traceability in the develop-ment as well as in the testing phase. Confor-mance and interoperability issues are quite com-mon for various OCPP implementations since thespecification is quite vague e.g. in terms of forhandling security. With the help of example stubsand skeletons provided by the OCPP forum aswell as third party conformance testing tools likeEURISCO’s OCPP TestBench (see Figure 6),concrete conformance and testing tools are avail-able today, alleviating the lack of a concrete con-formance test specification.

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 6

4 IEC 61850 - CommunicationNetworks and Systems forPower Utility Automation

IEC 61850 represents a core standard for futureSmart Grid deployments and plays a particularlyimportant role in the grid automation domain ac-cording to the IEC roadmap [2]. Originatingfrom the domain of substations, the scope ofIEC 61850 was continuously extended integrat-ing various types of Intelligent Electronic De-vices (IEDs) in the energy distribution process,especially Distributed Energy Resources (DERs),like photovoltaic or combined heat & power, etc.IEC 61850 defines a set of abstract objects andservices virtualizing the state as well as function-ality of an IED in an abstract model making themaccessible to authorized parties.

4.1 Technical Principles of IEC 61850The modeling of an IED in IEC 61850 is strictlyobject-oriented and driven by its components andtheir corresponding functionality. Every abstractmodel of an IED is therefore composed of a setof Logical Devices and Logical Nodes. LogicalDevices represent components of IEDs whereasthe functionality of each Logical Device is de-scribed by a set of Logical Nodes. Each Logi-cal Node refers to an Object Information Model(OIM) which defines a concrete set data objectsand data attributes for the node. In order to inter-act with an IED, each Logical Node exchangesinformation through an Abstract CommunicationService Interface (ACSI) being assigned to cer-tain roles for Role Based Access Control (RBAC)on data objects and furthermore characterized byQuality of Service criteria. An overview on theabstract model of an IED is shown in Figure 7.IEC 61850 builds upon typical communicationnetwork protocol stacks like TCP/IP and/or Eth-ernet but may also be implemented over differ-

IED [1..n]

Function [1..n]

Logical Device [1..n]

Abstract

Comm.

Service

Interface

(ACSI)

Logical Node [1..n]

Specific Communication

Service Mapping (SCSM)

Object Information

Model (OIM)

Data

Object [n]

Common

DataClasses

Common

Attributes

[1..n

]

Standard

Data Types

[1..n

]

[1..n][1..n]

[1..n

]

Figure 7: Virtualization of Intelligent Electronic De-vices in IEC 61850

ISO/OSILayers

L7

L6

L5

Application

Presentation

Session

Transport

Network

Data Link

Physical

L4

L3

L2

L1

ISO/IEC 8326, 8327

IPv4 (RFC 791)

TLS

TCP (RFC 1006)

ASN.1 ISO/IEC 8822

Ethertype (ISO/IEC 8802.3),

...

MMS (ISO 9506)

A-Profile

T-Profile

Ethernet (RFC 894), ISO/IEC 8802-2 LLC, ...

Abstract Communication Service Interface

ACSI (IEC 61850-7-2)

Information Model

(IEC 61850-7-4, IEC 61850-7-420)Application

Process

Specific Communication Service Mapping (SCSM)

Figure 8: IEC 61850 Protocol Stack for MMS-basedSCSM

ent protocol stacks. It supports both client-serverand peer-to-peer communication paradigms. Theclient-server approach is typically used for lesstime critical communication services utilizingTCP/IP, whereas the peer-to-peer approach istypically used for real-time communication ser-vices directly using Ethernet, e.g. GOOSE. Inorder to define the concrete interface to net-working protocols and frame formats, the ACSIis extended by Specific Communication ServiceMappings (SCSM). One SCSM example for theclient-server based approach is the Manufactur-ing Message Specification (MMS) which buildsupon a TCP/IP stack and is defined in IEC 61850-8-1 [9]. The corresponding protocol stacks forthis specific SCSM are illustrated in Figure 8.As illustrated in Figure 8 the ACSI definition al-lows for a high level of abstraction between thedefinition of logical nodes including their com-munication services and concrete implementa-tions for underlying networking protocol stacks.It is therefore essential in terms of extendabil-ity towards other potential protocol bindings, likee.g. Web Service-based SCSMs which are cur-rently under development for IEC 61850-8-2, seealso IEC 61400-25-4 [10].

4.2 State of E-Mobility in IEC 61850In today’s published series of IEC 61850 stan-dards, EVs are not yet considered in IEC 61850-7-420 [11] as Distributed Energy Resources(DERs), even though EVs could act as energystorage for volatile energy generators such aswind power plants or PV plants. The authorsalready proposed an object model for electricmobility in [12] which was furthermore pub-lished in more detail as IEC Technical Report61850-90-8 in the meantime [13]. As shown inthese previous works the proposed object modelsatisfies the requirements of ISO/IEC 15118 aswell as IEC 61851-1 in terms of monitoring and

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 7

parametrization of an EV charging process. For acharge spot operator such functionality may be-come crucial in the future in order to provide gridservices to other stakeholders e.g. in the form ofDemand Response Mgmt. (DRM) or as part of atechnical head of a Virtual Power Plant (VPP).This section briefly summarizes the underlyingapproach.The first step in the modeling process was theanalysis of information being provisioned ac-cording to the E-Mobility standardization land-scape described in detail in section 2. As part ofthese standards a multitude of control and mon-itoring information is exchanged between tech-nical components being involved in the chargingprocess in order to ensure an automated and safecharging process. However, for managing EVsas DERs in the grid only a subset of this infor-mation is necessary and must be identified. Inorder to ensure a scalable system design it is ex-plicitly required to reduce level of detail in termsof information provisioning for upstream stake-holders, e.g. infrastructure operators.The second step in the modeling process ad-dressed the operators view on an interconnectedEV. In accordance with the first step, necessaryinput and output parameters for monitoring andcontrol purposes must be identified and modeledaccordingly. The modeling approach taken forthis work adheres to IEC 61850-7-420 guide-lines. Figure 9 provides an overview which enti-ties are involved in the information provisioningprocess, what information originates from whichentity and how this information is finally mappedto the proposed E-Mobility Object Model.The diamond shaped elements in the diagramdifferentiate three different types of informa-tion: Config, Setting, and Measurement. Configs(blue) describe persistent information, e.g. defin-ing hardware installation characteristics. Settings

Electric Vehicle

ISO/IEC 15118

Controller

IEC 61851-1

Controller

Cable & Plug

IEC 62196-2

EVSE

IEC 61851-1

Controller

SECC

ISO/IEC 15118

Controller

IEC 61850-7-420 EVSE

OperatorCommon

Information ModelInstallation

Plug Present

(PP)

Charge Cable

Rating

Connection

Type Selection

EV Connection

Status (Control

Pilot, CP)

Charge Power

Rating

Charging

Current Limit

Enable Dig.

Communication

EV Nameplate

Information

EVSE

Nameplate

Information

Available

Power for

Charging

EV Planned

Charging

Schedule

Config (Constant)

Setting: PWM

Duty Cycle on CP

Config (Constant)

Setting:

EVSE Schedule

Setting:

CP Voltage Level

Available

Connection

Types

Measurement:

CP Voltage Level

Measurement:

PWM Duty Cycle

Measurement:

PWM Duty Cycle

Setting: PWM

Duty Cycle on CP

Measurement:

PP Resistor

Measurement:

PP Resistor

Config (Constant)

Charging

Requirements &

Parametrization

DE

EV

DE

SE

DE

OL

DS

CH

Setting

(Depends on HW)

Config (Constant)

Setting:

EV Schedule

Setting:

Target Settings

Figure 9: E-Mobility Object Modeling Approach inIEC TR 61850-90-8 [12]

(green) describe dynamic configuration informa-tion of an entity which may change over timeand may be influenced from a secondary actor,like the EVSE operator. Measurements (red) areobserved at the respective entity and also repre-sent dynamic information. The actual informa-tion being provided by the respective entities issummarized in the common information model(orange) in Figure 9 and is mapped to the follow-ing three newly defined LNs of the E-MobilityObject Model:

1. DESE: This LN represents an EVSE whichmay house several outlets and contains in-formation related to monitoring and control-ling of the EVSE.

2. DEOL: This LN represents an individualEVSE outlet and contains information re-lated to monitoring and controlling of theoutlet.

3. DEEV: This LN represents a connected EVand contains information on an EV con-nected to an EVSE. If the connection / plugstatus indicates that no EV is connected theDEEV LN is unregistered.

The DSCH LNs in Figure 9 are re-usedfrom IEC 61850-7-420 and cover the twoway charge schedule negotiation handshake ofISO/IEC 15118 (see also [14]). In addition and asshown in Figure 10, a charging infrastructure op-erator may include further LNs known from thealready existing portfolio of LNs in IEC 61850-7-2, -7-4, -7-420 if necessary in order to repre-sent the charging infrastructure’s setup.

Electric Vehicle

Proposed E-Mobility Object Model for IEC 61850-7-420

Charge Spot

Safety &

Switching Devices

PLC

MMTR: Electric Energy Meter

XSWI: Contactor

XCBR: Circuit Breaker

RCCB: Residual Current Device

ZSAR: Surge Arrester

Secondary

Actors

System

Operators

Service

ProvidersMMTR

XCBR

XSWI

ZSAR

RCCB ZCABDEOL

DESE

DEEV

DSCH

DSCH

DESE: EV Supply Equipment

DEOL: EVSE Outlet

DEEV: Electric Vehicle

DSCH: Energy & Ancillary Service

Schedule

Figure 10: Example AC-Charging Deployment Sce-nario of the E-Mobility Object Model

This abstract model of the charging infrastructureallows for flexible physical designs of EV-basedDERs. The selection of LNs on the one handand adhering to their specification on the otherensures harmonized information models betweeninvolved actors, on top of independent underly-ing protocol bindings corresponding to the ACSIand SCSM.Demand & supply management is provided bysetting the charge spot’s DSCH Logical Node forthe Local Load Limit Profile as well as observ-ing the EV’s virtual DSCH Logical Node for theLocal Load Reservation Profile. Depending onwhether the EVSE controller acts upon one indi-vidual outlet or implements a load management

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 8

for several outlets, the DSCH schedules either re-fer to a single outlet and its corresponding EV oran aggregate of all managed outlets and the cor-responding set of EVs. The integrated sequenceincluding the ISO/IEC 15118 charge parameternegotiation process as well as handling of theDSCH Local Load Limit Profile and the DSCHLocal Load Reservation Profile is detailed in Fig-ure 11.

EV Controller EVSE Controller

Power Delivery

Charge Parameter Discovery

......

...

Charge Spot Operator

Set_LocalLoadLimitProfile

Report_LocalReservationProfile

2

4

1

3

5

6

1

2

3

4

5

6

Defines max. power over time to be consumed from feeder of the EVSE

User and EV target settings (energy amount to charge until departure time +EV limitations)

Max. power schedule for outlet refering to LocalLoadLimitProfile (1)

EV charging profile with indication of power to be consumed over time from outlet

Ackowledgement of EV charging profile unless EV violates max. power schedule from (3)

Report on local load profile associated to the EVSE

Figure 11: Load Management for Smart Chargingwith ISO/IEC15118 and E-Mobility Object Model ac-cording to IEC TR 61850-90-8

Based upon these principles, the current ver-sion of the proposed E-Mobility Object Model inIEC 61850-80-9 represents the functions summa-rized in Table 3:

Service Supported OperationsIEC 61850E-MobilityCharge PointService

Get EVSE (& EV) NameplateGet Charge Power RatingGet Charge Cable RatingGet Plug PresentGet (Available) Connection TypeGet State (A,B,C,D,E,F)Enable / Disable Digital Comm.Get User Target Settings (EnergyAmount, Departure Time)Get EV Charge Power RatingSet Local Load Limit Profile(EVSE/Station limits)Report Local Reservation Profile(EV/EV Pool Reservation)

Table 3: Overview of Supported Operations of IEC61850-90-8 E-Mobility Object Model

Note, Table 3 only refers to newly defined LNsas part of [13] that are also shown in Fig-ure 9. Other services and respective functionsmay be added by the means of already exist-ing LNs according to IEC 61850-7-2, -7-4, -7-420, e.g. metering capability through the LogicalNode MMTR.

4.3 Evaluation of IEC 61850 forE-Mobility

In line with the evaluation of OCPP in sec-tion 3.2, we look again at the following list of cri-teria: Functional scope/limitations of IEC 61850in E-Mobility context, problems and drawbacksfrom an operational / technical point of view, andmaturity of the IEC 61850 & E-Mobility ObjectModel specification.

4.3.1 Functional Scope and Limitations

In contrast to OCPP, the functional scope of theIEC 61850 E-Mobility Object Model is tailoredtowards grid services but at the same time lacksmany other operational aspects of the charge spotoperator’s business. The IEC 61850-90-8 designapproach considered from the very beginning allother ISO/IEC V2G standards and ongoing stan-dardization efforts. Hence, it fulfills all smartcharging requirements which are also consideredin the current proposition of e.g. ISO/IEC 15118-2. It is also extensible by other existing LNsfrom the Part 7 series of IEC 61850. However,basic functionality for charge spot operators likeauthenticating an user who wants to charge at acharge spot is missing because it was consideredout of scope of IEC 61850 from the very begin-ning and delegated to other specifications, e.g.IEC 61970, OCPP etc. In general, IEC 61850provides in conjunction with IEC 62351 RoleBased Access Control (RBAC) to operational gridstakeholders which might furthermore becomeessential in multi-use scenarios of charging in-frastructures.

4.3.2 Technical Issues and Drawbacks

The issue with IEC 61850 today is that comingfrom the substation domain it is not well inte-grated in heterogeneous environments due to itscurrently very restrictive and inflexible bindingtechnology which is based on the ManufacturingMessage Specification (MMS) dating back to the1990s. New binding mechanisms based on WebService technologies like SOAP or REST wouldallow much better integration with assets fromother domains as well as common IT back-endsystems and would furthermore simplify devel-opment for spot operators due to a much largertool-chain support. These aspects including a setof solution concepts are also already detailed bythe authors in [15] and supported by others in[16] and [17]. Working Group 17 of IEC TC57is also already investigating WS-based bindingsfor IEC 61850 and successfully proposed a re-spective new work item proposal for IEC 61850-8-2 in 2012. When moving towards Web Servicebased bindings, the use of a suitable presentationlayer technologies should also be considered aspreviously also indicated as potential improve-ment for OCPP in section 3.2.

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 9

4.3.3 Specification and Standard MaturityThe proposed E-Mobility Object Model forIEC 61850 was published as technical reportin TC57. It is currently revised to align withongoing standardization processes of surround-ing standards in the E-Mobility landscape, e.g.ISO/IEC 15118. In general, IEC 61850 hasa very long history and builds upon a matureset of specifications. However, the complex-ity of the standard, its long learning curves,and the complex standardization processes cer-tainly are disadvantages. New Web Service-based bindings might help to simplify applica-tion of IEC 61850 and gain larger audiences inthe industry. Especially in the domain of DERsit may help for quicker adoption rates, like it hasalready been adopted for wind power generationin IEC 61400-25-4.

5 Lessons LearnedThe previous analysis showed, that the technicalapproaches taken in OCPP 1.5 and IEC 61850with the proposed E-Mobility Object Model arequite different. Also from a functional point ofview there are only marginal overlaps betweenboth candidates. OCPP 1.5 clearly addresses thebusiness domain of charge spot operators whichare not necessarily directly interested in smartcharging of EVs. IEC 61850 on the other side isall about grid automation and therefore closer togrid stakeholders like plant and distribution sys-tem operators. With the trend towards an increas-ing amount of distributed energy supply, the needfor integrating EVs as DERs with a certain stor-age capacity and controllable demand curves willbecome more crucial in the long-term.From a technical perspective our evaluation onOCPP and IEC 61850 for smart charging of EVsresults in the following three feasible scenarios:

• Leveraging the IEC 61850 E-Mobility Ob-ject Model as Meta-Model for enablingSmart Charging in OCPP.

• Integrated approach for OCPP andIEC 61850 based on new IEC 61850-8-2Web Service Binding.

• Outlook on future releases.

5.1 IEC 61850 E-Mobility Meta-ModelThe first option describes the situation whereone or several implementations exist using theIEC 61850 E-Mobility Object Model as Meta-Model and abstract service interface but with-out the Specific Communication Service Map-ping (SCSM) according to IEC 61850. This ap-proach would ensure the use of a harmonized andcommonly agreed information model across var-ious back-end communication protocols. How-ever interoperability would fail on the interfacelevel due to the lack of vertical integration of dif-ferent SCSMs.

5.2 OCPP and IEC 61850 IntegrationAs described previously, the need for a WebService binding for IEC 61850 becomes moreand more important with new sorts of DERtypes being added to the IEC 61850 portfolio.Since OCPP is already based on a SOAP-basedmessage framework and binding mechanism, itwould be attractive for charge spot operatorsto use the same message framework and com-munication stack and integrate both OCPP andIEC 61850. The advantage of such a solutionwould be, that EV charging infrastructures couldstill be integrated as portfolio enhancement intoother IEC 61850-based pools of DERs, like com-bined heat & power, PV etc. without breakingeither the IEC 61850’s or OCCP’s paradigms.In order to combine the existing functionalityof OCPP with automated grid services throughsmart charging of EVs according to [13], ad-ditional service(s) based on the IEC 61850E-Mobility Object Model must be deployed onthe charge spot, next to the OCPP Charge PointService. Figure 12 illustrates the overall ap-proach. The WSDL of the new IEC 61850services corresponds to the IEC 61850 ACSIand maps the E-Mobility Object Model whichis defined in XML Schema to the supported setof operations and messages (WS-based SCSM).The applicable set of operations resulting froma combined setup with OCPP 1.5 and theIEC 61850 E-Mobility Object Model would bea joint version of Tables 2 and 3.

5.3 OutlookThe market may also develop in an entirely dif-ferent direction based upon a different/new ap-proach not considered in this work. At the timeof this writing OCPP 2.0 is also being preparedfor release. According to the OCPP roadmap,many of the issues highlighted in this paper arebeing addressed as part of the new release. Mostimportantly, OCPP 2.0 will integrate support forISO/IEC 15118, which marks the most impor-tant point of criticism in this work. However,since OCPP is solely tailored towards the man-agement and operation of EV charging infras-tructures, it will not provide seamless integra-tion with other types of DERs in the future asopposed to IEC 61850. The same remains truefor all other types of dedicated charging infras-tructure back-end protocols. A plant operatorwho is envisioning to consolidate demand andsupply from various heterogeneous sources, e.g.VPP, would need to support a multitude of proto-col stacks coming along with an additional pro-cessing burden for the plant controller as wellas potential interoperability issues and version-ing conflicts. This sought of software fragmenta-tion would furthermore complicate the softwaredevelopment and maintenance processes for thecontroller. In such scenarios, the option in 5.2with support of IEC 61850 would be beneficial,since all tasks could be handled according tothe same paradigms set by IEC 61850 across alltypes of DERs being used throughout a heteroge-neous plant setup. Hence, operators who in the

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 10

Backend Comm.Frontend Comm.

EV Comm. Controller

15

118

Inte

rface

Charge Point Communication Controller

15

118

In

terf

ace

Secondary ActorWS

Msg. F

ram

ew

ork

WS

Msg. F

ram

ew

ork

OC

CP

1.5

61

85

0

OC

CP

1.5

61

85

0

EV

Finite

State

Machine

EVSE

Finite

State

Machine

61850-90-8 Object Model

61850 Service

OCPP Object Model

Central System Client

Charge Point Service

61850-90-8 Object Model

61850 Service

OCPP Object Model

Central System Service

Charge Point Client

Figure 12: Combined OCPP and IEC 61850 Smart Charging Setup for ISO/IEC 15118

long run want to support advanced and in partic-ular heterogeneous DER setups are well advisedto consider such aspects from the very beginning.

AcknowledgmentsThe work in this paper was partly funded by theEuropean Commission as part of the 7th Frame-work Programme with grant agreement num-ber 285586. The authors would like to thankour partners in the corresponding EU researchproject e-DASH (www.edash.eu).

References[1] European Parliament and the Council of the

European Union, Directive 2009/28/EC on thePromotion of the use of energy from renewablesources and amending and subsequently repeal-ing Directives 2001/77/EC and 2003/30/EC, 23April 2009.

[2] SMB Smart Grid Strategic Group (SG3), IECSmart Grid Standardization Roadmap - Edition1.0 , June 2010.

[3] Nationale Plattform Elektromobilitt(NPE), Die deutsche Normungs-RoadmapVersion 2 (German StandardizationRoadmap V2), [Online] available at:http://www.elektromobilitaet.din.de, accessedon 14.02.2013

[4] CHAdeMO Association, CHAdeMO Specifica-tion Version 1.0.0, Published 31.01.2012.

[5] Eastlake, Donald et al., XML Signature Syntaxand Processing Version 1.1, W3C Recommen-dation 11 April 2013.

[6] Eastlake, Donald et al., XML Encryption Syn-tax and Processing, W3C Recommendation 10December 2002.

[7] OCPP Forum, Open Charge Point Protocol,[Online] available at: http://www.ocpp.nl, ac-cessed on 14.02.2013.

[8] Schmutzler, Jens; Wietfeld, Christian Analy-sis of Message Sequences and Encoding Effi-ciency for Electric Vehicle to Grid Interconnec-tions, Proceedings of IEEE Vehicular Network-ing Conference (VNC) 2010, Jersey City, NewJersey, USA, 2010.

[9] IEC TC57 IEC IS 61850-8-1 Communicationnetworks and systems in substations - Part 8-1: Specific Communication Service Mapping(SCSM) - Mappings to MMS (ISO 9506-1 andISO 9506-2) and to ISO/IEC 8802-3, Inter-national Electrotechnical Commission (IEC),Geneva, Switzerland, September 2011.

[10] IEC TC/SC 88 Wind turbines Part 25-4: Com-munications for monitoring and control of windpower plants Mapping to communication pro-file, Geneva, Switzerland, October, 2008.

[11] IEC TC57 IEC IS 61850 Communication net-works and systems for power utility automa-tion - Part 7-420: Basic communication struc-ture - Distributed energy resources logicalnodes, International Electrotechnical Commis-sion (IEC), Geneva, Switzerland, June, 2009.

[12] Schmutzler, Jens; Andersen, Claus Amtrup;Wietfeld, Christian Distributed Energy Re-source Management for Electric Vehicles usingIEC 61850 and ISO/IEC 15118, Proceedings of8th IEEE Vehicle Power and Propulsion Con-ference (VPPC), pp.1457-1462, Seoul, SouthKorea, 9-12 Oct. 2012.

[13] IEC TC57 WG17 IEC TR 61850-90-8 Commu-nications Systems for Distributed Energy Re-sources Part 90-8: Object Model for ElectricMobility, May, 2012.

[14] Schmutzler, Jens; Wietfeld, Christian; Jundel,Sven; Voit, Stephan A mutual Charge Sched-ule Information Model for the Vehicle-to-GridCommunication Interface, Proceedings of 7thIEEE Vehicle Power and Propulsion Confer-ence (VPPC), pp.1-6, Chicago, IL, USA, Sept.2011.

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 11

[15] Schmutzler, J.; Groning, S.; Wietfeld, C.Management of Distributed Energy Resourcesin IEC 61850 using Web Services on De-vices, 2011 IEEE International Conferenceon Smart Grid Communications (SmartGrid-Comm), pp.315-320, 17-20 Oct. 2011.

[16] Pedersen, A.B.; Hauksson, E.B.; Andersen,P.B.; Poulsen, B.; Trholt, C.; Gantenbein, D.Facilitating a Generic Communication Inter-face to Distributed Energy Resources: Map-ping IEC 61850 to RESTful Services, 2010 FirstIEEE International Conference on Smart GridCommunications (SmartGridComm), pp.61-66,4-6 Oct. 2010.

[17] Sucic, S.; Bony, B.; Guise, L. Standards-compliant event-driven SOA for semantic-enabled Smart Grid Automation: EvaluatingIEC 61850 and DPWS Integration, 2012 IEEEInternational Conference on Industrial Technol-ogy (ICIT), pp.403-408, 19-21 March 2012.

AuthorsJens Schmutzler is a senior re-searcher at the CommunicationNetworks Institute (CNI) at theTU Dortmund University, Ger-many. He is actively involved innational and international researchprojects on interoperability of EVsand charging infrastructures and

coordinates the ICT for Energy Systems researchgroup at the CNI (currently 10 staff members). Heis an active member of DIN (German Standard-ization Body) and a delegate in the Joint WorkingGroup for standardization of the Vehicle-to-GridCommunication Interface (ISO/IEC 15118). Healso contributed to WG17 of TC57 in IEC 61850targeting an object model for e-mobility for ICTintegration of EVs into the Smart Grid. His researchbackground is embedded Web Services and theirimpact on constrained communication networks.Jens Schmutzler is a Dipl.-Ing. of TU DortmundUniversity and studied one year at the NationalUniversity of Singapore (NUS).

Claus Amtrup Andersen graduatedfrom OTS, Denmark in 1993 with adegree in embedded hardware andsoftware design. He has worked asManager for EURISCO since 1994.Claus Amtrup Andersen is activemember of IEC TC57 WG17 and

IEC TC69 WG4 incl. JWG ISO/IEC 15118. ClausAmtrup Andersen has been PT-leader of the M/468Focus group for E-mobility data communicationsand is now WG-leader of the CENELEC WG SmartCharging under EM-CG and SG-CG. As reporterbetween M/468 and M/490, Claus Amtrup Andersenis also member of the Steering group for the SmartGrid Coordination Group under CEN/CENELEC.

Christian Wietfeld received hisDipl.-Ing. and Dr.-Ing. degreesfrom RWTH Aachen University.He is a full professor and headof the Communication NetworksInstitute (CNI) of TU DortmundUniversity, Germany. For 20 yearshe has initiated and contributed to

national and international research and developmentprojects on wireless data communication systemsin academia and industry. He has published over165 peer-reviewed publications and holds severalpatents. For his contributions to the standardizationof next generation mobile network architectures, hereceived in 1999 an ITU-T outstanding contributionaward. His current research interests include thesystem design, modeling and performance evaluationof communication networks in challenging envi-ronments. Christian Wietfeld is a Senior Memberof IEEE and chairs the IEEEs German sister orga-nization VDE/ITG committee on CommunicationNetworks and Systems.

EVS27 International Battery, Hybrid and Fuel Cell Electric Vehicle Symposium 12