The RaPId Toolbox for Parameter Identification and Model Validation
How Modelica and FMI helped to create something nearly impossible in the electrical power systems field!
Prof.Dr.-Ing. Luigi Vanfretti
luigiv@kth.se
Associate Professor, Docent
School of Electrical Engineering
KTH
Stockholm, Sweden
Luigi.Vanfretti@statnett.no
Special Advisor in Strategy and
International Collaboration
Research and Development Division
Statnett SF
Oslo, Norway
E-mail: luigiv@kth.se, luigi.vanfretti@statnett.no
Web: http://www.vanfretti.com
FMI Tech Day – Volvo Cars Torslanda
March 11, 2015 - Gothenburg, Sweden

Outline
• Background:
– Modeling and simulation of large scale power systems
– What is iTesla and where is Modelica used?
• Why Model Validation in Power Systems?
– 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
– iTesla Power Systems Modelica Library
• 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 applications
• Conclussions

Acknowledgment
• The work presented here is a result of the collaboration between RTE
(France), AIA (Spain) and KTH (Sweden) within the EU funded FP7 iTesla
project: http://www.itesla-project.eu/
• The following people have contributed to this work:
– RTE: Patrick Panciatici, Jean-Baptiste Hyberger, Angela Chieh
– AIA: Gladys De Leon, Milenko Halat, Marc Sabate
– KTH: Wei Li, Tetiana Bogodorova, Maxime Baudette, Jan Lavenius, Francisco Gomez
Lopez, Achour Amazouz, Joan Russiñol, Mengjia Zhang, Janelle (Le) Qi … and others!
• Special thanks for ‘special training’ and support from
– Prof. Fritzson and his team at Linköping University
– Prof. Berhard Bachmann and Lennart Ochel, FH Bielefeld

UNAMBIGUOUS POWER SYSTEM MODELING
AND SIMULATION USING MODELICA TOOLS
Modeling and Simulation

• They are those who help bring power for you to charge your iPhone, ;-)
• … and they are hard to operate – when things fail, its expensive: e.g. European “blackout”
ocurred on 4/11/2006
• The frequency drops to 49 Hz, which causes automatic load schedding.
• Real power surplus of 6000 MW
Electrical Power Systems?
What are those?
5

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/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.

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
Phasor Time-
Domain Simulation

Power System Dynamics in Europe
February 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[Hz]
20110219_0755-0825
Freq. Mettlen Freq. Brindisi Freq. Wien Freq. Kassoe
Synchornized Phasor Measurement Data

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
SubSynchronous Resonances,
transformer energizations…
Transient stability
Long term dynamics
Daily load
following
seconds
Phasor Time-
Domain Simulation
PSS/E
Status Quo:
Multiple simulation tools, 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 of
information on power system dynamics
(parameter not equal to equations, block
diagrams not equal to equations)!
- 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 – but this is not the practice to date.
These are key drawbacks of today’s tools for
tackling pan-European problems.

Common Architecture of « most »
Available Power System Security Assessment Tools
Online
Data acquisition
and storage
Merging module
Contingency screening
(static power flow)
Synthesis of
recommendations
for the operator
External data
(forecasts and
snapshots)
“Static power flow model”
That means no (dynamic)
time-domain simulation is
performed.
The idea is to predict the
future behavior under a
given ‘contingency’ or set
of contingencies.
BUT, the model has no
dynamics – only
nonlinear algebraic
equations.
Computations made
on the power system
model are based on a
“power flow”
formulation.
Result : difficult to predict
the impact of a
contingency without
considering system
dynamics!

iTesla Toolbox Architecture
Online Offline
Sampling of
stochastic variables
Elaboration of
starting network
states
Impact Analysis
(time domain
simulations)
Data mining on the
results of
simulation
Data acquisition
and storage
Merging module
Contingency screening
(several stages)
Time domain
simulations
Computation of
security rules
Synthesis of
recommendations
for the operator
External data
(forecasts and
snapshots)
Improvements of
defence and
restoration plans
Offline validation of
dynamic models
Focus of this
presentation

