Erigrid User Case

European Research Infrastructure supporting Smart Grid
Systems Technology Development, Validation and Roll Out
Work Package 07
JRA1 - Use Case/Scenario Identification, Analysis and
Selection
Deliverable D7.3
D-JRA1.3 Use case implementation plan
Grant Agreement No: 654113

Funding Instrument: Research and Innovation Actions (RIA) – Integrating Activity (IA)
Funded under: INFRAIA-1-2014/2015: Integrating and opening existing national
and regional research infrastructures of European interest
Starting date of project: 01.11.2015
Project Duration: 54 month
Contractual delivery date: 31.01.2017

Actual delivery date: 02.04.2017
Name of lead beneficiary
for this deliverable: 18 VTT Technical Research Centre of Finland
Deliverable Type: Report (R)
Security Class: Confidential, only for members of the consortium (including the
Commission Services) (CO)
Revision / Status: released
Project co-funded by the European Commission within the H2020 Programme (2014-2020)
ERIGrid GA No: 654113 02.04.2017
Document Information
Document Version: 5
Revision / Status: released
All Authors/Partners Anna Kulmala / VTT

Kari Mäki / VTT
Carlo Sandroni / RSE
Daniele Pala / RSE
Maurizio Verga / RSE
Oliver Gehrke / DTU
Esteban Bondy / DTU
Kai Heussen / DTU
Panos Kotsampopoulos / ICCS
Achilleas Markou / ICCS
Alexandros Rigas / ICCS
Evangelos Rikos /CRES
Van Hoa Nguyen / GINP
Quoc Tuan Tran / CEA
Julia Merino / TEC
Distribution List ERIGrid consortium members
Document History
Revision Content / Changes Resp. Partner Date

1 First draft/content list VTT 25.01.17
2 Online working document, contents added VTT 01.02.17
3 First draft of the whole document VTT, CEA, CRES, TEC, 24.02.17
DTU, GINP, ICCS, RSE
4 Internal review version VTT 28.02.17
5 Complete version VTT 10.03.17
Document Approval
Final Approval Name Resp. Partner Date

Review Task Level Alexandros Rigas ICCS 06.03.17
Daniele Pala RSE
Ata Khavari DERlab
Rishabh Bhandia TUD
Review WP Level Marco Rossi, Daniele Pala RSE 07.03.17
Arjen van der Meer TUD
Oliver Gehrke DTU
Review Steering Com. Level Thomas Strasser AIT 02.04. 17
Disclaimer
This document contains material, which is copyrighted by certain ERIGrid consortium parties and
may not be reproduced or copied without permission. The information contained in this document
is the proprietary confidential information of certain ERIGrid consortium parties and may not be
disclosed except in accordance with the consortium agreement.
Deliverable: D7.3 Revision / Status: released 2 of 47

ERIGrid GA No: 654113 02.04.2017
The commercial use of any information in this document may require a licence from the proprietor
of that information.
Neither the ERIGrid consortium as a whole, nor any single party within the ERIGrid consortium
warrant that the information contained in this document is capable of use, nor that the use of such
information is free from risk. Neither the ERIGrid consortium as a whole, nor any single party within
the ERIGrid consortium accepts any liability for loss or damage suffered by any person using the
information.
This document does not represent the opinion of the European Community, and the European
Community is not responsible for any use that might be made of its content.
Copyright Notice
© The ERIGrid Consortium, 2015 – 2020

ERIGrid GA No: 654113 02.04.2017
Table of contents
Executive Summary ........................................................................................................................ 6

1 Introduction .............................................................................................................................. 7
1.1 Purpose of the Document ................................................................................................. 7
1.2 Scope of the Document .................................................................................................... 7
1.3 Structure of the Document ................................................................................................ 8
2 Test Case Descriptions ............................................................................................................ 9
2.1 System Configuration........................................................................................................ 9
2.2 Use case........................................................................................................................... 9
2.3 Test Case ....................................................................................................................... 10
3 Test Case Selection Process ................................................................................................. 11
3.1 Selection Criteria ............................................................................................................ 11
3.2 Testing Approaches ........................................................................................................ 11
3.3 Test Cases Selected for the Demonstration of ERIGrid Use Cases (JRA4 Test Cases) . 12
3.4 Test Cases Adopted in Simulations (JRA2 Test Cases) .................................................. 13
3.5 Test Cases Selected for the Laboratory Environments (JRA3 Test Cases) ..................... 14
3.6 Mapping to Focal Use Cases and System Configurations ............................................... 15
4 General Requirements for Test Case Implementation Plans .................................................. 17
4.1 Content of an Implementation Plan ................................................................................. 17
4.2 Test Case Mapping to RIs .............................................................................................. 17
4.2.1 TC.S.1: Component Testing at Different RIs with Different Set-up ........................... 18
4.2.2 TC.S.2: Use of SW Developed by RI1 in HW RI2 .................................................... 19
4.2.3 TC.S.3: Use of Comp. Model Devel. in RI1 to Perf. “Multi-domain System” Test in RI2 . 20
4.2.4 TC.S.4: Test of Distr. Cyber-Physical System in RI1 as a Monolithic Set-up in RI2.. 21
4.2.5 TC.M.1: Integrate Control SW Running in RI1 with HW RI2 ..................................... 22
4.2.6 TC.M.2: Extend HW Resources of RI1 Using Resources of Other RIs ..................... 24
5 Conclusions ........................................................................................................................... 26
6 References ............................................................................................................................ 27
7 Annex .................................................................................................................................... 28
7.1 List of Figures ................................................................................................................. 28
7.2 List of Tables .................................................................................................................. 28
7.3 Test Case Descriptions ................................................................................................... 29
7.3.1 TC.S.1: Component Testing at Different RIs with Different Set-up ........................... 29
7.3.2 TC.S.2: Use of SW Developed by RI1 in HW RI2 .................................................... 31
7.3.3 TC.S.3: Use of Comp. Model Devel. in RI1 to Perf. “Multi-domain System” Test in RI2 33
7.3.4 TC.S.4: Test of Distr. Cyber-Physical System in RI1 as a Monolithic Set-up in RI2.. 36
7.3.5 TC.M.1.1: Integrate Control SW Running in RI1 with HW RI2 .................................. 40
7.3.6 TC.M.1.2: Integrate Control SW Running in RI1 with HW RI2 .................................. 43
7.3.7 TC.M.2: Extend HW Resources of RI1 Using Resources of Other RIs ..................... 46

ERIGrid GA No: 654113 02.04.2017
Abbreviations
CHIL Controller Hardware-In-the-Loop

CIM Common Information Model
CVC Coordinated Voltage Control
DER Distributed Energy Resource
DMS Distribution Management System
EMS Energy Management System
ESS Energy Storage System
FRT Fault Ride Through
HIL Hardware-in-the-Loop
HW Hardware
ICT Information and Communication Technology
IED Intelligent Electronic Device
IGBT Insulated Gate Bipolar Transistor
JaNDER Joint Test Facility for Smart Energy Networks with Distributed Energy Resources
JRA Joint Research Activity
NA Networking Activity
OLTC On-Toad-Tap-Changer
PCC Point of Common Coupling
PHIL Power Hardware-In-the-Loop
RES Renewable Energy Source
RI Research Infrastructure
SM Smart Meter
SC System Configuration
SCADA Supervisory Control and Data Acquisition
SoC State of Charge
SuT System under Test
SW Software
TC Test Case
TCC Tap Changer Controller
UC Use Case
WP Work Package

ERIGrid GA No: 654113 02.04.2017
Executive Summary
This report summarizes the work conducted within ERIGrid Task JRA1.3 “Detailed implementation
of ERIGrid use cases”. The objective of this task has been to collect the test cases that will be im-
plemented in work packages JRA2 (Co-simulation based assessment methods), JRA3 (Integrated
laboratory-based assessment methods) and JRA4 (Implementation and demonstration of use cas-
es/scenarios in the integrated research infrastructures) and to strengthen the collaboration be-
tween these work packages. Synergies between the testing needs of JRA2, JRA3 and JRA4 have
been identified and taken into account in test case selection.
This deliverable presents the test cases that will be implemented in JRA2, JRA3 and JRA4. The
test cases have been selected based on research questions of each of the work packages and re-
search infrastructures to implement each of the test cases which have been selected. Test cases
are documented in the format determined in work package NA5. This deliverable concentrates es-
pecially on JRA4 test case selection and documentation. Work package JRA2 and JRA3 related
test cases are documented in this deliverable only briefly since they are detailed in the aforemen-
tioned work packages.

ERIGrid GA No: 654113 02.04.2017
1 Introduction
1.1 Purpose of the Document
Different smart grid use cases and scenarios require different validation and testing methods, in-
frastructures, deployment approaches as well as procedures. The development is also rapid in this
area and new solutions require a more cross-cutting methodology. ERIGrid Work Package (WP)
Joint Research Activity 1 (JRA1) “Use Case/Scenario Identification, Analysis and Selection” ad-
dresses these needs. The main objectives of this WP include:
 Identifying relevant scenarios and use cases,

 Analysing them in the context of ERIGrid capabilities, and
 Defining needs of extending Research Infrastructure (RI) services or developing new ones.
The work in WP JRA1 has been conducted in three tasks. At first, Task JRA1.1 defined generic
system configurations that provide an abstract description of three selected system areas: distribu-
tion grid, transmission grid and offshore wind, as well as vertical integration. These three system
areas are considered the most important ones for ERIGrid purposes and the system configurations
provide a context for ERIGrid testing. Task JRA1.2 continued from the system configuration defini-
tions by determining high-level focal use cases that cover the whole range of smart grid activities
relevant to ERIGrid. The five most relevant services (energy balance; energy efficiency; power
quality; power system stability; infrastructure integrity, protection and restoration) were selected as
a basis for focal use case selection and in total 16 focal use cases were selected. In these focal
use cases, all system configurations of Task JRA1.1 and all services of Task JRA1.2 are covered.
Whereas the work in Task JRA1.1 and Task JRA1.2 defined the most relevant testing scenarios for
ERIGrid at a relatively abstract level, the purpose of Task JRA1.3 is to develop practical test case im-
plementation plans. The implementation plans will be realized in the running and next JRA of ERIGrid:
 JRA2 - Co-simulation based assessment methods;

 JRA3 - Integrated laboratory-based assessment methods;
 JRA4 - Implementation and demonstration of use cases/scenarios in the integrated RIs.
Since the high-level focal use cases of JRA1.2 can be formulated to a multitude of test cases, all
the possible test cases cannot be implemented. JRA1.3 selects a subset of these test cases for
implementation in JRA2, JRA3 and JRA4. These test cases are selected based on the research
questions of each of the above mentioned WPs and do not try to cover the whole smart grid do-
main. The results of JRA1.3 work are documented in this deliverable.
This deliverable is intended for project internal use to facilitate the work in the other JRAs. There-
fore, the deliverable contains quite detailed information on contents of different WPs and tasks.
Task numbers and planned work for each of the tasks have been included.
1.2 Scope of the Document
This document presents the generic implementation plans for further work in ERIGrid WPs JRA2,
JRA3 and JRA4. Technical details of the work that will be conducted in these JRAs, as well as their
implementation are not included but will be defined later in each specific work package (e.g., de-
tails of the real-time communication interface between RIs). The purpose of this deliverable is to
select relevant test cases for the above mentioned WPs and to provide the necessary test case
documentation of the selected test cases in the format determined in WP Networking Activity 5
(NA5). The document will also define what other information, in addition to the NA5 format test
case documentation, is needed in a practical implementation plan. The detailed implementation
plans including detailed task division and exact schedules will be composed by the WPs imple-

