Dynamics Requirements

Version:- 10th March 2014
EirGrid Guide to Dynamic Model Provision for PSSE
Cormac Mc Carthy
Transmission Access Planning
Document Change Control
10 Mar 2014
10 July 2013
17 May 2013 – DRAFT
21 Dec 2012
Rev diagrams in section 6
Genmon and freq control
DRAFT - Convert to Word
Some additions
Original - e-mail
1 Introduction
The provision of the generator loadflow and dynamic model information is an important step in the
connection of a generator to the electricity system. The following guidelines are provided to assist
the developer.
Overview of what files and documentation to provide
o Performance requirements of model
o How reactive capability, loadflow and dynamic models interact
o Site specific data
Model needs to be tested before sending to EirGrid
o Sample network that EirGrid provides
Pre-connection tests that EirGrid performs
Other
o Possible interaction with other models
o Technical support for model
o Updates for as-commissioned data
o Ongoing Grid Code requirements
Please see related documentation
Grid Code model requirements
Simple test network files
01 - dynamics requirements - Mar 2014 (2) Page 1 of 1
Version:- 10th March 2014
2 MODEL USABILITY
In the past, EirGrid has had problems with badly coded dynamic models. Hence, the following
requirements are now specified for dynamic model behaviour.
All models provided to the TSO must be usable. Models shall be intuitive, practical and not cause
simulation problems. Models shall be suitable for inclusion in automated software.
The practical usability considerations include but are not limited to the following;
a) Model technical parameters shall be consistent with the real physical values. This information
shall be provided either on the appropriate per unit base or in physical units.
b) The model shall be intuitive.
In the case of an Interconnector, the model shall include a HVDC line with associated
power electronics and auxiliary equipment. It is unacceptable to represent an
Interconnector as two unrelated generators.
c) The parameter ranges of the model (e.g. real and reactive power limits and range of allowable
operating voltages) shall be consistent between loadflow and dynamic models and shall be
representative of the actual Users Plant.
The User shall specify the allowable operating ranges for the User’s Plant. This shall
include real and reactive power limits and allowable voltage ranges.
Both the loadflow and dynamic models shall solve provided that the Plant is operated
within these ranges, including operation at the limit of the parameter range (e.g. operating
at max reactive power).
The combined loadflow and dynamic model shall solve without the need for manual
intervention. It is unacceptable for models to require manual adjustment before the
simulation will solve or solve without warnings. The models shall account for loss
adjustment between the loadflow and dynamic cases.
The model shall be self contained. The combined loadflow and dynamic model shall solve
without the need to run external software routines that adjust parameters in either the
loadflow case or the dynamic case or both.
d) Certain types of equipment do not function correctly at low short circuit levels. In addition,
certain models do not correctly represent the behaviour of their equipment at low short circuit
levels. The model documentation shall clarify the range of short circuit levels for which the
model is expected to perform to expected equipment behaviour. If it is the case that the model
01 - dynamics requirements - Mar 2014 (2) Page 2 of 2
Version:- 10th March 2014
will not represent performance problems under certain network conditions, then this shall be
addressed in the model documentation provided to the TSO.
e) The model shall not fill the progress monitoring files with content that is not relevant to
monitoring the technical behaviour of the dynamic simulation. It is not acceptable to include
legal disclaimers in the progress monitoring files. Models shall not spuriously report to the
monitoring file during normal operation. Models that experience instability during simulation
should report to the progress monitoring file.
f)
Models shall interface with the host software in a manner that is consistent with the behaviour
of standard library models.
Models shall report standard variables including Active Power for the duration of the
simulation.
In the case where the User’s Plant trips during simulation, the relevant models shall set
the flag that indicates that the User’s Plant has tripped.
g) It is not acceptable for the model to crash catastrophically and provide no documentary
evidence as to why the simulation failed.
01 - dynamics requirements - Mar 2014 (2) Page 3 of 3
Version:- 10th March 2014
3 Overview of Files and Documentation to Provide
3.1 Files
For PSSE, there are five files required
Loadflow (*.raw)
Reactive Power for windfarm (*.gcp)
Dynamic input date (*.dyr)
Source code for dynamic model coding
Compiled version of dynamic model (*.lib or *.obj)
A consistent suite of files is required so that the models behave in reality, in loadflow and in
dynamics in a consistent manner.
It should be the case that you can set a case up in loadflow and then run a dynamic simulation
without having to tweak any parameters. See the appendix for some more notes about this.
EirGrid also require
Documentation outlining how the models work
Block diagrams of the controller
Updated model after the commissioning tests – including report on how values were
adjusted
3.2 Capability of the Dynamic Model / Network Studies
The dynamic model should give an accurate representation of
fault ride through performance
Governor response
Response to voltage variations
o Correctly map to which bus voltage is being controlled
These are the uses to which this dynamic model will be put.
3.2.1 Pelec and Qelec
A common issue with generator models is that when the generator is tripped whether by an external
relay or by its own internal relay, the generator model may set its current injection to zero
(correctly) but some generator models fail to also set the Pelec and Qelec outputs to zero. EirGrid
requires that the user-models ensure that PELEC and QELEC are correctly set to zero if the machine
is tripped by an internal or external relay model during a simulation. The trip would be detected by
checking to see if MCSTAT has been set to zero, or if the bus type code JCODE has been set to
anything other than 2. This check should be done at each time-step. The models are undoubtedly
doing this check during Mode 1 (STRT) anyway to determine whether the machine is in-service or
not in the steady-state case.
01 - dynamics requirements - Mar 2014 (2) Page 4 of 4
Version:- 10th March 2014
3.3 Documentation requirements
Explain how different modes are implemented in the model
Fault ride though
Governor response
o Document how different modes are enabled
Different voltage control modes
Etc.
Explain how different wind assumptions are handled
3.4 Protection and Interface Relays
The model should include internal protection relays so that the windfarm can be correctly modelled.
For distribution connected windfarms, EirGrid also requires information on the interface protection
that will be applied to the windfarm but EirGrid models that separately so it does not need to be
incorporated in the model provided of the windfarm.
3.5 Model Design and Major Component Co-ordination
The physical reality of what is implemented will be reflected in the dynamic model (and perhaps in
the loadflow implementation).
Hence, the first question is how will the Statcom, the capacitor and the wind turbines be coordinated in reality. Will the control for the Statcom and the capacitor be separate from the
windfarm or is there an existing windfarm controller which can be used to send signals to both the
wind turbines and the statcom and capacitor or will a new windfarm controller be supplied which
will control everything? Does the power park controller determine the responses for all types of
operation? E.g. it might be the case that a power park controller dominates the allocation of
reactive power provision for steady state voltage control but absents itself from fault ride through
where the statcom and wind turbines act based on their own models.
Some windfarms can be quite complex. It is important to EirGrid that any complexity is efficiently
handled in the model setup and design.
3.6 Component Model or Performance Model
This section to be updated.
01 - dynamics requirements - Mar 2014 (2) Page 5 of 5
Version:- 10th March 2014
3.7 Site Specific Data
Wind turbine models and wind turbine data contains some information that does not change and
some that does change depending on each particular installation.
EirGrid requires that the developer provide a data set with all the correct site specific settings.
The specific requirements for individual manufacturers are included in the Appendix.
[note – probably correct not to send one manufacturer’s requirements to the other manufacturers]
This section to be updated.
3.8 Model to be tested before sending to EirGrid and provided with the
test network
In order to minimise the risk of delays associated with modelling problems for this wind farm EirGrid
suggests that an overall integrated PSSE model of the wind farm be provided.
Typically this would involve supplying the following with the wind farm connected to a simple test
network / equivalent model representation of the power system:
EirGrid will provide both the short circuit levels for the fault ride through test and a template suite of
files to assist in creation of the model.
A PSSE load flow case file modelling any 38/20 kV circuits, transformers, wind
turbine generators, load, busbars, Statcoms etc. all connected to an infinite bus. This
file is known as a .sav file.
PSSE Dynamic models of the various wind turbine types (aggregated so that one
wind farm of the same turbine type is represented in PSSE as one generator), any
appropriate wind farm controllers and any Statcoms.
A .dyre file containing all the appropriate parameters to make the dynamic models
work, e.g. gains, time constants, site specific protection etc.
The above is required in PSSE version 30.3.2 and PSSE version 32. This should include a description of
how the overall integrated was built, the PSS/E Dyr dynamic data, library file (*.obj or *.lib) and
raw/.gcp/.sav load flow file.
3.9 Source Code
As EirGrid moves to future versions of PSSE, it will be necessary to compile the dynamic model to
work with the future versions of PSSE. If EirGrid has the source code, this can be done without
recourse to the developer and the software provider.
01 - dynamics requirements - Mar 2014 (2) Page 6 of 6
Version:- 10th March 2014
4 Pre-connection Simulation Tests that EirGrid performs
4.1 Pre connection System Integrity Tests
EirGrid includes the generator model in its model of the system and checks that the generator as
modelled does not represent at threat to the integrity of the power system.
4.2 Pre connection Fault Ride through Tests
EirGrid check the fault ride through tests using the test network with assumed low short circuit level
conditions. These low short circuit level conditions are for the fault ride through tests only. Other
parameter settings should be set as the manufacturer normally does.
Check generator responses as specified in the Grid Code against Voltage dips measured at the
connection bus
15% retained for 625 ms
40% retained for 990 ms
90% retained for 3 sec
01 - dynamics requirements - Mar 2014 (2) Page 7 of 7
Version:- 10th March 2014
4.3 How Fault Ride Through test is performed1
It is most likely that generator fault ride through is most difficult to achieve at times of weak
network conditions. For this reason, EirGrid provides generators with the system strength (and
Thevenin equivalents) at the connection point for these weak network conditions. The expectation
is that this is used to generate a simple test network so that the applicant can simulate the fault ride
through and demonstrate this to the satisfaction of EirGrid.
The diagrams below show a combination of simple equivalent network for the main transmission
system and a model of the local network (110kv station) to which the generator is expected to
connect.
It is deemed useful to provide a description of the dynamic simulation which EirGrid performs which
should help generators and their manufactures to
The test is taken to represent the following
a fault on a transmission circuit in the vicinity and which fault is typically cleared by
the tripping of a circuit
the expectation that the fault in question occurs reasonably close to the generator
Taking these considerations and depending on the local network configuration and how the
generator is connected, there are two options for analysis. Either the fault that is being simulated is
presumed to be back within the transmission network or the fault is considered to be local to the
generator. These alternatives are shown as follows:
110kV or 220kV
110kV or 220kV
Equivalent of
Transmission
System
R
X
thev thev
R
X
thev thev
System
Equivalent
System
Equivalent
R, X = zero
R, X = zero
ΔR, ΔX
ΔR, ΔX
Fault and trip
Test generator
and local
network
Test
generator
Test
generator
(a) Dynamic Simulation – Fault Ride Through – Fault and circuit trip in network
1
Question under consideration – is the applicant expected to model the interaction of local generation, at the
same 110kv station or generation tailed from the 110kV station?
01 - dynamics requirements - Mar 2014 (2) Page 8 of 8
Version:- 10th March 2014
110kV or 220kV
110kV or 220kV
R
R
X
thev thev
Equivalent of
Transmission
System
X
thev thev
System
Equivalent
System
Equivalent
R, X = zero
?R, ?X
R, X = zero
?R, ?X
Fault and trip
Test generator
and local
network
Local network
Local network
Test
generator
Test
generator
(b) Dynamic Simulation – Fault Ride Through – Fault and circuit trip locally
For the situation where the fault and circuit trips occurs within the network, the network strength
obviously changes during the event with the loss of the circuit. In other words, the network is
stronger (more circuits in service) before the fault and at fault inception compared with the weaker
network (one circuit removed from service) for post fault recovery. In the simple test network, this
is achieved by switching out the zero impedance branch in the simple test network at the point of
fault clearance. This is why EirGrid provides two values of system strength for these types of fault,
one for the first half of the fault and the other for the fault clearance and recovery.
01 - dynamics requirements - Mar 2014 (2) Page 9 of 9
Version:- 10th March 2014
4.4 Grid Code Requirement – ongoing
Just because EirGrid has performed a limited number of studies in advance of connection of the
generator to the power system does not mean that the generator is henceforth removed of the
responsibility to perform in compliance with the Grid Code requirements and nor should it be taken
as a statement that the generator is in all ways fully Grid Code compliant.
5 Other
5.1 Different Equipment Suppliers and the Model
Developers have asked EirGrid for advice on model requirements.
It may the case for relatively complex windfarms where there is a mix of several different
components (e.g. wind turbines, power farm controllers, statcoms and capacitors) that each is
provided by different manufacturers and that one of these opts to provide the model.
Please note that it is important from a contractual perspective that the individual parties are
contracted to both support their parts of the model and also to support the operation of the
combined model. It also needs to be clear with whom the overall responsibility for the operation of
the model lies.
5.2 Impact on other windfarm models with the same dynamic model in
our simulation
It is a feature of dynamic simulation that typically all the windfarms from a given manufacturer in
EirGrid’s system model are on the same version of the manufacturer’s dynamic model (e.g version
7.4, 5.2 or whatever). It is a feature of model evaluation that on occasion during the evaluation the
manufacturer would recommend moving to a new version of the model.
This can only be achieved if all other windfarms also move to the new version of the model.
Normally, the input data for the models stay the same between versions but on occasion the input
data can vary. In this instance, the manufacturer will be required to support EirGrid in bringing the
other windfarm models to the new version. Historically, this has not been a very big deal since the
manufacturer has the dyre data for all of its turbine types anyway but this support will be required.
5.3 Update for as commissioned data
After the commissioning tests, the developer shall be required to advise EirGrid of any changes that
may be required to the model information.
01 - dynamics requirements - Mar 2014 (2) Page 10 of 10
Version:- 10th March 2014
5.4 Future technical support
If an integrated controller is written, EirGrid is entitled to expect that as EirGrid moves from one
version of our analysis software to another (e.g. from Psse v30 to future versions of PSSE) that by
recompiling the model for the new version of PSSE that the model will continue to work.
Also, if the controller integrates with a specific version of the wind turbine models, EirGrid is entitled
to expect that if the windfarm manufacturer moves the wind turbine model onto other versions in
the future that the integrated windfarm model will continue to work with future versions of the
wind turbine models from the manufacturer.
It would be nice to expect that these transitions would be seamless but this is not always the case.
In the event that the model stops working in the future, EirGrid will require support to get it working
again.
5.4.1 Source Code for Dynamic Models
EirGrid would advise Windfarm Developers to provide the source code for the model which may
allow for some future recompiling and future possible debugging to be achieved with less interaction
with (and therefore cost for) the developer. In particular, this is advisable where the dynamic
modelling information for different parts of the windfarm and certain devices are provided by
different manufacturers.
01 - dynamics requirements - Mar 2014 (2) Page 11 of 11
Version:- 10th March 2014
6 Appendix – Site Specific and Manufacturer Specific Requirements
6.1 Site Specific Data
Typically dynamic models have a file of input data (the *.dyr file). The dyre data typically consists of
model values and parameters which are fixed for a given turbine type. In general there are also a
number of settings and modes that need to be set for each wind turbine model and are specific to
the windfarm. These should be set appropriately for the WINDFARM site in the integrated model
provided. These include fault ride through modes, voltage and frequency control modes and
sometimes windfarm settings that are related to expected system strength.
01 - dynamics requirements - Mar 2014 (2) Page 12 of 12
Version:- 10th March 2014
7 Appendix - Simple Test Network
7.1 System Being Represented
Real Network
Simple Case – for model evaluation
Base case – usually, with circuit out on maintenance
MVA base = 100 MVA
Thevenin impedance – base case
R
thev
Other
local
network
R.X = zero
ΔR, ΔX
X
thev
Equivalent of rest of
system
Test gen(s)
Load
Test gen(s)
Generator and local
network to be tested
Note: sometimes (especially for tail fed generator stations), the simulation involves a fault and
clearance but without the trip of a circuit that changes the network strength.
01 - dynamics requirements - Mar 2014 (2) Page 13 of 13
Version:- 10th March 2014
7.2 Use of Test Network – Scenario 1
The normal fault ride through study is done presuming that a fault applies on one of the circuits
connecting the generator to the rest of the system. This is referred to as scenario 1. It is assumed
that when the fault is cleared, that a circuit is also switched out so that the network strength is lower
for post fault clearance. This is handled in the test network, as shown above, by applying the fault to
the zero impedance branch in the model and tripping this branch when the fault is cleared in the
simulation.
01 - dynamics requirements - Mar 2014 (2) Page 14 of 14
Version:- 10th March 2014
7.3 Use of Test Network – Scenario 2
Real Network
Simple Case – for model evaluation
Base case – usually, with circuit out on maintenance
Equivalent of rest of system
MVA base = 100 MVA
Thevenin impedance
– base case
R
thev
X
thev
Fault and trip
this circuit to
clear f ault
R.X =
zero
Other
local
network
No change in
network
strength after
the fault!
ΔR, ΔX
Apply and clear f ault –
no circuit trips
Test gen(s)
Scenario 2
Load
Where the worst case is fault and trip of local circuit
but which does not weaken the connection between
the generator and the rest of the system .
Then, for the study, apply and clear the fault but no
circuit is tripped.
Test gen(s)
Generator and local
network to be tested
However, it is sometimes the case that the most onerous fault is not one that is expected to weaken
the connection between the generator under test and the rest of the system when fault is cleared.
This is referred to as Scenario 2. This is handled in the test network, as shown above, by simply
applying and clearing a fault and for which there is no need to trip any circuits during the simulation.
01 - dynamics requirements - Mar 2014 (2) Page 15 of 15
Version:- 10th March 2014
8 Appendix – Model Requirement
8.1 Smooth Transition between Loadflow and Dynamics
EirGrid has a system model that contains windfarm and generator models for the whole system. It is
important for the efficient modelling and analysis of the system that it be possible to solve a case in
loadflow and then move to dynamics as efficiently as possible. Hence, the loadflow file and dynamic
models of individual windfarms should be as compatible as possible. The models should be written
so as to achieve this objective.
In loadflow,
*.gcp file
Reactive capability of windfarms for different power output (there may be different *.gcp
inputs depending on windfarm mode (e.g. constant power factor, voltage control, etc.)
*.raw file
Windfarm transformers (target voltage range, which bus is being controlled, tapping range,
only for steady state – not used in dynamic studies)
Generator (target voltage, which bus is being controlled)
Statcoms and capacitors (target voltage range, which bus is being controlled)
If there is an interaction between several of the components (e.g. try and keep the spare reactive
power on the statcom rather than on the turbines) that impacts materially on the behaviour of the
response it may be necessary to discuss with EirGrid how this is implemented in loadflow.
8.2 Reactive Power Capability
*.gcp file in psse
Windf arm – reactive capability curve
Power
MW
- MVAr
(Leading MVAr)
Reactive Power
01 - dynamics requirements - Mar 2014 (2) Page 16 of 16
+ MVAr
(Lagging MVAr)
Version:- 10th March 2014
9 Appendix – Check List for Generators
The following files are provided
o *.raw
o *.gcp
o *.dyr
o *.obj or *.lib
 Source code for same
o *.sav
The case has been simulated in Psse 30 and works
Documentation
The data has been verified
o Interface protection information
o Correct operation of ancillary equipment (e.g. statcoms, capacitors, etc.) and
windfarm controllers
o Smooth transition between loadflow and dynamics for different power outputs
and network conditions
o Transformer impedances and ratios
o Network circuit lengths and impedances
o Correct site specific dyre data including control modes
Advice from the wind turbine manufacturer as to whether this information will require
an update to information for other windfarms (share turbine type)
Note that an updated dynamic model will be provided to EirGrid (if needed) after
commissioning
Note that an updated dynamic model will be required should plant performance
change in the future
01 - dynamics requirements - Mar 2014 (2) Page 17 of 17

Download Report