Where are Models used?
Sampling of
stochastic variables
Elaboration of
starting network
states
Impact Analysis
(time domain
simulations)
Data mining on the
results of
simulation
Data acquisition
and storage
Merging module
Contingency screening
(several stages)
Time domain
simulations
Computation of
security rules
Synthesis of
recommendations
for the operator
External data
(forecasts and
snapshots)
Improvements of
defence and
restoration plans
Offline validation of
dynamic models
Data
management
Data mining
services
Dynamic
simulation
Optimizers
Graphical
interfaces
Modelica use planned for time-domain
simulation:
Developing a builder/translator using the
iTesla Internal Data Model (IIDM)

WHY POWER SYSTEM MODEL
VALIDATION?
Motivation

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 “good
sanity” 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(pu)
Time (sec)
Measured Response
Model Response
US WECC
Break-up in 1996
BAD Model for Dynamic
Security Assessment!!!

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
(1)
Prior Knowledge
(Experience)
Parameter Tuning
Choice of Model
Structure (2)
Criterion fit:
- fitting the data?
- purpose of the
model? (3)
OK!
Model meets the
performance criteria/
indicator.
Not OK!
Revise from (1), (2), or (3)
Experiment Design
(Staged Tests)
Data
(System Measured
Response)
Assumed Model Structure(s)
(Model of the System During
the Test) Simulate the Model
(System Simulated
Response)Chosen Criterion of Fit
(Performance Indicator)
Validate the Model
(Model of the System
During the Test)
?

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)
G1
G2
G3
G4
G5
G7
G6
G8
G9

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
against
measurements
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
Requirements
forValidation
Limitationsofcommonmodeling
practices
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
Functional
Specificationof
WP6Tools
Task
3.1
Task
3.2
Task
3.3
Task
3.4
Task
3.5

UNAMBIGUOUS POWER SYSTEM MODELING
AND SIMULATION USING MODELICA-DRIVEN
TOOLS
Modeling and Simulation

Power System Modeling
limitations, 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 (Common Information Model) 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.
This is very costly!
An equation based
modeling language can
help in avoiding all of
these issues!

• Modeling and simulation should not be ambiguous: it should be
consistent 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 to provide:
– 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
Unambiguous
Power System Modeling and Simulation

iTesla Power Systems
Modelica Library
• Power Systems Library:
– The Power Systems library developed using as reference domain specific software tools
(e.g. PSS/E, Eurostag, PSAT and others)
• PSS/E and Eurostag (proprietary) , PSAT (OSS) power system specific simulation tools.
– The library has been tested in several Modelica supporting software: OpenModelica,
Dymola, SystemModeler and Jmodelica.org.
– Components and systems are validated against the proprietary tools and OSS tool
• New components and time-driven events are being added to this library in
order to simulate new systems.
– PSS/E (proprietary tool) equivalents of different components are now available and
being validated.
– Automatic translator from domain specific tools to Modelica will use this library’s classes
to build specific power system network models is being developed.

iTesla Power Systems
Modelica Library in OpenModelica

SW-to-SW Validation of
Models used by TSOs
• Derive the equations
– Eletrocmagnetic dynamics
– Motion
– Saturation
– Stator voltage equations
• Boundary equations
– Change coordinate
• Provide initial (guess)
values for the initialization
problem
Validation of a PSS/E Model: Genrou

Typical SW-to-SW Validation Tests
• Basic grid
• Perturbation scenarios

• Set-up a model in each tool with the
simulation scenario configured
• In the case of Modelica, the simulation
configuration can be done within the model
• In the case of PSS/E, a Python script is
created to perform the same test.
• Sample Test:
1. Running under steady state for 2s.
2. Vary the system load with constant P/Q ratio.
3. After 0.1s later, the load was restored to its original
value .
4. Run simulation to 10s.
5. Apply three phase to ground fault.
6. 0.15s later clear fault by tripping the line.
7. Run simulation until 20s.
Model Set-Up of SW-to-SW
Validation Tests
Modelica
PSS/E
Python

Results from Validation Test
for GENROU

