Verification of ancillary services in

large scale power system

Agreement no.: PSO ForskEl 12347

Project Name: Ancillary Services from Renewable Power Plants
Acronym: RePlan
Duration: 2015 - 2018
Co-ordinator: DTU Wind Energy
 Document information

Document name: Verification of ancillary services in large scale power

system
Document number: D51
Lead Author Florin Iov
Contributors: Kamal Shahid, Lennart Petersen, Rasmus L. Olsen
Document type: Deliverable D5.1
Date: 07.02.2018
WP: 5
Content
Preface ............................................................................................................................................................... 4
1 Scope of document.................................................................................................................................... 1
2 Real-Time Hardware-In-the-Loop Framework .......................................................................................... 2
2.1 Overview ............................................................................................................................................ 2
2.2 Real-Time ICT Emulator ..................................................................................................................... 4
2.3 Model-based Design Approach ......................................................................................................... 5
2.4 Summary............................................................................................................................................ 7
3 Validation of ICT Model ............................................................................................................................. 8
3.1 Background ........................................................................................................................................ 8
3.2 Setup 1 – Off-Line Model................................................................................................................... 8
3.3 Setup 2- RT Online Model.................................................................................................................. 9
3.4 Characterization of Models ............................................................................................................... 9
3.5 Test Cases ........................................................................................................................................ 10
3.6 Simulation Results & Comparison ................................................................................................... 11
3.6.1 Offline Setup – Test Results ..................................................................................................... 11
3.6.2 Online Setup – Test Results ..................................................................................................... 16
3.7 Results Discussion and Summary .................................................................................................... 19
4 Validation of Distributed On-Line Voltage Coordination ........................................................................ 22
4.1 Control Architecture ........................................................................................................................ 22
4.2 RT-HIL Setup .................................................................................................................................... 22
4.2.1 Distribution Grid Model........................................................................................................... 23
4.2.2 Aggregator Control .................................................................................................................. 24
4.2.3 ICT Model................................................................................................................................. 24
4.2.4 Considerations on Real Time Implementation ........................................................................ 24
4.3 Test Cases ........................................................................................................................................ 24
4.4 Test Results ...................................................................................................................................... 26
4.5 Conclusions .......................................................................................... Error! Bookmark not defined.
5 References ............................................................................................................................................... 36
Preface
This report is a deliverable in WP5 in the project “Ancillary services from Renewable power Plants”
(RePlan). RePlan is funded as POS project 2015 no. 12347 by the Danish PSO-programme ForskEL,
which is administered by Energinet.DK. RePlan is carried out in collaboration between DTU Wind
Energy, DTU Elektro, Aalborg University Energy Technology, Aalborg University Wireless
Communication Networks and Vestas Wind System A/S. DTU Wind Energy is manager of the project.
1 Scope of document
This deliverable report is summarizing the results of WP5 Task5.1. This work package is aiming to verify the
capability of a ReGen plant to provide ancillary services to system operators. The ancillary services provision
from the ReGen plants is verified both on a large scale power system against the baseline scenario defined
in WP1.
The novelty of this approach relies on considering the hierarchical industrial controller platforms used
nowadays in power plants. Moreover, the communication networks as well as their data traffic are taken into
account. Based on these sets of recordings, guidelines and recommendations for practical implementation
of the developed control algorithms for targeted ancillary services are made. This is providing a deep insight
for stakeholders i.e. wind turbines and PV system manufacturers, system operators regarding the existing
boundaries for current technologies and requirements for accommodating the new ancillary services in
industrial application.

1
2 Real-Time Hardware-In-the-Loop Framework
2.1 Overview
Verification of ancillary services in large scale power system is conducted using the Laboratory facilities
available at AAU-ET partner, namely the Smart Energy Systems (SES) Laboratory [1]. The structure of this
platform is given in Figure 1.

Figure 1. Architecture of Smart Energy Systems Laboratory.

The main components are as:

Information and Communication Technology Layer
The Information and Communication Technology (ICT) layer is the backbone for the setup and aims to
emulate different technologies and topologies for the communication networks. A dedicated server is used
to mimic the characteristics of different communication networks such as 3G, LTE, xDSL etc, for which all
traffic between controllers and assets are routed through. A dedicated server is used for generating
stochastic or trace-based background traffic patterns to emulate realistic cross traffic. This traffic is based on
traffic models and traces of real network traffic. The network configuration includes mapping GIS data to
communication network as well as Offline and Online network reconfiguration is done from a Visualization
server. The developed RT ICT Emulator is able to provide reproducible behavior of a network along with an
exact control on network traffic over Internet.
Control Layer (Hardware-In-the-Loop)
Different computers and industrial hardware platforms are hosting functionalities of different actors e.g.
DSO, TSO, Aggregator, Renewable plant owner, etc. A dedicated platform for demand response is used to
host functionalities related to aggregation and control of large scale flexible loads in distribution networks.
A dedicated industrial controller (Medium Voltage Grid Controller) is used to host typical control functions in
primary substations in medium voltage grids. It is also offering the possibility to implement and verify new
control and operational strategies for components in medium voltage networks such as voltage control, loss

