Research ArticleA Cosimulation Architecture for Power SystemCommunication and Market in the Smart Grid

Markus Mirz 1 Lukas Razik 1 Jan Dinkelbach 1 Halil Alper Tokel 2

Gholamreza Alirezaei 2 Rudolf Mathar2 and Antonello Monti 1

1 Institute for Automation of Complex Power Systems RWTH Aachen University Aachen Germany2Institute for Theoretical Information Technology RWTH Aachen University Aachen Germany

Correspondence should be addressed to Markus Mirz mmirzeonercrwth-aachende

Received 24 November 2017 Accepted 30 January 2018 Published 28 February 2018

Academic Editor Joao Soares

Copyright copy 2018 Markus Mirz et al This is an open access article distributed under the Creative Commons Attribution Licensewhich permits unrestricted use distribution and reproduction in any medium provided the original work is properly cited

Smart grids evolve rapidly towards a system that includes components from different domains which makes interdisciplinarymodelling and analysis indispensable In this paper we present a cosimulation architecture for smart grids together with acomprehensive datamodel for the holistic representation of the power system the communication network and the energymarketCosimulation is preferred over amonolithic approach since it allows leveraging the capabilities of existing well-established domain-specific software The challenges that arise in a multidomain smart grid cosimulation are identified for typical use cases througha discussion of the recent literature Based on the identified requirements and use cases a joint representation of the smart gridecosystem is facilitated by a comprehensive datamodelTheproposed datamodel is then integrated in a software architecture wherethe domain-specific simulators for the power grid the communication network and the market mechanisms are combined in acosimulation framework The details of the software architecture and its implementation are presented Finally the implementedframework is used for the cosimulation of a virtual power plant where battery storages are controlled by a novel peak-shavingalgorithm and the battery storages and the market entity are interfaced through a communication network

1 Introduction

The increase of distributed energy resources (DERs) in powersystems and the resulting bidirectional power flows are driv-ing changes in the associated communication infrastructureandmarket mechanisms For instance the ongoing extensionof measuring infrastructure in lower voltage layers requires aconcurrent deployment of a capable communication networkin order to provide for a reliable communication among con-trol centers substations and measurement devices Hencethe planning of electrical grid operation and the underlyingcommunication network should be considered simultane-ously in order to enable the analysis of the impact ofinteractions between the two domains as it is already shownin [1] Meanwhile new market models are developed tosupport customers taking amore active role in their exchangeof power with the grid [2] in such a way that their behaviorwill also be taken into account in the grid operation [3] Forexample individual users can contribute to a more efficient

operation of the grid by putting their battery storage atthe disposal of the grid operators which would require acommunication network for the data exchange Bearing thisdevelopment in mind it is interesting to include a marketsimulation in the analysis as well

This integration of market mechanisms the communica-tion network and the power system complicates studies onfuture power systemsrsquo behavior since a common modellingapproach that encompasses the three domains has not beenestablished yet and there are few tools that enable a joint sim-ulationThe comprehensive data model and the cosimulationarchitecture presented in this work tackle these challengesenabling the investigation of dynamic interactions betweenthe electrical grid communication network and marketThese interactions could be technical constraints to the gridthat require actions on the market side communicationfailures that affect the control loop between the grid and themarket and market decisions that change the behavior of ageneration unit or energy consumers connected to the grid

HindawiComplexityVolume 2018 Article ID 7154031 12 pageshttpsdoiorg10115520187154031

2 Complexity

Therefore we propose a data model based on the IEC Com-mon Information Model (CIM) [4] that is able to describean entire smart grid topology including communication andmarket entities Besides the proposed data model allowsusers to store the whole network topology with componentsfrom the three domains in a single well-defined data modeltherefore hiding the complexity of the cosimulation from theusers Topology descriptions compliant with this data modelcan be processed by the presented cosimulation architectureThis architecture and implementation example combinesdedicated simulators for the power system communicationnetwork and energy market whereas previous approachesknown to the authors only considered a subset of these threedomains or monolithic concepts

The main contributions of this paper can be summarizedas follows

(i) Analysis of the requirements of a cosimulation com-bining the three domains and definition of the cosim-ulation specifications

(ii) Identification of technical challenges of interconnect-ing the simulators

(iii) Development and the implementation of the cosimu-lation architecture and the interfaces that implementthe specifications

(iv) Validation of the proposed cosimulation environmentby simulation results

The paper is structured as follows Section 2 gives anoverview of the related work on integrated modelling andsimulation of smart grids In Section 3 we identify anddescribe the use cases for which the proposed cosimulationenvironment can be used The challenges for the realizationof the cosimulation environment are discussed in Section 4whereas we present our solutions regarding the designed datamodel and the software architecture but also its limitationsin Section 5 The integrity of the cosimulation environmentis validated by the results of a cosimulation in Section 6where an optimal management of distributed battery storagesystems is simulated to improve the voltage stability ofa distribution network We conclude the paper with finalremarks in Section 7

2 Related Work

21 Architecture and Data Model The evolution of tradi-tional power systems towards intelligent power grids hasrecently triggered efforts for comprehensive modelling andstandardization which aim to include various aspects ofa smart grid ecosystem One major contribution in thiscontext is the Smart Grid Architecture Model (SGAM) whichprovides a basis for the representation of relationshipsbetween entities functionalities and subsystems in smartgrids [5] SGAM framework models a smart power grid infive interoperability layers which cover physical componentsin the network (component layer) protocols for exchangeof information between services or systems (communicationlayer) data models which define the rules for data structures

(information layer) functions and services (function layer)and business and market models (business layer) The modelfurther divides the component layer to hierarchical electricalenergy conversion and transmission domains from generationto customer premises and to component zones such as fieldand station This architectural view aims to accelerate andstandardize the development of unified datamodels servicesand applications in industry and research In this context ourdata model and cosimulation framework in this work buildupon the fundamental concept of SGAMwhere our focus liesin the following aspects of SGAM

(i) The unified data model which is presented in Sec-tion 51 formally defines the structure for dataexchange in alignment with the concept of the infor-mation layer of SGAM

(ii) The domain-specific simulators of our cosimulationenvironment include models of power system andcommunication network components as well as mar-ket actors in the component layer of SGAMwithin thedistribution DER and customer premise domains

(iii) The communication layer is abstracted by a cosim-ulation interface and the extensions in the domain-specific simulators in order to enable the dataexchange between the components

(iv) The example use case presented in Section 6 regard-ing the optimal management of distributed batterystorage systems is an example of a system func-tion which would fall on the function layer in theSGAM framework Besides the business model thatmotivates the provision of such a system functionfor example an incentive by the system operator isdefined within the business layer

For the realization of the unified data model in alignmentwith the SGAM concept we identify the IEC CommonInformation Model (CIM) [4] as a well-established basis forextensions in Section 51 as it is a widely accepted format toexchange grid data in power systems Although it includesan extensive list of electrical grid components as well asmarket-related objects the communication infrastructure ofa power system is hardly included except for a few classesregarding supervisory control and data acquisition (SCADA)links However CIM can easily be extended as demonstratedfor the market in [6 7]

22 Simulation of Smart Grids There have been severalattempts to build a cosimulation environment with the focuson power grids and communication networks for example[1 8ndash10] However the proposed approaches so far do notaccount for the market because they focus more on short-term effects caused by limitations of the communicationnetwork

AlthoughMOCES [3] attempts to take a holistic approachtomodel distributed energy systems this results in the imple-mentation of a monolithic simulation instead of a cosimula-tion with a hybrid simulation for the physical part and anagent-based simulation for the behavioral part which could

Complexity 3

represent the market Therefore this approach hinders theuse of existing domain-specific tools and requires substantialdevelopment effort Instead in this work we aim to takeadvantage of the capabilities that existing tools offer which (i)enhances the credibility of the results and (ii) decreases theeffort that is needed to replicate their functionalities

The proposed simulation framework consists of severalsimulators each responsible for a specific domain Theadvantage is the possibility of using the best tool for eachdomain Besides the vision is to be able to replace simulatorswith reasonable effort if the simulation requirements changeFor example in Section 6 it is mentioned how [11] could beused to implement amore comprehensivemarket simulation

23 Classification of Simulations Schloegl et al [12] providesa clear classification scheme for energy-related cosimulationsBecause our cosimulation environment shall provide holisticsimulations all four categories of simulation elements ormodels (ie continuous processes discrete processes andevents roles and statistical elements) defined by Schloegl etal have to be considered

In our implementation the power system is modelledin Modelica as it can be used for physical systems in gen-eral [3] and has already proven its capabilities for thermalsystems [13] and power systems in particular [14] Modelicamodels consist of continuous processes discrete processesand events which makes the power system simulation ahybrid simulationThe communication network is simulatedwith the available discrete event simulation (DES) tools suchas ns-3 In a DES the simulation time proceeds with theexecution of single events such as packet arrival and timeexpiry [15] The energy market simulation is implemented inPython asDES Pythonwas chosen as programming languagebecause of its suitability to implement and test differentoptimization methods [16] Each market participant aims atoptimizing the schedule for its assets for example minimiz-ing energy costs and maximizing its profit Depending onthe simulation scenario the behavior or role of the marketparticipants changes Examples for statistical elements arewind farm models of the energy grid simulator and commu-nication link models which consider packet losses and thereliability metrics of the communication network simulator

Furthermore the proposed cosimulation environmentcan be formalized as a coupled Discrete Event System Specifi-cation (DEVS) as defined in [17] which is why a classificationof our architecture in terms of DEVS is given in Section 55

3 Use Cases of the Cosimulation Environment

Our cosimulation solution including the three domains canbe used to evaluate different scenarios To address the physi-cally relevant dependencies we divide the dynamic interac-tions between the simulators into two groups

(i) Fast phenomena in the range of microseconds toseconds between highly dynamic power system com-ponents for example power electronics and commu-nication network

(ii) Slow phenomena in the range of minutes to hourswhich include market entities power system andcommunication network

In recent literature the most prominent fast dynamicinteractions occur in wide area measurement and controlapplications as well as remote power electronics devices[10] Compared to slow phenomena the simulation of fastphenomena requires relatively smaller simulation time stepsdue to switching events of electronic components and the factthat the market interactions are not consideredTherefore ina cosimulation of the fast phenomena the focus should bemore on the efficiency of the cosimulation interface ratherthan a simplification of the coupling with multiple simula-tors The proposed cosimulation environment is intended tosupport the investigation of fast dynamics but should not belimited to them This has an influence on our design of thecommunication interface between the simulators as can beseen in Section 54

On the other hand slow phenomena are created byclosing the loop between the power system and marketby means of the communication network The behavior ofmarket entities may cause changes in the usage of powersystem components which has an impact on the grid and viceversa and this loopmight be impaired by the communicationnetworkThe cosimulation environmentmight be used eitherto verify the functioning of the control loop given a specificcommunication network or to plan a communication net-work that fulfills the requirements of the control mechanismsin power system and market

Based on this classification of use cases it can be con-cluded that all three simulators do not necessarily have to beactive at the same time for all scenarios In this paper we willfocus on the requirements and the implementation for thecosimulation of slow phenomena and confine our discussionon fast phenomena to a description of the adaptions neededfor fast phenomena investigations since there already existseveral cosimulation environments proposed for these stud-ies [1]

An example use case for slow phenomena is the optimalmanagement of distributed storage systems for peak-shavingto support the grid operation The proposed cosimulationenvironment including the communication network allowstesting the effects of communication failures on the operationstrategy and eventually on the electrical grid which canprovide valuable insights for decision-making Simulationresults for this example are provided in Section 6

Before the cosimulation is initiated it is necessary todefine and store the topology under investigation along withthe scenario-specific parameters For example the scenarioscan be investigated in which the failures in the commu-nication network are stochastically or deterministically setby the user in the data model From a user perspective itwould be advantageous if all components their links andparameters could be defined in one environment ratherthan splitting this information between different softwaresolutions and formats Then the data model for the topol-ogy needs to include components that couple differentdomains

4 Complexity

From these use cases the following challenges can beidentified

(i) Common data model that includes components of alldomains and their interconnections

(ii) Interaction of simulators with different simulationtypes for example event-driven for the communica-tion network and continuous processes for the powersystem

(iii) Choice of the cosimulation time step which is limitedby the synchronization method connecting the simu-lators

4 Challenges of the Cosimulation

41 CommonDataModel A common datamodel that coversthe electrical market communication infrastructure andgrid does not exist to the best of our knowledge eventhough these components are integral part of smart gridsNot only would the user of a simulation software benefitfrom a common data model during the specification ofthe simulation scenario but the data exchange would alsobe simplified A system description that encompasses allcomponents of smart grids as shown in Figure 1(a) couldbe either used directly by holistic smart grid simulators ordivided into subsystems for a cosimulation as in Figure 1(b)

For many components this division is straightforwardsince their parameters are only needed by one domain-specific simulator For example electrical lines exist only inthe power system domain and have connections only to otherpower system components Some components on the otherhand constitute natural coupling points between the powersystem the market and the communication network Thesecomponents are called interdomain components in the follow-ing For instance a battery storage device connected to thegrid can act as a market participant that offers its capabilityto charge or discharge In order to enable its participationin the energy market the battery storage needs an interfacewhich is a communication modem in this case The modemcan be seen as a part of the battery storage Therefore thedata model class associated with the battery storage devicehas to be able to hold or reference to data on the properties ofthe battery storage in electrical market and communicationdomains For a cosimulation the information on interdomaincomponents have to be split into several parts since theirparameters are needed by the simulators and each simulatorhas to simulate a dedicated part of these components

42 Cosimulation Time and Synchronization A remainingand major issue in such a cosimulation in which simulatorsof different categories are combined is the selection andimplementation of a proper synchronization mechanismwhich must ensure the proper progress of the simulationtime and a timely data exchange between the domain-specificsimulators This selection is of crucial significance in orderto minimize the error propagation in the cosimulation andthe synchronization overhead in terms of simulation timeIn [1] three main synchronization methods for cosimulation

have been specified time-stepped global event-driven andmaster-slave There are two different considerations relatedto the simulation time [12]

(i) Time resolution a challenge of the cosimulationis the highly diverse time resolutions of the threesimulators The time steps of power grid simulatorreach from milliseconds (electromagnetic processes)to subseconds and above (steady-state and electrome-chanic processes) The time steps of communicationnetwork simulations can even vary from tens ofmicroseconds (eg latencies in LANs) to seconds(eg latencies in WANs) On the other hand inenergy market simulations a time step of severalminutes can be sufficient as it is the case forGermanyrsquoscontrol power market with price calculations on 15-minute basis

(ii) Time ratio time ratio describes the relation betweensimulation time and wall clock time [12]With appro-priate use cases we want to show how holistic cosim-ulations with our approach can be used for planningand decision-making Therefore it is important torun the scenarios much faster than wall clock timeand for time intervals of days as well as of weeks sothatmanymodelswith different configurations can besimulated

The problem is that a very small time step or a high resolutionin time impedes short simulation times Therefore it isnecessary to adjust the time step according to the phenomenathat are under investigation At the same time it may befeasible to aim at a higher integration of the simulators andsacrifice flexibility and increase the efficiency if both timeresolution and time ratio need to be optimized In Section 53we discuss our design choices regarding the synchronizationof the simulators in detail The approach for an optimizationof time resolution and time ratio is further discussed in theSection 54

5 Concept of the Cosimulation Environment

51 Data Model for Power System Communication Networkand Market As explained in Section 2 one possibility isto extend the cosimulation topology format on CIM whichleads to a superset of CIM New classes which are introducedfor completing CIM in its representation of smart grids arelinked to theCIMclasses using the terminology of theUnifiedModeling Language (UML) The proposed format can bestructured in four packages

(i) Original CIM (IEC61970 IEC61968 IEC62325)(ii) Communication(iii) Market(iv) EnergyGrid

Whenever possible the CIM classes are used Howeversome components might not have an associated class in thestandard yet Then these components are represented asclasses in one of the other three packages The reason for

Complexity 5

Wholesale andretail market

Marketparticipants

(a)

Power system Communicationnetwork

Wholesaleand retail

Market

market

participantsMarket

(b)

Figure 1 Exemplary topology including components of all domains (a) and domain-specific topologies (b)

this approach is that this way it is easier to update to a newversion of CIM without losing the newly added classes andtheir interconnections

The most important feature of our model formatis the interconnection of domains In order to accom-plish this we have identified possible interdomain com-ponents Some examples of interdomain componentsnamely BatteryStorage SolarGeneratingUnit andMarketCogeneration are shown in Figure 2 which isan excerpt from our data model According to the UMLdiagram the energy market components are associatedwith the power system components whereas power systemcomponents have an aggregation relationship to com-munication devices This means that parameters specificto the market communication network and power systemwhich relate to the same device are linked with each otherTherefore all information on one device is easily accessiblebut at the same time there is a separation according tothe domains The connections between classes of differentdomains are defined in a logical and not a topological wayInstead topological connections exist to connect powersystem components for instance

Coming back to the battery storage device example thedatamodel is as follows the device is a part of the grid and haselectrical parameters Furthermore the battery storagemightparticipate in the market for example as part of a virtualpower plant (VPP) Market-specific information can bestored in the MarketBatteryStorage class which is associ-atedwith the electrical representationBatteryStorageThedata on the class for a communicationmodem ComModwhichcould be used to communicate with the VPP is aggregated tothe BatteryStorage class

In the following we briefly mention the domain-specificconsiderations for the three domains

(1) Power System Package The purpose of the EnergyGridpackage is to group models for power system componentsthat are not already part of the CIM standard For the simula-tion scenario that is presented later it was necessary to create

a new model for electrical energy storages like stationarybatteries A battery storage is a conducting equipment thatis able to regulate its energy throughput in both directionsTherefore the class BatteryStorage is a specialization ofa CIM RegulatingConductingEquipment since it caninfluence the flow of power at a specific point in the network

(2) Market Package The key component of the marketpackage for the scenarios that we would like to investigateis a VPP since the aggregation of small DER units enablestheir participation at electricity markets In case the DERsare not owned by the operator of the VPP they can be seenas customers that offer their energy in exchange for share ofthe VPP operators profits Besides a VPP might support theDistribution System Operator (DSO) in ensuring a safe gridoperation which results in an association between the DSOand the VPP

(3) Communication Package This package includes all addi-tionally defined classes that are related to the communicationnetwork model such as classes for communication linksand technologies modems network nodes along with theirparameters and their relations with the classes in CIMpower system package and market package In this waythe user can model the communication network layer andits specifications in the simulation tool The communicationnetwork topology and its parameters are then used by thecommunication network simulator for the cosimulation

Figure 3 shows an excerpt from the communication datamodel with an aggregation to a WindGeneratingUnit Bymeans of the associated classes for modems communicationrequirements and channels the model enables a descriptionof network parameters and topology Furthermore the com-munication network data model integrates the flexibility toenable the planning of the communication network undercommunication and power system requirements even beforethe beginning of the cosimulation The topological parame-ters will be used for an optimal design of the communica-tion network with the desired objective such as minimum

6 Complexity

Market

MarketBatteryStorage

Power System

EnergyStorageBatteryStorage

Communication

MarketSolarGeneratingUnit

GeneratingUnitProduction

SolarGeneratingUnit

EquipmentMarketCogenerationUnit

ProductionCogenerationPlant

ModemsComMod

PowerSystemResourceRegulatingCondEq

EquipmentEquipment

Figure 2 Interdomain connections between classes of power sys-tem communication network and market

GeneratingUnitWindGeneratingUnit

ComMod

WirelessMod

LTEModem

01

communicationRequirement

WiredMod

FiberModemWiredInterface

FiberInt

WiredChannelFiberChannel

11

1

0lowast

1lowast

1

Figure 3 Communication network class association example

cost while required conditions are satisfied such as givenreliability metric An example of this approach is presentedin [18] for an integrated design of a wide area measurementsystem Eventually the optimized communication networksolution can be evaluated against different scenarios using thecosimulation environment

52 Model Data Processing and Simulation Setup The overallinformation flow for the simulation setup is depicted inFigure 4 After the topology is created or modified in agraphical Topology Builder and includes the three domainsthe input file which complies with the common data modelof Section 51 is sent to the cosimulation interface Thecosimulation interface incorporates a component basedon CIM++ [19] which parses the CIM XML-RDF fileand generates a container of C++ objects that containthe topological data In order to execute a simulationthe Modelica solver requires a Modelica model whereas

Modelica models

Power systemsimulation

Modelica (DymolaOpenModelica)

Topology builder

Extended CIM

Cosimulation interfacemosaik CIM++

Objects2ModelicaObjects2Comm Net

Block diagram oftopology

XML representationof topology

C++ objects amp simulatorspecific text formats

Communication networkPython objects topology

CommunicationMarket simulation simulationpython ns-3 etc

Figure 4 Overall architecture for simulation setup

the communication network topology can be given to thecommunication network simulator in JSON or XML for-mat which includes the components in the network theirconnections and parameters Since the topology will beavailable as an XML-RDF file and a container of C++objects the relevant information for the power system andcommunication network is extracted during a deserializationstep In the subsequent transformation step a componentwhich we call Objects2ModelicaCommunicationNetworkgenerates Modelica and communication network files withthe topology and parameters In contrast the Python basedmarket simulation relies on a C++Python interface whichcould be realized using one of the common libraries forPython to wrap C++ data types and functions to retrieve themarket relevant information from the C++ objects and storethem in Python objects

The following paragraph explains the translation on thebasis of a CIM to Modelica example The loads are definedin the extended CIM data model described in Section 51 asPQ-loads with a characteristic power demand as follows

ltcimSvPowerFlow rdfID=PQ1-svgtltcimSvPowerFlowpgt1000ltcimSvPowerFlowpgtltcimSvPowerFlowqgt329ltcimSvPowerFlowqgtltcimSvPowerFlowTerminal

rdfresource=E-1229789360gtltcimSvPowerFlowgt

The cosimulation interface extracts the corresponding com-ponent parameters from the CIM XML-RDF file and intro-duces them in the Modelica model of the grid The latteris done by the Objects2Modelica component explained inSection 52 which iterates through the list of C++ objects pro-vided by CIM++ Thus the specification of the parameters 119875and119876 in the CIMmodel generates two attributemodificationequations in the declaration of the PQ-load in Modelica

Complexity 7

ModPowerSystemsPhasorSinglePhaseLoads

PQLoad CIM PQ1 (Pnom = 1000 Qnom = 329)

These values are applied during the quasistationary simula-tion of the single-phase representation of the grid

53 Synchronization The synchronization of all three sim-ulators will be performed in fixed time steps Fixed syn-chronization time steps have been chosen because of theresulting flexibility to integrate more simulators easily and itscomparatively high speed in terms of time steps per simula-tion time [1] An event-driven approach as it is implementedin [10] for two simulators requires a deeper integration ofthe cosimulation framework and the simulators Apart fromthat it was shown in [10] that the cosimulation error can bereduced for fixed time steps by reducing the global time stepsize

The synchronization between all simulators for slowphenomena scenarios is performed with mosaik a well-established cosimulation framework [20] which was devel-oped for stationary simulations with time steps of one secondor greater [21] It allows combining the three simulators in asimple manner as explained in Section 54 VILLASnode asoftware project for coupling real-time simulations in LANs[22 23] is a suitable alternative for mosaik in the case ofsynchronizations with very short intervals

