Co-Simulation of Energy Systems - Associate … · Co-Simulation of Energy Systems ... TRNSYS TYPE...
Transcript of 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
2Challenge the future
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
3Challenge the future
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)
4Challenge the future
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
5Challenge the future
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
6Challenge the future
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
7Challenge the future
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
8Challenge the future
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
9Challenge the future
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;
10Challenge the future
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
11Challenge the future
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
12Challenge the future
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;
13Challenge the future
Tool: SimScape
• Matlab / Simulink / Simscape
• Multi-Physics Toolbox, Modelica Clone
• Block-Oriented or Equations
• www.mathworks.com/products/simscape/
14Challenge the future
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
15Challenge the future
Use Case 1: SimScape
• Do
• Generate Simulink Drawing
• Many houses
• One Market, etc.
• Simulate
• Store results
• Until (all simulation cases)
16Challenge the future
Use Case 1 SimScape results
17Challenge the future
Usecase 2 Simscape Implementation
18Challenge the future
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.
19Challenge the future
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
20Challenge the future
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)
21Challenge the future
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
22Challenge the future
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
23Challenge the future
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...
24Challenge the future
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
25Challenge the future
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
26Challenge the future
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
27Challenge the future
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
28Challenge the future
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
29Challenge the future
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
30Challenge the future
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
31Challenge the future
Example: TRNSYS with Modelica
Modelica modelfor a District Heat Network
TRNSYSBuilding Model
32Challenge the future
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
33Challenge the future
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!
34Challenge the future
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
35Challenge the future
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
36Challenge the future
Use Case 7: Prototype I demonstration (with PowerFactory)
37Challenge the future
Dynamic step size control
• Example
• State of Charge of car batteries
• Undervoltage during charging
• -> limit charging current
• Controller is really busy
38Challenge the future
Use Case 7: GridLAB-D, PSAT, OpenModelica, 4DIAC
Open Source (!) Simulation Environment
• Power System (PSAT)
• Charge Control (4DIAC)
39Challenge the future
Use Case 7: (OSS only)
40Challenge the future
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
41Challenge the future
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
42Challenge the future
Ptolemy II: finite state machines
• Ptolemy II supports a sophisticated implementation of finite state machines
43Challenge the future
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
44Challenge the future
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
45Challenge the future
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++
46Challenge the future
Example: FMU actor in Ptolemy II’s DE Domain
47Challenge the future
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