2
minimization, etc. This industrial controller is getting information from the downstream assets placed in
medium and low voltage networks as highlighted in the next sections of this paper. A dedicated industrial
controller (Low Voltage Grid Controller) is used to host new control functionalities in secondary substations.
This platform offers the possibility to implement and verify new control and operational strategies for flexible
assets in low voltage grids. Another industrial controller is hosting typical control functionalities implemented
in renewable based generation plants such as wind or PV. Implementation of controls in all platforms is done
using MATLAB/Simulink. New actors and/or functionalities can be easily added to the platform.
Real-Time Digital Simulator.
The Real-Time Digital Simulator is implementing a large scale energy network including systems using the
multi-domain physics approach. This means that not only the electrical network and system is captured but
also other systems such as thermal, mechanical, etc. The main goal for this Real-Time simulator is to capture
the electrical system from the transmission level (TSO) down to low voltage distribution grids (DSO). The
system is able to simulate up to 200 three-phase bus-bars in EMT domain and very large electrical networks
in RMS domain (up to 10.000 buses). Other energy systems such as district heating, gas networks and
transportation systems can also be represented. All the modelling work in this real-time platform is done in
Matlab/Simulink including Toolboxes.
Physical Assets Layer (Power Hardware-In-the-Loop)
Grid Simulator. The voltages measured in a given point in the distribution network
implemented in the Real-Time Digital Simulator are applied to a 50 KVA four-quadrant AC Supply/Sink that is
supplying a local grid where different components are connected such as DER Emulator, Flexible load, etc.
The measured current at the output of the Grid Simulator is fed in back to the Real-Time Digital Simulator.
Thus, all physical equipment connected to this local grid is “seen” as part of the large real-time model
implemented in the digital simulator.
Dispersed Energy Resource. A four quadrant power converter based emulator for dispersed
generation (±20kW/10kVAR) is used to mimic characteristics of small wind turbines, PV systems or energy
storage.
Flexible loads. Three-phase independently controllable loads are used to mimic the behavior
of household appliances. Central Energy Management System for the entire house including communication
is also implemented in a dedicated server. A smart meter is providing power and energy consumption to the
upper hierarchical control levels.
Testing of new power converter based systems is also possible using this setup.
The key features of this Laboratory are as follows:

• Real-Time simulation of energy networks and systems

• Control Hardware-In-the-Loop – physical industrial controllers and other components are connected
to the Real-Time Digital Simulator
• Communication Hardware-In-the-Loop – powerful system able to simulate in real-time
communication network technologies and their traffic.
• Power Hardware-In-the-Loop – physical equipment that are emulating energy resources and
households are connected to a large scale energy system as they are part of it.
3
 • Model Based Design – modelling and control of all components and functionalities is based on
Matlab/Simulink.

2.2 Real-Time ICT Emulator

Network emulation refers to an experimental network that can mimic a target network by imposing
predefined network effects to the traversing traffic. The concept of network emulation is used because it is
difficult to access real networks and even if they are accessible, a network emulator can have more controlled
and reproducible environment. A network emulator can be a workstation or group of connected workstations
[2]. The concept is illustrated in Figure 2.

Figure 2. Concept of using network emulation.

The ICT layer in SES laboratory mainly comprises of a network emulator, traffic generator, visualization server
and a high-speed switch. This switch is a fast 1 GB VLAN enabled Ethernet switch that enables full control
over the network traffic, such that traffic between controllers, assets and other entities to the network can
be redirected through a network emulator, as illustrated in Figure 3. The switch is setup using VLAN to
forward any received packets to the network emulator, which is then setup to bridge the different VLANs.
The network emulator workstation provides other services necessary for operating the test bed, e.g. DHCP
services for test bed components, secure Internet access in the test bed, trace and log options for capturing
the network traffic via a PCAP module [3].

4
 Figure 3. Real-time ICT layer with network emulator connecting grid assets and controllers.

KauNet [4] is used as the network emulator in ICT layer that enables ingoing as well as outgoing data packets
to pass a queue configured with a buffer length and service time according to a given stochastic model of a
network. KauNet provides control on bit errors, packet losses, bandwidth, and delay changes. Using KauNet,
reproducible behavior of network along with an exact control on network traffic over Internet can be
provided [2]. The traffic using KauNet is routed through a set of buffers, where each buffer emulates specific
network characteristics in terms of delay, packet losses etc. The network capacity can also be emulated by
shaping the buffer sizes, such that packet losses can be efficiently emulated. The queues can internally be
linked together if needed, e.g. if multiple types of networks are connected.

2.3 Model-based Design Approach

The RT-HIL framework described above is enabling model-based design for power systems. Initial the method
was used by automotive industry then for motor drives. Nowadays control capabilities for power systems are
more and more demanding especially with high share of power generation from renewable sources. Design
and tuning of control algorithms is typically using dedicated simulation tools e.g. Matlab/Simulink while
control verification may require another power system tools. Translation of control schemes between tools
may be time consuming and the typical iterations in control development may increase the time even more.
Once the control schemes are verified in a power system tool under various operating conditions and test
cases an implementation phase on the actual target hardware is required. Another series of tests are then
required to validate the implementation. Finally, the controller is tested in a real environment. Some of the
measurements are later used to validate the designed control performance but also the models used in the
design process. Worth to mention here that site testing may not involve specific tests that requires