In Modelica the synchronization data exchange isachieved by integrating Modelica blocks of the ModelicaDeviceDrivers library which was originally developed forinterfacing device drivers to Modelica models This con-veniently allows the definition of a fixed interval for dataexchange Modelica DeviceDrivers were chosen instead ofthe FMI approach shown in [21] because it allows moreflexibility in picking the desired simulation variables andchoosing the required cosimulation step size independentlyfrom the Modelica simulator time step At synchronizationsteps between all simulators the step function of the energymarket simulator is called synchronously from the mosaikPython API After the market simulator has finished thesimulation step the results are retrieved by mosaik

The simulation time in the DES of the communicationnetwork advances with the execution of the generated eventswhich are stored in an event-list The execution of eventsis controlled by a scheduler which determines the nextevent and its execution time Whereas the default schedulerexecutes the events sequentially without any interruptionsthe available simulation environments offer the flexibility tointegrate external control inputs to receive external controlmessages which can be used to manipulate the simulationflow by changing the module parameters during the simula-tion In order to realize this the event-driven nature of DEStools can be used to generate new events called flow controlevents which stop the communication simulation exchangedata and use the input data to manipulate the followingsimulation steps Furthermore the execution of events canbe controlled and the simulation can be stopped after theexecution of the last event before a synchronization point sothat the simulation runs in fixed steps and a data exchange ispossible at the end of each step

Powersystem

Commnetwork

MarketEvent 0

Event 1

Powersystem

Commnetwork

MarketEvent 2

Event 3

Powersystem

Market

Individualsimulator steps

Cosimulation step

0

0

0

0

1

1 2

1 1

1

2

2

211

Figure 5 Synchronization scheme of simulators at cosimulationtime steps

Figure 5 depicts the flow of time for the cosimulationand each simulator It can be seen that the power system andmarket simulators compute in parallel whereas the commu-nicationnetwork iswaiting for their inputs In amathematicalnotation the interactions between the simulators in eachcosimulation step can be defined by

119906119901 (119899 + 1) = 119865119888 (119865119898 (119906119898 (119899)))

119906119898 (119899 + 1) = 119865119888 (119865119901 (119906119901 (119899))) (1)

where 119906119898 and 119906119901 are the corresponding input values ofthe simulators for the power system energy market andcommunication network for each time step Therefore it isrequired to set initial values 119906119901(0) 119906119898(0) at the beginningof the cosimulation 119899 denominates the current cosimulationtime step 119865119888 (communication) 119865119898 (market) and 119865119901 (powersystem) are the functions describing the calculation of thenext time step

54 Cosimulation Runtime Interaction In Figure 6 the cou-pling of the power system communication and market sim-ulator for their cosimulation runtime interaction is shown Inthe following we briefly introduce the individual parts of thecosimulation environment

(i) Mosaik as already mentioned mosaik is used forthe coordination during the synchronization stepsof several minutes (in simulation time) regarding allsimulators [24] mosaik has two different APIs forsimulator coupling It provides handlers for differentsimulator types allows modelling of different simula-tion scenarios and schedules the step-wise executionof the connected simulators with the aid of SimPy[25] The two mosaik APIs are

(a) the low-level API which uses common TCPIPnetwork sockets for exchanging messages en-capsulated in JSON an open-source and hu-man-readable data format

(b) the high-level API which can be directly usedby a simulator and communicate with mosaikthrough sockets but also handle their creationevents and message (de)serialization

8 Complexity

TCP sockets

Communicationsimulation

DESenvironment

(R)UDP sockets

(R)UDP sockets

VILLAS-node

Python environmentMarket

simulation

TCP sockets TCP sockets TCP sockets

TCP sockets

TCP socketsmosaik-

core

Slow phenomenacommunication

MODD server

ModelicaDeviceDrivers

Power systemsimulation

Modelicaenvironment

Fast phenomena communication

(R)U

DP

sock

ets

Mod

elic

aD

evic

eDriv

ers

Figure 6 Scheme of runtime interaction between cosimulationcomponents

(ii) Market simulator implemented in Python it canmake use of the high-level API as illustrated inFigure 6Theuse of the sockets allows the desired flex-ibility of running all simulators on different computersystems and environments

(iii) Communication network simulator based on avail-able DES tools their network simulation modules areextendedwith interprocess communication function-alities for JSON message exchange with mosaik

(iv) Power system simulator the integration of so-called TCPIP SendRecv IO blocks from ModelicaDeviceDrivers into the Modelica models allows theexchange of simulation data via sockets but in theform of Modelica variables as bitvectors instead ofJSON messages Therefore the MODD Server isimplemented

(v) MODD server it receives commands from the socketconnected with mosaik Based on these commandsit starts for example the power system simulator orreceives the bitstream from Modelica DeviceDriversand encapsulates it into JSON messages before trans-ferring them to mosaik Besides the synchronizationsteps controlled by mosaik there will be also morefine-grained synchronization steps of fractions of sec-onds between the power system and communicationnetwork simulator That is why a VILLASnode serveris included

Root-coordinator

Topcoordinator

subcoordinator

simulator simulator

simulatorC

MP

Figure 7 Cosimulation environment as a hierarchical simulator

(vi) VILLASnode instead of TCP (Transmission ControlProtocol) it makes use of UDP (User DatagramProtocol) sockets for data exchange between real-time simulators for which it was designedThe use ofUDP leads to less overhead and consequently to lowersynchronization time steps but with the disadvantageof an unreliable connectionOur solution for avoidingany datagram losses is the usage of Reliable UDP(RUDP) to keep a low overhead in comparison withTCP with the benefit of a reliable connection

55 DEVS Formalization As explained in Section 53 adiscrete time base is chosen for the synchronization betweenthe domain-specific simulators Therefore the simulatorscan be formalized by Discrete Time System Specifications(DTSS) Since the time steps are fixed the DTSS can besimulated by DEVS [17] The abstraction level of the DEVShas not been considered for the mosaik framework fordifferent reasons [26] and is not needed for the definitionof cosimulation scenarios Therefore a formal definition ofthe whole simulation as coupled DEVS is beyond the scopeof this paper However a so-called hierarchical simulatorfor the three atomic simulators 119875 119872 and 119862 (for energymarket and communication) is shown in Figure 7 as leavesof the hierarchical simulator (ie tree) [17] and describedin the following The root-coordinator sends an initializationmessage (119894 119905) which is propagated to all atomic simulators inthe tree at simulation start and initiates the simulation stepswith state transition messages (lowast 119905) The coordinators handlethe levels of coupled simulators up to the root of the treeThe scheduling of an event is performed by a (lowast 119905) messageforwarded by each receiver coordinator to its imminent childThe imminent child is the simulator which shall perform itsnext internal transition or the coordinator being the root ofthe subtree containing the simulator which performs the nextinternal transition

Complexity 9

In case of our cosimulation architecture the first (lowast 119905)message is forwarded by the top and the subcoordinatorto the first component in the event-list (here 119875 simulator)computing the new output 119910119875 = 120582(119904) and sending it as outputmessage (119910119875 119905) to the subcoordinator The subcoordinatorthen recognizes an internal coupling and therefore sends anx-message (119909119872 119905) with 119909119872 = 119885119875119872(119910119875) to the 119872 simulatorwhereby 119885119875119872 119884119875 rarr 119883119872 is the translation function fromthe output events of the 119875 simulator to the input events of the119872 simulator Although the computations of the119872 simulatorwithin the same transition donot dependon the output of the119875 simulator its output message (119910119872 119905) includes the output ofboth simulators This output is translated and forwarded bythe subcoordinator to its parent (top coordinator) becauseof the external coupling as output message (119910119873 119905) of thebelonging Discrete Event Specified Network (DEVN) After-wards the top coordinator translates the message to an inputmessage (119909119862 119905) of the119862 simulator which computes the outputof the whole cosimulation step This output is transformedby the top coordinator because of its internal coupling toan input message for the subcoordinator which translatesand sends the message down to the 119875 simulator because ofthe external input coupling and the next cosimulation stepbegins

An improvement of this formalization based on thehierarchical simulator could be accomplished by a formal-ization of the 119875 and 119872 simulator as a conservative paralleldiscrete event simulation [17] Nevertheless the describedcommunication pattern between the components of thehierarchical simulator shows that the chosen cosimulationsynchronization scheme depicted in Figure 5 is validwhen causality violations between the energy and marketsimulation within one time step of the cosimulation areavoided which is guaranteed for the considered simulationscenarios

56 Limitations Due to the communication overhead causedby the cosimulation environment the simulation time mightincrease significantly for large network sizes Currently real-time simulations are not possible but the available frameworkcan be extended for real-time and hardware-in-the-loopsimulations for example by using VILLASnode instead ofmosaik

Furthermore the synchronization step size cannot bechanged during simulation runtime whereas the domain-specific simulators support variable simulation time stepsTo enable a variable step size for an optimized cosimulationthrough more sophisticated algorithms modifications of themosaik framework would be necessary as it allows fixed timesteps onlyThe cosimulation flowmanaged by mosaik whichallows parallel and sequential progress of simulators mightintroduce inaccuracies in the simulation results with respectto the synchronization step size

Moreover the simulation of heterogeneous communi-cation networks and standards is possible However theabstraction level of the communication protocols influ-ences the simulation time of the communication networksimulator and thus the simulation time of the cosimu-lation

6 Verification of the Cosimulation Interfaces

In this section we aim to show that the implementedcosimulation infrastructure does not impair the accuracyof the simulation results As an exemplary application weconsider a scenario where a VPP operator aims at gainingprofits by reducing the VPPrsquos peak power Thus a peak-shaving algorithm is employed for an optimal managementof distributed battery storage systems Financial incentives forthe peak-shaving behavior might originate from agreementswithDSOs regarding themaximumpower feed-in of theVPPStarting from results without the cosimulation frameworkwe successively include the cosimulation environment anddomain-specific simulators to demonstrate that the results donot change under the assumption of an ideal communicationnetwork in the same scenario Eventually a slightly differentscenario is presented where the communication network issupposed to impair the control loop between the powersystem and themarket due to communication device failuresthereby showing an exemplary use case for the cosimulationarchitecture presented in this paper

61 Simulation Scenarios andModels The investigated powersystem is a part of the IEEE European Low Voltage TestFeeder The loads in the test feeder are replaced with build-ings each incorporating a PQ-load Furthermore severalof these buildings feature stationary batteries and solargeneration The battery storages are controlled by a peak-shaving algorithm which is implemented in the market sim-ulator The peak-shaving algorithm is supposed to representa VPP operator that utilizes its aggregated storage in a gridsupporting way That is why in a real world application itneeds to exchange measurement and control values with thebattery storages through the communication network

In the first simulation scenario the communicationbetween batteries and the peak-shaving algorithm is idealand not subject to any communication network failures Thisscenario is used to verify the correct exchange of simulationdata between the simulators involved in the cosimulationFor this reason the simulation is first executed withoutcosimulation framework connecting the peak-shaving algo-rithm directly to the power system simulation Then thecosimulation environment is introduced and afterwards thecommunication network simulatorThe results of these threesimulation cases are presented in Section 62

The second simulation scenario analyzed in Section 63features a communication network failure in order to show apossible use case of the complete cosimulation environment

The following equations are implemented in Modelicato simulate the power system components in the buildingsThe PQ-loads in the buildings are modelled as ideal constantpower loads which means that the load current is directlydependent on the voltage at the grid connection point

The implemented Modelica model of the solar generatordetermines the active power output 119875sg by

119875sg3 = 119881oc sdot 119868sc sdot 119865119865 sdot

119875sginst1198750

(2)

10 Complexity

under the assumption that the plant is operating at itsmaximum power point and where 119881oc and 119868sc are the open-circuit voltage and the short-circuit current respectivelyThey vary with temperature and solar radiation which can bemodelled according to [27] The term 119875sginst1198750 in (3) adaptsthe magnitude of the output power to the installed power ofa specific solar generating unit given that 1198750 represents theinstalled power of the solar panel used in [27]

The model of the battery storages consists of a simple setof equations describing the derivative of the state of charge(SOC) as

119889119889119905SOC =

120578ch119875119861119862119861

119875119861 ge 0

119875119861120578disch119862119861

119875119861 lt 0(3)

In addition the battery model limits the SOC to be in therange between zero and oneThe values specifying the batterycapacity 119862119861 the charging efficiency 120578ch and the dischargingefficiency 120578disch are extracted from the extended CIM classessee Section 51

The VPP algorithm aims at stabilizing the voltage profileby reducing the power exchange between the grid andthe buildings using a model predictive control approachTherefore the battery charging power 119875119861 is set according toan optimal scheduling which is based on forecasts for solarradiation and load demand To compensate for inaccuraciesin the forecasts the algorithm receives measurements ofactual load demand generated solar power and battery stateof charge from the power system simulator

62 Comparison of Results with and without CosimulationEnvironment At first both measurements and set pointsare neither passed through the communication networksimulator nor the cosimulation framework Instead thecontrol signals for the battery storages are directly suppliedby the peak-shaving algorithm before each power systemsimulation step Following this reference case both simula-tors are connected through the cosimulation environment asdescribed in Section 54 Still the communication networksimulator is not involved The results depicted in Figure 8present the voltage profile over time at one node in thetest feeder and it can be seen that the results with andwithout the cosimulation environment are consistent If thecommunication network had altered the exchanged datacontrol values and measurements the voltage profile wouldhave changed Next we take this one step further andalso introduce the communication network simulator Thecommunication network simulator acts as mediator betweenthe power system and market simulators Any data that isexchanged between the power system and market has to passthrough the former The communication network simulatoris added to the cosimulation as presented in Sections 53and 54 To verify that the three simulators are synchronizedproperly we include an ideal communication network that isall messages are transmitted without any latencies Evidentlyan ideal communication should not affect the informationexchange between power system and market so that the

1003

1002

1001

1000

0999

0998

0997

Volta

ge (p

u)

Time (h)

Direct couplingmosaik coupling

24211815129630

Figure 8 Comparison of simulation results of power system andmarket with and reference case without cosimulation environment

No comm simulatorWith comm simulator

3 6 9 12 15 18 21 240

Time (h)

0997

0998

1000

1001

1002

1003Vo

ltage

(pu

)

0999

Figure 9 Comparison of simulation results with cosimulationenvironment and ideal communication network and reference casewithout cosimulation environment

implemented scheduling for battery charging should performequally

In Figure 9 it is visible that the simulation results incor-porating the ideal communication network do not deviatefrom the ones obtained without the communication networkeven though all messages are now passing through thecommunication network simulatorThus the results confirma correct synchronization of the three simulators and theconsistency of the implemented cosimulation environment

63 Exemplary Cosimulation with Communication NetworkFailure In this subsection the three simulators are exchang-ing data in the sameway as described at the end of Section 62Only this time the communication network simulator emu-lates a fault in the communication network which leadsto a communication failure of one hour at the site of the

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

Complexity 3

represent the market Therefore this approach hinders theuse of existing domain-specific tools and requires substantialdevelopment effort Instead in this work we aim to takeadvantage of the capabilities that existing tools offer which (i)enhances the credibility of the results and (ii) decreases theeffort that is needed to replicate their functionalities

The proposed simulation framework consists of severalsimulators each responsible for a specific domain Theadvantage is the possibility of using the best tool for eachdomain Besides the vision is to be able to replace simulatorswith reasonable effort if the simulation requirements changeFor example in Section 6 it is mentioned how [11] could beused to implement amore comprehensivemarket simulation

23 Classification of Simulations Schloegl et al [12] providesa clear classification scheme for energy-related cosimulationsBecause our cosimulation environment shall provide holisticsimulations all four categories of simulation elements ormodels (ie continuous processes discrete processes andevents roles and statistical elements) defined by Schloegl etal have to be considered

In our implementation the power system is modelledin Modelica as it can be used for physical systems in gen-eral [3] and has already proven its capabilities for thermalsystems [13] and power systems in particular [14] Modelicamodels consist of continuous processes discrete processesand events which makes the power system simulation ahybrid simulationThe communication network is simulatedwith the available discrete event simulation (DES) tools suchas ns-3 In a DES the simulation time proceeds with theexecution of single events such as packet arrival and timeexpiry [15] The energy market simulation is implemented inPython asDES Pythonwas chosen as programming languagebecause of its suitability to implement and test differentoptimization methods [16] Each market participant aims atoptimizing the schedule for its assets for example minimiz-ing energy costs and maximizing its profit Depending onthe simulation scenario the behavior or role of the marketparticipants changes Examples for statistical elements arewind farm models of the energy grid simulator and commu-nication link models which consider packet losses and thereliability metrics of the communication network simulator

Furthermore the proposed cosimulation environmentcan be formalized as a coupled Discrete Event System Specifi-cation (DEVS) as defined in [17] which is why a classificationof our architecture in terms of DEVS is given in Section 55

3 Use Cases of the Cosimulation Environment

Our cosimulation solution including the three domains canbe used to evaluate different scenarios To address the physi-cally relevant dependencies we divide the dynamic interac-tions between the simulators into two groups

(i) Fast phenomena in the range of microseconds toseconds between highly dynamic power system com-ponents for example power electronics and commu-nication network

(ii) Slow phenomena in the range of minutes to hourswhich include market entities power system andcommunication network

In recent literature the most prominent fast dynamicinteractions occur in wide area measurement and controlapplications as well as remote power electronics devices[10] Compared to slow phenomena the simulation of fastphenomena requires relatively smaller simulation time stepsdue to switching events of electronic components and the factthat the market interactions are not consideredTherefore ina cosimulation of the fast phenomena the focus should bemore on the efficiency of the cosimulation interface ratherthan a simplification of the coupling with multiple simula-tors The proposed cosimulation environment is intended tosupport the investigation of fast dynamics but should not belimited to them This has an influence on our design of thecommunication interface between the simulators as can beseen in Section 54

On the other hand slow phenomena are created byclosing the loop between the power system and marketby means of the communication network The behavior ofmarket entities may cause changes in the usage of powersystem components which has an impact on the grid and viceversa and this loopmight be impaired by the communicationnetworkThe cosimulation environmentmight be used eitherto verify the functioning of the control loop given a specificcommunication network or to plan a communication net-work that fulfills the requirements of the control mechanismsin power system and market

Based on this classification of use cases it can be con-cluded that all three simulators do not necessarily have to beactive at the same time for all scenarios In this paper we willfocus on the requirements and the implementation for thecosimulation of slow phenomena and confine our discussionon fast phenomena to a description of the adaptions neededfor fast phenomena investigations since there already existseveral cosimulation environments proposed for these stud-ies [1]

An example use case for slow phenomena is the optimalmanagement of distributed storage systems for peak-shavingto support the grid operation The proposed cosimulationenvironment including the communication network allowstesting the effects of communication failures on the operationstrategy and eventually on the electrical grid which canprovide valuable insights for decision-making Simulationresults for this example are provided in Section 6

Before the cosimulation is initiated it is necessary todefine and store the topology under investigation along withthe scenario-specific parameters For example the scenarioscan be investigated in which the failures in the commu-nication network are stochastically or deterministically setby the user in the data model From a user perspective itwould be advantageous if all components their links andparameters could be defined in one environment ratherthan splitting this information between different softwaresolutions and formats Then the data model for the topol-ogy needs to include components that couple differentdomains

4 Complexity

From these use cases the following challenges can beidentified

(i) Common data model that includes components of alldomains and their interconnections

(ii) Interaction of simulators with different simulationtypes for example event-driven for the communica-tion network and continuous processes for the powersystem

(iii) Choice of the cosimulation time step which is limitedby the synchronization method connecting the simu-lators

4 Challenges of the Cosimulation

41 CommonDataModel A common datamodel that coversthe electrical market communication infrastructure andgrid does not exist to the best of our knowledge eventhough these components are integral part of smart gridsNot only would the user of a simulation software benefitfrom a common data model during the specification ofthe simulation scenario but the data exchange would alsobe simplified A system description that encompasses allcomponents of smart grids as shown in Figure 1(a) couldbe either used directly by holistic smart grid simulators ordivided into subsystems for a cosimulation as in Figure 1(b)

For many components this division is straightforwardsince their parameters are only needed by one domain-specific simulator For example electrical lines exist only inthe power system domain and have connections only to otherpower system components Some components on the otherhand constitute natural coupling points between the powersystem the market and the communication network Thesecomponents are called interdomain components in the follow-ing For instance a battery storage device connected to thegrid can act as a market participant that offers its capabilityto charge or discharge In order to enable its participationin the energy market the battery storage needs an interfacewhich is a communication modem in this case The modemcan be seen as a part of the battery storage Therefore thedata model class associated with the battery storage devicehas to be able to hold or reference to data on the properties ofthe battery storage in electrical market and communicationdomains For a cosimulation the information on interdomaincomponents have to be split into several parts since theirparameters are needed by the simulators and each simulatorhas to simulate a dedicated part of these components

42 Cosimulation Time and Synchronization A remainingand major issue in such a cosimulation in which simulatorsof different categories are combined is the selection andimplementation of a proper synchronization mechanismwhich must ensure the proper progress of the simulationtime and a timely data exchange between the domain-specificsimulators This selection is of crucial significance in orderto minimize the error propagation in the cosimulation andthe synchronization overhead in terms of simulation timeIn [1] three main synchronization methods for cosimulation

have been specified time-stepped global event-driven andmaster-slave There are two different considerations relatedto the simulation time [12]

(i) Time resolution a challenge of the cosimulationis the highly diverse time resolutions of the threesimulators The time steps of power grid simulatorreach from milliseconds (electromagnetic processes)to subseconds and above (steady-state and electrome-chanic processes) The time steps of communicationnetwork simulations can even vary from tens ofmicroseconds (eg latencies in LANs) to seconds(eg latencies in WANs) On the other hand inenergy market simulations a time step of severalminutes can be sufficient as it is the case forGermanyrsquoscontrol power market with price calculations on 15-minute basis

(ii) Time ratio time ratio describes the relation betweensimulation time and wall clock time [12]With appro-priate use cases we want to show how holistic cosim-ulations with our approach can be used for planningand decision-making Therefore it is important torun the scenarios much faster than wall clock timeand for time intervals of days as well as of weeks sothatmanymodelswith different configurations can besimulated

The problem is that a very small time step or a high resolutionin time impedes short simulation times Therefore it isnecessary to adjust the time step according to the phenomenathat are under investigation At the same time it may befeasible to aim at a higher integration of the simulators andsacrifice flexibility and increase the efficiency if both timeresolution and time ratio need to be optimized In Section 53we discuss our design choices regarding the synchronizationof the simulators in detail The approach for an optimizationof time resolution and time ratio is further discussed in theSection 54

5 Concept of the Cosimulation Environment

51 Data Model for Power System Communication Networkand Market As explained in Section 2 one possibility isto extend the cosimulation topology format on CIM whichleads to a superset of CIM New classes which are introducedfor completing CIM in its representation of smart grids arelinked to theCIMclasses using the terminology of theUnifiedModeling Language (UML) The proposed format can bestructured in four packages

(i) Original CIM (IEC61970 IEC61968 IEC62325)(ii) Communication(iii) Market(iv) EnergyGrid