ERIGrid GA No: 654113 02.04.2017
menting the test cases i.e., JRA2, JRA3 and JRA4. The test case selection and documentation will
serve as a starting point for this work.
This deliverable discusses the test cases for each ERIGrid JRA and also the links between tests
conducted in different WPs. The main focus of the work related to test case definitions has been on
JRA4 test cases. JRA2 test cases have already been defined as a part of the JRA2 work and will
be documented in this deliverable only briefly. JRA3 partly utilizes the same test cases as JRA4
and for some parts the detailed definition was not yet possible because some JRA3 related tasks
need to be finalized before the final test case decisions can be made. Hence, this deliverable con-
centrates especially on JRA4 test case selection and documentation.
1.3 Structure of the Document
The test case description method developed in NA5 is briefly introduced in Section 2. Section 3
discusses the test case selection process and presents the selected test cases. Section 4 maps
the selected test cases to RIs and discusses the next steps for test case implementation plans to
be conducted in JRA4. NA5 based test case descriptions are presented in the Annex.

ERIGrid GA No: 654113 02.04.2017
2 Test Case Descriptions
The ERIGrid approach and method for the description of holistic testing scenarios has been devel-
oped in WP NA5 and is utilized in the whole project to describe test cases. The description method
is presented in detail in Deliverable D-NA5.1 [1] and will be introduced only very briefly in this de-
liverable. Three concepts: System Configurations (SC), Use Cases (UC), and Test Cases (TC), are
essential in the ERIGrid scenario description method. The method provides a consistent terminolo-
gy and approach for describing multi-domain tests.
The main steps of the ERIGrid holistic testing approach are represented in Figure 2.1. Generic sys-
tem configurations have been composed in Task JRA1.1 (summarized in Deliverable D-JRA1.1 [2])
and focal use cases in Task JRA1.2 (described in Deliverable D-JRA1.2 [3]). The main focus of
this deliverable is on test case descriptions.
Figure 2.1. ERIGrid holistic testing approach
In the following, the concepts of system configurations, use cases and test cases are briefly de-
scribed from the point of view of Task JRA1.3 needs.
2.1 System Configuration
The system configuration description method offers a standard way of representing systems. Sys-
tem configurations provide information on domains, components, connectivity, constraints and at-
tributes in a system. The information can be provided in table form and/or using a standardized
graphical SC representation.
For test case implementation plans, component and connectivity information is particularly im-
portant. The graphical SC descriptions are utilized in the test case documentation.
2.2 Use case
The use case methodology is a practice for formal description and specification of functional re-
quirements of systems. Use case descriptions are constructed according to IEC 62559-2 template
[4] and define the general functionality, actors, data transfer and operational sequences of the spe-
cific function. From testing point of view, use cases specify objectives and desired behaviour of a
system so that it can be said to exhibit the named function. The use case descriptions serve as an
input for test case descriptions.

ERIGrid GA No: 654113 02.04.2017
2.3 Test Case
Test case descriptions have to be constructed as a part of test case implementation plans. The test
case description method of NA5 includes three types of specifications (see Figure 2.1): (i) test
case, (ii) test specification, and (iii) experiment specifications. The first step is to construct the test
case definition. The test case definition provides a set of conditions under which a test can deter-
mine whether or how well a system, component or one of its aspects is working given its expected
function. The RI where the test is conducted does not need to be known at the time of composing
this document and the system under test is described in a general level. The test case definitions
are constructed for all the selected WP4-related JRA4 test cases in the Annex.
The second step is constructing the test specification, which defines the specific system under test.
It also defines in more detail how the test will be conducted and which parameters of the system
will be varied and observed for the evaluation of the test objective. Several test specifications can
be linked to a test case definition. Full test specifications are not composed for the selected test
cases in this deliverable but will be constructed later in the project. However, some parts of the test
specifications are defined for some of the test cases already in this deliverable.
The last step is composing the experiment specification, which defines the experiment set-up in a
particular RI in detail. If the same test is conducted in several RIs, own experiment specifications
for each of the RIs need to be constructed. Experiment specifications are not defined in this deliv-
erable but can be considered as a part of the actual test case implementation and will be con-
structed later in the project.

ERIGrid GA No: 654113 02.04.2017
3 Test Case Selection Process
Selection of ERIGrid test cases and RIs to implement those is an essential outcome of Task
JRA1.3 and will speed-up the kick-off phase of later WPs, especially JRA4. Also, collecting all
ERIGrid test cases together enables identifying similar test objectives and possibilities for closer
collaboration between different work packages and tasks.
Thanks to the collaboration with the ERIGrid Joint Research Activities (JRA2, JRA3 and JRA4) the
most relevant test cases have been selected. This section documents the test case selection pro-
cess and also maps the selected test cases to system configurations of Task JRA1.1 and focal use
cases of Task JRA1.2. As anticipated above, the main focus in the selection process has been the
implementation and demonstration (JRA4) of the test cases. For test cases related to the simula-
tion and laboratory methods (JRA2 and JRA3 respectively), this deliverable contains only a brief
description on conceptual level; the detailed test case documentations will be included in Delivera-
bles D-JRA2.1, D-JRA3.2 and D-JRA3.3.
3.1 Selection Criteria
Test cases have been selected based on the needs of the consortium members. ERIGrid aims at
better integration of RIs and the test cases should be such that this objective can be met. Better RI
integration is needed to enable comprehensive testing of multi-domain systems and also to en-
hance the already existing single-domain testing procedures. Better integration can be achieved by
at least two means: By simplifying the process of porting an experiment from one RI to another,
e.g., by using standardized interfaces, and by enabling joint use of RIs with different capabilities
through a real-time communication between the RIs. In this document, the concept of an RI in-
cludes off-line simulation tools as well as physical laboratory infrastructure consisting of real
equipment such as generators and virtual equipment such as real-time simulators.
Research questions defined by each of the WPs JRA2, JRA3 and JRA4 are the main input for the
test case selection. They determine the test objectives for each of the selected test cases. Addi-
tionally, the previous work of JRA1 (system configurations from JRA1.1 and focal use cases from
JRA1.2) and the capabilities of different RIs are used as inputs for the selection process (ongoing
work in NA5.3). The aim is to utilize the selected test cases to address the research questions of
JRA2, JRA3 and JRA4 and, at the same time, to have a set of different testing approaches cover-
ing the range of partner interests as comprehensively as possible. The number of tested use cases
is intentionally quite low so that the work can concentrate on the research questions on RI integra-
tion instead of developing new smart grid functionalities which is not at the core of ERIGrid. The
same use cases are used for many different test cases so that the testing approaches can be de-
veloped and results of individual set-ups can be compared.
There are synergies in the test objectives and work of JRA2, JRA3 and JRA4 and the same test
cases can partly be utilized in these work packages.
3.2 Testing Approaches
ERIGrid covers all testing approaches consisting of virtual-based and/or real-world-based meth-
ods. The test set-ups can be divided into four categories: (i) pure simulation (incl. co-simulation),
(ii) Controller Hardware-in-the-Loop (CHIL) simulations, (iii) Hardware (HW) experiments, and (iv)
Power Hardware-in-the-Loop (PHIL) experiments. These testing approaches can be considered to
form a structured testing chain consisting of the following steps:
 Pure simulation: Virtual-based approaches both offline and in real-time. All aspects of the Sys-
tem under Test (SuT) are modelled using suitable software(s) and the accuracy of the results
depends on the accuracy of the utilized models. Co-simulation can be used to combine differ-
ent simulators that consider each domain-specific part of the SuT individually.

ERIGrid GA No: 654113 02.04.2017
 CHIL experiments: Real control hardware is utilized in a closed-loop simulation of the system.
Virtual-based and real-world-based approaches are combined. CHIL experiments enable more
accurate simulations in case an exact model of the controller is not available. Communication
delays, noise, execution time of algorithms etc. can be taken into account more easily than with
a pure simulation approach. CHIL experiments can also be used to verify the correct operation
of a specific control hardware.
 Hardware experiments: Open-loop testing of real components. This can be seen as the conven-
tional part of component testing and the results are mainly related to component characteristics.
 PHIL experiments: Closed-loop testing of real components. Virtual-based and real-world-based
approaches are combined. Interactions between the hardware under test and the overall sys-
tem can be studied.
The next step after the four testing approaches would be demonstration in a real operational envi-
ronment. The test cases for WPs JRA2, JRA3 and JRA4 are selected to cover all of the four testing
approaches.
3.3 Test Cases Selected for the Demonstration of ERIGrid Use Cases (JRA4 Test Cases)
The work of JRA4 will consist of three tasks. JRA4.1 will develop real-time communication between
RIs. JRA4.2 will implement the test cases defined in this deliverable. JRA4.3 evaluates the results
of previous tasks and analyses the deployment potential of the developed ERIGrid methodologies.
JRA4.1 concentrates on developing interfaces between and inside laboratories. The interface de-
velopment is based on previous work in DERri project where the first version of JaNDER (Joint
Test Facility for Smart Energy Networks with Distributed Energy Resources) interface was devel-
oped [5]. In ERIGrid, two types of real-time interfaces between RIs are foreseen:
 JaNDER Level 1 (L1) interface is based on IEC 61850 and is a further developed version of the
JaNDER interface developed in the DERri project [5]. This interface is used to transfer individ-
ual measurement data, control signals etc. from one RI to another but not the data of the whole
RI including for example static electrical network topology data.
 JaNDER Level 2 (L2) is based on CIM (Common Information Model) and is used to integrate
different services to RIs. This interface requires a CIM model of the whole RI utilizing it.
Task JRA4.2 concentrates on demonstrating and validating research infrastructure integration. The
task will include two types of test cases: In single-RI integration test cases, models, algorithms etc.
developed in one RI are used in another RI as a part of a test but real-time communication be-
tween the RIs is not needed. Single-RI test cases are also used to compare different experiment
set-ups to enable performing the same tests in different facilities. In multi-RIs integration test cas-
es, the interface development of JRA4.1 is utilized and real-time communication between the RIs is
needed.
Technical challenges identified for single-RI test cases include comparison of different testing ap-
proaches (see Section 3.2) and test set-ups, integrating third-party Software (SW) as a part of a
test case and model transfer between RIs. Four single-RI test cases have been selected and are
represented in Table 3.1. This table represents the different single-RI testing challenges that
ERIGrid addresses. The intention is to extend TC.S.1 to another use case, On-Load-Tap-Changer
(OLTC) control, which is studied also in TC.JRA2.2. This TC will be documented in detail in Deliv-
erable D-JRA2.1 and also in the JRA4 deliverables.

ERIGrid GA No: 654113 02.04.2017
Table 3.1. The selected single-RI test cases
Test Case Test Objectives Use Case

TC.S.1  Comparison of different experiment set-ups P-f and Q-V droop
Component testing at controls in battery
 Implementing each step of a structured testing chain