5
measurements of real events in the power grid. Thus, typically open loop testing is performed. Some of these
events i.e. large frequency excursion may not occur during the limited testing period of controllers.
In order to overcome some of the drawbacks encountered during the design and testing of control schemes
for power systems a model-based design approach can be utilized. An overview of different stages from
development to testing is given in Figure 4.

S and/or Z Dom

Figure 4. Model-based design approach for power system applications.

Desktop Simulations. Initially the control development and tuning process will use simplified/reduced order
models of power system and assets. Either continuous or discrete time models can be used according to the
tuning methodology. However, since the dynamics in the power system applications involve a wide range of
time constants and various sampling time for the subsystems involved a continuous time domain tuning is
preferred. Then, considerations about translation of models in discrete models shall be made in respect to
the actual expected sampling time of various control platform used.
Rapid Control Prototyping. In this stage the entire model is implemented in discrete domain with the proper
sampling time for various subsystems. This model is implemented in a Real-Time discrete simulator e.g. Opal-
RT. The control algorithms are tested intensively under various operating conditions to identify the
robustness of the design. Worth to mention that information exchange between different subsystems i.e.
plant controller, aggregator, assets, etc. shall be captured properly with a dedicated model that is able to
simulated the communication networks and their traffic. Based on the executed tests and their results
iterations of the control design and tuning may be necessary. At this stage it can be also identified if specific
information and communication technologies can meet the requirements imposed by control response.
Specifications about minimum requirements for ICT to provide a specific control function can also be derived
here. This will allow the selection of the ICT for the deployment. The control is ready for implementation on
the target hardware when the control design verification is finalized.
Automatic Coding Implementation. Typically, target hardware requires coding of control algorithms in
different software specific to manufacturers of the platforms e.g. structured text, C/C++, etc. This process
can be shortened if the simulation tools used for control design are capable of generating automatically the

6
code such as Matlab/Simulink. Thus, this stage can be skipped when using the facilities available in Smart
Energy Systems Laboratory.
RT-HIL Co-Simulation. Verifying control algorithms on large scale power systems requires testing of the
controller platform connected to a Real-Time model of the power system including assets i.e. wind power
plants, PV plants, energy storage devices, etc. Moreover, for a realistic testing a real-Time model of the
communication networks shall be used. Thus, the controller platform including the developed algorithms in
the first phase can be tested in realistic condition close to daily operation. Power system events that cannot
be measured in real life can also be replicated in a controlled environment while data traffic associated to
specific network technologies is captured properly without actually involving the real technologies. The
advantage of this approach can be summarized as:
• Extensive testing and verification of control algorithms under operating conditions which cannot be
encountered during the field-test trials.
• Accounting for impact of communication technologies, protocols and traffic on the developed
control algorithms in a unified and consistent without being constraint by the physical systems.
The developed control algorithms including physical implementation on target hardware is then ready for
site testing. This stage corresponds to a Technology Readiness Level of 6 according to [2].
Validation. The actual controller platform is tested on-site under operating conditions allowed by the
physical power grid and assets. Typically, the targeted tests have to be reported and documented to power
system operator (TSO or DSO) as well as to the plant operator or owner before execution. This process may
be complicated when different owners/operators are involved. The main goal for this process is to ensure
that no physical equipment will be damaged during the tests. The testing campaign is typically limited in time
and power system events in scope for the developed algorithms e.g. large voltage and frequency excursions
may not occur in the system during this period. Thus, an open loop approach is used. This means that the
controller is fed with pseudo-measurements and the output of the plants is recorded. However, the actual
impact on the power grid cannot be evaluated as well as possible control interactions between assets. These
recordings may be used to validate some of the developed models including modelling assumptions used in
the previous stages.
The existing facilities in Smart Energy Systems Laboratory allows all the above design and verification
procedure being a powerful environment for achieving high TRLs.

2.4 Summary
The Real-Time Hardware-In-the-Loop framework used for validation of ancillary services in RePlan is briefly
presented. The mechanisms for emulating in Real-Time the communication networks and traffic is detailed.
A new methodology for designing and verifying controls in power systems is proposed.

