Co-Simulation of heterogeneous Energy

SystemsPeter Palensky

TU Delft, Netherlands

1

Back in 2004: IRON Box

• Embedded rail-mount communicating node

• Measures consumption, frequency

• Takes influence on load behavior

• Demand Response

• Aggregates (virtual)storages

• Shedding, shifting

Refrigerators as control power stations

• Real measurement (!): nominal power over freq

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

Modeling a hybrid system

• Hybrid = discrete + continuous

• Options– Abuse discrete models

• Put continuous part into discrete form

– Abuse continuous models• Represent asynchronous events as

continuous curve

– Have universal model• Universal language, special solvers

– Co-simulation• Best of both worlds?

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)

Example: 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

– Monolithic, acausal• Equation-based model of physics -> ODE-> code• Solver integrates and tries to find zero crossings• Examples: Modelica, Simscape

– Agent/Module-oriented, causal• Autonomous modules• Components determine synchronization points• Examples: GridLAB-D, Omnet++

ODE: Ordinary Differential Equations

Monolithic tools example

• Simscape, Modelica

• PRO– Convenient

– Multi-domain physics

– Strong syntax

– Good docu

• CON– Low Performance

– Closed platforms?

– Events?

A

External World of Component A

B

C

Energy Ea+E

b+E

c=0

Potential Pa=P

b=P

c

Ea

Pa

Eb

Pb

Ec

Pc

ModelFlat

ModelSorted

Equations

Index ReducedEquations

ODEExecutable

flattening sorting

Indexreduction

Modular tools example

• 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

– provides various simulation utilities• debugging, profiling, plotting, histogramming, write to file etc.

Modular tools: 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

• Modules propose sync points

Modular: 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)

Modular tools: conclusion

• Pro– allows precise timing of dynamic interactions

– even for large-scale event-driven problems

– modular, hierarchies

• Con:– Integrators?

– (Multi)Physics sometimes tedious to implement

– extension are hard to implement

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

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 (OpenModelica)

• Power System (PowerFactory, also PSAT/Octave)– load and generation

– dynamic loads from EV

• Charge Control (GridLAB-D, also 4DIAC)– keep voltage limits

FMI: Functional Mockup Interface

Use Case 7: Prototype I demonstration (with PowerFactory)

Agent/discrete Part

• Done in GridLAB-D

• Sequence of car activities

• Configured via car-sharing monitoring data

Dynamic step size control

• Example

• State of Charge of car batteries

• Undervoltage during charging

• -> limit charging current

• Controller is really busy

Example for Master Algorithm: 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“

• Java

• Actors and directors

• Combine different models of computation (MoC) in hierarchies

• Hybrid models using modal models

• Pre-defined set of actors for various MoCs– synchronous data flow (SDF) (sequential data)

– discrete events domain (DE): SDF plus a notion of time

– continuous domain: atop of DE

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

actor abstract semantics

• MoCs implement concrete semantics governed by the directors

• Concrete semantics conform to abstract semantics– permits hierarchical composition of different MoCs

• model of time– directors with a notion of time provide this information to their actors

– actors may schedule events

• communication– determine how send/receive of data between actors is done (FIFO

queues, mailboxes, proxies for a global queue, rendezvous, etc.)

• execution control– defines flow of control for execution (interface + assumptions)

– example: only postfire() method should change the state of an actor

• domain polymorphic Actors: can be used within any actor-oriented director

E.g.: FMU actor in Ptolemy II’s DE Domain

FMU: Functional Mockup Unit

Conclusion

Prof. Dr. Peter PalenskyIntelligent Electric Power Grids

TU Delft, NETHERLANDSpalensky@ieee.org

• Co-simulation is the way to go

• FMI is a hot topic and supported by powerful industries– Events? -> upgrade via FMI++

• Master Algorithm?– Ptolemy II is promising

• hierarchical composition of MoCs• modal models, etc.

– MOSAIK

• Fundamentals → Applications

FMI: Functional Mockup Interface