different RIs with differ- or PV inverter
ent set-up  Studies on the applicability of each of the set-ups
TC.S.2  Integrate third-party SW in RIs Coordinated volt-

Use of SW developed age control (CVC)
by RI1 in HW RI2
TC.S.3  Model transfer from one RI to another Aggregator of
Use of component mod- houses and other
el developed in RI1 to controllable re-
perform “multi-domain sources
system” test in RI2
TC.S.4  Allowing comparative tests of distributed control be- CVC
Test of distributed tween RIs even if some RIs do not support physical
cyber-physical system in distribution of control (centralized SCADA system)
RI1 as a monolithic set-  Establish the testing of physical distribution with
up in RI2 simulated communication as an intermediate/hybrid
testing mode between full cyber-physical simulation
on one side and full hardware experiment on the
other side
Technical challenges identified for multi-RI test cases include integration of remote software and
integration of remote simulators or hardware. The multi-RI test cases are used both to validate the
correct operation of the JaNDER interfaces developed in JRA4.1 and to demonstrate the real-time
joint operation of RIs for smart grid testing purposes. Two multi-RI test cases have been selected
and are listed in Table 3.2. The table represents the different multi-RI testing challenges that
ERIGrid addresses. The first multi-RI test case has been divided into two sub-TCs to enable test-
ing both JaNDER implementations.
Table 3.2.The selected multi-RI test cases
Test Case Test Objectives Use Case

TC.M.1  Integrate remote SW to testing TC.M.1.1: CVC
Integrate control SW run- TC.M.1.1: JaNDER L1 TC.M.1.2: state
ning in RI1 with HW RI2 TC.M.1.2: JaNDER L2 estimation
TC.M.2  Integrate remote hardware to testing CVC

Extend HW resources of
RI1 using resources of
other RIs
3.4 Test Cases Adopted in Simulations (JRA2 Test Cases)
WP JRA2 concentrates on pure simulation based methods. The main focus is on offline simula-
tions but also studies on coupling non-real-time simulators with physical devices are conducted.
The aim is to enhance co-simulation capabilities and to extend model libraries to enable compre-
hensive multi-domain simulations. The methods also allow the assessment of dedicated cyberse-
curity issues. The test cases of JRA2 have been defined as a part of JRA2 earlier work and will be
discussed in this deliverable only briefly.

ERIGrid GA No: 654113 02.04.2017
Three main research questions have been identified for JRA2 (cyclic dependencies between simula-
tors, coupling non-real-time simulators with physical devices and signal based synchronization). Simi-
larly as for JRA4 TCs, JRA2 test cases have been selected such that the identified research ques-
tions can be addressed. The selected test cases are shown in Table 3.3. JRA2 and JRA4 partly utilize
the same use cases, and it is foreseen that these work packages can also use results of each other.
Table 3.3. JRA2 test cases
Test Case Test Objectives and Implementation Use Case

TC.JRA2.1 Studied by co-simulation of a power system simulator Fault ride through
Cyclic dependencies and mosaik by means of the functional mockup interface capability of an on-
between simulators shore wind power
plant
TC.JRA2.2 Three different test set-ups: pure simulation, pure hard- OLTC control
Coupling non-real-time ware and a combination of a non-real-time simulator and
simulators with physical hardware
devices
TC.JRA2.3 Studied by co-simulation of a power system simulator CVC
Signal based synchroni- and a communication simulator, thereby using the func-
sation tional mockup interface standard
The JRA2 test cases of Table 3.3 will be defined in detail in Deliverable D-JRA2.1. A more com-
prehensive JRA2 test case will be defined later in JRA2 after the individual research questions
have been studied. The details of this test case cannot be defined yet since the outcome of the on-
going JRA2 work will affect its content.
3.5 Test Cases Selected for the Laboratory Environments (JRA3 Test Cases)
WP JRA3 concentrates on improving laboratory testing methodology and enabling better integra-
tion of RIs. The work package covers both open-loop hardware experiments and closed-loop CHIL
and PHIL experiments. The work is conducted in four tasks.
JRA3.1 aims at lowering the ICT-related barriers to access a laboratory by external users, lowering
the effort required to port experiments between facilities and simplifying the integration and testing
of new equipment at various levels of the control hierarchy. Documentation of the RIs is improved
and standardized data models and communication protocols are utilized when possible. JRA3.1
work does not include any testing needs and test cases are not defined for it. However, some of
the test cases defined for JRA4 will also serve JRA3.1 needs since, for example, integration of an
external software in an RI will be studied in JRA4. This is important also from JRA3.1’s point of
view and JRA3.1 will contribute to the development of TC.S.2.
JRA3.2 aims at analyzing and developing the new Hardware-in-the-Loop (HIL) environments in
laboratories of the ERIGrid consortium, capable of performing PHIL and CHIL validation case stud-
ies. The value of PHIL testing, as the future validation method for power system testing and ad-
vanced simulation tool for system studies, will be widely provided and used. In first steps of the
task, a questionnaire of PHIL development status and a state of the art working group in JRA3.2
has collected information from a majority of ERIGrid consortium. The status of PHIL development,
current limitations of the technology as well as expected improvements have been defined. In gen-
eral, the partners expect innovative approaches to enable the capacity of remote PHIL and integra-
tion of PHIL within a co-simulation framework. The following technical challenges limiting these
functionalities are identified:
 Loop delay due to introduction of power amplifier to the HIL interface. The loop delay may de-
stabilize and decrease the accuracy of the test. It is the main obstacle towards remote HIL.

ERIGrid GA No: 654113 02.04.2017
 Desynchronization of timeline in real-time/non-real-time simulators. It is the main obstacle

which prevents integration of PHIL into co-simulation frameworks.
 Difficulty in synchronization of timeline in power/communication interface. The power system
timeline is continuous while the communication timeline is discrete. It is also one of the obsta-
cles to the integration of PHIL into co-simulation frameworks.
 Besides the above challenges, JRA3.2 also shares the research questions of JRA2 in coupling dif-
ferent simulators, with stricter requirements, due to integration with real-time simulation and PHIL.
In order to demonstrate and validate the technical solutions proposed in JRA3.2, test cases with
PHIL testing capacity integration with co-simulation framework are being identified. The test cases
are dependent on the ongoing work of JRA3.2 and, therefore, cannot be defined in detail yet. They
will be documented in detail in Deliverable D-JRA3.2. JRA3.2 test cases share a great synergy
with the test cases of JRA2 because of similar technical challenges. On the other hand, with regard
to the implementation of multi-site PHIL and integration into co-simulation, the test cases of JRA3.2
will have similarities to JRA4 test cases TC.S.1, TC.M.1.1 and TC.M.1.2. Moreover, the test cases
will provide a general set-up towards a generalization of the proposed solutions into a standardisa-
ble methodology for PHIL testing.
JRA3.3 aims at developing harmonized laboratory-based testing procedures for small scale power
systems. The first step is to review the existing testing procedures currently implemented at partner
laboratories, mapping them to the focal use cases identified in the Deliverable D-JRA1.2. The pro-
cedures related to the same focal use case will then be compared in order to find common patterns
and possible differences in the approach.
Based on the lessons learned from the first step, the second part of the task consists of developing
harmonized lab-based validation methods, which will be implemented in the partner laboratories.
This part will take advantage of the integrated testing possibilities demonstrated by the test cases
proposed in this deliverable. For example, the testing chain proposed in TC.S.1 will be used as a
method for assessing and extending the validity of holistic testing results.
JRA3.4 evaluates the results of previous tasks and combines the results of JRA3 and JRA2. It
does not have testing needs of its own.
3.6 Mapping to Focal Use Cases and System Configurations
The test cases were selected based on research questions of WPs JRA2, JRA3 and JRA4 but also
trying to cover a wide range of the system configurations defined in JRA1.1 and system services
defined in JRA1.2. Table 3.4 represents the mapping between the selected test cases, focal use
cases from JRA1.2 and system configurations from JRA1.1.
Table 3.4. Mapping between test cases, focal use cases and system configurations
Test Cases Connected Focal System Services System Configura-

Use Case
(JRA1.3) Use Cases (JRA1.2) (JRA1.2) tions (JRA1.1)
P-f and Q-V TC.S.1 SS4.SC1 Management SS4 Power system SC1 Distribution grid
droop con- of flexible DERs for the stability SC3 Vertical integra-
trols in bat- instantaneous ac- tion
tery or PV tive/reactive power bal-
inverter ancing of microgrid in
island-mode
SS4.SC3 DERs support
in Frequency Contain-
ment Control and power
system inertia

ERIGrid GA No: 654113 02.04.2017
Test Cases Connected Focal System Services System Configura-

Use Case
(JRA1.3) Use Cases (JRA1.2) (JRA1.2) tions (JRA1.1)
Coordinated TC.S.2, SS3.SC1 Advanced volt- SS3 Power quality SC1 Distribution grid
Voltage TC.S.4, age control of distribution SS2 Energy efficiency SC3 Vertical integra-
Control CVC) TC.M.1.1, grids supported by DERs tion
TC.M.2, power interfaces
TC.JRA2.3 SS3.SC3 Transmission
network voltage quality
support by the distribu-
tion network (VPP)
SS2.SC1 Optimal distri-
bution network control
for the reduction of sys-
tem energy losses
Aggregator TC.S.3 SS1.SC3 Automatic Fre- SS3 Power quality SC3 Vertical integra-
of houses quency Restoration Re- tion
and other serve from DERs
controllable
resources
State TC.M.1.2 SS2.SC1 Optimal distri- SS2 Energy efficiency SC1 Distribution grid
estimation bution network control SS3 Power quality SC2 Transmission
for the reduction of sys- network and offshore
SS5 Infrastructure
tem energy losses wind
integrity, protection
SS2.SC2 Optimal trans- and restoration SC3 Vertical integra-
mission network man- tion
agement level for system
energy losses reduction
SS2.SC3 Incentivising
distribution network (mi-
crogrid) local balancing
to minimize transmission
network loading
SS3.SC1 Advanced volt-
age control of distribution
grids supported by DERs
power interfaces
SS3.SC3 Transmission
network voltage quality
support by the distribu-
tion network (VPP)
SS5.SC1 Fault detection
and corrective manage-
ment of distribution grid
assets and energetic
resources
Fault ride TC.JRA2.1 SS4.SC2 VSC-based SS4 Power system SC2 Transmission
through large wind farms support stability grid and offshore
in Frequency Contain- SS5 Infrastructure wind
ment Control and power integrity, protection,
system inertia and restoration
OLTC control TC.JRA2.2, SS3.SC1 Advanced volt- SS3 Power quality SC1 Distribution grid
possibly also age control of distribution
TC.S.1 grids supported by DERs
power interfaces

