COTEVOS. Deliverable D5.2. Specification of the potentially convenient infrastructure for assessing interoperability. AIT June-2015 Version 2.

Transcription

1 COTEVOS Deliverable D5.2 Specification of the potentially convenient infrastructure for assessing interoperability AIT June-2015 Version 2.0 Project Full Title: COncepts, Capacities and Methods for Testing EV systems and their interoperability within the Smart grid FP7-SMARTCITIES-2013, ENERGY Grant agreement no Collaborative Project Deliverable no EU Project no

2 Document information Author(s) F. Lehfuß, M. Nöhrer AIT S. Martinenas DTU F. Belloni RSE J.A. Lopez Montero Tecnalia R. Koffrie, E. Werkman TNO P. Kelm., B. Olek, M.Wierzbowski TUL E. Karfopoulos NTUA A. Roscoe USTRATH Company WP no. and title WP leader Task no. and title Task leader WP5: New and unified test facilities IWES Dissemination level PU: Public 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) X For information Draft Final Version Approved Status X Revisions Version Date Author Comments F. Lehfuß (AIT) Initial version with Table of Content All Initial inputs from all partners All Completion of V1.0 for internal revision TUL, AIT Implementation of internal revision results TECNALIA Revision for final version Deliverable no EU Project no

3 Executive Summary Based upon the common reference architecture that was developed within WP3 multiple partner implementations are documented within this deliverable. These partner implementations represent the most relevant parts of the interface reference architecture. With each implementation being different to the others, one major achievement was to maintain a common approach to interoperability testing. Within this deliverable and the therein documented implementations, this common approach can be identified clearly. It defines the specification of the convenient way for assessing interoperability and conformance testing. The following two figures, in the later document Figure 4 and Figure 51, clearly demonstrate the common approach of the COTEVOS project based upon the physical/laboratory layer of the COTEVOS reference architecture developed within WP3. The top figure depicts the physical layer of the common reference model, whereas the bottom figure additionally shows how many partners have implemented respective parts of the architecture as explained in detail within the document at hand. This figure also clearly states the current testing capabilities of the COTEVOS consortium utilizing a depiction of the 3 rd layer of the COTEVOS common reference architecture. Deliverable no EU Project no

4 Table of contents Document information... 2 Executive Summary... 3 Table of contents... 4 List of figures... 5 List of tables... 7 Abbreviations and Acronyms Introduction Scope of the document Structure of the document The COTEVOS Reference Architecture Actor/Interface Layer Service/Function Layer Laboratory/Physical Layer COTEVOS Partners Infrastructure Implementation AIT EV Test System Implementation Reference Architecture Mapping Scope of executable Tests DTU Implementation Reference Architecture Mapping Scope of Executable Tests RSE Implementation Scope of test scenarios and executable tests TECNALIA Implemented protocols and functionality Actor emulators implementation Developed software and scope of executable tests TNO Requirements Architecture and design Envisioned supported test cases within WP Current status TUL EV Test System Implementation Reference Architecture Mapping Scope of executable Tests COTEVOS 3 rd parties NTUA U.Strath Summary References Deliverable no EU Project no

5 List of figures FIGURE 1: COTEVOS REFERENCE ARCHITECTURE, LAYER 1 ACTORS/INTERFACES FIGURE 2: COTEVOS SERVICE LAYER DEPICTION FIGURE 3: COTEVOS SERVICE LAYER, PROVIDING A MAPPING EXAMPLE ON THE ACTOR LAYER.. 14 FIGURE 4: LABORATORY/PHYSICAL LAYER FIGURE 5: TEST SCENARIO EXECUTION WITH SIMULATED/REAL-WORLD COMPONENTS FIGURE 6: STRUCTURE OF THE AIT EV TEST SYSTEM FIGURE 7: CONCEPT OF THE EV EMULATOR FIGURE 8: CONTROLLED EVSE OF THE TEST SYSTEM (IN THE FOREGROUND) FIGURE 9: CONCEPT OF THE EVSE EMULATOR FIGURE 10: SCREENSHOT OF THE MEASUREMENT SYSTEM FIGURE 11: SCREENSHOT OF THE EVSE CONTROL IN THE SCADA SYSTEM FIGURE 12: SCREENSHOT OF THE AUTOMATIC TEST EXECUTION CLIENT FIGURE 13: AIT EV TEST SYSTEM MAPPED INTO THE COTEVOS REFERENCE ARCHITECTURE FIGURE 14: NEVIC IEC61851 EMULATORS CONNECTED FIGURE 15: IEC15118 EMULATORS CONNECTED FIGURE 16: IEC15118 TEST SETUP EXAMPLE FOR EV TESTING WITH EVSE EMULATOR FIGURE 17: EV BACKEND CONNECTION DIAGRAM FIGURE 18: REFERENCE INFRASTRUCTURE AREA COVERED BY DTU TEST FACILITIES FIGURE 19: RSE LAB ARCHITECTURE FIGURE 20: HARMONIZED ELECTRICITY MARKET ROLE MODEL (HEM-RM) SOURCE: [12] FIGURE 21: RSE EVSE AND CUSTOM METERING SYSTEM FIGURE 22: IMPLEMENTATION OF THE OCPP SERVER FOR EVSEO EVSE TESTS FIGURE 23: IEC61851 AND IEC15118 COMPLIANT EV FIGURE 24: FUNCTIONAL ARCHITECTURE MODEL RELATED TO GRID/CUSTOMER INTERFACE FIGURE 25: TECNALIA S INFRASTRUCTURE MAPPED TO THE REFERENCE ARCHITECTURE FIGURE 26: TECNALIA S HARDWARE FOR EV FIGURE 27: TECNALIA S HARDWARE FOR EVSE FIGURE 28: EV SEQUENCE DIAGRAM ACCORDING TO IEC FIGURE 29: COMMUNICATION SETUP FOR EV ACCORDING TO ISO/IEC FIGURE 30: EVSE SEQUENCE DIAGRAM ACCORDING TO IEC FIGURE 31: TNO S ENVISIONED INTEROPERABILITY LAB IN A SUITCASE FIGURE 32: TNO S WP5 TEST ENVIRONMENT RELATED WITH THE COTEVOS REFERENCE TEST ARCHITECTURE FIGURE 33: SERVICES AND INTERCONNECTIONS SUPPORTED BY TNO S SMART GRID SYSTEM SIMULATION TOOL FIGURE 34: GENERAL CONCEPT OF SMART GRID CONTROL STRUCTURE FIGURE 35: LAYOUT OF COMMUNICATION LINKS BETWEEN ENTITIES ACCORDING TO A GENERAL CONCEPT PRESENTED IN FIGURE Deliverable no EU Project no

