The CPES co-simulation framework MOSAIK has been developed especially with two major principles in mind: the integration of black box simulators and flexible configuration of simulation setups. To realize this, MOSAIK provides a set of application programming interfaces (API). The so-called Component-API allows the integration of new simulation components into the co-simulation environment by providing a description model for the component’s variables as well as a set of interface functions. It is comparable to the Functional Mock-up Interface (FMI) standard (Blochwitz et al., 2011), but more simplified, specifying only the minimal set of functions a simulator needs to provide to participate in a co-simulation. For the creation of a complete co-simulation setup, MOSAIK provides the so-called Scenario-API. This Python library provides a slim set of commands that may be used to write a so-called scenario script that will initialize and configure the selected simulation components, connect them with one another based on the data they provide and expect, and execute the actual co-simulation process.
The VPP simulation is part of a methodology which has been developed at the Institute of Power Systems and Power Economics (IAEW) to determine the costs of flexibility provision for congestion management in distribution grids’ flexibility options, e. g. generation, demand and storage units. This methodology involves simulation of power generation dispatch, marketing of flexibility options, calculation of nodal generation and load situations, as well as consideration of grid restrictions. Within the PAVN co-simulation setup, however, only the power generation dispatch simulation is used to determine the power generation and consumption schedules in a rolling configuration. The VPP simulation thus provides DER schedules as output data and expects grid restriction information as input, which is used to recalculate the schedules for the next time step. Both, input as well as output data sets, are multi-dimensional. Therefore, the simulator has been implemented to accept and provide the data in the form of CSV files. The communication between MOSAIK and the VPP simulator uses the cloud computing service Sciebo. For each simulation time step, the VPP simulator uploads a file containing the schedules onto the Sciebo cloud and downloads a file with grid restrictions from it by means of the client-server software ownCloud (The ownCloud developers, 2018). The file name of each exchanged file consists of specifiers indicating the associated data (schedules or grid restrictions) and the currently simulated point in time as a string following a pre-defined time stamp format. This way, both MOSAIK and the VPP simulator can regularly check the Sciebo cloud for file names containing their expected data specifiers and time stamps. In other words, temporal synchronization of the remote VPP simulation with MOSAIK is established with synchronous file exchange via a shared folder on a web server.
The power system simulation is based on the Venios Energy Platform (VEP). It is based on the latest Microsoft technologies in the field of public- and private-cloud. Data management is achieved via a powerful NoSQL database. The VEP modules employed in the co-simulation provide the basic power flow calculation capability, which consists of a Newton Raphson module, the grid structure module as well as the models of attached consumers and providers. For more information on the concept of cloud-based power flow calculation see (Albrecht, 2014). The MOSAIK coupling has been implemented via a simple simulation state machine. State transitions and data transfer are realized via a JSON data structure that can be exchanged through a web socket channel. In contrast to the other presented interfaces, the MOSAIK-VEP coupling exchanges mostly scalar data values. However, more complex prognosis data is also integrated into the JSON exchange structures encoded as byte strings. VEP not only calculates the grid state for a triggered time step, but also runs the grids state estimation and flexibility calculation for the next several simulated hours. Triggering the simulation step by MOSAIK calls this module too. Afterwards the data is stored within the NoSQL database. The KDP access the stored data by calling a REST API. The same REST API is used within the field test setup of PAVN.
The communication and service platform, KDP, addresses the needs of intercompany cooperation in the energy transition context (e.g. (Expert Group 3 - Regular Recommendations for Smart Grids Deployment, 2013)). The transition to renewable energies requires the use of a plethora of new technologies and specialists that can bring the new technologies into operations and business. As a consequence, many specialists may be cooperating in different cooperation contexts and offer their services to each other. However, due to possibly daily changing partner requirements, interoperability of such services may be hard to achieve in planning and operation. The KDP is intended to solve the described problem. The platform can be installed on premise or used in the cloud, respectively. It is designed to integrate cooperation processes, communication, security, documentation and so forth in a reusable way and be extensible with arbitrary services for specific cooperation cases. Accordingly, the KDP consists of a basic platform as well as a number of services and adapters for the integration of companies’ internal systems. In Fig. 1 the KDP services in the given study are illustrated. The services employed for this application case are partly used for gathering and storing of information via the so-called CIM cache module. The Congestion detection module can be seen as an adapter to the previously discussed state estimation algorithm that is interfaced by the KDP system. The modules called here Congestion handling and Flex call represent services that distribute the calculated grid restrictions among participating DER and establish communication between them and the rest of the platform.
Despite the composite structure of the KDP, consisting of different modules, coupling with MOSAIK is realized via a single interface. Via this interface MOSAIK provides various data sets to the KDP. In field application, the platform would acquire this data from several services and interfaces in the energy system. In the co-simulation, however, the data is provided by simulators and partly given in different formats than required by the KDP. Therefore, some data mapping and formatting is implemented in the interface. This aspect is discussed in more detail in the next section. The overall data sets are strongly multi-dimensional so that data exchange is realized via CSV files that are placed in a shared folder structure, similar to the interfacing of the VPP simulator. However, since MOSAIK and the KDP are executed in the same computation infrastructure, no web server is needed in this case. As seen in Fig. 1, the KDP provides grid restriction data to MOSAIK while requiring DER schedules and power feed-in prognosis data from renewable energy resources. Furthermore, the platform requires acceptance notifications as an answer to the grid restrictions. This acceptance would be iteratively negotiated with the VPP in the field, but in the given co-simulation setup this is not possible since the employed VPP simulator does not support it. Therefore, a scenario has been established in which the provided grid restrictions are always accepted. The associated notification is directly constructed via the MOSAIK interface. One of the most crucial aspects of interfacing MOSAIK and the KDP is the time synchronization. The KDP has been developed for operation in real-time systems. Thus, it has been implemented to obtain time information from the system clock of its computation environment. This would lead to a setup that cannot be simulated faster or slower than real-time. In order to establish more temporal flexibility, the MOSAIK interface implements its own Network Time Protocol (NTP) server that provides the simulated point in time as a UTC-compliant time stamp. The KDP has been configured to synchronize with this server instead of its local system clock.