ERIGrid GA No: 654113 02.04.2017
4 General Requirements for Test Case Implementation Plans
Test cases of WPs JRA2, JRA3 and JRA4 were discussed in Section 3 at a general level. This
section will discuss the JRA4 test cases (also utilized in JRA3.1 and JRA3.3) in more detail and
initiate the work of composing implementation plans for them. JRA2 and JRA3.2 test cases and
their implementation plans will be composed as a part of JRA2 and JRA3 work. At first, the con-
tents of an implementation plan are briefly discussed. Some parts of the implementation plans are
conducted as a part of JRA1.3. Some parts of the implementation plans can be considered as a
part of the actual test case implementation and will be composed at the beginning of JRA4.
4.1 Content of an Implementation Plan
Detailed implementation plans need to be constructed for ERIGrid test case implementation phase
of JRA4. These implementation plans will divide the work to smaller pieces and assign responsible
partners for each of the identified tasks. Also a schedule for the tasks needs to be determined. The
detailed implementation plans will contain information on at least the following items for each of the
test cases and experiment set-ups:
 Participating RIs and their roles in the test

 Test case descriptions according to NA5 templates (test case, test specification, experiment
specification [1])
 Needed devices, data transfer, algorithms and models cross-checked with RI capabilities
 Steps needed to implement the test case
 Responsible partner for each of the steps
 Schedule
This deliverable will concentrate on the first two points. The test cases are mapped to RIs (see
Section 4.2). Preliminary evaluation of the feasibility of each of the test cases in the selected RIs
has been conducted as a part of JRA1.3 work. First descriptions of each of the RIs are represented
in [6] and all partners have evaluated their ability to participate to the selected TCs. More detailed
RI data will be available also in written form after laboratory descriptions of NA5.3 (i.e., Deliverable
D-NA5.2) and JRA3.1 (i.e., Deliverable D-JRA3.1) are available.
The test case descriptions are documented in the annex of this report. The descriptions in this de-
liverable contain the information related to the test case template of NA5. Test specifications and
experiment specifications require quite detailed information on the actual implementation and will
be composed at the beginning of JRA4. Some parts of these documents are, however, already in-
cluded in this deliverable for those test cases where the required information is already available.
The remaining parts of the implementation plans for each of the test cases will be composed at the
beginning of JRA4. The work will start by constructing the test specifications and experiment speci-
fications for each of the test cases and experiment set-ups. Then, the full test case descriptions
including system configurations as a part of them and the information on the participating RIs serve
as a starting point for the remaining parts of the detailed implementation plans. System configura-
tions provide information on the required components and connectivity. NA5.3 RI database pro-
vides information on the available laboratory components and data transfer possibilities and
JRA3.1 elaborates the RI descriptions to a more detailed level.
4.2 Test Case Mapping to RIs
The roles of different partners in each of the test cases have been defined as a part of JRA1.3
work. These selections are preliminary and some changes might be necessary during JRA4 execu-
tion. Brief descriptions of each test case and partner roles in each of them are represented in the
following sections. The detailed test case descriptions for all the selected test cases are represent-
ed in the Annex of this deliverable.

ERIGrid GA No: 654113 02.04.2017
4.2.1 TC.S.1: Component Testing at Different RIs with Different Set-up
The aim of TC.S.1 is to implement the same test case with all four testing approaches presented in
Section 3.2. The selected use case is P-f and Q-V droop controls in a battery or a PV inverter and
each of the testing approaches is implemented by several RIs. Therefore, comparison both be-
tween the different testing approaches and between the different experiment set-ups can be made.
The results can be used to evaluate, for example, in which cases HW tests are needed and where
CHIL experiments can replace them. Test set-ups with real power and/or control hardware can al-
so be used to improve the component models for set-ups where they are represented by models.
TC.S.1 is used both by JRA3.3 and by JRA4.
The system under test consists of the electrical grid, physical storage or PV system including the
power electronics as well as the converter controller (main building blocks of the test system are
represented in Figure 4.1). Depending on the test set-up, either models or physical components
are used to represent the different parts of the test system. Figure 4.2 illustrates some of the char-
acteristics of different testing approaches and some interactions between the different set-ups.
Grid
Control hardware
Measurements Converter
(V, f) controller
Control signals
AC DC Storage
DC DC or PV
Power hardware
(converter and storage or PV)
Figure 4.1. System under test of TC.S.1
Pure simulation CHIL Pure HW PHIL

Large systems with a
multitude of storages or V, f time series for
PV units can be studied playback (from any of
the three other set-ups)
Grid Grid Grid Grid
V,f V,f Closed V,f Open loop V,f Closed

P,Q P,Q P,Q loop
loop
Converter Converter Converter Converter

controller controller controller controller
Storage/PV and Storage/PV and Storage/PV and Storage/PV and

power electronics power electronics power electronics power electronics
Real system operation to

improve controller model
Represented by a model
Real system operation to improve
controller and component models
Physical component
Figure 4.2. TC.S.1 testing approaches

ERIGrid GA No: 654113 02.04.2017
Mapping of different TC.S.1 experiment set-ups to RIs is presented in Table 4.1.
Table 4.1. TC.S.1 mapping to RIs
Experiment Set-up Responsible Partners

Pure simulation (Matlab/Simulink, Battery or/and PV inverter) RSE, TEC, ICCS, OFF
CHIL (algorithms in a hardware controller and the model of the con- AIT, ICCS, GINP
verter and distribution grid model simulated in a real time simulator)
Pure HW experiment (real controller and converter, open-loop test) RSE, IWES, ICCS, TEC
PHIL (real time simulator runs a distribution grid model, real controller UST, AIT, SIN, ICCS
and converter in a closed-loop test)
In addition to the above described use case, there are also plans to deploy OLTC control use case
as a second implementation of TC.S.1.
4.2.2 TC.S.2: Use of SW Developed by RI1 in HW RI2
The aim of TC.S.2 is to integrate software developed in one RI to another RI. The SW will be run at
the RI that is running the test and no real-time communication between the RIs is needed. The se-
lected use case is coordinated voltage control. The basic idea of TC.S.2 is represented in Figure
4.3. The CVC algorithm developed by RI1 is integrated as a part of the lab SCADA of RI2. The test
case aims at developing methods to simplify third-party SW integration in RIs. It also allows testing
of SW packages in HW of different RIs.
CVC –from RI1 SCADA
RI2
Figure 4.3. TC.S.2 basic idea
Mapping of TC.S.2 roles in RIs is represented in Table 4.2. Two types of CVC algorithms might be
used in tests but the final decision whether to also implement the simple rule-based algorithm will
be done at the beginning of JRA4.

ERIGrid GA No: 654113 02.04.2017
Role Responsible Partner(s)

Developer of CVC software ICCS (optimizing algorithm)
VTT (simple rule-based if needed)
RI using CVC software RSE, AIT
4.2.3 TC.S.3: Use of Comp. Model Devel. in RI1 to Perf. “Multi-domain System” Test in RI2
The aim of TC.S.3 is to study model transfer between different RIs. The selected use case is aggrega-
tor of houses and other controllable resources. The intention is to use a distributed multi-agent based
aggregator algorithm similar to [7] (the detailed implementation will be defined later as a part of JRA4
work). It is assumed that a physical house is not available for testing and, therefore, the houses are
represented by a model. The house model is developed in one RI and transferred to another to be
used as a part of testing. The main parts of the system under test are represented in Figure 4.4.
Aggregator
central agent Electrical
ICT/control
Aggregator
distributed
House
(modelled)
Aggregator
distributed
Controllable
resource 1
… Aggregator
distributed
Controllable
resource N
agent agent agent
Figure 4.4. TC.S.3 system under test
Mapping of TC.S.3 roles in RIs is represented in Table 4.3. The house model is developed in one
RI and the aggregator algorithm in another RI. Two different test set-ups are implemented. The first
one is a pure simulation case and the second one a lab set-up. The physical controllable resources
differ between the labs and, so all experiment set-ups will be different, even for the same test sys-
tem, which will enable to evaluate the quality of test replication in different RIs. Alternatively, also
the test system configuration can be varied to address different test criteria, for example to allow
for scalability assessments of the aggregator algorithms, by using several instances of the house
model in a co-simulation setup.

Developer of the model (PowerFlexhouse) DTU
Developer of the aggregator algorithm OFF
RI using the model in a pure simulation set-up OFF, CEA
RI using the model in a lab set-up RSE, SIN, CEA, UST

ERIGrid GA No: 654113 02.04.2017
4.2.4 TC.S.4: Test of Distr. Cyber-Physical System in RI1 as a Monolithic Set-up in RI2
The aim of TC.S.4 is to study how different RI implementations affect testing of communication re-
lated characteristics of a use case and to develop testing methods that enable more realistic repre-
sentation of the communication infrastructure in different types of RIs. Two different test set-ups
are implemented. The first one is suitable for RIs with physically distributed control resources
where communication can be represented corresponding to the situation in real implementations.
The second one is designed for RIs where the characteristics of communication channels cannot
be altered (RIs with central SCADA). In this test case, the communication network characteristics
are added using an ICT simulator.
The selected use case is coordinated voltage control implemented in a monolithic controller. The
CVC algorithm implementations of TC.S.2 can be used also in this test case. The operational prin-
ciple of the test set-up with physically distributed control resources is represented in Figure 4.5 and
for the set-up with the central SCADA in Figure 4.6. The figures represent a very simple case
where a transformer tap changer is the only controllable resource but the operational principle re-
mains the same even when the amount of controllable resources increases.
Smart meter
Smart meter
Tap changer
controller
Input
Control measurements
signal
CVC
X Hardware + software
Figure 4.5. TC.S.4 test set-up with physically distributed resources (characteristics of the blue and red com-
munication channels can be altered to correspond to the situation in a real network implementation)
Mapping of TC.S.4 roles in RIs is represented in Table 4.4.
Experiment Set-up Responsible Partner

Physically separated components and real communication between DTU
them (real IEDs and a central controller, etc.)
Physically separated components with all control processes executing in OFF

one location and simulated (or neglected) communication between them

ERIGrid GA No: 654113 02.04.2017
Smart meter 1
Smart meter 2
Tap changer
controller
Input
Control measurements
signal Lab
SCADA
Hardware
Software
TCC Simulated SM1 processes
communication
CVC SM2
Communication simulator
and CVC algorithm
Figure 4.6. TC.S.4 test set-up with central SCADA (characteristics of the blue and red communication chan-
nels as well as the properties of the SCADA system cannot be altered; the characteristics of the communica-
tion channels are taken into account in the simulated communication (orange arrows))
4.2.5 TC.M.1: Integrate Control SW Running in RI1 with HW RI2
The aim of TC.M.1 is to test local control software against power system hardware at another RI.
The test case is somewhat similar to TC.S.2. The difference is that in TC.S.2 the third-party SW is
integrated as a part of the RI conducting the test but in TC.M.1 the SW runs at a remote RI and
real-time communication between the RIs is needed. TC.M.1 has been divided into two different
cases having a different implementation of the real-time communication between the RIs.
TC.M.1.1 uses JaNDER L1 and the selected use case is coordinated voltage control. The CVC
algorithm runs at a remote RI1 and sends control commands to the controllable resources of RI2.
The basic idea of TC.M.1.1 is represented in Figure 4.7.
Mapping of TC.M.1.1 roles in RIs is represented in Table 4.5.
Table 4.5. TC.M.1.1 mapping to RIs

RI1 running the CVC algorithm ICCS
RI2 with grid model and/or hardware devices RSE, TUD, GINP, AIT, CEA