7
3 Validation of ICT Model
3.1 Background
The integration of ICT into the electrical energy infrastructure is shifting from a phase of demonstration to
large-scale deployment. This will have a strong impact on system architectures as well as it raises concerns
about cyber-security issue. The electric power grid integrated with communication systems and renewable
energy source (such as solar, wind, etc.) has become a cyber-physical energy system, also termed as smart
grids. A general framework for smart grids is therefore required for the validation which takes into account
their mutual interactions and interdependencies. One of the main barriers to this has been the lack of design
and validation tools that are capable of analyzing power and communication systems in a holistic manner.
Extending power system simulation tools for the ICT domain, or vice versa, demands a lot of effort and
collaboration among experts of both areas, because the life cycle and technical specifications of the electrical
and communication equipment (in terms of reliability requirements, round trip time, determinism, temporal
consistency and hierarchy) are significantly different [5]. By creating a so-called co-simulation environment
for the integrated analysis of both domains, via ad-hoc connections (or in a master/slave fashion), one can
understand the impacts of different communication solutions used for the operation of power systems much
better. Although simulation architectures may vary, a co-simulation framework allows in general the joint
and simultaneous investigation of models developed with different tools, in which the intermediate results
are exchanged during the execution of the simulations. However, the sub-systems are usually solved
independently by their corresponding domain-specific simulators [5]. Co-simulation allows to have a
complete view of both network behavior and the physical energy system states, while power system and
communication networks are simulated with the most suitable solver and the calculation loads are shared.
In the following, two test simulation setups (off-line and on-line) are implemented where a same input signal
is sent and received with different network conditions. Main purpose of the two test setups is to validate the
off-line communication model with its on-line counterpart.

3.2 Setup 1 – Off-Line Model

In this setup, a network emulator is used between a signal generator and the receiver (scope) to send signals
under different network conditions i.e. varying end-to-end delays and packet loss rates, as shown in Figure
5. The output signals were captured through a scope in the same working station.

Figure 5. Test Setup: Off-line Model.

8
 3.3 Setup 2- RT Online Model
In this setup, a signal generated at one working station was sent to the second working station through
KauNet network emulator under the same network conditions as in off-line test setup. The original signal as
well as the delayed signals were captured and recorded on working station 2, as shown in Figure 6.

Figure 6. Test Setup: On-line Model.

3.4 Characterization of Models

In the off-line model, the three components (i.e. signal generator, network emulator and a scope to capture
output) reside in the same workstation. However, for the on-line model, signal generator and the scope are
placed in two different workstations. The two components are connected via KauNet network emulator, as
shown in Figure 6. Making the communication between two workstations possible via KauNet requires
defining IP addresses, port numbers as well as creating pipes between these ports.
The signal and parameters used in the two aforementioned test setups (off-line + on-line) are as follows:
- Original Signal: Sine Wave
- Amplitude: 10
- Sampling time: 1 msec.
- Packet Loss: 0%
- Frequency: 2*π*0.05
- Phase (rad): 0
The tests have also been conducted considering a square wave because using this signal, it is possible to see
a wide range of potential problems, especially in case where set-point values are sent (instead of a
continuous-time signal), as in case of ReGen plants coordinating with the system operator. The parameters
used for generating a square wave are as follows:
- Original Signal: Square wave
- Amplitude: 1
- Duty Cycle: 20 %
- Period (for delay case): 0.5 sec.
- Period (for Packet loss case): 0.1 sec.
- Sampling Time: 1 msec.
Typically, to understand network behavior or the impact of delay on information, a simple transport layer
delay is used. However, in reality there’s much more on top of a simple delay by which a signal might be

9
effected, for instance, packet drops etc. Specifically, while considering public networks as a means of
coordination between ReGen plants and the system operators (TSO/DSO), a constant delay or packet loss
cannot be guaranteed. It is, therefore, necessary to see how different network conditions (in terms of higher
delays or packet drops) affect the performance of a signal. Thus, for both off-line as well on-line test setup,
the original signal was sent through the network under two conditions i.e.:
1. Added delays with zero packet loss rate in the network
2. Added packet loss rate with constant delay in the network
It is pertinent to mention here that the delays added in the network in case 1 are not constant delays. These
delays are rather based on delay patterns with mean values of 10ms, 100ms, 250ms and 500ms. The delays
with such mean values were considered based on the delay patterns obtained from a real network in [6] and
[7]. The real network based delay patterns in [6] were used as a base case in Deliverable D2 [7].
Here, the delay and packet drops are divided into four groups to get a better understanding of four different
network conditions, as given in Table 1:

Table 1. Delays for different network conditions

Network Condition Average Delay [ms] Packet Loss [%]
Normal 10 25
Average 100 50
Below Average 250 75
Worst 500 90

3.5 Test Cases

Figure 7 and Figure 8 show the original sine wave and square wave signals, respectively, used for off-line as
well as on-line tests with the parameters stated in section 3.4.

Figure 7. Original Sine Wave used in Off-line and On-line tests.

10
 Figure 8. Original Square Wave used in Off-line and On-line tests to validate impact of delay on a signal.

Based on the average delays and packet drop rates used to send these original signal through a network,
there are four test cases defined for both test setups (off-line + on-line), as shown in Table 2

Table 2. Test Setups and cases for evaluation

Test Setup Test Case Network Condition Average Delay [ms] Packet Loss [%]
1 Normal 10 25
2 Average 100 50
Off-line
3 Below Average 250 75
4 Worst 500 90
1 Normal 10 25
2 Average 100 50
On-line
3 Below Average 250 75
4 Worst 500 90

3.6 Simulation Results & Comparison

3.6.1 Offline Setup – Test Results

3.6.1.1 Test Results based on added delays

