Towards a standardized binary simulation model interface · Towards a standardized binary simulation model interface ... Supports initialization from standard models as well as from

© REpower Systems AG/Siemens AG 2011. All rights reserved.

Towards a standardized binary Towards a standardized binary simulation model interfacesimulation model interfaceJens Fortmann, REpower Systems AGJens Fortmann, REpower Systems AGRalph Hendriks, Siemens AGRalph Hendriks, Siemens AG

2011-06-17 Jens Fortmann, Ralph HendriksPage 2© REpower Systems AG/Siemens AG 2011. All rights reserved.

E D SE PTI© REpower Systems AG/Siemens AG 2011. All rights reserved.

Challenges WTG model development

Standardized binary interface for simulation models

Development aspects

Application aspects

Outlook and roadmap

Contents


E D SE PTI

Load flow studiesNo particular WTG models required

Short-circuit studiesStandardized simulation framework does not allow custom models

Transient stability (TS) studiesSpecific WTG models required

Electro-magnetic transients (EMT) studiesOnly done by TSO/DSO in case of specific concerns

When referring to ‘WTG models’, in most cases we mean TS models.

WTG models in TSO/DSO power system studies


E D SE PTI

The landscape of WTG modeling becomes increasingly complex:Model validation (comparison with measurements/type tests)

Validated models require certification in some countries

Models may contain vendor Intellectual Property (IP)Black box/compiled models vs. white box/open source models

Different transient stability simulation programs are being used and need to be supported by WTG vendors

Usually vendors maintain a ‘reference implementation’ (e.g. Matlab/Simulink)

Large systems consists of wide range of equipment, with custom modelsModel interoperability becomes an issue

Developments in WTG standard models

Recent developments in WTG modeling


E D SE PTI

Progress being made in development of more elaborate standard models of WTGs, e.g. in IEC and WECC/IEEE

Standard models are aimed at interconnected system operationBehavior during faults and switching actionsWind power plants represented as single/few scaled unitsConstant wind speed

Vendor-specific models will always remain necessaryCollector system designControl interaction (plant level controls, FACTS)Load rejection studies (islanding/reconnection)Very weak systemsGrid connection through HVDCVarying wind speed conditions

Standard models vs. vendor-specific models


E D SE PTI

To actively address some of the modeling challenges, REpower, Converteam, and Siemens PTI have jointly developed a binary model interface.

A well-described interface between simulation models and power system time-domain simulation software.

Interoperability between models and simulation programs that support the API

Model can be developed in any software that supports the APIFocus during development on automatic code generation from Matlab/Simulink

Reference implementation in PSS®NETOMAC

Further implementations exist in PSS®E, Power Factory, Matlab/Simulink, PSD

Binary simulation model interface −Key points


E D SE PTI

Models are implemented as DLL and connected to the main program

Multiple models and multiple instances of the same model supported

Main program invokes models by function calls, defined in API

Data exchange defined in API

Model AInstance 1

Simulation Program

Model Ainstance 2

Model Binstance 1

etc.

Internal models

Binary simulation model interface −Overview


E D SE PTI

No need to maintain specific implementations of ‘core model’

Models are compiled and hence could be black boxes

Interface designed with various stability simulation approaches in mind

Applicable to all time-domain simulation models, both TS and EMT type

Not limited to WTG models, generally applicable for all sorts of models

Supports initialization from standard models as well as from custom load flow models

Automatic extraction of parameters, limit checking, and documentation strings

Binary simulation model interface −Advantages



Development aspects


E D SE PTI

Features

Multiple instances of one component (model) with different parameter sets

Input and output of scalar and vector data

Provision of information of the component (model), e.g. version, API release, description, parameters, defaults, min/max values, etc.

Support for internal (fixed step) and external (fixed and variable step) solvers.

Providing information about the supported modes: TS (RMS), EMT, or both

Includes interface for restoring a system snapshot (system restart mechanism)


E D SE PTI

Limitations

Input/output quantitiesFloating pointScalar or vector (no matrix data, structured data or busses)Real-valued (not complex)Sample-based (not frame-based)

ParametersFloating pointScalar (no vectors, structured data, or cell arrays)Real-valued (not complex)

Single tasking mode only (model must provide own scheduler if necessary)

Absolute time not available within model

Zero-crossing or hit-detection mechanisms not supported


E D SE PTI

Component interface, static methods and data

Static instant independent methods and data

Provide general model information (e.g. version, description, parameter names) Model and API version and release

Short description and copyright informationNumber, size and description of inputs and outputsNumber, min/max/default value and unit of parametersNumber of continuous states, size of discrete state structureSolver information and sample timeCode generation date and toolModel creator, checksum, date, history, etc.Mechanisms for error handlingEMT / RMS mode


E D SE PTI

Component interface, dynamic methods and data

Dynamic, Instance specific methodsProvide access to the calculation methods and parameters of each instance

Create instance and give access to instant specific datainput data, output data, parametersstates and state derivatives