ERIGrid GA No: 654113 02.04.2017
CVC RI1
Jander-L1
RI2
Figure 4.7. TC.M.1.1 basic idea
TC.M.1.2 utilizes JaNDER L2 and the selected use case is state estimation. The state estimation
algorithm runs at remote RI1. It receives necessary input data from RI2 through JaNDER L2 inter-
face, calculates the state estimate and returns the result to RI2. The basic idea of TC.M.1.2 is rep-
resented in Figure 4.8.
State
Estimator
RI1
Jander-L2
SCADA EMS
RI2
Figure 4.8. TC.M.1.2 basic idea

ERIGrid GA No: 654113 02.04.2017
Mapping of TC.M.1.2 roles in RIs is represented in Table 4.6.
Table 4.6. TC.M.1.2 mapping to RIs
Role Responsible partner(s)

RI running the state estimation algorithm RSE
RI with grid model and/or hardware devices ICCS, GINP, CEA
4.2.6 TC.M.2: Extend HW Resources of RI1 Using Resources of Other RIs
The aim of TC.M.2 is to integrate remote hardware as a part of testing. When utilizing remote HW
is possible, a wider range of tests can be performed without a need for additional investments in
new HW. The test case also enables integrating remote real systems behaviour as a part of real-
time grid simulation and, therefore, system testing of components located in RIs that do not contain
a HIL capable simulator can be performed.
The selected use case is coordinated voltage control and the algorithms developed for TC.S.2 can
be utilized. In the test set-up, RI1 simulates a distribution network using a real-time simulator, and
simulates DSO operations by performing voltage control in this network using the CVC algorithm.
Other RIs represent smaller parts of the network that are locally controlled by an EMS (Energy
Management System) algorithm i.e., microgrids. The centralized CVC algorithm utilizes the control-
lable resources of the microgrids as a part of its pool of flexible resources, by exchanging real and
reactive power measurements and set points with the microgrids. The experiment set-up corre-
sponds to a control architecture that can also be used in real network hierarchical implementations
of CVC. The operational principle of TC.M.2 is represented in Figure 4.9.
Grid simulator RI1
Jander-L1
P,Q set P,Q set
points points
Available and
actuated P&Q
RI2 RI3
Real microgrids
Figure 4.9. TC.M.2 basic idea
Mapping of TC.M.2 roles in RIs is represented in Table 4.7.

ERIGrid GA No: 654113 02.04.2017
Table 4.7. TC.M.2 mapping to RIs
Role Responsible Partners

RI1 with grid simulator and CVC algorithm UST, TUD
RI2 & RI3 representing a part of the network VTT, TEC, RSE, DTU, UST

ERIGrid GA No: 654113 02.04.2017
5 Conclusions
This deliverable concludes the work of JRA1. The objective of JRA1 was to identify which types of
testing needs are relevant for smart grid system development. This information is needed in order
to define in detail which services offered by the current RIs have to be extended and improved.
Besides, it identifies new services which have to be developed in order to satisfy the needs of ad-
vanced users. The work of JRA1 started with the development of generic system configurations
(JRA1.1) which provide a context for ERIGrid testing. In JRA1.2 the work proceeded to defining
focal use cases which cover the whole range of smart grid activities relevant to ERIGrid. JRA1.1
and JRA1.2 defined the most relevant testing scenarios for ERIGrid at an abstract level, outlining
the most important areas of smart grid testing. The work of JRA1.3 differed from the first two tasks
in that the aim was to define concrete test cases which will be implemented in subsequent work
packages of ERIGrid. Hence, the whole smart grid testing domain could not be covered but a sub-
set of test cases was selected to be implemented in ERIGrid RIs.
This deliverable introduces the test cases that will be implemented as a part of JRA2, JRA3 and
JRA4. The test cases have been selected based on key research questions identified by the above
mentioned work packages. For JRA4, the considered test cases have been mapped to RIs and test
case definitions have been composed according to the NA5 description method. This work lays down
the basis for further work in JRA4 and strengthens collaboration between JRA2, JRA3 and JRA4.

ERIGrid GA No: 654113 02.04.2017
6 References
[1] Deliverable D5.1, „D-NA5.1 Smart grid configuration validation scenario description method,“
H2020 ERIGrid project, 2017.
[2] Deliverable D7.1, „D-JRA1.1 ERIGrid scenario descriptions,“ H2020 ERIGrid project, 2016.
[3] Deliverable D7.2, „D-JRA1.2 Focal use case collection,“ H2020 ERIGrid project, 2016.
[4] „IEC 62559: Use Case Methodology,“ International Electrotechnical Commission (IEC),
Geneva, Switzerland, 2015.
[5] Deliverable D1.4, „Handbook of JaNDER laboratories: Components and interfaces,“ FP7 DERri
project, 2012.
[6] Deliverable D3.1, „D-NA3.1 General rules for the ERIGrid trans-national access,“ H2020
ERIGrid project, 2016.
[7] A. Niesse und M. Tröschel, „Controlled self-organization in smart grids,“ in IEEE International
Symposium on System Engineering, 2016.

ERIGrid GA No: 654113 02.04.2017
7 Annex
7.1 List of Figures
Figure 2.1. ERIGrid holistic testing approach .................................................................................. 9

Figure 4.1. System under test of TC.S.1 ....................................................................................... 18
Figure 4.2. TC.S.1 testing approaches .......................................................................................... 18
Figure 4.3. TC.S.2 basic idea ........................................................................................................ 19
Figure 4.4. TC.S.3 system under test ............................................................................................ 20
Figure 4.5. TC.S.4 test set-up with physically distributed resources (characteristics of the blue and
red communication channels can be altered to correspond to the situation in a real network
implementation) ..................................................................................................................... 21
Figure 4.6. TC.S.4 test set-up with central SCADA (characteristics of the blue and red
communication channels as well as the properties of the SCADA system cannot be altered;
the characteristics of the communication channels are taken into account in the simulated
communication (orange arrows))............................................................................................ 22
Figure 4.7. TC.M.1.1 basic idea .................................................................................................... 23
Figure 4.8. TC.M.1.2 basic idea .................................................................................................... 23
Figure 4.9. TC.M.2 basic idea ....................................................................................................... 24
7.2 List of Tables
Table 3.1. The selected single-RI test cases ................................................................................. 13

Table 3.2.The selected multi-RI test cases.................................................................................... 13
Table 3.3. JRA2 test cases ........................................................................................................... 14
Table 3.4. Mapping between test cases, focal use cases and system configurations .................... 15
Table 4.1. TC.S.1 mapping to RIs ................................................................................................. 19
Table 4.5. TC.M.1.1 mapping to RIs.............................................................................................. 22
Table 4.6. TC.M.1.2 mapping to RIs.............................................................................................. 24
Table 4.7. TC.M.2 mapping to RIs ................................................................................................ 25

ERIGrid GA No: 654113 02.04.2017
7.3 Test Case Descriptions
The test case descriptions for each of the selected JRA4 test cases are represented here. JRA2
and JRA3 test case documentation is developed in those work packages and will be documented
in Deliverables D-JRA2.1, D-JRA3.2 and D-JRA3.3.
7.3.1 TC.S.1: Component Testing at Different RIs with Different Set-up
The test case description of TC.S.1 is presented below.
Name of the test case TC.S.1. Component Testing at Different RIs with Different Set-up
Narrative The purpose of this test case is the comparison of P-f and V-Q droop control
characteristics, between pure simulation, pure hardware or hybrid (CHIL
and/or PHIL) set-ups. Test results are expected to differ due to the different
RIs’ approaches to testing as well as due to the set-ups. The tests can also
be used to validate and adjust component simulation models against their
physical counterparts. A general scheme of the TC is shown below.
The PV/storage element is connected to a DC/DC converter, responsible for

controlling the voltage on the DC bus. In the distribution grid, voltage and cur-
rent measurements are acquired through a SCADA system and processed in
order to get the current values of P and Q injections. The PQ measurements
are compared with the PQ set-points in order to define the reference voltage
and frequency that are used to generate the gate signals for switching the
inverter’s IGBTs.
System under Test The system under test (SuT) is comprised of the inverter (DC/AC) and the in-
(SuT) verter controller, as well as the distribution grid because of the direct impact of
the control over the grid. The inverter is in charge of regulating the active and
reactive power that the PV or the storage system is able to provide to the distri-
bution grid. The voltage on the DC bus is regulated by means of a DC/DC
converter which provides the DC voltage on the bus to be used by the inverter.
Object under Inves- The object under investigation (OuI) is the inverter controller that is responsi-
tigation (OuI) ble of the P-f, Q-V droop controls.
Domain under In- Domains & Subdomains:

vestigation (DuI) ● Electrical system
 Distribution network (DER)
● Control system

ERIGrid GA No: 654113 02.04.2017
 Local control
● ICT
 Communication system
 Measurement system
 Data management
The generic system configuration diagram showing the connectivity of the

different domains is shown in the figure below.
Functions under Test The functions to be tested within this TC (P-f & V-Q droop controls) can be
(FuT) used in many UCs of interest within ERIGrid. Among the focal UCs selected
by the project, the droop control functions are relevant for:
 SS4.SC1: Management of flexible DERs for the instantaneous ac-

tive/reactive power balancing of microgrid in island mode.
 SS4. SC3: DERs support in frequency containment control and power
system inertia.
Function(s) under P-f (or ω) and Q-V droop control functions.

Investigation (FuI)

ERIGrid GA No: 654113 02.04.2017
Purpose of Investigation With a correct testing of the droop algorithms, several testing objectives can
(PoI) be achieved:
1) The simulation models can be validated with the results of the real
component testing.
2) The differences due to the set-ups can be detected and evaluated
3) The suitability or adequacy of pure simulation, pure hardware or hybrid
approaches can be determined.
Test criteria The satisfaction of the test is achieved if the same test performed within dif-
ferent RIs with the same set-up leads to similar results, only deferring due to
some quality criteria agreed (e.g. reaction time of the controller).
target metrics  Successful integration of the simulated and the emulated parts of the sys-
(criteria) tem to evaluate the same control functions
 Comparison of the models behaviour in case of simulated components
 Comparison of the behaviour in case of open-loop tests and closed-loop tests
variability attributes  Variation of the power injection by the PV or the storage system
(test factors)  Droop (slope)
 Voltage level in the DC bus
quality attributes To be defined (according to the PoI)

(thresholds)
Test specification and experiment specifications will be composed at the beginning of JRA4.
7.3.2 TC.S.2: Use of SW Developed by RI1 in HW RI2
Name of the test case TC.S.2 Use of SW Developed by RI1 in HW RI2
Narrative The purpose of this test is the demonstration of Hardware/Software integra-

tion between different RIs. To this end the target controller is a Coordinated
Voltage Control algorithm. The relevant focal use cases describing such a
controller are reported in Table 3.4. Specifically, this test case regards the
use of a CVC SW controller developed by one partner (RI1) in the RI of an-
other partner (RI2) without involving any real-time communication between
the two parties. In other words, the controller will be installed in the second
partner’s infrastructure (i.e. SCADA) in order to investigate the performance
of the RI2 resources under the control functionalities of the RI1’s software.
System under Test In the following diagram an overview of the SuT is provided. This includes the
(SuT) electrical system of RI2, e.g. an LV microgrid which incorporates various con-
trollable micro-generators (PVs, batteries, micro-turbines) and loads. Each
unit is equipped with a local control module (device or control function of the

ERIGrid GA No: 654113 02.04.2017
interconnection inverter) which allows for voltage control at the connection