Whenever possible the CIM classes are used Howeversome components might not have an associated class in thestandard yet Then these components are represented asclasses in one of the other three packages The reason for

Complexity 5

Wholesale andretail market

Marketparticipants

(a)

Power system Communicationnetwork

Wholesaleand retail

Market

market

participantsMarket

(b)

Figure 1 Exemplary topology including components of all domains (a) and domain-specific topologies (b)

this approach is that this way it is easier to update to a newversion of CIM without losing the newly added classes andtheir interconnections

The most important feature of our model formatis the interconnection of domains In order to accom-plish this we have identified possible interdomain com-ponents Some examples of interdomain componentsnamely BatteryStorage SolarGeneratingUnit andMarketCogeneration are shown in Figure 2 which isan excerpt from our data model According to the UMLdiagram the energy market components are associatedwith the power system components whereas power systemcomponents have an aggregation relationship to com-munication devices This means that parameters specificto the market communication network and power systemwhich relate to the same device are linked with each otherTherefore all information on one device is easily accessiblebut at the same time there is a separation according tothe domains The connections between classes of differentdomains are defined in a logical and not a topological wayInstead topological connections exist to connect powersystem components for instance

Coming back to the battery storage device example thedatamodel is as follows the device is a part of the grid and haselectrical parameters Furthermore the battery storagemightparticipate in the market for example as part of a virtualpower plant (VPP) Market-specific information can bestored in the MarketBatteryStorage class which is associ-atedwith the electrical representationBatteryStorageThedata on the class for a communicationmodem ComModwhichcould be used to communicate with the VPP is aggregated tothe BatteryStorage class

In the following we briefly mention the domain-specificconsiderations for the three domains

(1) Power System Package The purpose of the EnergyGridpackage is to group models for power system componentsthat are not already part of the CIM standard For the simula-tion scenario that is presented later it was necessary to create

a new model for electrical energy storages like stationarybatteries A battery storage is a conducting equipment thatis able to regulate its energy throughput in both directionsTherefore the class BatteryStorage is a specialization ofa CIM RegulatingConductingEquipment since it caninfluence the flow of power at a specific point in the network

(2) Market Package The key component of the marketpackage for the scenarios that we would like to investigateis a VPP since the aggregation of small DER units enablestheir participation at electricity markets In case the DERsare not owned by the operator of the VPP they can be seenas customers that offer their energy in exchange for share ofthe VPP operators profits Besides a VPP might support theDistribution System Operator (DSO) in ensuring a safe gridoperation which results in an association between the DSOand the VPP

(3) Communication Package This package includes all addi-tionally defined classes that are related to the communicationnetwork model such as classes for communication linksand technologies modems network nodes along with theirparameters and their relations with the classes in CIMpower system package and market package In this waythe user can model the communication network layer andits specifications in the simulation tool The communicationnetwork topology and its parameters are then used by thecommunication network simulator for the cosimulation

Figure 3 shows an excerpt from the communication datamodel with an aggregation to a WindGeneratingUnit Bymeans of the associated classes for modems communicationrequirements and channels the model enables a descriptionof network parameters and topology Furthermore the com-munication network data model integrates the flexibility toenable the planning of the communication network undercommunication and power system requirements even beforethe beginning of the cosimulation The topological parame-ters will be used for an optimal design of the communica-tion network with the desired objective such as minimum

6 Complexity

Market

MarketBatteryStorage

Power System

EnergyStorageBatteryStorage

Communication

MarketSolarGeneratingUnit

GeneratingUnitProduction

SolarGeneratingUnit

EquipmentMarketCogenerationUnit

ProductionCogenerationPlant

ModemsComMod

PowerSystemResourceRegulatingCondEq

EquipmentEquipment

Figure 2 Interdomain connections between classes of power sys-tem communication network and market

GeneratingUnitWindGeneratingUnit

ComMod

WirelessMod

LTEModem

01

communicationRequirement

WiredMod

FiberModemWiredInterface

FiberInt

WiredChannelFiberChannel

11

1

0lowast

1lowast

1

Figure 3 Communication network class association example

cost while required conditions are satisfied such as givenreliability metric An example of this approach is presentedin [18] for an integrated design of a wide area measurementsystem Eventually the optimized communication networksolution can be evaluated against different scenarios using thecosimulation environment

52 Model Data Processing and Simulation Setup The overallinformation flow for the simulation setup is depicted inFigure 4 After the topology is created or modified in agraphical Topology Builder and includes the three domainsthe input file which complies with the common data modelof Section 51 is sent to the cosimulation interface Thecosimulation interface incorporates a component basedon CIM++ [19] which parses the CIM XML-RDF fileand generates a container of C++ objects that containthe topological data In order to execute a simulationthe Modelica solver requires a Modelica model whereas

Modelica models

Power systemsimulation

Modelica (DymolaOpenModelica)

Topology builder

Extended CIM

Cosimulation interfacemosaik CIM++

Objects2ModelicaObjects2Comm Net

Block diagram oftopology

XML representationof topology

C++ objects amp simulatorspecific text formats

Communication networkPython objects topology

CommunicationMarket simulation simulationpython ns-3 etc

Figure 4 Overall architecture for simulation setup

the communication network topology can be given to thecommunication network simulator in JSON or XML for-mat which includes the components in the network theirconnections and parameters Since the topology will beavailable as an XML-RDF file and a container of C++objects the relevant information for the power system andcommunication network is extracted during a deserializationstep In the subsequent transformation step a componentwhich we call Objects2ModelicaCommunicationNetworkgenerates Modelica and communication network files withthe topology and parameters In contrast the Python basedmarket simulation relies on a C++Python interface whichcould be realized using one of the common libraries forPython to wrap C++ data types and functions to retrieve themarket relevant information from the C++ objects and storethem in Python objects

The following paragraph explains the translation on thebasis of a CIM to Modelica example The loads are definedin the extended CIM data model described in Section 51 asPQ-loads with a characteristic power demand as follows

ltcimSvPowerFlow rdfID=PQ1-svgtltcimSvPowerFlowpgt1000ltcimSvPowerFlowpgtltcimSvPowerFlowqgt329ltcimSvPowerFlowqgtltcimSvPowerFlowTerminal

rdfresource=E-1229789360gtltcimSvPowerFlowgt

The cosimulation interface extracts the corresponding com-ponent parameters from the CIM XML-RDF file and intro-duces them in the Modelica model of the grid The latteris done by the Objects2Modelica component explained inSection 52 which iterates through the list of C++ objects pro-vided by CIM++ Thus the specification of the parameters 119875and119876 in the CIMmodel generates two attributemodificationequations in the declaration of the PQ-load in Modelica

Complexity 7

ModPowerSystemsPhasorSinglePhaseLoads

PQLoad CIM PQ1 (Pnom = 1000 Qnom = 329)

These values are applied during the quasistationary simula-tion of the single-phase representation of the grid

53 Synchronization The synchronization of all three sim-ulators will be performed in fixed time steps Fixed syn-chronization time steps have been chosen because of theresulting flexibility to integrate more simulators easily and itscomparatively high speed in terms of time steps per simula-tion time [1] An event-driven approach as it is implementedin [10] for two simulators requires a deeper integration ofthe cosimulation framework and the simulators Apart fromthat it was shown in [10] that the cosimulation error can bereduced for fixed time steps by reducing the global time stepsize

The synchronization between all simulators for slowphenomena scenarios is performed with mosaik a well-established cosimulation framework [20] which was devel-oped for stationary simulations with time steps of one secondor greater [21] It allows combining the three simulators in asimple manner as explained in Section 54 VILLASnode asoftware project for coupling real-time simulations in LANs[22 23] is a suitable alternative for mosaik in the case ofsynchronizations with very short intervals

In Modelica the synchronization data exchange isachieved by integrating Modelica blocks of the ModelicaDeviceDrivers library which was originally developed forinterfacing device drivers to Modelica models This con-veniently allows the definition of a fixed interval for dataexchange Modelica DeviceDrivers were chosen instead ofthe FMI approach shown in [21] because it allows moreflexibility in picking the desired simulation variables andchoosing the required cosimulation step size independentlyfrom the Modelica simulator time step At synchronizationsteps between all simulators the step function of the energymarket simulator is called synchronously from the mosaikPython API After the market simulator has finished thesimulation step the results are retrieved by mosaik

The simulation time in the DES of the communicationnetwork advances with the execution of the generated eventswhich are stored in an event-list The execution of eventsis controlled by a scheduler which determines the nextevent and its execution time Whereas the default schedulerexecutes the events sequentially without any interruptionsthe available simulation environments offer the flexibility tointegrate external control inputs to receive external controlmessages which can be used to manipulate the simulationflow by changing the module parameters during the simula-tion In order to realize this the event-driven nature of DEStools can be used to generate new events called flow controlevents which stop the communication simulation exchangedata and use the input data to manipulate the followingsimulation steps Furthermore the execution of events canbe controlled and the simulation can be stopped after theexecution of the last event before a synchronization point sothat the simulation runs in fixed steps and a data exchange ispossible at the end of each step

Powersystem

Commnetwork

MarketEvent 0

Event 1

Powersystem

Commnetwork

MarketEvent 2

Event 3

Powersystem

Market

Individualsimulator steps

Cosimulation step

0

0

0

0

1

1 2

1 1

1

2

2

211

Figure 5 Synchronization scheme of simulators at cosimulationtime steps

Figure 5 depicts the flow of time for the cosimulationand each simulator It can be seen that the power system andmarket simulators compute in parallel whereas the commu-nicationnetwork iswaiting for their inputs In amathematicalnotation the interactions between the simulators in eachcosimulation step can be defined by

119906119901 (119899 + 1) = 119865119888 (119865119898 (119906119898 (119899)))

119906119898 (119899 + 1) = 119865119888 (119865119901 (119906119901 (119899))) (1)

where 119906119898 and 119906119901 are the corresponding input values ofthe simulators for the power system energy market andcommunication network for each time step Therefore it isrequired to set initial values 119906119901(0) 119906119898(0) at the beginningof the cosimulation 119899 denominates the current cosimulationtime step 119865119888 (communication) 119865119898 (market) and 119865119901 (powersystem) are the functions describing the calculation of thenext time step

54 Cosimulation Runtime Interaction In Figure 6 the cou-pling of the power system communication and market sim-ulator for their cosimulation runtime interaction is shown Inthe following we briefly introduce the individual parts of thecosimulation environment

(i) Mosaik as already mentioned mosaik is used forthe coordination during the synchronization stepsof several minutes (in simulation time) regarding allsimulators [24] mosaik has two different APIs forsimulator coupling It provides handlers for differentsimulator types allows modelling of different simula-tion scenarios and schedules the step-wise executionof the connected simulators with the aid of SimPy[25] The two mosaik APIs are

(a) the low-level API which uses common TCPIPnetwork sockets for exchanging messages en-capsulated in JSON an open-source and hu-man-readable data format

(b) the high-level API which can be directly usedby a simulator and communicate with mosaikthrough sockets but also handle their creationevents and message (de)serialization

8 Complexity

TCP sockets

Communicationsimulation

DESenvironment

(R)UDP sockets

(R)UDP sockets

VILLAS-node

Python environmentMarket

simulation

TCP sockets TCP sockets TCP sockets

TCP sockets

TCP socketsmosaik-

core

Slow phenomenacommunication

MODD server

ModelicaDeviceDrivers

Power systemsimulation

Modelicaenvironment

Fast phenomena communication

(R)U

DP

sock

ets

Mod

elic

aD

evic

eDriv

ers

Figure 6 Scheme of runtime interaction between cosimulationcomponents

(ii) Market simulator implemented in Python it canmake use of the high-level API as illustrated inFigure 6Theuse of the sockets allows the desired flex-ibility of running all simulators on different computersystems and environments

(iii) Communication network simulator based on avail-able DES tools their network simulation modules areextendedwith interprocess communication function-alities for JSON message exchange with mosaik

(iv) Power system simulator the integration of so-called TCPIP SendRecv IO blocks from ModelicaDeviceDrivers into the Modelica models allows theexchange of simulation data via sockets but in theform of Modelica variables as bitvectors instead ofJSON messages Therefore the MODD Server isimplemented

(v) MODD server it receives commands from the socketconnected with mosaik Based on these commandsit starts for example the power system simulator orreceives the bitstream from Modelica DeviceDriversand encapsulates it into JSON messages before trans-ferring them to mosaik Besides the synchronizationsteps controlled by mosaik there will be also morefine-grained synchronization steps of fractions of sec-onds between the power system and communicationnetwork simulator That is why a VILLASnode serveris included

Root-coordinator

Topcoordinator

subcoordinator

simulator simulator

simulatorC

MP

Figure 7 Cosimulation environment as a hierarchical simulator

(vi) VILLASnode instead of TCP (Transmission ControlProtocol) it makes use of UDP (User DatagramProtocol) sockets for data exchange between real-time simulators for which it was designedThe use ofUDP leads to less overhead and consequently to lowersynchronization time steps but with the disadvantageof an unreliable connectionOur solution for avoidingany datagram losses is the usage of Reliable UDP(RUDP) to keep a low overhead in comparison withTCP with the benefit of a reliable connection

55 DEVS Formalization As explained in Section 53 adiscrete time base is chosen for the synchronization betweenthe domain-specific simulators Therefore the simulatorscan be formalized by Discrete Time System Specifications(DTSS) Since the time steps are fixed the DTSS can besimulated by DEVS [17] The abstraction level of the DEVShas not been considered for the mosaik framework fordifferent reasons [26] and is not needed for the definitionof cosimulation scenarios Therefore a formal definition ofthe whole simulation as coupled DEVS is beyond the scopeof this paper However a so-called hierarchical simulatorfor the three atomic simulators 119875 119872 and 119862 (for energymarket and communication) is shown in Figure 7 as leavesof the hierarchical simulator (ie tree) [17] and describedin the following The root-coordinator sends an initializationmessage (119894 119905) which is propagated to all atomic simulators inthe tree at simulation start and initiates the simulation stepswith state transition messages (lowast 119905) The coordinators handlethe levels of coupled simulators up to the root of the treeThe scheduling of an event is performed by a (lowast 119905) messageforwarded by each receiver coordinator to its imminent childThe imminent child is the simulator which shall perform itsnext internal transition or the coordinator being the root ofthe subtree containing the simulator which performs the nextinternal transition

Complexity 9

In case of our cosimulation architecture the first (lowast 119905)message is forwarded by the top and the subcoordinatorto the first component in the event-list (here 119875 simulator)computing the new output 119910119875 = 120582(119904) and sending it as outputmessage (119910119875 119905) to the subcoordinator The subcoordinatorthen recognizes an internal coupling and therefore sends anx-message (119909119872 119905) with 119909119872 = 119885119875119872(119910119875) to the 119872 simulatorwhereby 119885119875119872 119884119875 rarr 119883119872 is the translation function fromthe output events of the 119875 simulator to the input events of the119872 simulator Although the computations of the119872 simulatorwithin the same transition donot dependon the output of the119875 simulator its output message (119910119872 119905) includes the output ofboth simulators This output is translated and forwarded bythe subcoordinator to its parent (top coordinator) becauseof the external coupling as output message (119910119873 119905) of thebelonging Discrete Event Specified Network (DEVN) After-wards the top coordinator translates the message to an inputmessage (119909119862 119905) of the119862 simulator which computes the outputof the whole cosimulation step This output is transformedby the top coordinator because of its internal coupling toan input message for the subcoordinator which translatesand sends the message down to the 119875 simulator because ofthe external input coupling and the next cosimulation stepbegins

An improvement of this formalization based on thehierarchical simulator could be accomplished by a formal-ization of the 119875 and 119872 simulator as a conservative paralleldiscrete event simulation [17] Nevertheless the describedcommunication pattern between the components of thehierarchical simulator shows that the chosen cosimulationsynchronization scheme depicted in Figure 5 is validwhen causality violations between the energy and marketsimulation within one time step of the cosimulation areavoided which is guaranteed for the considered simulationscenarios

56 Limitations Due to the communication overhead causedby the cosimulation environment the simulation time mightincrease significantly for large network sizes Currently real-time simulations are not possible but the available frameworkcan be extended for real-time and hardware-in-the-loopsimulations for example by using VILLASnode instead ofmosaik

Furthermore the synchronization step size cannot bechanged during simulation runtime whereas the domain-specific simulators support variable simulation time stepsTo enable a variable step size for an optimized cosimulationthrough more sophisticated algorithms modifications of themosaik framework would be necessary as it allows fixed timesteps onlyThe cosimulation flowmanaged by mosaik whichallows parallel and sequential progress of simulators mightintroduce inaccuracies in the simulation results with respectto the synchronization step size

Moreover the simulation of heterogeneous communi-cation networks and standards is possible However theabstraction level of the communication protocols influ-ences the simulation time of the communication networksimulator and thus the simulation time of the cosimu-lation

6 Verification of the Cosimulation Interfaces

In this section we aim to show that the implementedcosimulation infrastructure does not impair the accuracyof the simulation results As an exemplary application weconsider a scenario where a VPP operator aims at gainingprofits by reducing the VPPrsquos peak power Thus a peak-shaving algorithm is employed for an optimal managementof distributed battery storage systems Financial incentives forthe peak-shaving behavior might originate from agreementswithDSOs regarding themaximumpower feed-in of theVPPStarting from results without the cosimulation frameworkwe successively include the cosimulation environment anddomain-specific simulators to demonstrate that the results donot change under the assumption of an ideal communicationnetwork in the same scenario Eventually a slightly differentscenario is presented where the communication network issupposed to impair the control loop between the powersystem and themarket due to communication device failuresthereby showing an exemplary use case for the cosimulationarchitecture presented in this paper

61 Simulation Scenarios andModels The investigated powersystem is a part of the IEEE European Low Voltage TestFeeder The loads in the test feeder are replaced with build-ings each incorporating a PQ-load Furthermore severalof these buildings feature stationary batteries and solargeneration The battery storages are controlled by a peak-shaving algorithm which is implemented in the market sim-ulator The peak-shaving algorithm is supposed to representa VPP operator that utilizes its aggregated storage in a gridsupporting way That is why in a real world application itneeds to exchange measurement and control values with thebattery storages through the communication network

In the first simulation scenario the communicationbetween batteries and the peak-shaving algorithm is idealand not subject to any communication network failures Thisscenario is used to verify the correct exchange of simulationdata between the simulators involved in the cosimulationFor this reason the simulation is first executed withoutcosimulation framework connecting the peak-shaving algo-rithm directly to the power system simulation Then thecosimulation environment is introduced and afterwards thecommunication network simulatorThe results of these threesimulation cases are presented in Section 62

The second simulation scenario analyzed in Section 63features a communication network failure in order to show apossible use case of the complete cosimulation environment

The following equations are implemented in Modelicato simulate the power system components in the buildingsThe PQ-loads in the buildings are modelled as ideal constantpower loads which means that the load current is directlydependent on the voltage at the grid connection point

The implemented Modelica model of the solar generatordetermines the active power output 119875sg by

119875sg3 = 119881oc sdot 119868sc sdot 119865119865 sdot

119875sginst1198750

(2)

10 Complexity

under the assumption that the plant is operating at itsmaximum power point and where 119881oc and 119868sc are the open-circuit voltage and the short-circuit current respectivelyThey vary with temperature and solar radiation which can bemodelled according to [27] The term 119875sginst1198750 in (3) adaptsthe magnitude of the output power to the installed power ofa specific solar generating unit given that 1198750 represents theinstalled power of the solar panel used in [27]

The model of the battery storages consists of a simple setof equations describing the derivative of the state of charge(SOC) as

119889119889119905SOC =

120578ch119875119861119862119861

119875119861 ge 0

119875119861120578disch119862119861

119875119861 lt 0(3)

In addition the battery model limits the SOC to be in therange between zero and oneThe values specifying the batterycapacity 119862119861 the charging efficiency 120578ch and the dischargingefficiency 120578disch are extracted from the extended CIM classessee Section 51

The VPP algorithm aims at stabilizing the voltage profileby reducing the power exchange between the grid andthe buildings using a model predictive control approachTherefore the battery charging power 119875119861 is set according toan optimal scheduling which is based on forecasts for solarradiation and load demand To compensate for inaccuraciesin the forecasts the algorithm receives measurements ofactual load demand generated solar power and battery stateof charge from the power system simulator

62 Comparison of Results with and without CosimulationEnvironment At first both measurements and set pointsare neither passed through the communication networksimulator nor the cosimulation framework Instead thecontrol signals for the battery storages are directly suppliedby the peak-shaving algorithm before each power systemsimulation step Following this reference case both simula-tors are connected through the cosimulation environment asdescribed in Section 54 Still the communication networksimulator is not involved The results depicted in Figure 8present the voltage profile over time at one node in thetest feeder and it can be seen that the results with andwithout the cosimulation environment are consistent If thecommunication network had altered the exchanged datacontrol values and measurements the voltage profile wouldhave changed Next we take this one step further andalso introduce the communication network simulator Thecommunication network simulator acts as mediator betweenthe power system and market simulators Any data that isexchanged between the power system and market has to passthrough the former The communication network simulatoris added to the cosimulation as presented in Sections 53and 54 To verify that the three simulators are synchronizedproperly we include an ideal communication network that isall messages are transmitted without any latencies Evidentlyan ideal communication should not affect the informationexchange between power system and market so that the

1003

1002

1001

1000

0999

0998

0997

Volta

ge (p

u)

Time (h)

Direct couplingmosaik coupling

24211815129630

Figure 8 Comparison of simulation results of power system andmarket with and reference case without cosimulation environment

No comm simulatorWith comm simulator

3 6 9 12 15 18 21 240

Time (h)

0997

0998

1000

1001

1002

1003Vo

ltage

(pu

)

0999

Figure 9 Comparison of simulation results with cosimulationenvironment and ideal communication network and reference casewithout cosimulation environment

implemented scheduling for battery charging should performequally

In Figure 9 it is visible that the simulation results incor-porating the ideal communication network do not deviatefrom the ones obtained without the communication networkeven though all messages are now passing through thecommunication network simulatorThus the results confirma correct synchronization of the three simulators and theconsistency of the implemented cosimulation environment

63 Exemplary Cosimulation with Communication NetworkFailure In this subsection the three simulators are exchang-ing data in the sameway as described at the end of Section 62Only this time the communication network simulator emu-lates a fault in the communication network which leadsto a communication failure of one hour at the site of the

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

4 Complexity

From these use cases the following challenges can beidentified

(i) Common data model that includes components of alldomains and their interconnections

(ii) Interaction of simulators with different simulationtypes for example event-driven for the communica-tion network and continuous processes for the powersystem

(iii) Choice of the cosimulation time step which is limitedby the synchronization method connecting the simu-lators

4 Challenges of the Cosimulation

41 CommonDataModel A common datamodel that coversthe electrical market communication infrastructure andgrid does not exist to the best of our knowledge eventhough these components are integral part of smart gridsNot only would the user of a simulation software benefitfrom a common data model during the specification ofthe simulation scenario but the data exchange would alsobe simplified A system description that encompasses allcomponents of smart grids as shown in Figure 1(a) couldbe either used directly by holistic smart grid simulators ordivided into subsystems for a cosimulation as in Figure 1(b)