ITESLA MODEL VALIDATION MOCK-
UP SOFTWARE PROTOTYPE
RaPId: a proof of concept implementation using Modelica and FMI
Technologies

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 EMSMeasurements
Static Values:
- Time Stamp
- Average Measurement Values of P, Q and V
- Sampled every 5-10 sec
Time Series:
- GPSTime Stamped Measurements
- Time-stamped voltage and current phasor meas.
Time Serieswith single time stamp:
- Time-stamp in the initial sample, use of samplingfrequency to
determine the time-stamp of other points
- Three phase (ABC), voltage and current measurements
- Other measurements available: frequency, harmonics, THD, etc.
Time Seriesfrom other devices(FNET FDRsor
Similar):
- GPSTime Stamped Measurements
- Single phase voltage phasor measurement, frequency, etc.
Scenario
Initialization
State Estimator
Snap-shop
Dynamic
Simulation
Limited visibility of custom or manufacturer
models will by itself put alimitation on the
methodologies used for model validation
• Support “harmonized”
dynamic models
• Process
measurements using
different DSP
techniques
• Perform simulation of
the model
• Provide optimization
facilities for
estimating and
calibrating model
parameters
• Provide user
interaction

User Target
(server/pc)
Model Validation Software
iTesla WP2 Inputs to WP3: Measurements & Models
Mockup SW Architecture
Proof 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
MATLAB
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 and
.xml 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 and
.xml files
FMU compiled
by another tool
FMU

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.
• Based on Modelica and FMI – applicable to other
systems, not only power systems!
• 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
compared against measurements.
• RaPId attempts to tune the parameters of the
model in so as to satisfy a fitness criterion (e.g.
minimize the error between the simulation and
measurement traces) between the outputs of the
Simulation and the experimental measurements of
the same outputs provided by the user.

RaPId Interface
Options
and
Settings
Algorithm Choice
Results and Plots
Simulink Containerl
Output measurement data
Input measurement data
• RAPID has been developed in
MATLAB, where the MATLAB
code acts as wrapper to
provide interaction with
several other programs.
• Advanced users can simply
use MATLAB scripts instead of
the interface.
• Plug-in Architecture:
– Completely extensible and open
architecture allows advanced
users to add:
• Identification methods
• Optimization methods
• Specific objective functions
• Solvers (integration
routines)

What does RaPId do?
1 Output (and optionally input) measurements are provided to RaPId by the user.
2 At initialization, 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’
1
2
3
4
5
2’
The simulations continue
until a minimal fitness or
a maximum number of
iterations (simulation
runs) are reached.

File Structure
RaPId gui
core
GUI - Contains the
configuration menus, and
the main window.
algos
functions algoFunctions
rapidFunctions
Functions adapting the
calls to the optimization
method to the parameter
optimization of RaPId
Functions used by
the algorithm
implemented with
the toolbox (pso,
ga, naive method)
Base functions of
the toolbox
Data files use to transfer data
from the GUI to rRaPId.
Can be read by the user after
computation.
Modelica, Examples, Experiments
Directories containing Modelica and
FMU models, Examples, Experiments,
other…

Implementation
rapid.m
Called from the GUI or
the command line,
needs to be fed the
settings struct and the
measured data
Reads in settings the name of
the method to be used, call the
appropriate method
xxx_algo.m
func.m
Rapid_simuSystem.m
Rapid_objectiveFunctio
n.m
Generates iteratively parameter vectors to test taking
into account past values of the parameters and
corresponding fitness (example of methods: PSO, GA,
Gradient) stop after a number of iterations or when a
condition on fitness is reached
Provide a vector of parameter,
expect the fitness as return value
Simulate the simulink model with the vector
of parameters fed by the method and return
the output of the model
Evaluate the fitness of the vector of
parameters based on the output from the
simulation and the output measured
Several criterions can be used
Return the fitness
Functions from :
corefunctionsrapidFunctions