point of each unit. The control of the voltage level is obtained by external set-
points specified by the SCADA system. Between the SCADA system and lo-
cal controllers, communication channels allow for the transmission of data
regarding the setpoints and the measurement of the actual voltage, power, or
other electrical parameters. Last but not least, the Object under Investigation
is the piece of SW performing the Coordinated Voltage Control strategy. The
CVC module is attached to the SCADA system of RI2 and makes use of the
input signals (either direct measurements or processed data) in order to cal-
culate the setpoint(s) of primary controllers that are specified by the control
objectives. The setpoint values are communicated to the SCADA system
which then relays them to the individual units. It is worth noting that the exter-
nal interactions of the system include the interconnection to the MV distribu-
tion grid (if the interconnection switch is closed) as well as the environmental
conditions that determine the behaviour of specific units such as PVs (solar
irradiance, temperature), batteries (temperature) etc.
Object under Inves- The OuI for this test case is the SW controller which performs CVC. The OuI
tigation (OuI) is a centralised controller which means that it is directly connected to the
SCADA system (by contrast with a distributed approach in which it could con-
sist of several agents connected to each local controller). The input signals
depend on the control objectives and may involve direct measurements of
electrical quantities such as voltages, currents, powers etc. or processed
quantities calculated by the SCADA system such as power loss, cost etc. The
output signals are setpoints of primary controllers that the local controllers
should follow in order to satisfy the control criteria.
Domain under In- The DuIs of this test case are electric power and ICT.
vestigation (DuI)

ERIGrid GA No: 654113 02.04.2017
Functions under Test The FuTs of this test case include the CVC algorithm, the local controllers
(FuT) and measurement devices and the communication via ICT.
The specific test case involves functions related to the focal UCs:
 SS3.SC1 “Advanced voltage control of distribution grids supported by

DERs power interfaces”
 SS3.SC3 “Transmission network voltage quality support by the distribu-
tion network (VPP)”
 SS2.SC1 “Optimal distribution network control for the reduction of system
energy losses”
The relevant services specified for these use cases regard Power Quality
(SS3) and Energy Efficiency (SS2) whilst the relevant system configurations
are Distribution Grids (SC1) and Vertical Integration (SC3).
Function(s) under The FuI of this test case is the integration of the CVC algorithm as a part of
Investigation (FuI) the test set-up in RI2.
Purpose of Investigation The PoI for this test case is a combination of Characterisation and Validation
(PoI) because the test requirements deal with the demonstration of integration of
the third-party (RI1) SW (characterisation) as well as the optimal operation of
the RI2 resources (validation based on qualitative test criteria).
Test criteria The aspect of SW integration of a third-party SW controller can be considered

as the main criterion for success of the test. The assessment of the success
implementation can be shown by means of the correct (but not necessarily
optimal) operation of the controller in terms of signals acquisition, internal cal-
culations and setpoint dispatching. The criteria to quantify the specific func-
tionalities and optimal operation of CVC can be specified only once the CVC
control algorithm has been specified and designed.
target metrics  Successful functioning of the SW controller and interaction with the RI2
(criteria) SCADA system
 Successful modification of primary controller setpoints at points of the
local grid
variability attributes  Load variations. The variation of loads should be between zero and nom-
(test factors) inal power.
 Environment variations such as solar irradiance on PVs. The solar irradi-
ance should vary from zero to 1000W/m2
 Connection/disconnection of resources and grid components such as in-
ductors/capacitors. The maximum reactive power consumed/produced by
these components should be at least some hundreds of VAr.
7.3.3 TC.S.3: Use of Comp. Model Devel. in RI1 to Perf. “Multi-domain System” Test in RI2
Name of the test case TC.S.3 Use of Component Model Developed in RI1 to Perform “Multi-
domain System” Test in RI2
Narrative The main purpose of the test is to validate control software integration testing
by means of model transfer between different RIs: instead of transferring the
control software to another RI (TC.S.2), component models are transferred to
evaluate the control software in RI2. The selected control algorithm is an ag-

ERIGrid GA No: 654113 02.04.2017
gregator algorithm. The aggregator controls different types of resources

(houses and other controllable resources) based on its optimization targets. It
is assumed that a physical house is not available for testing and, therefore,
the houses are represented by a model.
The house model development and validation is conducted as one test set-up
at RI1. The aggregator validation test is conducted in other RIs (RI2) using
two alternative set-ups: pure simulation set-up and lab set-up. The simulation
case is an offline set-up where the purpose is to demonstrate model ex-
change and co-simulation between different simulation softwares. The lab set-
up demonstrates inclusion of models as a part of a real-time operating set-up
including also physical components. The output of the model has to be repre-
sented correctly in the lab set-up.
System under Test The SuT consists of the aggregator software, the house model, other availa-
(SuT) ble controllable resources, the electrical network connecting the resources
and the ICT network connecting the different software components.
Object under Inves- The OuIs for this test case are the aggregator function (for final test in RI2)
tigation (OuI) and the house for modeling (in RI1).
Domain under In- The DuIs of this test case are electric power and ICT and thermal domain (in-
vestigation (DuI) cluded in the house model).
Functions under Test The FuTs of this test case include the house model, central and distributed
(FuT) parts of the aggregator algorithm, communication functionality between the
aggregator parts and the DER local controllers.
 SS1.SC3 Automatic Frequency Restoration Reserve from DERs
Function(s) under The FuIs of this test case are the house model transfer to RI2 and the aggre-
Investigation (FuI) gator functionality consisting of centralized and distributed parts. The aggre-
gator algorithm FuI relates to an optimization criterion for the aggregation de-
pending on a specific use case.

ERIGrid GA No: 654113 02.04.2017
Purpose of Investigation The PoI for this test case is a combination of characterization and validation.
(PoI) The test case aims at (1) demonstrating model development and transfer
(characterization); (2) successful integration of the model into a (co-
)simulation environment and concordance with the expected behavior of the
model (functional verification); and (3) evaluating the operation of the aggre-
gator functionality on qualitative criteria (validation).
Test criteria The main criteria for success of the test are aspects related to successful uti-
lization of the house model as a part of the validation of aggregator functional-
ity. The quality of the house model itself can be evaluated comparing the sim-
ulation with measurements of the real house where the data should be inde-
pendent from the “training data” (PoI 1). The quality of the house model as a
part of the test case can be evaluated by comparing original house model
simulation results from the model development phase to the house model
operation as a part of the test case (PoI 2). The first criterion for the integra-
tion test of the aggregator functionality is to have a functioning implementation
of and communication between the different aggregator parts. The second
criterion is to evaluate the optimality of the aggregator operation. (PoI 3)
Two separate test specifications need to be composed for TC.S.3. The first test specification ad-
dresses the house model development and the second one aggregator function validation. The
detailed test specifications will be composed at the beginning of JRA4 but some preliminary ideas
are documented already in this deliverable.
The test specification for house model development is presented below.
Title TS.S.3.1 House Model Development
Ref. Holistic test case TC.S.3 (1)
Test System The test system documentation will be conducted as a part of JRA4 work.
(also graphical)
Target measures  House model quality (uncertainty quantified)
Input and output pa- Controllable input parameters:

rameters
 Setpoints for house heating system
Uncontrollable input parameters:

 External parameters, such as Wind, Insolation, etc.
Measured parameters:
 House model parameters (temperature, real and reactive powers etc.)
The test specification for aggregator function validation is presented below.
Title TS.S.3.2 Aggregator Function Validation
Ref. Holistic test case TC.S.3 (2)
Test System The test system documentation will be conducted as a part of JRA4 work.
(also graphical)
Target measures  Successful utilization of the house model as a part of the test case
 Successful integration of the centralized and distributed aggregator

ERIGrid GA No: 654113 02.04.2017
agents as a part of the test case

 Comparison of the house model operation between the model develop-
ment test and this test
 Aggregator operation optimality

rameters
 Input signal for the aggregator centralized agent
 Real and reactive powers of loads, generators and storage units i.e. load-
ing and production conditions in the network
· Uncontrollable input parameters:

 State of the house model (e.g. temperature)
 State of charge of possible storage units
 House model parameters (temperature, real and reactive powers etc.)
 Aggregator parameters (control actions of each agent, communicated
messages between the agents, optimization target function values etc.)
 Real and reactive powers of all the controllable resources
 State of charge of possible storage units·
Three types of experiment specifications need to be constructed for this test case. The first one is
related to TS.S.3.1 and describes the experiment set-up for the house model development test.
This test is conducted at DTU SYSLAB. The two following are related to TS.S.3.2 and describe the
two alternative experiment set-ups for the aggregator function validation test. The simulation set-up
will be described as one experiment specification. The same set-up will be used in both RIs imple-
menting the test (OFF, CEA) and, therefore, one experiment specification for the simulation set-up
will be adequate. The lab set-up combines real lab hardware, the house model and the aggregator
implementation. The experiment set-ups will have differences between RIs depending on the
available physical resources, possibilities to implement the aggregator agents etc. and, therefore,
own experiment specifications will be composed for all four RIs (RSE, CEA, SIN, UST) implement-
ing the aggregator function validation test in their labs.
7.3.4 TC.S.4: Test of Distr. Cyber-Physical System in RI1 as a Monolithic Set-up in RI2
Name of the test case TC.S.4 Test of Distributed Cyber-Physical System in RI1 as a Monolithic
Setup in RI2
Narrative The purpose of the test is to demonstrate the performance testing of distribut-
ed controllers in RIs with different architectures. In real network distributed
control applications, the characteristics of communication channels (band-
width and latencies, but also error rates and disturbance characteristics) af-
fect the operation of the controller. In testing, the effect has often been ig-
nored and communication channels have been assumed to be very reliable
and fast which is not always the case. This test aims at developing testing
methods that enable a more realistic representation of the communication
infrastructure in different types of RIs. In RIs with the capability to physically
distribute control resources, communication can be represented correspond-
ing to the situation in real implementations and the characteristics of the
communication channels can be altered. In RIs with a centralized SCADA
system, the communication channels to and from the SCADA are very fast
and reliable. Their characteristics cannot usually be altered.

ERIGrid GA No: 654113 02.04.2017
This test is conducted using two test set-ups. A reference test is conducted at
an RI at which physically distributed deployment of control resources is possi-
ble. The second test is conducted at an RI where communication channels
reading measurements and sending control commands cannot be modified to
resemble the real situation (RI with centralized SCADA). At this RI, the SCADA
system is augmented with a communication simulator in order to emulate the
communication network characteristics of the physically distributed set-up.
The selected use case is coordinated voltage control (CVC). In the case under
consideration, the control algorithm is implemented in one controller which
needs to communicate with meter controllers providing and preprocessing input
data, as well as with resource controllers (e.g. an OLTC controller) in order to
physically affect the grid. The CVC algorithm reads measurement data from the
electrical network and controllable resources, solves an optimal power flow
problem and emits new setpoints in order to optimize the network state.
System under Test The SuT consists of the distribution network, the CVC algorithm, the control-
(SuT) lable devices (transformer OLTC, DG units, storages etc.), local controllers
and measurement devices (OLTC controller, DER controllers, smart meters
etc.) and the communication network.
Object under Inves- The OuI for this test case is the characteristic of the simulated communication
tigation (OuI) network in RI2, the difference in behaviour versus the physical network in RI1,
and the impact of this difference on the performance of the CVC controller.
Domain under In- The DuIs of this test case are electric power and ICT domains.
vestigation (DuI)
Functions under Test The FuTs of this test case include the CVC algorithm, the local controllers
(FuT) and measurement devices and the communication via ICT.
 SS3.SC1 Advanced voltage control of distribution grids supported by

