Applying Modelica and FMI Technologies for Power System Model Validation in the itesla Project

Transcription

1 Applying Modelica and FMI Technologies for Power System Model Validation in the itesla Project Prof.Dr.-Ing. Luigi Vanfretti Web: Associate Professor, Docent Electric Power Systems Dept. KTH Stockholm, Sweden Special Advisor in Strategy and Public Affairs Research and Development Division Statnett SF Oslo, Norway 2 nd itesla/umbrella Common Workshop Jan. 14, 2014 Brussels, Belgium

2 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 Modeling and Simulation UNAMBIGUOUS POWER SYSTEM MODELING AND SIMULATION USING MODELICA-DRIVEN TOOLS

4 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 Power system dynamics Lightning Line switching Electromechanical Transients SubSynchronous Resonances, transformer energizations Quasi-Steady State Dynamics Transient stability Electromagnetic Transients Long term dynamics Daily load following seconds

6 Power system dynamics Lightning Line switching Electromagnetic Transients Electromechanical Transients SubSynchronous Resonances, transformer energizations Electromagnetic Transients Transient stability Quasi-Steady State Dynamics Interaction between the electrical field of capacitance and magnetic field of inductances in Long term dynamics power systems. Daily load following Ex : lightning impact, line switching May 10-1 produce 1 : overvoltages, overcurrents, abnormal seconds waveforms, electromechanical transients

7 Power system dynamics Lightning Line switching Electromechanical Transients Electromechanical Transients SubSynchronous Resonances, transformer energizations Transient stability Quasi-Steady State Dynamics Interaction Electromagnetic between Transients the electrical energy stored in the system and the mechanical energy stored in the inertia of rotating machines Long term dynamics Daily load following Ex : Power oscillations May produce: system breakup. seconds

8 Power system dynamics challenges for simulation Generally there are no discrete events. (Ad-hoc DAE solvers) Lightning Line switching 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) (Ad-hoc DAE solvers) SubSynchronous Resonances, The models are simplified further by transformer energizations neglecting most dynamics (replacing most differential equations by algebraic equations). The presence of very small time scales and large amount of discrete switches. Transient stability Long term dynamics Difficult to simulate very large networks. Daily load following This 10-7 is 10 usually deal -5 with 10-4 by seconds discretizing the model and to solve it using discrete solvers.

9 Power system phenomena and domain specific simulation tools PSS/E Algebraic Steady State (Power Flow) Ad-hoc Initialization of Dynamic States = Dynamic equilibrium Lightning Line switching Simulation SubSynchronous Resonances, transformer energizations Transient stability Long term dynamics Daily load following seconds Broad range of time constants results in specific domain tools for simulation. Non-exhaustive list. There exists other proprietary and few OSS tools.

10 Power System Time-Scale Modeling from this point on Lightning Line switching SubSynchronous Resonances, transformer energizations Transient stability Long term dynamics Phasor Time- Domain Simulation Daily load following seconds

11 Power System Dynamics in Europe February 19th 2011 Synchornized Phasor Measurement Data _ f [Hz] :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 Freq. Mettlen Freq. Brindisi Freq. Wien Freq. Kassoe

12 Power System Phasor-Time Domain Modeling and Simulation Status Quo Lightning Status Quo: Multiple simulations, with their own interpretation of different model features and Line data switching format. Implications of the Status Quo: - Dynamic models can rarely be shared in a straightforward manner without loss SubSynchronous of Resonances, information on power system dynamics. transformer energizations - Simulations are inconsistent without drastic and specialized human intervention. Transient stability PSS/E Phasor Time- Domain Simulation 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. Long term dynamics Daily load following seconds

13 Motivation and Overview of WP3 WHY MODEL VALIDATION?

14 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) P (pu) Measured Response 1 Model Response WECC Break-up 1996 BAD Model for Dynamic Security Assessment!!! Time (sec)

15 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 Model Validation Requirements for the Model Validation Process 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 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 The Power System Data Set Limited visibility of custom or manufacturer models will by itself put a limitation on the methodologies used for model validation Dynamic Model Standard Models Custom Models Manufacturer Models Dynamic Simulation Needs and Roles of Models and Measurements for Off-line Dynamic Model Validation Models Static Model Static Measurements Initialization State Estimator Snap-shop Scenario Static Values: - Time Stamp - Average Measurement Values of P, Q and V - Sampled every 5-10 sec SCADA Measurements Other EMS Measurements Time Series: - GPS Time Stamped Measurements - Time-stamped voltage and current phasor meas. Measurement, Model and Scenario Harmonization System Level Model Validation Measurements PMU Measurements Dynamic Measurements 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. DFR Measurements Time Series from other devices (FNET FDRs or Similar): - GPS Time Stamped Measurements - Single phase voltage phasor measurement, frequency, etc. Other

