co-simulation of energy systems - associate … · co-simulation of energy systems ... trnsys type...

1Challenge the future

Co-Simulation of Energy Systems

1st Symposium on Modelling and SimulationChallenges for Future Sustainable Energy Systems

Peter PalenskyTU Delft26.6.2015


Cyber-physical energy systems…

physical world

continuous models

energy generation, transport, distribution, consumption, etc.

physical world

continuous models

energy generation, transport, distribution, consumption, etc.

information technology

discrete models

controllers, communication infrastructure, software, etc.

information technology

discrete models

controllers, communication infrastructure, software, etc.

roles/individual behavior

game theory models

agents acting on behalf of a customer, market players, etc.

roles/individual behavior

game theory models

agents acting on behalf of a customer, market players, etc.

aggregate/stochastic

statistical models

weather, macro-view of manyindividual elements, etc.

aggregate/stochastic

statistical models

weather, macro-view of manyindividual elements, etc.

cyber-physicalenergy system

cyber-physicalenergy system


Simulating energy (sub-)systems

• Many different energy-related domains

• generation, distribution, storage, HVAC, thermal networks, power electronics, controls, etc.

• Many different expert tools

• lots of dedicated simulators for each domain

• massive amount of expert experience

• Domains are typically treated separately

• focus on components, not systems

• simplifying models

• incompatible tools

• Scalability issues

• Large (interconnected grids) vs. Small

• Quick (frequency balance, harmonics) vs. Slow (weather, prices)


Causal vs. acausal modeling

• Block diagrams are very suitable for modeling of controls/signal processing

• each block represent a set of ODE equations

• connections define uni-directional (causal) relations between blocks

• use ODE integrator to compute successive states of system

• Bi-directional (acausal) connections are more intuitive for physics modeling


Use Case 1: Thermal System with Market

• Thermal domain

• Discrete controller

• Agents/Market

• Stochastic events

• Describe via bond graph

• Analyze interplay of continuous domain and asynchronous events

• Scalability of platforms

Heater Thermal Mass

conduct1 conduct2

Switch

Controller

Agent

Tin

TsetPrice

Vent Schedule

Q_dot_amb

Energy CounterE

P

Out0 Out1

On/Off

SUM

Market

Price

Consumption

Environment

H1 [house]

H2 [house]

Hn [house]

Thermal Flow

Information


Use Case 2: UC1 + el. power station

• Physical parts not isolated

• Plus: Electrical domain

• Ideal grid

• Non-ideal power station

• Plus: Mechanical domain

• Further use cases

• 3: Thermal grid

• 4: Non-trivial market

• 5: Communication network

• 6: non-ideal grid

• 7: EV-charging

EV: electric vehicle


Fundamental (“one tool”) approach

• Two types of modeling paradigms / simulation philosophies

• Agent-oriented, causal

• Autonomous modules

• Components determine synchronization points

• Examples: GridLAB-D, Omnet++

• Monolithic, acausal

• Equation-based model of physics -> ODE-> code

• Solver integrates and tries to find zero crossings

• Examples: Modelica, Simscape

ODE: Ordinary Differential Equations


Monolithic Modeling

• E.g.: Simscape, Modelica

• PRO

• Convenient

• Multi-domain physics

• Strong syntax

• Good docu

• CON

• Low Performance

• Closed platforms?

ModelFlat

ModelSorted

Equations

Index ReducedEquations

ODEExecutable

flattening sorting

Indexreduction


Monolithic Example: Modelica

• Model Topology

• Physics

• Libraries, packages, etc.

Model HouseEnv “Non-isolated House and Temperature controlled by two point controller“

Agent agent; House house; Heater heater; Wall wall; Environment environment; Window window; equation

connect(house.outputTemp , agent.inputTemp); connect(agent.switch , heater.switch); connect(heater.port_b , house.port_a); connect(wall.port_b , house.port_a); connect(environment.port_b , window.port_a); connect(window.port_b , house.port_a);

end HouseEnv;