DERs power interfaces
 SS3.SC3 Transmission network voltage quality support by the distribution
network (VPP)
 SS2.SC1 Optimal distribution network control for the reduction of system
energy losses
The relevant system services specified for these use cases regard Power
Quality (SS3) and Energy Efficiency (SS2) whilst the relevant system configu-
rations are Distribution Grids (SC1) and Vertical Integration (SC3).
Function(s) under The FuI of this test case is the ability of the simulated communication network in
Investigation (FuI) RI2 to replicate the characteristics of the physical communication network in RI1.
Purpose of Investigation The PoI of this test case is to characterize the operation of the two alternative
(PoI) set-ups for testing distributed control, based upon differences in the imple-
mentation of the communication system.
Test criteria The first test set-up with real communication between physically separated
components is used as a reference case when evaluating the operation of the
second test set-up with simulated communication. The differences in system
responses are evaluated and the second test set-up iteratively further devel-
oped to represent the real system operation better.
target metrics Operation of the two alternative test set-ups with the same test sequences will be

ERIGrid GA No: 654113 02.04.2017
(criteria) compared to evaluate the operation of the test set-up with simulated communica-
tion. Important parameters to measure will be at least CVC algorithm control ac-
tions and delays in them and network state parameters (voltages, currents).
variability attributes 1. Load and RES Patterns (typical, daily, annual variation)
(test factors) 2. Communication attributes (packet loss, data corruption, packet duplica-
tion, link loss, latencies, jitter, etc.)
quality attributes Measurement uncertainty in the two RIs must be comparable.

(thresholds) Different time constants between RIs (voltage regulator ramp rate, data ac-
quisition speed, etc.) must be accounted for in the performance comparison.
The detailed test specification will be composed at the beginning of JRA4 but some preliminary
ideas are documented already in this deliverable.
Title TC.S.4 Test of Distributed Cyber-Physical System in RI1 as a Monolithic

Setup in RI2
Ref. Holistic test case TC.S.4
Test System The first test system with real communication between physically separated
(also graphical) components is represented in the figure below.
Transmission
Grid
System under Test
Transformer
Distribution
DER
Grid
Measurement
Controller Controller
Device
CVC
Electric power domain

ICT/control domain
The second test system with simulated communication is represented below.

ERIGrid GA No: 654113 02.04.2017
Transmission
Grid
System under Test
Transformer
DER Distribution
Grid
Measurement
Device
SCADA
Simulated
Meas. Device
Controller CVC
Controller
Electric power domain

ICT/control domain
Target measures  Successful implementation of both the test set-ups

 Comparison of the time domain operation between the two test set-ups

rameters
 Real and reactive power injections prior to control actions i.e. power flow
conditions in the network
 Communication network parameters
Uncontrollable input parameters:

 State of charge of possible storage units
 CVC algorithm control actions and events
 Network state parameters (voltages, currents)
Test Design Real and reactive powers of resources connected to the network are used as
disturbances to invoke CVC operation. Test sequences will be designed such
that the CVC algorithm operation will be visible. Same test sequences will be
conducted using both the two test set-ups to enable comparing the results.
Tests are conducted using different communication network characteristics,
again the same in both test set-ups.
The experiment specifications for both of the test set-ups will be composed at the beginning of
JRA4. The first test set-up will be implemented by DTU and the second by OFFIS.

ERIGrid GA No: 654113 02.04.2017
7.3.5 TC.M.1.1: Integrate Control SW Running in RI1 with HW RI2
The test case description of TC.M.1.1 is presented below.
Name of the test case TC.M.1.1 Integrate Control SW Running in RI1 with HW RI2
Narrative A central controller is installed at RI1 and is initialized with all the necessary
static data of the network: network topology, admittance of lines and trans-
former, nominal power of DER units and storage systems, operating limits of
DER units, storage systems and OLTC.
While it operates, it requests and receives from RI2 real-time power meas-
urements of loads and DER units, as well as the state of charge (SoC) of the
storage systems and the current tap position of the OLTC, in discrete itera-
tions (e.g. every 10 minutes). Using this dynamic data, it formulates an opti-
mal power flow problem, whose objective function involves the minimization
of voltage deviation of critical nodes from the nominal value, power losses of
the lines and transformer, and tap change operations of the OLTC.
The outputs that result from the solution of this optimization are set-points for
all controllable devices located in the network of RI2. Specifically, the control-
ler calculates a set-point for the tap position of the OLTC, reactive power set-
points for the inverters of DER units, as well as active and reactive power set-
points for the storage systems.
Part of RI2’s network can be simulated in a real-time simulator while the rest
is realized as hardware devices/components such as lines, inverters, battery
banks etc.
The reception of measurements and transmission of set-points is carried out

through a communication network.
System under Test The SuT consists of the CVC controller operating as a part of the distribution
(SuT) management system (DMS), DER devices, OLTC controller, transformer, dis-
tribution lines (from the electric power domain), telecommunication network
and communication platform between RIs (from the ICT domain).
Object under Inves- The OuI of this test case is the DMS controller (CVC).
tigation (OuI)
vestigation (DuI)
Functions under Test The FuTs of this test case include optimization of the DMS controller, the
(FuT) DER P-Q control, OLTC tap control, measurements, and communication of
RIs via ICT.

network (VPP)
energy losses

ERIGrid GA No: 654113 02.04.2017
Function(s) under The FuIs of this test case are the voltage control optimization executed in the
Investigation (FuI) DMS controller and the communication between RIs via ICT.
Purpose of Investigation The PoI of this test case is DMS controller characterization and validation in
(PoI) terms of:
1. Convergence of the optimization (validation)

2. Performance of the optimization under realistic conditions (characterization)
3. Successful regulation of bus voltages (verification)
Test criteria The test criteria are divided in target criteria, variability attributes, and quality
attributes and are described below:
target metrics 1. When and how often the optimization converges. How fast and what is the
(criteria) solutions quality (optimality etc).
2. Voltage deviation of all the nodes from the nominal value, number of tap
changes, network active power losses
variability attributes 1. Load and RES Patterns (typical, daily, annual variation)
(test factors) 2. Communication attributes (packet loss, delays)
quality attributes 1. Convergence within 2 sec (validation)

(thresholds) 2. All voltages are within ±2% of the nominal value (verification)
The test specification of TC.M.1.1 is presented below.
Title TS.M.1.1 Characterization and Validation of a Distribution Management

System (DMS) Controller for Coordinated Voltage Control
Test Setup
The figure above illustrates the test setup and its interfaces with the OuI
(RI1). The OuI is shown in green (DMS controller) and the DuI are both the
electric power and ICT domains.
Test Objective The test objective is to experimentally verify the ability of the optimization algo-
rithm to regulate the bus voltages when voltage violations occur by means of
coordination of the OLTC and dispatchable sources’ functionalities. Further-
more, another goal of the test is the validation of the ability to remotely integrate
the software that contains the optimization algorithm to RI2’s SCADA.

ERIGrid GA No: 654113 02.04.2017
Input and output pa- 1. Controllable input parameters:

rameter
 Real and reactive power injections prior to control actions i.e. power flow
conditions in the network
 Active power of the Storage and OLTC position.
2. Uncontrollable input parameters:

3.
 State of charge for the Storage
4. Outputs / measured parameters:

5.
 Reactive power set-point to the PV inverters, active and reactive power

set-points to the simulated storage and the OLTC position.
 Node voltages.
Test Design The following is considered when designing the test:
 Choice of load and RES profiles in order to stimulate voltage limit violations
 Network topology to ensure that the coordination of OLTC and controlla-
ble sources is necessary for voltage control
 Energy storage system (ESS) and RES placement within the network
 Initial SoC of the ESS
 Communication establishment between RIs
The test design follows a “Validation & Verification-Repeating” test design cluster.
Initial system state  Nominal network voltage and frequency (400V, 50Hz)
 Consumers (P,Q) = (0,0)
 Producers (P,Q) = (0,0)
Evolution of system Initially the OLTC tap position is chosen in a way that every voltage lies within
state and test signals the limits. Load and RES power profiles, as they are changing in time, they
are bound to cause voltage limit violation at certain periods in time. When this
happens the DMS controller that monitors the state of the system is trying to
optimize the OLTC and RES and ESS functionalities by running an optimal
power flow algorithm that results in a system without voltage limit violations.
Other parameters Line losses, time
Storage of data Matlab files
Temporal Resolution Discrete simulation

Resolution of the discrete time step: 80μs
Source of uncertainty Noise coming from the measuring equipment.
Suspension criteria / The test stops when every voltage lies within limits. If not, the optimization
Stopping criteria has failed and the test is suspended.
Experiment specifications for all the set-ups in different RIs participating to the test case will be
composed at the beginning of JRA4.

ERIGrid GA No: 654113 02.04.2017
7.3.6 TC.M.1.2: Integrate Control SW Running in RI1 with HW RI2
The test case description of TC.M.1.2 is presented below.
Name of the test case TC.M.1.2 Integrate Control SW Running in RI1 with HW RI2
Narrative The growing number of smart grid research and development projects around
the world has led to a significant portfolio of demonstration projects. The col-
laboration and information exchange among research and industrial institu-
tions has become more and more necessary to efficiently exploit the research
infrastructures and to rapidly transfer new developments. To achieve that
purpose, interoperability among infrastructures, especially micro-grid plat-
forms, is identified as a top priority, to efficiently exploit the existing platforms
and to complement the missing infrastructure with available assets from other
partners. As a consequence, it is necessary to ensure a certain degree of in-
teroperability among the platforms. Furthermore, connecting interoperable
platforms under a holistic testing framework will require much less time and
resources than locally constructing new experimental modules from scratch.
The mutual understanding and control of technological means provide also
the possibility to realize multi-site research projects, for example, coupled
platforms, wide area energy management, etc. Two specific applications can
be considered in this test case:
 Controlling resources at RI2 with SW developed by and executing at RI1.

 State estimator (RI1) integrated as a service into RI2 SCADA (JaNDER
level 2).
System under Test The SuT consists of the grid model, the JanDER platform to deliver software
(SuT) to RI2, the state estimation algorithm, other available controllable resources,
the electrical network connecting the resources and the ICT network connect-
ing the infrastructure.
Object under Inves- The OuIs for this test case are the functionality of the software (in RI1) over
tigation (OuI) the hardware of RI2, via JanDER platform.
Domain under In- The DuIs of this test case are electric power and ICT.
vestigation (DuI)
Functions under Test The FuTs of this test case are the state estimation algorithm and the commu-
(FuT) nication between RIs through JaNDER.

energy losses
 SS2.SC2 Optimal transmission network management level for system
energy losses reduction
 SS2.SC3 Incentivising distribution network (microgrid) local balancing to