6 FIGURE 36: V2G LABORATORY ARCHITECTURE DEVELOPED BY TUL FIGURE 37: LOGICAL NODES OVERVIEW OF AC SUPPLY EQUIPMENT AND THE EV FIGURE 38: ABB TERRA 52 CHARRING STATION FIGURE 39: COTEVOS REFERENCE ARCHITECTURE FIGURE 40: NTUA S INFRASTRUCTURE MAPPED TO THE REFERENCE ARCHITECTURE FIGURE 41: NTUA S EV COMPONENT FIGURE 42: NTUA S EVSE COMPONENT FIGURE 43: ETREL S EVSE FIGURE 44: NTUA S MANAGEMENT SYSTEM AND USER INTERFACE FIGURE 45: NTUA S REAL TIME SIMULATOR FIGURE 46: EVOLT EV-PM3 3G CHARGER FIGURE 47: IEC61851 EVSE TESTER [ 77 FIGURE 48: ISO BENCHTOP TEST RIG [DESIGN BY DTU] FIGURE 49: BEAGLEBONE BLACK MICROCONTROLLER SECC COTEVOS HW PLATFORM [RECOMMENDED BY DTU] FIGURE 50: INSYS POWERLINE GP [RECOMMENDED BY DTU] FIGURE 51: COLOR CODED LAYER 3 OF THE COMMON REFERENCE MODEL BY THE AMOUNT OF IMPLEMENTATIONS OF ACTORS IN THE COTEVOS PARTNER LABORATORIES Deliverable no EU Project no

7 List of tables TABLE 1: ACRONYMS... 8 TABLE 2: CONSIDERED ACTORS AND THEIR IMPLEMENTATION IN RSE LAB ARCHITECTURE TABLE 3: TESTS SUPPORTED BY RSE LABORATORY IMPLEMENTATION Deliverable no EU Project no

8 Abbreviations and Acronyms Table 1: Acronyms API CA CP DHCP DuT EIM EMSP EV EVCC EVSE Application Program Interface Certificate Authority Control Pilot Dynamic Host Configuration Protocol Device under Test External Identification Means ElectroMobility Service Provider Electric Vehicle Electric Vehicle Communication Controller Electric Vehicle Supply Equipment EVSEO Electric Vehicle Supply Equipment Operator 1 EXI HLC IP Efficient XML Interchange High Level Communication Internet Protocol (IPv4) IPv6 Internet Protocol (version 6) NMK OCA OCHP Network Membership Key Open Charge Alliance Open Clearing House Protocol 1 COTEVOS has agreed to use the concept and acronym of CSO (Charging Station Operator). However, EVSEO is a common term outside the project and up to now in COTEVOS, and it is still used in this document. Deliverable no EU Project no

9 1. Introduction 1.1. Scope of the document This Deliverable gives a specification of potentially convenient infrastructure for accessing interoperability. Interoperability assessing is no easy task that can be executed in a plug and play manner. The work of the COTEVOS project until now has clearly shown that there are not only a lot of standards and activities (reported within the D2.1) that need to be taken into account but also the current and expected design of the e-mobility area, services, functions, players, actors. The existing set of standards provides a very solid fundamental basis for those areas that are well known and have a clear perspective in the near future. Those areas are mainly concentrated around the connection of the EV to the grid. Where the future view is very opaque is the connection of e-mobility (and its cloud or environment) to the smart grid. Multiple possible future actors as e.g. clearing houses can be found that do not exist at the moment and their specific attributes are yet unknown or only vaguely known. As a result of this the flexibility of an implemented test infrastructure is a key requirement. This difficult environment, being new and potentially growing in addition, does not enable the generation or definition of a single and unique infrastructure for interoperability assessment. The approach chosen by the COTEVOS project, reported within this deliverable, is not to define a single solution, but to provide multiple solutions that in total reflect a common approach to a unified testing infrastructure. This common approach was started with the definition of a common reference architecture for interoperability testing and further rolled out by multiple different infrastructure implementations, that all represent a subset of the common reference architecture. These implementations as well as the scheduled goals and capabilities are reported within this document and thereby represent multiple convenient laboratory infrastructures for assessing interoperability and conformance Structure of the document The document is structured in four main sections with the first section being the introduction. The second section of the document gives a compendious description to the COTEVOS common reference architecture which was the basis for all the laboratory implementations that are described in the section thereafter. This third section describes the convenient laboratory infrastructures as implemented by the partners of COTEVOS as well as third parties. The final section is the summary and the conclusion. Deliverable no EU Project no

10 2. The COTEVOS Reference Architecture The COTEVOS Reference Architecture was strongly inspired by two well-known state-of-the art models in the e-mobility and smart grid environment; The CEN/CENELEC/ETSI focus group model [1] and the Smart Grid Architectural Model (SGAM) [2]. COTEVOS builds further upon the work of M/490, including SGAM, the methodology and interoperability workgroups. A part of the validation of the interoperability methodology was provided by COTEVOS mainly within WP2 activities. The Reference Architecture extensively uses the layered model provided by the SGAM, the zones and domains are of less use for e-mobility aspects, since they focus mainly on managing the grid itself, which is taken as given within COTEVOS. Furthermore, SGAM provides a generic smart grid model that is applicable for Smart Grids in Europe, whereas COTEVOS requires a specific model instance for the e-mobility system. Despite their quality for their field of application, neither of these models fulfils the requirements that are given to a common reference architecture for interoperability testing of an electric vehicle charging infrastructure. They do not provide a common and unambiguous context for interoperability testing in the required range, as well as the current and future e-mobility system in Europe is not fully captured. The current view of the future e-mobility system can partly be mapped into the SGAM model, mainly by the separation of the DER Layer into multiple domains that address electric mobility needs and issues. The CEN/CENELEC model gives a view of the interfaces involved but lacks a clearer description of these interfaces, as well as the ability to map services and functions onto the model. Another disadvantage is that neither of models presents a description of responsibilities for each actor, which results in a lack of stabilization of the interfaces. The reference architecture discussed in this contribution was strongly inspired by both the CEN/CENELEC interface and the SGAM model and takes their approaches one step further into an architecture that can fulfil the requirements given by the future electric mobility environment. Furthermore, current real world implementations and developments have been taken into account. Testing pan-european interoperability is a very sophisticated task. Roaming issues, national guidelines and different regulations for each European country are just a few of many challenges that will be encountered. The simple demand of the EV User, to be able to travel throughout Europe with its electric vehicle, raises requirements that are by far not fulfilled today. Not only the need of having a network of charging spots available, but also more basic tasks such as charging in different low voltage grids need to be fulfilled. The e-mobility system is built-up from all kinds of subsystems (i.e. system actors) and parties (i.e. human actors) that are (presumed to be) present in the market. To create an interoperable system is of utmost importance that all participants are able to talk together using the same vocabulary. For example when talking about an EMSP it should be clear what it is and what not. The basic reference architecture utilizes this common set of vocabulary as defined in WP1 of the COTEVOS project and all parties within the e-mobility system. The requirements for the basic reference architecture are as follows: 1. Provide a common and unambiguous context for COTEVOS in the form of a basic reference architecture. All COTEVOS partners agreed to use it when specifying use cases and test cases. 2. Reflect the current and future e-mobility system in Europe. The basic reference architecture should not only describe the future system but also fit the current real world situation. Deliverable no EU Project no

11 3. Describe the responsibilities of each actor in the system. When the responsibilities of all the actors are clear the interfaces between the actors will be stable, creating a future proof architecture and e-mobility system. The requirements that are raised to the COTEVOS reference architecture are located in three different domains, the actor/interface domain, the service/function domain and the physical/electrical domain. The COTEVOS reference architecture is based on these domains using a 3-Layer approach. This multidimensional approach has strong similarities to the SGAM model, but clearly defines not to be an e-mobility clone of the SGAM model as the three layers are focusing the testing purpose. The first layer in COTEVOS identifies the different (business/legal) actors and all the involved (visible) physical components and some required communication protocols. The second layer adds services and information being exchanged, and some additional communication requirements. The third layer makes it possible to map these services in different configurations on test labs and systems Actor/Interface Layer Analysing the different initiatives, such as M/468 Smart Charging [3], FP7 Green emotion project, emi3, SGAM, PlanGridEV [4] and the current European electricity market [5], the actors have been identified along with their functionalities. In many cases both actors and their functionalities are similar in all initiatives (e.g. the EV, EV user and the EVSE). However, there are other actors (e.g. the EMSP) whose functionalities differ among the initiatives. Moreover, depending on the country regulatory frameworks, it could happen that some responsibility should be dealt by an actor whose functions are not defined for this actor. As a result, the COTEVOS reference architecture has been specially designed to solve these contingencies. Actor-based Approach for the Reference Architecture The actor-based architecture covers all functionalities regardless the actor which implements them. In other words, this architecture pays more attention to the actor who receives the information than to all the involved actors within the complete chain from the data generation to the final consumption. With this concept in mind, the defined interfaces among actors are depicted in the Figure 1, which gathers the interfaces in the e-mobility system. The interaction between actors (or more accurate, roles) are described by A to M interfaces (COTEVOS Interface IDs), where the final data consumer is connected to the producer. The secondary actors, OEM and energy markets are out of the scope of the COTEVOS project, as far as they use their own proprietary and energy regulated data models and interfaces. Standard and nonstandard Interfaces In some cases, the interfaces depicted are supported by one (or even more) communication system, standard or widely used protocol. For example, IEC [7], ISO [8] standards or other proprietary alliances such as CHAdeMO [9] can be used for the EV-EVSE interface (Figure 1, interface A). In other cases there are no standards, but widely adopted communication protocols and semantics are available. This is the case for OCPP [10] (Figure 1, interface E), which has already been adopted by many existing EVSE Operators. Nevertheless, the existence of a standard does not mean that it will be adopted by the industry. For example OCHP [11] (Figure 1, interfaces K and L) is an existing open protocol for clearing house and EMSP interoperability, but has not (yet) been adopted by any Clearing House, EVSE Operator or EMSP. Deliverable no EU Project no

12 Although interaction as well as information exchange among the e-mobility actors are necessary, in some cases there is not an adopted standard and likely never will be. A representative example is the way EV users access the services offered by the EMSP. Every EMSP will have its own web page or smartphone application available for its users. Moreover, the services that two different EMSP can offer to their customers can also be completely different. Figure 1: COTEVOS Reference Architecture, Layer 1 Actors/Interfaces 2.2. Service/Function Layer The architecture of the e-mobility system is constrained by regulations, national guidelines and legacy systems that are already in place. A larger part of the e-mobility system is built up from the ground (e.g. by startups), instead of a system wide top-down approach. That makes it difficult to create interoperability tests that are valid for each situation. As for example a possible evolution of an EVSE Operator: It might start by selling and managing EVSEs, and gradually extend its business model to provide more sophisticated e-mobility services towards customers (e.g. reservation of poles, green energy charging, smart charging). According to the COTEVOS reference architecture this EVSE Operator gradually transforms into an EVSE Operator and an EMSP, without conforming to the interfaces specified for interaction between these two actors. A study of the use cases currently available within the COTEVOS project, further information can be found in Deliverable 1.1, showed that there is no common understanding of the (business) services in the e-mobility system and a mapping of these services to the actors. Without this, no stable (i.e. future proof, interoperable) interface architecture could be developed, as different stakeholders have a different view on the responsibilities of the actors. To make sure that all stakeholders have the same understanding of the e-mobility system, the reference architecture needs to have more details regarding the responsibilities of each of the actors. Within COTEVOS this is done by detailing which Deliverable no EU Project no

13 (business) services each actor provides in a service layer. Figure 2: COTEVOS Service Layer depiction This service layer allows for a separation of concerns within the e-mobility system and shows which main services, functions and interfaces are required when dealing with the use cases in COTEVOS. The service layer resembles the functional layer of SGAM, since SGAM s function layer also describes functions and services including their relationships following business needs [2]. The service definitions are based on the use cases available within COTEVOS and agreed upon by all the project partners. In Figure 2 these services are visually represented by rounded boxes, and services required by other services are connected by lines. Each service provides specific functions and consequently describes the responsibilities of that service. These functions are not detailed in the figure due to space constraints, for that refer to Deliverable 3.2. The proposed view allows the use cases to be defined in terms of services instead of actors or physical power infrastructure, making a functional specification independent from its deployment(s). This means that the interfaces between the services can be defined (and will be stable), without knowing the actual mapping of services to actors in the (emobility) market. Furthermore, the figure helps identify gaps with respect to interfaces that need to be standardized between services and their actors. Figure 3 shows an example mapping of the services back to the actors. This means that for their usage we know the responsibilities of each of the actors. This mapping may be different for another EU member state, while the services and their interfaces stay the same. This approach is similar to the one taken to develop the EU Smart Grid Conceptual Model within the Methodology report from the M/490 mandate by CEN/CENELEC /ETSI [2]. That conceptual model is based on the Harmonized Energy Market Role Model [5], in which all actors in the EU electricity market are harmonized by using roles. Deliverable no EU Project no

14 Figure 3: COTEVOS Service Layer, providing a mapping example on the actor layer 2.3. Laboratory/Physical Layer The layers in the previous sections describe the actors and services within the electric mobility system and can be used as a common scheme. The additional Laboratory/Physical Layer provides an architecture approach for conformance and interoperability testing within a laboratory environment. Therefore the approach for Black-Box-Testing is used, where the test operator has no knowledge about the internal structure and functionality of the device under test (DuT). Only the interactions of the DuT with its environment have to be known and therefore the test operator can only affect the interfaces of the DuT. The laboratory system, which is based on this architecture, must have the possibility to test every actor described in Section 2.1. For interoperability testing the interfaces of the DuT will be influenced by mock-up components which work as counterparts for the interfaces under test. Within this layer these components are either simulated or emulated components of the actors within the reference architecture. We have chosen for the possibility to simulate several system components since the e- mobility system and standards are still evolving, so often an up to date component is not available. In order to be capable of implementing a service orientated view as given in layer 2 of the COTEVOS reference architecture, several requirements need to be met. Mainly a modular design, a fast transformation of the system structure and the possibility for scaling up the testing operation meet these problems for such a laboratory reference architecture and support the test case development described before. Therefore, it should be possible to quickly change the configuration of the test system. The focus for the device under test can be either a single actor/component or service but it is also possible to extend the DuT to a composition of several actors. Deliverable no EU Project no

15 Figure 4: Laboratory/Physical Layer Figure 4 shows the laboratory reference architecture developed within COTEVOS project and documented in the Deliverable 3.2. Every actor of the e-mobility system is integrated as a simulated component. In addition one or more of these implemented components will be replaced by real-world actors like an EMSP or a clearing house. The communication between the actors is based on a Simulation Message Bus which works as a software based message router between the connected components and it allows the information transport within the whole system. The hardware integration will also be possible using a standardized communication structure provided by the Simulation Message Bus. Thereby a real-world EV or EVSE is connected to the laboratory test system. To complete the reference architecture, a graphical user interface for visualization, logging and control must be provided. This allows a test operator to control the tests by an integrated scenario editor and compare the test results with expected ones using visualization and logging tools. The Simulation Message Bus can be based on a TCP/IP based data exchange to provide the best flexibility with the web based actors (like the clearing house) of the e-mobility system. If necessary, the flexible and modular approach of the architecture allows the simple substitution of the communication media to different ones. From an overall view the reference architecture provides a co-simulation environment with hardware integration support, which isn t only restricted to the e-mobility system. The substitution possibilities are depicted in Figure 5. In the user interface and control software (e.g. the scenario editor) all components are abstracted implemented as proxies. Each proxy acts as a common interface for the user interface and can either represent a simulated/emulated component or a real-world based actor (e.g., a clearing house). Also an EV or EVSE as hardware based components can be controlled or represented with such proxies in the scenario editor. The information exchange between the proxies and the corresponding devices will use the Simulation Message Bus as described before. Every hardware component will have its own connector, which works as a protocol converter to the common bus system infrastructure. This configuration allows a fast replacement of simulated components by hardware based ones. It also allows a fast introduction of new communication protocols or components into the test laboratory environment. Deliverable no EU Project no

16 Figure 5: Test scenario execution with simulated/real-world components Deliverable no EU Project no

17 3. COTEVOS Partners Infrastructure Implementation In this section of the deliverable the implementations of the convenient infrastructure for interoperability testing as executed by multiple partners out of COTEVOS are documented. The subsection of each partner contents the following three main parts: A documentation of the implemented COTEVOS test infrastructure A description of which part(s) of the reference architecture developed in WP3 is covered A short discussion on what type of tests are the main focus of the implementation The laboratories have implemented the described Reference Architecture in different ways. As it can be seen there are overlaps, which it is an interesting point when performing Round Robin tests, as far as real DuTs will also have different protocols and standards implementations. Moreover, according to the implemented actors and services by the laboratories, two or more of them can collaborate to provide a wider range of standards to be tested within the same laboratory. This way, a DuT can be tested not only by the lab implementation which receives the device, but also by others which offer alternative protocol compliance testing. The information about the facilities that have been deployed within COTEVOS is detailed right after, listed in alphabetical order of the corresponding partners. Deliverable no EU Project no

18 3.1. AIT This section gives an overview of the laboratory implementation at AIT. The provided test system focuses on the grid interactions of the EV/EVSE charging infrastructure. After describing the implementation details with its built-in components and the different possible operation modes the mapping of the implementation into the COTEVOS reference architecture is shown. Finally, the possible test cases for EV charging and the focus of the AIT implementation are described in details EV Test System Implementation The implementation of the test system is concentrated to the electric domain and all components of the EV charging infrastructure directly depending to it. Its purpose is to control all relevant parameters of the charging process to enable the test capabilities or the research of smart charging algorithms. The structure of the system is shown in Figure 6, where three sections can be identified. Each section, the electric grid, the EVSE and the EV, is provided as real-world hardware components as also in a simulation environment. Therefore, the test system implementation can be used for single component evaluation and for compound and large-scale interaction tests using the simulation part. This structure allows the simulation of the EV integration into the electric power system using a simple hardware-inthe-loop simulation and enables the analysis of smart charging algorithms with all involved actors. Figure 6: Structure of the AIT EV test system In the first development stage the test system is constructed for a maximum electric power of 25 kva. The today s common used communication protocol IEC is implemented within the test system for the low-level communication between the electric vehicle and the EVSE. Deliverable no EU Project no

19 Components of the EV Test System Each domain of the test system contains different components, as simulated, emulated and real-world ones. This allows the maximum flexibility testing and researching the EV charging infrastructure. Each domain with its different components is described in details in this section. EV As first step of the test stand configuration a real-world electric vehicle is used as a device under test. This configuration allows the interoperability and the electric conformance testing of the EV. As improvement of the EV test system the emulation of the electric vehicle is necessary to complete the flexibility of the system. Figure 7 shows the structure of the communication unit of the emulated EV. The communication will be based on the IEC low-level protocol as also on the high-level protocol ISO The signals of the low-level protocol are measured by the emulator. This allows the detection of small deviations and provides the most flexibility for testing the low-level protocol. Next to the communication of the EV with its infrastructure the emulator will implement the possibility to control the charging current. Therefore, the control of the electric characteristics is possible and a virtual EV battery system can be emulated. This emulator can be used as mock-up interface for testing EVSEs. For the common European charging infrastructure with its AC charging, this component isn t very important, but for future application with DC charging infrastructure this component will be a main part for the testing purpose. Figure 7: Concept of the EV emulator EVSE At the current development state a conventional charging station (EVSE) with a built in Phoenix Deliverable no EU Project no

20 Controller is used as shown in Figure 8. This controller enables the communication between the electric vehicle and the EVSE using the IEC communication in mode 3 (AC-charging). The whole EVSE is under full control by the SCADA system. Therefore, all parameters of the low-level protocol can be controlled by the test system. Possible functions are enabling and disabling the charging process or adjusting the maximum allowed charging current. Figure 8: Controlled EVSE of the test system (in the foreground) For extensive research and test purposes this current EVSE will be replaced by a more smart one, which concept is depicted in Figure 9. Next to the low level communication this system allows the high-level communication between the electric vehicle and the EVSE using the standardized ISO protocol. The usage of the higher communication enables the possibility for researching the impact of smart charging algorithm to the electric power system. The charging station will also support the Open Charge Point Protocol for the communication with a management system. With this improved EVSE emulator it will be possible to cover the most available stations in Europe. Figure 9: Concept of the EVSE emulator Deliverable no EU Project no

21 Electric Power System and Electric Grid Emulation The system can be directly supplied by the electric distribution grid available in the laboratory. Therefore, it isn t possible to influence any characteristic of the electric supply. For enabling the full control and emulation of the charging infrastructure the grid connection is replaced by a 4-quadrantpower amplifier up to 25 kva maximum power. This enables the freedom to influence any electric characteristic of the supply and allows the emulation of different scenarios. Some of the possible test functions are listed: Voltage level control of each phase separately Changing the frequency of the supply Generating voltage drops Generating the outage of one phase Generating unbalanced grid conditions Generating jumps of one or more phases The signals for the three phases are generated by a signal processing unit (Grid Emulator), which generates analog low-level signals of the three phases, This signal are used to control the power amplifier. The grid emulator is controlled by the SCADA system using a Modbus TCP interface. The reference signals for the emulator can be generated by an electric power system simulation. This allows large scale integration tests with a simulated distribution grid. Measurement System Figure 10: Screenshot of the measurement system The electric power lines of the test system are connected to a measurement system, which is shown in Figure 10. This system records all electric parameters, like voltages and currents of the three Deliverable no EU Project no

22 phases or different power parameters, during the running charging process and allows an accurate analysis latterly. The system also records the display of the electric vehicle to check the state of charge and the remaining time of the charging process, which is provided by the EV to the user. The trust ability and correctness of these values may be important to the EV users and can increase their acceptance. SCADA and Test System The main component for the work with the EV/EVSE test system is a Supervisory Control and Data Acquisition (SCADA) system. The open source based ScadaBr system controls all connected components and shows their states in a clear way on a screen. In Figure 11 the control view of the connected charging station is depicted as an example. This control screen allows the adjustment of the charging current and it shows the state and possible errors of the charging controller. Figure 11: Screenshot of the EVSE control in the SCADA system Simulation Components The second part of the EV test system is a simulation environment. The SCADA system can transmit measured data to the simulation components. It is also possible to set calculation values from the simulation system to the hardware connected devices. The main component of the simulation system is the Simulation Message Bus. It works as a software based message router and synchronization tool and connects different simulators with the test system. In the most cases the electric grid is simulated within the power system simulator. In this simulator the real-world EVSE is abstracted as a connected load. The SCADA system sends the measured power values to this corresponding load. The grid simulator calculates the voltage at the connection point and sends it back to the test system. The power amplifier of the grid emulator will used this calculated value to set the voltage of the real-world charging station. Deliverable no EU Project no

23 The flexibility of the Simulation Message Bus allows different simulation tools to be connected next to the grid simulation. This enables the usage of all cloud-based actors, like the management systems of the EVSE operator or E-Mobility service provider. The configuration of different simulators with management function allows the research of smart charging algorithm with hardware integration Operation Modes With the explained implementation different operations and tests can be executed and will be explained in details. The flexibility of the test system allows a wide operation spectrum from the simulation up to conformance testing of single components. Electric Power Measurements and Charge Cycle Analysis The first application for the EV test stand is the acquisition and recording of electric characteristics during the charging process of an electric vehicle. These measured records can be used to improve future models for EV simulations. Conformance Testing The test stand can also be used for a test execution scenario, which has already been shortly described in the section before. With scripted test cases, like unit tests in the software development, the execution will be automated and the test results are generated immediately as passed or failed. Figure 12 shows the scripting and execution engine for the automatic conformance testing. Figure 12: Screenshot of the automatic test execution client Deliverable no EU Project no

24 Hardware-In-the-Loop-Simulation With the integration of simulation components within the test stand a simple hardware-in-the-loop simulation is possible as already described before. With the simulation components smart charging algorithms can be easily tested using the interaction of real-world EVSEs and EVs Reference Architecture Mapping AIT s EV test system implementation concentrates to the main components of the charging infrastructure that correspond to the electric power flow. Therefore the EV, EVSE and the distribution grid are implemented within the test system. The distribution grid part already contains all three components (simulated, emulated and real device). The EVSE is also under full control of the test system, only the electric vehicle is currently as real-world device available. For the first test executions this component will be used as device under test. Figure 13 shows the mapping of the AIT implementation into the COTEVOS reference architecture. The already implemented components are shown in Grey. These components directly correspond to the electric domain and will exist in the end of the development process as simulated, emulated and real-world device. Management components, like the EVSE Operator or the EMSP, can easily be implemented in software/simulation using the Simulation Message Bus. This allows the most flexibility within the system and a fast adaption of the test system to future requirements and actors. Figure 13: AIT EV test system mapped into the COTEVOS reference architecture Deliverable no EU Project no

25 Scope of executable Tests The currently available development stage of the EV test system allows the analysis of the power flow from the electric power system to the electric vehicle. Therefore, multiple measurements are implemented to analyse the electric characteristics of an EV during its charging process. The communication between the vehicle and the EVSE is based on the IEC protocol. Therefore, the scope of the test cases is based on this low-level communication. This protocol already enables simple charging control. The structure of the test system enables a cross-domain analysis and test evaluation between the information exchange and the electric power flow. Further developments will implement the high-level protocol ISO for the test system. Also the Open Charge Point Protocol (OCPP) will be used to enable smart charging analysis for the EV test system. This will allow real time adaptive charging and scheduling of the charging process. The simulation components allow a large scale integration analysis of the EV within the electric power grid. Deliverable no EU Project no

26 3.2. DTU Implementation DTU already has an EV interoperability test center called NEVIC (Nordic Electric Vehicle Interoperability Center). NEVIC is located at DTU Electrical Engineering and is using the existing PowerLabDK infrastructure as a basis. NEVIC test facilities are aimed at testing existing e-mobility standards, such as IEC61851 and IEC NEVIC is focusing on the technical side of the interoperability, i.e. the ability for the operator to identify the EV to be charged, and the capability to charge the EV from the charging posts. In this way it is ensured that the communication between the EVs, the charging post and the operators back-end systems are compatible. NEVIC is currently conducting interoperability tests of EV s, cable cord sets and EVSE s. The NEVIC have custom charging posts and commercially available ones from main EV operators in the Danish market: eon, Clever and CleanCharge (RWE). The center also has access to the commercial EV models such as: Nissan Leaf, Peugeot ion, Renault Kangoo ZE, Renault Zoe, AC Propulsion ebox. Additionally, custom build EV's are also available providing deeper insight and ability to customize inner workings of the vehicles. NEVIC has developed emulators where the behavior of equipment can be tested to and beyond the limits of the standards. Figure 14: NEVIC IEC61851 emulators connected Deliverable no EU Project no

27 IEC61851 Emulator The set up for testing IEC61851 and IEC62196 standards and related issues, consists of three emulators (left to right in Figure 14): 1. EV emulator 2. Cable emulator 3. EVSE emulator EV Emulator EV Emulator implements a full IEC61851 control circuit in the EV. All the components in the circuit are controllable, such as resistors for S2 state switching on the CP line and correct cable value detection in PP line circuit. Additionally, ground fault and capacitance tests are implemented. Finally, the emulator has a power plug to connect the AC load, supporting real power flow testing. Therefore, it includes the power flow measurement equipment to test the correct power flow. Cable Emulator Cable emulator implements the variable cable ratings of the charging cable. Additionally, cable capacitance- and ground fault test can be performed. Finally, the emulator contains power lines to support real power flow testing. EVSE Emulator EVSE Emulator implements a fully functional charging spot with fully configurable PWM signal generation with variable peak to peak voltage, frequency and duty cycle. Additionally, ground fault and capacitance tests are implemented. Finally, the emulator has an AC power socket for a grid connection, supporting real power flow testing. Therefore, it contains power measurement equipment to test the correct power flow. Currently all the IEC61851 emulators are made for manual test execution. However, second generation of current setup is under active development. It is planned to combine the functionality of the emulators into one automated test box. This is done to improve the portability of the test setup. The setup is flexible and adaptable for new technology add-ons, such as extensions for IEC15118 testing. Deliverable no EU Project no

28 IEC15118 Emulators An IEC15118 testing add on is a full IEC15118 implementation of parts 1,2 and 3. It is using Power Line Communication (PLC) modems from INSYS and full IEC15118 software stack running on the embedded communication controller connected to the PLC modem. Figure 15: IEC15118 emulators connected The IEC15118 testing set up consists of two emulators: 1. EV emulator implementing EVCC 2. EVSE emulator implementing SECC IEC15118 EV emulator IEC15118 EV emulator first reads the PWM signal on the CP line from EVSE and if it corresponds to the duty cycle indicating digital communication it enables IEC The communication is established from EV to EVSE. The setup supports SLAC and TLS, together with full implementation of IEC and IEC IEC15118 EVSE emulator IEC15118 EVSE emulator first generates the 5% duty cycle PWM signal to indicate to the EV that digital communication according to IEC15118 is supported. The setup uses build in EVSE SLAC, implemented inside INSYS PLC modem. The communication is established from EVSE to the EV Both emulators have the following functions implemented: SLAC association support SDP client and server Deliverable no EU Project no

29 V2G XML messages TCP and UDP communication support TLS communication with certificates Low level functionality such as SLAC and SDP are implemented inspired by OpenPLC library from Qualcomm. The higher level communication such as V2G XML and EXI are based on OpenV2G project. The IEC15118 emulators can be tested together or against other emulators as shown in Figure 15. However, the primary purpose of the emulators is to allow for testing of real IEC15118 EV and EVSE as Device Under Test (DUT). Figure 16: IEC15118 test setup example for EV testing with EVSE emulator Figure 16 shows a sample test setup for testing a real EV with IEC15118 protocol support. In this scenario, the EV is the Device Under Test (DUT) that is connected with a standard charging cable to the EVSE emulator. Deliverable no EU Project no

30 EV Backend System The EV backend system is developed for interaction and management with the EV and EVSE. The system is performing the role of the EVSEO using custom protocols and OCPP. Figure 17: EV backend connection diagram As shown in Figure 17 DTU EV backend is communicating multiple entities. EV backend is receiving the information from the electric vehicle data logger. EV backend is also performing the role of EVSE Operator by communicating to the EVSE Communication Controller (SECC) using OCPP protocol. It is possible to extend the backend to communicate with EMSP, thus implementing full e-mobility infrastructure test setup. Finally, connected infrastructure is available in a form of a microgrid with adjustable grid conditions. Therefore, testing can easily be extended to V2G testing and to cover data exchange/interoperability hub testing between operators. Overall DTU test infrastructure for COTEVOS tests consists of the following parts: 1. Full IEC61851 test emulators 2. Full IEC15118 test emulators 3. Commercially available EVs and EVSEs 4. Flexible grid infrastructure for V2X services and Smart Charging 5. Information and data exchange network Deliverable no EU Project no

31 Reference Architecture Mapping The parts of the Reference Architecture developed in WP3, that are covered by DTU testing facilities are shown in Figure18. Figure 18: Reference infrastructure area covered by DTU test facilities DTU/NEVIC test facilities concentrate on the main physical components of the reference architecture. Therefore, fully functional EV, EVSE and configurable grid are implemented in the center. Most of the devices are available in the form of real/commercial product and custom built emulators. These devices are supplemented by control and simulation software. The test system is flexible and can be reconfigured to almost any test in the focus area. Deliverable no EU Project no

32 Scope of Executable Tests The focus of DTU testing facilities is on the tests that involve physical device under test such as EV or EVSE. These types of tests are prioritized as the focus of the NEVIC center and facilities connected to it are on EV integration into the electricity grid. Additionally, DTU focuses on extending the testing capabilities of the existing interoperability test facilities for EV-EVSE to perform development of Energy Management System and Smart Market, through existing infrastructure and cooperation with EV operators, Charging spot operators, and development of requirements for an interoperability hub. Currently the following tests can be conducted: 1. Full testing of IEC Testing of IEC15118 according to the IEC test specification 3. EVSEO to EVSE interaction tests 4. EV to Grid interaction tests, in a form of Normal Charging, Smart Charging and V2G grid service provision Deliverable no EU Project no

33 3.3. RSE Implementation A schematic view of the RSE Lab architecture for Interoperability Tests in Electro-mobility domain is reported in Figure 19. The dotted lines represent the information exchanges, not compliant to ICT standards, used to support the business process related to the considered use cases. The black solid lines represent the information exchanges compliant to specific ICT standards or specifications and that consequently are object of interoperability tests. The red solid lines represent energy exchanges from a Distribution Grid/Grid Simulator to the EVSE and from the EVSE to the EV. Figure 19: RSE Lab Architecture The main systems/actors considered in the Lab architecture are reported in Table 2. Table 2: Considered actors and their implementation in RSE Lab Architecture ACTOR EQUIPMENT and DESCRIPTION NOTES Distribution Grid/Grid Simulator Actual LV grid connection point or controlled AC voltage source (grid simulator) which serves as energy source during EV charging phases. The actual electric grid is a 50 Hz, three-phase Low Voltage grid with a short circuit power of 200 Deliverable no EU Project no

34 kva. The grid simulator is a controlled linear voltage generator with a total power of 30 kva. Since simulator output voltage, frequency and output impedance can be fully controlled, a sort of Virtual DSO can be implemented Electric Vehicle (EV) Actual EV that can be charged both in MODE 3 (AC, up to 7 kva) and in MODE 4 (DC, up to 50 kw). The EV is IEC15118 compliant and fully supports also IEC61851 for communications with EVSE; MODEL: BMW i3 with range extender EV Supply Equipment (EVSE) It is an EVSE fully compliant with IEC61851 standard on EV side and partially compliant with OCPP 1.5 on operator side. The EVSE can supply up to 63 A per phase in MODE 3 charging MODEL: SCAME LIBERA 63 A Metering system (Meter) It is based on a custom solution and can provide data to a Meter Operator for monitoring the charging process or for further processing EVSE Operator (EVSEO) Emulation of an EVSEO through custom developed OCPP server/client. EVSEO emulator can control the EVSE through an OCPP 1.5 interface, according to some requests coming from a EV Service Provider (EVSP) or other possible actors EV Service Provider (EVSP) Emulated actor that manages the charging process at business level considering the requests and information coming from an Energy Service Provider/User or from other generic grid side actors EV User The EV user can only authenticate to the EVSE through a proprietary RF ID-card system Proprietary RF IDcard system not compliant to any standard. Useful for verifying white lists. Energy Service Provider/User Generic grid side actor that provides or uses Energy Services as defined in Harmonized Electricity Market Role Model (Figure 20). In the EV context, this actor could have different roles, for example it could provide Energy supply services to the EV charging system or Flexibility Services to the grid (e.g. to Balance Deliverable no EU Project no

35 Responsible Party) Flexibility Market Reserve Allocator Merit Order List Responsible Markets Grid Capacity Market Capacity Coordinator Transmission Capacity Allocator Nomination Validator Energy Market Market Information Aggregator Market Operator facilitates and coordinates trade in trade via Operations Energy Services System Operations System Operator Control Area Operator Control Block Operator Coordination Center Operator Imbalance Settlement Responsible Reconciliation Responsible Metering Operations Meter Administrator Meter Operator Metering Point Administrator Metered Data Aggregator Metered Data Collector Metered Data Responsible Grid Operations Grid Operator Grid Access Provider facilitates and coordinates trade by Energy Trade Balance Supplier Block Energy Trader Reconciliation Accountable Grid Capacity Trade Capacity Trader Interconnection Trade Responsible Flexibility Trade / Balancing Responsibilities Balance Responsible Party Consumption Responsible Party Production Responsible Party Trade Responsible Party Scheduling Coordinator Resource Provider provides energy services to Grid Users Legend: Conceptual Domain Subdomain Role transports power from and to Production, storage and consumption Party Connected to the Grid Consumer Producer Figure 20: Harmonized Electricity Market Role Model (HEM-RM) Source: [12] Views of the implemented Lab architecture are shown in Figure 21, Figure 22 and Figure 23. Deliverable no EU Project no

36 Figure 21: RSE EVSE and custom metering system. Figure 22: Implementation of the OCPP server for EVSEO EVSE tests. Figure 23: IEC61851 and IEC15118 compliant EV. Deliverable no EU Project no

37 Scope of test scenarios and executable tests As it can be inferred by Figure 19 and Table 2, RSE Lab architecture can perform basic interoperability tests on standards concerning interfaces A and D of the COTEVOS basic Reference Architecture. More specifically, RSE Lab is equipped to perform interoperability test of the communication interface between EV and EVSE according to IEC61851 standard, and in particular the test reported in Table 3 can be performed. Table 3: Tests supported by RSE Laboratory Implementation TEST TEST DESCRIPTION STANDARD/PROTOCOL Charging cable plug-in Verify that the charging cable can be plugged into the EV Mechanical test Charging cable lock Verify that the EV is able to lock the charging cable once plugged in Mechanical test Verify that the EV status changes from B to C once the charging process starts. Initiation of charging Verification is performed by monitoring the process PWM signal on the CP wire of the charging Standard IEC61851 cable Control of the states Measure the PWM signal on the CP wire of the charging cable in order to recognize the Standard IEC61851 EV status during the charging process Control of the power Verify the relation between the duty cycle of Standard IEC61851 according to duty cycle Termination of charging process EVSE Monitoring EVSE Control Write configuration Write white list the PWM signal and the charging current Verify that charging can be stopped by EV user EVSE status monitoring: EVSE sends a <<StatusNotification.req>> request to the Central System, the Central System sends a <<StatusNotification.conf>> reply to the EVSE. Verify the actual status of the EVSE Change EVSE status: The Central System sends a <<ChangeAvailability.req>> request to the EVSE, in order to modify its status. EVSE sends a <<ChangeAvailability.conf>> confirmation to the Central System indicating success. Verify the actual status of the EVSE Change EVSE configuration parameters Write white list of users that can charge at the EVSE: The Central System sends a <<SendLocalList.req>> request to the EVSE, with a full update type. EVSE sends a <<SendLocalList.conf>> reply to the Central System indicating success. Connect EV to EVSE Identify user using keycard Verify charging has started Standard IEC61851 OCPP 1.5 OCPP 1.5 OCPP 1.5 Partially supported by RSe architecture OCPP 1.5 Read configuration Read EVSE configuration parameters: OCPP 1.5 Deliverable no EU Project no

38 Read parameters Read white list Diagnostics Stop/Interrupt charging Restart charging Reset/Restart EVSE The Central System sends a <<GetConfiguration.req>> request to the EVSE, with some chosen keys. EVSE sends a <<GetConfiguration.conf>> reply to the Central System, with values corresponding to the requested keys. Verify compliance between read configuration and actual EVSE configuration Read EVSE parameters: EVSE sends a <<MeterValues.req>> request to the Central System. The Central System sends a <<MeterValues.conf>> reply to the EVSE. Verify compliance between read parameters and actual EVSE parameters Read white list of enabled users: Perform test <<Write white list>> with a given list version number. The Central System sends a <<GetLocalListVersion.req>> request to the EVSE. EVSE sends a <<GetLocalListVersion.conf>> reply to the Central System, with the version number. Verify that the version number corresponds to the one sent before EVSE functionality diagnostic: The Central System sends a <<GetDiagnostics.req>> request to the EVSE EVSE sends a <<GetDiagnostics.conf>> reply to the Central System Verify actual EVSE functionality status Stop and restart the charging process by Central System: Start charging EV The Central System sends a <<RemoteStopTransaction.req>> request to the EVSE EVSE sends a <<RemoteStopTransaction.conf>> reply to the Central System indicating success Verify charging has stopped (TEST 1) The Central System sends a <<RemoteStartTransaction.req>> request to the EVSE EVSE sends a <<RemoteStartTransaction.conf>> reply to the Central System indicating success Verify charging has restarted (TEST 2) Reset/Restart EVSE: The Central System sends a <<Reset.req>> request to the EVSE, requesting a hard reset. EVSE sends a <<Reset.conf>> reply to the Central System indicating success. Verify EVSE actually restarts OCPP 1.5 OCPP 1.5 OCPP 1.5 OCPP 1.5 OCPP 1.5 Enable/Disable EVSE Enable/Disable EVSE: OCPP 1.5 Deliverable no EU Project no

39 The Central System sends a <<ChangeAvailability.req>> request to the EVSE, in order to modify its status to <<Inoperative>>. EVSE sends a <<ChangeAvailability.conf>> reply to the Central System indicating success Verify the actual status of the EVSE The Central System sends a <<ChangeAvailability.req>> request to the EVSE, in order to modify its status to <<Operative>>. EVSE sends a <<ChangeAvailability.conf>> reply to the Central System indicating success. Verify the actual status of the EVSE In a more general picture, RSE Lab architecture supported tests are framed within an electric system flexibility scenario, which involves the interface and the interactions between a high level grid actor, e.g. Aggregator 2 (Actor A of Figure 24), and the EV charging system. The Aggregator actor supplies a Flexibility Services to the grid by using the flexibility made available by the entire EV charging system (this function is assured by an EVSE-O or EMSP). The information exchange at this level is mostly related to market information, and it is implemented by means of the IEC standard, as an example. It should be noted that the Aggregator could manage in a similar way also the Flexibility offered by EVs in private and home domains. The interface between the Actor A and the Energy Management Gateway 4 reported in the functional architecture proposed by the IEC draft (Figure 24), is functionally equivalent to the interface between the Aggregator and EMSP in RSE Lab architecture. 2 An Aggregator is a legal entity that aggregates the load or generation of various demand and/or generation/production units. 3 Systems interface between customer energy management system and the power management system- Currently in a draft version 4 The EMG+CEM could manage an EV as a specific kind of Smart Appliance Deliverable no EU Project no

40 Figure 24: Functional Architecture Model related to grid/customer interface In this way the Aggregator could use the same IEC standard solution in order to manage the flexibility offered by EVs both in public (Aggregator - EMSP interface) and in private domain (Aggregator - EMG+CEM interface). The EV User actors are authenticated by the EVSE and express to EMSP their preferences related to charging time and requested energy. The Virtual DSO is implemented through a controllable grid simulator, in case a real EVSE is under test. An alternative is the connection of the EVSE to a real LV distribution grid, which can be monitored. Regarding the metering aspect, it should be noted that a Demand Response service requires an adequate advanced metering infrastructure, that should support a reading interval corresponding to the specific time period (e.g. 15, 30 or 60 minutes) requested by the Demand Response functionality. There are two types of use and related information exchange path for the metering data. The first kind of metering information are collected by the Meter Operator and are periodically (i.e. weekly/monthly) sent to the Aggregator in order to define the economic transaction in favor of the Demand Response participants. Another kind of metering information is needed more frequently (i.e. every 15 minutes) for operational objectives and are sent from the meter to the Aggregator by the EVSE-EVSEO-EMSP path. RSE metering equipment and their information exchange interfaces are based on a custom solution and do not comply with any metering standard. So the test architecture considers the information exchanges related to the interface between the meter and the meter Operator only as a functional support of the Demand Response scenario, without any implementation of a real metering standard interface. On the other hand, the information flow from the meter to the Aggregator by the EVSE-EVSEO-EMSP path is concretely realized in the interfaces between the EVSE-EVSEO (OCPP) and EMSP- Aggregator (IEC-62746). Deliverable no EU Project no

41 3.4. TECNALIA The infrastructure implemented by Tecnalia comprises several emulators designed for testing: the EV, the EVSE, the EVSE Operator and up to some extent the Clearing House. The following picture shows this implementation mapped into the 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 Tecnalia Electrical/Physical Figure 25: Tecnalia s infrastructure mapped to the Reference Architecture Both, the EV and the EVSE are physical devices which perform the following tasks: They are complete emulators, which can be connected to any real component (as far as the real component implements the same communication protocol) They have special capabilities to test DuT (online and offline) The DuT can be connected to the real world through the router As prerequisite, the laboratory was designed not only for testing EV and EVSE, but to collaborate with other laboratories too. As an example, when an EVSE is sent to Tecnalia for testing IEC and OCPP protocols, Tecnalia will use its emulated EV for testing the charging (IEC 61851) and its EVSE Operator for testing OCPP. As OCPP has several versions and protocol implementations, the laboratory is able to send the OCPP messages to other COTEVOS laboratories. This solution provides to the manufactures a more robust testing because several laboratories are involved in the testing process Implemented protocols and functionality There is a difference between protocols and standards. A protocol is a system of rules which defines the normal behaviour and procedures that must be followed. Therefore, a communication protocol includes all communication rules (communication establishment and termination, data model, data types, message exchange, routing, bridging, etc.). Once a protocol is approved by an authority related Deliverable no EU Project no

42 to the purpose of this organization, the protocol becomes a standard. The infrastructure implemented by Tecnalia includes two standards for EV charging, one widely adopted protocol (OCPP) that almost all EVSEs implement it and an ad-hoc system. Tecnalia does not implement non adopted or ad-hoc protocols because they are closed protocols, even private in most cases, which could change without previous notice. Therefore, its efforts were aimed to standards and protocols that are (or will be) worldwide deployed. The exception of this is OCHP, as it is not being adopted by the industry, the Clearing House developed in the European project ICT4EVEU is used for testing the communication with the Clearing House IEC This EV charging protocol has been implemented for both EV and EVSE. The functionality that these components can perform is listed below: EV. Hardware and software installed in the EV emulator to test EVSE from manufacturers. 1. Read of the PWM incoming signals (frequency and duty cycle) 2. Normal or forced ventilation required selection 3. S2 selector selection (for normal and anomalous behavior) 4. Charge at higher rate of the duty cycle EVSE. Hardware and software installed in the EVSE emulator to test EV from manufacturers. 5. Configure PWM outgoing signal (frequency and duty cycle) 6. Read of the Proximity Pilot resistor for cable maximum power capacity 7. Read of the Control Pilot Voltage (to get S2 selector) 8. Ad-hoc power line relay control to deliver energy to the cable Common functionality. This functionality is available for both, EV and EVSE, modules o o o o Automatic parameters reading and storage Predefined set of actions for testing. It contains a file gathering the actions that the testing platform must execute within the testing timeline. The test execution reads this file and when an action is defined for a specific time (seconds after the beginning of the test), the action is fired. This way, the testing file drives the behavior of the process, executing any of the 1-8 actions. Logging module for software and firmware State machine implementation driven by events Deliverable no EU Project no

43 ISO/IEC This EV charging protocol has been implemented for both EV and EVSE. As this standard is very extensive and contains multiple protocols, the following functions were: DHCP client and server SDP client and server o o UDP messages V2GTP headers V2G XML messages (request and response) with complete headers: o o o o o o o o o o o o SupportedAppProtocol SessionSetup ServiceDiscoveryRes Service-Detail ServicePaymentSelection PaymentDetails Authorization ChargeParametersDiscovery PowerDelivery ChargingStatus MeteringReceipt SessionStop EXI implementation TCP communication Certificates and CA SLAC server State machine implementation driven by received messages Three execution modes o Only ISO/IEC o Combined execution (both ISO/IEC and IEC are executing and collaborating) Error handling HLC for the whole testing execution Combined HLC and duty cycle control Deliverable no EU Project no

44 PnC charge Automatic parameters reading and storage Bridge to send/receive V2G messages to third parties for authorization and parameters discovery messages Allows enabling and disabling timeouts Functions which are not covered and workarounds: V2G XML messages: o o CertificateInstallation CertificateUpdate SLAC client. The SLAC protocol cannot be tested. In order to perform a communication link between PLC devices, the NMK must be modified manually TLS communication EIM charge Although a CA for e-mobility was created in Tecnalia and several certificates were issued for EVs and EVSEs, encrypted information was not used so far OCPP The emulated EVSE contains the OCPP ChargePointService (client and server) v1.2. When defined in the testing configuration file, all the protocol related information is sent to the central system (EVSE Operator). This function can be disabled for testing, as far as the DuT already has its own interface for this communication. There is also an OCPP v2.0 rc1 testing implementation for SOAP. The WSDL defined for the EVSE and EVSE Operator have been implemented in separate computers, allowing this testing functionality: Message launchers. One message launcher for EVSE and other for the EVSE Operator have been implemented. They import the soapui platform and use its API for configuring the messages and launch them to the reception point in an automatic way. Servers. Two servers were also implemented for the EVSE and for the EVSE Operator. They are aimed to gather the information from the invoking actor and answer accordingly Clearing House communication (decoupled) As OCHP is not being adopted by the industry, the Clearing House developed in the ICT4EVEU project will be used for testing the communication with the Clearing House. It is not a standard, but a Clearing House implementation developed in a European project. Implemented functions: Roaming authorization Deliverable no EU Project no

45 Exchange charge information Exchange charge point information Actor emulators implementation The following sections describe the way the actors are implemented, including the covered protocols, that the DuT is able to test, the hardware and software used as well as the deployment diagram EV It is an emulated EV with full functionality which implements both IEC and ISO/IEC This hardware can be connected to any EVSE DuT in order to check if the EVSE complies with the standard. the following picture shows the EV hardware installed in the laboratory and their connections. Tecnalia + Arduino CP DSIEC2f-EV32S-NC INSYS PowerLine GP PP Switch EKI 2525 Xanbus gateway Link Pro Charger/Inverter XW Industrial PC ARK-2120L Tecnalia 2 x Classic FF Figure 26: Tecnalia s hardware for EV The functionality of the components depicted in the picture is the following: Industrial PC. An industrial PC containing the software of the state machines for the two standards, all tests, software and drivers, etc. One Ethernet connection is used for internal management and the other Ethernet connection is used for a complete ISO/IEC charging. Deliverable no EU Project no

46 INSYS PowerLine. This is an Ethernet bridge to send and receive Ethernet messages through a power line cable according to ISO/IEC It uses the Control Pilot for the PLC. Tecnalia + Arduino. A couple of chip and boards with Ethernet support and TCP for the IEC protocol, which: o o Reads the Control Pilot and the Proximity Pilot signals, processes and sends them to the Industrial PC, which is running the state machine. Executes the orders given by the state machine and the test case application, such as controlling S2 selector and select forced ventilation or not. Switch. A simple switch for the components network EV connector. A normative Mennekes 32A connector Batteries. Two batteries, installed as serial (up to 24V) Charger/Inverter. A device than can charge and discharge the batteries, controlling the power and the current by proprietary commands (developed by Xantrex). Gateway. This gateway translates the proprietary commands developed by Xantrex to restricted Modbus TCP communication Link Pro. As the charger/inverter cannot calculate the State of Charge of the batteries properly, this component was purchased for monitoring. Notice that for image clarity, other hardware such as bulbs, power sources and their cables are not depicted in the figure. The lines connecting the components have different meanings: Black line. The power line, the cables and cords for energy transport. Red line. Ethernet connection. Orange line. The Control Pilot line. The PWM signal (and the coupled PLC signal when using both standards) is transmitted by this cable. Green line (white line in conventions). The Proximity Pilot cable that the Arduino + Tecnalia board uses to get the value of the cable grip resistor. This data is used to know the maximum current capacity that the power line cord can support. Dashed red lines. For proprietary communication. A special program, driver, serial connector, etc. must be installed to communicate with devices implementing proprietary protocols. The developed software and libraries are installed in the Industrial PC and in the Tecnalia + Arduino board. Special drivers were developed to gather the information from external devices with proprietary implementation (LinkPro and Xantrex charger/inverter). Deliverable no EU Project no

47 EVSE It is an emulated EVSE with full functionality which implements both IEC and ISO/IEC standards. This hardware allows charging a real EV DuT according to these standards, adopting also OCPP. The following picture shows the EVSE hardware installed in the laboratory and their connections. Tecnalia + Arduino CP (pure) INSYS PowerLine GP (with SLAC) CP (with HLC) PP DSIEC-M-EV32S Schneider LC1D Switch EKI 2528 Industrial PC Xtrem n7000 Circutor CVM Mini Tecnalia To Tecnalia Internet Router To power grid Figure 27: Tecnalia s hardware for EVSE The functionality of the components depicted in the figure is listed below: Industrial PC. An industrial PC containing the software of the state machines for the two standards, all tests, software and drivers, etc. One Ethernet connection is used for internal management and for a complete ISO/IEC charging. The other Ethernet connection is used to connect the EVSE to Internet through a router. This allows that the EV can be charged using real communication and information from the central system (EMSP). INSYS PowerLine. This is an Ethernet bridge to send and receive Ethernet messages through a power line cable according to ISO/IEC It uses the Control Pilot for the cable communication. This device has its SLAC server enabled. This allows that any EV can be charged without any workaround. Tecnalia + Arduino. A couple of chip and boards with Ethernet connection and TCP for IEC which: o reads the Control Pilot and the Proximity Pilot signals, processes and sends them to Deliverable no EU Project no

48 the Industrial PC, which has installed the state machine, o executes the orders given by the state machine and the test case application, such as changing the PWM duty cycle or frequency, read internal parameters, etc. Switch. A simple switch for the components network. This switch also manages the IPv6 network for ISO/IEC EV connector. A normative Mennekes 32A connector Power relay. A 24V activated device which opens and closes the power line (energy delivery to EV). Power analyzer. This device analyses the power line and can transmit several values, such as voltage, current, energy, power factor, etc. Once more, some hardware was omitted in the figure for image clarity. An emergency stop button was installed in the EVSE for safety. The lines connecting the components have different meanings: Black line. The power line, the cables and cords for energy transport. Red line. Ethernet connection. Orange line. The Control Pilot line. The PWM signal (and the coupled PLC signal when using both standards) is transmitted by this cable. Green line (white line in conventions). The Proximity Pilot cable that the Arduino + Tecnalia board uses to get the value of the cable grip resistor. This data is used to know the maximum current capacity that the charging cord can support. Dashed red lines. For proprietary communication. A special program, driver, serial connector, etc. must be present to send, receive and understand the information transmitted in this lines. Dashed black lines. Digital signals (1-0) for sending trivial signals to limited devices. All the developed software and libraries are installed in the Industrial PC and in the Tecnalia + Arduino board. A special driver for the power analyzer was developed to gather the electric values (mainly current and power from the power line) EVSE Operator OCPP was implemented for the EVSE Operator. In fact, it is an emulated system for any SOAP message containing information related to the specification (or not). The only hardware requirement for this infrastructure is a computer with Internet connection when the DuT is being tested remotely or even together with another COTEVOS laboratory. Deliverable no EU Project no

49 Clearing House OCHP was not used for Clearing House because it is not being adopted nowadays. As a result, the Clearing House developed within the ICT4EVEU was selected. As the EVSE Operator, only a computer is required to emulate a Clearing House, but in this case the Internet connection is mandatory. The testing platform can test any actor which has communication with the Clearing House; mainly the EVSE Operator and the EMSP Developed software and scope of executable tests The software developed by Tecnalia to implement the required functionalities was programmed in different packages. All the modules deployed in the Industrial PCs in both sides (EV and EVSE), as well as the Clearing House and the EVSE Operator, were implemented in Java (JDK 1.7). For some ISO/IEC mandatory protocols, third parties software and libraries were also installed. All modules installed in Arduino were developed in C programming language. The drivers which control proprietary communication protocols were also installed in the Industrial PCs and an ad-hoc Java based API was also developed and installed for all of them. In the following sections a resume of this software is described EV The EV emulates a real EV, designed to test EVSEs. The charging can be made by means of the IEC and the ISO/IEC standards. They are separate software modules. The IEC module is a relatively simple state machine with an event driven model that must comply with the following sequence diagram for charging. As a result, every change in the read parameters (voltage, current) leads to a state change. A small configuration file is used for testing containing information about the test that must be executed. For example, a normal, successful charge, a forced failure at a specific time or an abnormal charge can be configured. Once this file is read by a parser, a timer is started and the charge process is executed according to the information read. This timer helps to read all parameters (current state machine, voltages, currents, etc.) and stores it in a log file, which is the output file of the test. This timer also fires the actions written in the configuration file at the specified time. Deliverable no EU Project no

50 Figure 28: EV sequence diagram according to IEC The ISO/IEC module is composed by several components. Although this standard is also a state machine, the implementation was made in a different way. The messaging module contains the XSD and the rules and prerequisites to be followed once the message is sent to the EVSE. Therefore, the module is also a state machine but with a messages driven model. Every message sent must be mapped to an specific state according to the response or the possible responses. Once the response is received, it is processed in the specified way. The system is designed to work in IEC mode, in ISO/IEC pure mode and in combined mode. The first mode just runs the module. In the second mode, the module is mounted upon the module, forcing it to send a constant 5% duty cycle to say that a 100% HLC is demanded and all the charge will be driven by the XML messages interchanged between the EV and the EVSE. However, in the combined mode, both machines must be executed and coexist. This means that both modules are executed as if they were independent, but a manager must control constantly which module is the master. These modes are described in the part 1 of the ISO/IEC standard, which describes the charge allowed modes (A use cases). The ISO/IEC is a very complex standard, which imports several communication protocols, data models, etc. It also covers all OSI levels 1-7, which forces this standard to specify every message, every event and every communication protocol that is used, from the session establishment until the end of the charge. The following picture shows all the actions that the EV must perform and check to establish a link between it and the EVSE. According to this sequence diagram, a great number of messages must be interchanged and a great number of communication protocols must be used. Notice that this diagram only shows the EV and EVSE association process, the charging process is not depicted in the picture. Once the association is successfully established, the charging process can start, using the messages and rules in the part 2 of the standard. Deliverable no EU Project no

51 Figure 29: Communication setup for EV according to ISO/IEC The whole EV software is implemented in several modules: Common modules. They are modules that gather common functionality for the EV and the EVSE, such as data types, messages, I/O streams, etc. As these modules are shared by both actors, they have been developed as libraries. o o o o o 61851common library. It contains the data types, states, timers, test functionalities, event sources and interfaces described in the IEC standard StateMachine library. It contains the data types, states, timers, test functionalities and interfaces described in the ISO/IEC standard. Xml15118 library. This is a small XML parser to marshal and unmarshal XML messages to Java objects. It also provides the XML-EXI conversions. Arduino library. This software sends commands to the Arduino + Tecnalia board and gets the returned data in a specific way, according to the data model of the module which request for the information. SDPCommon library. This software composes and decomposes UDP messages when both EV and EVSE are trying to discover each other. Deliverable no EU Project no

52 o o Log library. This module writes a great amount of parameters into a log file while the testing is executing. Root CA library. This CA delivers certificates for EV and EVSEs. It is self-signed EV module. This is the main program for testing EVSEs following only the IEC standard. Once started, this module acts as a real EV, performing any action described in the testing configuration file. EV15118StateMachine module. This is a program for testing EVSEs according only to the messages described in the state machine of the ISO/IEC standard. This module is for testing the messages once the EV-EVSE link is stablished. SDPClient module. This module is the SDP client that the EV must execute to know where is the EVSE (IP, port) where its ISO/IEC software is running. A2EVp15118 module. This is the main program to perform tests by means of the ISO/IEC pure mode, as well as in combined mode. The testing configuration file must gather what kind of test must be executed. This module makes use of all other modules and libraries. Other software, drivers, etc. o o o o DHCP client to get the IPv6 from the EVSE Modbus library to communicate with the charger/inverter and its gateway Xantrex2 for the charger/inverter data model LinkPro for reading the state of charge of the batteries Notice that the part 3 of the ISO/IEC is not present in the implemented modules, as far as the INSYS Powerline device manages all this information. In Figure 29, a boundary is depicted (in orange) for this functionality. Although the functionality within this boundary is executed, the developed software cannot trace the actions taken by this device because it does not provide access to its internal variables. INSYS Powerline does not implement the SLAC client. This means that the orange boundary will never be launched. According to the standard, the link at OSI level 1 is established by means of this protocol. Once the SLAC protocol is executed, a key (NMK) is retrieved from the SLAC server, installed in the EVSE, and stored locally to share the same NMK. Once the NMK is shared, the EV- EVSE link is established and both systems can communicate and configure the Ethernet and IP network. When testing a EVSE, the EV emulator NMK must be updated manually EVSE The EVSE emulates a real EVSE and it is designed to test EVs. As for the EV, the charging can be made by means of the IEC and the ISO/IEC standards and they were implemented in separate software modules. The IEC module is similar to the EV module but adapted for the EVSE, using also a small configuration file for testing. The state machine reads this file and performs the described actions within the charging process by means of a timer, writing the states, variables, etc. in a log file as the result of the test. The sequence diagram for the EVSE can be seen in the Deliverable no EU Project no

53 Figure 30: EVSE sequence diagram according to IEC The ISO/IEC module is also composed by several components, including the messaging module containing the XSD and the rules and prerequisites to be followed once the message is received from the EV. This is also a state machine with messages driven model. The system is also designed to work in IEC mode, in ISO/IEC pure mode and in combined mode, similar to the EV emulator described before. Figure 30: EVSE sequence diagram according to IEC The software is implemented in several modules: Common modules. They are the same common modules described in the EV side EVSE module. This is the main program for testing EVs following only the IEC standard. Once started, this module acts as a real EVSE, performing any action described in the testing configuration file. EVSE15118StateMachine module. This is a program for testing EVs according only to the messages described in the state machine of the ISO/IEC standard. This module is for testing the messages once the EV-EVSE link is stablished. SDPServer module. This module is the SDP server which is constantly listening to incoming UDP/SDP messages from the EV. A2EVSEp15118 module. This is the main program to perform tests by means of the ISO/IEC pure mode, as well as in combined mode. The testing configuration file must gather what kind of test must be executed. This module makes use of all other modules and libraries. Other software, drivers, etc. Deliverable no EU Project no

54 o o o DHCP server to assign valid IPv6 to the EVs. Modbus library to communicate with the power line analyser. DHCP client (or static IP) to get the external IP address to communicate this emulated EVSE to the Internet. It is used to access to the EVSE Operator and other actors. Notice that the part 3 of the ISO/IEC is also not present in the developed modules for the same reasons as described in the EV emulator. As a result, although the functionality is executed, the developed software cannot trace these actions. In contrast, INSYS Powerline implements the SLAC server. This means that it is able to provide the NMK to any real EV which implements the SLAC client, obviously. Therefore, this EVSE is a full implementation of the Part 3 of the standard and can charge any EV according to the standard, without any workaround. The EVSE implementation not only deals with the EV-EVSE communication, but with the rest of the actors as well. This emulated EVSE also contains functionality for some messages that have to be transmitted or received from third parties. The authorization process, as well as the charge parameters discovery process in ISO/IEC is designed to integrate third parties in the whole charging process. When the EV is authorizing itself in the EVSE, the authorization message is produced by the EV and sent to the EVSE. If the EVSE cannot decide whether allow charging or not (in its white list), the EVSE should send this message to the EMSP through its Internet connection. This process is transparent to the EVSE because it only routes the message to a remote endpoint. This endpoint (e.g. EMSP) will decide if the EV can be charge or not, or it can invoke the Clearing House for this decision. OCPP module The EVSE OCPP module is not installed in the emulated EVSE described previously. This module was developed to test the EVSE Operator separately from the EV-EVSE communication. It is a SOAP OCPP v2.0 client and server installed in a separate computer which additional functionalities for customized SOAP messages generation. This approach allows this software acting as a real EVSE, which sends and receives OCPP messages. The customized SOAP messages produced by this module are used for interoperability, sending valid and invalid messages and allowing modifying headers. It was also developed in Java EVSE Operator The emulated EVSE Operator was developed to test the OCPP protocol. This allows testing EVSEs with the OCPP v2.0 SOAP protocol. Two pieces of software were implemented. The first one is a Java implementation of the Web Service server described in the WSDL centralsystem.wsdl. The second one is another Java implementation of the Web Service client described in the WSDL chargepoint.wsdl. Both WSDL files are defined by the OCA. Both applications contain a configuration file for generating valid and invalid responses (unitary SOAP testing conformance). Moreover, a context dependent tool was also developed in order to test sequences. According to the Web Services specification, the messages are always sent in order, but nobody assures that the reception will be in order too. This sentence can affect to OCPP, whose messages are context dependent in many cases (authorization, metering values, etc.). As a result, this software also manages these messages and checks their possible incongruences. Deliverable no EU Project no

55 Clearing House As the OCHP is not being adopted by the industry, the Clearing House developed in the ICT4EVEU project is used. It is a complete implementation of a Clearing House providing clearing services to several actors, mainly between EVSE Operators and EMSP, interchanging information about charging process, authorization, list of contracted users, etc. The developed software in Java provides has two execution modes. The normal mode, the module generates messages to tests EMSP, EVSE Operators to check if the outcome of the tests complies with the specifications. As the Clearing House could be installed in several Internet sites, the auto mode allows testing Clearing Houses too. Deliverable no EU Project no

56 3.5. TNO The goals for the COTEVOS project comprise the development of test methods and test infrastructure in order to be able to assess interoperability between existing and (near) future EV (charging) systems, charging infrastructure and (smart) grids. To assess interoperability in a meaningful way, a full system approach will be required. In practice such full system cannot be built into a lab environment using real/tangible smart grid actors and components, as these actors/components are either too expensive, not available, or it is physically not possible to create representative situations while using these components within a laboratory setup. In order to be able to provide a full system approach, TNO aims to build a Content-wise Complete tool that is able to emulate the E-mobility reference architecture as defined in the COTEVOS project, including the specified actors and their associated responsibilities (see section 4.2 of Deliverable D3.2).The tool addresses the interaction between the grid infrastructure and electric vehicles, thereby allowing interoperability focused use- and test-cases to be executed in a meaningful way. Furthermore, the tool explicitly addresses test cases regarding adaptive charging. This means that the test cases will focus on aspects such as supported charge schedules, changing these schedules according different objectives (e.g. electricity price, congestion management, slower/faster charging, etc.) and the interaction between the EV, EVSE, DSO, EVSE Operator and/or EMSP providing smart charging algorithms. Part of these functions are implemented in the so called back-end systems of the DSO, EVSE Operator and EMSP and can subsequently be implemented in software. Since such a software implementation can easily run on a single laptop, TNO s InterOperability (IOP) laboratory can fit in a suitcase, as visualized in Figure 31. TNO s EV- IOP-Lab- In-A-Suitcase EVSE as DUT EV simulator Connected to grid Figure 31: TNO s envisioned interoperability Lab in a Suitcase Deliverable no EU Project no

57 To be able to support the execution of COTEVOS s enhanced interoperability focused test cases in a meaningful way, the tool shall support the inclusion and use of realistically emulated actors. The idea therewith is that these emulated actors can only share information that can be shared in real-life (which is typically restricted due to limitations in the available physical connections, the used standards/ protocols and other practical constraints). This implies that there shall exist a one-to-one mapping between the internal connections in the tool and the corresponding real-world (physical) connections. Such one-to-one mapping shall also exist between the internally used information objects and the real-world standards/protocols for the considered group of test cases/scenarios. Knowing that the proof of the pudding is in the eating, the proof for an information content wise precise implementation of the tool is that actors can be replaced by their real-world equivalents without changing the information objects used by, and behavior of, the other actors in the tool. TNO wants to provide such proof in the context of the activities for WP5 5. As the focus within the COTEVOS project is on the interoperability of EVs and EVSEs with each other and with the back-end systems, TNO wants to demonstrate within WP5 of the COTEVOS project that a combination of an emulated EVSE instance and an emulated EV instance in the tool can be replaced by an actual implementation of an EVSE, connected with an EV. Within WP4 and WP5 (of the COTEVOS project) TNO is expected to define and execute interoperability focused test cases for the Adaptive Charging group of test cases. The goal is therewith to identify mismatches between the information that the interfaces, which are associated with existing standards, can transfer and the information objects required to successfully execute the considered group of test cases. This insight allows standardization gaps to be identified. TNO aims to execute a part of these use cases using an actual implementation of an EVSE, connected with an EV Requirements In order to support the mentioned goals for TNO s emulation tool, this tool shall: be able to contain a representation of all actors from the COTEVOS reference architecture (as defined in D3.2 and visualized in Figure 1), support any meaningful mapping of the services as defined in D3.2 (and visualized in Figure 2) onto the contained/represented actors, be able to execute realistic test scenarios, addressing the functionality associated with the involved actors and the services that these actors are presumed to provide, support the definition of communication channels between the contained actors (or: between the services provided by these actors), be able to associate one or more interfaces for each of these communication channels. These 5 Important note: the step from a Content-wise Complete simulation environment towards a (Behavioral) Complete emulation environment can only be considered as doable within the given constraints (i.e. time and budget) if for the added hardware and corresponding communication protocol stacks only the (typical) happy paths are considered. This implies that with the intended extension of the tool it will not be possible to support conformance tests! Deliverable no EU Project no

58 interfaces shall support the exchange of information objects, which can be seen as a set of parameters from which each parameter can be provided, required or both provided and required. The parameter sets from an interface can be constrained. Interface definitions, and more in particular: the exchanged parameters, may be constrained by a specific protocol implementation, or a stack of several specific protocol implementations. These constraints need to be asserted explicitly in the simulation software, thereby allowing the identification of interoperability issues, support the replacement of simulated actors with their real-world or emulated equivalents. The latter implies that the execution of a test case shall not only result in a realistic sequence of events, using realistic information exchange information (objects), but also the timing of these events, needs to be taken into account, provide an implementation (i.e. a tool) based on the mentioned requirements, thereby including support for a direct OCPP 1.6 based connection between this implementation/tool and a compatible EVSE-EV combination Architecture and design The architecture of TNO s ESGSST is defined in accordance with the COTEVOS reference architecture as visualized in Figure 32. The services, as defined in the COTEVOS reference service oriented architecture (Figure 2), will be implemented as web services (i.e. a service oriented architecture will be adopted for the design of TNO s Lab-in-a-suitcase tool). Message bus GUI Logging Visualis -ation Scenario Editor EVSP Sim. Energy retailer sim OEM sim Simulated Actors EVuser sim EVSE proxy EVSE sim. OCPP stack EV sim. DSO sim. EVSE O sim. CH sim... EVSP Energy retailer OEM EV user DSO Real World Actors EVSEO CH TNO s WP5 test environment EMS EV Charger / Inverter EVSE Grid Electrical/Physical Actors Deliverable no EU Project no

59 Figure 32: TNO s WP5 test environment related with the COTEVOS reference test architecture To start, stop and monitor all the services that are included in the simulation, the tool will use an Orchestrator component. A web-based GUI will be used to configure, control and visualize the simulation and it results. This means that for the Message bus a TCP/IP based implementation has been chosen. All simulated actors will be implicitly defined by instantiating the set of services that these actors are presumed to provide. Each service is associated with a set of information objects, which implicitly define the interface belonging to that service. The information objects may be further specialized/detailed and constrained by a standard/protocol, or set of standards/protocols. Specialization means that specific behaviour can be associated with the exchange of data. This mechanism allows for example the exchange of information between an EV and an EVSE to be specialized using the behaviour of the IEC protocol, which first requires the setup of a high level communication link, possibly followed by a certification, identification, authentication, and/or authorization method, possibly followed by the selection of some charging schedule, before the actual charging of the EV can be started. Constraining the data means that conditions are attached to (a subset of the parameters belonging to) information objects, which need to be asserted/logged by the Smart Grid simulation software thereby allowing the identification of interoperability issues. Information object constraints may be defined in terms of parameter based expressions (e.g. (evse.dutycycle==5%) && (veh.soc >80%) ), possibly extended with dependencies on the state of the standard/protocol related state machine (e.g. evse_ protocol.currentstate == F0). The tool, or more precisely: the Orchestrator and all required services, will be implemented in the programming language Java, using the Eclipse development environment. A SOAP/XML based implementation of the OCPP stack, encapsulated by an EVSE proxy will be implemented to provide access to the real-world EVSE (which is possibly connected to a real-world EV) Envisioned supported test cases within WP5 With the ESGSST, TNO should be able to execute round-robin tests using one or more EVSEs that support the OCPP as the protocol between the EVSE and EVSE Operator. Such EVSE can be used in combination with an(y) EV. The expectation is to test 2-3 EVSEs; two from TNO partners in the Netherlands and may be another one from or through one of the COTEVOS partners. The test cases to be performed are the test cases that originate from the Adaptive Charging use case group. Within this group, the test cases resulting from the Controlled charging use case are the most likely candidates to be executed as part of WP5. For the design of the tool the focus will be on the implementation of those services, standards, protocols and functionality that needs to be implemented in order to be able to run the use-/test-case (extensions) that reside in the Adaptive Charging use-/test-case group. 6 A SOAP/XML implementation is foreseen, but a JSON/websocket based implementation might be supported as well Deliverable no EU Project no

60 Current status At the moment of writing this report, TNO has realized parts of the tool, allowing instances of the different services provided by multiple actors (from the COTEVOS E-mobility architecture) to be defined. These services are able to exchange data, but not (yet) via specific standards/protocols and also not (yet) taking specific constraints into account. In its current state, the tool is information object focused, i.e. the expected behaviour and the required information objects that need to be exchanged between the actors services are already in place, but are currently not using the specified standards (if applicable/available) for those interfaces. In the remainder of the COTEVOS project this tool needs to be extended towards a Protocol focused tool, where at least the EVSE Operator backend (services) needs to be able to communicate through OCPP with a physical EVSE. This will allow the inclusion of a real EVSE (and EV) when executing the test cases from the Adaptive Charging use-/test-case group in WP5. The main services required for Smart Charging are implemented. Services that are not required for the Adaptive Charging use-/test-case group are out of scope (these are represented by the dark grey services in Figure 33). Clearing house EMSP Energy Provider Clearinghouse Service Other Services (e.g. Navigation) Procurement Service Energy Provider Service Contract & Billing Service EV Flexibility Aggregation Service Authentication & Authorisation service Charge Allocation Service EV User User ID Service EVSE Operator EVSE Operator Backend DSO Grid Management Service User Preference Service Charge Management Service EVSE Operational Mngt Service Meter Operator EV EVSE (CP) Metering Operations Service EV Battery Info Service Charge Execution Service EVSE Management Service Actor Physical Entity Service Out of scope Service Interface Figure 33: Services and interconnections supported by TNO s Smart Grid system simulation tool Deliverable no EU Project no

61 3.6. TUL This section gives an overview of the e-mobility oriented laboratory implementation at Lodz University of Technology. Presented architecture can be divided into two separate groups which are meant to be used to test: communication between EV/EVSE and Smart Gird - necessary to support V2G services, communication between EV and EVSE - needed for EV charging operations. After a concise description of the V2G concept the corresponding TUL laboratory implementation is depicted. Next, the infrastructure allowing for EV-EVSE communication testing is presented. Finally, the mapping of the implementation into the COTEVOS reference architecture is shown and the possible test cases of V2G services and EV charging operations are described EV Test System Implementation The TUL infrastructure is focused on two separate communication standards, the IEC utilized for provision of V2G services and IEC for EV-EVSE charging operation IEC testing infrastructure for V2G services V2G concept One of the main COTEVOS goals is to make progress in interoperability assessment at higher levels communications between EV/EVSE and a Smart Grid. For this purpose, within COTEVOS, the V2G test cases should be developed and tests must be performed. To be able to test the V2G services, it is necessary to initially: implement the Smart Grid architecture (including network metering and control) develop the EV/EVSE equipment with V2G functionality (mainly in the field of hardware and communication) Since, V2G architecture is meant to be the integral part of Smart Grid, it should not be introduced without it. Additionally, the presented concept of system should be coherent with both: the general COTEVOS architecture and communication scheme and with the existing Smart Grid solutions. Other words it is assumed that the V2G architecture must be adopted to the existing Smart Grid infrastructure, not conversely. The depicted V2G laboratory architecture in TUL was designed on the basis of this approach and is currently under development. The framework describing a Smart Grids, with implemented V2G services, are presented in Figure 34. One should note that a joint consideration of many MV and LV areas, in case of many additional actors such as EVs, DGs, controllable loads etc., would introduce serious modelling problems. Thus, it is believed that a Distribution System Operator (DSO) should control a LV network operation by Deliverable no EU Project no

62 additional controllers. Such separation is necessary to properly conduct optimization and other management activities. In certain cases, for example in LV network with just EVSE connected (such as big charging station/parking), the DSO controller and EVSE Operator would not differ from technical point of view. DSO level Distribution System Operator Secondary substation level DSO CONTROLLER DSO CONTROLLER DSO CONTROLLER the operator managing smart grid assets of local LV network DSO CONTROLLER DSO CONTROLLER Distributed Generation (DG) level Distributed Generation Energy Storage Charging Station (EVSE operator) Charging Station Distributed Generation Energy Storage EV level Numerous EVs EV Figure 34: General concept of Smart Grid control structure In Smart Grid accommodated in power system environment (including legal aspects), any operator of Smart Grid actually must be a network operator and should be subject to the Distribution System Operator. In the concept presented, the DSO controller serves as an operator of a Smart Grid, which is understood as a LV network area supplied by a single MV/LV substation. Such DSO controller can represent a legal entity or be a DSO s server or a controller. It would perform autonomously, controlling tasks according to defined criteria. In the DSO network it is conceivable that several DSO controllers can operate. The single controller would collect information from all DER units and EVSEs connected to its network. The DSO controller, taking into account metering data from: a grid, the DER units and the external signals from DSO, should be able to arrange operation of its network and send control signals to the actors. The detailed communication layout, describing V2G concept is presented in Figure 35. Two types of EVSE infrastructures are assumed: single EVSE with V2G ability EVSE cluster numerous EVSEs with V2G ability. The EVSE cluster may also be seen as the controller of many single EVSEs located in a single place, e.g. in car park next to shopping mal. In the first type of EVSE implementation, all information required for V2G provision is transmitted from EV by EVSE to DSO controller. In the second case, EVSE-Operator manages numerous dependent EVSEs and then DSO controller receives only aggregated information, e.g. aggregated available Deliverable no EU Project no

63 power in defined network node. Since a V2G is a kind of power system ancillary services, related communication should be coherent with a communication already existing in an electrical power networks. One of communication protocols that are strongly developed and used in a distribution systems is IEC This standard allows for double-side communication and is being adopted to the needs of V2G services. Therefore, it is reasonable that the communication between a DSO controller and an EVSE/EVSE-O will be established within IEC The standard IEC is designed in a very generally way, thus the spectrum of application is very wide [17]. The standard is made for the communication within substations, i.e. the communication with devices for protection control and metering. IEC does not define a communication stack with relation to the OSI layer model. It is utilizing TCP/IP as its basic transmission protocol and supporting both the Manufacturing Messaging Specification (MMS) and the File Transfer Protocol (FTP) for classic client/server communication. Two peer-to-peer services for real time communication are also described. In some cases, an EVSE with V2G ability would utilize some other double-side communication standard, such as OCPP (at present existing ver. 2.0 allows only for smart charging). Then protocol translator would be required to adjust communication from EVSE/EVSE-O to DSO controller backend. For communication between an EVSE and an EV, the IEC standard is assumed, as the most promising standard in this field. Deliverable no EU Project no

64 V2G communication scheme DSO level 20 kv Transformer 20/0,4 kv DSO s SCADA IEC Secondary substation level 0,4kV DSO CONTROLLER N PE IEC ph A M I IEC ph A M I IEC Protocol translator 3ph A M I EVSE level Charging Station (EVSE operator) ISO Charging Station ISO ISO OCCPv3.0 Charging Station EV level Numerous EVs Single EV Single EV LEGEND IEC IEC OCCPv3.0 ISO Agregated information about V2G transmitted by IEC Communication DSO controller-evse Detail information about V2G transmitted by IEC Communication DSO controller-evse Detail information about V2G transmitted by OCCPv3.0. Communication DSO controller-evse. Currently available version of the standard is OCCPv2.0 that do not support two direction communication. It is assumed that eventual further version of the protocol will allow both direction information exchange. Detail information about V2G transmitted by ISO Communication EVSE-EV Figure 35: Layout of communication links between entities according to a general concept presented in Figure 34 Deliverable no EU Project no

65 V2G Laboratory Architecture The main objective of the TUL V2G infrastructure is to test IEC communication at various levels: DSO DSO controller, DSO controller Single EV/EVSE, DSO controller EVSE-O. This communication is needed when the charging controller of the EVSE operator performs the EVSEs management. The DSO controller is provided only with aggregated information from charging controller (no detail information about EV is necessary). The communication layout together with the main equipment needed for V2G tests are presented in Figure 36. The SCADA (DSO) and the DSO Controller installed in TUL are based on commercial SCADA PRINS system, provided by BTC AG. Communication in this system is based on IEC which is a popular transmission protocol between grid control systems and substations. This standard enables the communication between control stations and substations via common TCP/IP networks using connection oriented, protected data transfer [17]. For the purpose of V2G test, the existing SCADA was upgraded to support the IEC Nevertheless, the IEC is utilized in EV/EVSE emulators for communication (in technical channel) between software emulated EV/EVSE and real devices such as programmable PLC controllers. The utilized real devices consists of: the universal telecontrol module utilized as IEC servers - Bilfinger Mauell ME4012PA- N, programmable logic controller used for management of real power inverter and emulate the EV - SAE Gate, energy storage power converter - ABB PCS100 and DTSTATCOM, signal emulator - custom computer application. Real model of MV and LV networks with DER (PV, gas microturbine, loads, etc) and Real Time Digital Simulator with power amplifier used in Smart Grid model. Although, in the presented TUL infrastructure, the IEC is used for communication between EV and EVSE, it is possible to replace it in future with IEC Deliverable no EU Project no

66 I-15 Laboratory architecture LEGEND DSO level 20 kv Transformer 20/0,4 kv DSO s SCADA IEC IEC IEC Detail information needed for V2G service transmitted by IEC Communication NOA-EVSE Detail information needed to emulate EVSE/ EV by IEC Connection between EVSE and EV can be replaced by in future. NOA level Partner SCADA 0,4kV N 3ph CONTROLLER (e.g. DSO) 3ph EVSE communication module External singal for emulators control Real device (MAUEL controler) representing EVSE/EV infrastructure (protocol translator). PE A M I A M I EV Gateway Emulator Emulated device/system of e-mobility infrastructure V2G ready. EVSE level EVSE Claster communication module (e.g. EVSO) EVSE communication module Stanowisko lokalne 1 (DR01) External control EV level EVSE emulator Power Inverter MODBUS TCP SAE GATE EV Emulator EVSE emulator Power Inverter MODBUS TCP SAE GATE EV Emulator Energy Storage (Battery) EV Gateway Emulator Energy Storage (Battery) EV Gateway Emulator Figure 36: V2G Laboratory architecture developed by TUL To enable communication (needed for V2G services), that complies with IEC standard, it was necessary to emulate EVSE and EV utilizing the logical nodes, Figure 37. The physical device is modelled by IED device (Intelligent Electronic Device), which includes one or more Logical Device (LD). LD model represents information about the resources of the host itself including real equipment connected and the common communication aspects applicable to a number of Logical Nodes (LN). LN model includes set of signals which represents detailed measurements, statuses etc. The description of the e-mobility logical devices and nodes can be found in the draft of IEC Object Models for Electrical Transportation. Deliverable no EU Project no

67 Figure 37: Logical Nodes overview of AC supply equipment and the EV IEC testing infrastructure for EV-EVSE charging operations Besides testing capabilities in the scope of IEC 61850, TUL can perform number of interoperability tests involving real life and market accessible devices, such as: ABB Terra 51 [13] charging station and Mitsubishi i-miev [14] electric vehicle. The available equipment can be utilized for the examination of communication between an electric vehicle and a charging station, performed by IEC However some tests, referring to IEC or OCCP, are possible. Additionally, presented equipment can be used for the assessment of electric power quality parameters (e.g. to monitor the charging station s influence on the supplying grid during the charging and the idle stages). For the purpose of preserving real life conditions, during EV charging, this equipment is neither modified nor customized. It should be taken into account, especially that for example the Mitsubishi I-Miev has no factory provided IEC capabilities, for example, this vehicle can be used to evaluate the responses of IEC devices trying to communicate with it. For the measurements and analysis of electrical characteristics of charging processes the FLUKE 1760 (manufactured by Fluke Corporation) [15] will be utilized. This instrument enables the assessment of supplying voltage indices according to criteria defined in European standard EN [4]. The Fluke 1760 can be connected to Terra charging station feeder or to the regular socket feeder (used to measure the slow charging processes). Some of the technical parameters of charging station and the electric vehicle are as follows: The ABB Terra 52 is a dual outlet (AC/DC) 50 kw fast charging station. Available network connection: 10/100 Base-T Ethernet (OCPP), GSM/GPRS/3G/CDMA/EVDO. It is compatible with electric vehicles compliant to: CHadeMO protocol - for DC charging and the EN standard - for AC charging (type 2, mode 3 charging). The Terra 52 rated input power is 55 kva (simultaneously changes up to 77 kva). The DC output maximum power is 50 kw, voltage range from 50 to 500 VDC, and maximum current is 120 ADC. The AC output allows for charging with maximum power up to 22 kw, voltage range is 400 VAC +/-10% and maximum current up to 30 AAC. The Mitsubishi i-miev parameters are as follows: o Propulsion System: Battery Electric Vehicle, o Onboard, one phase 3.5 kw charger o Inlet compliant to CHadeMO and EN o Battery type: Lithium Ion, Deliverable no EU Project no

68 o Nominal System Voltage: 330 V o Rated Pack Energy: 16 kwh o Fast charging characteristics: 30 min, 330 VDC, 150 ADC (up to 80 %), Figure 38: ABB Terra 52 charring station Reference Architecture Mapping TUL s infrastructure focuses on the real power flow. Hence, EV, EVSE and electricity network are implemented in a test system. Tandem of EV and EVSE is treated jointly and represented by emulator with real advanced power converter and battery storage. Electricity network can be modelled in various ways from real, physical model to computed digital model. Complete test bed can be controlled by SCADA system. Additionally, connection of EV and EVSE can be analysed within real, market available solutions. The mapping of TUL s infrastructure with COTEVOS reference architecture is depicted in Figure 39. Laboratory implementation covers interface H, E, A, G. Interfaces H and E are implemented with IEC Interface A is covered with protocol IEC Interface G indicates a real power flow and in TUL s implementation it includes emulators of EV+EVSE and electricity network model. Deliverable no EU Project no

69 Figure 39: COTEVOS Reference Architecture Scope of executable Tests TUL s laboratory infrastructure is focused mainly on the power system aspect of the EV integration. Much effort has been put toward implementation of hardware and software allowing V2G analyses and evaluation of real energy flow during EV charging or discharging. Because development of e-mobility is highly dependent on communication aspects, they have been also enabled in TUL s test bed. Tests of communication between EV and EVSE are possible in terms of IEC For evaluation of communication between EVSE/EVSE-O and DSO backend, IEC has been selected. Testing of such communication is especially important for V2G services in which a DSO is interested. Test of the physical interaction between grid and EV in case of normal charging, Smart Charging and V2G grid service provision are possible within the deployment of EV+EVSE emulators and real model of the electricity grid. Current range of the TUL s potential tests relating to EV includes two main areas: 1. Communication: a. selected tests of IEC protocol, b. tests of IEC protocol, including IEC TR (V2G services), Deliverable no EU Project no

70 c. translation of IEC to IEC Real power flow: a. management of LV grid with EVs (charging, smart charging and V2G), b. impacts of EVs charging (in all forms) on electricity network (in any configuration), c. particular V2G services. Deliverable no EU Project no

71 3.7. COTEVOS 3 rd parties NTUA The e-mobility testing infrastructure developed by the NTUA laboratory for the scope of the project comprises real charging equipment, i.e. EV, EVSE, as well as emulated one, i.e. EV, EVSE and EVSEO, Grid, EV User. A conceptual outline of the e-mobility facilities of NTUA is illustrated in Figure 51. Figure 40: NTUA s infrastructure mapped to the Reference Architecture In the next paragraphs, a detailed description of the different e-mobility components is provided E-mobility lab components A. EV An EV emulator supporting the interoperability testing of the EV related protocols (IEC61851 and IEC15118) is developed. The EV component is illustrated in Figure 41. It can be connected to an EVSE (as the device under testing) in order to validate its compliance with the standards. Deliverable no EU Project no

72 Figure 41: NTUA s EV component The EV emulator comprises the following components: Personal Computer: The software related to the EV side of two standards is developed in this computer. The drivers and the requested software for interacting with the different components are installed in this computer. INSYS PowerLine Module: Ethernet bridge allowing interaction between two components via a power line cable in respect to IEC NTUA + Arduino: A Custom made electronic interface for the control pilot processing in respect to IEC protocol EV connector Mennekes Type 2 (16A) Electromagnetic Lock for IEC Type 2 Socket/Inlet XML-RPC: The XML remote procedure call enables the interaction (data and operational message exchange) between the computer and the inverter Sunny Island Battery Inverter 4500 (3.7kW) Lead Acid Batteries 250Ah, 60V Moreover, a real-world electric vehicle will be exploited as the device under test for the interoperability tests. Deliverable no EU Project no

73 B. EVSE An EVSE emulator is developed by NTUA which allows the charging of a real or emulated EV in respect to two standards IEC61851 and IEC The EVSE can also communicate with external stakeholders, i.e. the EVSEO, implementing the OCPP 1.5 protocol. Figure 42 presents the EVSE emulator developed by NTUA. Figure 42: NTUA s EVSE component The EV emulator comprises the following components: Personal Computer: The software related to the EVSE side of two standards (IEC15118 and IEC 61851) and the OCPP 1.5 is developed in this computer. The drivers and the requested software for interacting with the different components are installed in this computer. INSYS PowerLine Module: Ethernet bridge allowing interaction between two components via a power line cable in respect to IEC INSYS SGM Pilot provides all the functions necessary for mode 3 charging according to IEC 61851, i.e. pilot signal, charging cable detection, load protection control, connector locking etc. NTUA + Arduino: A custom made electronic interface for the producing and managing (duty cycle, frequency, PWM, etc.) the control pilot in respect to IEC protocol. EV connector Mennekes Type 2 (16A) Electromagnetic Lock for IEC Type 2 Socket/Inlet Power relay Power analyzer Deliverable no EU Project no

74 Apart from the EVSE emulator, a commercial EV charging station (ETREL - 32A ). The technical specifications of the charging station are: Single phase charging up to (32A) IEC Type 2 Socket IEC Pilot Signal Touch Interface Remote User Interface for smart management RFID capabilities Figure 43: ETREL s EVSE C. EVSEO The OCPP 1.5 protocol for the communication between the EVSE and the EVSEO is implemented. No specific hardware is required apart from the device under testing. D. User Interface A custom-made energy management system with user interface has been developed by NTUA offering several services to e-mobility stakeholders: Searching for EVSE location Electricity price information EVSE availability (orange coloured EVSE means occupied while green one means available) Booking capabilities Figure 44. The interaction between the EV user interface and the EVSEO is realized via Rest-Based Web Service technology. The Web Service is using Maven built framework in order to compile and link the project into a.war file and RESTEasy framework as a JAX-RS (Java API for RESTful Web Services) implementation which provides support in creating Web Services according to the REST architectural pattern. Service method results are sent to the client in XML(Extensible Markup Language) format, generated via JAXB (Java API for XML Binding) on the service. The interaction between the EVSEO and the EVSE is realized in respect to the OCPP 1.5 protocol. Deliverable no EU Project no

75 Figure 44: NTUA s management system and User Interface E. Grid There are two alternatives for supplying the EVSE: either using the main grid or a grid-emulator. The grid-emulator is realized through the Real-Time Simulator (RTDS). The RTDS allows for hardware-inthe-loop simulations. The Real-Time Simulator of NTUA is a rack of the commercially available Real Time Digital Simulator RTDS. The rack contains several processing cards that work in parallel, an interface card as well as various analog, digital inputs and outputs. Specifically, the rack consists of 16 TPC (Tandem Processor Card), 1 dual 3PC (Triple Processor Card) and one WIF (Workstation Interface) card that is responsible for the communication of all the processing cards. Moreover, each TPC card has 8 analogue output ports and 2 digital input-outputs while the dual 3PC card has 48 analogue outputs and 4 digital input-outputs. The rack is also equipped with an OADC card that gives an addition of 6 inputs to the original 3 analogue inputs. In dedicated software (RSCAD) electric power networks with various components such as generators, transformers, protection devices, loads, etc. are simulated with a typical time-step of 50 μsec. The analog output range is ±10V and the analog input range is ±5V for the specific version of RTDS. Deliverable no EU Project no

76 Figure 45: NTUA s Real Time Simulator For the testing needs of the project, the real grid will be utilized. Deliverable no EU Project no

77 U.Strath At the University of Strathclyde we will attempt to set up 2 small test environments. The first test environment will use an existing small EVolt EV-PM3 3G charger [18], combined with a hand-held test unit (that emulates the vehicle). The tester includes a short EVSE-EV (charger to vehicle) test cable, which includes the dedicated communications conductors. This small rig can be used to show IEC61851-compatable handshaking and communications between the EVolt charger and the IEC61851 tester [19]. Figure 46: EVolt EV-PM3 3G Charger Figure 47: IEC61851 EVSE tester [ The second line of research involves basic ISO demonstration, coupled with (hopefully) some investigation into immunity of the power-line-carrier (PLC) communication to power quality on the EVSE-EV cable. Firstly, the benchtop ISO emulation environment will be recreated according to the design made by DTU (Technical University of Denmark): Deliverable no EU Project no

78 Figure 48: ISO benchtop test rig [design by DTU] This test rig consists of 2 power-line-carrier modems (PLC modems in this context). These are the devices labelled INSYS (EVSE) and INSYS (EV) in Figure 48. They will be coupled to 2 Beaglebone Black microcontrollers, labelled SECC COTEVOS HW platform. These two pairs of devices: the microcontrollers coupled to PLC modems, emulate (one one side) the EV, and (on the other side) the EVSE (charger). Both the microcontrollers communicate with the TEST PC over USB. The Test PC and Beaglebone Black microcontrollers will have testbed-specific software running on them. This software is developed by DTU and we hope to download it from the github portal at: Opensource implementation of IEC15118 based on openv2g stack and plc-utils from Qualcomm: The hardware we are purchasing is: 2 x BEAGLEBONE BLACK microcontrollers [20] 2 x HomePlug Green PHY INSYS Modems (PLC Power-Line Carrier) [21] Deliverable no EU Project no

79 Figure 49: Beaglebone black microcontroller SECC Cotevos HW platform [recommended by DTU] Figure 50: INSYS Powerline GP [recommended by DTU] Using this ISO test bench, we hope to be able to recreate basic communication and handshaking activities between the (emulated) EVSE (charger) and (emulated) EV, with the Test/Master PC controlling/observing the messages, and the microcontrollers and INSYS modems performing the low-level message generation/reception and modulation/demodulation onto the powerlines. One the rig is operational, a potential line of research is to inject different quantities and types of power quality disturbance onto the EVSE-EV line, using either our 15kVA or 90kVA power-hardwarein-the-loop interfaces. No current needs to flow in the EVSE-EV cable. But, we could include different levels of (for example) harmonic voltages onto the lines, to see if these have detrimental effects on the ability of the PLC modems to exchange their information. Deliverable no EU Project no

80 4. Summary The often discussed complexity of the area of EV-EVSE-grid interoperability as well as the interconnection between the e-mobility and the smart grid cloud is the most obvious reason why a single implementation of a convenient infrastructure for interoperability assessment is not suitable. The laboratory implementations presented in this deliverable do not only show the most convenient infrastructure(s) but also clearly demonstrate the common approach of the COTEVOS partners. This common approach is carried by the definition of the reference architecture which was agreed on throughout the whole consortium. The implementations presented by each partner represent a subset of this common reference architecture and thus together form the common approach for interoperability testing throughout the COTEVOS project. The following Figure 51 presents a depiction of the layer 3 the physical/laboratory layer of the COTEVOS reference architecture where the coloring of the different actors that are currently implemented are dependent on the amount of partners that have this actor currently implemented. Real World actors as well as the GUI are not colored, which does not mean that no partner has a real EV user, obviously if a partner has an EV he has an EV user, also each partner obviously has a GUI. But for the figure below (high level) real world actors are seen as an asset to a single test where required but not as part of laboratory infrastructure. Figure 51: Color coded layer 3 of the common reference model by the amount of implementations of actors in the COTEVOS partner laboratories The figure above not only shows a compilation of different laboratory implementations but in total also defines the most convenient infrastructure for interoperability testing. Deliverable no EU Project no