Connectors link physical properties

Flow Variables

Potential Variables

A

B

CI

V

I

V

I

V

• Flow: Ia+Ib+Ic=0

• Potential: Va+Vb+Vc


Potential & flow variables: Energy conservation

CurrentVoltageElectrical

Reaction RateConcentration(Bio)Chemical

Heat Flow RateTemperatureThermodynamics

Volume Flow RatePressureFlow, Hydraulic

Magnetic FluxMagnetic potentialMagnetic

Force

Torque

Position

AngleMechanics

Flow

Variables

Potential Variables

Domain


Modelica code example

package Energy package Interfaces partial connector HeatPort “Thermal port for 1-dim. Heat transfer“ Types.Temperature T; flow Types.HeatFlowRate Q_flow; end HeatPort; ... end Interfaces; package Components model House4 "House and Temperature lumped thermal element storing heat" Types.Temperature T(start=20 + 273.15, displayUnit="degC") "Temperature of element"; parameter Energy.Types.ThermalCapacity Cth = 430.578 "Heat capacity of element“; parameter Types.Density ro = 1.2041; parameter Types.Volume volume = 200; Interfaces.HeatPort_a port_a; equation T = port_a.T; ro*volume*Cth*der(T) = port_a.Q_flow; end House4; model Heater ... end Heater; ... end Components; ... end Energy;


Tool: SimScape

• Matlab / Simulink / Simscape

• Multi-Physics Toolbox, Modelica Clone

• Block-Oriented or Equations

• www.mathworks.com/products/simscape/


Monolithic Method: Simscape

• Part of Matlab/Simulink

• Object-oriented

• Multi-domain

• Comes with Matlab-comfort

• Parameters

• Scripting

• Interaction with Simulink models

• Topology via Simulink

component ElHeater < foundation.electrical.branch nodes M = foundation.thermal.thermal; % B:right end inputs Level = { 0.50, '1' }; % :left end parameters R = { 40, 'Ohm' }; % Resistance end

variables Q = { 0, 'J/s' }; end function setup through( Q, [], M.Q ); end

equations v == R*i*Level; Q == v*i; endend


Use Case 1: SimScape

• Do

• Generate Simulink Drawing

• Many houses

• One Market, etc.

• Simulate

• Store results

• Until (all simulation cases)


Use Case 1 SimScape results


Usecase 2 Simscape Implementation


GridLAB-D

• Simulation environment specifically designed for the analysis of modern power systems

• open source, developed by PNNL

• Main features:

• command line tool written in C/C++

• runs under Windows (MSVC, MinGW, Cygwin) and Unices

• flexible agent-based simulator

• can model the behavior of many objects over time

• comprises a modular design

• buildings (residential, commercial, industrial)

• electric network (generation, transmission, distribution, controllers, reliability)

• markets (retail double auctions, transaction journals)

• climate

• implements a modelling language

• parametric syntax for dynamic model generation

• provides various simulation utilities

• debugging, profiling, plotting, histogramming, write to file etc.


GridLAB-D: Time synchronization

time

order of execution

Object 1

Object 1

Object 2

Object 2

Object 3

Object 3

Object 4

Object 4

Object 1

Object 1

Object 2

Object 2

Object 3

Object 3

Object 4

Object 4

• Time synchronization of objects

• each object has to update its current state

• each object can tell when it wants to update next

• under the assumption that the other objects stay in their current state

• next synchronisation (of all objects) scheduled for the nearest requested update time


GridLAB-D: Results for use case 1

Faster than Dymola, because of explicit event handling! Model needs to be analytically solvable!

• Execution time scales with the square of the number of objects (dashed line)

• Saturation effect for large number of objects

• average time between two updates smaller than minimum time step (default 1 second)

• scales linearly (dotted line)


GridLAB-D: Overview

• Pro: agent-based simulation performs very well

• allows precise timing of dynamic interactions

• even for large-scale event-driven problems

• Con: no support for time-based simulation (integrators etc.)

