ITesla- 6_Dynamic Models LV (2)

8/17/2019 ITesla- 6_Dynamic Models LV (2)

1/57

Applying Modelica and FMI Technologies

for

Power System Model Validation in the iTesla Project

Prof.Dr.-Ing. Luigi Vanfretti

[email protected]

Associate Professor, Docent

Electric Power Systems Dept.

KTH

Stockholm, Sweden

[email protected]

Special Advisor in Strategy and Public Affairs

Research and Development Division

Statnett SF

Oslo, Norway

E-mail: [email protected]

Web: http://www.vanfretti.com

2nd

iTesla/Umbrella Common Workshop – Jan. 14, 2014Brussels, Belgium


2/57

Outline

• Background: modeling and simulation of large scale power systems in the iTesla

context

• Why Model Validation?

– Motivation

– Overview of WP3 tasks in iTesla

• Unambiguous power system modeling and simulation using Modelica-Driven Tools – Limitations of current modeling approaches used in power systems

– Object oriented equation – based modeling of physical systems using the Modelica

language

• Mock-up SW prototype for model validation:

– Model validation software architecture based using Modelica tools and FMI

Technologies

– Prototype proof-of-concept implementation: the Rapid Parameter Identification Toolbox

(RaPId)

– Sample application: aggregate load model identification in Scottish Power Grid

distribution network


3/57

UNAMBIGUOUS POWER SYSTEM MODELINGAND SIMULATION USING MODELICA-DRIVEN

TOOLS

Modeling and Simulation


4/57

Large Scale Power Systems

To operate large power networks, planners and operators need

to analyze variety of operating conditions – both off-line and in

near real-time (power system security assessment).

Different SW systems have been designed for this purpose.

But, the dimension and complexity of the problems are

increasing due to growth in electricity demand, lack of

investments in transmission, and penetration of intermittent

resources.

New tools are needed!

Current and new tools will need to perform simulations:

• Of complex hybrid model components and networks with

very large number of continuous and discrete states.

• Models need to be shared, and simulation results need

to be consistent across different tools and simulation

platforms…

• If models could be “systematically shared at the equation

level”, and simulations are “consistent across different SW

platforms” – we would still need to validate each new

model (new components) and calibrate the model to

match reality.


5/57

Power system dynamics

10-7 10-6 10-5 10-4 10-3 10-2 10-1 1 10 102 103 104

Lightning

Line switching

SubSynchronous Resonances,transformer energizations…

Transient stability

Long term dynamics

Daily load

following

seconds

Electromechanical

Transients

Electromagnetic Transients

Quasi-Steady

State Dynamics


6/57


10-7 10-6 10-5 10-4 10-3 10-2 10-1 1 10 102 103 104

Lightning

Line switching


Transient stability

Long term dynamics

Daily load

following

seconds

Electromagnetic TransientsInteraction between the electrical field of

capacitance and magnetic field of inductances in

power systems.

Ex : lightning impact, line switching

May produce : overvoltages, overcurrents,

abnormal waveforms, electromechanical

transients

Electromechanical

Transients


Quasi-Steady

State Dynamics


7/57


10-7 10-6 10-5 10-4 10-3 10-2 10-1 1 10 102 103 104

Lightning

Line switching


Transient stability

Long term dynamics

Daily load

following

seconds

Electromechanical

Transients


Electromechanical Transients

Interaction between the electrical energy stored

in the system and the mechanical energy storedin the inertia of rotating machines

Ex : Power oscillations

May produce: system breakup.

Quasi-Steady

State Dynamics


8/57

Power system dynamics challenges

for simulation

10-7 10-6 10-5 10-4 10-3 10-2 10-1 1 10 102 103 104

Lightning

Line switching


Transient stability

Long term dynamics

Daily load

following

seconds

The presence of very small

time scales and large amount

of discrete switches.

Difficult to simulate very

large networks.

This is usually deal with by

discretizing the model and to

solve it using discrete solvers.

Models are simplified (averaged) to allow for simulation

of very large networks.