Figure 9 shows the original signal compared to the ones received from network emulator under four delay
based test cases. It can be observed how a signal can be affected due to different (average) delays in a
network. It can be noticed that all received sine waves are steady state waveforms. This is because of a very high
sampling rate selected (i.e. 1 ms). However, if the sampling rate is reduced, this will influence the shape of the
incoming signal with each added average delay patterns.

11
 Figure 9. Test Results from off-line setup showing received sine wave signals obtained through a network with four different
average delay patterns.

Figure 10 shows the received square wave signals from network emulator under the same delay based test
cases. It can be observed how a signal can be affected due to different (average) delays in a network.

12
Figure 10. Test Results from off-line setup showing received square wave signals obtained through a network with four different
average delay patterns.

3.6.1.2 Test Results based on packet drops

Figure 11 shows the received sine wave signals from network emulator under four packet loss based test
cases. In the current scenario, the impact of increasing packet loss rates in the network is not much clear,
which again is due to a very high sampling rate (i.e. 1 ms). However, this effect is much more distinct in case
of square wave signal, where the signals can be clearly seen to be dropped (see Figure 12).

13
 Figure 11. Test Results from off-line setup showing received sine wave signals obtained through a network with four different
packet loss rates.

In order to have a better understanding and proper visualization of increased packet loss rates in a network,
the original square wave is changed to the one shown below (see Figure 12). The period of this square wave
is changed to 0.1 sec.

14
 Figure 12. Original Square Wave used in Off-line + On-line tests to validate impact of packet loss on a signal.

Figure 13 shows the impact of increasing packet losses in the network.

Figure 13. Test Results from off-line setup showing received square wave signals obtained through a network with four different
packet loss rates.

15
3.6.2 Online Setup – Test Results

3.6.2.1 Test Results based on added delays

Figure 14 shows the original signal compared to the ones received from working station 1 through KauNet
network emulator under the four delay based test cases. As in offline results, it can be clearly observed how
the sent signal is affected due to different (average) delays in a network.

Figure 14. Test Results from RT online setup showing received signals obtained through a network with four different average
delay patterns.

Figure 15 captures the original sine wave with the ones received from offline as well as online test setups
(with avg. delay = 500 msec.) to show that the results obtained from both test setups are comparable.

Figure 15. Original sine wave signal compared with delayed signals received from off-line and online test setups.

16
Figure 16 shows the received (delayed) square wave signal from working station 1 through KauNet network
emulator under the four delay based test cases. As in offline results, it can be clearly observed how the sent
signal is affected due to different (average) delays in a network.

Figure 16. Test Results from RT online setup showing received signals obtained through a network with four different average
delay patterns.

3.6.2.2 Test Results based on packet drops

Figure 17 shows the received sine wave signals from network emulator under four packet loss based test
cases. As in offline test setup, the impact of increasing packet loss rates in the network is not much clear due
to a very high sampling rate (i.e. 1 ms). This effect is much more distinct in case of square wave signal, where
the signals can be clearly seen to be dropped (see Figure 18).

17
Figure 17. Test Results from RT online setup showing received sine wave signals obtained through a network with four different
packet loss rates.

Figure 18. Test Results from RT online setup showing received square signals obtained through a network with four different
packet loss rates.

18
 3.7 Results Discussion and Summary
From the above two test setups (off-line and on-line), same input signal was sent and received with different
network conditions. The results obtained from online test setup clearly validate the results from the offline
test setup. However, as a conclusion it is important to mention here that the electric power devices do not
have communication capability by themselves. Each electric device is attached with an embedded computer
system to serve as the communication interface to the network infrastructure. The electric device and the
embedded computer system together form an IED. The message processing steps within an IED are illustrated
in Figure 19, in which a message containing the device status data is generated and transmitted through four
modules in the IED i.e.:
(i) analog–digital converter transforms a status measurement into digital data,
(ii) CPU processes the measurement data,
(iii) set-point structure stores the current measurement data, and
(iv) network protocol stack formats the message and sends it into the network.

As soon as the message is received at the other (receiving) end, it passes through the same four modules.
The time spent within IEDs is part of the end-to-end delay that effects the whole control cycle.

Figure 19 Processing time spend in IED device

Based on the time spent in the whole process, a control cycle can be divided into four periods, i.e.:
(i) Read – time taken to read the incoming signal,
(ii) Compute – after reading the signal, the controller computes the set-points to be sent,
(iii) Send – the controller sends the set-points, and
(iv) Finally, the controller gets ready for the next incoming signal.

This is shown in Figure 20.

Figure 20. A line diagram showing events in a control cycle.

A signal(s) delayed or lost during this cycle will result in wrong/invalid computation of the set-point values,
especially in case where the delay increases sampling time, as shown in Figure 21.

19
 Figure 21. Message signal diagram showing a scenario where delay increases the sampling time.

These scenarios can also be observed in the above test cases, for instance, in case the average delay increases
up to 500 ms and/or packet loss rate is increased up to 90% due to poor network conditions. The two
scenarios are shown in Figure 22 and Figure 23, respectively. Therefore, it is necessary to send a right set-
point value at the right time, while making sure that it is not lost/dropped on the way.

