COTEVOS
Deliverable D1.3
Requirements for infrastructure for interoperability assessment
TECNALIA 28/11/2014 v.2.3
Project Full Title: COncepts, Capacities and Methods for Testing EV systems and their interOperability within the Smart grid
FP7-SMARTCITIES-2013, ENERGY 2013.7.3.2 Grant agreement no. 608934 Collaborative Project
This project has received funding from the European Union’s Seventh Programme for research, technological development and demonstration under grant agreement No 608934
D1.3 1-59 EU Project no. 608934
Document information
Author(s) Company Raúl Rodríguez, C. Madina, E. Zabala TECNALIA Additional authors Company F. Lehfuss, M. Nöhrer AIT G. Mantovani ALTRA S. Misara DERlab T. Meier Sørensen, S. Martinenas DTU R. Kralj, J. Ratej, B. Mehle ETREL A. Barahona-Abrego IWES I. Karakitsios NTUA F. Beloni, D. Pala RSE J. Laarakkers, R. Koffrie, E. Werkman TNO P. Kelm, B. Olek, M. Wierzbowski TUL P. Ševce ZSDIS
WP no. and title WP1 – Analysis of the situation and needs for validating the interoperability of the different systems WP leader TUL Task no. and title Tasks 1.5 Task leader TECNALIA
Dissemination level PU: Public X PP: Restricted to other program participants (including the Commission Services) RE: Restricted to other a group specified by the consortium (including the Commission Services) CO: Confidential, only for members of the consortium (including the Commission Services)
Status For information Draft Final Version X Approved
Revisions Version Date Author Comments 0.1 23/06/2014 TECNALIA first version 0.2 09/11/2014 TECNALIA Minor amendments after TUL comments and further TECNALIA's revision 0.3 30/09/2014 TECNALIA 0.4 15/10/2014 TECNALIA State of the art completed, strategy of partners included 1.0 31/10/2014 TECNALIA Revision of partners to their strategy included, introduction, conclusions and executive summary was completed 1.1 05/11/2014 TECNALIA Comments by ETREL included. Revision of tables 1 and 5 according to last inputs.
D1.3 2-59 EU Project no. 608934
Inclusion of annex 1. 2.1 07/11/2014 TECNALIA Internal comments included. New section 4 and Annex B added. Conclusions and executive summary accordingly updated. 2.2 17/11/2014 TECNALIA Comments by DERlab included 2.3 28/11/2014 TECNALIA Comments by AIT, final reviewer, included
D1.3 3-59 EU Project no. 608934
Executive Summary
The state of art analysis performed in the frame of COTEVOS project permitted, among other things, to depict market solutions available today in the electro-mobility field. These were used as input by project partners to help define their future strategies for interoperability assessment. In this way, a first approach of that vision is presented at the current stage of the project and it will be further defined through the rest of tasks to come.
The summary of the state of art analysis is presented below classified by aspects related to the Smart Grid Architecture Model (SGAM) layers (Smart Grid Coordination Group approach): Regulation: it sets the highest level framework for the development of activities in a region and therefore it has a relevant impact on the development of both regulated and private business models. Even if harmonisation is being pursued at EU level, structural differences exist between countries resulting in diverse market conditions, which are characterised by players' roles, electricity system operation procedures, small consumers' participation in energy markets, low voltage codes, etc. This poses risks for interoperability. Business: business models rely on product and/or service sale. Those related to e-mobility have to take into account ICT requirements in order to estimate costs. Several solutions exist and companies will deploy the ones suiting better their models, e.g., end-to-end communications involving many different stakeholders might be required. Services/Functions: they are the basis of business models. Use cases can be utilized to describe them, at high level or in a more detailed way going down to, for example, data exchange definition. Services definition permits to know the required interactions between components (stakeholders or systems) and the functions that will have to be covered. Communication and information: the interaction between components requires the use of communication and information protocols. This is a fundamental aspect to achieve interoperability. The state of art analysis permitted to identify candidates for the communication between stakeholders, considering not just the e-mobility but other related domains, such as the smart grid, ITS and home automation. The next Figure 1 shows this outcome. Components: they can refer to devices, applications, persons and organizations. They will use communication and information protocols to exchange data and they will carry out the functionalities required to fulfil services. Similarities may exist between the devices or applications of different stakeholders and this helps simplify, up to certain extent, the interoperability problem.
D1.3 4-59 EU Project no. 608934
Figure 1 Information protocols summary
This state of the art information helped COTEVOS partners define their vision and present strategy in the e-mobility interoperability assessment field. The interfaces between stakeholders together with the available communication and information protocols were reviewed and evaluated, mainly by partners who will offer testing services in the future.
As it would be expected, the diverse points of view are not uniform, leading to complementarity within the project. The following Table 1 summarizes partners' opinions and strategy. The latter is represented by the protocols that will be presumably implemented in laboratory environments (last column). The vision on standardization relevance of the interfaces between actors, as well as on the expected market interest and implementation costs for each of them, is summed up in columns 3 to 6 in the table. Possible answers for concept assessment were limited to High (H), Medium (M) or Low (L).
D1.3 5-59 EU Project no. 608934
Table 1 Summary of IOP vision and strategy by COTEVOS partners Communication Standardization Market interest Cost COTEVOS partners from to relevance Short Medium expected services term / long Secondary ICT platform L-M L-M M-H L-M OCHP: 1 partner Actor system EVSE ICT platform M-H L-M H L-M IEC 62746: 1 Secondary Secondary M-H L-M M-H M Open ADR, OSCP, Actor Actor PowerMatcher: 1 DSO HEMS H L M-H L-M Not specified: 1 DSO EV M L L-M M-H IEC 61850, OpenADR, Proprietary: 1 Not specified: 1 IEC 61850, OpenADR, DSO EVSE M-H L M-H M-H Proprietary: 1 IEC 61850-90-8: 1 DSO / Energy M M-H H L Retailer customer HEMS / EVSE/smart M L M L-M smart meter socket Fleet EV M-H L M-H M manager
EVSEO EVSE H M M-H M OCPP: 4
Secondary EV user Actor and L-M L M L ICT systems
EV user EVSE H H H L-M RFID: 1
EVSE EVSE L L L L
ITS EV M-H L M M platforms
IEC 61851: 6 partners EV EVSE H M-H M-H M-H IEC/ISO 15118: 5
EV Smart socket M L-M M-H L-M EV EV user L-M L M-H L EV EV (ITS) M L M-H M EV (Inside EV L-M L L-M L the Vehicle)
The main conclusions of the report are presented below: The uncertain market evolution and the broad options spectrum in the e-mobility sector and smart grid field make it advisable that interoperability assessment is based on flexible laboratory architectures able to adapt to different business models requirements. In order to benefit from the complementarity of COTEVOS partners' approaches, sharing infrastructures through remote internet connections (cloud) could be an interesting option to move towards a unified laboratory concept and contribute to the cost effectiveness of test procedures.
D1.3 6-59 EU Project no. 608934
Other several ongoing developments within the project are also paving the way towards the setting up of the unified laboratory: o Common conceptual approach. o Common laboratory reference architecture. o Definition of test cases and testing procedures. o Inter-laboratory comparison. o The presentation of results for evaluation in the international arena.
D1.3 7-59 EU Project no. 608934
Table of contents
Document information ...... 2 Executive Summary ...... 4 Table of contents ...... 8 List of figures ...... 9 List of tables ...... 10 Abbreviations and Acronyms ...... 11 1. Introduction ...... 13 2. Interoperability overview from the State of the Art results ...... 14 2.1. Regulation ...... 14 2.2. Business ...... 15 2.3. Services/Functions analysis ...... 16 2.4. Information and Communication protocols summary ...... 24 2.5. Components ...... 26 3. Outline of the current strategy of COTEVOS partners ...... 27 3.1. AIT ...... 27 3.2. DTU ...... 28 3.3. IWES ...... 29 3.4. RSE ...... 30 3.5. TECNALIA ...... 31 3.6. TNO ...... 32 3.7. TUL ...... 33 3.8. Views from other COTEVOS partners ...... 34 3.9. Summary ...... 36 4. The concept of the test for assessing interoperability ...... 42 5. Conclusions: requirements for unified test procedures ...... 44 5.1. The challenge of e-mobility interoperability assessment ...... 44 5.2. COTEVOS approach for a unified interoperability assessment ...... 45 6. References ...... 47 6.1. General ...... 47 6.2. Standards references ...... 47 Annex A. COTEVOS partners inputs on vision and interests ...... 49 Annex B. Minutes of COTEVOS workshop in Roskilde (02/10/2014) ...... 52
D1.3 8-59 EU Project no. 608934
List of figures
FIGURE 1 INFORMATION PROTOCOLS SUMMARY ...... 5 FIGURE 2 INFORMATION PROTOCOLS SUMMARY ...... 24 FIGURE 3 COMMUNICATION PROTOCOLS SUMMARY ...... 25 FIGURE 4: AIT LAB SCHEME ...... 28 FIGURE 5 AIT LAB STRATEGY ...... 28 FIGURE 6 DTU LAB STRATEGY ...... 29 FIGURE 7 IWES LAB STRATEGY ...... 30 FIGURE 8 RSE LAB STRATEGY ...... 31 FIGURE 9 TECNALIA LAB STRATEGY ...... 32 FIGURE 10 TNO LAB STRATEGY ...... 33 FIGURE 11 TUL LAB STRATEGY ...... 34 FIGURE 12 ETREL LAB STRATEGY ...... 35 FIGURE 13 IOP CURRENT STRATEGY BY COTEVOS PARTNERS ...... 41 FIGURE 14 COMMON LABORATORY REFERENCE ARCHITECTURE IN COTEVOS ...... 43 FIGURE 15 TEST CASES GROUPS ...... 43
D1.3 9-59 EU Project no. 608934
List of tables
TABLE 1 SUMMARY OF IOP VISION AND STRATEGY BY COTEVOS PARTNERS ...... 6 TABLE 2 ACRONYMS ...... 11 TABLE 3 IOP RELATED SERVICES SUMMARY ...... 18 TABLE 4 COMPONENTS AND ROLES/ACTORS ...... 26 TABLE 5 IOP VISION AND STRATEGY BY COTEVOS PARTNERS ...... 37 TABLE 6 STANDARD REFERENCES ...... 47 TABLE 7 PARTNER RESPONSES - IOP VISION ...... 50 TABLE 8 PARTNER RESPONSES - IOP INTERESTS ...... 51
D1.3 10-59 EU Project no. 608934
Abbreviations and Acronyms
Table 2 Acronyms
AMI Advanced Metering Infrastructure CEM(S) Customer Energy Management (System) CH Clearing House DR Demand Response DSO Distribution System Operator DUT Device Under Test EMG Energy Management Gateway EMS Energy Management System EMSP Electro-Mobility Service Provider EV Electric Vehicle EVSE EV Supply Equipment EVSEO EVSE Operator HEMS Home Energy Management System HES Head End System HMI Human Machine Interface ICT Information and Communications Technology IOP Interoperability ITS Intelligent Transport Systems LNAP Local Network Access Point PLC Power Line Communication SO System Operator (DSO, TSO) SGAM Smart Grid Reference Architecture Model TSO Transmission System Operator V2G Vehicle to Grid WAN Wide Area Network
D1.3 11-59 EU Project no. 608934
1. Introduction
This report represents the last deliverable of COTEVOS project WP1, which deals mainly with the state of art of interoperability in the field of e-mobility. However, at the same time, it also establishes the basis for the future work ahead. Taking these two aspects into account, and the fact that this text is part of the first milestone of the project, the content summarizes the following main points: Some of the results of the state of the art assessment worth taking into account to explain the current status of the project. The vision and strategy of project partners in regard to interoperability testing, at the present time. The COTEVOS project concept of the test for assessing interoperability that should be used from now on.
First, the state of the art summary is introduced in chapter 2. The SGAM methodology approach, used as framework within the project, is presented here to highlight the importance of the regulatory and market environment; to identify the services involving interoperability between stakeholders; to show the set of available communication and information protocols for data exchange; and to refer to the components that could be part of the e-mobility environment and that should be considered in end-to end communications.
Chapter 3 introduces the strategic view of COTEVOS partners in regard to interoperability testing and a summary of their vision for each of the specific component interfaces identified in the previous chapter.
The main concepts of test for assessing interoperability are introduced in chapter 4, which puts together the state of art-based vision and strategy of the laboratories and the developments in other tasks of the project, leading both to setting up the EU level unified laboratory for e-mobility interoperability assessment.
Chapter 5 sums up the main outcomes of the document in the form of conclusions.
The last chapter is devoted to the references and it consists of two parts: COTEVOS document references and standards references.
Additional documentation is presented in two annexes. The first deals with project partner responses on their vision and main interests in the e-mobility sector. The last, Annex B, contains the minutes of the workshop in Roskilde in which the project approach was confronted to external experts at international level.
The deliverable sums up the current status of the e-mobility interoperability assessment approach within the project. The development of the rest of the tasks of COTEVOS should help refine and define with more detail the strategies of partners in the field.
D1.3 13-59 EU Project no. 608934
2. Interoperability overview from the State of the Art results
COTEVOS project considers a comprehensive approach for interoperability assessment based on the SGAM methodology. This is reflected in WP1 work throughout Deliverable 1.1 content [1].
In this chapter, the relevant results of that deliverable are analysed and processed, as context for the definition of the strategy and infrastructure for interoperability assessment. The analysis of the state of the art helped the partners establish a first strategy based on their vision on the e-mobility field.
2.1. Regulation
Regulation sets the highest level framework for the development of activities within a region. It has a direct influence on regulated businesses, as those related to the distribution and transmission of energy, but it also builds a framework for private business development.
Regulation should not hinder EV penetration but promote business models and permit their profitability under global sustainability concepts. Both strict rules and the lack of regulatory definition might become a barrier for the development of healthy businesses.
The electricity sector regulation establishes, for example, the characteristics of the participation of small consumers in electricity markets as well as the role of players, which affects the development and feasibility of potential businesses. The main aspects covered by the electricity sector regulation having an impact on business are the following: Network operation procedures: they define the involvement of small DER, the implementation of mechanisms for the deployment of demand flexibility services, etc. Low voltage and building codes: the LV code defines the basic requirements that infrastructure assets and installations should meet when connected to the low voltage network. In the case of EVs, this affects charging infrastructure projects, both technically and economically. Building codes may also impose some requirements on infrastructure in residential and industrial buildings. Electricity tariff definition: it has influence on final users’ behaviour with respect to the use of electricity, basically, on how much and when it is demanded. Flat or time of use tariffs, critical peak pricing and real time pricing will cause, presumably, different consumption patterns. Currently, energy supply tariffs are not regulated anymore, however, in some countries they are still an option for smaller customers. Network tariffs remain regulated and they could be used for demand response shaping. Compensation of regulated activity: system operators’ incomes are based on the eligible costs defined by regulation. Among these, the following are quite common: investments, operation and management, marketing, metering activities… This fact has direct influence on the strategies that system operators accomplish. For example, the way in which demand response strategies are compensated will cause them to be considered or not by system operators and this will have an effect on the services that EVs could offer to the network. New actors’ definition: the involvement of small DER in system operation requires the definition of the aggregator role (for demand, generation or both). These actors should be legally defined and entitled to participate in electricity markets or operation mechanisms, and the requirements requested to them should not hinder the feasibility of their business model. Security and environmental aspects: homologation, EMC or emissions requirements have an impact on EV and infrastructure characteristics and on their commercialisation. Market requirements: market requirements, from the electricity wholesale market to balancing or ancillary services markets, may prevent the participation of small capacity DER, demand, etc. due to cost, technical or administrative issues and, therefore, they might hinder the involvement of some actors in potential business models.
Market regulation evolution, which may help demand participation increase, requires normally long time implementation periods. Proposals for future markets address the need to:
D1.3 14-59 EU Project no. 608934
Allow demand and small DER participation in system operation and electricity markets to increase system flexibility and resources. Link electricity price to electricity cost through variable tariffs and network fees. Increase the efficiency and reduce the environmental impact of the different stages of the electricity supply chain and, considering EVs, of the mobility transport. Increase the competence in energy markets, especially in some countries.
Until this is achieved, business options for small consumers such as EVs and new stakeholders will be limited from the regulatory framework perspective. Although big modifications are not expected in the short term, they should be considered in our analysis.
An essential characteristic of regulation is its area of applicability. At EU level, EC directives are common for all countries and they should be transposed to national legislation, nevertheless, other rules and requirements exist at national, regional and municipal level. In addition, some countries are not part of the EU but, due to their geographical situation, EV interoperability effectiveness is more than recommended. Normally, electricity market particularities will have an impact on: Increased functionality/service availability: more evolved markets or regulation allow, in general, a greater variety of services and, as consequence, of potential business models. Increased profitability of business models: an optimum regulation should not represent a barrier to business model profitability. This can happen either globally or only for certain business types. Different actors: some actors are not defined by certain regulation and, therefore, some business models could be hindered. Some actors have some competences in one country and others in a different nation.
In each market model, actors will offer/demand products and/or services. Many stakeholders can be defined and, still, the most relevant aspect is probably the role they play, since market actors might not either have the same functions or share the same names in all regulatory frameworks.
Other more general aspects of regulation, on the top of those mentioned above, have also a great influence on the development of business options: Competence protection: it is of great importance to allow the access of new stakeholders to established markets. Administrative requirements and taxes: they might represent a burden, especially for starting businesses. Support schemes or other benefits for final users: they might be necessary at the beginning in order to help develop a new market.
Summing up, even if harmonisation is being pursued at EU level, structural differences exist between countries resulting in diverse market conditions, which are characterised by players' roles, electricity system operation procedures, small consumers' participation in energy markets, low voltage codes, etc. This poses risks for interoperability.
2.2. Business
The importance of the regulatory framework for the development of business models and, in particular, of innovative businesses has been already mentioned in the previous section. Even if some areas provide better environments than others for e-mobility business development, current and future market options should be considered.
Consumers’ tendency to value losses higher than gains, has already triggered the pursue of innovative businesses able to surface EVs’ positive aspects. In this context, service sale (compared to product sale) and solutions based on ICT seem to stand out. Some examples are the following: Alternatives to vehicle purchase: the high price of batteries and, in general, the total cost of ownership (TCO) of EVs, make leasing (of the complete vehicle or only batteries), vehicle sharing and rental especially suitable services.
D1.3 15-59 EU Project no. 608934
Infrastructure: charging is the main service linked to EVs. The charging point location area, private, public or semi-public, leads to different costs, smartness opportunities and competition level options. Interoperability: roaming is expected to bring a demand increase for service providers, higher comfort for the final user (more available charging points) and a lower level of overall costs in the sector (duplication is avoided). Another interoperability option is the deployment of mobile smart meters (meter inside the vehicle or in the charging cable), which may require lower infrastructure costs (EVSE) but the use of ICT interoperability platforms (data hub) for socket and EV user identification. Sustainable transportation: EV is part of a global sustainable approach and, therefore, solutions offering new mobility concepts are starting to appear (combined use of private and public transport, vehicle share, smart logistic…).
Each of these types of business model may involve different setups and information requirements. However, similarities will be also many when we stick to the exchange of information between systems and actors.
2.3. Services/Functions analysis
Use cases are utilized to describe services: from high level aspects, related to business processes or models, actor roles, general functionalities, etc., to more detailed interactions such as data exchange definition.
The main service linked to EVs is charging and the associated business is the energy supply to vehicles. However, this service requires different characteristics and information features depending, basically, on its smartness, interoperability levels and market model. Some options are shown below as example: Open access: the EV user charges at an EVSE without the need of having a contract with an EMSP. The EVSE operator offers the whole charging service to the EV user and, to do this, it has an agreement with one or more EMSPs. The EV user can be offered the possibility to choose from a list of charging services offered by different EMSPs at the EVSE. The EV user pays at the spot. Without roaming: The EV users charge at the EVSEs they are allowed to do so. In this case, the EVSE operator and the EV user have an agreement with the same EMSP. Roaming: The EV user can charge at the infrastructure of an EVSE operator who has no agreement with his EMSP. Clearance, either financial and/or of data, is done through a clearing house. This can happen internationally or within a certain region. With roaming through a market place: EV customers charge at an EVSE operated by an EVSE operator who does not have a roaming agreement with their EMSP, but who has a roaming agreement with a market place operator with whom the EMSP has an agreement too. Private charging: In the private domain, smart charging is normally foreseen through an EMS system, able to control the EV load through a dedicated EVSE or a more conventional smart switch, normally allowing for low levels of management (on/off, deferred start...).
The information exchange required to perform this charging services depends on the characteristics of each option. The open access will need less information because it involves fewer actors during the charging process (EVSE operator and EV user) and may not require identification beyond established processes (credit card payment, for example). Roaming involves the clearing house, and the market place adds a new actor but it might simplify operations by centralising exchanges. By adding smartness to the charging process, other actors (network operators) and services (electricity price information, vehicle information, etc.) are included in the procedure.
Services definition permits to go deeper into the interactions between components (stakeholders or systems) and into the functions that will have to be covered. The main services and functionalities linked to electro-mobility were identified and described in the following Table 3, including candidate protocols for each of them.
D1.3 16-59 EU Project no. 608934
Apart from the work in COTEVOS WP1, which provided inputs coming from the Smart Grid Coordination Group (e.g. First set of standards document [2]), e-mobility deployments were analysed in WP4 [3] and the results of this work were also included here, in order to complement the communication and information standards state of art overview.
Further explanations to the terms used in the table are detailed after it.
D1.3 17-59 EU Project no. 608934
Table 3 IOP related services summary Suitable Protocols 1 CP Service Network type Comments Involved actors Communication Information domain2 Physical Connection EV-EVSE Connector type (1,2,3) EV-EVSE 1-4 IEC 62196-1/2/3. Electrical features validation. Residential and industrial sockets can also be deployed for EV charging (respectively IEC 60884-1, IEC 60309-1/2) Start of charging process/communication set-up Charge mode EV-EVSE IEC 61851-1 Mode 1 NO NO 4 Residential sockets (IEC 60884-1) Mode 2 NO NO 1-4 Residential sockets (IEC 60884-1) Mode 3 IEC 61851-1 (PWM) IEC 61851-1 EV-EVSE communication. 1-4 IEC 62196-1/2/3 ISO/IEC 15118 (digital, IP) ISO/IEC 15118 Control pilot (PLC). Industrial sockets (IEC 60309-1/2). No control pilot cable CAN (SAE J1939) CAN (SAE J1939) Mode 4 IEC 61851-23/24 (digital) IEC 61851-23/24 EV-EVSE comm., (CAN, PLC (to 3 IEC 62196-3 ISO/IEC 15118 (digital) ISO/IEC 15118 be validated), pilot wire) Chademo uses a own protocol between EV and EVSE to CAN (SAE J1939) CAN (SAE J1939) guarantee a secure charge Charge Authentication/identification Not required NO NO EV user identification EV user - EVSE - ISO/IEC 14443, 15693 and 18000 Proprietary EV user-EVSE communication 1-4 Radius and Tacacs+ provide access to networks for routers, EVSEO - ICT platform (RFID) RADIUS/UDP (RFC 2865) Neighbourhood network servers… users of a network in general. The secure (IOP)3 ISO 7816-3 (chip card), etc. TACACS+/TCP Intra-substation network connection is normally done through a VPN but in the future EAP over internet X.509 (WAN) this might be enhanced using IEC 62351, especilly for VPN/IPsec EAP (RFC 3748, 5247) connections using IEC 61850 or 60870-5-104 IEC 62351-8 IEC 62351-8 IEC802.1X EV identification (EV) - EVSE - EVSEO - ISO/IEC 15118 (digital) ISO/IEC 15118 EV-EVSE communication 1-4 ICT platform (IOP) CAN (SAE J1939) CAN (SAE J1939) Intra-substation network Neighbourhood network WAN EVSE identification Smart phone app EV user- SA front-end XML/SOAP (Web services) Proprietary Mobile phone network 1-3 Code, barcode or QR code (Hubject/Intercharge use a QR Proprietary (http…) code to identify the CP and be able to perform the charging through a smart phone app) Mobile metering EVSE - EV PLC Proprietary PLC 1-3 Socket communicaiton with EV through PLC (Görlitz)
D1.3 18-59 EU Project no. 608934
EV user service selection At EVSE EV user - HMI at EVSE NO NO Communication between EVSE and EMSP will also exist. See bellow Directly with provider EV user - SA front-end XML/SOAP (Web services) Propietary Mobile phone network Proprietary (http…) 1-3 Marketplace EV user - SA front-end XML/SOAP (Web services) Propietary Mobile phone network 1-3 Proprietary (http…) See bellow (Marketplace) Charge Authorization Open Access NO NO 1-3 No identification, contract or subscription is needed, like in oil stations Local (white list) NO NO Identification is checked at EVSE. The white list is updated 1-3 through EVSE maintenance systems. Remote without (EV) - EVSE - EVSEO - ISO/IEC 15118 ISO/IEC 15118 (EV-EVSE network) 1-3 The EV user charges in allowed CPs. Identification is sent to roaming (EMSP) XML/SOAP (Web services) OCPP Intra-substation network EVSE op. and this will contact the EMSP if necessary. Proprietary Neighbourhood network Communications between close EVSEs: ethernet, wifi… Remote with roaming (EV) - EVSE - EVSEO - ISO/IEC 15118 ISO/IEC 15118 (EV-EVSE network) 1-3 Identification is sent to the secondary actor through a ICT platform (CH, IOP) XML/SOAP (Web services) OCPP Intra-substation network Clearing House. More than one EVSE op. or EMSP is involved OCHP Neighbourhood network Proprietary WAN Charging process uncontrolled charging NO NO No communications needed Open loop load DSO/Flexibility XML/SOAP (Web services) Propietary Subscriber access network 4 The EV user manages the load according to price or other management provider - EV user Proprietary (http…) See bellow (AMI, Info Mobile phone network type of signals. Demand response strategy not specific for SMS (GSM), e-messages… exchange) EVs See bellow (AMI, Info exchange) Close loop load (DSO/Flexibility The EVSE operator might need to contact the EMSP in order management provider) - EVSEO - to ask for EVs suitable for control EVSE EV control (DSO/Flexibility ISO/IEC 15118 (digital) IEC 61851-1 Intra-substation network 1-4 Charging schedule negotiation according to 15118 provider) -EVSEO - IEC 61851-1 ISO/IEC 15118 EV-EVSE communication EVSE - EV OCPP OSCP IEC 61850-90-8 EVSE control (DSO/Flexibility XML/SOAP (Web services) OCPP Intra-substation network 1-4 provider) - EVSEO - IEC 61850-90-8 OSCP EVSE Modbus Proprietary IEC 61850-90-8
D1.3 19-59 EU Project no. 608934
CEMS control (DSO/Flexibility 4 CEMS: Customer Energy Management Service. It depends on provider)- CEMS - its communication capabilities. EVSE via AMI Check below: HES- Check below (AMI) Check below (AMI) Subscriber acess network or 4 (NNAP)-LNAP; LNAP- Field/neighbourhood networks EMG direct link DSO/Flexibility IEC 62746 Open ADR2.0b (IEC 62746:2014) Subscriber access network 4 DR strategies provider Front-end - EMG/CEM Charge payment/accounting Free 1-3 Service payment Direct EV user - EVSE/EVSEO Credit card system Credit card system 2, 3 Credit card or cash (like oil stations or car parks currently) Through internet EV user -SA front- Https Proprietary Mobile phone network 1, 3 Through web site or payment platform/gateway end/ICT platform (payment) Contract, substcription (EV) - EVSE - EVSEO - XML/SOAP (Web services) OCPP (EV-EVSE network) 1-4 Charge data must be forwarded from EVSE to e-mobility card (e.g. prepayment) (ICT platform - IOP) - ISO/IEC 15118 (digital) ISO 15118 Intra-substation network provider EMSP Proprietary Neighbourhood network WAN EVSE monitoring and maintenance EVSE monitoring and EVSEO - EVSE XML/SOAP (Web services) OCPP Intra-substation network 1-4 An EVSE communication hub may exist. Close EVSEs would maintenance IEC 61850-90-8 Proprietary Neighbourhood network send the information through cheaper means to the hub: Modbus IEC 61850-90-8 ethernet, wifi… Fleet management EV monitoring and Fleet operator - EV XML/SOAP (Web services) Proprietary Mobile phone network For the rest of services the fleet operator could assume the maintenance ITS network (see bellow) ITS ITS network role of a EVSEO. OEMs could be considered as fleet managers in terms of services Information exchage/End-user services EV user to EV EV user - EV Wifi (IEEE802.11) CAN SAE J1939 EV user - EV communication 1-3 The EV user can connect its smart phone to the car and use CAN SAE J1939 Proprietary this cellular connection . NFC, bluetooth, USB can be used to etc. share wifi details. Big data transmission can be done through wifi. The HMI of the vehicle is another connection mean
Vehicle to vehicle or EV - EV IEEE802.11p (WAVE, wifi for ETSI TS 101 556-1 (CP ITS network 1-3 ITS. Between vehicles and ITS stations or other vehicles ITS Infrastructure EV - ITS infrastructure vehicles base for ITS5G) information) communications ITS G5 (ETSI ES 202 663) ETSI TS 102 894-2 3GPP (transport: UDP/RTP/TCP; CAN (SAE J1939) network: IPv4/6; access: LTE/HSPA/GSM) CAN (SAE J1939)
D1.3 20-59 EU Project no. 608934
Vehicle/user to EMSP EV/EV user - Service XML/SOAP (Web services) Propietary via cellular network provider front-end Proprietary (http…) Secondary actor to Secondary Actor - ICT XML/SOAP (Web services) WXMM, WMO METCE (for Mobile phone network 1-4 EV or EV user to service provider. Depends on the service service provider platform Http Weather data), etc. (information service) Proprietary Proprietary Participation in energy market schemes/Provision of services to the network Through aggregators* Secondary Actor - ICT IEC 61968-100 Proprietary Interchange network 1-3 * e-mobility providers, flexibility providers… Provision of platform (Energy (Web services) OASIS EMIX Balancing network services to the network market) EnergyInterop IEC 62325 series Clearing House All Secondary Actors Secondary Actor - ICT XML/SOAP (Web services) OCHP Interchange network 1-3 with CH platform (CH) Proprietary Marketplace / Service exchange Marketplace and Secondary Actor - ICT EN 62325-450/451 (Entso-e ecan 451-EN 62325-301/351 (Entso-e Interchange network 1-3 Any actor should have access and be able to offer servcies at trading systems platform 3) MADES) the marketplace (marketplace) Web services IEC 61970-301:2013 IEC 61968-11:2013 AMI (Advanced Metering Infrastructure) Proprietary Meter/EMG - Home Energy services Home automation protocols (C- Home automation protocols (C- LAN 4 customer Bus, KNX, Zigbee, Lontalk, Meter- Bus, KNX, Zigbee, Lontalk, Bus…) Meter-Bus…) Proprietary Local Network Access DSO/Meter operator - DLSM/COSEM (IEC62056, EN52056) DLSM/COSEM (IEC62056, LAN 4 There are three posibilities to perform demand control Point (LNAP) - Meter Energy services Lontalk (EN 14908) EN52056) through the AMI system: customer Meter Bus (EN 13757) Lontalk (EN 14908) - Meter as communication gateway Meter Bus (EN 13757) - Meter with relays - Throught the CEM LNAP - Energy DSO/Meter operator HBES (EN 50090) HBES (EN 50090) LAN 4 There are three posibilities to perform demand control Management Gateway Lontalk (EN 14908) Lontalk (EN 14908) through the AMI system: (EMG) EN 13321 EN 13321 - Meter as communication gateway Meter Bus (EN 13757) Meter Bus (EN 13757) - Meter with relays prTS 50568-5: Messages for - Throught the CEM Neighbourhood DSO/Meter operator DLSM/COSEM (IEC62056, EN52056) DLSM/COSEMPLC&IP (IEC62056, Neighbourhood network 1-4 Network Access Point PLC (S-FSK, IEC 61334): Prime (prTS EN52056) (NNAP) or Meter data 50567-1), G3 (prTS 50567-2) Lontalk (EN 14908) concentrator - LNAP Lontalk (EN 14908) Meter Bus (EN 13757) Meter Bus (EN 13757) IEEE 1377
D1.3 21-59 EU Project no. 608934
Head-end System DSO/Meter operator COSEM (IEC62056-47) over IPv4 COSEM (IEC62056-5-3, 6-1, 6-2, 9- Subscriber access network 1-4 (HES) - LNAP TS102887 wireless 7, 9-8) 3GPP pr EN 62056-5-8 ISDN IEEE 1377 HES - NNAP DSO/Meter operator COSEM (IEC62056-47) over IPv4 COSEM (IEC62056-5-3,6-1,6-2) Field area network 1-4 TS102887 wireless pr EN 62056-5-8 3GPP prTS 50568-5,6,9 PLC&IP ISDN IEEE 1377 HES - Metering Back DSO/Meter operator IEC 61968-100 (web services) IEC 61968 Intra control data network 1-4 office WAN Intra metering back DSO/Meter operator IEC 61968-100 (web services) IEC 61968 Intra control data network 1-4 office Enterprise network Distribution system operation (DMS SCADA/GIS, Substation automation, DER management) At process level DSO IEC 61850 IEC 61850 Intra-substation network 1-4 Primary equipment: measuring elements, swiching, regulators… Process - Field DSO IEC 61850 IEC 61850 Intra-substation network 1-4 Between process and field level systems IEC 60870-5-103 At field level DSO IEC61850 IEC61850 Intra-substation network 1-4 Between IEDs (relays, meters, fault detectors…), field Fieldbus (IEC61158, 61784) Fieldbus (IEC 61131, 61499) Inter-substation network devices, DER control units, etc. Industrial fieldbus area network Field - Station DSO IEC 61850 IEC 61850 Intra-substation network 1-4 Between field and station level systems IEC 60870-5-103 (linking with primary equipment at process level) At Station level DSO IEC 61850 IEC 61850 Intra/Inter substation network 1-4 Between systems intra/inter-substations: DER/plant controllers, RTUs, network interfaces… Station - Operation DSO IEC 61850 IEC 61850 WAN, Inter-substation 1-4 Between station and operation level systems IEC 60870-5-101 network, Field area network IEC 60870-5-104 At operation level DSO IEC 61968-100 (Web services) IEC 61968 Intra Control/Data Centre 1-4 DMS/SCADA & GIS, OMS, EMS (Transmission), DER operation IEC 60870-6 IEC 61970 network system, DER EMS, technical VPP. IEC 61698,61970 integrate back office applications (necessity to harmonize these with the IEC 61850) Operation - Enterprise DSO IEC 61968-100 (Web services) IEC 61968 Intra Control/Data Centre 1-4 Between operation and enterprise level systems IEC 61970 network At enterprise level DSO IEC 61968-100 (Web services) IEC 61968 Enterprise network,network Intra 1-4 GIS, Customer Information System (CIS), Asset management, IEC 60870-6 IEC 61970 control/data centre network commercial VPP, meter back office Enterprise - market DSO - ICT platforms IEC 61968-100 (Web services) IEC 62325 Balancing network 1-4 Between enterprise and market level systems (market) At market level DSO - Market see above see above 1-4 Trading systems (front office, back office), market places operators
D1.3 22-59 EU Project no. 608934
Explanations to some of the concepts in the previous table:
1 Charging Point (CP) domain: 1. Public CP in public domain (e.g. curb). 2. Public CP in private domain (e.g. shopping mall). 3. Semi-public CP in public or private domain (e.g. car sharing, hotel). 4. Private access CP (home, working place).
2 ICT platforms: o IOP: Interoperability. It makes reference to all ICT platforms providing some kind of interoperability: marketplace, roaming/clearing house, payment, etc. o CH: Clearing House to provide roaming services. o Marketplace: B2B platform for EV services exchange. o Payment platform: platform providing payment services for EV services.
3 Communication technologies on smart grid sub-networks (for more details check [1] or [2]): o Subscriber access network (providing broadband access for customer premises): PLC (narrow and broadband), LR WPAN, Wi-Fi, WiMAX, IPv4/6, RPL/6LowPan, GSM/GPRS/EDGE, 3G/WCDMA/UMTS/HSPA, LTE/LTE-A, SDH/OTN, IP MPLS/MPLS TP, DLS/PON, high layer protocol. o Neighbourhood network: PLC (narrow and broadband), Lontalk, HBES, LR WPAN, Wi- Fi, WiMAX, Smart metering wireless access, IPv4/6, RPL/6LowPan, IEC 61850, GSM/GPRS/EDGE, 3G/WCDMA/UMTS/HSPA, LTE/LTE-A, SDH/OTN, IP MPLS/MPLS TP, M-Bus, DLS/PON, high layer protocol. o Interchange network (connecting wholesale electricity markets to market operators, retailers and traders): IPv4/6, 3G/WCDMA/UMTS/HSPA, LTE/LTE-A, SDH/OTN, IP MPLS/MPLS TP, high layer protocol. o Intra-substation network: PLC, Wi-Fi, Ethernet, IPv4/6, IEC 61850, IEC 61870-5, SDH/OTN (optical fibre), IP MPLS/MPLS TP. o Inter-substation network: PLC, IPv4/6, IEC 61850, IEC 61870-5, SDH/OTN, IP MPLS/MPLS TP, LTE/LTE-A (3GPP), DSL/PON (optical network), high layer protocol. o Industrial fieldbus area network: Ethernet. o WAN: IPv4, IPv6, IEC 61850, IEC 61870-5, GSM/GPRS/EDGE, 3G/WCDMA/UMTS/HSPA, LTE/LTE-A, SDH/OTN, IP MPLS/MPLS TP, DLS/PON, high layer protocol. o Field area network: PLC, Lontalk, HBES, LR WPAN, WiMAX, smart metering wireless access (ETSI TS 102887), IPv4/6, RPL/6LowPan, IEC 61850, LTE/LTE-A, SDH/OTN, IP MPLS/MPLS TP, high layer protocol. o Intra-control centre/Intra data-centre network: Ethernet, IPv4/6, 3G/WCDMA/UMTS/HSPA, LTE/LTE-A, SDH/OTN, IP MPLS/MPLS TP, high layer protocol. o Enterprise network: Ethernet, IPv4/6, 3G/WCDMA/UMTS/HSPA, LTE/LTE-A, SDH/OTN, IP MPLS/MPLS TP, high layer protocol. o Balancing network: IPv4/6, 3G/WCDMA/UMTS/HSPA, LTE/LTE-A, SDH/OTN, IP MPLS/MPLS TP, high layer protocol. Other communication and network types (not defined in the First set of standards by the SC-CG [2]): o EV-EVSE communication: pilot wire, PLC, wireless (Wi-Fi, Bluetooth, ZigBee, Infrared…), CAN (SAE J1939). o EV user - EVSE communication: RFID card, chip card, magnetic stripe card, barcode or QR code, NFC, code (smartphone app: WAN connection, Wi-Fi, Bluetooth…; EVSE HMI)… o EV user - EV communication: NFC, Wi-Fi, Bluetooth, CAN, HMI. o Mobile phone network: IPv4/6, GSM/GPRS/EDGE, 3G/WCDMA/UMTS/HSPA, LTE/LTE- A… o LAN: Ethernet, Wi-Fi, PLC. o ITS network: WiMAX (IEEE 802.16), IEEE 802.11p (WAVE, Wi-Fi for vehicles base for ITS5G), ITS G5 (ETSI ES 202 663), 3GPP (transport: UDP/RTP/TCP; network: IPv4/6; access: LTE/HSPA/GSM), CAN (SAE J1939).
D1.3 23-59 EU Project no. 608934
2.4. Information and Communication protocols summary
The interaction between components requires the use of communication and information protocols. This is a fundamental aspect to achieve interoperability. The state of art analysis (Table 3) permitted to identify candidates for the communication between stakeholders, considering not just e-mobility but other related domains, such as smart grid, ITS and home automation. The next figures show this outcome. Further reference to the international standards below is provided in 6.2.
Figure 2 Information protocols summary
D1.3 24-59 EU Project no. 608934
Figure 3 Communication protocols summary
Most of the protocols above were not designed to provide interoperability, which means that meeting the standard does not guarantee it. For example RFID systems can follow ISO/IEC 14443, ISO/IEC 15693 or ISO/IEC 18000 standards. Once the technology is selected, the codification should also be made under interoperability requirements: which information fields are defined, with which length, where is the information stored in the card, how users IDs are defined in order for all EVSEs to be able to identify them and the vehicle, etc.
D1.3 25-59 EU Project no. 608934
The minimum required information is also an important aspect to fulfil interoperability. For example, in an identification and authentication process even if many fields could be exchanged according to different protocol data structures, some of them should be obligatory. Still, a high number of requisites may cause the impossibility to charge for some users.
It should be noted that business models are based on service trading and that companies use these services to differentiate their product from that of other competitors. Sometimes, communication protocols are not able to address all the services that companies want to provide and this makes some communication protocols to be adapted to allow for new data structures permitting new services. This is a barrier for interoperability but something common today, especially in some interfaces such as the EVSE-EVSEO interface.
2.5. Components
The definition of components is derived from the use case information on actors, since these can be of different types: Devices. Applications. Persons. Organizations.
Components use communication and information protocols to exchange data and they carry out the functionalities required to fulfil services. Similarities may exist between the devices or applications of different stakeholders and this helps simplify, up to certain extent, the interoperability problem.
The following table shows a selection of those smart grid components more directly related to e- mobility, while it proposes a link with several actors/roles.
Table 4 Components and roles/actors
Components Roles/actors HMI platforms, EVSE, computer, smart phone, charging control, Customer EV user energy management system, energy management gateway, load controller, meter, smart plug, Plug-in EV, etc. Asset management system, Demand response management system, EVSE operator Building/customer management system, Energy management gateway, GIS, HES, EVSE, meter data concentrator, SCADA, charging/load control, billing, etc. Customer information system, customer portal, billing, Demand response EMSP* management system, energy trading application, enterprise resource planning, front-end processor, GIS, meter data management system, asset management, Load controller, etc. SW platform permitting access and operations, energy market management, Market Place operator registration application, settlement. SW platform permitting clearing house services, energy market Clearing House operator management, registration application, settlement SCADA, EVSE, DER control, Demand Response Management system, Network operators (DSO, front-end processor, GIS, HES, energy market management (ancillary TSO) services). Customer information system, customer portal, energy trading application, Energy retailer enterprise resource planning, billing, etc. AMI Head End, Meter data concentrator; meter data management system, Metering operator etc. * Different systems depending on the services offered by the EMSP: energy provider, aggregator, OEM, etc.
D1.3 26-59 EU Project no. 608934
3. Outline of the current strategy of COTEVOS partners
The analysis of the state of art summed up in the previous section resulted in the general picture of COTEVOS partners' vision and interests on IOP interfaces (see Annex A). Based on this, the laboratories involved in the project have identified their present time strategy in the e-mobility interoperability testing field, as a first step to infrastructure requirement definition.
The strategy presented here should be further detailed and confirmed throughout the project, considering the inputs that will be obtained in future developments, with special focus on testing cases development, laboratory capability definition and business model analysis.
3.1. AIT
The AIT laboratory for EV and EVSE focuses its strategy on the interactions between EV/EVSE and the power supplying grid. The AIT lab infrastructure aims to be composed in such a way that all the main components are available as simulation and emulation elements. This results in the possibility to exchange any component with a real DUT and evaluate its behaviour according to existing and/or foreseen standards and regulations.
The simulated/emulated components are designed as flexible as possible in order to be adaptable for future needs and requirements. The secondary actors will utilize the Smart Message Bus architecture for message exchange. Actors such as the DSO, the EVSE Operator, the Clearing House, etc. can be installed on any PC having a TCP/IP interface required for the connection to the Smart Message Bus.
The beneath listed interfaces are implemented in a first step: EV-EVSE: This interface will be implemented using real devices or emulated/simulated devices. It will be mainly evaluated according to the IEC 61851 and, in the near future, also to the ISO 15118. The DUT for this interface can be the EV, the EVSE or both (control, electronics and communications). EVSE-EVSEO: This interface will be implemented utilizing the Smart Message Bus. The main protocol that will be tested in the first implementations will be the OCPP, to test the monitoring and control of EVSEs and the EV user charge authorization. EV user–EVSE interface: This interface is of low priority for the AIT lab. Only the information necessary to carry out interoperability tests will be implemented. The focus will not be set on the interface implementation (RFID, Credit Card, etc…) but on the information to be exchanged. EVSE/EV–DSO: This interface will be implemented utilizing simulated/emulated actors as well as real DUTs, and is one of the interfaces of main concern for AIT. Evaluations of this interface will focus on multiple tasks, such as for example: o Grid interoperability: the ability of the EVSE/EV to charge in different grid conditions. o Grid failure behaviour: the behaviour of the EVSE/EV in the case of unexpected grid errors such as e.g. voltage drops or frequency shifts. o Communication: although not available at the moment, it can be foreseen in the (near) future that EVSE/EVs and DSOs will communicate. This communication will be evaluated with the same priority as the energy evaluations mentioned above.
Summing up, the main asset of the AIT EV/EVSE interoperability laboratory will be the flexible implementation of all the relevant actors in both simulation and emulation domains. Consequently, they can be replaced by a real DUT, which will be embedded in a fully restorable and adjustable laboratory environment.
D1.3 27-59 EU Project no. 608934
Figure 4: AIT lab scheme
The figure above shows the future AIT laboratory scheme with an EVSE as DUT. In the final stage of the AIT laboratory implementation, every component depicted beneath the Simulation Message Bus will be eligible to become a DUT for interoperability tests, either as real device or as emulated device.
This is presented below in a more simplified way to focus on the actors involved in the lab architecture.
Figure 5 AIT lab strategy
3.2. DTU
DTU's NEVIC centre tests the functional interoperability of EVs and EVSEs according to IEC and SAE standards. The interfaces that will be tackled at NEVIC according to DTU strategy are the following: EV-EVSE interface: uncontrolled, basic and smart charging according to IEC 61851 and ISO/IEC 15118 protocols. Simulated and real EV, EVSE and connection cables are available at the laboratory, including the following features: AC charging (slow and fast), DC charger (at the moment, charging and discharging without communications) and V2G charger. V2G characteristics according to ISO/IEC 15118 are expected to be tested. EVSE/EV-Secondary Actor (DSO/TSO/Aggregator): Simulation of stakeholders in a DTU backend system. Facilitating IEC 61850 (IEC 61850-90-8), OpenADR and a proprietary protocol based on web services. Used to perform smart grid services.
Variable grid and load systems will also part of the laboratory. Simulator, emulators and/or reference systems are an essential part of test cases design at NEVIC.
There are other interfaces that DTU finds interesting. Works are carried out on some of them, even if they will likely not be offered in the laboratory the short term: Secondary Actor backend-ICT Platform interface: DIN 91286 protocol was expected to be deployed (the pilot dealing with this stopped before it could be tested). DSO-HEMS: IEC 62746 (Open ADR) protocol is used for EV control in demos by DTU.
D1.3 28-59 EU Project no. 608934
EVSE-EVSEO: OCPP. EV user-EVSE: Apps giving the user control of the EVSE. EV-ICT platform interface: ITS systems. EV-EV user interface: Apps from DTU's data logger to a mobile phone. EV-EV interface: CAN SAE J1939.
Figure 6 DTU lab strategy
3.3. IWES
The IWES test system developed in the frame of COTEVOS will be focused on the EV-EVSE interface: EV-EVSE interface: AC charging based on both IEC 61851 and ISO/IEC 15118 protocols. Total control will be possible over the PWM signals and the messages that will be exchanged between both systems. In this regard, the test system should be able to test both EV and EVSE acting as DUT. The ongoing work on the ISO/IEC 15118-4 will be used as input: conformance testing according to the CD version of the draft. Tests will be automated using the TTCN-3 abstract language.
However, according to IWES other interaction between actors may also be interesting in a longer term: DSO-HEMS: IEC 62746 (Open ADR). DSO-EVSE. EMS/Smart meter-EVSE/Smart socket: first in buildings and after that in homes. EVSEO-EVSE. EV-smart socket: Mobile metering.
Additionally, IWES has the capability to integrate electrical vehicles and charging points in more complex systems, including renewable energy generation and management. Therefore, they are able to study the influence of other actors in EV charging processes. Laboratory capabilities at IWES on e- mobility include the following: Integration with smart grids. Roller dynamometer combined with virtual batteries. EMC Tests. Conformance tests of ISO/IEC 15118. Conformance tests of IEC 61851. Hardware in the loop. Development and test of wireless charging systems.
D1.3 29-59 EU Project no. 608934
Figure 7 IWES lab strategy
3.4. RSE
The general scenario behind the RSE strategy considers a flexibility service implementation, leading to secondary frequency regulation support. In this scenario, an energy service provider (aggregator, supplier, Balance Responsible Party) will provide energy services to the grid through the aggregation of the flexibility provided by EV charging infrastructures. The interaction between the aggregator and the EV charge infrastructure will be based on the coming IEC 62746 standard, in relation with the OpenADR protocol. The consequent EV smart charging control procedure will be deployed both at public (through EMSP and EVSO) and private domains (through a Customer Energy Management System).
RSE will deal with the following interfaces for interoperability testing according to the current previsions: EV-EVSE interface: it is expected that the basic AC smart charging will be assessed through the IEC 61851 protocol. Both EV and EVSEs will be the devices under test (DUT). Besides a measurement and recording system of 3-phase voltages and currents, EV-EVSE Interface tests will be available. The main tasks of the system are the following: o Characterization of the voltages/currents spectrum. o Analysis of the charging process transients that can occur as consequence of amplitude or frequency changes at the AC feeder. EVSE-EVSEO backend interface: the OCPP protocol will be assessed for the monitoring and control of EVSEs. The EVSEO backend system communication with the EVSE will be considered as DUT. EMSP-Aggregator (Secondary Actor-Secondary Actor) interface: The energy service provider (aggregator) communication with the EMSP will be tested according to the IEC 62746 standard.
In order to support the test cases, other actors and interactions will be simulated according to protocols not related to international or de-facto standards: EV user-EVSE interface: identification and authentication. EV user-EMSP interface: for EV user charging preferences communications (charging time and energy requested). EVSEO-EMSP interface: metering information and EV supply settings should be exchanged Smart meter-meter operator interface: metered data for billing purposes (demand response assessment).
In addition to this, other systems are expected to provide additional functionalities: a Virtual DSO, for the connection of real EVSEs; and a Virtual EVSE+EV+Meter to check the scalability of the solution.
RSE’s laboratory capabilities on e-mobility before starting COTEVOS project were restricted to communication between EV-EVSE based on PWM signal, according to IEC 61851-1 standard, and the monitoring of current and voltage (single phase or three-phase) aimed at determining the charging power, energy and efficiency.
D1.3 30-59 EU Project no. 608934
Figure 8 RSE lab strategy
3.5. TECNALIA
TECNALIA's EV laboratory strategy will be focused in two domains: the EVSEO - EVSE - EV region and the clearing house (CH) offering roaming services. Testing capabilities are described below more in detail: EV-EVSE interface: uncontrolled charging and basic smart charging in AC through IEC 61851 and ISO/IEC 15118 protocol implementation. The laboratory can test both EV and EVSE by means of two high level platforms for real testing. A total control will be possible for the generation of charge management signals over the two protocols. Both EV and EVSE simulators will have remote monitoring and control capabilities. EVSE-EVSEO backend interface: the EVSE will be able to communicate with other actors using the OCPP protocol. When the DUT only implements the IEC 61851 standard, the charging schedule will be adapted internally by the EVSE to provide the power settings through the PWM signal. Secondary Actor backend-ICT Platform interface: the communications between the EVSEO and a clearing house platform will be performed using the OCHP v1.2.
Other interoperability aspects that are considered interesting by TECNALIA, even though related to testing capabilities that will not be developed in at this stage in the laboratory, are the following: Those affecting the standardization of products leading to an expected reduction of costs in the EV and smart grids sector: DSO-EMS and EVSEO-EVSE. Metering back office - DSO/Retailer and metering back-office - smart meters are relevant but not specific to EVs (smart grid scope). Those affecting directly the ability of EV users to charge the vehicle in different locations: EV user - EVSE (even if this could be bypassed by an easier EV user-EMSP/EVSEO/IOP platform connection) and EV-EVSE. Those affecting the information flow between EVs and infrastructure (ITS): EV-ICT platforms and EV-EV. Those affecting the network services provision harmonisation: DSO-EMS and DSO- Aggregator. Those affecting the security of ICT developments: all cyber communications are affected but they should be solved from a smart grid perspective (smart grid scope).
TECNALIA's laboratory capabilities on e-mobility before starting COTEVOS were restricted to mechanical and electrical tests on the IEC 61851-1 standard, with no involvement with PWM communications.
The developments taking place in the frame of the project will permit TECNALIA to test communications for smart charging processes, including the connection to an own clearing house platform and the possibility to exchange data and, therefore, share tests, with other external laboratory systems belonging to the consortium. D1.3 31-59 EU Project no. 608934
Figure 9 TECNALIA lab strategy
3.6. TNO
TNO's strategy, which will be brought to life through the concept of the EV-IOP Lab-in-a-Suitcase, is based on a full e-mobility system approach, in order to be able to simulate and verify use cases and test cases on system level. EVSEs in combination with EVs (emulator expected) will be the main DUT and they will be connected to a PC containing a simulated environment including EVs, EVSE Operator, EMSP, DSO, energy retailer, clearing house and OEM (optionally, together with smart phones, smart cards and cables).
Although the focus will be set on the whole e-mobility system, the tests will address the following interfaces: EV-EVSE interface: uncontrolled charging and smart charging in AC, implementing IEC 61851 and/or ISO/IEC 15118 protocols, is targeted. EVSE-EVSEO backend interface: OCPP related tests are expected and required to perform good EVSE interoperability tests. EV user-EVSE interface: RFID based identification processes will be tested, when required to get the charging process started at the EVSE. Secondary Actor-Secondary Actor: the protocols that will be used for the communication between the different secondary actors need still to be selected but the aim is to test smart charging with the whole system approach. Since not many protocols are already standardised here, the focus will be set on interoperability at information level and not at communication technology level. The EVSEO - EMSP and DSO - EVSEO/EMSP links are considered of high importance. The protocols that will be specially considered are OpenADR, PowerMatcher, and OSCP.
High interest is found by TNO in the following interfaces, even if no testing activity is foreseen around them in the short term: Secondary Actor systems-ICT platforms: the interactions with clearing houses and energy markets.
Because of a broad ICT system and architecture expertise, and also smart grid (application) expertise including EV integration, TNO focusses in this project on e-mobility interoperability from the system and smart grid perspective. Since the smart grid is not available yet, they decided to simulate it
D1.3 32-59 EU Project no. 608934
partially, including multiple EVs, and integrate a real EVSE in the architecture. Then, the functionality and interoperability for that setup will be verified.
Figure 10 TNO lab strategy
3.7. TUL
In connection with its previous experience in the microgrids field, TUL wants to study the feasibility of integrating the EVs in the network using the IEC 61850-90-8 protocol, which is part of the 61850 series, first developed to address substation control aspects. This is due to the assumption that it is reasonable to adopt existing and accepted standards, since V2G functionalities are under discussion and there can be many potential interoperability issues related to them. Such an approach may be beneficial, since it does not require major investments into existing systems and it may be used to assess the limitations of already implemented (or known) communication protocols in real life conditions.
At present, the TUL’s laboratory infrastructure consists of a commercial SCADA system and the real time digital simulator (RTDS). Both can be adopted for the needs of IEC 61850 protocol. The SCADA system integrates controls and archives the measurements from all devices and from the LV network model located in the DER Laboratory of the Institute of Electrical Power Engineering. The RTDS system allows to simulate the investigated LV networks and to connect them, through a power amplifier, with the real charging station (DUT).
In order to investigate the problems related to the integration of EVs with the supply network, TUL plans to connect the SCADA system and the EV charging station utilizing the IEC 61850 protocol. The interfaces that will be considered by TUL are the following: DSO-EVSE: the IEC 61850-90-8.
Additionally, on the basis of same approach, the following interfaces might be taken into account if required: EVSEO-EVSE: the IEC 61850-90-8. DSO-EVSEO: the IEC 61850-90-8. EVSE-EV: the uncontrolled charging and basic smart charging in AC through IEC 61851 protocol implementation.
D1.3 33-59 EU Project no. 608934
Figure 11 TUL lab strategy
3.8. Views from other COTEVOS partners
The vision of partners not directly involved in developing testing capabilities in the frame of the project does also add value towards the unified laboratory definition. Below are presented some inputs to this respect.
ETREL lab capacities are based on the real needs of an EVSE OEM. They have simulated a complete system in order to complement real and emulated devices. The interfaces considered by ETREL are the following: EV - EVSE interface: uncontrolled charging and basic smart charging in AC through IEC 61851 and ISO/IEC 15118 protocol implementation. Both EVs and EVSEs can be the devices under test (DUT). Preferably, a real EV is used for testing IEC 61851 communications with the EVSE. However, in the case of the ISO/IEC 15118, an emulated EV is currently used due to the limited commercial availability of vehicles with this standard. In both cases, only AC charging scenarios can be tested. EVSE - EVSEO backend interface: ETREL's proprietary protocol for EVSE monitoring and control is used for EVSE communication and can be tested. The backend solution is compatible also with OCPP 1.2 and OCPP 1.5 protocols. Both the EVSEO backend system and the communication with the EVSE can be considered as DUT. EV user - EVSE interface: EV user identification through RFID cards can be tested using ISO/IEC 14443A and ISO/IEC 15693 standards. Smart phones are also considered as EV user identification means. At the moment, only SMS identification is supported but it is expected that, in the mid-term, also NFC identification will be developed, although it will not be tested. The EV user can be real or simulated. SA backend - ICT Platform interface: the communications between the EMSP/EVSEO and the EV roaming (clearing house) platform are performed via a proprietary protocol based on web services, which is already being used in real application as the backbone of the Slovenian roaming platform (connecting EMSP and EVSEO backend systems).
Other links implemented to support the whole architecture are the following: EVSEO backend - DSO backend interface: the DSO backend (virtual power plant operated by a Slovenian DSO) will be partially simulated to send and receive the essential parameters allowing the development of smart charging use cases. No standard protocol is foreseen to be used.
Simulated secondary actor components, with the exception of those of the DSO, will be based on real world applications (EVSEO, EMSP and CH backends).
D1.3 34-59 EU Project no. 608934
Figure 12 ETREL lab strategy
Zapadoslovenska Distribucna (ZSDIS) provides the utility point of view to COTEVOS. ZSDIS sets the standardization priority needs on the Aggregator-DSO link since, unless required by national regulations, no direct involvement is expected between the DSO and the final consumers (homes, EVSEs, EVs). In consequence, the aggregator, which might play the EMSP or energy provider roles, should be included in the general e-mobility picture.
The systems already used by DSOs (SCADA systems) should be the basis for the new communications with the aggregators. Communications in electrical distribution systems in many EU countries are currently based on IEC 60870-5-101 and 104 standards. They are used in HV/MV- substations. ZSDIS and E.ON, as DSOs, support the development of IEC 61850 as a common future standard with focus on feed-in management and MV/LV-substation-automation. The DSOs’ needs have to be taken into account during the standards development, otherwise complex and expensive solutions could result. The development of new parts of the IEC 61850 series offers the possibility to improve the network management. They may become useful for ancillary network services in the medium voltage, e.g. voltage control and reactive power management.
Other important interfaces for ZSDIS are the following: Meter-metering back office systems: it should be covered by smart metering standards. Metering back office-DSO. DSO/retailer-energy customer. HEMS/smart meter-EVSE/smart socket. EVSEO-EVSE: when the DSO plays the EVSEO role.
NTUA is not part of the COTEVOS consortium but, as third party, they are directly involved in the project and they will participate in round robin tests. Their laboratory has not yet any EV related equipment but NTUA is planning to enhance the facilities for the scope of the round robin tests within the framework of COTEVOS: the acquisition of one EV simulator and one EVSE simulator is planned. The option of buying a real EVSE is examined and it will be accomplished depending on the capital cost and the available budget. Thus, NTUA will focus on the communication interoperability issues between the EV and EVSE. EV-EVSE interface: uncontrolled charging and basic smart charging in AC through ISO/IEC 15118 protocol implementation. The OpenV2G project provides the basic functionalities for testing the IEC15118, and probably this will be utilized for the laboratory tests. EVSE-EVSEO backend interface: OCPP related tests are under consideration.
D1.3 35-59 EU Project no. 608934
3.9. Summary
The following Table 5 sums up the vision and strategy of the different COTEVOS partners, mainly of those developing testing services. The interfaces between components identified in the state of the art have been assessed from two points of view: Their standardization relevance, market interest and implementation cost estimation. These four columns in the table represent the current vision of COTEVOS partners. Possible answers to these questions were limited to High (H), Medium (M) or Low (L) and all responses are gathered in Annex A. Partner's current strategy, through their expected laboratory service offer. The last column of the table includes the protocols partners will try to implement in their laboratory architectures in the framework of the project.
The communication interfaces described in the first four columns in the table are based on the state of the art analysis (Figure 2) but new protocol proposals by partners for have been added. All interfaces have been assessed from three perspectives trying to give response to the following questions related to interoperability: Standardization relevance: How relevant is it to standardize, at EU level, the communications between these actors to provide interoperability for EV users charge? Market interest: How important do you think market interest will be in the short and medium/long term for this interface? Implementation costs: How costly will it be to implement the standards for each interface (in general, for all parties involved)?
Three interfaces in the table were left in grey because it is considered that they are extensively developed, already today, in the smart grid context by testing organisations. For this reason, they will not be a main aim of COTEVOS project e-mobility laboratories. These interfaces are the ones involving the smart metering back office systems and general security aspects of communications in the internet (affecting routers, servers, etc.).
D1.3 36-59 EU Project no. 608934
Table 5 IOP vision and strategy by COTEVOS partners Communication Applicable standards Standardization Market interest Cost COTEVOS partners from to Communication Information relevance Short Medium/ expected services term long Proprietary OCHP Web services DIN 91286 Secondary ICT platform Http(s) WXMM, WMO... L-M L-M M-H L-M OCHP: 1 partner Actor system (front-end) IEC 61968-100 OASIS EMIX... EN 62325-450/451 IEC 62325(-301/351) IEC 61970-301 IEC 61968-11 ICT platform EVSE Web services Proprietary M-H L-M H L-M (front-end) Proprietary IEC 62746 (Secondary Web services Secondary Secondary OSCP Actor-Aggregator): 1 Http(s) M-H L-M M-H M Actor Actor IEC 62746 (Open ADR) Open ADR, OSCP, Batch messages IEC 60870-6/TASE.2 (ICCP) PowerMatcher: 1
DSO HEMS IEC 62746 IEC 62746 H L M-H L-M
Not specified: 1 IEC 61850(-90-8) IEC 61850(-90-8) DSO EV M L L-M M-H IEC 61850, OpenADR, ISO 15118 ISO 15118 Proprietary: 1 IEC 61850(-90-8) IEC 61850(-90-8) Not specified: 1 IEC 60870-5- IEC 62746 IEC 61850, OpenADR, DSO EVSE M-H L M-H M-H 101/104 IEC 62056 (extended, Proprietary: 1 IEC 62746 PowerUp) IEC 61850-90-8: 1 Web services Energy DSO/Retailer Http(s) Proprietary M M-H H L customer Batch messages Metering back IEC 61968 IEC 61968 DSO/Retailer M M M-H L-M Smart grid context office (IEC 61970) (IEC 61970)
D1.3 37-59 EU Project no. 608934
IEC 62056 IEC 62056 (DLMS/COSEM) (DLMS/COSEM) pr TS 50568-5 pr TS 50568-5 (meters&more) Metering back ETSI TS 102887 IEEE 1377 Smart meter M-H M M-H M-H Smart grid context office EN 14908 (Lontalk) EN 13321 EN 13321 EN 14908 (Lontalk) EN13757 (MBus) EN13757 (MBus) 3GPP, ISDN ANSI C12(USA)
EV 14908 (Lontalk) EN13757 (MBus) EV 14908 (Lontalk) EN 50090 (HBES) EN13757 (MBus) HEMS/smart EVSE/smart FNN EDL (DE), EN 50090 (HBES) M L M L-M meter socket Echonet, LonWorks FNN EDL, Echonet, HomePlug Green LonWorks Phy, Zigbee, Wifi, SEP 2.0 ethernet Web services Proprietary ITS Fleet manager EV ITS M-H L M-H M GPS IEC 61850(REST*) IEC 61850 Web services OCPP EVSEO EVSE IEC 61850-90-8 IEC 61850-90-8 H M M-H M OCPP: 4 Modbus Proprietary Secondary Web services EV user Actor and ICT Http(s) Proprietary L-M L M L systems Batch messages RFID, NFC... Proprietary EV user EVSE Credit card H H H L-M RFID: 1 Credit card Code (QR, bar...) Proprietary (master/slave EVSE EVSE PLC, ethernet... L L L L communication) Web services Proprietary Http(s) ICT platforms/ ETSI TS 101556-1 EV ITS G5, WAVE M-H L M M systems ETSI TS 102894-2 3GPP TPEG TPEG
D1.3 38-59 EU Project no. 608934
IEC 61851-1 IEC 61851-1 IEC 61851-23/24 IEC 61851-23/24 IEC 61851: 6 partners EV EVSE ISO 15118 ISO 15118 H M-H M-H M-H IEC/ISO 15118: 5 SCCP SCCP CHAdeMO CHAdeMO
EV Smart socket PLC Proprietary M L-M M-H L-M Bluetooth, Wifi, EV EV user Proprietary L-M L M-H L NFC... ITS G5, WAVE EV EV ETSI TS 102894-2 M L M-H M 3GPP
EV (Inside the EV CAN SAE J1939 CAN SAE J1939 L-M L L-M L Vehicle)
Proprietary EAP Radius/UDP Routers, VPN/IPsec Tacacs+/TCP Network (AAA) L-M L-M M H Smart grid context servers... IEC 62351-8 X.509 IEC 802.1X EAP IEC 62351-8 *REST mapping should be valid in all IEC 61850 deployment even if indicated only here A reference list of the standards in the table is provided in chapter 6.2.
D1.3 39-59 EU Project no. 608934
Figure 13 below summarizes, taking as basis the general interface picture, the stakeholders and protocols COTEVOS laboratories will deal with according to their current strategies (synthesis of previous figures 5 to 11 and last column of Table 5). The interfaces and protocols that will be covered by COTEVOS partners according to current expectations are also summed up here:
EV-EVSE interface: it is the most widely covered because it is the basis of all types of charging. IEC 61851 and ISO/IEC 15118 are the most addressed protocols, focusing mainly on AC charging procedures and considering charge control options. Due to its complexity and limited market deployment, the ISO/IEC protocol will be partially implemented by most of the laboratories at a first stage. EVSE operator-EVSE: The interconnection between the EVSE operator and the EVSE is one of those relying more on proprietary protocols, however, it is deemed of high interest. OCPP is the preferred option but IEC 61850-90-8 might be also considered by one of the partners. EV user-EVSE: This interface is related to the authentication phase of the charging process and some partners will consider it just as a pre-requisite for charging. RFID cards seem to be the most spread technology option. Secondary Actor-Secondary Actor: the communication between secondary actors (EVSE operator, EMSP, DSO, aggregator...) is considered of interest for smart charging processes involving end-to-end data exchange. Here, the DSO-aggregator/EMSP link and the communication between EMSP and EVSEO are the preferred interfaces. The protocols that will likely be implemented are the IEC 62746 (OpenADR based), the OSCP and the PowerMatcher. DSOs promote the use of the IEC 61850 series of standards (90-8 is the part devoted to e-mobility infrastructure) to maintain the coherence with the current developments in the field of smart grids. Secondary Actor-Clearing House: OCHP based protocols will be implemented in one of the laboratories to provide the connection to clearing house platforms. DSO-EV/EVSE: The direct control of EV and EVSE by the DSO is one of the aspects considered not feasible by some partners (the participation of an aggregator is foreseen in this cases) and important by others. The IEC 60850-90-8 protocols will be considered in COTEVOS to address this interface.
D1.3 40-59 EU Project no. 608934
Figure 13 IOP current strategy by COTEVOS partners
D1.3 41-59 EU Project no. 608934
4. The concept of the test for assessing interoperability
According to the definition by the Working Group Interoperability (WGI), which is working under the Smart Grid Coordination Group (SG-CG), Interoperability is the ability of two or more networks, systems, devices, applications, or components to interwork, to exchange and use information in order to perform required functions [4].
COTEVOS partners agreed that the last objective for e-mobility interoperability is that any EV user is able to charge easily at any public EVSE. Therefore, when selecting a test case, it should be considered the need for a product to comply with the interoperability requirements of all involved interfaces. When no interoperability conditions are met or defined, but that does not hinder the user to perform the desired function easily, the main objective is fulfilled and no interoperability requirement should be asked. For example, the mobile phone app allowing users to manage charging at an EVSE will probably not have any reference standard for harmonisation; however, users will still be able to charge their vehicles just by downloading and installing the required application from the internet (the interoperability problem is a smart phone issue in this case).
When interoperability requirements are needed, then the relevant standard must be applied. Nevertheless, even in the case of products expected to be interoperable (because they meet certain standards), some functions might not work properly, with the corresponding lack of interoperability. This highly depends, for instance, on the tolerances and accuracy of the definitions in the standard. Obviously, this type of case asks for interoperability assessment.
As shown in the previous section, project partners are already advancing in the definition of their strategies for EV interoperability assessment. In parallel, the particular view of each laboratory is moving towards the unified laboratory through different steps of the project development: Common framework developed in the state of art phase coherent with the SGAM approach. It is presented in section 2 of the present report. Common laboratory reference architecture where the strategies of all partners fit and which permits to share resources for test case implementation at EU level. It has been developed in the framework of WP3 and it is included in D3.2 [5] (see Figure 14). Common set of test cases defined for EV IOP assessment. It is an ongoing task in the frame of work packages 3 and 4 but the first results have already been presented. Round robin test development (inter-laboratory comparison tests) to assess that the testing procedures of the different laboratories produce the same results. Discussion and verification of COTEVOS approach outside the consortium (workshops). A workshop was held in Roskilde (2nd October 2014) where very relevant stakeholders in the EV sector presented their points of view and gave feedback to the project approach and developments to that date (see minutes of the meeting in Annex B). In addition, the project was also presented in the USA through visits to two important institutions: Argonne National Laboratory and NREL (National Renewable Energy Laboratory).
The common laboratory reference architecture has been agreed in the frame of WP3. It is flexible enough to admit all partners' strategies and it considers the possibility to connect simulated/emulated and real components remotely through the network. This makes possible to perform tests using the infrastructures of various laboratories, which will likely result in more cost-effective solutions.
D1.3 42-59 EU Project no. 608934
Figure 14 Common laboratory reference architecture in COTEVOS
Regarding test cases, they are mainly developed in the frame of WP4. Up to this moment, 28 test cases have been identified and they have been classified into 6 groups.
Figure 15 Test cases groups
Each of these test cases will be defined considering the following fields: General information: Test case ID, version, date Device under test (DUT) Test equipment EVSE specifications EV specifications Pre-conditions Test case description Post-conditions
The results of this work will be presented in D4.3.
This whole project approach was presented in a workshop held in Roskilde (DTU premises), where several relevant stakeholders from the EV sector participated as guests. Comments and interesting experiences were obtained from experts, which will become a valuable input for the future steps of the project. In addition, Argonne and NREL laboratories in the USA were visited in the summer of 2014 to share visions and results.
D1.3 43-59 EU Project no. 608934
5. Conclusions: requirements for unified test procedures
5.1. The challenge of e-mobility interoperability assessment
Regulatory aspects will influence the development of business models, while the demand will respond to their offer according to socio-economic conditions. All in all, most likely, differences will exist in markets at regional level, in spite of the harmonisation efforts taking place at EU level. In this context, several business/market models and services related use cases are expected in the e- mobility field in Europe, even if final solutions remain unclear yet.
We can consider different interoperability levels. One first approach is related to the charging process in public domains. Charging is the main service in the e-mobility context and here the objective of interoperability is to guarantee that any EV user is able to charge easily in the public infrastructure. This can be achieved in several ways, for example, open access to EVSEs (there is no need of a contract with an EMSP); uncontrolled charge (electro-mechanical level interoperability is "enough" to permit charging); smart charge, leading to the interaction between different stakeholders and involving end-to-end communications. This last option, introduces a second approach to interoperability, which is related to the integration of the charging process within smart grid systems.
Considering all this, several e-mobility interoperability levels can be taken into account in relation with both the smartness of the charging process, market model schemes, demand response strategies and other factors. This gives room to a great variety of interoperability use cases and related test cases. Some possible examples are: Electro-mechanical interoperability. Uncontrolled charging interoperability with open access to EVSE. Uncontrolled charging interoperability with local authorisation. Uncontrolled charging interoperability with remote authorisation. Uncontrolled charging interoperability with roaming. Controlled charging by the EVSE operator. Controlled charging considering system operator requirements. Controlled charging considering system operator requirements and end user preferences. Controlled charging with roaming authorisation. Controlled charging according to a specific demand response strategy. Controlled charging in the residential domain through CEMS.
The integration of e-mobility in the smart distribution grids turns out to be of paramount importance and an effective combination of both lies, to a large extent, in ICTs. Here, some key points related with this: The high number of involved stakeholders/roles and systems (components) depicts a complex interaction scenario. System operator's technical and business philosophies will affect the adoption of related solutions. The electricity system characteristics of each region will certainly have an impact in regard to charging infrastructure deployment, affecting EV penetration and the potential services for charging. Although e-mobility related standards should be the basis for IOP testing services in COTEVOS, ICT protocols in other fields of smart grids (network operation, AMI, ITS, home automation, etc.) must also be taken into account. The state of art analysis permitted to draw the following main conclusions on ICT protocols: The number of e-mobility related standards is not big but final solutions are diverse. In the practice, some of the standards are too complex to be implemented without the backup of a clear revenue model. Some protocols do not permit to cover all the services providers wish to offer, which leads to the utilization of proprietary solutions. Some of the interfaces between components are not realistic in certain market or business contexts, for example, the direct control of an EV charge by a DSO. D1.3 44-59 EU Project no. 608934
Some standards are still at development stage. Many protocols are not properly designed to provide interoperability at all levels. The lack of definition, the broad tolerances, etc. require more accurate specifications. One example is the information format and storage in RFID cards. It is expected that standards developed in other fields, such as smart grids, ITS and home automation, will be part of end-to-end communications for e-mobility related services. The number of standards is high and their deployment is not uniform yet throughout Europe.
As an example of the above, the use of proprietary protocols is spread when dealing about data exchange. Sometimes, these protocols are based on international or de-facto standards but, in other occasions, developers establish their own requirements. The main objective behind is to make ICTs suit better specific business models, which may rely, to some extent, on product/services differentiation from competitors. This does not facilitate interoperability but it is a characteristic of the current e-mobility market and it will probably remain like this in the short term.
Many are the challenges addressed above. Still, some considerations might help simplify the global problem: To set the focus on roles may help overcome the variety of stakeholder names and functions, which depend on specific market models and regulatory frameworks. At system/component level, it is also possible to find common areas. For example, the backend and frontend systems of different stakeholders might be similar. This reduces the casuistry of the problem. The number of services related to EV charging is not short but it is limited. The communication options between components will be based on existing or already foreseen market solutions at lowest OSI layers. One of the exceptions is the EV-EVSE communication through the control pilot according to the IEC 61851-1, which is specific for the e-mobility field.
5.2. COTEVOS approach for a unified interoperability assessment
The EU wide harmonisation challenge in the field of smart grids has driven COTEVOS project efforts towards the setting up of a unified laboratory for e-mobility interoperability testing. The first step in the way to this objective was to agree on a common framework for all project tasks, which was finally based on the work of the Smart Grid Coordination Group.
The analysis of the state of the art permitted COTEVOS partners to have a broad view on the existing alternatives in the e-mobility field, from regulatory aspects to ICT protocols. This global picture helped those partners expecting to offer testing services in the future to draft their current strategy.
Participant laboratories assessed the interfaces between components, identified in the state of the art analysis phase. In general, their opinion about standardization relevance and market interest was linked to their expectations on testing services provision. However, in many cases, the interest of partners exceeded their short-term strategy, which is understandable, since the latter is conditioned by their business approach. This happened, for example, in regard to interfaces belonging to domains other than e-mobility, like home automation, AMI and ITS, or to too specific services, like the fleet management-EV link.
As it would be expected, partners' interests and expectations resulting from this first analysis were not totally uniform, which leads to complementarity when putting together all visions. Nevertheless, some common factors were also found.
In order to benefit from the complementarity of COTEVOS' laboratory approaches, a proposal is being discussed among partners with the final objective of sharing resources for test case implementation. Because many components of the e-mobility environment are based on ICTs and software applications in backend and frontend systems, it is technically feasible and realistic to exchange data between remote devices located in different laboratories to test interoperability. In this way, not all partners would be forced to develop the complete architecture containing all components (devices, applications, persons and organisations) involved in end-to-end communications. D1.3 45-59 EU Project no. 608934
Although a challenge, this represents a relevant approach towards a unified concept of laboratories for e-mobility assessment in Europe and it would also contribute to cost effectiveness of test procedures. Nevertheless, several barriers should be tackled in the way to achieve this goal, one of them being the agreement on economic aspects between the different participating entities.
In order to cope with most of the challenges presented in the previous section, the uncertainty surrounding future e-mobility scenarios and the broad options spectrum make necessary for laboratories to adopt flexible architectures able to adapt to a great variety of use cases linked to different market and business models.
A common laboratory reference architecture has been designed in the frame of WP3, in order to fit every partner's approach into one unified scheme. This architecture is flexible enough to cover the several use and test cases that may well coexist in the future in the e-mobility field in Europe. It permits to combine simulated, emulated and real systems and to define different devices under test (DUT).
Even if uncertainties are many, steps must be taken and, with that in mind, the most promising approaches according to current solutions will be used to define a common set of test cases. Test case definition results basic for the development of harmonised test procedures. This work has already started in the project and it will become a key input for laboratories' strategy definition on electro-mobility interoperability.
Round robin tests, for inter-laboratory comparison, will guarantee the validity of results in the future unified laboratory. The services offered by testing facilities will not be totally complementary but some overlaps will exist according to business model based strategies. For example, the EV-EVSE interface will be likely developed by many COTEVOS partners and IEC 61851-1 will be the basic protocol considered. Therefore, it should be demonstrated that the application of proprietary test procedures in the laboratories will lead to the same results in all of them.
Finally, the presentation of the project approach and results in the international arena will also help feed and validate COTEVOS proposals.
D1.3 46-59 EU Project no. 608934
6. References
6.1. General
[1] P. Kelm et al., Report on the needs for interoperability between EVs and the electrical power system, COTEVOS FP7 project (608934), Deliverable 1.1., 30/06/2014 [available: http://cotevos.eu/publications/] [2] First set of Standards, CEN-CENELEC-ETSI Smart Grid Coordination Group (SG-CG), version 2.0, November 2012 [available: http://ec.europa.eu/energy/gas_electricity/smartgrids/doc/xpert_group1_first_set_of_standards .pdf] [3] R. Rodríguez et al., Specification, analysis and assessment of situation of interoperability related to EV deployment in EU cities and member states, COTEVOS FP7 project (608934), Deliverable 4.1., 26/08/2014 [4] Methodologies to facilitate Smart Grid system interoperability through standardization, system design and testing, WGI (Work Group Interoperability), CEN-CENELEC-ETSI Smart Grid Coordination Group, final draft report v2.2., 21/10/2014 [5] E. Werkman et al., Set up of the reference architectures in some COTEVOS infrastructures, COTEVOS FP7 project (608934), Deliverable 3.2., final version, 11/2014
6.2. Standards references
Table 6 Standard References
Standard number Standard Title Status (23/06/2014) Application integration at electric utilities - System Published: 26/07/2013 IEC 61968-100 interfaces for distribution management - Part 100: Implementation profiles Framework for energy market communications Part 450: Profile and context modelling rules Published: 26/07/2013 Part 451-1: Acknowledgement business process and Published: 08/05/2014 contextual model for CIM European market IEC 62325-450/451 Part 451-2: Scheduling business process and contextual Published: 07/10/2013 IEC 62325-301/351 model for CIM European market Part 301: Common information model (CIM) extensions Published: 08/05/2014 for markets Part 351: CIM European market model exchange profile Published: 26/09/2013 Energy management system application program Published: 13/12/2013 IEC 61970-301 interface (EMS-API) - Part 301: Common information model (CIM) base Application integration at electric utilities - System Published: 06/03/2013 interfaces for distribution management - Part 11: IEC 61968-11 Common information model (CIM) extensions for distribution Systems interface between customer energy Published: 19/02/2014 management system and the power management system IEC/PAS 62746-10-1 - Part 10-1: Open Automated Demand Response (OpenADR 2.0b Profile Specification) Communication networks and systems for power utility Diverse IEC 61850 automation (various parts) Communication networks and systems for power utility Draft: 04/10/2013 (PWI) IEC/TR 61850-90-8 automation – Part 90-8: IEC 61850 object models for electric mobility Road vehicles - Vehicle to grid communication interface Diverse ISO 15118 (various parts) Telecontrol equipment and systems IEC 60870-5-101/104 Part 5-101: Transmission protocols - Companion Published: 07/02/2003 D1.3 47-59 EU Project no. 608934
standard for basic telecontrol tasks Part 5-104: Transmission protocols - Network access for Published: 13/06/2006 IEC 60870-5-101 using standard transport profiles Application integration at electric utilities - System Diverse IEC 61968 interfaces for distribution management (various parts) Energy management system application program Diverse IEC 61970 interface (EMS-API) (various parts) Electricity metering data exchange - The DLMS/COSEM Diverse IEC 62056 suite (various parts) Electricity metering data exchange - The DLMS/COSEM Draft suite - Part 8: PLC profile based on SMITP B-PSK modulation - Including: The Original-SMITP PLC profile pr TS 50568-5 based on SMITP B-PSK modulation, The Original-SMITP Local data exchange profile and The Original-SMITP IP profile Electromagnetic compatibility and Radio spectrum Matters (ERM); Short Range Devices; Smart Metering ETSI TS 102887 Wireless Access Protocol Part 1: PHY layer Published: 07/2013 Part 2: Data Link Layer (MAC Sub-layer) Published: 09/2013 Information technology -- Control network protocol Diverse ISO/IEC 14908 (various parts). LonWorks Open data communication in building automation, Diverse EN 13321 controls and building management - Home and building electronic system (HBES) (various parts) EN 13757 Meter-Bus (various parts) Diverse IEEE Standard for Utility Industry Metering Published: 08/10/2012 IEEE 1377 Communication Protocol Application Layer (End Device Data Tables) Home and Building Electronic Systems (HBES) (various Diverse EN 50090 parts) Intelligent Transport Systems (ITS); Infrastructure to Published: 07/2012 ETSI TS 101 556-1 Vehicle Communication; Electric Vehicle Charging Spot Notification Specification Intelligent Transport Systems (ITS); Users and applications requirements Part 1: Facility layer structure, functional requirements Published: 08/2013 ETSI TS 102 894-2 and specifications Part 2: Applications and facilities layer common data Published: 08/2013 dictionary Electric vehicle conductive charging system Published: 25/11/2010 Part 1: General requirements IEC 61851-1 Part 23: DC electric vehicle charging station Published: 11/03/2014 IEC 61851-23/24 Part 24: Digital communication between a d.c. EV Published: 07/03/2014 charging station and an electric vehicle for control of d.c. charging Serial Control and Communications Heavy Duty Vehicle Diverse CAN SAE J1939 Network (CAN Bus) (various parts) Power systems management and associated information Published: 29/09/2011 IEC 62351-8 exchange - Data and communications security - Part 8: Role-based access control IEEE Standard for Local and metropolitan area networks Diverse IEEE 802.1X (various standards) Telecontrol equipment and systems - Part 6: Telecontrol Diverse IEC 60870-6/TASE.2 protocols compatible with ISO standards and ITU-T (ICCP) recommendations ICCP: Inter-Control Centre Communications Protocol
D1.3 48-59 EU Project no. 608934
Annex A. COTEVOS partners inputs on vision and interests
Two tables are presented in this annex showing COTEVOS partners' responses in regard to their vision on interoperability assessment. All laboratories taking part in the project were asked to fill in the tables and two additional partners decided also to carry out that work and provide their point of view.
The first table shows the concepts of standardization relevance, market interest and expected implementation costs for several interfaces between actors (defined in figures 1 to 3). These responses represent the general vision of the partners.
The last column for each concept shows a summary response based on all partners' inputs (basis for Table 1 and Table 5). For some interfaces, great disparity occurs amongst partner opinions and an average response is derived from them (the "*" symbol represents this fact).
The second table depicts partners' own interest level on the defined stakeholders' interfaces. It is surely related to their strategy, shown in section 3 of this document, but it may also cover wider considerations.
Key for the tables: H: high M: medium L: low
D1.3 49-59 EU Project no. 608934
Table 7 Partner Responses - IOP vision
Communication Standardization Relevance Market interest - short Market interest - medium/long Implementation costs from to AIT DTU ETREL IWES RSE TEC. TNO TUL ZSDIS Total AIT DTU ETREL IWES RSE TEC. TNO TUL Total AIT DTU ETREL IWES RSE TEC. TNO TUL Total AIT DTU ETREL IWES RSE TEC. TNO TUL Total Secondary ICT platform Actor system (front-end) L L M M M/H M L/M L M M H L L/M* L H M H H M M/H* L M L L L/M ICT platform EVSE (front-end) H H L M H M/H L L M L L/M H H M H H H M L M L L/M Secondary Secondary Actor Actor L H H M/H H M H M/H L M M L L/M H L/M* L H M M/H M M/H* M M L/M M M DSO HEMS H H H M H H H H L L L M L L M L H M H H M H M/H L L H L M M L/M* DSO EV H H L L L H M* L L L L L L M M M L L M L/M H L H M M/H* DSO EVSE H H H H L L H M/H* L L M M L L L L H M H L M M/H M/H* H L H H M M/H* Energy DSO/Retailer customer M M M M M H M H M/H H M H H H L L L L Metering DSO/Retailer back office L L H H M* L H M M* L M H H M/H* M M L L/M Metering Smart meter back office L H H H M/H* L M H M M* L H H M/H* H M M/H HEMS/smart EVSE/smart meter socket M M H M M M L L M L L L L M M M M/H M* H L L L/M* Fleet EV manager H H L M M H M/H L L L L M L H L M M M H M/H* M M L/M M M M EVSEO EVSE H H H H H M H H H L L H M M M M M M* H L H M H M H M/H* M M M M M/H M L M Secondary EV user Actor and ICT H L L H L L M L/M* L L L M L L L M L L M H M M M* L L L L L/M L L systems EV user EVSE H H H H H H H H H H H M M H H H M H H H H H H H M L/M L M L L/M EVSE EVSE L L L L L L L L L L L L ICT EV platforms/ H M M H M H M/H L L L L M L M L M M M H M* M M H M M M systems EV EVSE H H H H H H H H H H H H M H M M H M/H L L H H H H H M/H* H H L H H H L M/H* EV Smart socket M L M H M* L L H L/M* M M M H M/H M L L L/M EV EV user L M L L M L L/M L L L L H L M H M M M H M/H L L L L L L EV EV H M L H M L M* L L L M L L H M M M H M M/H M M H M L M EV (Inside EV the Vehicle) L H L L H L/M* L L M L L L L M H M L/M* L L L L Routers, Network L L H L/M* L M L/M L M H M* H H servers... (AAA) *: average (some partners Low, some partners High)
D1.3 50-59 EU Project no. 608934
Table 8 Partner Responses - IOP interests
Communication COTEVOS partners interest from to AIT DTU ETREL IWES RSE TEC. TNO TUL ZSDIS Secondary ICT platform L H H H M Actor system (front-end) ICT platform EVSE M H M (front-end) Secondary Secondary L H H H Actor Actor DSO HEMS M H H H H M DSO EV H H L M DSO EVSE H H H H L H M Energy DSO/Retailer M H customer Metering DSO/Retailer L H back office Metering Smart meter L H back office HEMS/smart EVSE/smart L H H H meter socket Fleet EV M M M manager EVSEO EVSE H H H H H H H H H Secondary EV user Actor and L L L M M ICT systems EV user EVSE H H M H M EVSE EVSE L ICT EV platforms/ M H H M systems EV EVSE H H H H H H M EV Smart socket M H M EV EV user L H L EV EV L L M EV (Inside EV L H M the Vehicle) Routers, Network L servers... (AAA)
D1.3 51-59 EU Project no. 608934
Annex B. Minutes of COTEVOS workshop in Roskilde (02/10/2014)
D1.3 52-59 EU Project no. 608934
Workshop: Plans for Interoperability Assessment Infrastructures and Test Cases for EV Integration 2nd October 2014, Roskilde - Denmark Version 2.0
Participants Name Company Comments/add. info. Andras Kovacs Broadbit Arjan Wargers ElaadNL Klaas van Zuuren ElaadNL Filipe Joel Soares INESC Harald Scholz JRC Miguel Angel Reina Ortega ETSI CTI Nils Dullum RWE Denmark Sébastien Grolleau EIGSI La Rochelle Felix Lehfuss AIT Giorgio Mantovani ALTRA Siwanand Misara DERLAB Eva Nielsen DTU Helle Faber DTU Thomas Meier Soerensen DTU Marianne Bruntt Jensen DTU Peter Bach Andersen DTU Sergeous Martinenas DTU Chresten Træholt DTU Mattia Marinelli DTU Town Graham DTU Anders Pedersen DTU/Macc. Univ. Jure Ratej ETREL Rok Kralj ETREL Axel Vladimir Barahona-Abrego IWES Raúl Rodríguez TECNALIA Txetxu López TECNALIA Eduardo Zabala TECNALIA Marjan Gjelaj RSE Daniele Pala RSE Pawel Kelm LodzUT Blazej Olek LodzUT
D1.3 53-59 EU Project no. 608934
Robert Koffrie TNO Joost Laarakkers TNO Efren Guillo Sansano U. Strathclyde Ioannis Karakitsios NTUA
COTEVOS: Goals, achievements and challenges Eduardo Zabala (Tecnalia) Aims of the project Important activity around networking: external stakeholders can contribute or participate in testing and procedures We have defined the framework: D1.1 done (public), and D1.2 and D1.3 are coming Important links with the standardization world We are completing the specification and implementation of architectures and testing infrastructures We are starting to define and agree on the necessary test cases
COTEVOS’ role and interactions with standards Joost Laarakkers (TNO) COTEVOS Main input Standardization o The groups have shown the possibility of performing real tests o Not to create standards Few standards about interoperability (out of >200 around EV) Interoperability and BAP definition and concept o BAP example in WGI report
Pre-normative research at JRC for EV-EVSE interoperability and first results from industry cooperation Harald Scholz (JRC) JRC in only involved in PRENORMATIVE TESTING/RESEARCH (nothing for lab conformity business) o the work is done in partnership with Argonne National Laboratory (collaboration agreement between the EU and USA)Former VELA laboratory InterOp project: collaboration with 7 car makers around CCS (Combined Charging System - Combo) o Workshop in Ispra 4th 5th June14 o Testing for EV – EVSE interoperability including mechanical tests at different temperatures, PWM quality (slew rate, frequency tolerance), digital communication check, energy, charging functionality... Smart grid integration aspects were not tested. . Test tool and automated software . Plug interoperability o 32 EV manufacturers: needed to avoid customers' disappointment . Standardization landscape “with holes”, including different requirements for the same aspect within the same standardization body documents. We must try to give recommendations to the standardization world o Support Argonne and car industry o Scope: to develop a consistent modular interoperability test for EVSE and EVs100 potential Use Cases (UC) . Test cases: “it is important to define very clear failure criteria”
D1.3 54-59 EU Project no. 608934
. Also climatic test (for EVSEs but also for lorries,…): until -30ºC . Tests according to any potential case of use: everything "we could think of" that a non-experimented EV user could do while charging was tested and considering extreme weather conditions . Many test instruments from many manufacturers worldwide were used Important feedback to OEMs for, instance, about the “man in the middle device”: there is a risk to modify real conditions in the test. . Results will be made public soon.
Discussion: Identify interoperability needs and define COTEVOS's role Moderator: Joost Laarakkers (TNO) Joost: the UC of JRC-OEM projects will be available? o Yes Also harmonics analysis? o Yes eLaad: some more standards could be considered
Coffee break
Infrastructures for interoperability assessment in COTEVOS Felix Lehfuss (AIT) How should the interoperability infrastructure look like? o Different approach in each COTEVOS laboratory as we are making progress o eMobility cannot be expected to be absolutely standardized, so maybe a single approach and single reference architecture should not be expected o 3 types of reference architectures in COTEVOS (3 GRAPHS): . Approach used by TNO in BAIOP . “Organic” high level architecture based on SERVICES . Real laboratory architecture
ETSI CTI introduction and participation in tests and projects Miguel Angel Reina Ortega (ETSI CTI) About ETSI, as EU standards organization Also interoperability testing Organization: also Industry Specification Group Some successful stories: GSM, TETRA… (developed by ETSI) Centre for Testing and Interoperability (CTI): o Technical support and organization of Interoperability events (also for non ETSI standards) . ETSI PLUGTEST (Interoperability event) Main goal: to facilitate the validation and development of interoperability standards (support the standardization activity) Manufacturers can validate their products Free participation (apart from covering costs) Results are communicated maintaining participants' anonymity (covered by a NDA) Other bodies can participate as observers, but all of the signing the NDAs Events are open to any organization/company "bringing" something to be tested. Different locations and timetables, sometimes through the website
D1.3 55-59 EU Project no. 608934
ETSI CTI develops the test specifications o Participation in research projects: Power-Up, preparing the specification for the tests
Discussion: Needs and business opportunities for interoperability assessment Moderator: Felix Lehfuss (AIT) Does COTEVOS want to perform conformance testing? o Maybe some labs are doing it or will do in the future, but the aim is to test for interoperability ETSI CTI and PowerUp: the certification procedure for the communication has been adopted by IEC o And the Infrastructure: provided by specific expert test labs ETSI CTI / Andras: complexity because different smart grids, but, in the end, the real possibilities are few: OCPP, DLMS/COSEM,… Needs for interoperability o eLaad: . Identification and authentication: It is not clear which standards should be used as reference. Start with the use case, not every message set / business object / attribute is necessary in scope for a specific use case. . Smart grids o Andras: Need for EVSE reservation (present gap in ISO/IEC 15118) . Discussion: it is considered by OCPP, and it is a matter of assigning a user ID (with authorization) during a time slot o ETREL: Need to know where to read the ID within the RFID card
Lunch
Visit: the NEVIC centre
Test Cases and Round Robin Tests in COTEVOS Thomas Meier Sørensen (DTU) Legal requirements and COTEVOS certificate A, E, F interfaces pretty known. But F, B… can be difficult. Maybe no interest in C interoperability
List and grouping of UCs Test Cases
D1.3 56-59 EU Project no. 608934
Development exercise with two test cases o We will consider the convenience of clearly defining the failure situations
V2G conformance testing suite within ISO/IEC 15118 Andras Kovacs (BroadBit) Protocols: mainly based on IEC15118-2 and -3 Both EnterOp (German) and PowerUp projects have worked on ISO/IEC 15118 conformance test specifications team for 15118 These contributions are trying to be merged in the CURRENT VERSION OF 15118-4 ( on going, expected for 2016) Test case definition structure o Test cases specifications were developed in TTCN-3 abstract language. TPLan is used for a readable description of the test case. . The code is public, for free. The compiler must be bought o Three components: . Test case header: it identifies test case, objective and reference requirements being tested . Graphical representation of the test case process as a flow (automatically generated): some kind of sequence diagram . Compiler
OCPP (OCA) and testing/certification experiences in ElaadNL Arjan Warjers (ElaadNL) About ElaadNL: founded in 2009 by cooperating grid operators 3000 sockets o Actively developing and supporting OCPP, OCSP involving DSO (also OCHP, OCPI) . eLaadNL integrates them in their back office Based on past experience, ElaadNL started to perform firmware testing on OCPP implementation Bottom up approach: since COTEVOS is up-down, we can talk how to share experiences o Function layer: UC and BAP based development was limited . For instance, some misunderstandings related to Mode 3 occurred Invitation to set up an in-depth information exchange workshop with COTEVOS
Discussion: Which test cases should be implemented? Moderator: Thomas Meier Sørensen (DTU) How is developing OCSP? o In version 0.8. Some comments about flexibility provision and incentives by the DSOs Remark of the interest to reuse the UCs of the different initiatives What is important to be tested? o Andras: check unexpected scenarios, e.g., what happens with communications if the network fails? o Harald: . cases about potential damages of unexpected actuations, for instance Does the EVSE stop the charge when the vehicle battery is full (the failure probability might be low but the effect in case of failure very important) How do DC fast charging EVSEs respond to power outages? The high cost of DC EVSEs makes important the analysis. . DC testing needs more time and deep testing, since different failures can happen. For instance, fast high amperage variations can disturb the PLC communication leading to an unexpected stop of the charging process.
D1.3 57-59 EU Project no. 608934
Siwanand and INESC: what do DSOs do in the event of congestion or emergency situations? o Difficult to find consensus in DSOs, but we could test some UCs
Coffee break
Research works and contribution to projects in the electro mobility related to interoperability Sébastien Grolleau (EIGSI La Rochelle) Capabilities of EIGSI around EV testing, even not so close to Interoperability o The objective is to feel potential possibilities for collaboration L3E: laboratory for electrical testing and experimentation o Battery testing (ageing), and capacity for State of Health estimation o Optimal charging for fleets o Developing of a fast charge station with minimal stress to the grid
Intercharge - A customer focused approach for international interoperable charging Thomas Daiber (Hubject) A market perspective INTERCHARGE: charge wherever you like From 4500 to 13000 EVSE in 2013 HUBJECT detects an interoperability problem o 70 different access media (cards…) o Accelerating circle around eMobility Vision: . 2 operators needed: EMSP and EVSE operator o HUBJECT . Roaming platform based on real time web services. . Roaming contract Standard price for using a CS is proposed For those not accepting the standard price: Marketplace to exchange offers, bilateral prices… . Visibility . Authentication and authorization can be performed through: smart phone (app or QR code scanning), RFID cards, and ISO/IEC15118. No white lists are used. . Next week they will present a pay-as-you-go model: interchange direct No contract with the EMSP. The EVSE operator offers products at the web site, you choose the service and pay (paypal, credit card…) o More than 300 cities in Germany o Connection with other companies as HUBJECT (VIRTA in Finland,…)
ISO/IEC15118: Disruptive technology – what is it? Nils Dulum (RWE Denmark) Norway (10k) Sweden (2k) Denmark (2k) EVs, because very different incentive policies CCS (Combo): growing worldwide EVSE and EV also growing But many different hardware and services Smart charging: ACEA members are expected to adopt the ISO/IEC 15118 by 2017
D1.3 58-59 EU Project no. 608934
Towards grid integration o 20 different protocols EVSE-EVSE backend o Intelligent infrastructure with 15118: load management according to the capacity of the grid, load management according to energy prices and V2G. o Daimler reference project in Stuttgart (for fleet): charge@work
Discussion, decisions and further steps together Moderator: Eduardo Zabala (Tecnalia) Possibilities for collaboration o Now we know each other and are in close contact, the precise ways to collaborate, according to each one’s strategy and capabilities, will be fixed in the next weeks Test cases: o Unified approach from the different activities
End of the workshop
Cultural event: Guided tour at Roskilde Viking Ship Museum
Joint Dinner: Restaurant Byparken in Roskilde
D1.3 59-59 EU Project no. 608934