Ad-hoc solvers have been developed to reduce simulation

time, but usually the “model” is “interlaced” with the

solver (inline integration)

Generally there are no

discrete events.

(Ad-hoc DAE solvers)

The models are simplified further byneglecting most dynamics (replacing most

differential equations by algebraic equations).

(Ad-hoc DAE solvers)


9/57

10-7 10-6 10-5 10-4 10-3 10-2 10-1 1 10 102 103 104

Lightning

Line switching

SubSynchronous

Resonances, transformer

energizations…

Transient stability

Long term dynamics

Daily loadfollowing

seconds

Power system phenomena and

domain specific simulation tools

Broad range of time constants results in specific domain tools for simulation.

Non-exhaustive list. There exists other proprietary and few OSS tools.

Algebraic

“Steady

State”

(Power

Flow)

Ad-hoc

Initialization of Dynamic

States

=

Dynamic

equilibrium

Simulation

PSS/E


10/57

Power System Time-Scale Modeling

from this point on

10-7 10-6 10-5 10-4 10-3 10-2 10-1 1 10 102 103 104

Lightning

Line switching


Transient stability

Long term dynamics

Daily load

following

seconds

Phasor Time-

Domain Simulation


11/57

Power System Dynamics in EuropeFebruary 19th 2011

49.85

49.9

49.95

50

50.05

50.1

50.15

08:08:00 08:08:10 08:08:20 08:08:30 08:08:40 08:08:50 08:09:00 08:09:10 08:09:20 08:09:30 08:09:40 08:09:50 08:10:00

f [ H z ]

20110219_0755-0825

Freq. Mettlen Freq. Brindisi Freq. Wien Freq. Kassoe

Synchornized Phasor Measurement Data


12/57

Power System Phasor-Time Domain

Modeling and Simulation Status Quo

10-7 10-6 10-5 10-4 10-3 10-2 10-1 1 10 102 103 104

Lightning

Line switching


Transient stability

Long term dynamics

Daily load

following

seconds

Phasor Time-

Domain Simulation

PSS/E

Status Quo:

Multiple simulations, with their own interpretation

of different model features and data “format”.

Implications of the Status Quo:

- Dynamic models can rarely be shared in a

straightforward manner without loss ofinformation on power system dynamics.

- Simulations are inconsistent without drastic

and specialized human intervention.

Beyond general descriptions and parameter

values, a common and unified modeling language

would require a formal mathematical description

of the models.

These are key drawbacks of today’s tools for

tackling pan-European problems.


13/57

WHY MODEL VALIDATION?

Motivation and Overview of WP3


14/57

Why “Model Validation”?

• iTesla tools aim to perform“security assessment”

• The quality of the models

used by off-line and on-line

tools will affect the result

of any SA computations – Good model : approximates

the simulated response as

“close” to the “measured

response” as possible

• Validating models helps in

having a model with “goodsanity” and “reasonable

accuracy”:

– Increasing the capability of

reproducing actual power

system behavior (better

predictions) 2 3 4 5 6 7 8 9

-2

-1.5

-1

-0.5

0

0.5

1

∆ P

( p u )

Time (sec)

Measured Response

Model Response

WECC Break-up 1996

BAD Model for Dynamic

Security Assessment!!!


15/57

The Model Validation Loop

• The major ingredients of the model validation loop below have been

incorporated into the proposed general framework for validation:

• A model can NEVER be accepted as a final and true description of the actual

power system.

– It can only be accepted as a suitable (“Good Enough”) description of the system for specific

aspects of interest (e.g. small signal stability (oscillations), etc.)

– Model validation can provide confidence on the fidelity and quality of the models for

replicating system dynamics when performing simulations. – Calibrated models will be needed for systems with more and more dynamic interactions


16/57

Requirements for the Model

Validation Process•

Model Validation – Inherently depends on two main sources of information:

• An assumed model

– This model includes the details models of power system components and

controls, during

– The power system topology and any related changes, during

• A set of measured data

