IGREENGRID Conference on Scalability and Replicability COTEVOS COncepts, capacities and methods for Testing EV systems and their interoperability within the Smartgrids José Antonio López TECNALIA josea.lopez@tecnalia.com Bilbao, 22 th October 2015 1
Why the need to test EV and EVSE grid integration Current predictions state the amount of cars with an electric plug in will reach ~70-85% in 2030. (This estimate includes HEV, PHEV and EV) The given penetration of EVs (2015) is very unlikely to cause car sourced grid errors but this can be expected to change as EVs roll out more and more. Current evaluations show that grid failures will first occur locally on a low voltage grid level with relatively low penetration rates. Resulting in the in-ability of EVs to charge ICE-Internal combustion engine, HEV Hybrid Electric vehicle (optional plug), REEV Range Extended electric vehicle, BEV Battery electric vehicle, FCEV Fuel cell electric vehicle Source: Evolution, Electric Vehicles in Europe: gearing up for a new phase? Amsterdam Roundtable Foundation and McKinsey & Company, April 2014 2
COTEVOS towards the unified testing infrastructure The COTEVOS Reference Architecture aims to be a framework for the testing of: Interoperability is a product or system, whose interfaces are completely understood, to work with other products or systems, present or future, without any restricted access or implementation Conformance is how well something, such as a product or system, meets a specified standard 3
COTEVOS towards the unified testing infrastructure Standards IEC 61851 ISO 15118 IEC 62196 Protocols OCPP OCHP OSCP Regulations TOR (Technisch Organisatorische Richtlinie) VDE AR-N 4105 Source: The German Standardisation Roadmap 4
COTEVOS towards the unified testing infrastructure Is standardization alone the solution? Is simple testing against standards sufficient? Is it enough to build test infrastructure for the existing standards? aims to develop infrastructure to test Conformance Interoperability Interoperability contains a future view 5
COTEVOS towards the unified testing infrastructure A very first step prior to defining a reference architecture is to look around what is already there 6
COTEVOS towards the unified testing infrastructure The COTEVOS Reference Architecture Describes all the actors and their interfaces of the current e- mobility system Provides a context for use- and test-case definition Strong alignment with existing initiatives Layered approach enables a future evolution of the architecture as the e-mobility system develops 7
COTEVOS towards the unified testing infrastructure COTEVOS Interface Reference Architecture 3 Layer Topology (some topological similarity to the SGAM) Layer 1 - Actor/Interface Layer Layer 2 - Service/Function Layer Layer 3 - Physical/Test Stand Layer 8
COTEVOS Reference Architecture Actor / Interface Layer 9
COTEVOS Reference Architecture Actor / Interface Layer The Actor / Interface Layer of the COTEVOS RA includes: Actor definition first definition in alignment with M/490 Interface definition Based on standard and nonstandard interfaces All functionalities are covered, regardless of the actor which implements them. 10
COTEVOS Reference Architecture Service / Function Layer Clearing house Clearinghouse Service EMSP Other Services (e.g. Navigation) EVSE Operator Procurement Service Energy Supplier Energy Retailer Service Contract & Billing Service EV Flexibility Aggregation Service Flexibility Operator Commercial Aggregation Service Authentication & Authorisation Service Charge Allocation Service EV User Identification Service Charge Management Service EVSE Operational Management Service Grid Management Service DSO User Preference Service Charge Execution Service EVSE EVSE Management Service Metering Operator Metering Service EV EV Battery Service OEM EV Diagnostics & Maintenance LEGEND Service Actor 11
COTEVOS Reference Architecture Service / Function Layer The Service / Function Layer of the COTEVOS RA includes: Based on the idea that functions and actors are not always directly coupled. Use-case depended coupling Allows a separation of concerns within the emobility system resembles of the functional layer of SGAM 12
COTEVOS Physical / Test Layer Different Implementations of the Reference Architecture TNO s EV- IOP-Lab- In-A-Suitcase EVSE as DUT Connected to grid EV simulator 13
COTEVOS Reference Architecture Message bus GUI EVSP Sim. Energy retailer sim OEM sim EVuser sim DSO sim. EVSE O sim. CH sim... EVSP Energy retailer OEM EV user DSO EVSEO CH Logging Visualis -ation Scenario Editor Emulated Router Real World EMS EV Charger / Inverter EVSE Grid Electrical/Physical 14
From Use Cases to Test Cases Round robin tests will be used for inter-laboratory comparison: first basic tests have been already performed Define test suites (like the WGI BAIOP) that cover a use case The test suite will consist of different test cases (steps) that need to conform to a specific standard e.g. EV requests a charging schedule to EVSE (e.g. conform IEC15118) EVSE operator sends the proposed charge profile to EVSE (e.g. conform IEC15118) 15
Test Cases aggrupation 28 test cases have been identified and they have been sorted into 6+1 groups +7 for wireless charging 16
Test Case examples 17
s testing capabilities Part II s implementation 18
Capabilities covered by Message bus GUI EVSP Sim. Energy retailer sim OEM sim EVuser sim DSO sim. EVSE O sim. CH sim... EVSP Energy retailer OEM EV user DSO EVSEO CH Logging Visualis -ation Scenario Editor Emulated Router Real World EMS EV Charger / Inverter EVSE Grid Electrical/Physical 19
EV-EVSE testing platform illustration 20
Testing EVSE charge 1/3 Message bus OCHP OCHP OCHP OCPP EVSP Sim. Lab2 CH sim EVSE O sim. Lab3 - OCPP - ISO 15118 authorization messages* Simulated Router EV 61851 Charger / Inverter IEC 61851 ISO 15118 EMS EVSE DUT Grid Electrical/Physical * Comm. not defined in the standard (simulated process using CAs) 21
EV - Hardware 2/3 + Arduino CP DSIEC2f-EV32S-NC INSYS PowerLine GP PP Switch EKI 2525 Xanbus gateway Link Pro Charger/Inverter XW4024-230-50 Industrial PC ARK-2120L 2 x Classic FF 12 080 1 22
EV - Software 3/3 IEC 61851 Charger/inverter (and related tools) software developed State machine developed board + Arduino software. Interface finished System integration + testing platform ISO/IEC 15118 Implemented: SDP, TCP ISO 15118 A1 and A2 Use cases State machine triggers and events EXI XML and bindings with programming language X509 certificates DHCP support System integration + testing platform Pending: TLS Workarounds: SLAC (part 3) not implemented. NMK must be manually assigned 23
Testing EV charge 1/3 Message bus OCHP OCHP OCHP OCPP EVSP Sim. Lab2 CH sim EVSE O sim. Lab3 CA Real World - OCPP - ISO 15118 authorization messages* Simulated Router EV 61851 DUT IEC 61851 EMS EV 15118 DUT ISO 15118 EVSE Grid Electrical/Physical * Comm. not defined in the standard (simulated process using CAs) 24
EVSE - Hardware 2/3 + Arduino INSYS PowerLine GP (with SLAC) CP (pure) CP (with HLC) PP DSIEC-M-EV32S Schneider LC1D Switch EKI 2528 Industrial PC Xtrem n7000 Circutor CVM Mini To Internet Router To power grid 25
EVSE - Software 3/3 IEC 61851 State machine developed board + Arduino software. Interface finished System integration + testing platform ISO/IEC 15118 Implemented: SDP, TCP State machine triggers and events EXI XML and bindings with programming language X509 certificates DHCP server ISO 15118 A1 and A2 Use cases System integration + testing platform Access to Internet (through the s router) Pending: TLS Some messages (part 2) of the state machine OCPP integration. Some interesting operations 26
OCPP compliancy Use of SoapUI internal API to perform predefined OCPP (v1.2, v1.5 and v2.0) tests Conformance testing for For the EVSE Operator (Central System in OCPP) For the EVSE Not defined the extent of the application Proposed tests: SOAP messages testing (changing SOAP versions 1.2, 2.0) Namespace changes Headers Communication tampering and stress testing Test sequences Graphical interface 27
A real test case Watch testing video Discussion Bilbao, 22 th October 2015