19 Overview of Model Validation work in itesla WP3 Off-line validation of dyanmic models Synchronized Phasor Measurements and high bandwidth model simulated responses Requirements for Validation Functional Specification of WP6 Tools Parameter Estimation using measurements and high bandwidth simulated responses Validated Device Models Methods to Generate Aggregate Models of PV and Wind Farms Validated Aggregate Models Methods for the Assessment of largepower network simulation responses against measurements Dynamic performance discrepancy indexes Limitations of common modeling practices Task on Validation Requirements Task 3.1 Task 3.3 Tasks on Device Model Validation and Parameter Estimation Task 3.4 Unvalidated Models, Models that need updates, Etc. Tasks on Methods to Obtain Aggregate Models and their Validation Task 3.5 Validated Models and Model Parameters, Updated Models, and Discrepancy Indexes WP2 Data Needs, Collection and Management Tasks on Large-Power System Model Dynamic Performance Assessment Task on Identification of modeling limitations of current practices Task 3.2

20 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 Modeling and Simulation UNAMBIGUOUS POWER SYSTEM MODELING AND SIMULATION USING MODELICA-DRIVEN TOOLS

22 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 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 retuning parameters.

23 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 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: This is very costly! 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 retuning parameters.

24 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 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: This is very costly! An equation based modeling language can help in avoiding all of these issues! 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 retuning parameters.

25 Unambiguous Power System Modeling and Simulation 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 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

26 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 if desired). It also allows decomposing complex systems into simple sub-models easier to understand, share and reuse

27 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 by equations. There is a hierarchical decomposition of each component. Component 1 Component 2 Component 3

28 Modelica Non-proprietary, object-oriented, equation-based hybrid modeling language for modeling complex cyber-physcial systems. i.e., Modelica is not a tool 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.

29 Modelica The Next Generation Modeling Language Declarative language Equations 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 programming Hierarchical system architecture capabilities Efficient, non-proprietary Efficiency comparable to C; advanced equation compilation, e.g equations, ~ lines on standard PC Used with permission of Prof. Peter Fritzson:

30 Object Oriented Mathematical 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 Used with permission of Prof. Peter Fritzson:

31 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 other reference 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 itesla Power Systems Modelica Library in OpenModelica

33 Example Model Implementation in Modelica of a WT Type 3 (DFIG) Each sub-block was implemented independently in Modelica and tested Each sub-block contains its own intialization equations, dynamic and algebraic equations Parameters are passed from the upper layer to the sub-blocks ω m T m PitchControl θ p windblk MechaBlk v w ω m T ee ω m ElecBlk V bbb ElecDynBlk i qq, i dr

34 Pitch Control Block Details model PitchControl Modelica.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; Initialization Dynamic Equations Limiter Equations initial equation (Kp*phi - theta_pi)/tp = 0; equation // Dynamics of the pitch angle, the anti-windup if omega_m < 1 then phi=0; else phi=ceil(0.5*floor(1000*(omega_m - 1)*2))/1000; // 0.5*floor(ceil(2*x)) corresponds to round(x) end if; der(theta_pi)=(kp*phi - theta_p)/tp; // Anti-windup theta_p=min(max(theta_pi, theta_p_min), theta_p_max) "saturation"; when theta_pi > theta_p_max and der(theta_pi) < 0 then reinit(theta_pi, theta_p_max); end when; when theta_pi < theta_p_min and der(theta_pi) > 0 then reinit(theta_pi, theta_p_min); end when; end PitchControl;

35 SW-to-SW Validation PSAT vs. Modelica Model Reference DFIG Model in PSAT Implemented Model in Modelica

36 SW-to-SW Validation Response to a three phase fault T s = 10 3

37 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 standard definition 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 FMUs for Unambiguous Model 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 locked into a specific simulation environment! We explore the second option.

39 Sharing FMUs with MATLAB/Simulink and the FMI Toolbox The model validation architecture needs to exploit the sys id. tools in MATLAB (explained latter). FMU compilation of the Modelica Model using Dymola FMUs generated from Dymola. Model Import into MATLAB using the FMI Toolbox FMUs allow for model simulation in Matlab for self-contained integration of prototype model validation tool. Output configuration and simulation