Plugins:
Obj. Functions
function fitness = rapid_objectiveFunction( realRes, simuRes,settings)
%OBJECTIVEFUNCTION compute the fitness criterion
% Default - quadratic criterion
% realRes is data used for matching, from measurments
% simuRes is the data we want to have matching realRes
% the two of them are under the shape [[x[1];y[1]] [x[2];y[2]] ...
[x[nStep];y[nStep]]]
%
% settings has to contain the fields
% cost: integer, for quadratic cost the value is 2
% objective: struct adapted to the method chose
% if cost = 2, objective contains the field:
% Q: nb_parameters*nb_parameters weight matrix,
% should take into account the respective outputs scaling
switch settings.cost
case 2
nStep = size(realRes,2);
nx = size(settings.objective.Q,1);
Q_ = repmat({settings.objective.Q},1,nStep);
Q_ = blkdiag(Q_{:});
fitness = (realRes(:)-simuRes(:))'*Q_*(realRes(:)-simuRes(:));
otherwise
errorWrongCost
end
end
rapid_objectiveFunction, choose a keyword:
eg. case 2.
To plugin a new optimization function: add a
case to the switch, in the body of the case,
compute the fitness of the vector of
parameters based on realRes and simuRes,
(measured and simulated output signals).
realRes is an interpolation of the result of the
simulation at the time instants given by the
measurement data.
Allows to compare measured and simulated
data point to point.
A new method can be added for fitness
computation if the appropriate keyword is
given in settings.cost
You can define as many elements as needed
inside settings.objective, in the example here a
weight matrix is provided in settings.objective
Here the fitness is characterised by one unique
matrix Q : 𝜑 = 𝑘(𝑦 𝑘 − 𝑦 𝑚𝑒𝑠[𝑘])
𝑇
𝑄(𝑦 𝑘 − 𝑦 𝑚𝑒𝑠[𝑘])

Plugins:
Optim. Methods (1)
function [ sol, historic ] = rapid( settings, systemDescription )
%RAPID main function of the rapid toolbox RaPId
global nbIterations
nbIterations = 0;
% Set-up the simulink model to run between 0 and tf with a step of Ts and
% with the solver given by settings.methodName, the function
% rapid_simuSystem call the simulation in the workspace of rapid.m after
% changing the parameters value through fmuSetValueSimulink
addpath(settings.rapidFolder);
settings.realData = rapid_interpolate(systemDescription,settings);
% choose and launch the desired method for parameter estimation
switch settings.methodName
case 'pso'
[ sol, historic, settings ] = pso_algo(settings);
case 'ga'
[ sol, historic, settings ] = ga_algo(settings);
case 'naive'
sol = naive_algo(settings);
historic = [];
case 'cg'
[ sol, historic, settings ] = cg_algo(settings);
case 'nm'
[ sol, historic, settings ] = nm_algo(settings);
case 'combi'
settings2 = settings;
settings2.methodName = settings2.combiOptions.firstMethod;
[sol1,historic1, settings2] = rapid(settings2,systemDescription);
settings2.methodName = settings2.combiOptions.secondMethod;
settings2.p0 = sol1;
[sol,historic2, settings] = rapid(settings2,systemDescription);
historic.sol1 = sol1;
historic.historic1 = historic1;
historic.historic2 = historic2;
case 'psoExt'
[ sol, historic, settings ] = psoExt_algo(settings);
case 'gaExt'
[ sol, historic, settings ] = gaExt_algo(settings);
otherwise
errorWrongMethodName
end
end
A case with a new keyword in the function rapid.m can be
added.
Call your method methodName_algo.
It takes the struct settings as argument and return the vector
solution.
A new method can only call the function func(v)
func takes a vector of parameter and returns the fitness
associated to this vector.
This assumes that the good settings.cost and
settings.objective were declared to use the objective function
you desire to evaluate.
func takes care of simulating the model, saving its output,
interpolating the output data and computing the fitness.
All fields of the settings struct must however be filled
correctly. (Not presented here)

function [ sol, other ] = yourMethod_algo(settings)
%Adapting your optimization method
%function defined by the parameter identification problem
% settings must have as a field the initial guess for the parameter
% vector p0, lower and upper bound for the vector of parameters and possibly
% options generated by optimset
options = settings.yourMethod_options;
sol = yourMethod(@func,settings.p0,settings.p_min,settings.p_max,[],options);
end
What you need to write:
Call to new
function
1) The function may output any number of
parameters, you can store them in other
parameters. They will be saved and accessible
after computations are complete.
2) If the function is on the main folder of RaPId,
nothing needs to be done for the path
management.
Plugins:
Optim. Methods (2)

Using RaPId for
for parameter estimation
• 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 using the FMI Toolbox
for Matlab
• RaPId is excecuted 𝑖 times (simulation/excecution runs) until the
performance indicator is acceptable.
𝑦(𝑡)𝑢(𝑡)
System studied
System to be
identified
S(θ)
𝑢(𝑡) 𝑦(𝑡)
θ𝑖