Figure 22. Original square wave signal compared with the signal delayed above sampling time.

20
 Figure 23. Original square wave signal compared with the signal received under poor network conditions (higher packet loss
rates).
Overall, the response of the off-line ICT model is matching the one provided by the RT Network Emulator
under the same input and parameters. This off-line model proved to be a powerful but yet simple
representations of the communication networks and their traffic especially for off-line multi-run studies
focusing on verification of control design. However, in order to have complete confidence selected test cases
shall go to a validation stage in the RT HIL framework. Notice that in this case longer simulation time is
expected as the entire system is running in Real-Time.

21
4 Validation of Distributed On-Line Voltage Coordination
4.1 Control Architecture
The control architecture for Distributed On-Line Voltage Coordination as defined in [7] is given in Figure 24.

HV

Vmeas SS , Pmeas SS ,Q meas SS

Vstp , droop P + jQ MV
ReGen
Plant 1 Vmeas
PoC1

Vstp , droop
P + jQ
Vmeas

Figure 24. Control architecture for Distributed On-Line Voltage Coordination.

It requires grid layout and parameters provided by the DSOs, measurements from secondary side of primary
substations as well as measurements from each of the controlled ReGen plants. It provides voltage setpoints
and droop values for each ReGen plant considered in the asset’s portfolio.

4.2 RT-HIL Setup

In order to implement the control architecture for Distributed On-Line Voltage Coordination in the RT-HIL
framework a setup as shown in Figure 25 was used.
Aggregator Hardware Platform is based on the MCxx controller provided by Bachmann Electronics Gmbh
[8]. It supports model based design approach using Matlab/Simulink. It receives from Opal-RT System
measurements from primary substation, ReGen plants and it will provide voltage setpoints and the droop
values respectively using dedicated UDP links through RT ICT Emulator.
Host PC – Aggregator Hardware is a PC used for developing the initial Controller schemes in Matlab Simulink.
It is also hosting the dedicated software to communicate with the controller for setting up the configuration
of the controller via a dedicated TCP/IP link. The automatic code generation and transfer of the control
scheme on target hardware is also included in the tools provided by Bachmann Electronics Gmbh.
Opal-RT System is hosting the benchmark MV grid and the ReGen plants RT models developed using ePhasor
Tool [5] [9]. It provides to Aggregator Hardware measurements and it receives the setpoints using dedicated
UDP links through RT ICT Emulator.

22
Host PC-Opal RT is a computer dedicated to development of the RT model but also to monitor and to control
the RT Model using a dedicated TCP/IP link. Automatic code generation of the RT Model is included in the
RT-Lab suite provided with the Opal-RT system [10]. The Monitoring and Control Module is sending the
following signals to the Opal-RT System:
• Meteorological data: wind speeds, solar irradiation
• External grid voltage setpoint
• Load profiles in terms of active and reactive values
This module is also receiving selected signal from the Opal-RT System for monitoring the model performance
during simulations.
All the data exchange between Aggregator Hardware and Opal-RT system is executed through the RT ICT
Emulator. This means that only these signals are prone to delays, packet drop and cyber security threats. The
data exchange between Host PCs and corresponding hardware is not affected.

Vmeas SS , Pmeas SS ,Q meas SS

Vstp , droop HV

MV
ReGen P + jQ
Plant 1 Vmeas
Vstp , droop PoC1

P + jQ
Vmeas

Figure 25. RT-HIL setup used for validation of Distributed On-Line Voltage Coordination.

4.2.1 Distribution Grid Model

The benchmark grid used for development of Distributed On-Line Voltage Coordination in WP2 is
implemented in the Real-Time Digital Simulator. The grid layout is implemented using ePhasor tool from
RTLab [9] and [10]. The wind power plant and solar PV plant models defined in [7] are directly implemented
in the Opal-RT System.

23
4.2.2 Aggregator Control
The Distributed On-Line Voltage Coordination presented and used in WP2 is used as such. The only
modifications are related to TCP/IP interfaces between different hardware platforms.

4.2.3 ICT Model

The ICT model presented and used in WP2 [7] was based on NetMap [6] that is a real mobile-network
performance measurement system. It provides actual measurements on existing networks using actual end
user devices in real end user scenarios. The measured metrics include throughput, round trip times,
connectivity, and signal strength, accompanied by a wide range of context information about the device
state. The same model will be used here as such. According to the model, following considerations shall be
made regarding delay times:
Normal (base) case. 15ms delay in the transfer of information update can be expected for the maximum
times in daily operations.
Worst case. Since the realized network is a shared public network, the delay will vary. In the worst case, this
delay may jump up to 500 ms (RTT)

4.2.4 Considerations on Real Time Implementation