For many components this division is straightforwardsince their parameters are only needed by one domain-specific simulator For example electrical lines exist only inthe power system domain and have connections only to otherpower system components Some components on the otherhand constitute natural coupling points between the powersystem the market and the communication network Thesecomponents are called interdomain components in the follow-ing For instance a battery storage device connected to thegrid can act as a market participant that offers its capabilityto charge or discharge In order to enable its participationin the energy market the battery storage needs an interfacewhich is a communication modem in this case The modemcan be seen as a part of the battery storage Therefore thedata model class associated with the battery storage devicehas to be able to hold or reference to data on the properties ofthe battery storage in electrical market and communicationdomains For a cosimulation the information on interdomaincomponents have to be split into several parts since theirparameters are needed by the simulators and each simulatorhas to simulate a dedicated part of these components

42 Cosimulation Time and Synchronization A remainingand major issue in such a cosimulation in which simulatorsof different categories are combined is the selection andimplementation of a proper synchronization mechanismwhich must ensure the proper progress of the simulationtime and a timely data exchange between the domain-specificsimulators This selection is of crucial significance in orderto minimize the error propagation in the cosimulation andthe synchronization overhead in terms of simulation timeIn [1] three main synchronization methods for cosimulation

have been specified time-stepped global event-driven andmaster-slave There are two different considerations relatedto the simulation time [12]

(i) Time resolution a challenge of the cosimulationis the highly diverse time resolutions of the threesimulators The time steps of power grid simulatorreach from milliseconds (electromagnetic processes)to subseconds and above (steady-state and electrome-chanic processes) The time steps of communicationnetwork simulations can even vary from tens ofmicroseconds (eg latencies in LANs) to seconds(eg latencies in WANs) On the other hand inenergy market simulations a time step of severalminutes can be sufficient as it is the case forGermanyrsquoscontrol power market with price calculations on 15-minute basis

(ii) Time ratio time ratio describes the relation betweensimulation time and wall clock time [12]With appro-priate use cases we want to show how holistic cosim-ulations with our approach can be used for planningand decision-making Therefore it is important torun the scenarios much faster than wall clock timeand for time intervals of days as well as of weeks sothatmanymodelswith different configurations can besimulated

The problem is that a very small time step or a high resolutionin time impedes short simulation times Therefore it isnecessary to adjust the time step according to the phenomenathat are under investigation At the same time it may befeasible to aim at a higher integration of the simulators andsacrifice flexibility and increase the efficiency if both timeresolution and time ratio need to be optimized In Section 53we discuss our design choices regarding the synchronizationof the simulators in detail The approach for an optimizationof time resolution and time ratio is further discussed in theSection 54

5 Concept of the Cosimulation Environment

51 Data Model for Power System Communication Networkand Market As explained in Section 2 one possibility isto extend the cosimulation topology format on CIM whichleads to a superset of CIM New classes which are introducedfor completing CIM in its representation of smart grids arelinked to theCIMclasses using the terminology of theUnifiedModeling Language (UML) The proposed format can bestructured in four packages

(i) Original CIM (IEC61970 IEC61968 IEC62325)(ii) Communication(iii) Market(iv) EnergyGrid

Whenever possible the CIM classes are used Howeversome components might not have an associated class in thestandard yet Then these components are represented asclasses in one of the other three packages The reason for

Complexity 5

Wholesale andretail market

Marketparticipants

(a)

Power system Communicationnetwork

Wholesaleand retail

Market

market

participantsMarket

(b)

Figure 1 Exemplary topology including components of all domains (a) and domain-specific topologies (b)

this approach is that this way it is easier to update to a newversion of CIM without losing the newly added classes andtheir interconnections

The most important feature of our model formatis the interconnection of domains In order to accom-plish this we have identified possible interdomain com-ponents Some examples of interdomain componentsnamely BatteryStorage SolarGeneratingUnit andMarketCogeneration are shown in Figure 2 which isan excerpt from our data model According to the UMLdiagram the energy market components are associatedwith the power system components whereas power systemcomponents have an aggregation relationship to com-munication devices This means that parameters specificto the market communication network and power systemwhich relate to the same device are linked with each otherTherefore all information on one device is easily accessiblebut at the same time there is a separation according tothe domains The connections between classes of differentdomains are defined in a logical and not a topological wayInstead topological connections exist to connect powersystem components for instance

Coming back to the battery storage device example thedatamodel is as follows the device is a part of the grid and haselectrical parameters Furthermore the battery storagemightparticipate in the market for example as part of a virtualpower plant (VPP) Market-specific information can bestored in the MarketBatteryStorage class which is associ-atedwith the electrical representationBatteryStorageThedata on the class for a communicationmodem ComModwhichcould be used to communicate with the VPP is aggregated tothe BatteryStorage class

In the following we briefly mention the domain-specificconsiderations for the three domains

(1) Power System Package The purpose of the EnergyGridpackage is to group models for power system componentsthat are not already part of the CIM standard For the simula-tion scenario that is presented later it was necessary to create

a new model for electrical energy storages like stationarybatteries A battery storage is a conducting equipment thatis able to regulate its energy throughput in both directionsTherefore the class BatteryStorage is a specialization ofa CIM RegulatingConductingEquipment since it caninfluence the flow of power at a specific point in the network

(2) Market Package The key component of the marketpackage for the scenarios that we would like to investigateis a VPP since the aggregation of small DER units enablestheir participation at electricity markets In case the DERsare not owned by the operator of the VPP they can be seenas customers that offer their energy in exchange for share ofthe VPP operators profits Besides a VPP might support theDistribution System Operator (DSO) in ensuring a safe gridoperation which results in an association between the DSOand the VPP

(3) Communication Package This package includes all addi-tionally defined classes that are related to the communicationnetwork model such as classes for communication linksand technologies modems network nodes along with theirparameters and their relations with the classes in CIMpower system package and market package In this waythe user can model the communication network layer andits specifications in the simulation tool The communicationnetwork topology and its parameters are then used by thecommunication network simulator for the cosimulation

Figure 3 shows an excerpt from the communication datamodel with an aggregation to a WindGeneratingUnit Bymeans of the associated classes for modems communicationrequirements and channels the model enables a descriptionof network parameters and topology Furthermore the com-munication network data model integrates the flexibility toenable the planning of the communication network undercommunication and power system requirements even beforethe beginning of the cosimulation The topological parame-ters will be used for an optimal design of the communica-tion network with the desired objective such as minimum

6 Complexity

Market

MarketBatteryStorage

Power System

EnergyStorageBatteryStorage

Communication

MarketSolarGeneratingUnit

GeneratingUnitProduction

SolarGeneratingUnit

EquipmentMarketCogenerationUnit

ProductionCogenerationPlant

ModemsComMod

PowerSystemResourceRegulatingCondEq

EquipmentEquipment

Figure 2 Interdomain connections between classes of power sys-tem communication network and market

GeneratingUnitWindGeneratingUnit

ComMod

WirelessMod

LTEModem

01

communicationRequirement

WiredMod

FiberModemWiredInterface

FiberInt

WiredChannelFiberChannel

11

1

0lowast

1lowast

1

Figure 3 Communication network class association example

cost while required conditions are satisfied such as givenreliability metric An example of this approach is presentedin [18] for an integrated design of a wide area measurementsystem Eventually the optimized communication networksolution can be evaluated against different scenarios using thecosimulation environment

52 Model Data Processing and Simulation Setup The overallinformation flow for the simulation setup is depicted inFigure 4 After the topology is created or modified in agraphical Topology Builder and includes the three domainsthe input file which complies with the common data modelof Section 51 is sent to the cosimulation interface Thecosimulation interface incorporates a component basedon CIM++ [19] which parses the CIM XML-RDF fileand generates a container of C++ objects that containthe topological data In order to execute a simulationthe Modelica solver requires a Modelica model whereas

Modelica models

Power systemsimulation

Modelica (DymolaOpenModelica)

Topology builder

Extended CIM

Cosimulation interfacemosaik CIM++

Objects2ModelicaObjects2Comm Net

Block diagram oftopology

XML representationof topology

C++ objects amp simulatorspecific text formats

Communication networkPython objects topology

CommunicationMarket simulation simulationpython ns-3 etc

Figure 4 Overall architecture for simulation setup

the communication network topology can be given to thecommunication network simulator in JSON or XML for-mat which includes the components in the network theirconnections and parameters Since the topology will beavailable as an XML-RDF file and a container of C++objects the relevant information for the power system andcommunication network is extracted during a deserializationstep In the subsequent transformation step a componentwhich we call Objects2ModelicaCommunicationNetworkgenerates Modelica and communication network files withthe topology and parameters In contrast the Python basedmarket simulation relies on a C++Python interface whichcould be realized using one of the common libraries forPython to wrap C++ data types and functions to retrieve themarket relevant information from the C++ objects and storethem in Python objects

The following paragraph explains the translation on thebasis of a CIM to Modelica example The loads are definedin the extended CIM data model described in Section 51 asPQ-loads with a characteristic power demand as follows

ltcimSvPowerFlow rdfID=PQ1-svgtltcimSvPowerFlowpgt1000ltcimSvPowerFlowpgtltcimSvPowerFlowqgt329ltcimSvPowerFlowqgtltcimSvPowerFlowTerminal

rdfresource=E-1229789360gtltcimSvPowerFlowgt

The cosimulation interface extracts the corresponding com-ponent parameters from the CIM XML-RDF file and intro-duces them in the Modelica model of the grid The latteris done by the Objects2Modelica component explained inSection 52 which iterates through the list of C++ objects pro-vided by CIM++ Thus the specification of the parameters 119875and119876 in the CIMmodel generates two attributemodificationequations in the declaration of the PQ-load in Modelica

Complexity 7

ModPowerSystemsPhasorSinglePhaseLoads

PQLoad CIM PQ1 (Pnom = 1000 Qnom = 329)

These values are applied during the quasistationary simula-tion of the single-phase representation of the grid

53 Synchronization The synchronization of all three sim-ulators will be performed in fixed time steps Fixed syn-chronization time steps have been chosen because of theresulting flexibility to integrate more simulators easily and itscomparatively high speed in terms of time steps per simula-tion time [1] An event-driven approach as it is implementedin [10] for two simulators requires a deeper integration ofthe cosimulation framework and the simulators Apart fromthat it was shown in [10] that the cosimulation error can bereduced for fixed time steps by reducing the global time stepsize

The synchronization between all simulators for slowphenomena scenarios is performed with mosaik a well-established cosimulation framework [20] which was devel-oped for stationary simulations with time steps of one secondor greater [21] It allows combining the three simulators in asimple manner as explained in Section 54 VILLASnode asoftware project for coupling real-time simulations in LANs[22 23] is a suitable alternative for mosaik in the case ofsynchronizations with very short intervals

In Modelica the synchronization data exchange isachieved by integrating Modelica blocks of the ModelicaDeviceDrivers library which was originally developed forinterfacing device drivers to Modelica models This con-veniently allows the definition of a fixed interval for dataexchange Modelica DeviceDrivers were chosen instead ofthe FMI approach shown in [21] because it allows moreflexibility in picking the desired simulation variables andchoosing the required cosimulation step size independentlyfrom the Modelica simulator time step At synchronizationsteps between all simulators the step function of the energymarket simulator is called synchronously from the mosaikPython API After the market simulator has finished thesimulation step the results are retrieved by mosaik

The simulation time in the DES of the communicationnetwork advances with the execution of the generated eventswhich are stored in an event-list The execution of eventsis controlled by a scheduler which determines the nextevent and its execution time Whereas the default schedulerexecutes the events sequentially without any interruptionsthe available simulation environments offer the flexibility tointegrate external control inputs to receive external controlmessages which can be used to manipulate the simulationflow by changing the module parameters during the simula-tion In order to realize this the event-driven nature of DEStools can be used to generate new events called flow controlevents which stop the communication simulation exchangedata and use the input data to manipulate the followingsimulation steps Furthermore the execution of events canbe controlled and the simulation can be stopped after theexecution of the last event before a synchronization point sothat the simulation runs in fixed steps and a data exchange ispossible at the end of each step

Powersystem

Commnetwork

MarketEvent 0

Event 1

Powersystem

Commnetwork

MarketEvent 2

Event 3

Powersystem

Market

Individualsimulator steps

Cosimulation step

0

0

0

0

1

1 2

1 1

1

2

2

211

Figure 5 Synchronization scheme of simulators at cosimulationtime steps

Figure 5 depicts the flow of time for the cosimulationand each simulator It can be seen that the power system andmarket simulators compute in parallel whereas the commu-nicationnetwork iswaiting for their inputs In amathematicalnotation the interactions between the simulators in eachcosimulation step can be defined by

119906119901 (119899 + 1) = 119865119888 (119865119898 (119906119898 (119899)))

119906119898 (119899 + 1) = 119865119888 (119865119901 (119906119901 (119899))) (1)

where 119906119898 and 119906119901 are the corresponding input values ofthe simulators for the power system energy market andcommunication network for each time step Therefore it isrequired to set initial values 119906119901(0) 119906119898(0) at the beginningof the cosimulation 119899 denominates the current cosimulationtime step 119865119888 (communication) 119865119898 (market) and 119865119901 (powersystem) are the functions describing the calculation of thenext time step

54 Cosimulation Runtime Interaction In Figure 6 the cou-pling of the power system communication and market sim-ulator for their cosimulation runtime interaction is shown Inthe following we briefly introduce the individual parts of thecosimulation environment

(i) Mosaik as already mentioned mosaik is used forthe coordination during the synchronization stepsof several minutes (in simulation time) regarding allsimulators [24] mosaik has two different APIs forsimulator coupling It provides handlers for differentsimulator types allows modelling of different simula-tion scenarios and schedules the step-wise executionof the connected simulators with the aid of SimPy[25] The two mosaik APIs are

(a) the low-level API which uses common TCPIPnetwork sockets for exchanging messages en-capsulated in JSON an open-source and hu-man-readable data format

(b) the high-level API which can be directly usedby a simulator and communicate with mosaikthrough sockets but also handle their creationevents and message (de)serialization

8 Complexity

TCP sockets

Communicationsimulation

DESenvironment

(R)UDP sockets

(R)UDP sockets

VILLAS-node

Python environmentMarket

simulation

TCP sockets TCP sockets TCP sockets

TCP sockets

TCP socketsmosaik-

core

Slow phenomenacommunication

MODD server

ModelicaDeviceDrivers

Power systemsimulation

Modelicaenvironment

Fast phenomena communication

(R)U

DP

sock

ets

Mod

elic

aD

evic

eDriv

ers

Figure 6 Scheme of runtime interaction between cosimulationcomponents

(ii) Market simulator implemented in Python it canmake use of the high-level API as illustrated inFigure 6Theuse of the sockets allows the desired flex-ibility of running all simulators on different computersystems and environments

(iii) Communication network simulator based on avail-able DES tools their network simulation modules areextendedwith interprocess communication function-alities for JSON message exchange with mosaik

(iv) Power system simulator the integration of so-called TCPIP SendRecv IO blocks from ModelicaDeviceDrivers into the Modelica models allows theexchange of simulation data via sockets but in theform of Modelica variables as bitvectors instead ofJSON messages Therefore the MODD Server isimplemented

(v) MODD server it receives commands from the socketconnected with mosaik Based on these commandsit starts for example the power system simulator orreceives the bitstream from Modelica DeviceDriversand encapsulates it into JSON messages before trans-ferring them to mosaik Besides the synchronizationsteps controlled by mosaik there will be also morefine-grained synchronization steps of fractions of sec-onds between the power system and communicationnetwork simulator That is why a VILLASnode serveris included

Root-coordinator

Topcoordinator

subcoordinator

simulator simulator

simulatorC

MP

Figure 7 Cosimulation environment as a hierarchical simulator

(vi) VILLASnode instead of TCP (Transmission ControlProtocol) it makes use of UDP (User DatagramProtocol) sockets for data exchange between real-time simulators for which it was designedThe use ofUDP leads to less overhead and consequently to lowersynchronization time steps but with the disadvantageof an unreliable connectionOur solution for avoidingany datagram losses is the usage of Reliable UDP(RUDP) to keep a low overhead in comparison withTCP with the benefit of a reliable connection

55 DEVS Formalization As explained in Section 53 adiscrete time base is chosen for the synchronization betweenthe domain-specific simulators Therefore the simulatorscan be formalized by Discrete Time System Specifications(DTSS) Since the time steps are fixed the DTSS can besimulated by DEVS [17] The abstraction level of the DEVShas not been considered for the mosaik framework fordifferent reasons [26] and is not needed for the definitionof cosimulation scenarios Therefore a formal definition ofthe whole simulation as coupled DEVS is beyond the scopeof this paper However a so-called hierarchical simulatorfor the three atomic simulators 119875 119872 and 119862 (for energymarket and communication) is shown in Figure 7 as leavesof the hierarchical simulator (ie tree) [17] and describedin the following The root-coordinator sends an initializationmessage (119894 119905) which is propagated to all atomic simulators inthe tree at simulation start and initiates the simulation stepswith state transition messages (lowast 119905) The coordinators handlethe levels of coupled simulators up to the root of the treeThe scheduling of an event is performed by a (lowast 119905) messageforwarded by each receiver coordinator to its imminent childThe imminent child is the simulator which shall perform itsnext internal transition or the coordinator being the root ofthe subtree containing the simulator which performs the nextinternal transition

Complexity 9

In case of our cosimulation architecture the first (lowast 119905)message is forwarded by the top and the subcoordinatorto the first component in the event-list (here 119875 simulator)computing the new output 119910119875 = 120582(119904) and sending it as outputmessage (119910119875 119905) to the subcoordinator The subcoordinatorthen recognizes an internal coupling and therefore sends anx-message (119909119872 119905) with 119909119872 = 119885119875119872(119910119875) to the 119872 simulatorwhereby 119885119875119872 119884119875 rarr 119883119872 is the translation function fromthe output events of the 119875 simulator to the input events of the119872 simulator Although the computations of the119872 simulatorwithin the same transition donot dependon the output of the119875 simulator its output message (119910119872 119905) includes the output ofboth simulators This output is translated and forwarded bythe subcoordinator to its parent (top coordinator) becauseof the external coupling as output message (119910119873 119905) of thebelonging Discrete Event Specified Network (DEVN) After-wards the top coordinator translates the message to an inputmessage (119909119862 119905) of the119862 simulator which computes the outputof the whole cosimulation step This output is transformedby the top coordinator because of its internal coupling toan input message for the subcoordinator which translatesand sends the message down to the 119875 simulator because ofthe external input coupling and the next cosimulation stepbegins

An improvement of this formalization based on thehierarchical simulator could be accomplished by a formal-ization of the 119875 and 119872 simulator as a conservative paralleldiscrete event simulation [17] Nevertheless the describedcommunication pattern between the components of thehierarchical simulator shows that the chosen cosimulationsynchronization scheme depicted in Figure 5 is validwhen causality violations between the energy and marketsimulation within one time step of the cosimulation areavoided which is guaranteed for the considered simulationscenarios

56 Limitations Due to the communication overhead causedby the cosimulation environment the simulation time mightincrease significantly for large network sizes Currently real-time simulations are not possible but the available frameworkcan be extended for real-time and hardware-in-the-loopsimulations for example by using VILLASnode instead ofmosaik

Furthermore the synchronization step size cannot bechanged during simulation runtime whereas the domain-specific simulators support variable simulation time stepsTo enable a variable step size for an optimized cosimulationthrough more sophisticated algorithms modifications of themosaik framework would be necessary as it allows fixed timesteps onlyThe cosimulation flowmanaged by mosaik whichallows parallel and sequential progress of simulators mightintroduce inaccuracies in the simulation results with respectto the synchronization step size

Moreover the simulation of heterogeneous communi-cation networks and standards is possible However theabstraction level of the communication protocols influ-ences the simulation time of the communication networksimulator and thus the simulation time of the cosimu-lation

6 Verification of the Cosimulation Interfaces

In this section we aim to show that the implementedcosimulation infrastructure does not impair the accuracyof the simulation results As an exemplary application weconsider a scenario where a VPP operator aims at gainingprofits by reducing the VPPrsquos peak power Thus a peak-shaving algorithm is employed for an optimal managementof distributed battery storage systems Financial incentives forthe peak-shaving behavior might originate from agreementswithDSOs regarding themaximumpower feed-in of theVPPStarting from results without the cosimulation frameworkwe successively include the cosimulation environment anddomain-specific simulators to demonstrate that the results donot change under the assumption of an ideal communicationnetwork in the same scenario Eventually a slightly differentscenario is presented where the communication network issupposed to impair the control loop between the powersystem and themarket due to communication device failuresthereby showing an exemplary use case for the cosimulationarchitecture presented in this paper

61 Simulation Scenarios andModels The investigated powersystem is a part of the IEEE European Low Voltage TestFeeder The loads in the test feeder are replaced with build-ings each incorporating a PQ-load Furthermore severalof these buildings feature stationary batteries and solargeneration The battery storages are controlled by a peak-shaving algorithm which is implemented in the market sim-ulator The peak-shaving algorithm is supposed to representa VPP operator that utilizes its aggregated storage in a gridsupporting way That is why in a real world application itneeds to exchange measurement and control values with thebattery storages through the communication network

In the first simulation scenario the communicationbetween batteries and the peak-shaving algorithm is idealand not subject to any communication network failures Thisscenario is used to verify the correct exchange of simulationdata between the simulators involved in the cosimulationFor this reason the simulation is first executed withoutcosimulation framework connecting the peak-shaving algo-rithm directly to the power system simulation Then thecosimulation environment is introduced and afterwards thecommunication network simulatorThe results of these threesimulation cases are presented in Section 62

The second simulation scenario analyzed in Section 63features a communication network failure in order to show apossible use case of the complete cosimulation environment

The following equations are implemented in Modelicato simulate the power system components in the buildingsThe PQ-loads in the buildings are modelled as ideal constantpower loads which means that the load current is directlydependent on the voltage at the grid connection point

The implemented Modelica model of the solar generatordetermines the active power output 119875sg by

119875sg3 = 119881oc sdot 119868sc sdot 119865119865 sdot

119875sginst1198750

(2)

10 Complexity

under the assumption that the plant is operating at itsmaximum power point and where 119881oc and 119868sc are the open-circuit voltage and the short-circuit current respectivelyThey vary with temperature and solar radiation which can bemodelled according to [27] The term 119875sginst1198750 in (3) adaptsthe magnitude of the output power to the installed power ofa specific solar generating unit given that 1198750 represents theinstalled power of the solar panel used in [27]

The model of the battery storages consists of a simple setof equations describing the derivative of the state of charge(SOC) as

119889119889119905SOC =

120578ch119875119861119862119861

119875119861 ge 0

119875119861120578disch119862119861

119875119861 lt 0(3)

In addition the battery model limits the SOC to be in therange between zero and oneThe values specifying the batterycapacity 119862119861 the charging efficiency 120578ch and the dischargingefficiency 120578disch are extracted from the extended CIM classessee Section 51

The VPP algorithm aims at stabilizing the voltage profileby reducing the power exchange between the grid andthe buildings using a model predictive control approachTherefore the battery charging power 119875119861 is set according toan optimal scheduling which is based on forecasts for solarradiation and load demand To compensate for inaccuraciesin the forecasts the algorithm receives measurements ofactual load demand generated solar power and battery stateof charge from the power system simulator