Parameter checkLoad flowInitialization

[during Time-domain simulation:]Model outputs (algebraic equations)Model update (differential equations)

Termination


E D SE PTI

Begin:S=Model_GetInfo() Get static model information needed to configure the environmentM = Model_Instance(Solver, Ta) Create instance, use internal (1) or external (0) solver, set sample timeModel_CheckParameters(M) Check parametersLoadFlowIteration: (Number of iterations depends on load flow solver)

Model_Loadflow(M) Calculate outputs of load flow functionEndLoadFlowIterationModel_Initialize(M) Reset and initialize the states

SimulationLoop:Model_Outputs(M, 1) Calculate system outputs on major time step (1)Model_Update(M) Update discrete states (and continuous states if internal solver used)IntegrationLoop: (Only needed if external solver is used)

Model_Derivatives(M) Calculate continuous state derivativesIteration: (Number of iterations depends on ODE solver)

Model_Outputs(M, 0) Calculate system outputs on minor time step (0)Model_Derivatives(M) Calculate continuous state derivatives

EndIterationEndIntegrationLoop

EndSimulationLoop

Model_Terminate(M) Delete the instanceEnd

Pseudo code of the simulation loop


E D SE PTI

Component (model) lifetime

Calling convention is similar to call Matlab/Simulink S-functions

Support of discrete and continuous states

Code generation with Matlab RealTimeWorkshop leads to direct implementation of this structure

Multiple calls to outputs possible (network solution iteration)

Methods for different solvers Internal solver: fixed step ODEexternal solver: fixed step or variable step source: The Mathworks


E D SE PTI

Code Generation example

Simulink Model Generated Code

R29S02.cR29S02.h…

ext_simenv_main.cext_simenv_capi.h…

Software Interface

Simulation System 1

Software Component

Shared Library

R29S02.dll

Simulation System 2

[ … ]



Application aspects


E D SE PTI

Opening DLL in PSS®NETCAD GUI

Automatic detectionNumber of inputs and outputsSignal labelsParameter descriptions, limits, and default valuesDefault time-step size

Model is then available as a calculation block, just as e.g. an integrator

Embedding binary model into PSS®NETOMAC


E D SE PTI

Connection to the power system model

External component (DLL) model gets available as a building block in Netomac

Connection to the power system needs to be made in BOSL model, e.g.:Controlled current source (GNE-I)Controlled voltage source (GNE-V)Variable admittance (GNE-Y)Machine exciter (field voltage) and governor (mechanical torque)etc.

Inputs from the power system to be connected by end uservoltages, currents, power flows (any node or branch)machine model quantitiesphasor sequence components (TS), instantaneous values (TS and EMT)


E D SE PTI

T

Connecting the model to the power system


E D SE PTI

Model synchronization

A common problem with previous ‘external’ models is the occurrence of numerical spikes:

Caused by direct feedthrough (‘algebraic loops’)Most notable in TS models (e.g. voltage inputs)

With external ODE solver:Iteration with multiple calls to model output functionModel and main program have perfect time synchronization

With internal ODE solver:Additional synchronization issues may have to be consideredIn implementation PSS®NETOMAC/BOSL a robust synchronization algorithm has been included, tested for a wide range of time-step sizes



Outlook and roadmap


E D SE PTI

Present status

Initial API specified and developed by project team consisting of members from:

Siemens PTI (PSS®NETOMAC development team)REpowerConverteam

Current API version is fully supported by PSS®NETOMAC and BOSLSupport under PSS®E version 33 through BOSL GNE-models

Interface tested in several further simulation environments (Digsilent Power Factory, Matlab/Simulink, PSD)

Detailed REpower WTG model successfully implemented

Interest shown by other WTG vendors


E D SE PTI

Next steps

A white paper and API description with selected examples (‘walk through’) for code generation from Matlab/Simulink will be available

End of summer 2011

REpower WTG model to be applied for detailed wind power plant design and submission to TSO

Presently discussion with Siemens PTI software team in US about applicability to US market


E D SE PTI

Roadmap

Further development driven by market reception and first user experiencesIssues that are addressed with interface are widely recognized as bottlenecksMarket signals are positive

Collect practical experience from usersTSO input is essentialIs there interest within TSOs to use one single, standardized interface for simulation models?

Project aim was to create a well-defined and harmonized definition of binary simulation model interface.Open issues are documentation and reference implementations.

Most suitable platform for maintaining and further development of interface definition:

National/international working groups/standardization? (FGW, IEEE, IEC)Other ideas?



Thank you for your attention!

© REpower Systems AG/Siemens AG 2011. All rights reserved.© REpower Systems AG/Siemens AG 2011. All rights reserved.

Ralph HendriksSiemens AGE-mail: [email protected]/energy/power-technologies

Jens FortmannREpower Systems AGE-mail: [email protected]

Documents

Towards a standardized binary simulation model interface · Towards a standardized binary simulation model interface ... Supports initialization from standard models as well as from