– This includes PMU data, fault-recorder data, and any other source of

measurements capable of capturing power system dynamics, during

– Snapshots from SCADA/EMS, indicating the topology and particular

measurements , during

– During an “experiment”

• Experiment: in our context we can loosely define it as a particular “event”

that excited the power system dynamics.

•Types of experiments: staged tests, transient disturbances, “blue sky”data, etc.


17/57

Different Validation Levels

• Component level

– e.g. generator such as wind

turbine or PV panel

• Cluster level

– e.g. gen. cluster such as wind

or PV farm

• System level – e.g. power system small-signal

dynamics (oscillations)


18/57

The Power System “Data” Set

• Needs and Roles

of Models andMeasurements

for Off-line

Dynamic Model

Validation

Models

Static Model

Standard Models

Custom Models

Manufacturer Models

System Level

Model Validation

Measurements

Static

Measurements

Dynamic

Measurements

PMU Measurements

DFR Measurements

Other

Measurement,

Model and Scenario

Harmonization

Dynamic Model

SCADA Measurements

Other EMS Measurements

Static Values:

- Time Stamp

- Average Measurement Values of P, Q and V

- Sampled every 5-10 sec

Time Series:

- GPS Time Stamped Measurements- Time-stamped voltage and current phasor meas.

Time Series with single time stamp:

- Time-stamp in the initial sample, use of sampling frequency to

determine the time-stamp of other points

- Three phase (ABC), voltage and current measurements

- Other measurements available: frequency, harmonics, THD, etc.

Time Series from other devices (FNET FDRs or

Similar):

- GPS Time Stamped Measurements

- Single phase voltage phasor measurement, frequency, etc.

Scenario

Initialization

State Estimator

Snap-shop

DynamicSimulation

Limited visibility of custom or manufacturer

models will by itself put a limitation on the

methodologies used for model validation


19/57

Overview of Model Validation work in iTesla

Parameter

Estimation using

measurements and

high bandwidth

simulated responses

Validated Device

Models

Methods for the

Assessment of large-

power network

simulation responses

againstmeasurements

Methods to

Generate Aggregate

Models of PV and

Wind Farms

Validated Aggregate

Models

Tasks on Device Model

Validation and Parameter

Estimation

Tasks on Methods to

Obtain Aggregate Models

and their Validation

Tasks on Large-Power System

Model Dynamic Performance

Assessment

WP3

Off-line validation of dyanmic models

Dynamic

performance

discrepancy indexes

Synchronized Phasor Measurements and high bandwidth model simulated responses

R e q u i r e m e n t s

f o r V a l i d a t i o n L

i m i t a t i o n s o f c o m m o n m o d e l i n g

p

r a c t i c e s

Task on

Validation

Requirements

Task on Identification

of modeling limitations

of current practices

Validated Models and

Model Parameters,

Updated Models, and

Discrepancy Indexes

Unvalidated Models,

Models that need

updates, Etc.

WP2

Data Needs, Collection and Management

F u n c t i o n a l

S p e c i f i c a t i o n o f

W P 6 T o o l s

Task

3.1

Task

3.2

Task

3.3

Task

3.4

Task

3.5


20/57

iTesla WP3 Goals and Tasks

• To validate models of components (individual or aggregate)

• To validate system-wide power system dynamic behavior

• NB: Focus is on validating models used in Phasor Time Domain

simulations

• Tasks:

• Completed

– WP3.1: Requirements for validation [RTE]

– WP3.2: Identification of limitations of common modeling approaches [TE]

• On-going

– WP3.3: Validation of device models [KTH]

– WP3.4: Aggregated dynamic models of variable generation sources and

loads [DTU]

– WP3.5: System-wide validation of power system dynamic behavior [KTH]


21/57

UNAMBIGUOUS POWER SYSTEM MODELINGAND SIMULATION USING MODELICA-DRIVEN

TOOLS

Modeling and Simulation


22/57

Power System Modelinglimitations, inconsistency and consequences

• Causal Modeling:

– Most components are defined using causal block diagram definitions.