62 Comparison of Results with and without CosimulationEnvironment At first both measurements and set pointsare neither passed through the communication networksimulator nor the cosimulation framework Instead thecontrol signals for the battery storages are directly suppliedby the peak-shaving algorithm before each power systemsimulation step Following this reference case both simula-tors are connected through the cosimulation environment asdescribed in Section 54 Still the communication networksimulator is not involved The results depicted in Figure 8present the voltage profile over time at one node in thetest feeder and it can be seen that the results with andwithout the cosimulation environment are consistent If thecommunication network had altered the exchanged datacontrol values and measurements the voltage profile wouldhave changed Next we take this one step further andalso introduce the communication network simulator Thecommunication network simulator acts as mediator betweenthe power system and market simulators Any data that isexchanged between the power system and market has to passthrough the former The communication network simulatoris added to the cosimulation as presented in Sections 53and 54 To verify that the three simulators are synchronizedproperly we include an ideal communication network that isall messages are transmitted without any latencies Evidentlyan ideal communication should not affect the informationexchange between power system and market so that the

1003

1002

1001

1000

0999

0998

0997

Volta

ge (p

u)

Time (h)

Direct couplingmosaik coupling

24211815129630

Figure 8 Comparison of simulation results of power system andmarket with and reference case without cosimulation environment

No comm simulatorWith comm simulator

3 6 9 12 15 18 21 240

Time (h)

0997

0998

1000

1001

1002

1003Vo

ltage

(pu

)

0999

Figure 9 Comparison of simulation results with cosimulationenvironment and ideal communication network and reference casewithout cosimulation environment

implemented scheduling for battery charging should performequally

In Figure 9 it is visible that the simulation results incor-porating the ideal communication network do not deviatefrom the ones obtained without the communication networkeven though all messages are now passing through thecommunication network simulatorThus the results confirma correct synchronization of the three simulators and theconsistency of the implemented cosimulation environment

63 Exemplary Cosimulation with Communication NetworkFailure In this subsection the three simulators are exchang-ing data in the sameway as described at the end of Section 62Only this time the communication network simulator emu-lates a fault in the communication network which leadsto a communication failure of one hour at the site of the

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

Complexity 5

Wholesale andretail market

Marketparticipants

(a)

Power system Communicationnetwork

Wholesaleand retail

Market

market

participantsMarket

(b)

Figure 1 Exemplary topology including components of all domains (a) and domain-specific topologies (b)

this approach is that this way it is easier to update to a newversion of CIM without losing the newly added classes andtheir interconnections

The most important feature of our model formatis the interconnection of domains In order to accom-plish this we have identified possible interdomain com-ponents Some examples of interdomain componentsnamely BatteryStorage SolarGeneratingUnit andMarketCogeneration are shown in Figure 2 which isan excerpt from our data model According to the UMLdiagram the energy market components are associatedwith the power system components whereas power systemcomponents have an aggregation relationship to com-munication devices This means that parameters specificto the market communication network and power systemwhich relate to the same device are linked with each otherTherefore all information on one device is easily accessiblebut at the same time there is a separation according tothe domains The connections between classes of differentdomains are defined in a logical and not a topological wayInstead topological connections exist to connect powersystem components for instance

Coming back to the battery storage device example thedatamodel is as follows the device is a part of the grid and haselectrical parameters Furthermore the battery storagemightparticipate in the market for example as part of a virtualpower plant (VPP) Market-specific information can bestored in the MarketBatteryStorage class which is associ-atedwith the electrical representationBatteryStorageThedata on the class for a communicationmodem ComModwhichcould be used to communicate with the VPP is aggregated tothe BatteryStorage class

In the following we briefly mention the domain-specificconsiderations for the three domains

(1) Power System Package The purpose of the EnergyGridpackage is to group models for power system componentsthat are not already part of the CIM standard For the simula-tion scenario that is presented later it was necessary to create

a new model for electrical energy storages like stationarybatteries A battery storage is a conducting equipment thatis able to regulate its energy throughput in both directionsTherefore the class BatteryStorage is a specialization ofa CIM RegulatingConductingEquipment since it caninfluence the flow of power at a specific point in the network

(2) Market Package The key component of the marketpackage for the scenarios that we would like to investigateis a VPP since the aggregation of small DER units enablestheir participation at electricity markets In case the DERsare not owned by the operator of the VPP they can be seenas customers that offer their energy in exchange for share ofthe VPP operators profits Besides a VPP might support theDistribution System Operator (DSO) in ensuring a safe gridoperation which results in an association between the DSOand the VPP

(3) Communication Package This package includes all addi-tionally defined classes that are related to the communicationnetwork model such as classes for communication linksand technologies modems network nodes along with theirparameters and their relations with the classes in CIMpower system package and market package In this waythe user can model the communication network layer andits specifications in the simulation tool The communicationnetwork topology and its parameters are then used by thecommunication network simulator for the cosimulation

Figure 3 shows an excerpt from the communication datamodel with an aggregation to a WindGeneratingUnit Bymeans of the associated classes for modems communicationrequirements and channels the model enables a descriptionof network parameters and topology Furthermore the com-munication network data model integrates the flexibility toenable the planning of the communication network undercommunication and power system requirements even beforethe beginning of the cosimulation The topological parame-ters will be used for an optimal design of the communica-tion network with the desired objective such as minimum

6 Complexity

Market

MarketBatteryStorage

Power System

EnergyStorageBatteryStorage

Communication

MarketSolarGeneratingUnit

GeneratingUnitProduction

SolarGeneratingUnit

EquipmentMarketCogenerationUnit

ProductionCogenerationPlant

ModemsComMod

PowerSystemResourceRegulatingCondEq

EquipmentEquipment

Figure 2 Interdomain connections between classes of power sys-tem communication network and market

GeneratingUnitWindGeneratingUnit

ComMod

WirelessMod

LTEModem

01

communicationRequirement

WiredMod

FiberModemWiredInterface

FiberInt

WiredChannelFiberChannel

11

1

0lowast

1lowast

1

Figure 3 Communication network class association example

cost while required conditions are satisfied such as givenreliability metric An example of this approach is presentedin [18] for an integrated design of a wide area measurementsystem Eventually the optimized communication networksolution can be evaluated against different scenarios using thecosimulation environment

52 Model Data Processing and Simulation Setup The overallinformation flow for the simulation setup is depicted inFigure 4 After the topology is created or modified in agraphical Topology Builder and includes the three domainsthe input file which complies with the common data modelof Section 51 is sent to the cosimulation interface Thecosimulation interface incorporates a component basedon CIM++ [19] which parses the CIM XML-RDF fileand generates a container of C++ objects that containthe topological data In order to execute a simulationthe Modelica solver requires a Modelica model whereas

Modelica models

Power systemsimulation

Modelica (DymolaOpenModelica)

Topology builder

Extended CIM

Cosimulation interfacemosaik CIM++

Objects2ModelicaObjects2Comm Net

Block diagram oftopology

XML representationof topology

C++ objects amp simulatorspecific text formats

Communication networkPython objects topology

CommunicationMarket simulation simulationpython ns-3 etc

Figure 4 Overall architecture for simulation setup

the communication network topology can be given to thecommunication network simulator in JSON or XML for-mat which includes the components in the network theirconnections and parameters Since the topology will beavailable as an XML-RDF file and a container of C++objects the relevant information for the power system andcommunication network is extracted during a deserializationstep In the subsequent transformation step a componentwhich we call Objects2ModelicaCommunicationNetworkgenerates Modelica and communication network files withthe topology and parameters In contrast the Python basedmarket simulation relies on a C++Python interface whichcould be realized using one of the common libraries forPython to wrap C++ data types and functions to retrieve themarket relevant information from the C++ objects and storethem in Python objects

The following paragraph explains the translation on thebasis of a CIM to Modelica example The loads are definedin the extended CIM data model described in Section 51 asPQ-loads with a characteristic power demand as follows

ltcimSvPowerFlow rdfID=PQ1-svgtltcimSvPowerFlowpgt1000ltcimSvPowerFlowpgtltcimSvPowerFlowqgt329ltcimSvPowerFlowqgtltcimSvPowerFlowTerminal

rdfresource=E-1229789360gtltcimSvPowerFlowgt

The cosimulation interface extracts the corresponding com-ponent parameters from the CIM XML-RDF file and intro-duces them in the Modelica model of the grid The latteris done by the Objects2Modelica component explained inSection 52 which iterates through the list of C++ objects pro-vided by CIM++ Thus the specification of the parameters 119875and119876 in the CIMmodel generates two attributemodificationequations in the declaration of the PQ-load in Modelica

Complexity 7

ModPowerSystemsPhasorSinglePhaseLoads

PQLoad CIM PQ1 (Pnom = 1000 Qnom = 329)

These values are applied during the quasistationary simula-tion of the single-phase representation of the grid

53 Synchronization The synchronization of all three sim-ulators will be performed in fixed time steps Fixed syn-chronization time steps have been chosen because of theresulting flexibility to integrate more simulators easily and itscomparatively high speed in terms of time steps per simula-tion time [1] An event-driven approach as it is implementedin [10] for two simulators requires a deeper integration ofthe cosimulation framework and the simulators Apart fromthat it was shown in [10] that the cosimulation error can bereduced for fixed time steps by reducing the global time stepsize

The synchronization between all simulators for slowphenomena scenarios is performed with mosaik a well-established cosimulation framework [20] which was devel-oped for stationary simulations with time steps of one secondor greater [21] It allows combining the three simulators in asimple manner as explained in Section 54 VILLASnode asoftware project for coupling real-time simulations in LANs[22 23] is a suitable alternative for mosaik in the case ofsynchronizations with very short intervals

In Modelica the synchronization data exchange isachieved by integrating Modelica blocks of the ModelicaDeviceDrivers library which was originally developed forinterfacing device drivers to Modelica models This con-veniently allows the definition of a fixed interval for dataexchange Modelica DeviceDrivers were chosen instead ofthe FMI approach shown in [21] because it allows moreflexibility in picking the desired simulation variables andchoosing the required cosimulation step size independentlyfrom the Modelica simulator time step At synchronizationsteps between all simulators the step function of the energymarket simulator is called synchronously from the mosaikPython API After the market simulator has finished thesimulation step the results are retrieved by mosaik

The simulation time in the DES of the communicationnetwork advances with the execution of the generated eventswhich are stored in an event-list The execution of eventsis controlled by a scheduler which determines the nextevent and its execution time Whereas the default schedulerexecutes the events sequentially without any interruptionsthe available simulation environments offer the flexibility tointegrate external control inputs to receive external controlmessages which can be used to manipulate the simulationflow by changing the module parameters during the simula-tion In order to realize this the event-driven nature of DEStools can be used to generate new events called flow controlevents which stop the communication simulation exchangedata and use the input data to manipulate the followingsimulation steps Furthermore the execution of events canbe controlled and the simulation can be stopped after theexecution of the last event before a synchronization point sothat the simulation runs in fixed steps and a data exchange ispossible at the end of each step

Powersystem

Commnetwork

MarketEvent 0

Event 1

Powersystem

Commnetwork

MarketEvent 2

Event 3

Powersystem

Market

Individualsimulator steps

Cosimulation step

0

0

0

0

1

1 2

1 1

1

2

2

211

Figure 5 Synchronization scheme of simulators at cosimulationtime steps

Figure 5 depicts the flow of time for the cosimulationand each simulator It can be seen that the power system andmarket simulators compute in parallel whereas the commu-nicationnetwork iswaiting for their inputs In amathematicalnotation the interactions between the simulators in eachcosimulation step can be defined by

119906119901 (119899 + 1) = 119865119888 (119865119898 (119906119898 (119899)))

119906119898 (119899 + 1) = 119865119888 (119865119901 (119906119901 (119899))) (1)

where 119906119898 and 119906119901 are the corresponding input values ofthe simulators for the power system energy market andcommunication network for each time step Therefore it isrequired to set initial values 119906119901(0) 119906119898(0) at the beginningof the cosimulation 119899 denominates the current cosimulationtime step 119865119888 (communication) 119865119898 (market) and 119865119901 (powersystem) are the functions describing the calculation of thenext time step

54 Cosimulation Runtime Interaction In Figure 6 the cou-pling of the power system communication and market sim-ulator for their cosimulation runtime interaction is shown Inthe following we briefly introduce the individual parts of thecosimulation environment

(i) Mosaik as already mentioned mosaik is used forthe coordination during the synchronization stepsof several minutes (in simulation time) regarding allsimulators [24] mosaik has two different APIs forsimulator coupling It provides handlers for differentsimulator types allows modelling of different simula-tion scenarios and schedules the step-wise executionof the connected simulators with the aid of SimPy[25] The two mosaik APIs are

(a) the low-level API which uses common TCPIPnetwork sockets for exchanging messages en-capsulated in JSON an open-source and hu-man-readable data format

(b) the high-level API which can be directly usedby a simulator and communicate with mosaikthrough sockets but also handle their creationevents and message (de)serialization

8 Complexity

TCP sockets

Communicationsimulation

DESenvironment

(R)UDP sockets

(R)UDP sockets

VILLAS-node

Python environmentMarket

simulation

TCP sockets TCP sockets TCP sockets

TCP sockets

TCP socketsmosaik-

core

Slow phenomenacommunication

MODD server

ModelicaDeviceDrivers

Power systemsimulation

Modelicaenvironment

Fast phenomena communication

(R)U

DP

sock

ets

Mod

elic

aD

evic

eDriv

ers

Figure 6 Scheme of runtime interaction between cosimulationcomponents

(ii) Market simulator implemented in Python it canmake use of the high-level API as illustrated inFigure 6Theuse of the sockets allows the desired flex-ibility of running all simulators on different computersystems and environments

(iii) Communication network simulator based on avail-able DES tools their network simulation modules areextendedwith interprocess communication function-alities for JSON message exchange with mosaik

(iv) Power system simulator the integration of so-called TCPIP SendRecv IO blocks from ModelicaDeviceDrivers into the Modelica models allows theexchange of simulation data via sockets but in theform of Modelica variables as bitvectors instead ofJSON messages Therefore the MODD Server isimplemented

(v) MODD server it receives commands from the socketconnected with mosaik Based on these commandsit starts for example the power system simulator orreceives the bitstream from Modelica DeviceDriversand encapsulates it into JSON messages before trans-ferring them to mosaik Besides the synchronizationsteps controlled by mosaik there will be also morefine-grained synchronization steps of fractions of sec-onds between the power system and communicationnetwork simulator That is why a VILLASnode serveris included

Root-coordinator

Topcoordinator

subcoordinator

simulator simulator

simulatorC

MP

Figure 7 Cosimulation environment as a hierarchical simulator

(vi) VILLASnode instead of TCP (Transmission ControlProtocol) it makes use of UDP (User DatagramProtocol) sockets for data exchange between real-time simulators for which it was designedThe use ofUDP leads to less overhead and consequently to lowersynchronization time steps but with the disadvantageof an unreliable connectionOur solution for avoidingany datagram losses is the usage of Reliable UDP(RUDP) to keep a low overhead in comparison withTCP with the benefit of a reliable connection

55 DEVS Formalization As explained in Section 53 adiscrete time base is chosen for the synchronization betweenthe domain-specific simulators Therefore the simulatorscan be formalized by Discrete Time System Specifications(DTSS) Since the time steps are fixed the DTSS can besimulated by DEVS [17] The abstraction level of the DEVShas not been considered for the mosaik framework fordifferent reasons [26] and is not needed for the definitionof cosimulation scenarios Therefore a formal definition ofthe whole simulation as coupled DEVS is beyond the scopeof this paper However a so-called hierarchical simulatorfor the three atomic simulators 119875 119872 and 119862 (for energymarket and communication) is shown in Figure 7 as leavesof the hierarchical simulator (ie tree) [17] and describedin the following The root-coordinator sends an initializationmessage (119894 119905) which is propagated to all atomic simulators inthe tree at simulation start and initiates the simulation stepswith state transition messages (lowast 119905) The coordinators handlethe levels of coupled simulators up to the root of the treeThe scheduling of an event is performed by a (lowast 119905) messageforwarded by each receiver coordinator to its imminent childThe imminent child is the simulator which shall perform itsnext internal transition or the coordinator being the root ofthe subtree containing the simulator which performs the nextinternal transition

Complexity 9

In case of our cosimulation architecture the first (lowast 119905)message is forwarded by the top and the subcoordinatorto the first component in the event-list (here 119875 simulator)computing the new output 119910119875 = 120582(119904) and sending it as outputmessage (119910119875 119905) to the subcoordinator The subcoordinatorthen recognizes an internal coupling and therefore sends anx-message (119909119872 119905) with 119909119872 = 119885119875119872(119910119875) to the 119872 simulatorwhereby 119885119875119872 119884119875 rarr 119883119872 is the translation function fromthe output events of the 119875 simulator to the input events of the119872 simulator Although the computations of the119872 simulatorwithin the same transition donot dependon the output of the119875 simulator its output message (119910119872 119905) includes the output ofboth simulators This output is translated and forwarded bythe subcoordinator to its parent (top coordinator) becauseof the external coupling as output message (119910119873 119905) of thebelonging Discrete Event Specified Network (DEVN) After-wards the top coordinator translates the message to an inputmessage (119909119862 119905) of the119862 simulator which computes the outputof the whole cosimulation step This output is transformedby the top coordinator because of its internal coupling toan input message for the subcoordinator which translatesand sends the message down to the 119875 simulator because ofthe external input coupling and the next cosimulation stepbegins

An improvement of this formalization based on thehierarchical simulator could be accomplished by a formal-ization of the 119875 and 119872 simulator as a conservative paralleldiscrete event simulation [17] Nevertheless the describedcommunication pattern between the components of thehierarchical simulator shows that the chosen cosimulationsynchronization scheme depicted in Figure 5 is validwhen causality violations between the energy and marketsimulation within one time step of the cosimulation areavoided which is guaranteed for the considered simulationscenarios

56 Limitations Due to the communication overhead causedby the cosimulation environment the simulation time mightincrease significantly for large network sizes Currently real-time simulations are not possible but the available frameworkcan be extended for real-time and hardware-in-the-loopsimulations for example by using VILLASnode instead ofmosaik

Furthermore the synchronization step size cannot bechanged during simulation runtime whereas the domain-specific simulators support variable simulation time stepsTo enable a variable step size for an optimized cosimulationthrough more sophisticated algorithms modifications of themosaik framework would be necessary as it allows fixed timesteps onlyThe cosimulation flowmanaged by mosaik whichallows parallel and sequential progress of simulators mightintroduce inaccuracies in the simulation results with respectto the synchronization step size

Moreover the simulation of heterogeneous communi-cation networks and standards is possible However theabstraction level of the communication protocols influ-ences the simulation time of the communication networksimulator and thus the simulation time of the cosimu-lation

6 Verification of the Cosimulation Interfaces

In this section we aim to show that the implementedcosimulation infrastructure does not impair the accuracyof the simulation results As an exemplary application weconsider a scenario where a VPP operator aims at gainingprofits by reducing the VPPrsquos peak power Thus a peak-shaving algorithm is employed for an optimal managementof distributed battery storage systems Financial incentives forthe peak-shaving behavior might originate from agreementswithDSOs regarding themaximumpower feed-in of theVPPStarting from results without the cosimulation frameworkwe successively include the cosimulation environment anddomain-specific simulators to demonstrate that the results donot change under the assumption of an ideal communicationnetwork in the same scenario Eventually a slightly differentscenario is presented where the communication network issupposed to impair the control loop between the powersystem and themarket due to communication device failuresthereby showing an exemplary use case for the cosimulationarchitecture presented in this paper

61 Simulation Scenarios andModels The investigated powersystem is a part of the IEEE European Low Voltage TestFeeder The loads in the test feeder are replaced with build-ings each incorporating a PQ-load Furthermore severalof these buildings feature stationary batteries and solargeneration The battery storages are controlled by a peak-shaving algorithm which is implemented in the market sim-ulator The peak-shaving algorithm is supposed to representa VPP operator that utilizes its aggregated storage in a gridsupporting way That is why in a real world application itneeds to exchange measurement and control values with thebattery storages through the communication network

In the first simulation scenario the communicationbetween batteries and the peak-shaving algorithm is idealand not subject to any communication network failures Thisscenario is used to verify the correct exchange of simulationdata between the simulators involved in the cosimulationFor this reason the simulation is first executed withoutcosimulation framework connecting the peak-shaving algo-rithm directly to the power system simulation Then thecosimulation environment is introduced and afterwards thecommunication network simulatorThe results of these threesimulation cases are presented in Section 62

The second simulation scenario analyzed in Section 63features a communication network failure in order to show apossible use case of the complete cosimulation environment

The following equations are implemented in Modelicato simulate the power system components in the buildingsThe PQ-loads in the buildings are modelled as ideal constantpower loads which means that the load current is directlydependent on the voltage at the grid connection point

The implemented Modelica model of the solar generatordetermines the active power output 119875sg by

119875sg3 = 119881oc sdot 119868sc sdot 119865119865 sdot

119875sginst1198750

(2)

10 Complexity

under the assumption that the plant is operating at itsmaximum power point and where 119881oc and 119868sc are the open-circuit voltage and the short-circuit current respectivelyThey vary with temperature and solar radiation which can bemodelled according to [27] The term 119875sginst1198750 in (3) adaptsthe magnitude of the output power to the installed power ofa specific solar generating unit given that 1198750 represents theinstalled power of the solar panel used in [27]

The model of the battery storages consists of a simple setof equations describing the derivative of the state of charge(SOC) as

119889119889119905SOC =

120578ch119875119861119862119861

119875119861 ge 0

119875119861120578disch119862119861

119875119861 lt 0(3)

In addition the battery model limits the SOC to be in therange between zero and oneThe values specifying the batterycapacity 119862119861 the charging efficiency 120578ch and the dischargingefficiency 120578disch are extracted from the extended CIM classessee Section 51

The VPP algorithm aims at stabilizing the voltage profileby reducing the power exchange between the grid andthe buildings using a model predictive control approachTherefore the battery charging power 119875119861 is set according toan optimal scheduling which is based on forecasts for solarradiation and load demand To compensate for inaccuraciesin the forecasts the algorithm receives measurements ofactual load demand generated solar power and battery stateof charge from the power system simulator

62 Comparison of Results with and without CosimulationEnvironment At first both measurements and set pointsare neither passed through the communication networksimulator nor the cosimulation framework Instead thecontrol signals for the battery storages are directly suppliedby the peak-shaving algorithm before each power systemsimulation step Following this reference case both simula-tors are connected through the cosimulation environment asdescribed in Section 54 Still the communication networksimulator is not involved The results depicted in Figure 8present the voltage profile over time at one node in thetest feeder and it can be seen that the results with andwithout the cosimulation environment are consistent If thecommunication network had altered the exchanged datacontrol values and measurements the voltage profile wouldhave changed Next we take this one step further andalso introduce the communication network simulator Thecommunication network simulator acts as mediator betweenthe power system and market simulators Any data that isexchanged between the power system and market has to passthrough the former The communication network simulatoris added to the cosimulation as presented in Sections 53and 54 To verify that the three simulators are synchronizedproperly we include an ideal communication network that isall messages are transmitted without any latencies Evidentlyan ideal communication should not affect the informationexchange between power system and market so that the