A Textbook Example:
Measurement-based parameter identification of an “unknown” component
Assume we have the measured response 𝑦(𝑡) of a system 𝐺(𝑡, 𝜃), subject to a change in the
input 𝑢(𝑡) where 𝜃 is a vector of unknown parameters to be identified.
We now hypothesize that the model of the unknown component 𝐺(𝑡, 𝜃) can be posed as a
transfer function of the form
𝐺 𝑠 =
𝑏1
𝑎1 𝑠2 + 𝑎2 𝑠 + 𝑎3
The Modelica model for 𝐺 can be easily built.
The parameters 𝑏1, 𝑎1, 𝑎2 and 𝑎3 are calibrated be minimizing the error between measured
and simulated response with the fitness function:
𝜙θ =
𝑡0
𝑡 𝑓
(𝑦 𝑚(𝑡) − 𝑦 𝜃(𝑡))2
𝑑𝑡
Measurement

• We use an initial guess of the parameters of the model (un-calibrated parameters):
[𝑏1, 𝑎1, 𝑎2, 𝑎3] = [0.4, 4.15, 1.75 ,1.15]
• After the optimization process, the parameters obtained by RaPId, which satisfy
the performance indicator are:
[𝑏1, 𝑎1, 𝑎2, 𝑎3] = [0.3413, 4.5488, 1.7956, 1.1374]
• Observe that the true model is given indeed by a transfer function with
parameters:
[𝑏1, 𝑎1, 𝑎2, 𝑎3] = [0.3, 4.00, 1.6 ,1.00]
• To obtain the exact parameters, the performance indicator needs to be stricter –
leading to more executions of the calibration process.
Measurements
Model response with
initial guess
Demo!
simout
To Workspace
Scope
datameasured
From
Workspace
y1
FMUrafael
FMU of the Modelica Model
in the Simulink Container

Measurements from tests are imported into
MATLAB:
Δοκιμή 1/ 60% MCR/-200 mHz/ 900sec.
220
230
240
250
260
270
280
19:58:11
19:58:58
19:59:45
20:00:32
20:01:19
20:02:06
20:02:53
20:03:40
20:04:27
20:05:14
20:06:01
20:06:48
20:07:35
20:08:22
20:09:09
20:09:56
20:10:43
20:11:30
20:12:17
20:13:04
20:13:51
20:14:38
20:15:25
20:16:12
20:16:59
Ώρα
Ισχύς
99.5
99.6
99.7
99.8
99.9
100
100.1
Συχνότητα(%)ωςποσοτότων
50Hz
Pow er output
(MW)
Injected
Signal (%)
*Rescaling to p.u. was performed after data extraction.
Application Example
Model Parameter Identification for a Greek Generating Plant

iGrGen Model
FMU in Simulink
for RaPId

Algorithms: PF vs. PSO
Particle Filter PSO
Assumption:
The Particle Filter approach will reduce the
solution space to samples that will result in
a lower values of the fitness function (lower
error).
In contrast, PSO will have slower
convergence as it will evaluate the fitness
function over the whole solution space, for
each iteration.

Results of identification

Results of identification – cont.
R has influence on height of ΔPm,
Ts has influence on the raise and fall time transient.
The mismatch between the model response and the real system is
product of the modeling adequacy.
The model cannot exactly reproduce the system behavior.
However, for practical purposes, the results are satisfactory.

Results using
PF and PSO
The assumption on faster convergence of the Particle Filter over PSO appears to be
valid from the results above.

Conclusions and
Looking Forward
• Modeling power system components with Modelica (as compared with domain
specific tools) is very attractive:
– Formal mathematical description of the model (equations)
– Allows model exchange between Modelica tools, with consistent
(unambiguous) simulation results
• The FMI Standard allows to take advantage of Modelica models for:
– Using Modelica models in different simulation environments
– Coupling general purpose tools to the model/simulation (case of RaPId)
• There are several challenges for modeling and validated “large scale” power
systems:
– A well populated library of typical components (and for different time-scales)
– Model builder from domain-specific tools “data files/base” (in development)
– Support/linkage with industry specific data exchange paradigm (Common
Information Model - CIM)
• Developing a Modelica-driven model validation for large scale power systems will
prove more complex challenge than the case of RaPId.

Questions?
luigiv@kth.se
luigi.vanfretti@statnett.no
Thank you!
50