minimize transmission network loading
network (VPP)
 SS5.SC1 Fault detection and corrective management of distribution grid
assets and energetic resources
The relevant system services specified for these use cases regard energy

ERIGrid GA No: 654113 02.04.2017
efficiency (SS2), power quality (SS3) and infrastructure integrity, protection

and restoration (SS5) whilst the relevant system configurations are distribu-
tion grid (SC1), transmission network and offshore wind (SC2) and vertical
integration (SC3).
Function(s) under The FuI of this test case is the state estimation including communication la-
Investigation (FuI) tency due to the JaNDER interface.
Purpose of Investigation The test case TC.M.1.2 aims to providing the technical basis of a collabora-
(PoI) tion framework, in particular:
 Demonstrate HW/SW integration between different RIs.

 Allow testing complex SW packages in different HW at different RIs.
 Extend HW infrastructures to all ERIGrid Partners.
Test criteria The main criteria for success of the test are aspects related to successful uti-
lization of the state estimation algorithm for the remote grid model via the
JanDER platform.
The test specification of TC.M.1.2 is presented below.
Title TS.M.1.2 Integrate Control SW Running in RI1 with HW RI2
Test Setup General setup for TC-M.1.2 is given in the figure below.
State
Estimator
RI1
Jander-L2
SCADA EMS
RI2
In this test case, the micro-grid runs or is simulated at RI2. Measurement da-
ta is sent to RI1 through JaNDER L2 and the state estimation algorithm lo-
cated at RI1 calculates the network state. The state estimation results are

ERIGrid GA No: 654113 02.04.2017
sent back to RI2 using the JaNDER infrastructure where the local EMS algo-
rithm can utilize this information in its own control decisions.
The test case TC.M.1.2 requires an integration of the laboratory SCADA sys-
tems between the partner RIs. Due to the geographical distance between
partner RIs, the classical central approach is no longer suitable and new ar-
chitectural approaches with ICT integration are required. The JaNDER con-
cept uses remote network based server to store and handle information that
can be accessed through network connection. The service is then delivered
to RI1 via either Software-as-a-service (SaaS) or Platform-as-a-Service
(PaaS) delivery model.
In this architecture with PaaS delivery model, the SCADA application is run-
ning on-site and is directly connected to the platform control network. The
critical functions of the SCADA server are isolated at local platform and only
selected non-critical information is transferred to the common cloud SCADA
server that provides visualization, reporting and limited access to a range of
applications, to remote authorized users and partner institutions. This (physi-
cal or virtual) common cloud SCADA server should be private (for the partner
network), located at a partner platform or a site ,agreed by the partners, to
provide optimized latency for the possible applications and is strictly moder-
ated by a common council and technical staff, in charge of the interoperability
within the network.
Using PaaS delivery model, it is also possible to remotely demand to launch a

certain function (setting values, starting simulating, etc.) and visualize the re-
sult, provided that the demander is allowed by the platform owner. This proper-
ty is very important in the context of interoperability among micro-grid platforms
of research institutions, because it enables the possibility to make experiments
on the shared resources, without having to come to the platform in person.
Test Objective The test objective is to experimentally verify the ability of the state estimation
algorithm to function in case of existing latency between the estimator and
the grid. It should validate also the functionalities of the JaNDER platform.
Input and output param- Input: Measurements from the grid or devices
eter Output: estimated state of the grid.
Test Design Real and reactive powers of resources connected to the RI2 network are var-
ied in order to change the network state. Test sequences will be designed
such that the operation of the state estimation algorithm located at RI1 can
be evaluated and the effect of running the algorithm at a remote location in-
stead of a local implementation can be assessed.
Storage of data According to the software of state estimation.
Temporal Resolution Discrete simulation

Resolution of the discrete time step will be chosen in function of the estimat-
ed latency in order to ensure a good functionality of the system.
Source of uncertainty Noise coming from the measuring equipment, communication latency and
packet loss during transmission.
Suspension criteria / The test stops when the set timer is reached.
Stopping criteria
Experiment specifications for all the set-ups in different RIs participating to the test case will be
composed at the beginning of JRA4.

ERIGrid GA No: 654113 02.04.2017
7.3.7 TC.M.2: Extend HW Resources of RI1 Using Resources of Other RIs
The test case description of TC.M.2 is presented below.
Name of the test case TC.M.2 Extend HW Resources of RI1 Using Resources of Other RIs
Narrative An RI (RI1) has a simulated grid with various distributed energy resources (DER)
connected and a centralized coordinated voltage control (CVC) algorithm. The
DERs’ reactive power and, if needed, active power can be controlled in order to
regulate the grid voltages, according to the declared capabilities of each device.
Some of the connected DERs are aggregates of multiple real devices that are
coordinated by a microgrid controller, in order to act as a single equivalent DER.
One or more remote RIs (RI2, RI3) can act as aggregate devices, sending
their current capabilities and actual power values at point of common coupling
(PCC) and receiving P and Q setpoints. A remote RI can also run a microgrid
model in a real time simulator.
This test case allows:
 Demonstrating the integration of hardware and simulated power systems

between different RIs
 Integrating real system behaviour into simulated grids
 Assessing aggregate functions provided by microgrid
System under Test The SuT of this test case consists of the following parts:
(SuT)
 Medium Voltage Grid: Primary Substation, lines, loads, generators.
 MV Grid Controller: CVC.
 Low Voltage Microgrid: Secondary substation (PCC), microgrid DERs
(generators, controllable loads, storage systems).
 LV Microgrid Controller: P/Q controller at PCC by means of DERs Energy Mgt
 Communication between main grid and microgrids
Object under Inves- The OuIs of this test case are:

tigation (OuI)
 MV Grid Controller: CVC.
 LV Microgrid Controller: P/Q controller at PCC by means of DERs Energy Mgt
vestigation (DuI)
Functions under Test The FuTs of this test case include:

(FuT)
Coordinated Voltage Control:
 collection of updated capabilities from DERs
 computation of optimal and feasible P/Q setpoint
 verification of actual P/Q produced and recalculation
Local Microgrid Control:

 calculation of current overall capability
 actuation of requested setpoints (load sharing)
 aggregated measurements calculation
 transmission of aggregated values.
Communication between RIs through JaNDER

ERIGrid GA No: 654113 02.04.2017

network (VPP)
energy losses
Function(s) under The FuIs are the following:

Investigation (FuI)
Microgrid:
 calculation of current microgrid overall capability
 actuation of requested setpoints (gen/load sharing)
MV grid controller:
 CVC verification of actual P/Q produced and recalculation
Communication between RIs through JaNDER
Purpose of Investigation The PoI consists in testing the interactions between the CVC on the main grid
(PoI) and the local microgrid controller in order to verify the fulfillment of aggregat-
ed requests.
Test criteria In order to address the PoI, it’s possible to formulate two different test criteria
 Sub-Test-1: Verification of the performances of the microgrid local mi-

crogrid controller when realizing the P/Q by the CVC , assuming that it
lays inside the declared capability;
 Sub-Test-2: Verification of the CVC performance when the requested P/Q
setpoint cannot be satisfied by the microgrid.
target metrics  Sub-Test-1: error between requested P/Q setpoints and measured values
(criteria) after a settling time.
 Sub-Test-2: Voltage error at significant nodes, compared to the P/Q actu-
ation error from a microgrid
variability attributes  Sub-Test-1: P/Q setpoints at the limits of the declared capability; Different
(test factors) microgrid status, depending on the specific test system (i.e. different load
and generation levels, different state of charges of the storages) and re-
newable generation variability
 Sub-Test-2: Voltage error at significant nodes, compared to the P/Q actu-
ation error from a microgrid
quality attributes Microgrid P/Q measurements uncertainty must be less than a percentage to
(thresholds) be defined of the P/Q set point step resolution.
Microgrid P/Q actuation and settling time must be significantly smaller than
CVC control time step.
In repeated tests the calculated control variables should differ only due to
measurement uncertainty and renewable generation variability.

Erigrid User Case

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Erigrid User Case

Uploaded by

Copyright:

Available Formats

European Research Infrastructure supporting Smart Grid

Systems Technology Development, Validation and Roll Out

Grant Agreement No: 654113

Contractual delivery date: 31.01.2017

All Authors/Partners Anna Kulmala / VTT

Distribution List ERIGrid consortium members

Revision Content / Changes Resp. Partner Date

Final Approval Name Resp. Partner Date

Deliverable: D7.3 Revision / Status: released 2 of 47

© The ERIGrid Consortium, 2015 – 2020

Deliverable: D7.3 Revision / Status: released 3 of 47

Executive Summary ........................................................................................................................ 6

Deliverable: D7.3 Revision / Status: released 4 of 47

CHIL Controller Hardware-In-the-Loop

Deliverable: D7.3 Revision / Status: released 5 of 47

Deliverable: D7.3 Revision / Status: released 6 of 47

1.1 Purpose of the Document

 Identifying relevant scenarios and use cases,

 JRA2 - Co-simulation based assessment methods;

1.2 Scope of the Document

Deliverable: D7.3 Revision / Status: released 7 of 47

1.3 Structure of the Document

Deliverable: D7.3 Revision / Status: released 8 of 47

2 Test Case Descriptions

Figure 2.1. ERIGrid holistic testing approach

2.1 System Configuration

2.2 Use case

Deliverable: D7.3 Revision / Status: released 9 of 47

2.3 Test Case

Deliverable: D7.3 Revision / Status: released 10 of 47

3 Test Case Selection Process

3.1 Selection Criteria

3.2 Testing Approaches

Deliverable: D7.3 Revision / Status: released 11 of 47

Deliverable: D7.3 Revision / Status: released 12 of 47

Table 3.1. The selected single-RI test cases

Test Case Test Objectives Use Case

TC.S.2  Integrate third-party SW in RIs Coordinated volt-

Table 3.2.The selected multi-RI test cases

Test Case Test Objectives Use Case

TC.M.2  Integrate remote hardware to testing CVC

3.4 Test Cases Adopted in Simulations (JRA2 Test Cases)

Deliverable: D7.3 Revision / Status: released 13 of 47

Table 3.3. JRA2 test cases

Test Case Test Objectives and Implementation Use Case

Deliverable: D7.3 Revision / Status: released 14 of 47

 Desynchronization of timeline in real-time/non-real-time simulators. It is the main obstacle

3.6 Mapping to Focal Use Cases and System Configurations

Test Cases Connected Focal System Services System Configura-

Deliverable: D7.3 Revision / Status: released 15 of 47

Test Cases Connected Focal System Services System Configura-

Deliverable: D7.3 Revision / Status: released 16 of 47

4 General Requirements for Test Case Implementation Plans

4.1 Content of an Implementation Plan

 Participating RIs and their roles in the test

4.2 Test Case Mapping to RIs

Deliverable: D7.3 Revision / Status: released 17 of 47

4.2.1 TC.S.1: Component Testing at Different RIs with Different Set-up

Figure 4.1. System under test of TC.S.1

Pure simulation CHIL Pure HW PHIL

Grid Grid Grid Grid

V,f V,f Closed V,f Open loop V,f Closed

Converter Converter Converter Converter

Storage/PV and Storage/PV and Storage/PV and Storage/PV and