1003

1002

1001

1000

0999

0998

0997

Volta

ge (p

u)

Time (h)

Direct couplingmosaik coupling

24211815129630

Figure 8 Comparison of simulation results of power system andmarket with and reference case without cosimulation environment

No comm simulatorWith comm simulator

3 6 9 12 15 18 21 240

Time (h)

0997

0998

1000

1001

1002

1003Vo

ltage

(pu

)

0999

Figure 9 Comparison of simulation results with cosimulationenvironment and ideal communication network and reference casewithout cosimulation environment

implemented scheduling for battery charging should performequally

In Figure 9 it is visible that the simulation results incor-porating the ideal communication network do not deviatefrom the ones obtained without the communication networkeven though all messages are now passing through thecommunication network simulatorThus the results confirma correct synchronization of the three simulators and theconsistency of the implemented cosimulation environment

63 Exemplary Cosimulation with Communication NetworkFailure In this subsection the three simulators are exchang-ing data in the sameway as described at the end of Section 62Only this time the communication network simulator emu-lates a fault in the communication network which leadsto a communication failure of one hour at the site of the

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

6 Complexity

Market

MarketBatteryStorage

Power System

EnergyStorageBatteryStorage

Communication

MarketSolarGeneratingUnit

GeneratingUnitProduction

SolarGeneratingUnit

EquipmentMarketCogenerationUnit

ProductionCogenerationPlant

ModemsComMod

PowerSystemResourceRegulatingCondEq

EquipmentEquipment

Figure 2 Interdomain connections between classes of power sys-tem communication network and market

GeneratingUnitWindGeneratingUnit

ComMod

WirelessMod

LTEModem

01

communicationRequirement

WiredMod

FiberModemWiredInterface

FiberInt

WiredChannelFiberChannel

11

1

0lowast

1lowast

1

Figure 3 Communication network class association example

cost while required conditions are satisfied such as givenreliability metric An example of this approach is presentedin [18] for an integrated design of a wide area measurementsystem Eventually the optimized communication networksolution can be evaluated against different scenarios using thecosimulation environment

52 Model Data Processing and Simulation Setup The overallinformation flow for the simulation setup is depicted inFigure 4 After the topology is created or modified in agraphical Topology Builder and includes the three domainsthe input file which complies with the common data modelof Section 51 is sent to the cosimulation interface Thecosimulation interface incorporates a component basedon CIM++ [19] which parses the CIM XML-RDF fileand generates a container of C++ objects that containthe topological data In order to execute a simulationthe Modelica solver requires a Modelica model whereas

Modelica models

Power systemsimulation

Modelica (DymolaOpenModelica)

Topology builder

Extended CIM

Cosimulation interfacemosaik CIM++

Objects2ModelicaObjects2Comm Net

Block diagram oftopology

XML representationof topology

C++ objects amp simulatorspecific text formats

Communication networkPython objects topology

CommunicationMarket simulation simulationpython ns-3 etc

Figure 4 Overall architecture for simulation setup

the communication network topology can be given to thecommunication network simulator in JSON or XML for-mat which includes the components in the network theirconnections and parameters Since the topology will beavailable as an XML-RDF file and a container of C++objects the relevant information for the power system andcommunication network is extracted during a deserializationstep In the subsequent transformation step a componentwhich we call Objects2ModelicaCommunicationNetworkgenerates Modelica and communication network files withthe topology and parameters In contrast the Python basedmarket simulation relies on a C++Python interface whichcould be realized using one of the common libraries forPython to wrap C++ data types and functions to retrieve themarket relevant information from the C++ objects and storethem in Python objects

The following paragraph explains the translation on thebasis of a CIM to Modelica example The loads are definedin the extended CIM data model described in Section 51 asPQ-loads with a characteristic power demand as follows

ltcimSvPowerFlow rdfID=PQ1-svgtltcimSvPowerFlowpgt1000ltcimSvPowerFlowpgtltcimSvPowerFlowqgt329ltcimSvPowerFlowqgtltcimSvPowerFlowTerminal

rdfresource=E-1229789360gtltcimSvPowerFlowgt

The cosimulation interface extracts the corresponding com-ponent parameters from the CIM XML-RDF file and intro-duces them in the Modelica model of the grid The latteris done by the Objects2Modelica component explained inSection 52 which iterates through the list of C++ objects pro-vided by CIM++ Thus the specification of the parameters 119875and119876 in the CIMmodel generates two attributemodificationequations in the declaration of the PQ-load in Modelica

Complexity 7

ModPowerSystemsPhasorSinglePhaseLoads

PQLoad CIM PQ1 (Pnom = 1000 Qnom = 329)

These values are applied during the quasistationary simula-tion of the single-phase representation of the grid

53 Synchronization The synchronization of all three sim-ulators will be performed in fixed time steps Fixed syn-chronization time steps have been chosen because of theresulting flexibility to integrate more simulators easily and itscomparatively high speed in terms of time steps per simula-tion time [1] An event-driven approach as it is implementedin [10] for two simulators requires a deeper integration ofthe cosimulation framework and the simulators Apart fromthat it was shown in [10] that the cosimulation error can bereduced for fixed time steps by reducing the global time stepsize

The synchronization between all simulators for slowphenomena scenarios is performed with mosaik a well-established cosimulation framework [20] which was devel-oped for stationary simulations with time steps of one secondor greater [21] It allows combining the three simulators in asimple manner as explained in Section 54 VILLASnode asoftware project for coupling real-time simulations in LANs[22 23] is a suitable alternative for mosaik in the case ofsynchronizations with very short intervals

In Modelica the synchronization data exchange isachieved by integrating Modelica blocks of the ModelicaDeviceDrivers library which was originally developed forinterfacing device drivers to Modelica models This con-veniently allows the definition of a fixed interval for dataexchange Modelica DeviceDrivers were chosen instead ofthe FMI approach shown in [21] because it allows moreflexibility in picking the desired simulation variables andchoosing the required cosimulation step size independentlyfrom the Modelica simulator time step At synchronizationsteps between all simulators the step function of the energymarket simulator is called synchronously from the mosaikPython API After the market simulator has finished thesimulation step the results are retrieved by mosaik

The simulation time in the DES of the communicationnetwork advances with the execution of the generated eventswhich are stored in an event-list The execution of eventsis controlled by a scheduler which determines the nextevent and its execution time Whereas the default schedulerexecutes the events sequentially without any interruptionsthe available simulation environments offer the flexibility tointegrate external control inputs to receive external controlmessages which can be used to manipulate the simulationflow by changing the module parameters during the simula-tion In order to realize this the event-driven nature of DEStools can be used to generate new events called flow controlevents which stop the communication simulation exchangedata and use the input data to manipulate the followingsimulation steps Furthermore the execution of events canbe controlled and the simulation can be stopped after theexecution of the last event before a synchronization point sothat the simulation runs in fixed steps and a data exchange ispossible at the end of each step

Powersystem

Commnetwork

MarketEvent 0

Event 1

Powersystem

Commnetwork

MarketEvent 2

Event 3

Powersystem

Market

Individualsimulator steps

Cosimulation step

0

0

0

0

1

1 2

1 1

1

2

2

211

Figure 5 Synchronization scheme of simulators at cosimulationtime steps

Figure 5 depicts the flow of time for the cosimulationand each simulator It can be seen that the power system andmarket simulators compute in parallel whereas the commu-nicationnetwork iswaiting for their inputs In amathematicalnotation the interactions between the simulators in eachcosimulation step can be defined by

119906119901 (119899 + 1) = 119865119888 (119865119898 (119906119898 (119899)))

119906119898 (119899 + 1) = 119865119888 (119865119901 (119906119901 (119899))) (1)

where 119906119898 and 119906119901 are the corresponding input values ofthe simulators for the power system energy market andcommunication network for each time step Therefore it isrequired to set initial values 119906119901(0) 119906119898(0) at the beginningof the cosimulation 119899 denominates the current cosimulationtime step 119865119888 (communication) 119865119898 (market) and 119865119901 (powersystem) are the functions describing the calculation of thenext time step

54 Cosimulation Runtime Interaction In Figure 6 the cou-pling of the power system communication and market sim-ulator for their cosimulation runtime interaction is shown Inthe following we briefly introduce the individual parts of thecosimulation environment

(i) Mosaik as already mentioned mosaik is used forthe coordination during the synchronization stepsof several minutes (in simulation time) regarding allsimulators [24] mosaik has two different APIs forsimulator coupling It provides handlers for differentsimulator types allows modelling of different simula-tion scenarios and schedules the step-wise executionof the connected simulators with the aid of SimPy[25] The two mosaik APIs are

(a) the low-level API which uses common TCPIPnetwork sockets for exchanging messages en-capsulated in JSON an open-source and hu-man-readable data format

(b) the high-level API which can be directly usedby a simulator and communicate with mosaikthrough sockets but also handle their creationevents and message (de)serialization

8 Complexity

TCP sockets

Communicationsimulation

DESenvironment

(R)UDP sockets

(R)UDP sockets

VILLAS-node

Python environmentMarket

simulation

TCP sockets TCP sockets TCP sockets

TCP sockets

TCP socketsmosaik-

core

Slow phenomenacommunication

MODD server

ModelicaDeviceDrivers

Power systemsimulation

Modelicaenvironment

Fast phenomena communication

(R)U

DP

sock

ets

Mod

elic

aD

evic

eDriv

ers

Figure 6 Scheme of runtime interaction between cosimulationcomponents

(ii) Market simulator implemented in Python it canmake use of the high-level API as illustrated inFigure 6Theuse of the sockets allows the desired flex-ibility of running all simulators on different computersystems and environments

(iii) Communication network simulator based on avail-able DES tools their network simulation modules areextendedwith interprocess communication function-alities for JSON message exchange with mosaik

(iv) Power system simulator the integration of so-called TCPIP SendRecv IO blocks from ModelicaDeviceDrivers into the Modelica models allows theexchange of simulation data via sockets but in theform of Modelica variables as bitvectors instead ofJSON messages Therefore the MODD Server isimplemented

(v) MODD server it receives commands from the socketconnected with mosaik Based on these commandsit starts for example the power system simulator orreceives the bitstream from Modelica DeviceDriversand encapsulates it into JSON messages before trans-ferring them to mosaik Besides the synchronizationsteps controlled by mosaik there will be also morefine-grained synchronization steps of fractions of sec-onds between the power system and communicationnetwork simulator That is why a VILLASnode serveris included

Root-coordinator

Topcoordinator

subcoordinator

simulator simulator

simulatorC

MP

Figure 7 Cosimulation environment as a hierarchical simulator

(vi) VILLASnode instead of TCP (Transmission ControlProtocol) it makes use of UDP (User DatagramProtocol) sockets for data exchange between real-time simulators for which it was designedThe use ofUDP leads to less overhead and consequently to lowersynchronization time steps but with the disadvantageof an unreliable connectionOur solution for avoidingany datagram losses is the usage of Reliable UDP(RUDP) to keep a low overhead in comparison withTCP with the benefit of a reliable connection

55 DEVS Formalization As explained in Section 53 adiscrete time base is chosen for the synchronization betweenthe domain-specific simulators Therefore the simulatorscan be formalized by Discrete Time System Specifications(DTSS) Since the time steps are fixed the DTSS can besimulated by DEVS [17] The abstraction level of the DEVShas not been considered for the mosaik framework fordifferent reasons [26] and is not needed for the definitionof cosimulation scenarios Therefore a formal definition ofthe whole simulation as coupled DEVS is beyond the scopeof this paper However a so-called hierarchical simulatorfor the three atomic simulators 119875 119872 and 119862 (for energymarket and communication) is shown in Figure 7 as leavesof the hierarchical simulator (ie tree) [17] and describedin the following The root-coordinator sends an initializationmessage (119894 119905) which is propagated to all atomic simulators inthe tree at simulation start and initiates the simulation stepswith state transition messages (lowast 119905) The coordinators handlethe levels of coupled simulators up to the root of the treeThe scheduling of an event is performed by a (lowast 119905) messageforwarded by each receiver coordinator to its imminent childThe imminent child is the simulator which shall perform itsnext internal transition or the coordinator being the root ofthe subtree containing the simulator which performs the nextinternal transition

Complexity 9

In case of our cosimulation architecture the first (lowast 119905)message is forwarded by the top and the subcoordinatorto the first component in the event-list (here 119875 simulator)computing the new output 119910119875 = 120582(119904) and sending it as outputmessage (119910119875 119905) to the subcoordinator The subcoordinatorthen recognizes an internal coupling and therefore sends anx-message (119909119872 119905) with 119909119872 = 119885119875119872(119910119875) to the 119872 simulatorwhereby 119885119875119872 119884119875 rarr 119883119872 is the translation function fromthe output events of the 119875 simulator to the input events of the119872 simulator Although the computations of the119872 simulatorwithin the same transition donot dependon the output of the119875 simulator its output message (119910119872 119905) includes the output ofboth simulators This output is translated and forwarded bythe subcoordinator to its parent (top coordinator) becauseof the external coupling as output message (119910119873 119905) of thebelonging Discrete Event Specified Network (DEVN) After-wards the top coordinator translates the message to an inputmessage (119909119862 119905) of the119862 simulator which computes the outputof the whole cosimulation step This output is transformedby the top coordinator because of its internal coupling toan input message for the subcoordinator which translatesand sends the message down to the 119875 simulator because ofthe external input coupling and the next cosimulation stepbegins

An improvement of this formalization based on thehierarchical simulator could be accomplished by a formal-ization of the 119875 and 119872 simulator as a conservative paralleldiscrete event simulation [17] Nevertheless the describedcommunication pattern between the components of thehierarchical simulator shows that the chosen cosimulationsynchronization scheme depicted in Figure 5 is validwhen causality violations between the energy and marketsimulation within one time step of the cosimulation areavoided which is guaranteed for the considered simulationscenarios

56 Limitations Due to the communication overhead causedby the cosimulation environment the simulation time mightincrease significantly for large network sizes Currently real-time simulations are not possible but the available frameworkcan be extended for real-time and hardware-in-the-loopsimulations for example by using VILLASnode instead ofmosaik

Furthermore the synchronization step size cannot bechanged during simulation runtime whereas the domain-specific simulators support variable simulation time stepsTo enable a variable step size for an optimized cosimulationthrough more sophisticated algorithms modifications of themosaik framework would be necessary as it allows fixed timesteps onlyThe cosimulation flowmanaged by mosaik whichallows parallel and sequential progress of simulators mightintroduce inaccuracies in the simulation results with respectto the synchronization step size

Moreover the simulation of heterogeneous communi-cation networks and standards is possible However theabstraction level of the communication protocols influ-ences the simulation time of the communication networksimulator and thus the simulation time of the cosimu-lation

6 Verification of the Cosimulation Interfaces

In this section we aim to show that the implementedcosimulation infrastructure does not impair the accuracyof the simulation results As an exemplary application weconsider a scenario where a VPP operator aims at gainingprofits by reducing the VPPrsquos peak power Thus a peak-shaving algorithm is employed for an optimal managementof distributed battery storage systems Financial incentives forthe peak-shaving behavior might originate from agreementswithDSOs regarding themaximumpower feed-in of theVPPStarting from results without the cosimulation frameworkwe successively include the cosimulation environment anddomain-specific simulators to demonstrate that the results donot change under the assumption of an ideal communicationnetwork in the same scenario Eventually a slightly differentscenario is presented where the communication network issupposed to impair the control loop between the powersystem and themarket due to communication device failuresthereby showing an exemplary use case for the cosimulationarchitecture presented in this paper

61 Simulation Scenarios andModels The investigated powersystem is a part of the IEEE European Low Voltage TestFeeder The loads in the test feeder are replaced with build-ings each incorporating a PQ-load Furthermore severalof these buildings feature stationary batteries and solargeneration The battery storages are controlled by a peak-shaving algorithm which is implemented in the market sim-ulator The peak-shaving algorithm is supposed to representa VPP operator that utilizes its aggregated storage in a gridsupporting way That is why in a real world application itneeds to exchange measurement and control values with thebattery storages through the communication network

In the first simulation scenario the communicationbetween batteries and the peak-shaving algorithm is idealand not subject to any communication network failures Thisscenario is used to verify the correct exchange of simulationdata between the simulators involved in the cosimulationFor this reason the simulation is first executed withoutcosimulation framework connecting the peak-shaving algo-rithm directly to the power system simulation Then thecosimulation environment is introduced and afterwards thecommunication network simulatorThe results of these threesimulation cases are presented in Section 62

The second simulation scenario analyzed in Section 63features a communication network failure in order to show apossible use case of the complete cosimulation environment

The following equations are implemented in Modelicato simulate the power system components in the buildingsThe PQ-loads in the buildings are modelled as ideal constantpower loads which means that the load current is directlydependent on the voltage at the grid connection point

The implemented Modelica model of the solar generatordetermines the active power output 119875sg by

119875sg3 = 119881oc sdot 119868sc sdot 119865119865 sdot

119875sginst1198750

(2)

10 Complexity

under the assumption that the plant is operating at itsmaximum power point and where 119881oc and 119868sc are the open-circuit voltage and the short-circuit current respectivelyThey vary with temperature and solar radiation which can bemodelled according to [27] The term 119875sginst1198750 in (3) adaptsthe magnitude of the output power to the installed power ofa specific solar generating unit given that 1198750 represents theinstalled power of the solar panel used in [27]

The model of the battery storages consists of a simple setof equations describing the derivative of the state of charge(SOC) as

119889119889119905SOC =

120578ch119875119861119862119861

119875119861 ge 0

119875119861120578disch119862119861

119875119861 lt 0(3)

In addition the battery model limits the SOC to be in therange between zero and oneThe values specifying the batterycapacity 119862119861 the charging efficiency 120578ch and the dischargingefficiency 120578disch are extracted from the extended CIM classessee Section 51

The VPP algorithm aims at stabilizing the voltage profileby reducing the power exchange between the grid andthe buildings using a model predictive control approachTherefore the battery charging power 119875119861 is set according toan optimal scheduling which is based on forecasts for solarradiation and load demand To compensate for inaccuraciesin the forecasts the algorithm receives measurements ofactual load demand generated solar power and battery stateof charge from the power system simulator

62 Comparison of Results with and without CosimulationEnvironment At first both measurements and set pointsare neither passed through the communication networksimulator nor the cosimulation framework Instead thecontrol signals for the battery storages are directly suppliedby the peak-shaving algorithm before each power systemsimulation step Following this reference case both simula-tors are connected through the cosimulation environment asdescribed in Section 54 Still the communication networksimulator is not involved The results depicted in Figure 8present the voltage profile over time at one node in thetest feeder and it can be seen that the results with andwithout the cosimulation environment are consistent If thecommunication network had altered the exchanged datacontrol values and measurements the voltage profile wouldhave changed Next we take this one step further andalso introduce the communication network simulator Thecommunication network simulator acts as mediator betweenthe power system and market simulators Any data that isexchanged between the power system and market has to passthrough the former The communication network simulatoris added to the cosimulation as presented in Sections 53and 54 To verify that the three simulators are synchronizedproperly we include an ideal communication network that isall messages are transmitted without any latencies Evidentlyan ideal communication should not affect the informationexchange between power system and market so that the

1003

1002

1001

1000

0999

0998

0997

Volta

ge (p

u)

Time (h)

Direct couplingmosaik coupling

24211815129630

Figure 8 Comparison of simulation results of power system andmarket with and reference case without cosimulation environment

No comm simulatorWith comm simulator

3 6 9 12 15 18 21 240

Time (h)

0997

0998

1000

1001

1002

1003Vo

ltage

(pu

)

0999

Figure 9 Comparison of simulation results with cosimulationenvironment and ideal communication network and reference casewithout cosimulation environment

implemented scheduling for battery charging should performequally

In Figure 9 it is visible that the simulation results incor-porating the ideal communication network do not deviatefrom the ones obtained without the communication networkeven though all messages are now passing through thecommunication network simulatorThus the results confirma correct synchronization of the three simulators and theconsistency of the implemented cosimulation environment

63 Exemplary Cosimulation with Communication NetworkFailure In this subsection the three simulators are exchang-ing data in the sameway as described at the end of Section 62Only this time the communication network simulator emu-lates a fault in the communication network which leadsto a communication failure of one hour at the site of the

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

Complexity 7

ModPowerSystemsPhasorSinglePhaseLoads

PQLoad CIM PQ1 (Pnom = 1000 Qnom = 329)

These values are applied during the quasistationary simula-tion of the single-phase representation of the grid

53 Synchronization The synchronization of all three sim-ulators will be performed in fixed time steps Fixed syn-chronization time steps have been chosen because of theresulting flexibility to integrate more simulators easily and itscomparatively high speed in terms of time steps per simula-tion time [1] An event-driven approach as it is implementedin [10] for two simulators requires a deeper integration ofthe cosimulation framework and the simulators Apart fromthat it was shown in [10] that the cosimulation error can bereduced for fixed time steps by reducing the global time stepsize

The synchronization between all simulators for slowphenomena scenarios is performed with mosaik a well-established cosimulation framework [20] which was devel-oped for stationary simulations with time steps of one secondor greater [21] It allows combining the three simulators in asimple manner as explained in Section 54 VILLASnode asoftware project for coupling real-time simulations in LANs[22 23] is a suitable alternative for mosaik in the case ofsynchronizations with very short intervals

In Modelica the synchronization data exchange isachieved by integrating Modelica blocks of the ModelicaDeviceDrivers library which was originally developed forinterfacing device drivers to Modelica models This con-veniently allows the definition of a fixed interval for dataexchange Modelica DeviceDrivers were chosen instead ofthe FMI approach shown in [21] because it allows moreflexibility in picking the desired simulation variables andchoosing the required cosimulation step size independentlyfrom the Modelica simulator time step At synchronizationsteps between all simulators the step function of the energymarket simulator is called synchronously from the mosaikPython API After the market simulator has finished thesimulation step the results are retrieved by mosaik

The simulation time in the DES of the communicationnetwork advances with the execution of the generated eventswhich are stored in an event-list The execution of eventsis controlled by a scheduler which determines the nextevent and its execution time Whereas the default schedulerexecutes the events sequentially without any interruptionsthe available simulation environments offer the flexibility tointegrate external control inputs to receive external controlmessages which can be used to manipulate the simulationflow by changing the module parameters during the simula-tion In order to realize this the event-driven nature of DEStools can be used to generate new events called flow controlevents which stop the communication simulation exchangedata and use the input data to manipulate the followingsimulation steps Furthermore the execution of events canbe controlled and the simulation can be stopped after theexecution of the last event before a synchronization point sothat the simulation runs in fixed steps and a data exchange ispossible at the end of each step

Powersystem

Commnetwork

MarketEvent 0

Event 1

Powersystem

Commnetwork

MarketEvent 2

Event 3

Powersystem

Market

Individualsimulator steps

Cosimulation step

0

0

0

0

1

1 2

1 1

1

2

2

211

Figure 5 Synchronization scheme of simulators at cosimulationtime steps