40 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 No.2: This is natural thanks to the Modelica language 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 The Power of Modelica Unambiguous Modeling Simulation and Optimization of Power Systems across Multiple SW Platforms Tested and validated The same model can be shared and simulated without ambiguity in 5 different SW platforms from completely different vendors! Function alities of the Tool Textual Modeling Graphical Modeling and Simulation FMI Support Optimization Text Editor OpenModelica OMEdit, OMOptim Text Editor Dymola Via additional library Different Tools Text Editor Wolfram System Modeler (WSM) and WSMLink for Mathematica Planned WSMLink for Mathematica Text Editor Jmodelica.org FMI Toolbox + Matlab/Simulink

42 Modelica Faster Development and Lower Maintenance than with Traditional Tools Block Diagram (e.g. Simulink,...) or Proprietary Code (e.g. Ada, Fortran, C, C++,...) vs Modelica Proprietary Code Systems Definition System Decomposition Modeling of Subsystems Causality Derivation (manual derivation of input/output relations) Implementation Simulation Block Diagram Modelica Used with permission of Prof. Peter Fritzson:

43 RaPId: a proof of concept implementation using Modelica and the FMI Standard within Matlab/Simulink ITESLA MODEL VALIDATION MOCK- UP SOFTWARE PROTOTYPE

44 What is required from a SW architecture for model validation? Limited visibility of custom or manufacturer models will by itself put a limitation on the methodologies used for model validation Models Measurements Dynamic Model Static Model Static Measurements Dynamic Measurements Standard Models Custom Models Manufacturer Models Initialization State Estimator Snap-shop Scenario Static Values: - Time Stamp - Average Measurement Values of P, Q and V - Sampled every 5-10 sec SCADA Measurements Other EMS Measurements Time Series: - GPS Time Stamped Measurements - Time-stamped voltage and current phasor meas. PMU Measurements 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. DFR Measurements Time Series from other devices (FNET FDRs or Similar): - GPS Time Stamped Measurements - Single phase voltage phasor measurement, frequency, etc. Other Dynamic Simulation Measurement, Model and Scenario Harmonization System Level 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

45 Mockup SW Architecture Proof of concept of using MATLAB+FMI itesla WP2 Inputs to WP3: Measurements & Models HARMONIZED MODELICA MODEL: Modelica Dynamic Model Definition for Phasor Time Domain Simulation.mo files SCADA/EMS Snapshots + Operator Actions PMU and other available HB measurements EMTP-RV and/or other HB model simulation traces and simulation configuration Internet or LAN itesla Cloud or Local Toolbox Installation FMU FMU compiled by another tool.mat files MATLAB/Simulink (used for simulation of the Modelica Model in FMU format).mat files Data Conditioning Model Validation Tasks: Any measurement data is converted to.mat format. Model Validation Software User Target (server/pc) MATLAB FMI Toolbox for MATLAB (with Modelica model) Parameter tuning, model optimization, etc. User Interaction

46 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 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 2 Based on the fitness computed in (5) a new set of parameters is computed by RaPId

48 RaPId in Action Parameter estimation for an aggregate load model u(t) System studied y(t) u(t) System to be identified y(t) S(θ) 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 θ i

49 Identification Setup u(t) System to be identified S(θ) Simulation y i (t) Pre-processed measurement data θ i Simulation data y(t) Optimization Algorithm

50 Example for a voltage dependent load // Equations from the load model v=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 θ = (α p, α q ) The measurement give the evolution of the active and reactive power P m and Q m but also the voltage magnitude v m and angle a m The fitness function is defined by the quadratic criterion: t f φ θ = (P m (t) P θ (t)) 2 + (Q m (t) Q θ (t)) 2 +(v m (t) v θ (t)) 2 +(a m (t) a θ (t)) 2 )) dd t 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 the method

51 Simulation results after identification 0.08 Comparison of actual P and P in the parametrized model 0.08 P (active power p.u.) Response with Identified Parameters Response with True Parameters Demo! t (s)

52 Application Aggregate Load Model Identification of a Feeder in Scottish Power Distribution Grid Loads inside the feeder Green Feeder Connection of feeder with Substation

53 Aggregate Load Model Identification Aim 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 Different types of load models Known portion of the model Unknown portion to be identified 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

54 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 optimization process is carried out using RaPId

55 Exponential Recovery Load Model

56 Results Analysis Based on the maximum fitness criteria (MSE), the aggregate load model which matches the behaviour of the data is the Exponential Recovery Load model.

57 Thank you! Questions? 57