– User defined modeling by scripting or GUIs is sometimes available (casual)

• Model sharing:

– Parameters for black-box definitions are shared in a specific “data format”

– For large systems, this requires “filters” for translation into the internal data format of each program

• Modeling inconsistency:

– For (standardized casual) models there is no guarantee that the model definition is implemented “exactly” in the

same way in different SW

– This is even the case with CIM dynamics, where no formal equations are defined, instead a block diagram

definition is provided.

– User defined models and proprietary models can’t be represented without complete re-implementation in each

platform

•Modeling limitations: – Most SWs make no difference between “model” and “solver”, and in many cases the model is somehow

implanted within the solver (inline integration, eg. Euler or trapezoidal solution in transient stability simulation)

• Consequence:

– It is almost impossible to have the same model in different simulation platforms.

– This requires usually to re-implement the whole model from scratch (or parts of it) or to spend a lot of time “re-tuning” parameters.


23/57





• Model sharing:









platform



• Consequence:



This is very costly!


24/57





• Model sharing:









platform



• Consequence:



This is very costly!

An equation based

modeling language canhelp in avoiding all of

these issues!


25/57

• Modeling and simulation should not be ambiguous: it should beconsistent across different simulation platforms.

• For unambiguous modeling, model sharing and simulation,

Modelica and Modelica Tools can be used due to their

standarized equation-based modeling language. • We have utilized Modelica in iTesla for our Model Validation WP,

providing:

– Building blocks for power system simulation: iTelsa PS Modelica Library

– The possibility to use FMUs for model sharing in general purpose tools

and exploiting generic solvers

UnambiguousPower System Modeling and Simulation


26/57

Equation-based modeling

• Defines an implicit relation between variables. The data-flow between

variables is defined right before simulation of the model (not during the

modelling process!)

• A system is described in terms of differential-algebraic equations.

• A system can be seen as a complete model or a set of individual

components.

• The user is in principle only concerned with the model creation, and

does not have to deal with the underlying simulation engine (only ifdesired).

• It also allows decomposing complex systems into simple sub-models

easier to understand, share and reuse


27/57

Graphical Equation Based

Modeling• Each icon represents a physical

component (i.e. a generator, wind

turbine, etc.)

• Composition lines represent the

actual interconnections between

components (e.g. generator to

transformer to line to …)

• Physical behavior of each

component is described byequations.

• There is a hierarchical

decomposition of each component.

Component 1

Component 2

Component 3


28/57

Modelica

Non-proprietary, object-oriented, equation-based hybrid modeling

language for modeling complex cyber-physcial systems.

Models are described by differential, algebraic or discrete equations.

Suited for modeling large, complex, and heterogeneous systems

No fixed causality imposed on the models.

It provides a strict separation between the model and the solver.

The model is completely independent from the solver, and many different

solvers can be used for simulation.

Specialized algorithms can be utilized to enable efficient handling of large

models having more than one hundred thousand equations.

There exist numerous simulation environments open source and

commercial.

Models can be exchanged among different environments.

i.e., Modelica is not a tool


29/57

Declarative languageEquations and mathematical functions allow acausal modeling,

high level specification, increased correctness

Multi-domain modeling

Combine electrical, mechanical, thermodynamic, hydraulic,

biological, control, event, real-time, etc...Everything is a class

Strongly typed object-oriented language with a general class

concept, Java & MATLAB-like syntax

Visual component programmingHierarchical system architecture capabilities

Efficient, non-proprietaryEfficiency comparable to C; advanced equation compilation,

e.g. 300 000 equations, ~150 000 lines on standard PC

ModelicaThe Next Generation Modeling Language

Used with permission of Prof. Peter Fritzson:


30/57

Object OrientedMathematical Modeling with Modelica

• The static declarative structure of a mathematical model is

emphasized

• OO is primarily used as a structuring concept

• OO is not viewed as dynamic object creation and sending messages

• Dynamic model properties are expressed in a declarative way

through equations.• Acausal classes supports better reuse of modeling and design