Figure 5 depicts the flow of time for the cosimulationand each simulator It can be seen that the power system andmarket simulators compute in parallel whereas the commu-nicationnetwork iswaiting for their inputs In amathematicalnotation the interactions between the simulators in eachcosimulation step can be defined by

119906119901 (119899 + 1) = 119865119888 (119865119898 (119906119898 (119899)))

119906119898 (119899 + 1) = 119865119888 (119865119901 (119906119901 (119899))) (1)

where 119906119898 and 119906119901 are the corresponding input values ofthe simulators for the power system energy market andcommunication network for each time step Therefore it isrequired to set initial values 119906119901(0) 119906119898(0) at the beginningof the cosimulation 119899 denominates the current cosimulationtime step 119865119888 (communication) 119865119898 (market) and 119865119901 (powersystem) are the functions describing the calculation of thenext time step

54 Cosimulation Runtime Interaction In Figure 6 the cou-pling of the power system communication and market sim-ulator for their cosimulation runtime interaction is shown Inthe following we briefly introduce the individual parts of thecosimulation environment

(i) Mosaik as already mentioned mosaik is used forthe coordination during the synchronization stepsof several minutes (in simulation time) regarding allsimulators [24] mosaik has two different APIs forsimulator coupling It provides handlers for differentsimulator types allows modelling of different simula-tion scenarios and schedules the step-wise executionof the connected simulators with the aid of SimPy[25] The two mosaik APIs are

(a) the low-level API which uses common TCPIPnetwork sockets for exchanging messages en-capsulated in JSON an open-source and hu-man-readable data format

(b) the high-level API which can be directly usedby a simulator and communicate with mosaikthrough sockets but also handle their creationevents and message (de)serialization

8 Complexity

TCP sockets

Communicationsimulation

DESenvironment

(R)UDP sockets

(R)UDP sockets

VILLAS-node

Python environmentMarket

simulation

TCP sockets TCP sockets TCP sockets

TCP sockets

TCP socketsmosaik-

core

Slow phenomenacommunication

MODD server

ModelicaDeviceDrivers

Power systemsimulation

Modelicaenvironment

Fast phenomena communication

(R)U

DP

sock

ets

Mod

elic

aD

evic

eDriv

ers

Figure 6 Scheme of runtime interaction between cosimulationcomponents

(ii) Market simulator implemented in Python it canmake use of the high-level API as illustrated inFigure 6Theuse of the sockets allows the desired flex-ibility of running all simulators on different computersystems and environments

(iii) Communication network simulator based on avail-able DES tools their network simulation modules areextendedwith interprocess communication function-alities for JSON message exchange with mosaik

(iv) Power system simulator the integration of so-called TCPIP SendRecv IO blocks from ModelicaDeviceDrivers into the Modelica models allows theexchange of simulation data via sockets but in theform of Modelica variables as bitvectors instead ofJSON messages Therefore the MODD Server isimplemented

(v) MODD server it receives commands from the socketconnected with mosaik Based on these commandsit starts for example the power system simulator orreceives the bitstream from Modelica DeviceDriversand encapsulates it into JSON messages before trans-ferring them to mosaik Besides the synchronizationsteps controlled by mosaik there will be also morefine-grained synchronization steps of fractions of sec-onds between the power system and communicationnetwork simulator That is why a VILLASnode serveris included

Root-coordinator

Topcoordinator

subcoordinator

simulator simulator

simulatorC

MP

Figure 7 Cosimulation environment as a hierarchical simulator

(vi) VILLASnode instead of TCP (Transmission ControlProtocol) it makes use of UDP (User DatagramProtocol) sockets for data exchange between real-time simulators for which it was designedThe use ofUDP leads to less overhead and consequently to lowersynchronization time steps but with the disadvantageof an unreliable connectionOur solution for avoidingany datagram losses is the usage of Reliable UDP(RUDP) to keep a low overhead in comparison withTCP with the benefit of a reliable connection

55 DEVS Formalization As explained in Section 53 adiscrete time base is chosen for the synchronization betweenthe domain-specific simulators Therefore the simulatorscan be formalized by Discrete Time System Specifications(DTSS) Since the time steps are fixed the DTSS can besimulated by DEVS [17] The abstraction level of the DEVShas not been considered for the mosaik framework fordifferent reasons [26] and is not needed for the definitionof cosimulation scenarios Therefore a formal definition ofthe whole simulation as coupled DEVS is beyond the scopeof this paper However a so-called hierarchical simulatorfor the three atomic simulators 119875 119872 and 119862 (for energymarket and communication) is shown in Figure 7 as leavesof the hierarchical simulator (ie tree) [17] and describedin the following The root-coordinator sends an initializationmessage (119894 119905) which is propagated to all atomic simulators inthe tree at simulation start and initiates the simulation stepswith state transition messages (lowast 119905) The coordinators handlethe levels of coupled simulators up to the root of the treeThe scheduling of an event is performed by a (lowast 119905) messageforwarded by each receiver coordinator to its imminent childThe imminent child is the simulator which shall perform itsnext internal transition or the coordinator being the root ofthe subtree containing the simulator which performs the nextinternal transition

Complexity 9

In case of our cosimulation architecture the first (lowast 119905)message is forwarded by the top and the subcoordinatorto the first component in the event-list (here 119875 simulator)computing the new output 119910119875 = 120582(119904) and sending it as outputmessage (119910119875 119905) to the subcoordinator The subcoordinatorthen recognizes an internal coupling and therefore sends anx-message (119909119872 119905) with 119909119872 = 119885119875119872(119910119875) to the 119872 simulatorwhereby 119885119875119872 119884119875 rarr 119883119872 is the translation function fromthe output events of the 119875 simulator to the input events of the119872 simulator Although the computations of the119872 simulatorwithin the same transition donot dependon the output of the119875 simulator its output message (119910119872 119905) includes the output ofboth simulators This output is translated and forwarded bythe subcoordinator to its parent (top coordinator) becauseof the external coupling as output message (119910119873 119905) of thebelonging Discrete Event Specified Network (DEVN) After-wards the top coordinator translates the message to an inputmessage (119909119862 119905) of the119862 simulator which computes the outputof the whole cosimulation step This output is transformedby the top coordinator because of its internal coupling toan input message for the subcoordinator which translatesand sends the message down to the 119875 simulator because ofthe external input coupling and the next cosimulation stepbegins

An improvement of this formalization based on thehierarchical simulator could be accomplished by a formal-ization of the 119875 and 119872 simulator as a conservative paralleldiscrete event simulation [17] Nevertheless the describedcommunication pattern between the components of thehierarchical simulator shows that the chosen cosimulationsynchronization scheme depicted in Figure 5 is validwhen causality violations between the energy and marketsimulation within one time step of the cosimulation areavoided which is guaranteed for the considered simulationscenarios

56 Limitations Due to the communication overhead causedby the cosimulation environment the simulation time mightincrease significantly for large network sizes Currently real-time simulations are not possible but the available frameworkcan be extended for real-time and hardware-in-the-loopsimulations for example by using VILLASnode instead ofmosaik

Furthermore the synchronization step size cannot bechanged during simulation runtime whereas the domain-specific simulators support variable simulation time stepsTo enable a variable step size for an optimized cosimulationthrough more sophisticated algorithms modifications of themosaik framework would be necessary as it allows fixed timesteps onlyThe cosimulation flowmanaged by mosaik whichallows parallel and sequential progress of simulators mightintroduce inaccuracies in the simulation results with respectto the synchronization step size

Moreover the simulation of heterogeneous communi-cation networks and standards is possible However theabstraction level of the communication protocols influ-ences the simulation time of the communication networksimulator and thus the simulation time of the cosimu-lation

6 Verification of the Cosimulation Interfaces

In this section we aim to show that the implementedcosimulation infrastructure does not impair the accuracyof the simulation results As an exemplary application weconsider a scenario where a VPP operator aims at gainingprofits by reducing the VPPrsquos peak power Thus a peak-shaving algorithm is employed for an optimal managementof distributed battery storage systems Financial incentives forthe peak-shaving behavior might originate from agreementswithDSOs regarding themaximumpower feed-in of theVPPStarting from results without the cosimulation frameworkwe successively include the cosimulation environment anddomain-specific simulators to demonstrate that the results donot change under the assumption of an ideal communicationnetwork in the same scenario Eventually a slightly differentscenario is presented where the communication network issupposed to impair the control loop between the powersystem and themarket due to communication device failuresthereby showing an exemplary use case for the cosimulationarchitecture presented in this paper

61 Simulation Scenarios andModels The investigated powersystem is a part of the IEEE European Low Voltage TestFeeder The loads in the test feeder are replaced with build-ings each incorporating a PQ-load Furthermore severalof these buildings feature stationary batteries and solargeneration The battery storages are controlled by a peak-shaving algorithm which is implemented in the market sim-ulator The peak-shaving algorithm is supposed to representa VPP operator that utilizes its aggregated storage in a gridsupporting way That is why in a real world application itneeds to exchange measurement and control values with thebattery storages through the communication network

In the first simulation scenario the communicationbetween batteries and the peak-shaving algorithm is idealand not subject to any communication network failures Thisscenario is used to verify the correct exchange of simulationdata between the simulators involved in the cosimulationFor this reason the simulation is first executed withoutcosimulation framework connecting the peak-shaving algo-rithm directly to the power system simulation Then thecosimulation environment is introduced and afterwards thecommunication network simulatorThe results of these threesimulation cases are presented in Section 62

The second simulation scenario analyzed in Section 63features a communication network failure in order to show apossible use case of the complete cosimulation environment

The following equations are implemented in Modelicato simulate the power system components in the buildingsThe PQ-loads in the buildings are modelled as ideal constantpower loads which means that the load current is directlydependent on the voltage at the grid connection point

The implemented Modelica model of the solar generatordetermines the active power output 119875sg by

119875sg3 = 119881oc sdot 119868sc sdot 119865119865 sdot

119875sginst1198750

(2)

10 Complexity

under the assumption that the plant is operating at itsmaximum power point and where 119881oc and 119868sc are the open-circuit voltage and the short-circuit current respectivelyThey vary with temperature and solar radiation which can bemodelled according to [27] The term 119875sginst1198750 in (3) adaptsthe magnitude of the output power to the installed power ofa specific solar generating unit given that 1198750 represents theinstalled power of the solar panel used in [27]

The model of the battery storages consists of a simple setof equations describing the derivative of the state of charge(SOC) as

119889119889119905SOC =

120578ch119875119861119862119861

119875119861 ge 0

119875119861120578disch119862119861

119875119861 lt 0(3)

In addition the battery model limits the SOC to be in therange between zero and oneThe values specifying the batterycapacity 119862119861 the charging efficiency 120578ch and the dischargingefficiency 120578disch are extracted from the extended CIM classessee Section 51

The VPP algorithm aims at stabilizing the voltage profileby reducing the power exchange between the grid andthe buildings using a model predictive control approachTherefore the battery charging power 119875119861 is set according toan optimal scheduling which is based on forecasts for solarradiation and load demand To compensate for inaccuraciesin the forecasts the algorithm receives measurements ofactual load demand generated solar power and battery stateof charge from the power system simulator

62 Comparison of Results with and without CosimulationEnvironment At first both measurements and set pointsare neither passed through the communication networksimulator nor the cosimulation framework Instead thecontrol signals for the battery storages are directly suppliedby the peak-shaving algorithm before each power systemsimulation step Following this reference case both simula-tors are connected through the cosimulation environment asdescribed in Section 54 Still the communication networksimulator is not involved The results depicted in Figure 8present the voltage profile over time at one node in thetest feeder and it can be seen that the results with andwithout the cosimulation environment are consistent If thecommunication network had altered the exchanged datacontrol values and measurements the voltage profile wouldhave changed Next we take this one step further andalso introduce the communication network simulator Thecommunication network simulator acts as mediator betweenthe power system and market simulators Any data that isexchanged between the power system and market has to passthrough the former The communication network simulatoris added to the cosimulation as presented in Sections 53and 54 To verify that the three simulators are synchronizedproperly we include an ideal communication network that isall messages are transmitted without any latencies Evidentlyan ideal communication should not affect the informationexchange between power system and market so that the

1003

1002

1001

1000

0999

0998

0997

Volta

ge (p

u)

Time (h)

Direct couplingmosaik coupling

24211815129630

Figure 8 Comparison of simulation results of power system andmarket with and reference case without cosimulation environment

No comm simulatorWith comm simulator

3 6 9 12 15 18 21 240

Time (h)

0997

0998

1000

1001

1002

1003Vo

ltage

(pu

)

0999

Figure 9 Comparison of simulation results with cosimulationenvironment and ideal communication network and reference casewithout cosimulation environment

implemented scheduling for battery charging should performequally

In Figure 9 it is visible that the simulation results incor-porating the ideal communication network do not deviatefrom the ones obtained without the communication networkeven though all messages are now passing through thecommunication network simulatorThus the results confirma correct synchronization of the three simulators and theconsistency of the implemented cosimulation environment

63 Exemplary Cosimulation with Communication NetworkFailure In this subsection the three simulators are exchang-ing data in the sameway as described at the end of Section 62Only this time the communication network simulator emu-lates a fault in the communication network which leadsto a communication failure of one hour at the site of the

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

8 Complexity

TCP sockets

Communicationsimulation

DESenvironment

(R)UDP sockets

(R)UDP sockets

VILLAS-node

Python environmentMarket

simulation

TCP sockets TCP sockets TCP sockets

TCP sockets

TCP socketsmosaik-

core

Slow phenomenacommunication

MODD server

ModelicaDeviceDrivers

Power systemsimulation

Modelicaenvironment

Fast phenomena communication

(R)U

DP

sock

ets

Mod

elic

aD

evic

eDriv

ers

Figure 6 Scheme of runtime interaction between cosimulationcomponents

(ii) Market simulator implemented in Python it canmake use of the high-level API as illustrated inFigure 6Theuse of the sockets allows the desired flex-ibility of running all simulators on different computersystems and environments

(iii) Communication network simulator based on avail-able DES tools their network simulation modules areextendedwith interprocess communication function-alities for JSON message exchange with mosaik

(iv) Power system simulator the integration of so-called TCPIP SendRecv IO blocks from ModelicaDeviceDrivers into the Modelica models allows theexchange of simulation data via sockets but in theform of Modelica variables as bitvectors instead ofJSON messages Therefore the MODD Server isimplemented

(v) MODD server it receives commands from the socketconnected with mosaik Based on these commandsit starts for example the power system simulator orreceives the bitstream from Modelica DeviceDriversand encapsulates it into JSON messages before trans-ferring them to mosaik Besides the synchronizationsteps controlled by mosaik there will be also morefine-grained synchronization steps of fractions of sec-onds between the power system and communicationnetwork simulator That is why a VILLASnode serveris included

Root-coordinator

Topcoordinator

subcoordinator

simulator simulator

simulatorC

MP

Figure 7 Cosimulation environment as a hierarchical simulator

(vi) VILLASnode instead of TCP (Transmission ControlProtocol) it makes use of UDP (User DatagramProtocol) sockets for data exchange between real-time simulators for which it was designedThe use ofUDP leads to less overhead and consequently to lowersynchronization time steps but with the disadvantageof an unreliable connectionOur solution for avoidingany datagram losses is the usage of Reliable UDP(RUDP) to keep a low overhead in comparison withTCP with the benefit of a reliable connection

55 DEVS Formalization As explained in Section 53 adiscrete time base is chosen for the synchronization betweenthe domain-specific simulators Therefore the simulatorscan be formalized by Discrete Time System Specifications(DTSS) Since the time steps are fixed the DTSS can besimulated by DEVS [17] The abstraction level of the DEVShas not been considered for the mosaik framework fordifferent reasons [26] and is not needed for the definitionof cosimulation scenarios Therefore a formal definition ofthe whole simulation as coupled DEVS is beyond the scopeof this paper However a so-called hierarchical simulatorfor the three atomic simulators 119875 119872 and 119862 (for energymarket and communication) is shown in Figure 7 as leavesof the hierarchical simulator (ie tree) [17] and describedin the following The root-coordinator sends an initializationmessage (119894 119905) which is propagated to all atomic simulators inthe tree at simulation start and initiates the simulation stepswith state transition messages (lowast 119905) The coordinators handlethe levels of coupled simulators up to the root of the treeThe scheduling of an event is performed by a (lowast 119905) messageforwarded by each receiver coordinator to its imminent childThe imminent child is the simulator which shall perform itsnext internal transition or the coordinator being the root ofthe subtree containing the simulator which performs the nextinternal transition

Complexity 9

In case of our cosimulation architecture the first (lowast 119905)message is forwarded by the top and the subcoordinatorto the first component in the event-list (here 119875 simulator)computing the new output 119910119875 = 120582(119904) and sending it as outputmessage (119910119875 119905) to the subcoordinator The subcoordinatorthen recognizes an internal coupling and therefore sends anx-message (119909119872 119905) with 119909119872 = 119885119875119872(119910119875) to the 119872 simulatorwhereby 119885119875119872 119884119875 rarr 119883119872 is the translation function fromthe output events of the 119875 simulator to the input events of the119872 simulator Although the computations of the119872 simulatorwithin the same transition donot dependon the output of the119875 simulator its output message (119910119872 119905) includes the output ofboth simulators This output is translated and forwarded bythe subcoordinator to its parent (top coordinator) becauseof the external coupling as output message (119910119873 119905) of thebelonging Discrete Event Specified Network (DEVN) After-wards the top coordinator translates the message to an inputmessage (119909119862 119905) of the119862 simulator which computes the outputof the whole cosimulation step This output is transformedby the top coordinator because of its internal coupling toan input message for the subcoordinator which translatesand sends the message down to the 119875 simulator because ofthe external input coupling and the next cosimulation stepbegins

An improvement of this formalization based on thehierarchical simulator could be accomplished by a formal-ization of the 119875 and 119872 simulator as a conservative paralleldiscrete event simulation [17] Nevertheless the describedcommunication pattern between the components of thehierarchical simulator shows that the chosen cosimulationsynchronization scheme depicted in Figure 5 is validwhen causality violations between the energy and marketsimulation within one time step of the cosimulation areavoided which is guaranteed for the considered simulationscenarios

56 Limitations Due to the communication overhead causedby the cosimulation environment the simulation time mightincrease significantly for large network sizes Currently real-time simulations are not possible but the available frameworkcan be extended for real-time and hardware-in-the-loopsimulations for example by using VILLASnode instead ofmosaik

Furthermore the synchronization step size cannot bechanged during simulation runtime whereas the domain-specific simulators support variable simulation time stepsTo enable a variable step size for an optimized cosimulationthrough more sophisticated algorithms modifications of themosaik framework would be necessary as it allows fixed timesteps onlyThe cosimulation flowmanaged by mosaik whichallows parallel and sequential progress of simulators mightintroduce inaccuracies in the simulation results with respectto the synchronization step size

Moreover the simulation of heterogeneous communi-cation networks and standards is possible However theabstraction level of the communication protocols influ-ences the simulation time of the communication networksimulator and thus the simulation time of the cosimu-lation

6 Verification of the Cosimulation Interfaces

In this section we aim to show that the implementedcosimulation infrastructure does not impair the accuracyof the simulation results As an exemplary application weconsider a scenario where a VPP operator aims at gainingprofits by reducing the VPPrsquos peak power Thus a peak-shaving algorithm is employed for an optimal managementof distributed battery storage systems Financial incentives forthe peak-shaving behavior might originate from agreementswithDSOs regarding themaximumpower feed-in of theVPPStarting from results without the cosimulation frameworkwe successively include the cosimulation environment anddomain-specific simulators to demonstrate that the results donot change under the assumption of an ideal communicationnetwork in the same scenario Eventually a slightly differentscenario is presented where the communication network issupposed to impair the control loop between the powersystem and themarket due to communication device failuresthereby showing an exemplary use case for the cosimulationarchitecture presented in this paper

61 Simulation Scenarios andModels The investigated powersystem is a part of the IEEE European Low Voltage TestFeeder The loads in the test feeder are replaced with build-ings each incorporating a PQ-load Furthermore severalof these buildings feature stationary batteries and solargeneration The battery storages are controlled by a peak-shaving algorithm which is implemented in the market sim-ulator The peak-shaving algorithm is supposed to representa VPP operator that utilizes its aggregated storage in a gridsupporting way That is why in a real world application itneeds to exchange measurement and control values with thebattery storages through the communication network

In the first simulation scenario the communicationbetween batteries and the peak-shaving algorithm is idealand not subject to any communication network failures Thisscenario is used to verify the correct exchange of simulationdata between the simulators involved in the cosimulationFor this reason the simulation is first executed withoutcosimulation framework connecting the peak-shaving algo-rithm directly to the power system simulation Then thecosimulation environment is introduced and afterwards thecommunication network simulatorThe results of these threesimulation cases are presented in Section 62

The second simulation scenario analyzed in Section 63features a communication network failure in order to show apossible use case of the complete cosimulation environment

The following equations are implemented in Modelicato simulate the power system components in the buildingsThe PQ-loads in the buildings are modelled as ideal constantpower loads which means that the load current is directlydependent on the voltage at the grid connection point

The implemented Modelica model of the solar generatordetermines the active power output 119875sg by

119875sg3 = 119881oc sdot 119868sc sdot 119865119865 sdot

119875sginst1198750

(2)

10 Complexity

under the assumption that the plant is operating at itsmaximum power point and where 119881oc and 119868sc are the open-circuit voltage and the short-circuit current respectivelyThey vary with temperature and solar radiation which can bemodelled according to [27] The term 119875sginst1198750 in (3) adaptsthe magnitude of the output power to the installed power ofa specific solar generating unit given that 1198750 represents theinstalled power of the solar panel used in [27]

The model of the battery storages consists of a simple setof equations describing the derivative of the state of charge(SOC) as

119889119889119905SOC =

120578ch119875119861119862119861

119875119861 ge 0

119875119861120578disch119862119861

119875119861 lt 0(3)

In addition the battery model limits the SOC to be in therange between zero and oneThe values specifying the batterycapacity 119862119861 the charging efficiency 120578ch and the dischargingefficiency 120578disch are extracted from the extended CIM classessee Section 51

The VPP algorithm aims at stabilizing the voltage profileby reducing the power exchange between the grid andthe buildings using a model predictive control approachTherefore the battery charging power 119875119861 is set according toan optimal scheduling which is based on forecasts for solarradiation and load demand To compensate for inaccuraciesin the forecasts the algorithm receives measurements ofactual load demand generated solar power and battery stateof charge from the power system simulator

62 Comparison of Results with and without CosimulationEnvironment At first both measurements and set pointsare neither passed through the communication networksimulator nor the cosimulation framework Instead thecontrol signals for the battery storages are directly suppliedby the peak-shaving algorithm before each power systemsimulation step Following this reference case both simula-tors are connected through the cosimulation environment asdescribed in Section 54 Still the communication networksimulator is not involved The results depicted in Figure 8present the voltage profile over time at one node in thetest feeder and it can be seen that the results with andwithout the cosimulation environment are consistent If thecommunication network had altered the exchanged datacontrol values and measurements the voltage profile wouldhave changed Next we take this one step further andalso introduce the communication network simulator Thecommunication network simulator acts as mediator betweenthe power system and market simulators Any data that isexchanged between the power system and market has to passthrough the former The communication network simulatoris added to the cosimulation as presented in Sections 53and 54 To verify that the three simulators are synchronizedproperly we include an ideal communication network that isall messages are transmitted without any latencies Evidentlyan ideal communication should not affect the informationexchange between power system and market so that the