The various subsystems presented in Figure 2 are running with different sampling times in order to capture
a realistic behavior of such a system used in real applications. The following considerations shall be made
regarding specific sampling time.
Host PC-Opal RT. The Monitoring&Control Module is using a 200 msec sampling time for sending the
meteorological data but also for monitoring of the internal variables from Opal-RT System.
Opal-RT System. The power grid and the ReGen plants are running with 10 msec sampling time. The feedback
signals from ReGen plants and primary substation to Aggregator Hardware are updated every second.
Aggregator Hardware. The Distributed On-Line Voltage Coordination algorithm is running with a sampling
time of 500 msec and it is sending the setpoint values to ReGen plants with the desired update rate [7].

4.3 Test Cases

In order to identify voltage stability challenges in distribution systems with large penetration of ReGen and
to assess the voltage control functionalities developed in work package 2 [7], a benchmark distribution grid
(BDG) was developed in [7]. The BDG in [7] is based on a real MV grid operated by Himmerland Elforsyning
(HEF) near Aalborg in North Jutland and it is considered as starting point for the definition of the BDG. In
order to account for realistic scenarios regarding the current and future penetration of renewables in Danish
distribution grids, the BDG has been supplemented by the following ReGen plants providing voltage control
functionality, i.e. one WPP with type-4 (full-scale converter connected) WTs and three PVPs:
1. WPP (18 MW) representing 6 WTs of 3 MW each
2. PVP 1 (10 MW) representing remotely located ground-mounted system

24
 3. PVP 2 & 3 (2.5 MW each) representing typical rooftop systems mounted on top of large industrial
plants and shopping centers

Figure 26. Structure of MV Benchmark Grid.

Based on the control architecture described in Section 4.1, this structure of the BDG is used to analyze voltage
control in time domain for a volatile power profile of the ReGen plants, used as a benchmark test scenario
that covers the crucial operating points with high solar irradiation and high wind speed (see [7]). The ReGen
plants models are implemented in MATLAB/Simulink and the phasor model of the BDG is implemented in
OpalRT’s real-time simulation platform ePHASORsim. In [7], this model was used for off-line simulations,
while in this chapter on-line validation including the ICT layer will be performed to validate off-line simulation
results.
Two options for on-line coordination were taken into consideration in [7]:
• Updating the voltage droop values
• Updating the voltage set-point of the ReGen plants
However, it was ascertained in [7] that updating the droop settings according to the actual operating point
of ReGen plants did not significantly reduce the power losses within the distribution grid. While, updating
the voltage set-points according to the actual operating point of ReGen plants reduced the power losses
within the distribution grid to a measurable extent. Moreover, it decreased the reactive power utilization
rate of the ReGen plants, in comparison to Control Concept 2 (Distributed Off-Line Coordination) in [7].
Therefore, in this section we only consider the case of updating the voltage set-points of the ReGen plants.
In [7], four different update rates (10 sec., 1 min., 5 min., 15 min.) were considered in simulations for
adjusting the voltage set-point of each ReGen plant to evaluate their impact on the power losses within the
grid. Since it has already been shown in Chapter 3 that the offline communication model performs the same
as the online communication setup (with KauNet), two update rates are considered as test cases to validate
the offline simulations via online setup:

25
 1. 𝑇𝑇𝑠𝑠 = 10 sec.
2. 𝑇𝑇𝑠𝑠 = 1 min.
A time frame of one hour is considered sufficient to represent a volatile power profile covering the extreme
operational points at high wind speed and solar irradiation.

4.4 Test Results

From Figure 25 to Figure 32 it is shown for each ReGen plant in the BDG the active power, reactive power
and voltage profile both for offline simulation and online/real-time communication setup throughout the
considered time frame of 1 hour according to the specified test cases.

Figure 27. P, Q, V of PVP 1 over one hour for 10 sec. update rate.

26
Figure 28. P, Q, V of PVP 2 over one hour for 10 sec. update rate.

Figure 29. P, Q, V of PVP 3 over one hour for 10 sec. update rate.

27
Figure 30. P, Q, V of WPP over one hour for 10 sec. update rate.

Figure 31. P, Q, V of PVP 1 over one hour for 1 min. update rate.

28
Figure 32. P, Q, V of PVP 2 over one hour for 1 min. update rate.

Figure 33. P, Q, V of PVP 3 over one hour for 1 min. update rate.

29
 Figure 34. P, Q, V of WPP over one hour for 1 min. update rate.

It can be observed from Figure 27 to Figure 34 that no significant differences are observed for the specified
test cases in the online test setup as compared to the offline tests. However, since there is a little difference
seen in the some results, it is worth calculating the percentage error in each case. The percentage error in
case of voltage (V) and active power (P) is calculated based on the difference between offline and online
results, keeping offline results as reference:
𝑉𝑉𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜 − 𝑉𝑉𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜
𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 [%] = × 100
𝑉𝑉𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜
The same applies for the active power (P). While for the reactive power (Q), it can be observed that the signal
includes zero, which will give infinitely large errors once divided by the reference signal (offline). Therefore,
for the reactive power (Q), a delta signal (∆Q) is plotted which is the difference between the Q obtained
offline and online:
∆𝑄𝑄 = 𝑄𝑄𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜 − 𝑄𝑄𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜𝑜

The results are shown from Figure 35 to Figure 42.

30
Figure 35. Error in V, P and Q of PVP 1 sent via offline and online communication models over one hour with 10 sec. update rate.