knowledge than traditional classes



31/57

iTesla Power Systems

Modelica Library• Power Systems Library:

– The Power Systems library developed using as reference Eurostag and PSAT models

converted to Modelica

– The library has also been tested in several Modelica supporting software:

OpenModelica, Dymola, SystemModeler and Jmodelica.org.

– Components and systems are validated against Eurostag’s and PSAT results (or otherreference models)

• New components and time-driven events are being added to this

library in order to simulate new systems.

– Efforts will be put in replicating all of Eurostag’s and PSAT models in the library, and

adding new models of RES and other power electronic controlled devices

– PSS/E components will also be included and validated.

– Automatic translator from domain specific tools to Modelica will use this library’s

classes.

• Several test power system models have been built and simulated in

Dymola, OpenModelica, SystemModeler and Jmodelica.org.


32/57

iTesla Power Systems Modelica Library

in OpenModelica

l d l l i i d li


33/57

Example Model Implementation in Modelica

of a WT Type 3 (DFIG)

• Each sub-block was implemented independently in Modelicaand tested

• Each sub-block contains its own intialization equations,

dynamic and algebraic equations

• Parameters are passed from the upper layer to the sub-blocks

PitchControl windBlk

ElecBlk ElecDynBlk

MechaBlk

,


34/57

Pitch Control Block Details

model PitchControlModelica.Blocks.Interfaces.RealInput omega_m "Real voltage"; Modelica.Blocks.Interfaces.RealOutput theta_p(start=theta_p0) "saturated

theta_p" ; Real theta_pI "internal non-saturated theta_p"; Real phi;

initial equation(Kp*phi - theta_pI)/Tp = 0; equation

// Dynamics of the pitch angle, the anti-windupif omega_m theta_p_max and der(theta_pI)


35/57

SW-to-SW ValidationPSAT vs. Modelica Model

Reference

DFIG Model

in PSAT

Implemented Model in Modelica

SW to SW Validation


36/57

SW-to-SW ValidationResponse to a three phase fault

= 10−3


37/57

FMI and FMUs

• FMI stands for flexible mock-up interface:

– FMI is a tool independent standard to support both model exchange

and co-simulation of dynamic models using a combination of xml-files

and C-code

• FMU stands for flexible mock-up unit

– An FMU is a model which has been compiled using the FMI standarddefinition

• For what?

– Model Exchange• Generate C-Code of a model as an input/output block that can be utilized

by other modeling and simulation environments

– Co-simulation

• Couple two or more simulations in a co-simulation environment.

• The FMI Standard is now supported by 35 different tools.


38/57

FMUs for UnambiguousModel Sharing between different tools

• FMUs can help for power system simulation:

– FMUs of specific devices can be generated in a specific

tool, and then incorporated into an overall power system

model in another tool (need a co-simulation environment)

– FMUs of a complete model can be generated in one

environment and then shared to another environment.

• The key idea to understand here is that the model is not lockedinto a specific simulation environment!

• We explore the second option.

Sharing FMUs with


39/57

Sharing FMUs withMATLAB/Simulink and the FMI Toolbox

• The model validationarchitecture needs to

exploit the sys id. tools

in MATLAB (explained

latter).

• FMUs generated from

Dymola.

• FMUs allow for model

simulation in Matlabfor self-contained

integration of

prototype model

validation tool.

FMU compilationof the Modelica

Model using

Dymola

Model Importinto MATLAB

using the FMI

Toolbox

Output

configuration

and simulation


40/57

Results & Lessons Learned

No.1:

• A Modelica library has been developed and tested in different Modelica tools.

• Modelica allows for unambiguous model sharing across different simulation software

– This is natural thanks to the Modelica language

No.2:

• Modeling of complex power system controls and protections can take into account

discrete events – Flexibility of modeling language and solvers to handle discrete events.

No.3:

• It is possible to simulate large models (although not very large so far) of power systems.

– Proper initialization will allow to determine the suitability for real-life networks

– Automatic conversion from domain specific tool will be required