• Pro: software core provides many useful features

• plugin-system, hierarchies

• communication utilities

• modeling language

• Con: written in (legacy) C

• some parts are poorly documented

• sometimes tedious to implement

• extension are hard to implement and most likely end up as quirky hacks


What is co-simulation?

• “normal simulation”

• Model → ODEs/DAEs

• One modeling tool, one solver (e.g. Euler, RK45, DASSL, ODE15s, etc.)

• Co-Simulation

• Multiple solvers, multiple tools!

• Coupled models

# solvers

One System from

differently modeled

Parts

“Classic” Simulation

Model Separation

for Simulation

1 >1

1

>1

# To

ols

ODE: ordinary differential equationDAE: differential-algebraic equation

CoSimulation


Coupled Models

• r coupled systems of DAEs

• m external steps during simulation time

• n internal steps during one external step

FMU1

FMU2

FMU: Functional Mockup Unit, a single model...


Implicit and explicit coupling

• Explicit coupling exchanges data at every external step once

• Implicit coupling iterates each external step until the system converges

• # external steps determines error


Example for internal/external steps

• 2-DOF oscillator

• Effectively two subsystems with different frequencies

• Different step sizes for subsystems desirable

• Generate two subsystem and try different micro and macro step sizes

• Use a simple solver (forward Euler) and equidistant steps

DOF: degrees of freedom


Results

• Monolithic simulation (blue)

• Gauss-Seidel/Jacobi co-simulation

• Case A: quick subsystem stays with 1 internal step

• Case B: slow subsystem stays with 1 internal step

1 internal step per external step

10 internal steps per external step case A

10 internal steps per external step case B

Err

or

# external steps


FMI Functional Mock-up Interface

• ITEA Modelisar Project: Daimler, DLR, ITI, Qtronic, SimPACK, Dynasim, LMS,…

• FMI: A standardized API for describing models of DAE-based modeling environments (Modelica, Simulink, etc.)

• FMU:

• XML file describing the model

• C-Code / *.DLL or *.so libraries implementing the model equations

• Can be utilized by:

• Offline/Online simulations

• Embedded control systems

DAE-basedModeling

Environment

FunctionalMock-up

Unit (FMU)

Simulation-basedEnvironments

FMI Export

Utilized by


FMI for Model Exchange

• Functional Mock-Up Unit

• model interface (shared library)

• model description (XML file)

• Executable according to C API

• low-level approach

• most fundamental functionalities only

• tool/platform independent

Well suited for simulation tools focusing on hybrid ODE-based modeling continuous time-based simulation (OpenModelica, Dymola, SimulationX, …) provide integrators, event handling


The FMI++ library

• High-level access to FMUs

• model initialization, get/set variable by name, etc.

• High-level FMU functionalities

• integrators, event handling, rollback mechanism, look-ahead predictions, etc.

• Open-source C++ library

• tested on Linux and Windows (MinGW/GCC and Visual Studio)

• available at sourceforge.net

http://sourceforge.net/p/fmipp/


Class IncrementalFMU: advanced event handling

• Implements advanced event-handling capabilities for FMUs

• Use look-ahead predictions

• predict occurrence of next internal event

• react to external events

• Especially useful for discrete event-based simulation


Example: TRNSYS with Modelica

Modelica modelfor a District Heat Network

TRNSYSBuilding Model


Coupling ways

C++Template

FMU

TRNSYS TYPE DLL

Modelica Model

FMU1

TRNSYS TYPE

for importing arbitrary FMUs

Modelica Model1

FMU2 FMUn

FMI++

FMI Export

Modelica Model1

Modelica Model1

Specific FMU Type

Generic FMU Type


Download and contribute!

• FMI++ library

• model-independent functionalities for simulating FMUs (for Model Exchange)

• numerical integration, advanced event handling, etc.

• eases the inclusion of FMUs into simulation environments

• examples: PyFMI, Ptolemy II and GridLAB-D

• hides low-level details of FMI behind C++ interfaces