1003

1002

1001

1000

0999

0998

0997

Volta

ge (p

u)

Time (h)

Direct couplingmosaik coupling

24211815129630

Figure 8 Comparison of simulation results of power system andmarket with and reference case without cosimulation environment

No comm simulatorWith comm simulator

3 6 9 12 15 18 21 240

Time (h)

0997

0998

1000

1001

1002

1003Vo

ltage

(pu

)

0999

Figure 9 Comparison of simulation results with cosimulationenvironment and ideal communication network and reference casewithout cosimulation environment

implemented scheduling for battery charging should performequally

In Figure 9 it is visible that the simulation results incor-porating the ideal communication network do not deviatefrom the ones obtained without the communication networkeven though all messages are now passing through thecommunication network simulatorThus the results confirma correct synchronization of the three simulators and theconsistency of the implemented cosimulation environment

63 Exemplary Cosimulation with Communication NetworkFailure In this subsection the three simulators are exchang-ing data in the sameway as described at the end of Section 62Only this time the communication network simulator emu-lates a fault in the communication network which leadsto a communication failure of one hour at the site of the

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

Complexity 9

In case of our cosimulation architecture the first (lowast 119905)message is forwarded by the top and the subcoordinatorto the first component in the event-list (here 119875 simulator)computing the new output 119910119875 = 120582(119904) and sending it as outputmessage (119910119875 119905) to the subcoordinator The subcoordinatorthen recognizes an internal coupling and therefore sends anx-message (119909119872 119905) with 119909119872 = 119885119875119872(119910119875) to the 119872 simulatorwhereby 119885119875119872 119884119875 rarr 119883119872 is the translation function fromthe output events of the 119875 simulator to the input events of the119872 simulator Although the computations of the119872 simulatorwithin the same transition donot dependon the output of the119875 simulator its output message (119910119872 119905) includes the output ofboth simulators This output is translated and forwarded bythe subcoordinator to its parent (top coordinator) becauseof the external coupling as output message (119910119873 119905) of thebelonging Discrete Event Specified Network (DEVN) After-wards the top coordinator translates the message to an inputmessage (119909119862 119905) of the119862 simulator which computes the outputof the whole cosimulation step This output is transformedby the top coordinator because of its internal coupling toan input message for the subcoordinator which translatesand sends the message down to the 119875 simulator because ofthe external input coupling and the next cosimulation stepbegins

An improvement of this formalization based on thehierarchical simulator could be accomplished by a formal-ization of the 119875 and 119872 simulator as a conservative paralleldiscrete event simulation [17] Nevertheless the describedcommunication pattern between the components of thehierarchical simulator shows that the chosen cosimulationsynchronization scheme depicted in Figure 5 is validwhen causality violations between the energy and marketsimulation within one time step of the cosimulation areavoided which is guaranteed for the considered simulationscenarios

56 Limitations Due to the communication overhead causedby the cosimulation environment the simulation time mightincrease significantly for large network sizes Currently real-time simulations are not possible but the available frameworkcan be extended for real-time and hardware-in-the-loopsimulations for example by using VILLASnode instead ofmosaik

Furthermore the synchronization step size cannot bechanged during simulation runtime whereas the domain-specific simulators support variable simulation time stepsTo enable a variable step size for an optimized cosimulationthrough more sophisticated algorithms modifications of themosaik framework would be necessary as it allows fixed timesteps onlyThe cosimulation flowmanaged by mosaik whichallows parallel and sequential progress of simulators mightintroduce inaccuracies in the simulation results with respectto the synchronization step size

Moreover the simulation of heterogeneous communi-cation networks and standards is possible However theabstraction level of the communication protocols influ-ences the simulation time of the communication networksimulator and thus the simulation time of the cosimu-lation

6 Verification of the Cosimulation Interfaces

In this section we aim to show that the implementedcosimulation infrastructure does not impair the accuracyof the simulation results As an exemplary application weconsider a scenario where a VPP operator aims at gainingprofits by reducing the VPPrsquos peak power Thus a peak-shaving algorithm is employed for an optimal managementof distributed battery storage systems Financial incentives forthe peak-shaving behavior might originate from agreementswithDSOs regarding themaximumpower feed-in of theVPPStarting from results without the cosimulation frameworkwe successively include the cosimulation environment anddomain-specific simulators to demonstrate that the results donot change under the assumption of an ideal communicationnetwork in the same scenario Eventually a slightly differentscenario is presented where the communication network issupposed to impair the control loop between the powersystem and themarket due to communication device failuresthereby showing an exemplary use case for the cosimulationarchitecture presented in this paper

61 Simulation Scenarios andModels The investigated powersystem is a part of the IEEE European Low Voltage TestFeeder The loads in the test feeder are replaced with build-ings each incorporating a PQ-load Furthermore severalof these buildings feature stationary batteries and solargeneration The battery storages are controlled by a peak-shaving algorithm which is implemented in the market sim-ulator The peak-shaving algorithm is supposed to representa VPP operator that utilizes its aggregated storage in a gridsupporting way That is why in a real world application itneeds to exchange measurement and control values with thebattery storages through the communication network

In the first simulation scenario the communicationbetween batteries and the peak-shaving algorithm is idealand not subject to any communication network failures Thisscenario is used to verify the correct exchange of simulationdata between the simulators involved in the cosimulationFor this reason the simulation is first executed withoutcosimulation framework connecting the peak-shaving algo-rithm directly to the power system simulation Then thecosimulation environment is introduced and afterwards thecommunication network simulatorThe results of these threesimulation cases are presented in Section 62

The second simulation scenario analyzed in Section 63features a communication network failure in order to show apossible use case of the complete cosimulation environment

The following equations are implemented in Modelicato simulate the power system components in the buildingsThe PQ-loads in the buildings are modelled as ideal constantpower loads which means that the load current is directlydependent on the voltage at the grid connection point

The implemented Modelica model of the solar generatordetermines the active power output 119875sg by

119875sg3 = 119881oc sdot 119868sc sdot 119865119865 sdot

119875sginst1198750

(2)

10 Complexity

under the assumption that the plant is operating at itsmaximum power point and where 119881oc and 119868sc are the open-circuit voltage and the short-circuit current respectivelyThey vary with temperature and solar radiation which can bemodelled according to [27] The term 119875sginst1198750 in (3) adaptsthe magnitude of the output power to the installed power ofa specific solar generating unit given that 1198750 represents theinstalled power of the solar panel used in [27]

The model of the battery storages consists of a simple setof equations describing the derivative of the state of charge(SOC) as

119889119889119905SOC =

120578ch119875119861119862119861

119875119861 ge 0

119875119861120578disch119862119861

119875119861 lt 0(3)

In addition the battery model limits the SOC to be in therange between zero and oneThe values specifying the batterycapacity 119862119861 the charging efficiency 120578ch and the dischargingefficiency 120578disch are extracted from the extended CIM classessee Section 51

The VPP algorithm aims at stabilizing the voltage profileby reducing the power exchange between the grid andthe buildings using a model predictive control approachTherefore the battery charging power 119875119861 is set according toan optimal scheduling which is based on forecasts for solarradiation and load demand To compensate for inaccuraciesin the forecasts the algorithm receives measurements ofactual load demand generated solar power and battery stateof charge from the power system simulator

62 Comparison of Results with and without CosimulationEnvironment At first both measurements and set pointsare neither passed through the communication networksimulator nor the cosimulation framework Instead thecontrol signals for the battery storages are directly suppliedby the peak-shaving algorithm before each power systemsimulation step Following this reference case both simula-tors are connected through the cosimulation environment asdescribed in Section 54 Still the communication networksimulator is not involved The results depicted in Figure 8present the voltage profile over time at one node in thetest feeder and it can be seen that the results with andwithout the cosimulation environment are consistent If thecommunication network had altered the exchanged datacontrol values and measurements the voltage profile wouldhave changed Next we take this one step further andalso introduce the communication network simulator Thecommunication network simulator acts as mediator betweenthe power system and market simulators Any data that isexchanged between the power system and market has to passthrough the former The communication network simulatoris added to the cosimulation as presented in Sections 53and 54 To verify that the three simulators are synchronizedproperly we include an ideal communication network that isall messages are transmitted without any latencies Evidentlyan ideal communication should not affect the informationexchange between power system and market so that the

1003

1002

1001

1000

0999

0998

0997

Volta

ge (p

u)

Time (h)

Direct couplingmosaik coupling

24211815129630

Figure 8 Comparison of simulation results of power system andmarket with and reference case without cosimulation environment

No comm simulatorWith comm simulator

3 6 9 12 15 18 21 240

Time (h)

0997

0998

1000

1001

1002

1003Vo

ltage

(pu

)

0999

Figure 9 Comparison of simulation results with cosimulationenvironment and ideal communication network and reference casewithout cosimulation environment

implemented scheduling for battery charging should performequally

In Figure 9 it is visible that the simulation results incor-porating the ideal communication network do not deviatefrom the ones obtained without the communication networkeven though all messages are now passing through thecommunication network simulatorThus the results confirma correct synchronization of the three simulators and theconsistency of the implemented cosimulation environment

63 Exemplary Cosimulation with Communication NetworkFailure In this subsection the three simulators are exchang-ing data in the sameway as described at the end of Section 62Only this time the communication network simulator emu-lates a fault in the communication network which leadsto a communication failure of one hour at the site of the

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

10 Complexity

under the assumption that the plant is operating at itsmaximum power point and where 119881oc and 119868sc are the open-circuit voltage and the short-circuit current respectivelyThey vary with temperature and solar radiation which can bemodelled according to [27] The term 119875sginst1198750 in (3) adaptsthe magnitude of the output power to the installed power ofa specific solar generating unit given that 1198750 represents theinstalled power of the solar panel used in [27]

The model of the battery storages consists of a simple setof equations describing the derivative of the state of charge(SOC) as

119889119889119905SOC =

120578ch119875119861119862119861

119875119861 ge 0

119875119861120578disch119862119861

119875119861 lt 0(3)

In addition the battery model limits the SOC to be in therange between zero and oneThe values specifying the batterycapacity 119862119861 the charging efficiency 120578ch and the dischargingefficiency 120578disch are extracted from the extended CIM classessee Section 51

The VPP algorithm aims at stabilizing the voltage profileby reducing the power exchange between the grid andthe buildings using a model predictive control approachTherefore the battery charging power 119875119861 is set according toan optimal scheduling which is based on forecasts for solarradiation and load demand To compensate for inaccuraciesin the forecasts the algorithm receives measurements ofactual load demand generated solar power and battery stateof charge from the power system simulator

62 Comparison of Results with and without CosimulationEnvironment At first both measurements and set pointsare neither passed through the communication networksimulator nor the cosimulation framework Instead thecontrol signals for the battery storages are directly suppliedby the peak-shaving algorithm before each power systemsimulation step Following this reference case both simula-tors are connected through the cosimulation environment asdescribed in Section 54 Still the communication networksimulator is not involved The results depicted in Figure 8present the voltage profile over time at one node in thetest feeder and it can be seen that the results with andwithout the cosimulation environment are consistent If thecommunication network had altered the exchanged datacontrol values and measurements the voltage profile wouldhave changed Next we take this one step further andalso introduce the communication network simulator Thecommunication network simulator acts as mediator betweenthe power system and market simulators Any data that isexchanged between the power system and market has to passthrough the former The communication network simulatoris added to the cosimulation as presented in Sections 53and 54 To verify that the three simulators are synchronizedproperly we include an ideal communication network that isall messages are transmitted without any latencies Evidentlyan ideal communication should not affect the informationexchange between power system and market so that the

1003

1002

1001

1000

0999

0998

0997

Volta

ge (p

u)

Time (h)

Direct couplingmosaik coupling

24211815129630

Figure 8 Comparison of simulation results of power system andmarket with and reference case without cosimulation environment

No comm simulatorWith comm simulator

3 6 9 12 15 18 21 240

Time (h)

0997

0998

1000

1001

1002

1003Vo

ltage

(pu

)

0999

Figure 9 Comparison of simulation results with cosimulationenvironment and ideal communication network and reference casewithout cosimulation environment

implemented scheduling for battery charging should performequally

In Figure 9 it is visible that the simulation results incor-porating the ideal communication network do not deviatefrom the ones obtained without the communication networkeven though all messages are now passing through thecommunication network simulatorThus the results confirma correct synchronization of the three simulators and theconsistency of the implemented cosimulation environment

63 Exemplary Cosimulation with Communication NetworkFailure In this subsection the three simulators are exchang-ing data in the sameway as described at the end of Section 62Only this time the communication network simulator emu-lates a fault in the communication network which leadsto a communication failure of one hour at the site of the

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

Complexity 11

Ideal commComm fault

3 6 9 12 15 18 21 240

Time (h)

0000

0005

0010

0015

0020

0025

0030

＋０）

Figure 10 Comparison of voltage KPI for cosimulation with andwithout communication network fault

VPP control algorithmThis represents slow phenomena casewhere the loop between power system and market simulatoris affected

To assess the impact of the communication fault on thewhole network section a voltage key performance indicator(KPI) as defined in (4) is applied to the results

KPIV =1119873 sdot sum119894isinN

10038161003816100381610038161003816100381610038161003816V119894 minus 1ΔVmax

10038161003816100381610038161003816100381610038161003816 (4)

Here119873 is the number of considered voltage nodes V119894 denotesthe voltage at one node in per unit andΔVmax is themaximumallowed voltage deviation Thus the KPI is representing theaverage absolute deviation at all network nodes in relationto the maximum allowed deviation Figure 10 shows that acommunication failure between hours five and six clearlyaffects the voltage profile of the power systemThe applicationof the latest control values during the communication failureresults in a charging of the batteries while after the faultclearance the reactivated control discharges the batteriesagain Hence the entire battery capacity is being madeavailable again for peak-shaving during themidday timeDueto the compensation behavior the system returns back to astate with completely discharged batteries and consequentlythe same voltage profile as for ideal communication occurssome time after the fault By modifying the communicationnetwork simulator input it is also possible to emulate otherfaults such as faults at single buildings or package loss

The applied market simulator focuses on the representa-tion of VPP operators which manage as market participantstheir assets in a peak-shavingmanner based onmathematicaloptimizationThe operators schedulingmay additionally takeinto account price trends at wholesale markets for examplegiven as historical time series An enhanced considerationof market dynamics can be obtained by an agent-based sim-ulation of market participants and customers for examplecarried out with the Power TAC platform [11] integrated withthe market simulator

7 Conclusion

The contributions of this paper are a data model that includesthree domains power system communication network andmarket and the architecture of a software environmentto simulate multidomain scenarios for smart grids Theproposed data model facilitates the use of the software envi-ronment since the domain-specific smart grid componentparameters and their interconnections can be modified andstored in a self-contained topology description Due to ourcosimulation approach we are able to take advantage ofestablished domain-specific simulators for each domain Theproposed cosimulation environment covers use cases whichare commonly investigated in literature and relate to powersystems in conjunction with communication networks anduse cases including the former two domains and the marketSimulation results of our cosimulation environment accord-ing to the proposed architecture confirm the consistency ofthe approach

Conflicts of Interest

The authors declare that they have no conflicts of interest

Acknowledgments

The authors gratefully acknowledge the financial support forthis project by BMBF (GermanFederalMinistry of Educationand Research) under Promotional Reference 03EK3567B

References

[1] W Li M Ferdowsi M Stevic A Monti and F Ponci ldquoCosim-ulation for smart grid communicationsrdquo IEEE Transactions onIndustrial Informatics vol 10 no 4 pp 2374ndash2384 2014

[2] Z Wang and Y He ldquoTwo-stage optimal demand response withbattery energy storage systemsrdquo IET Generation Transmissionamp Distribution vol 10 no 5 pp 1286ndash1293 2016

[3] L Exel F Felgner and G Frey ldquoMulti-domain modeling ofdistributed energy systems-The MOCES approachrdquo in SmartGrid Communications (SmartGridComm) IEEE InternationalConference pp 774ndash779 USA November 2015

[4] M Uslar M Specht S Rohjans J Trefke and J M VasquezGonzalez The Common Information Model CIM IEC 6196861970 and 62325-A practical introduction to the CIM SpringerScience amp Business Media 2012

[5] CEN-CENELEC-ETSI Smart Grid Coordination GroupldquoSmart grid reference architecturerdquo (Accessed on 030102018)[Online] Available httpseceuropaeuenergysitesenerfilesdocumentsxpert group1 reference architecturepdf Nov2012

[6] E Haq D Haller K A Rahman and B Iverson ldquoUse ofCommon Information Model (CIM) in electricity market atCalifornia ISOrdquo in Power and Energy Society General MeetingIEEE pp 1ndash6 2011

[7] J Fremont E Lambert C Bouquet O Carre D Ilhat andP Metayer ldquoCIM extensions for ERDF information systemprojectsrdquo in Power amp Energy Society General Meeting PESrsquo09IEEE July 2009

12 Complexity

[8] K Hopkinson X Wang R Giovanini J Thorp K Birman andD Coury ldquoEPOCHS A platform for agent-based electric powerand communication simulation built from commercial off-the-shelf componentsrdquo IEEE Transactions on Power Systems vol 21no 2 pp 548ndash558 2006

[9] K Zhu M Chenine and L Nordstrom ldquoICT architectureimpact on wide area monitoring and control systemsrsquo reliabil-ityrdquo IEEE Transactions on Power Delivery vol 26 no 4 pp2801ndash2808 2011

[10] H Lin S S Veda S S Shukla L Mili and J Thorp ldquoGECOGlobal event-driven co-simulation framework for intercon-nected power system and communication networkrdquo IEEETransactions on Smart Grid vol 3 no 3 pp 1444ndash1456 2012

[11] W Ketter J Collins and P Reddy ldquoPower TAC A competi-tive economic simulation of the smart gridrdquo [Online] AvailablehttplinkinghubelseviercomretrievepiiS0140988313000959vol 39 pp 262ndash270 2013

[12] F Schloegl S Rohjans S Lehnhoff J Velasquez C Steinbrinkand P Palensky ldquoTowards a classification scheme for co-simulation approaches in energy systemsrdquo in Smart ElectricDistribution Systems and Technologies (EDST) InternationalSymposium on IEEE pp 516ndash521 September 2015

[13] C Molitor S Gross J Zeitz and A Monti ldquoMESCOS-A mul-tienergy system cosimulator for city district energy systemsrdquoIEEE Transactions on Industrial Informatics vol 10 no 4 pp2247ndash2256 2014

[14] M Mirz L Netze and A Monti ldquoA multi-level approach topower system Modelica modelsrdquo in Control and Modeling forPower Electronics (COMPEL) 2016 IEEE 17th Workshop onIEEE pp 1ndash7 2016

[15] K Wehrle M Gunes J Gross and M Gunes Modeling andtools for network simulation Springer Science and BusinessMedia 2010

[16] W E Hart J-P Watson and D L Woodruff Pyomo-opti-mization modeling in python vol 67 Springer 2012

[17] B P Zeigler H Praehofer and T G Kim Theory of modelingand simulation integrating discrete event and continuous com-plex dynamic systems Academic press 2000

[18] H A Tokel G Alirezaei and R Mathar ldquoIntegrated networkdesign for measurement and communication infrastructures insmart gridsrdquo in Proceedings of the 26th International Telecom-munication Networks and Applications Conference ITNAC 2016pp 258ndash264 Dunedin New Zealand December 2016

[19] L Razik M Mirz D Knibbe S Lankes and A Monti ldquoAuto-mated deserializer generation from CIM ontologies CIM++aneasy-to-use and automated adaptable open-source library forobject deserialization in C++ from documents based on user-specified UML models following the Common InformationModel (CIM) standards for the energy sectorrdquoComputer Science- Research and Development pp 1ndash11 2017

[20] S Schutte S Scherfke andM Troschel ldquoMosaik A frameworkfor modular simulation of active components in Smart Gridsrdquoin Proceedings of the IEEE 1st International Workshop on SmartGrid Modeling and Simulation SGMS 2011 pp 55ndash60 October2011

[21] S Rohjans EWidlWMuller S Schutte and S Lehnhoff ldquoCo-Simulation of complex energy systems with mosaik and FMIrdquoAt - Automatisierungstechnik vol 62 no 5 pp 325ndash336 2014

[22] S Vogel M Mirz L Razik and A Monti ldquoAn open solutionfor next-generation real-time power system simulationrdquo inProceedings of the IEEE Conference on Energy Internet andEnergy System Integration (EI2) pp 1ndash6 Nov 2017

[23] M Stevic A Estebsari S Vogel et al ldquoMulti-site Europeanframework for real-time co-simulation of power systems IETGenerationrdquo Transmission Distribution 2017

[24] (Accessed 2016-08-18) mosaik documentation ndashrelease 230[Online] Available httpsmediareadthedocsorgpdfmo-saiklatestmosaikpdf

[25] (Accessed 2016-08-18) Simpy documentation ndashrelease 309[Online] Available httpsmediareadthedocsorgpdfsimpylatestsimpypdf

[26] S Schutte S Scherfke and M Sonnenschein ldquoMosaik -Smart grid simulation API Toward a semantic based standardfor interchanging smart grid simulationsrdquo in Proceedings ofSMARTGREENS pp 14ndash24 April 2012

[27] W Zhou H Yang and Z Fang ldquoA novel model for photovoltaicarray performance predictionrdquo Applied Energy vol 84 no 12pp 1187ndash1198 2007

Hindawiwwwhindawicom Volume 2018

MathematicsJournal of

Hindawiwwwhindawicom Volume 2018

Mathematical Problems in Engineering

Applied MathematicsJournal of

Hindawiwwwhindawicom Volume 2018

Probability and StatisticsHindawiwwwhindawicom Volume 2018

Journal of

Hindawiwwwhindawicom Volume 2018

Mathematical PhysicsAdvances in

Complex AnalysisJournal of

Hindawiwwwhindawicom Volume 2018

OptimizationJournal of

Hindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom Volume 2018

Engineering Mathematics

International Journal of

Hindawiwwwhindawicom Volume 2018

Operations ResearchAdvances in

Journal of

Hindawiwwwhindawicom Volume 2018

Function SpacesAbstract and Applied AnalysisHindawiwwwhindawicom Volume 2018

International Journal of Mathematics and Mathematical Sciences

Hindawiwwwhindawicom Volume 2018

Hindawi Publishing Corporation httpwwwhindawicom Volume 2013Hindawiwwwhindawicom

The Scientific World Journal

Volume 2018

Hindawiwwwhindawicom Volume 2018Volume 2018

Numerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisNumerical AnalysisAdvances inAdvances in Discrete Dynamics in

Nature and SocietyHindawiwwwhindawicom Volume 2018

Hindawiwwwhindawicom

Dierential EquationsInternational Journal of

Volume 2018

Hindawiwwwhindawicom Volume 2018

Decision SciencesAdvances in

Hindawiwwwhindawicom Volume 2018

AnalysisInternational Journal of

Hindawiwwwhindawicom Volume 2018

Stochastic AnalysisInternational Journal of

Submit your manuscripts atwwwhindawicom