No.4:

• FMUs allow to use general purpose tools for specific power system applications (model

validation)

• FMUs allow sharing of models without revealing the internal model definition/structure

(useful for manufacturer specific models).


41/57

The Power of ModelicaUnambiguous Modeling Simulation and Optimization of

Power Systems across Multiple SW Platforms

Graphical Modeling and

Simulation OptimizationFMI Support

OpenModelica

OMEdit, OMOptim

Dymola

Jmodelica.org

WSMLink for

Mathematica

Wolfram System Modeler (WSM)

and

WSMLink for Mathematica

FMI Toolbox + Matlab/Simulink

Textual

Modeling

Text Editor

Text Editor

Text

Editor

Text Editor

Planned

Tested and validatedThe same model can be shared and simulated without ambiguity

in 5 different SW platforms from completely different vendors!

Function

alities ofthe Tool

Different

Tools

Via additional library


42/57

Block Diagram (e.g. Simulink, ...) or

Proprietary Code (e.g. Ada, Fortran, C, C++, ...)

vs Modelica

Proprietary

Code

Block Diagram

Modelica

Systems

Definition

System

Decomposition

Modeling of

Subsystems

Causality

Derivation

(manual derivation of

input/output relations) Implementation Simulation

ModelicaFaster Development and Lower Maintenance

than with Traditional Tools



43/57

ITESLA MODEL VALIDATION MOCK-UP SOFTWARE PROTOTYPE

RaPId: a proof of concept implementation using Modelica and the FMI

Standard within Matlab/Simulink

What is required from a


44/57

What is required from a

SW architecture for model validation?

Models

Static Model

Standard Models

Custom Models

Manufacturer Models

System Level

Model Validation

Measurements

Static

Measurements

Dynamic

Measurements

PMU Measurements

DFR Measurements

Other

Measurement,

Model and Scenario

Harmonization

Dynamic Model

SCADA Measurements

Other EMS Measurements

Static Values:

- Time Stamp

- Average Measurement Values of P, Q and V

- Sampled every 5-10 sec

Time Series:


- Time-stamped voltage and current p hasor meas.

Time Series with single time stamp:

- Time-stamp in the initial sample, use of sampling frequency to

determine the time-stamp of other points

- Three phase (ABC), voltage and current measurements

- Other measurements available: frequency, harmonics, THD, etc.

Time Series from other devices (FNET FDRs or

Similar):


- Single phase voltage phasor measurement, frequency, etc.

Scenario

Initialization

State EstimatorSnap-shop

DynamicSimulation

Limited visibility of custom or manufacturer

models will by itself put a limitation on the

methodologies used for model validation

• Support “harmonized”

dynamic models

• Process

measurements using

different DSPtechniques

• Perform simulation of

the model

• Provide optimization

facilities forestimating and

calibrating model

parameters

• Provide user

interaction

Mockup SW Architecture


45/57

User Target

(server/pc)

Model Validation Software

iTesla WP2 Inputs to WP3: Measurements & Models

Mockup SW ArchitectureProof of concept of using MATLAB+FMI

EMTP-RV and/or other HB model simulation traces and

simulation configuration

PMU and other available

HB measurements

SCADA/EMS Snapshots +

Operator Actions

M A T L A B

MATLAB/Simulink(used for simulation of the Modelica Model

in FMU format)

FMI Toolbox for MATLAB(with Modelica model)

Model Validation Tasks:

Parameter tuning, model

optimization, etc.

User

Interaction

.mat files

HARMONIZED MODELICA MODEL:

Modelica Dynamic Model Definition for

Phasor Time Domain Simulation

Data Conditioning

iTesla Cloud or

Local Toolbox

Installation

Internet or LAN

.mo files

.mat filesAny measurement data is

converted to .mat format.

FMU compiled

by another toolFMU


46/57

Proof-of-Concept Implementation of the

iTesla Model Validation SW Mock-Up Prototype

•RaPId is our proof of concept implementation

• RaPId is meant for use in WP3.3 and WP3.4 used