Figure 36. Error in V, P and Q of PVP 2 sent via offline and online communication models over one hour with 10 sec. update rate.

31
Figure 37. Error in V, P and Q of PVP 3 sent via offline and online communication models over one hour with 10 sec. update rate.

Figure 38. Error in V, P and Q of WPP sent via offline and online communication models over one hour with 10 sec. update rate.

32
Figure 39. Error in V, P and Q of PVP 1 sent via offline and online communication models over one hour with 1 min. update rate.

Figure 40. Error in V, P and Q of PVP 2 sent via offline and online communication models over one hour with 1 min. update rate.

33
Figure 41. Error in V, P and Q of PVP 3 sent via offline and online communication models over one hour with 1 min. update rate.

Figure 42. Error in V, P and Q of WPP sent via offline and online communication models over one hour with 1 min. update rate.

It can be observed from Figure 35 to Figure 42 that in case of V and P from all ReGen plants, collectively the
error remained less than 1% approximately. The Ethernet and other real-time effects in the link can be a

34
reason to impose this error. While the relatively higher error initially in each case is expected due to the HIL
initialization setup.

4.5 Summary
Two relevant test cases from WP2 [7] are selected for comparison and verification. These test cases are co-
simulated in the RT HIL setup. Overall errors below 1% are obtained when comparing main variables from
off-line studies with RT HIL results. Some high errors are seen in the beginning of simulations due to
initialization of the RT system. However, these errors are becoming small after the initialization is done. The
validation of voltage control coordination is achieved using a RT HIL setup.

5 Conclusions and Future Work

The main goal of this report is to achieve validation of coordinated voltage control algorithms proposed in
WP2. Firstly, the report is addressing the validation of the proposed ICT model for off-line studies in WP2 and
WP3. The proposed ICT model is verified and validate through different test cases against the complete
network model and related data traffic implemented in the Smart Energy systems laboratory. Based on the
results from this comparison it can be concluded that the performance and characteristics of the off-line ICT
model is matching the more detailed RT HIL model. However, this off-line model should be used for
preliminary control studies while the detailed RT HIL model shall be used for validation purposes and thus
achieving a high TRL.
Then, the validation of coordinated voltage control for ReGen plants in MV grids is achieved. Two test cases
from WP2 are implemented in the RT HIL setup. These test cases are selected based on the results from
validation of the ICT model but also taking into account the main findings in WP2 [7]. Deviations below 1%
are obtained for the main variables involved from both off-line and RT studies. These results confirm that the
main assumptions regarding ICT behavior considered in WP2 are valid.
In general, the off-line ICT model is to be used in the design phase of any control algorithm and for verification
purposes under a wide range of delays and packet drops. In this way the simulation time for each test case
is shortened and a complete view on the impact of ICT for a given control functionality is achieved. Then
selected test cases are validated by using the RT HIL framework. The main advantage of the RT HIL approach
is that the actual control platform is used with a RT model of the power grid and corresponding assets i.e.
ReGen plants and also selected ICT including data traffic. These RT HIL studies are mainly targeting to get
confidence before actual site test trials. Moreover, specific power system phenomena can be replicated in
this controlled environment that may not be detected in normal operation of the power grid.
As part of future activities the following validations are considered:
• Validation of FFR coordination from WP3 using a more detailed model of the power grid e.g. modified
12-bus systems
• Validation of FCR from WP3

35
6 References
[1] »Smart Energy Systems Laboratory,« 2018. [Online]. Available:
http://www.et.aau.dk/laboratories/power-systems-laboratories/smart-energy-systems/.

[2] A. Azim og Z. I. Awan, »Network Emulation, Pattern based shaping and KauNET Evaluation,« 2008.

[3] »HORIZON 2020 – WORK PROGRAMME 2014-2015,« European Commission Decision C , 2014.

[4] J. Garcia, E. Conchon, T. Pérennou og A. Brunstrom, »KauNet: Improving Reproducibility for Wireless
and Mobile Research,« 2007.

[5] V. H. NGUYEN, Y. Q. Tuan og T. Lam, »Using Power-Hardware-in-the-Loop Experiments together with

Co-simulation for the Holistic Validation of Cyber-Physical Energy Systems«.

[6] L. M. Mikkelsen, S. R. Thomsen, M. S. Pedersen og T. K. Madsen, »NetMap - Creating a Map of

Application Layer QoS Metrics of Mobile Networks Using Crowd Sourcing«.

[7] L. Petersen, F. Iov, K. Shahid, R. L. Olsen, M. Altin og A. D. Hansen, »D2 - Voltage control support and
coordination between ReGen plants in distribution systems,« 2016.

[8] Bachmann, »Bachmann Electronics - System Overview,« Bachmann, --, 2018.

[9] »ePHASORSIM - OPAL-RT Tecnologies,« 2018. [Online]. Available: https://www.opal-rt.com/systems-

ephasorsim/.

[10] »Powering Real-Time Simulation - RT Lab,« 2018. [Online]. Available: https://www.opal-

rt.com/software-rt-lab/.

36