• open source, available at http://sourceforge.net/p/fmipp/

• Add your favorite tool to the CES ecosystem!




Proof of concept: Use Case 7: dynamic demand-response simulation

small scale distribution gridmedium/low voltage network with consumers

small scale distribution gridmedium/low voltage network with consumers

realistic battery modelrealistic battery modelhousehold load profilestaken from measurement campaign

household load profilestaken from measurement campaign

charging control algorithmdistributed charging power regulation

charging control algorithmdistributed charging power regulation

stochastic driving patternsderived from real-world car sharing data

stochastic driving patternsderived from real-world car sharing data


Use Case 7: GridLAB-D, PowerFactory, OpenModelica

Electric Vehicles (GridLAB-D)

• driving behavior (agents)

• energy demand

• charging process

• Battery (Modelica)

• Power System (PowerFactory)

• load and generation

• dynamic loads from EV

• Charge Control (GridLAB-D)

• keep voltage limits


Use Case 7: Prototype I demonstration (with PowerFactory)


Dynamic step size control

• Example

• State of Charge of car batteries

• Undervoltage during charging

• -> limit charging current

• Controller is really busy


Use Case 7: GridLAB-D, PSAT, OpenModelica, 4DIAC

Open Source (!) Simulation Environment

• Power System (PSAT)

• Charge Control (4DIAC)


Use Case 7: (OSS only)


Ptolemy II

• Multi-purpose simulation environment

• open source, developed at UC Berkeley

• „Serves as a playground for experimenting with different models of computation and their combination in heterogeneous models“

• Main features

• usually used via a graphical user interface (Vergil)

• written in JAVA, runs on every platform that supports JAVA

• models and composite actors are stored in a XML-based scheme (MoML)

• can be used in conjunction with JAVA (MoML parser)

• based on the concept of actors and directors

• allows to combine different models of computation (MoC) in hierarchies

• allows to create hybrid models using modal models

• comes with a pre-defined set of actors for various MoCs

• synchronous data flow (SDF): performs basic sequential data operations

• discrete events domain (DE): SDF plus a notion of time, for discrete systems

• continuous domain: atop of DE, allows to study continuous systems


Ptolemy II: composite actors and hierarchies

• Sub-models can be encapsulated in composite actors

• Opaque composite actor

• composite actor with its own director

• not necessarily of the same MoC as at the upper level hierarchy

• appear as „black box“ to the outside


Ptolemy II: finite state machines

• Ptolemy II supports a sophisticated implementation of finite state machines


Ptolemy II: modal models for hybrid systems

• Modal models are a composite actors

• multiple refinements instead of just one

• each refinement gives one behavior

• State machine determines which refinement is active at any given

time


Ptolemy II: superdense time

• In superdense time a timestamp consists of

• model time t

• microstep (also called index) n

• allows to handle simultaneous causally-related event

from: E. A. Lee, Modeling, Simulation, and Design of Concurrent Real-Time Embedded Systems using Ptolemy


FMI ME specification

initialize instantiate setContinuousStates setTime completedIntegratorStep … and many. many more

high-level wrapper

Ptolemy II abstract semantics

FMI++: class IncrementalFMU

initialize synchronize checkForEvent handleEvent

Ptolemy II: FMU-ME actor

initialize prefire fire postfire wrapup

Example: Mapping of Ptolemy II’s semantics to FMI++


Example: FMU actor in Ptolemy II’s DE Domain


Conclusion

Prof. Dr. Peter PalenskyIntelligent Electric Power Grids

TU Delft, [email protected]

• Co-simulation is the way to go

• FMI is a hot topic and supported by powerful industries

• Low level technology -> upgrade via FMI++

• Problems with event handling?

• Ptolemy II is promising

• hierarchical composition of MoCs

• modal models

• Based on solid concepts

• finite state machines

• abstract semantics

• superdense time

co-simulation of energy systems - associate … · co-simulation of energy systems ... trnsys type...

Documents