for Component Parameter Estimation and

Aggregate Model Parameter Estimation and

Validation

• RaPId is a toolbox providing a framework for

parameter identification.

• A Modelica model, made available through a

Flexible Mock-Unit (i.e. FMU) in the Simulink

environment, is characterized by a certain number

of parameters whose values can be independently

chosen.

• The model is simulated and its outputs are

measured.

• RaPId attempts to tune the parameters of the

model in so as to satisfy an objective function (e.g.

obtain the best curve fitting) between the outputs

of the Simulation and the experimental

measurements of the same outputs provided by

the user.


47/57

What does RaPId do?

1 Output (and optionally input) measurements are provided to RaPId by the user.

2 At initialisation, a set of parameter is generated randomly or preconfigured in RaPId.

3 The model is simulated with the parameter values given by RaPId.

4 The outputs of the model are recorded and compared to the user-provided measurements.

5 A fitness function is computed to judge how close the measured data and simulated data are to each other

Based on the fitness computed in (5) a new set of parameters is computed by RaPId2’


48/57

RaPId in Action Parameter estimation for an aggregate load model

• The objective is to determine which vector of parameters θ

gives the best fit on the output

• The parameterized model of this system is written in Modelica

and imported into the MATLAB/Simulink environment thanks

to the FMI toolbox

() () System studied

System to be

identified

S(θ)

() ()

θ


49/57

Identification Setup

System to beidentified

S(θ)

() y()

θ

Simulation data

Pre-processed

measurement data

Optimization

Algorithm

y()

Simulation


50/57

Example for a voltage dependent load

// Equations from the load modelv=sqrt(p.vr*p.vr + p.vi*p.vi); anglev=atan2(p.vi, p.vr); P=P0*v^alphap; Q=Q0*v^alphaq;

We choose = (,)The measurement give the evolution of the

active and reactive power and but alsothe voltage magnitude and angle

The fitness function is defined by the quadratic criterion:

θ = � (() ())2 + (() ())2+(() ())2+(() ())2)0

)

For this first test of the method, the identified system is defined by the same

model as the parametrized system.

Ultimately the identification will be performed on a physical system.

Here we just want to see if the parameter vector = (2,2) is found by themethod


51/57

Simulation results after identification

0 1 2 3 4 5 6 7 8 9 100.08

0.08

0.08

0.08

0.08

0.08

0.08

0.08Comparison of actual P and P in the parametrized model

t (s)

P

( a c t i v e p o w e r p . u . )

Response with

Identified Parameters

Response with True

Parameters

Demo!


52/57

Application Aggregate Load Model Identification of a Feeder

in Scottish Power Distribution Grid

Connection of feeder

with Substation

Green Feeder

Loads inside the

feeder


53/57

Aggregate Load Model IdentificationAim and Methodology

Aim

• Reference model (the whole feeder) is implemented in detail.

• We would like to represent the feeder as a load with an aggregate model.

Methodology:

• Identification set-up:

– Unknown Aggregate Load Model

– All other components are known.

• The identification process is executed with different load models

• The decision on which load type to use is based on a numerical criteria (Mean Squares Error /Best Fit)

• Experiments used for the identification process:

– 1% torque perturbation at the generator (excites electromechanical dynamics) – 1% filed voltage perturbation at the generator (excites voltage dynamics)

53

Different types of load

models

Known portion of the model Unknown portion to be identified

M d li M d l d


54/57

Modelica Model and

FMU-Simulink Model for RaPId

• The Modelica model is set up to

perform the simulation of both

experiments at the same time.

• The Modelica model is imported

to Simulink and the optimizationprocess is carried out using

RaPId

l d d l


55/57

Exponential Recovery Load Model


56/57

Results Analysis

• Based on the maximum fitness criteria (MSE),

the aggregate load model which matches thebehaviour of the data is the Exponential

Recovery Load model.


57/57

Questions?

[email protected]

[email protected]

Thank you!

Documents

ITesla- 6_Dynamic Models LV (2)