# Deliverable: D8.2 German Demonstrator –
Demonstration of congestion management using
market-based flexibility in the LV grid

Paul Kratsch, Helene Ask Uggla, David Brummund, Kseniia Sinitsyna,
Mahtab Kaffash, Evelyn Heylen, Pierre Crucifix, Louise Adam, Md Umar
Hashmi, Simon Nagels, et al.

► To cite this version:

Paul Kratsch, Helene Ask Uggla, David Brummund, Kseniia Sinitsyna, Mahtab Kaffash, et al. Deliverable: D8.2 German Demonstrator – Demonstration of congestion management using market-based flexibility in the LV grid. European Commission. 2023. hal-04232361

HAL Id: hal-04232361

https://hal.science/hal-04232361v1

Submitted on 9 Nov 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons CC BY 4.0 - Attribution - International License
MARKET ENABLING INTERFACE TO UNLOCK FLEXIBILITY SOLUTIONS FOR COST-EFFECTIVE MANAGEMENT OF SMARTER DISTRIBUTION GRIDS

## Deliverable: D8.2

German Demonstrator — Demonstration of congestion management using market-based flexibility in the LV grid

Specifications of test scenarios within the German Demonstrator

<figure><img src="image_2.png" /></figure>

This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 864334
Document

D8.2 Specifications of test scenarios within the German Demonstrator

Dissemination level

PU Public X

PP Restricted to other programme participants (including the Commission Services)

RE Restricted to a group specified by the consortium (including the Commission Services)

CO Confidential, only for members of the consortium (including the Commission Services)

<table><thead><tr><td>Author(s)</td><td>Institution</td><td>Contact (e-mail, phone)</td></tr></thead><tbody><tr><td>Gesa Milzer</td><td>NODES</td><td>gesa.milzer@NODESmarket.com</td></tr><tr><td>Paul Kratsch</td><td>E.ON</td><td>paul.kratsch@eon.com</td></tr><tr><td>Helene Ask Uggla</td><td>E.ON</td><td>helene.ask-uggla@eon.se</td></tr><tr><td>David Brummund</td><td>MNS</td><td>david.brummund@mitnetz-strom.de</td></tr><tr><td>Kseniia Sinitsyna</td><td>MNS</td><td>kseniia.sinitsyna@mitnetz-strom.de</td></tr><tr><td>Mahtab Kaffash</td><td>Centrica</td><td>mahtab.kaffash@centrica.com</td></tr><tr><td>Evelyn Heylen</td><td>Centrica</td><td>evelyn.heylen@centrica.com</td></tr><tr><td>Pierre Crucifix</td><td>N-SIDE</td><td>pcu@n-side.com</td></tr><tr><td>Louise Adam</td><td>N-SIDE</td><td>lad@n-side.com</td></tr><tr><td>Reinhilde D'hulst</td><td>VITO</td><td>Reinhilde.dhulst@vito.be</td></tr><tr><td>Md Umar Hashmi</td><td>KU Leuven</td><td>mdumar.hashmi@kuleuven.be</td></tr><tr><td>Simon Nagels</td><td>KU Leuven</td><td>simon.nagels@kuleuven.be</td></tr><tr><td>Gil Silva Sampaio</td><td>INESC TEC</td><td>gil.s.sampaio@inesctec.pt</td></tr></tbody></table>
<table><thead><tr><td>Key word</td><td>Demonstration</td></tr></thead><tbody><tr><td>Due Delivery Date</td><td>2023/06/30</td></tr><tr><td>Date of Delivery</td><td>2023/06/28</td></tr></tbody></table>

<table><thead><tr><td>Document version</td><td>Date</td><td>Change</td></tr></thead><tbody><tr><td>D8.2_V1</td><td>2023/05/31</td><td>1st draft for internal review</td></tr><tr><td>D8.2_V2</td><td>2023/06/08</td><td>First complete draft for official review</td></tr><tr><td>D8.2_V3</td><td>2022/06/28</td><td>Final version for submission</td></tr></tbody></table>

<table><thead><tr><td>Reviewers (Institution, Name)</td><td>Email</td><td>Validation date</td></tr></thead><tbody><tr><td>E-REDES Rita Mourão</td><td>ritalopes.mourao @e-redes.pt</td><td>2023/06/26</td></tr><tr><td>MIKRO Michał Konopiński</td><td>michal.konopinski@mikronika.com.pl</td><td>2023/06/26</td></tr></tbody></table>
# Table of Contents

<table><tr><td>TABLE OF CONTENTS</td><td>4</td></tr><tr><td>LIST OF ABBREVIATIONS</td><td>6</td></tr><tr><td>LIST OF TABLES</td><td>7</td></tr><tr><td>LIST OF FIGURES</td><td>8</td></tr><tr><td>EXECUTIVE SUMMARY</td><td>10</td></tr><tr><td>1. INTRODUCTION</td><td>11</td></tr><tr><td>1.1 BACKGROUND</td><td>11</td></tr><tr><td>1.2 APPLICABILITY AND LIMITATIONS</td><td>12</td></tr><tr><td>1.3 REPORT STRUCTURE</td><td>13</td></tr><tr><td>2. GENERAL OVERVIEW OF THE GERMAN DEMONSTRATOR</td><td>15</td></tr><tr><td>2.1 DEMO SITE CHARACTERISTICS</td><td>15</td></tr><tr><td>2.2 GRID SELECTION</td><td>15</td></tr><tr><td>2.3 MAPPING OF USE CASES AND KEY PERFORMANCE INDICATORS</td><td>16</td></tr><tr><td>2.3.1 Business Use Cases (BUC)</td><td>17</td></tr><tr><td>2.3.2 System Use Cases (SUC) of the German Demonstrator</td><td>18</td></tr><tr><td>2.3.3 Key Performance Indicators</td><td>19</td></tr><tr><td>3. FIELD TEST FRAMEWORK</td><td>21</td></tr><tr><td>3.1 SYSTEM ARCHITECTURE</td><td>21</td></tr><tr><td>3.1.1 Goals and objectives</td><td>21</td></tr><tr><td>3.1.2 Design principles</td><td>21</td></tr><tr><td>3.1.3 System Architecture: General Model</td><td>22</td></tr><tr><td>3.1.4 System Architecture: Dataflow</td><td>25</td></tr><tr><td>3.1.5 System Architecture: Internal View and Data Exchange</td><td>27</td></tr><tr><td>3.1.6 System Architecture: Calculation chain</td><td>29</td></tr><tr><td>3.2 INTERNAL AND EXTERNAL COMPONENTS OF THE CALCULATION CHAIN</td><td>30</td></tr><tr><td>3.2.1 Calculation Chain: Congestion Forecasting and Prevention Tool</td><td>31</td></tr><tr><td>3.2.2 Calculation Chain: Flexibility Needs Assessor</td><td>32</td></tr><tr><td>3.2.3 Calculation Chain: State Estimator</td><td>34</td></tr><tr><td>3.2.4 Calculation Chain: Optimal Bid Recommender</td><td>35</td></tr><tr><td>3.2.5 Calculation Chain: Market Platform</td><td>37</td></tr><tr><td>3.2.6 Calculation Chain: UMEI API</td><td>38</td></tr><tr><td>3.3 CUSTOMER ENGAGEMENT</td><td>39</td></tr><tr><td>3.3.1 Customer acquisition</td><td>39</td></tr></table>
<table><tr><td>Barriers</td><td>40</td></tr><tr><td>3.3.2 Mitigation Measures</td><td>41</td></tr><tr><td><b>4 FIELD TEST PROTOCOL</b></td><td><b>43</b></td></tr><tr><td>4.1 CONGESTION DETECTION AND FLEXIBILITY NEED QUANTIFICATION</td><td>43</td></tr><tr><td>4.1.1 The Pythia tool: Day-ahead LV Congestion Forecast and Asset Headroom calculation - VITO</td><td>43</td></tr><tr><td>4.1.1.1 Functional tests for input data correction</td><td>44</td></tr><tr><td>4.1.1.2 Including flexibility resources in the LV congestion forecast and headroom calculation</td><td>47</td></tr><tr><td>4.1.2 Day-ahead flexibility needs assessment tool development - KUL</td><td>49</td></tr><tr><td>4.1.2.1 DigSilent (DGS) Parser and scenario generation</td><td>50</td></tr><tr><td>4.1.2.2 Flexibility needs assessment (FNA)</td><td>50</td></tr><tr><td>4.1.2.3 Clustering and Zonal FNA</td><td>51</td></tr><tr><td>4.1.2.4 Docker implementation</td><td>51</td></tr><tr><td>4.1.2.5 Numerical results for MLq0096</td><td>52</td></tr><tr><td>4.1.2.6 Numerical results for MFn4420</td><td>54</td></tr><tr><td>4.1.3 Data-driven State Estimator (DdSE) - INESC</td><td>56</td></tr><tr><td>4.2 MARKET-BASED FLEXIBILITY SERVICE SELECTION AND ACTIVATION</td><td>57</td></tr><tr><td>4.2.1 Optimal Bid Recommender - N-SIDE</td><td>58</td></tr><tr><td>4.2.2 Flexibility service provider - Centrica</td><td>59</td></tr><tr><td>4.2.3 Market-based flexibility procurement on NODES market platform via the UMEI</td><td>60</td></tr><tr><td>4.2.3.1 Integration of NODES market platform and the UMEI</td><td>61</td></tr><tr><td>4.2.3.2 Field test: Registration and prequalification</td><td>62</td></tr><tr><td>4.2.3.3 Field test: Flexibility trading</td><td>64</td></tr><tr><td><b>5 CONCLUSION AND OUTLOOK</b></td><td><b>69</b></td></tr><tr><td><b>6 REFERENCES</b></td><td><b>70</b></td></tr><tr><td><b>7 ANNEX</b></td><td><b>71</b></td></tr></table>
List of Abbreviations

<table><tr><td>BEMS</td><td>Business Energy Management System</td></tr><tr><td>BUC</td><td>Business Use Case</td></tr><tr><td>CC</td><td>Chance Constraint</td></tr><tr><td>D</td><td>Deliverable</td></tr><tr><td>DdSE</td><td>Data driven State Estimation</td></tr><tr><td>DN</td><td>Distribution Network</td></tr><tr><td>DNI</td><td>Distribution Network Incidents</td></tr><tr><td>DSO(s)</td><td>Distribution System Operator</td></tr><tr><td>EV</td><td>Electric Vehicles</td></tr><tr><td>FNA</td><td>Flexibility Needs Assessment</td></tr><tr><td>HEMS</td><td>Home Energy Management System</td></tr><tr><td>KPI</td><td>Key Performance Indicator</td></tr><tr><td>LV</td><td>Low Voltage</td></tr><tr><td>MNS</td><td>Mitnetz Strom</td></tr><tr><td>MV</td><td>Medium Voltage</td></tr><tr><td>MVP</td><td>Minimum Valuable Product</td></tr><tr><td>OBR</td><td>Optimal Bid Recommender</td></tr><tr><td>OPF</td><td>Optimal Power Flow</td></tr><tr><td>PV</td><td>Photovoltaic</td></tr><tr><td>REST API</td><td>RESTful application programming interface</td></tr><tr><td>SO(s)</td><td>System Operator</td></tr><tr><td>SSH</td><td>Secure Shell</td></tr><tr><td>SUC</td><td>System Use Case</td></tr><tr><td>T</td><td>Task</td></tr><tr><td>UMEI</td><td>Universal Market Enabling Interface</td></tr><tr><td>WP(s)</td><td>Work Package</td></tr></table>
List of Tables

<table><tr><td>TABLE 2.1 - LV GRID AREAS OF THE GERMAN DEMONSTRATOR</td><td>16</td></tr><tr><td>TABLE 2.2 - BUSINESS USE CASES OF THE GERMAN DEMONSTRATOR</td><td>17</td></tr><tr><td>TABLE 2.3 - SYSTEM USE CASES OF THE GERMAN DEMONSTRATOR</td><td>18</td></tr><tr><td>TABLE 2.4 - KPI'S RELEVANT TO THE GERMAN DEMONSTRATOR</td><td>20</td></tr><tr><td>TABLE 3.1 - SYSTEM COMPONENTS AND ROLES</td><td>23</td></tr><tr><td>TABLE 3.2 - SYSTEM DATA SOURCES AND DATAFLOW</td><td>25</td></tr><tr><td>TABLE 3.3 - INPUT DATA CONGESTION FORECASTING AND PREVENTION TOOL</td><td>31</td></tr><tr><td>TABLE 3.4 - INPUT DATA FLEXIBILITY NEEDS ASSESSOR</td><td>33</td></tr><tr><td>TABLE 3.5 - INPUT DATA STATE ESTIMATOR</td><td>34</td></tr><tr><td>TABLE 3.6 - INPUT DATA OPTIMAL BID RECOMMENDER</td><td>36</td></tr><tr><td>TABLE 3.7 - OVERVIEW OF MARKET LIQUIDITY AND CUSTOMERS RECRUITED</td><td>42</td></tr><tr><td>TABLE 4.1 - TOKEN-BASED AUTHENTICATION OF THE CLIENT</td><td>65</td></tr><tr><td>TABLE 4.2 - BASIC REQUESTS</td><td>65</td></tr><tr><td>TABLE 4.3 - TRADING SCENARIOS</td><td>68</td></tr><tr><td>TABLE 7.1 - OVERVIEW INTERNAL DATA EXCHANGE</td><td>71</td></tr></table>
List of Figures

<table>
  <tbody>
    <tr>
      <td>FIGURE 1.1: GEOGRAPHICAL AND DEMO SITE CHARACTERISTICS</td>
      <td>12</td>
    </tr>
    <tr>
      <td>FIGURE 2.1- DEMO SITE CHARACTERISTICS</td>
      <td>15</td>
    </tr>
    <tr>
      <td>FIGURE 3.1- SYSTEM ARCHITECTURE MODEL</td>
      <td>23</td>
    </tr>
    <tr>
      <td>FIGURE 3.2- SYSTEM DATAFLOW</td>
      <td>25</td>
    </tr>
    <tr>
      <td>FIGURE 3.3- SYSTEM INTERNAL VIEW</td>
      <td>28</td>
    </tr>
    <tr>
      <td>FIGURE 3.4- CALCULATION CHAIN</td>
      <td>30</td>
    </tr>
    <tr>
      <td>FIGURE 3.5- CALCULATION CHAIN: CONGESTION FORECASTING AND PREVENTION TOOL</td>
      <td>32</td>
    </tr>
    <tr>
      <td>FIGURE 3.6- CALCULATION CHAIN: FLEXIBILITY NEEDS ASSESSOR</td>
      <td>33</td>
    </tr>
    <tr>
      <td>FIGURE 3.7- CALCULATION CHAIN: STATE ESTIMATOR</td>
      <td>35</td>
    </tr>
    <tr>
      <td>FIGURE 3.8- CALCULATION CHAIN: OPTIMAL BID RECOMMENDER</td>
      <td>36</td>
    </tr>
    <tr>
      <td>FIGURE 3.9- CALCULATION CHAIN: MARKET PLATFORM</td>
      <td>38</td>
    </tr>
    <tr>
      <td>FIGURE 3.10- CALCULATION CHAIN: UMEI API</td>
      <td>39</td>
    </tr>
    <tr>
      <td>FIGURE 4.1-EVALUATION OF CONGESTION FORECASTING TOOL: (A) USING THE ORIGINAL NETWORK LAYOUT AND CUSTOMER INFORMATION; (B) USING THE CORRECTED GRID LAYOUT AND NETWORK INFORMATION FOR FEEDER ID 67729182</td>
      <td>45</td>
    </tr>
    <tr>
      <td>FIGURE 4.2-EVALUATION OF CONGESTION FORECASTING TOOL: (A) USING THE ORIGINAL NETWORK LAYOUT AND CUSTOMER INFORMATION; (B) USING THE CORRECTED GRID LAYOUT AND NETWORK INFORMATION FOR FEEDER ID 327288</td>
      <td>46</td>
    </tr>
    <tr>
      <td>FIGURE 4.3- CONGESTION FORECASTING OF FEEDER 67729185</td>
      <td>48</td>
    </tr>
    <tr>
      <td>FIGURE 4.4- CONGESTION RISKS AND HEADROOM CALCULATION RESULTS FOR FEEDER 67729185</td>
      <td>49</td>
    </tr>
    <tr>
      <td>FIGURE 4.5- FLEXIBILITY NEEDS ASSESSMENT WITH THE INPUT AND THE OUTPUT DATA</td>
      <td>51</td>
    </tr>
    <tr>
      <td>FIGURE 4.6- DOCKER ARCHITECTURE</td>
      <td>52</td>
    </tr>
    <tr>
      <td>FIGURE 4.7- GERMAN DN MLQ0094 WITH ZONAL CLUSTERS</td>
      <td>52</td>
    </tr>
    <tr>
      <td>FIGURE 4.8- MEASUREMENT POINTS (IN YELLOW) AND CONSUMERS (IN BLUE DOTS) FOR MLQ0094</td>
      <td>53</td>
    </tr>
    <tr>
      <td>FIGURE 4.9- DAY-AHEAD TEMPORAL FLEXIBILITY NEEDS FOR GERMAN DN</td>
      <td>53</td>
    </tr>
    <tr>
      <td>FIGURE 4.10- TUNING CC LEVEL USING PARETO OPTIMALITY</td>
      <td>54</td>
    </tr>
    <tr>
      <td>FIGURE 4.11- TEMPORAL FLEXIBILITY NEEDS ARE CALCULATED IN A DA HORIZON</td>
      <td>54</td>
    </tr>
    <tr>
      <td>FIGURE 4.12- ZONAL CLUSTER FOR DEMONSTRATION NETWORK MFN4420</td>
      <td>55</td>
    </tr>
    <tr>
      <td>FIGURE 4.13- MEASUREMENT POINTS (YELLOW DOTS) AND CONSUMERS (BLUE DOTS) FOR MFN4420</td>
      <td>55</td>
    </tr>
    <tr>
      <td>FIGURE 4.14- ZONAL FNA FOR MFN4420</td>
      <td>55</td>
    </tr>
  </tbody>
</table>
<table><tr><td>FIGURE 4.15 - COMPARISON BETWEEN ESTIMATED AND REAL VOLTAGE VALUES FOR ONE SMART METER CONNECTED TO PHASE A, OVER THE PERIOD OF 10 DAYS.</td><td>56</td></tr><tr><td>FIGURE 4.16 - COMPARISON BETWEEN ESTIMATED AND REAL VOLTAGE VALUES FOR ONE SMART METER CONNECTED TO PHASE C, OVER THE PERIOD OF 10 DAYS.</td><td>57</td></tr><tr><td>FIGURE 4.17 - DIGITAL FLEXIBILITY VALUE CHAIN (WWW.NODESMARKET.COM).</td><td>58</td></tr><tr><td>FIGURE 4.18 - INPUTS AND OUTPUTS OF THE N-SIDE OPTIMAL BID RECOMMENDER.</td><td>59</td></tr><tr><td>FIGURE 4.19 - ORGANIZATION OF DATA FLOWS AND ASSET STEERING IN THE GERMAN DEMONSTRATOR.</td><td>60</td></tr><tr><td>FIGURE 4.20 - NODES INTEGRATED MARKET DESIGN (WWW.NODESMARKET.COM).</td><td>61</td></tr><tr><td>FIGURE 4.21 - MITNETZ LICENSE AREAS MV FEEDER MLQ0094 (ABOVE) AND MV FEEDER MFN4420 (BELOW) AND ASSOCIATED LV FEEDERS ON NODES MARKET PLATFORM.</td><td>63</td></tr><tr><td>FIGURE 4.22 - DETAILED REPRESENTATION OF REGISTERED ASSETS AT LV GRID NODE KV NORDSTR. / WURZENER STR. 7260/MV FEEDER MFN4420.</td><td>64</td></tr><tr><td>FIGURE 4.23 - ORDER BOOK STRUCTURE ACCORDING TO THE GRID NODE ORGANIZATION IN THE MITNETZ LICENSE AREA</td><td>64</td></tr><tr><td>FIGURE 4.24 - NODES MARKET PLATFORM: TRADING IN MFN4420 ORDERBOOK</td><td>67</td></tr></table>
Executive Summary

This Deliverable has been drafted in the context of the EUniversal project. The project aims to overcome existing limitations regarding the use of flexibility by DSOs for congestion and grid management. Considering the European approach as well as the need for harmonization and creation of standards, one objective of EUniversal is the establishment and integration of the Universal Market Enabling Interface (UMEI) to ensure system interoperability to facilitate access to multiple flexibility market platforms and thus access to distributed flexibility. The UMEI is tested in three locations across Europe, i.e. Portugal, Germany and Poland, examining its use for market-based flexibility procurement in various use cases.

This report follows up on the deliverable D8.1 for the German Demonstrator "Specifications and guidelines of tools for an Active LV grid for field testing". The deliverable describes the technical and operational details of the site-specific problem to solve, the pilot site, each tool implemented in the digital flexibility value chain and the interconnection between consecutive tools. Furthermore, D8.1 outlines the specific use of the UMEI to facilitate access to flexibility services via a market-based approach.

This deliverable reports the set up and test scenarios of the flexibility value chain within the German demonstrator (WP8) starting from congestion detection to the market-based flexibility service procurement. The tests are divided into two parts: 1) Individual tests of each smart grid tool, the market environment and associated functions of the DSO, FSP and the Optimal Bid Recommender to ensure correct functioning and information exchange and 2) the operational testing of consecutive members of the digital flexibility value chain. Due to time constraints as well as operational challenges, this report outlines the test part 1), related findings and challenges of the performed test series. Wherever possible, the functionalities and operational processes will be measured against the Key Performance Indicators (KPIs) identified in WP2. These results will be presented in detail in Deliverable 8.3 together with the results of the test series 2).
# 1. Introduction

## 1.1 Background

The European Union aims at transforming the energy system towards a sustainable, low-carbon and climate-friendly economy. The scope is to increase the energy share of electricity production in distribution grids to around 50% of renewable energy sources (RES) until 2030 while guaranteeing the security of supply and avoiding unnecessary network investments. For this purpose, load generation and consumption of prosumers across all grid levels shall serve as energy and flexibility resources making them active participants in the energy system. In such a scenario, prosumers become key enablers towards a more sustainable, low-carbon and climate-friendly electricity system by adapting their consumption and production behaviour to stabilize the grid when needed. Yet, flexibility will also add complexity and create unpredictable power flows in the distribution networks. Distribution System Operators (DSOs) need to integrate smart-grid solutions to cope with the new types of load patterns of diverse small-scale assets (e.g. electric vehicles and heat pumps) and to identify the required flexibility to safely host the increasing share of RES. Therefore, innovative technologies and solutions are required to transform the challenges of the energy transition into opportunities for the sector, and ultimately for the society.

The EUniversal project aims to overcome the existing challenges for DSOs concerning the use of flexibility. The primary project goal is to overcome barriers between multiple market agents and their internal systems through the Universal Market Enabling Interface (UMEI) (D2.4-D2.6). The UMEI has been developed to support distribution system operators and their active system management by facilitating access to distributed flexibility via multiple market platforms at different locations while limiting the DSO system changes to a minimum. The UMEI is tested in three different demonstrations in Germany, Poland and Portugal. This deliverable describes the technical specifications and test scenarios performed in the German demonstrator.

The German demonstrator led by German DSO Mitnetz Strom examines the operational and functional viability of each element required within the digital flexibility value chain, starting from smart grid tools to identify existing and future congestions in terms of location, volume and direction, to using an optimal bid recommender to select the optimal bid available on the local flexibility market (Figure 1.1).
<figure><img src="image_3.png" /><figcaption>**Figure 1.1- Simplified Overview of the smart grid tools and the market environment**</figcaption></figure>

## 1.2 Applicability and limitations

The preparation and realization of the field test encounters numerous technical, operational, and regulatory challenges, pointing out existing barriers that impede the successful use of distributed flexibility for grid management:

### Technical challenges

Technical applications and challenges are mainly related to the integration and interconnection of the different tools and APIs (mainly the UMEI and associated functional specifications) within the different systems. The smart grid tools developed within EUniversal and the underlying algorithms must be correctly integrated into the German DSO Mitnetz Strom (MNS) system to ensure the well-functioning of each component within the entire value chain, and to achieve sufficient accuracy and precision of the results. Furthermore, the use of flexibility requires intelligent Home Energy Management Systems (HEMS) and Business Energy Management Systems (BEMS) to provide a control mechanism of flexibility activation and data monitoring for validation of flexibility delivery. The test preparations have shown the enhanced need for standardization between technical devices for energy monitoring as well as the installation in place to ensure correct and effective functioning.

Another technical limitation concerns the management of active and reactive power, BUC I and BUC II in the German Demonstrator, respectively. The clear separation of both may not be realizable from a grid perspective. Considering the market-based procurement at this point, trading of reactive power as a flexibility product is still quite inaccurate due to limitations in quantification of the required volume and pricing. The presented tests within the German demonstrator therefore only concern active power to overcome technical and operational barriers in a first place.

### Operational challenges

From an operational perspective, the lack of active user participation, as well as meter data and grid data in terms of amount, type, and quality of data, as well as the required granularity, complicates the reliable replication of a realistic grid problem and solution. The input of this data directly affects the accuracy of the output of the smart grid tools and hence their
applicability and reliability for the DSO. Sufficient data is crucial for the Demonstrator to reliably evaluate the cost-effectiveness of the flexibility usage in the test locations.

To test the set-up as well as the entire value chain despite of partly insufficient data, a series of simulations has been performed. However, it is important to note that a simulation will only serve as an operational test scenario but does not reliably replicate a realistic situation.

The technical and operational challenges, however, persist to a large extent due to the underlying regulatory framework in Germany concerning an effective Smart Meter Rollout, grid tariff structures, taxes as well as mandatory and voluntary redispatch measures to support the smart use of available distributed flexibility for the purpose of grid management.

## Regulatory challenges

Germany has implemented two methods of steering flexibility, one being the mandatory Redispatch 2.0 and the other one being cost-based. The latter is mainly regulated through the paragraph §14a in the German Energy Industry Act (EnWG). The regulators are currently working on an updated version to amplify the roles and resources to use the distributed flexibility while maintaining the existing redispatch measures to a large extent.

On one hand, the use of market-based flexibility shall reduce or even prevent additional costs and bridge time delays of the grid infrastructure expansion. On another, the market-based flexibility helps to use the available resources efficiently and effectively by solving grid problems locally through smart regulation of local or regional assets. Besides, implementing flexibility markets to benefit from the available distributed flexibility for grid services requires an adaption of the German regulatory framework as well as adjustments of the grid tariff and tax schemes to incentivize the participation of flexibility providers. A detailed evaluation of the required adaptions has been elaborated by a forum of experts and presented to the German Ministry for Economic Affairs and Climate Action in June 2021. This adaptation has, however, not yet led to an alteration in the regulatory framework, and in the German Easter package (2022), market flexibility was only mentioned as an alternative measure with the flexibility potential being categorized as undetermined benefits. This categorization is especially important considering the challenges and risks of integrating flexibility markets, such as the increasing need for coordination between system operators as well as the coordination of numerous new assets and asset types that contribute to the load flow. Furthermore, especially in Germany the potential risk of strategic bidding to artificially increase the revenue of market participants is a major argument against the market-based approach.

With the ongoing work on the German Demo, the goal is to showcase the digital value chain of flexibility suggesting innovative solutions to overcome the existing technical and operational challenges.

## 1.3 Report structure

In the following chapters a summary of the pilot area and selected grid zones is presented together with the identified BUC and SUCs from WP2. In chapter 3 the set-up and integration of each tool into the DSO system to ensure correct functioning and interoperability is
explained. Chapter 4 includes the performed test series and results per tool and market participant to prove technical and operational feasibility of each tool and component. The last chapter includes the conclusion of the previously described tests followed by a short overview of the next steps.

This report is using valuable information from other WPs, namely:

* WP2, for the definition of use cases that will be demonstrated, as well as the UMEI API functional specification, namely with the identification of the interactions between the DSO and Flexibility Market platforms and data exchange

* WP3, with the use of a flexibility toolbox, identifying the technologies and solutions most suitable to provide flexibility services to the distribution grid

* WP4, for the development of the DSO smart grid tools and their alignment

* WP5, the identification of relevant market mechanisms

* WP6, with a common framework to harmonise, monitor and assess the validation of the result

The results of the pilot simulations and measures will be presented and explained in D8.3. The knowledge gained in this demonstration is also used to support WP10 in the development of business models for the exploitation of EUniversal's results and to provide recommendations for policy makers and regulatory authorities to set up a framework for flexibility markets.
# 2 General overview of the German demonstrator

## 2.1 Demo site characteristics

The German demonstration is conducted in LV Grids of the German DSO Mitnetz Strom (MNS - E.ON linked third party). The supply area of MNS is in the Eastern Germany, and includes parts of Brandenburg, Saxony-Anhalt, Saxony and Thuringia. The region is home to 2.3 million inhabitants in an area of 30,804 km². The length of the grid is about 6,000 km in HV, about 24,000 km in MV and about 44,000 km in LV Level. MNS operates and maintains about 17,000 substations with an installed capacity of more than 5,000 MVA. Therefore, the grid provides a broad variety of scenarios and can demonstrate the use cases defined in WP2, ie. Congestion Management & Voltage Control with market-based active/reactive power flexibility (2.3.1 Business Use Cases (BUC)).

<figure><img src="image_4.png" /><figcaption>**Figure 2.1- Demo site characteristics**</figcaption></figure>

To achieve the objectives of the demonstration, adequate grid sections with a relevant infeed of RES and cross-sector loads (e.g. storage and heat pump users) were selected considering grid size and topology, past congestion/voltage problems and the number and type of flexible devices in the network.

## 2.2 Grid selection

The grid areas for the German were selected considering grid size and topology, past congestion/voltage problems and aiming to embrace the largest possible number and variety of flexible applications to enable different scenarios for the field to replicate the future supply task of the distribution grid operators. The selected grids are among the MNS low-voltage
grids with the highest densities of flexible resources and are representative of the possible usage of flexibility markets at the low-voltage level. In addition, a further increase of steerable systems is expected for the coming years, which makes the selected regions an optimal use case for grid congestion solutions. In a second step two pilot regions were selected in the MNS grid regions of Brandenburg and West Saxony. However, since customer acquisition was only very moderately successful (chapter 3.3), it was decided to concentrate on the LV grids with larger cable expansions and set-up measuring support points and to use them for the evaluation and prognosis of the grid state.

<table><caption>Table 2.1 - LV grid areas of the German Demonstrator<fnref n="1" /></caption><tr><td>Identifier</td><td>MLq0094</td><td>MFn4420</td></tr><tr><td>Grid region</td><td>Brandenburg</td><td>West-Saxony</td></tr><tr><td>Town where the LV Grid is located</td><td>Falkenberg\Elster</td><td>Brandis</td></tr><tr><td>Number of connected meters²</td><td>400</td><td>300</td></tr><tr><td>Number of customers with flexible devices</td><td>50</td><td>44</td></tr><tr><td>Specifics</td><td><ul><li>Mostly single-family houses</li><li>Partly still use of night storage heaters (historically grown)</li><li>MNS site in town</li></ul></td><td><ul><li>Residential area with single-family houses from the 1990s/2000s</li><li>Radial grid structure</li></ul></td></tr></table>

## 2.3 Mapping of Use Cases and Key Performance Indicators

Starting from the flexibility needs from DSOs, explored, and defined in D2.1 of the project, a set of Business Use Cases (BUCs) were determined for each demonstrator in the project, each describing the interactions needed between the involved stakeholders and their associated information requirements. This description can be found in D2.2.

<footnote n="1">1 Rounded values</footnote>
Following these BUCs, a set of System Use Cases (SUCs) was defined, identifying clear functional specifications of the operational prototypes in the project test environments. This description can be found in D2.3.

In a next step, a set of key performance indicators (KPIs) was defined to evaluate and monitor the performance of the project tests and pilots. These KPIs are based on the previously defined BUCs and SUCs. These KPIs and the detailed process on how they are defined can be found in deliverable D6.3.

The following section provides an overview of the BUCs, SUCs and KPIs that are relevant to the German demonstrator.

### 2.3.1 Business Use Cases (BUC)

A BUC describes the steps and activities in a process that are necessary to achieve a business goal. Two BUCs were identified to be of predominant importance for the German Demonstrator:

<table><caption>Table 2.2- Business Use Cases of the German Demonstrator</caption><thead><tr><td>ID</td><td>Name</td><td>Service</td><td>Mechanism</td><td>Main Steps</td></tr></thead><tbody><tr><td>DE-AP</td><td>Congestion Management & Voltage Control with market-based active power flexibility</td><td>Congestion management and Voltage control</td><td>Local flexibility market</td><td><ul><li>Identification and localisation of required flexibility (smart grid tools)</li><li>Registration and Prequalification assets</li><li>Bidding and selection</li><li>Delivery and monitoring (not tested)</li><li>Settlement (not tested)</li></ul></td></tr><tr><td>DE-RP</td><td>Congestion Management & Voltage Control with market-based reactive power flexibility</td><td>Voltage control and congestion management</td><td>Local flexibility market</td><td><ul><li>Identification and localisation of required flexibility (smart grid tools)</li><li>Registration and Prequalification</li><li>Bidding and selection</li><li>Delivery and monitoring (not tested)</li><li>Settlement (not tested)</li></ul></td></tr></tbody></table>

Although the two BUCs, Congestion Management & Voltage Control with market-based active and reactive power flexibility, are clearly separated in Table 2.2, such a clear distinction may
not be realizable or useful from a grid perspective. The converters, especially in LV, are generally designed to have an operating range that is fully or partially dependent on active power. Furthermore, LV grids are resistive and the separation from a technical perspective is difficult. Therefore, the algorithms of the smart grid tools do not distinguish between active and reactive power as interdependent components.

The applied market clearing algorithms consider only one parameter that can be either active or reactive power. Both can be traded as separate products on the market platform assuming a correct quantification of the required dimensions, pricing and associated baselines. Nevertheless, the separation of both as a product may cause a trade-off and affect the efficiency of the market.

Therefore, within WP8.2, during the testing and pilot phase, the focus lies on BUC I DE-AP and related SUCs as a first step.

### 2.3.2 System Use Cases (SUC) of the German Demonstrator

The SUCs, in contrast to the BUCs, provide detailed descriptions of the process itself. The SUCs give the functional description needed to support the BUCs by detailing which activities are performed, who is going to execute them and on which system.

In the German Demonstrator, 10 System Use Cases have been defined within Task 2.3 and were classified into three domains:

* Smart Grid Operations - including all use cases involving the distribution network operation and planning

* Flexibility Market - including all use cases involving local flexibility market operation

* Flexibility Aggregation and grid users - including all use cases related to the FSP and the consumer/active customer provision of flexibility services in the market.

The list of System Use Cases defined for the German demonstration is presented in Table 2.3.

<table><caption>Table 2.3 - System Use Cases of the German Demonstrator</caption><thead><tr><th>Domain</th><th>SUC ID</th><th>SUC name</th><th>BUC ID</th><th>Related Pilot(s)</th><th>Owner</th></tr></thead><tbody><tr><td rowspan="3">Smart Grid Operation</td><td>SUC 4</td><td>Day-ahead congestion management considering flexibility needs in LV and MV networks</td><td>DE AP, DE RP</td><td>PT, DE</td><td>INESC TEC</td></tr><tr><td>SUC 5</td><td>Estimating LV voltage magnitude based on historical data and load forecasts</td><td>DE AP</td><td>PT, DE</td><td>INESC TEC</td></tr><tr><td>SUC 6</td><td>Day-ahead congestion forecasting</td><td>DE AP, DE RP</td><td>DE</td><td>VITO</td></tr></tbody></table>
<table><tr><td></td><td>SUC 7</td><td>Voltage control in LV networks based on limited observability and network topology</td><td>DE AP</td><td>PT, DE</td><td>INESC TEC</td></tr><tr><td></td><td>SUC 8</td><td>LV flexibility needs assessment for voltage and congestion management</td><td>DE AP, DE RP</td><td>DE</td><td>KUL</td></tr><tr><td></td><td>SUC 12</td><td>Minimizing costs linked to DSO flexibility requirements</td><td>DE AP, DE RP</td><td>DE</td><td>N-SIDE</td></tr><tr><td>Flexibility Market</td><td>SUC 13</td><td>Short-term flexibility procurement</td><td>DE AP, DE RP</td><td>PL, PT, DE</td><td>NODES</td></tr><tr><td rowspan="5">Flexibility Aggregation</td><td>SUC 16</td><td>DER registration and configuration</td><td>DE AP, DE RP</td><td>PT, DE</td><td>CENTRICA</td></tr><tr><td>SUC 17</td><td>Bidding aggregation</td><td>DE AP, DE RP</td><td>PT, DE</td><td>CENTRICA</td></tr><tr><td>SUC 18</td><td>Resources' dispatch and monitoring</td><td>DE AP, DE RP</td><td>PT, DE</td><td>CENTRICA</td></tr><tr><td>SUC 19</td><td>Baselining</td><td>DE AP, DE RP</td><td>PT, DE</td><td>CENTRICA</td></tr><tr><td>SUC 20</td><td>Collecting and publishing metering data</td><td>DE AP, DE RP</td><td>PT, DE</td><td>CENTRICA</td></tr><tr><td>Data Management</td><td>SUC 21</td><td>DSO data management - German Demonstrator</td><td>DE AP, DE RP</td><td>DE</td><td>MNS/E.ON</td></tr></table>

### 2.3.3 Key Performance Indicators

The KPIs that will be used to assess the demo results are shown in (Table 2.4) A first set of KPIs concerns the common demo KPIs, indicated by the IDs 'CM_KPI_x'. These KPIs will be evaluated within the German demonstrator, as well as within the other demonstrators of the EUniversal project. Within WP6, a set of demo specific KPIs were defined that are indicated by the IDs 'DE_KPI_x' in Table 2.4. Note that, according to D6.3, an extra demo specific KPI was defined, i.e. DE_KPI_06, with the objective to evaluate the performance of the flexibility needs assessment functionality.

The objective of this deliverable is to describe the set-up of the complete flexibility value chain within the demonstrator and to give the results of the functional tests of each individual tool and market component. These functional tests are necessary to make sure that the KPIs defined in WP6 can be calculated.
However, the complete KPI results based on the evaluation of the full flexibility value chain will be presented in the following and conclusive deliverable on the German demonstrator (D8.3).

<table><caption>Table 2.4 - KPI's relevant to the German Demonstrator</caption><thead><tr><td>KPI ID</td><td>KPI Name</td></tr></thead><tbody><tr><td>CM_KPI_1</td><td>Flexible capacity vs. flexible volume offered ratio</td></tr><tr><td>CM_KPI_2</td><td>Flex volume offered by FSP vs. Flex request by DSO</td></tr><tr><td>CM_KPI_3</td><td>Flex bids accepted by DSO vs flex volume delivered by FSP</td></tr><tr><td>CM_KPI_4</td><td>Avoided restrictions</td></tr><tr><td>CM_KPI_5</td><td>Voltage Magnitude Prediction Error</td></tr><tr><td>DE_KPI_01</td><td>Costs of Congestion Management with flex Market vs. Curtailment</td></tr><tr><td>DE_KPI_02</td><td>Cycle Time DSO process</td></tr><tr><td>DE_KPI_03</td><td>Share of correctly forecasted congestions</td></tr><tr><td>DE_KPI_04</td><td>Share of false positive congestion forecasts</td></tr><tr><td>DE_KPI_05</td><td>Baseline accuracy</td></tr><tr><td>DE_KPI_06</td><td>Over-/under-estimation of flexibility</td></tr></tbody></table>
# 3 Field test framework

## 3.1 System architecture

All the system processes and data flows are subdivided into several logical levels: system and data access, data collecting, data processing, internal and external data exchange.

### 3.1.1 Goals and objectives

The German Demo System was designed and implemented to overcome challenges of data collected from various sources and securely exchanging data while ensuring the independent operation of different applications and tools on the cloud virtual server.

The primary objectives of the German Demo System in terms of functionality are the following:

* setting up flexible a data storage and management, ie. a dedicated storage capacity on the cloud server's local disks + relational database system, to store data from external sources and calculation results from tools.

* building, deploying and managing multiple tools provided by EUniversal Consortium partners for the German Demonstrator

* building, deploying and managing an orchestrating synchronizing application (further - the Synchronizer) with built-in REST API, enabling data exchange between data sources and tools running on the server

* establishing reliable and stable communication between all system components

* maintaining a dockerized development system environment

* centralized logging to track the operation status of the system

* deploying API gateway by means of load balancing and reverse proxying software to support secure processing and handling of HTTP APIs built into the Synchronizer and other applications/tools.

### 3.1.2 Design principles

The system architecture meets all the primary objectives and needs of the German Demonstrator in the EUniversal Project and provides its assured functionality considering data protection requirements and operational reliability.

The system architecture is based on the following design principles:

* establishing trustworthy communication between all applications and tools within the German Demonstrator

* information protection in data exchange and storage - authentication and authorization provided

* containerized architecture as the basis for system architecture
* separate Docker container for each application/tool/database system

* central orchestrating unit (backend application build on the .NET framework) for data handling, validation and data exchange between all system components

* each application and tool are running independently and have their own specific functionality

* NGINX as general high-performance routing part handling multiple HTTP connections

* predefined scheduled and/or manually triggered data querying from external sources

* synchronous data processing by applications and tools according to a predefined calculation schedule

* capability of database polling through asynchronous queries to ensure better performance

* remote access to logging messages for tool developers to track the tools' status during the testing and operation phase

* Capability of querying tools' calculation results through the Synchronizer REST API along with their visualization and analysis in a BI tool

### 3.1.3 System Architecture: General Model

The main purpose of system architecture is to determine the essential structural components of the system along with the components' interaction.

The EUniversal system architecture model is shown in Figure 3.1 visualizing the following system component groups:

* external sources supplying data for calculation and analysis (Measurements Platform, Weather Forecast Source, DSO Internal Platform)

* embedded interfaces (CLI) and communication channels to external data sources

* data synchronizer – data processing and orchestration unit

* dockerized applications & tools – data analysis and calculation units

* system users (advanced users and system administrators)

* knowledge database system for data collection
<figure><img src="image_5.png" /><figcaption>Figure 3.1- System Architecture Model</figcaption></figure>

Each system component group is assigned a specific role (Table 3.1):

<table><caption>Table 3.1- System Components and Roles</caption><thead><tr><th>System Role</th><th>System Component Group</th><th>System Component</th><th>Role Description</th></tr></thead><tbody><tr><td>Data Owner</td><td></td><td>German Demonstrator customers<br>DSO</td><td>An organization or individuals that provides data by agreement and give permission for its use with the assurance of confidentiality and pre-anonymization</td></tr><tr><td>Data Provider</td><td>External data sources incl. communication channels</td><td>Azure Data Explorer Cluster<br>Databricks Cluster<br>Internal Platform<br>NODES Platform</td><td>Platform or data source that independently handles data, makes the data available for regular polling through dedicated interfaces, participates in data exchange process on demand of the data orchestrator</td></tr></tbody></table>
<table><tr><td></td><td></td><td>Universal Market Enabling Interface</td><td></td></tr><tr><td>Data Orchestra tor</td><td>Data Synchronizer</td><td>Synchronizer</td><td>Special application in charge of data managing, that is data handling from multiple data sources, as well as data combining, validating, and converting it when necessary, storing the data in a dedicated data storage location (database or a separate local space on the server) and making the data available for Data calculation and tool analysis</td></tr><tr><td rowspan="4">Data Calculatio n and Tool Analysis</td><td rowspan="4">Dockerized application s and tools</td><td>Congestion Forecasting and Prevention Tool</td><td rowspan="4">Continuously performing calculations/processing iteratively a new set of data from external sources; fulfills one of the key functions in calculation chain and produces data that can be entered into the next level of the chain or be handled as a final calculation result</td></tr><tr><td>Optimal Bid Recommender</td></tr><tr><td>State Estimator</td></tr><tr><td>Flexibility Needs Assessor</td></tr><tr><td rowspan="2">Data Storage</td><td rowspan="2">Knowledge database system</td><td>PostgreSQL</td><td rowspan="2">A database or dedicated storage space on the server for data collection, storage and providing on demand when receiving a request from a main participant via a data orchestrator</td></tr><tr><td>Local storage</td></tr><tr><td rowspan="2">Data User</td><td rowspan="2">System User</td><td>System administrator</td><td>The person in charge of monitoring the status and performance of the system and making all necessary updates to the system</td></tr><tr><td>Advanced Users</td><td>The person in charge of analyzing and visualizing the data coming from the system, and making decisions accordingly</td></tr></table>

Interaction between system components is ensured by secure communication channels. The communication between data providers and data orchestrator is mainly implemented by polling external APIs of the providers by the Orchestrator on a pre-planned schedule (every 15 minutes or hourly). The data querying from external sources is facilitated through the utilization of standard HTTP and HTTPS protocols, along with the corresponding RESTful API and CLI. The communication between the Orchestrator and Data Collector is supported by message-based protocol. Data exchange between the Orchestrator and corresponding tools/applications running internally on the server performed via querying of the intended internal APIs.
### 3.1.4 System Architecture: Dataflow

The need to regularly provide all the tools with sufficient up-to-date input data to perform calculations has led to the integration of an automated data collection system enabling the data acquisition (polling) according to the predetermined time schedule. For an effective management of the system, it's also critical to validate the source data each time it arrives. Considering this, the functions of data query, verification and storage in the system were delegated to the Data Synchronizer.

The dataflow taking place in the system is illustrated in Figure 3.2 and involves the following data and their related sources (Table 3.2):

<figure><img src="image_6.png" /><figcaption>Figure 3.2 - System Dataflow</figcaption></figure>

<table><caption>Table 3.2 - System Data Sources and Dataflow</caption><thead><tr><td>Nr</td><td>Data Recipient</td><td>Data Source</td><td>Data Source Role</td><td>Transmitted Data</td><td>Data Description</td><td>Data Type</td><td>Data Cycle</td></tr></thead><tbody><tr><td>1</td><td>Data Synchronizer</td><td>Azure Data Explorer Cluster</td><td>Measurement Platform</td><td>Node location, line current, voltage, active/ reactive/</td><td>Information about all measured values of current,</td><td>.json</td><td>~ 15 min</td></tr></tbody></table>
<figure><img src="image_7.png" /></figure>

<table><tr><td></td><td></td><td></td><td>apparent power</td><td>voltage and power for each particular node of the network</td><td></td><td></td></tr><tr><td>2</td><td></td><td>Azure Databricks Cluster</td><td>Weather forecast source</td><td>Hourly weather forecasts of temperature and cloud fraction</td><td>Predicted values of air temperature and cloud fraction for the location of each node of the network (for each hour for next 28 hours)</td><td>.rds</td><td>Updated every 3 hour</td></tr><tr><td rowspan="2">3</td><td rowspan="2">Data Synchronizer</td><td>Internal Platform</td><td>Network Topology System</td><td>Network topology</td><td>Information about network structure</td><td>.dgs</td><td>As updated</td></tr><tr><td>MITNETZ GIS Center</td><td>Measurement Platform</td><td>Active and reactive power measurements</td><td>Information from smart meters (current, voltage, active and reactive power) installed on customers side</td><td>.json</td><td>~ 15 min</td></tr><tr><td>4</td><td></td><td>NODES Platform</td><td>Flexibility Market Platform</td><td>Existing assets, grid assignments, grid areas, grid nodes, energy market, meter reading, price areas, orders, trades</td><td>Information about existing assets, grid areas and nodes, market platforms, placed orders, available flexibility resources, orders and trades</td><td>.json</td><td>hourly</td></tr><tr><td>5</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>6</td><td>NODES Platform</td><td>Data Synchronizer</td><td>System Operator placing</td><td>"Buy" flexibility orders</td><td>Information about needed energy volumes (for</td><td>.json</td><td>As congestion occurs/predicted</td></tr></table>
<table><tr><td></td><td></td><td>flexibility orders</td><td>each congested node) for mitigating network congestions</td><td></td><td></td></tr><tr><td>7</td><td>System Users</td><td>Data Synchronizer</td><td>Source of data for analytics and decision making</td><td>Calculation results for analytics and visualization</td><td>Calculation results per tool, information about calculations' performance, raw measurements fed into the tools</td><td>.json</td><td>As updated</td></tr></table>

### 3.1.5 System Architecture: Internal View and Data Exchange

The internal system view is illustrated in Figure 3.3.

Internal data exchange takes place between the following system components:

* knowledge database system (incl. object-relational database system and dedicated local storage space)

* dockerized calculation tools

* dockerized data synchronizer

The Data Synchronizer is the central orchestrating part of the system that combines all processes of data handling, processing, and transmission to the other system components. Each tool is deployed in a separate Docker container, which allows independent and secure operation of the system. Transferring data from one dockerized component to another is carried out via independent Docker volumes or via the internal IP address of a particular Docker container by means of the Data Synchronizer. Interaction between applications and the knowledge database system is also ensured through the Synchronizer.
<figure><img src="image_8.png" /><figcaption>Figure 3.3 - System Internal View</figcaption></figure>

## Tool Deployment

Given the dockerized development environment as a critical point in the server architecture, the basis for deployment of applications and tools on the server are Docker images and Dockerfiles, which are provided via a dedicated Docker Hub, third-party registry services or pushed directly to the DSO system via a trusted and secure communication channel.

Dockerfile is a premise that contains a set of instructions i.e., statements to assemble a Docker image. In other words, the Dockerfile includes all the necessary build context from which a Docker image is supposed to be built, including all pre-configured environments, code and dependencies.
After creating a Docker image from a Dockerfile or getting one directly from the Docker Hub or Docker repository, the next step is to start a Docker container containing the corresponding application or tool supplied by the image. Once the Docker container is successfully started, it becomes manageable and interoperable with other containers on the server. In this way all applications on the server are deployed and started.

### Internal Data Exchange

For establishing a secure and stable interaction with the system, all tools are equipped with a built-in REST API. Some tools are also equipped with an access control mechanism with bearer authentication. Thus, the relevant HTTP requests to a specific API of a particular tool can be used for authentication, entering input data, calculations triggering, monitoring the status of calculations, and finally for the retrieval of calculation results. One of the tools running on the server supports two-way data exchange by automatically pushing calculation results to the Synchronizer via a corresponding POST HTTP request to the REST API of the Synchronizer, which makes the data exchange even more flexible and faster.

Generally, all the main requests for entering input data into a particular tool, triggering and monitoring calculations, as well as extracting results are performed by the Synchronizer through the pre-established HTTP Client instance with the appropriate configuration, headers, and credentials. Thus, the Synchronizer acts as an orchestrator – monitors the data processing and redirects data from one tool to another or from one tool to the knowledge database system. In other words, all the inputs and outcomes are first verified by the Synchronizer (and stored in the knowledge database if needed) before being provided to the next tool in the chain.

### 3.1.6 System Architecture: Calculation chain

The main purpose of the calculation chain is to evaluate the state of the DSO's network, to identify network bottlenecks, to predict congestions using probability calculation and finally to determine network nodes with available flexibilities to solve the predicted congestions. The flexibility procurement is supported by the market platform and the UMEI enabling data exchange between all participants of the flexibility market.

The Calculation chain is illustrated in Figure 3.4.
<figure><img src="image_9.png" /><figcaption>Figure 3.4 - Calculation chain</figcaption></figure>

## 3.2 Internal and external components of the calculation chain

* Congestion Forecasting and Prevention Tool (Ch. 3.2.1)

* Flexibility Needs Assessment Tool (Ch. 3.2.2)

* State Estimator (Ch. 3.2.3)

* Optimal Bid Recommender (Ch. 3.2.4)

* Universal Market Enabling Interface (Ch. 3.2.5)

* Market Operator (Ch. 3.2.6)

The procedure of data collection, processing and calculation includes five basic steps:

* Initial data collection and network state estimation

* Congestion forecasting and flexibilities assessment in the network

* Pre-qualification stage - acquisition of up-to-date market-related information

* Acquisition of up-to-date information about baseline intervals and flexibility orders

* Optimal bids calculation – decision making on orders selection in accordance with offered market flexibilities and predicted congestions
The calculation chain is designed to perform a complete calculation cycle for a set of input data that is entered into the system from every 15 minutes to every hour.

The initial input data required to start the calculations include:

* network topology

* real-time power and voltage measurements at network nodes (for last 15 minutes)

* historical data including power and voltage measurements at network nodes (for last month)

* weather forecasts (day ahead)

### 3.2.1 Calculation Chain: Congestion Forecasting and Prevention Tool

**Location:** internal, running on the server.

**Tool developer:** VITO.

**Tool objective:** evaluation of network bottlenecks based on input data and prediction of network congestions and probabilities.

**Tool triggering:** hourly.

#### Input data

The tool accepts the following input data:

<table><caption>**Table 3.3 - Input data Congestion Forecasting and Prevention Tool**</caption><thead><tr><td>Input data</td><td>Description</td><td>Duration</td><td>Sampling</td></tr></thead><tbody><tr><td>Voltage measurements</td><td>Frequency; line and phase voltages.</td><td>1 day</td><td>Sampled every 15 minutes</td></tr><tr><td>Power measurements</td><td>Active, reactive, apparent power for each phase; current for each phase.</td><td>1 day</td><td>Sampled every 15 minutes</td></tr><tr><td>Weather forecast</td><td>Temperature and cloud fraction for each node.</td><td>Last 24 hours</td><td>Sampled every 15 minutes</td></tr><tr><td>Network structure</td><td>Input data during the initialization phase and thereafter in case of the network changes.</td><td>-</td><td>-</td></tr></tbody></table>

**Output data:** congestion headrooms with congestion probabilities for next 48 hours.

The tool's operation algorithm is presented in Figure 3.5.
<figure><img src="image_10.png" /><figcaption>**Figure 3.5 - Calculation chain: Congestion Forecasting and Prevention Tool**</figcaption></figure>

The input data are entered by the Synchronizer via appropriate HTTP GET request to the tool's REST API. After the data are collected in the tool's internal storage space it is processed by the tool after reception of an additional HTTP GET request to trigger the calculation. The calculation results are automatically pushed back to Synchronizer API via a corresponding HTTP POST request as soon as the calculation is finished. The output data are collected in the intended directory on the server and are available for retrieval through the REST API of the Synchronizer.

Monitoring of events occurring in the tool and tracing of errors and warnings in the calculation process is fulfilled via a proper analysis of log messages generated by the tool and collected in logs repository on the EUniversal server. Tool developers can retrieve the logs of the respective tool via the Synchronizer REST API.

### 3.2.2 Calculation Chain: Flexibility Needs Assessor

**Location:** internal, running on the server.

**Tool developer:** KU Leuven.

**Tool objective:** providing nodal and zonal FNA required to solve LV network voltage and thermal congestion while reducing distribution network imbalances.

**Tool triggering:** daily.

**Input data**
The tool accepts the following input data:

<table><caption>**Table 3.4 - Input Data Flexibility Needs Assessor**</caption><thead><tr><td>Input data</td><td>Description</td><td>Duration</td><td>Sampling</td></tr></thead><tbody><tr><td>Nodal Load Data</td><td>Line and phase voltage; line and phase power.</td><td>1 month</td><td>Sampled every 15 minutes</td></tr><tr><td>Grid topology</td><td>Grid hierarchical structure (incl. branches, buses and switches) for German Demo networks in DigSilent format</td><td>-</td><td>-</td></tr></tbody></table>

**Output data:** nodal day ahead load profile for each bus.

<figure><img src="image_11.png" /><figcaption>**Figure 3.6 - Calculation chain: Flexibility Needs Assessor**</figcaption></figure>

The FNA Tool is composed of two applications in Python and Julia programming languages. Before running the flexibility needs assessment with the FNA Tool each network provided by the German Demo must be converted from DigSilent format to Json format. To start the network conversion the Synchronizer makes a corresponding HTTP GET request to the FNA API. After receiving a successful response, the Synchronizer makes the next HTTP GET request to generate scenarios for grid assessment based on the available nodal load data. Both HTTP requests are made to the Python application. A successful response to the second
request means the successful generation of scenarios, which are stored in a Docker volume shared by both Python and Julia applications. The final FNA execution request is performed by the Synchronizer to the Julia application, which in turn fetches the calculated scenarios from the Docker volume and makes a flexibility needs assessment for the German Demo networks. The assessment outputs are stored back in the Docker volume and then extracted by the Synchronizer.

Monitoring of events occurring in the tool and tracing of errors and warnings in the calculation process is fulfilled via a proper analysis of log messages generated by the tool and collected in logs repository on the EUniversal server. Tool developers can retrieve the logs of the respective tool via the Synchronizer REST API.

### 3.2.3 Calculation Chain: State Estimator

The State Estimator is the first tool in the calculation chain.

**Location:** internal, running on the server.

**Tool developer:** INESC TEC.

**Tool objective:** Evaluation of the voltage magnitudes for the network nodes where no real-time measurements are available.

**Tool triggering:** every 30 minutes.

#### Input data

The tool accepts the following input data:

<table><caption>Table 3.5 - Input Data State Estimator</caption><thead><tr><td>Input data</td><td>Description</td><td>Duration</td><td>Sampling</td></tr></thead><tbody><tr><td>Historical measurements</td><td>Voltage and active power measurements; required for each node for initialization.</td><td>1 month</td><td>Sampled every 15 minutes</td></tr><tr><td>Real-time measurements</td><td>Voltage and active power measurements for nodes</td><td>15 minutes</td><td>Sampled every 15 minutes</td></tr></tbody></table>

**Output data:** voltages in all nodes of the network including nodes with no real-time measurements for every 15 minutes.

The tool's operation algorithm is presented in Figure 3.7.
<figure><img src="image_12.png" /><figcaption>Figure 3.7 - Calculation chain: State Estimator</figcaption></figure>

During the initialization phase, historical data, including voltage and power measurements for each node of the network, are entered into the tool by making a corresponding HTTP GET request to the tool's API. Next, the real-time measurements on each initialized node are sent to the tool every 15 minutes by making another HTTP GET request. All input data are stored in the database (Postgres), which is linked to the tool and runs in a separate Docker container. The calculations are triggered every 15 minutes by an HTTP GET request and the calculation results are returned consequently. The output data are collected in the intended directory on the server and are available for retrieval through the REST API of the Synchronizer.

Monitoring of events occurring in the tool and tracing of errors and warnings in the calculation process is fulfilled via a proper analysis of log messages generated by the tool and collected in logs repository on the EUniversal server. Tool developers can retrieve the logs of the respective tool via the Synchronizer REST API.

### 3.2.4 Calculation Chain: Optimal Bid Recommender

**Location:** internal, running on the server.

**Tool developer:** N-SIDE.

**Tool objective:** calculation of accepted bids and activation prices in accordance with given congestions and submitted flexibility orders.

**Tool triggering:** hourly.

**Input data**
The tool accepts the following input data:

<table><caption>**Table 3.6 - Input Data Optimal Bid Recommender**</caption><thead><tr><td>Input data</td><td>Description</td><td>Duration</td><td>Sampling</td></tr></thead><tbody><tr><td>Congestion Headrooms</td><td>Predicted congestion headrooms provided by the Congestion Forecasting and Prevention Tool</td><td>Next 48 hours</td><td>Sampled every 15 minutes</td></tr><tr><td>Flexibility orders</td><td>Flexibility orders submitted by the FSP on the market platform</td><td>Next 48 hours</td><td>Sampled every 15 minutes</td></tr><tr><td>Baseline intervals</td><td>Actual power consumption for each node of the network submitted by the FSP on the market platform</td><td>Next 48 hours</td><td>Sampled every 15 minutes</td></tr><tr><td>Network structure</td><td>Information about network hierarchy with parent and child nodes</td><td>Next 48 hours</td><td>-</td></tr></tbody></table>

**Output data:** accepted bids and activation prices related to flexibility orders submitted on the market platform.

The tool's operation algorithm is presented in the Figure 3.8.

<figure><img src="image_13.png" /><figcaption>**Figure 3.8 - Calculation chain: Optimal Bid Recommender**</figcaption></figure>
The final step in the calculation chain refers to the Optimal Bid Recommender. After the calculation of the network congestions have been made and the updated information of submitted sell orders and baseline intervals are collected from the market platform, all this data is fed into the tool to produce results on suitable orders and their activation prices according to the predicted congestions. Calculation results serve as the basis for DSO's decisions regarding order submission on the flexibility market to mitigate network congestions. The input data are entered into the tool by the Synchronizer via appropriate HTTP GET request to the tool's REST API, to then initiate the calculation. The calculation status is checked by the separate HTTP GET request. After the calculation status is "completed", the results of calculations are polled by another HTTP GET request, then collected in the intended directory on the server and are available for retrieval through the REST API of the Synchronizer.

Monitoring of events occurring in the tool and tracing of errors and warnings in the calculation process is fulfilled via a proper analysis of log messages generated by the tool and collected in logs repository on the Universal server. The tool developers can retrieve the logs of the respective tool via the Synchronizer REST API.

### 3.2.5 Calculation Chain: Market Platform

**Market Operator:** NODES

**Location:** external.

**Objective:** providing the DSO with all the necessary information and means to flexibility orders on the market platform.

**Requesting:** daily or after making changes in the DSO's network structure.

**Requested data:**

* Asset Types;

* Grid Nodes;

* Grid Areas;

* Organizations;

* Price Areas;

* Grid Hierarchy;

* Time Zones.

The algorithm for data requests by the Synchronizer via the NODES API invocation is shown in Figure 3.9.
<figure><img src="image_14.png" /><figcaption>**Figure 3.9 - Calculation chain: Market Platform**</figcaption></figure>

The NODES Market is queried daily by the Synchronizer through the UMEI to check the market platform for recent updates. Besides, the queries are performed after changes have been made to the network structure (adding a new node, deleting an invalid node, updating the information about a particular node, etc.). For these purposes, NODES API provides all necessary conventions and request types that allow changes to the DSO's network structure directly through the API. The data provided in the responses are stored in the intended database on the server and then used for order submission via the UMEI API.

### 3.2.6 Calculation Chain: UMEI API

**Developer:** NODES, N-SIDE, Centrica.

**Location:** external.

**Objective:** establishing communication between the DSO and other market participants by exchanging up-to-date information about submitted baseline intervals, orders, completed bids and enabling the placement of flexibility orders by the DSO.

**Requesting:** hourly.

Requested Data (for an appropriate time period):

* Baseline Intervals;

* Submitted flexibility (buy/sell) orders;

* Current status of relevant trades.

The algorithm for data requesting by the Synchronizer via the UMEI API is shown in Figure 3.10.
<figure><img src="image_15.png" /><figcaption>Figure 3.10 - Calculation chain: UMEI API</figcaption></figure>

In the fourth step related to the acquisition of appropriate information by the Synchronizer for further calculations the UMEI API acts as an external source. The UMEI API is used hourly to obtain valid orders and trades from the market platform as well as to retrieve baseline intervals submitted by the Flexibility Service Provider (further - the FSP). This information is a necessary input for the Optimal Bid Recommender next in the calculation chain. The appropriate HTTP requests to the UMEI API are performed by the Synchronizer and the corresponding HTTP responses are verified and stored in the Postgres database on the server.

## 3.3 Customer engagement

### 3.3.1 Customer acquisition

As neither the smart meter rollout in Germany is far advanced, nor is there any active regulation in Germany on the use of flexibilities in the low voltage grid, which the field tests could follow, it was of great importance to recruit volunteers for the testing. The strategy for customer acquisition was also briefly described in Deliverable 8.1.

The following section further elaborates on the customer topic and discusses the difficulties in the organisation, the mitigation measures and consequences for the field tests and gives an outlook for conclusions that will be further elaborated in the last deliverable of the German demo D8.3.
## Barriers

Several challenges were faced during the customer acquisition process, which are briefly described with their effects in the following.

* Lack of interest in energy/technology topics

The current geopolitical situation has made people aware of the importance of a secure energy supply. However, very few contact persons are interested in the technical details. Most of the contacted people did not respond to the enquiries - despite personal letters and reports in the local press.

* Corona pandemic and constraints

Due to the pandemic situation, some citizens stayed away from the town hall meetings. Digital formats were offered as an alternative. However, the personal connection and the possibility to ask questions individually were limited.

* Lack of financial incentives

The participants did not incur any costs and were provided with energy management systems for the test period as an incentive. However, without a recognisable clear and long-term financial incentive, only a few people were willing to sacrifice time to participate in the project and allow their premises to be externally controlled.

* Already existing energy management set-up

Technical savvy citizens partially had their own HEMS set-up already in place with motivation to increase the degree of self-sufficiency with their own PV and storage or to connect smart home applications. This reduced the incentive provided by the HEMS. Besides, problems were feared when restoring the own set-up at the end of the project period.

* Devices without web-communication interfaces

Older inverter types could not be used because they did not yet have web interfaces. As this was largely the case with devices built before 2015, this barrier is expected to disappear in the medium term.

* Focus on autarky/no external influence desired

Some citizens reported a strong interest in being as independent as possible from the public energy supply. The idea of being externally controlled by the DSO or FSPs is clearly opposed to this.

* Large number of devices, manufacturers and interfaces

Since the DSO does not have the data of the device types, the compatibility had to be checked beforehand. Furthermore, as there are no standard interfaces for communication with HEMS so far, most of the devices of interested persons had to be excluded. In addition, there were difficulties in finding service providers in the field, as craft enterprises usually specialise in a few manufacturers of inverters. This meant that an individual set-up was necessary for each customer. In some cases, extra
communication modules were missing in the inverters. Sometimes installation codes of the devices were necessary to change settings allowing for external connections.

* *Poor reputation of the energy sector/energy transition*

A multitude of changes combined with the energy transition make it difficult for customers to evaluate what options are beneficial and what are the consequences. Constantly rising energy prices and grid fees cause resentment.

* *Data protection and IT requirements*

High IT security and data protection requirements had to be fulfilled for the installation of the energy management systems. The classification and provision of all verifications delayed the implementation process and the provision of a visualisation application for the end customers.

* *Lack of experience in customer attraction*

Apart from metering services and connection requests, DSOs have limited contact with end customers and usually do not advertise for private customers. As a result, they lack experience in appropriate marketing.

### 3.3.2 Mitigation Measures

To attract customers to the project, proactive communication, takeover costs and thus free participation of end users, were performed in the acquisition process. Additionally marketing material like a promoting video and townhall events were used to gather interest in the project. When the lack of interest among residents became apparent, further measures were planned.

Additional effort was made with an on-site campaign, which included door advertising in the selected grid regions, as well as promotional leaflets to convince more residents with flexibility resources to participate in the EUniversal project. However, this action did not lead to further participation interest which means that further mitigation measures had to be introduced. These include that potentials of flexibility markets are evaluated based on the number of customers present in the grid regions instead of using the actual volunteering residents. In addition, an internal acquisition of MITNETZ colleagues with inverters and batteries was sought to have more customers for the aggregation in the FSP tests. Table shows the final figures of the participating volunteers.

To still be able to build a portfolio out of the few participants, the local affiliation to the selected test grids was removed and thus the aggregation was separated from the market analysis allowing for conclusions for portfolio set-up and aggregation instead of market liquidity, which would not be representative without regulatory financial incentives. In other words, grid nodes of the EUniversal market analysis will include simulated customers. Instead, the possible market potentials and their effect on congestions in the low-voltage and upstream medium-voltage grids will be evaluated using the developed smart grid tools and measurement as well of meta data of the selected LV grid. Real interaction of FSP with end-users will also be part of the field test but will be evaluated in a separated test case. Results of this analysis will be shown in the final Deliverable 8.3 of the work package.
<table><caption>Table 3.7 - Overview of market liquidity and customers recruited</caption><thead><tr><th></th><th>MFn4420</th><th>MLq0094</th><th>Mli809</th><th>MITNETZ colleagues</th></tr></thead><tbody><tr><td><strong>Inverters</strong></td><td></td><td></td><td></td><td></td></tr><tr><td>...of which customers with interest</td><td>13</td><td>7</td><td>7</td><td>18</td></tr><tr><td>...of which compatible (monitoring)</td><td>5</td><td>1</td><td>2</td><td>9</td></tr><tr><td>...compatible incl. steering</td><td>2</td><td>0</td><td>0</td><td>5</td></tr><tr><td><strong>Batteries-</strong></td><td></td><td></td><td></td><td></td></tr><tr><td>...of which customers with interest</td><td>3</td><td>1</td><td>1</td><td>17</td></tr><tr><td>...compatible incl. steering</td><td>1</td><td>0</td><td>0</td><td>5</td></tr><tr><td><strong>Heat Pumps</strong></td><td></td><td></td><td></td><td></td></tr><tr><td>...of which customers with interest</td><td>2</td><td>1</td><td>1</td><td>5</td></tr><tr><td>...compatible incl. steering</td><td>0</td><td>0</td><td>0</td><td>0</td></tr><tr><td><strong>Heat Storages</strong></td><td></td><td></td><td></td><td></td></tr><tr><td>...of which customers with interest</td><td>-</td><td>2</td><td>6</td><td>-</td></tr><tr><td>...compatible incl. steering</td><td>-</td><td>-</td><td>-</td><td>-</td></tr><tr><td><strong>Wallboxes (+ EV)</strong></td><td></td><td></td><td></td><td></td></tr><tr><td>...of which customers with interest</td><td>-</td><td>-</td><td>-</td><td>4</td></tr><tr><td>...compatible incl. steering</td><td>-</td><td>-</td><td>-</td><td>1</td></tr></tbody></table>
# 4 Field test protocol

This report outlines the different tests and Demonstrator scenarios performed in task 8.2 to prove the reliability of each tool and tool results, and the operational processes required to comply with each tool's minimal viable product (MVP). Due to the complexity of the individual tools and systems as well as the entire flexibility value chain, in a first step every component of the flexibility value chain was tested individually to ensure a correct functioning and information exchange between connected tools, as well as the required data input and output according to the presented SUCs (Ch. 2.3.2).

## 4.1 Congestion Detection and Flexibility Need Quantification

In this chapter, the smart grid tools are briefly introduced. For further information, please refer to Deliverables 4.1 and 4.2 for the Smart Grid tools, as well as Deliverable 5.1 regarding market processes.

### 4.1.1 The Pythia tool: Day-ahead LV Congestion Forecast and Asset Headroom calculation - VITO

As already mentioned in the previous chapter, the first step in the flexibility value chain process is the forecast of possible congestions (day ahead). Forecasting congestions in the Low Voltage (LV) distribution grid is a challenging task, mainly due to the very stochastic behavior of end-consumers, and because the grid layout is partially unknown (namely, the exact phase connectivity of the single-phase connections is unknown).

These challenges are tackled by the LV congestion forecast tool in Pythia by taking a statistical approach. Pythia calculates the probability density of voltage and current levels within the network, using available knowledge on the network, and by considering the stochasticity of unknown variables. The tool assumes that the following aspects of the LV system are known and can be used as input to the tool:

* The LV grid layout

* High-level metadata on end-consumers (yearly offtake, connection capacity, etc.)

* Historic and recent connection profile measurements of a group of representative users (not necessarily connected to the same grid system)

* Weather forecasts

* Information on the flexible assets, as available to the DSO: the type, location, and power rating of the asset.

In a second step, Pythia calculates the available headroom capacity for a secure flexibility activation on the network. This headroom capacity indicates the maximal flexibility that can be activated from the flexible devices without creating congestions for every time step. The headroom capacity drops when the congestion probability increases.

Details on the calculations performed by Pythia can be found in Deliverable D8.1 of the project.
#### 4.1.1.1 Functional tests for input data correction

In a first phase of the German Demonstrator field test, functional tests were performed to make sure that correct and accurate forecast results are produced by the LV congestion forecast.

It is obvious that inaccuracies of the input data lead to inaccuracies in the output forecast. The most common inaccuracies found in LV network environments are errors in the grid layout. LV networks mostly consist of (not visible) underground network cables. This easily results in errors while digitalizing network layouts. Secondly, the electricity network is not static. Over time, the LV network changes, e.g., new feeders are added to the system, feeders are switched differently, or new customers are connected, and these changes must also be registered in the digital version of the network. Having an up-to-date digitalized grid layout available is crucial to perform an accurate congestion forecast.

A second source of inaccuracies of the input data is in the representativeness of historic connection profile measurements. If certain user groups are not or under-represented in the set of historical profiles, their electricity offtake pattern will not be captured by the congestion forecast tool and will thus lead to inaccurate congestion forecasts.

Related to this is the availability of accurate information on end-consumers' characteristics, and their flexible assets. When the offtake pattern of end-consumers changes, e.g., because photovoltaic panels are installed at their premises, their heating system is changed to a heat-pump, or their connection is used to charge an electric vehicle, this information must be known to obtain accurate congestion forecast results.

To evaluate the correct performance of the congestion forecasting tool, the forecasting results were compared with measurements installed in the field.

Figure 4.1 shows such comparison: the currents measured at the head of a specific feeder within the Demonstrator are compared with their forecast. The Pythia LV congestion forecasting tool gives a statistical forecast as result, and therefore the forecast is shown as a range, with a probability density. The congestion forecast using the original input dataset is shown on top (Figure 4.1a). This figure shows that the forecast is structurally underestimating the currents in the network, pointing to missing connections in the network data. After a careful check of the data, it was found that a few household loads were missing in the original data. Correcting for this error resulted in the congestion forecast result shown at the bottom (Figure 4.1b.), where the structural underestimation has disappeared.
<figure><img src="image_16.png" /><figcaption>**Figure 4.1-Evaluation of congestion forecasting tool: (a) using the original network layout and customer information; (b) using the corrected grid layout and network information for feeder Id. 67729182.**</figcaption></figure>

A second example of a case where inaccurate input data lead to inaccurate forecasting results is given in Figure 4.2. Similarly, the figure shows the currents measured at the feeder head, compared with the forecasting result, on top (Figure 4.2a.) using the original data input, and at the bottom (Figure 4.2b.) for the corrected data input. For this case, the original result showed an overestimation of the forecast. The reason for this overestimation was that the historical profiles were not representative enough. More specifically, the feeder supplies a larger commercial consumer, which appeared to be overestimated using the original grouping of historical profiles
and customers. Re-grouping of the historical profiles, and network customers according to their characteristics led to better and more representative forecasting result, shown in Figure 4.2b.

<figure><img src="image_17.png" /><figcaption>**Figure 4.2-Evaluation of congestion forecasting tool: (a) using the original network layout and customer information; (b) using the corrected grid layout and network information for feeder Id 327288.**</figcaption></figure>

An observation that can be made, when examining Figure 4.2 is the fact that the consumption of a (large) resource is missed in the congestion forecast. This offtake originates from a large electric heating system present in the network. This device is considered a flexible resource in the German Demonstrator and is not included in the forecast of the default consumption presented in Figure 4.2. This first phase of functional testing, where measurements and forecasts
were compared, allowed to correct inaccuracies in the overall input data set. This effort also
shows that Pythia can also be used to discover such errors in the grid data.

The impact of the flexible devices on the forecast accuracy is discussed in the next section.

### 4.1.1.2 Including flexibility resources in the LV congestion forecast and headroom calculation

Simultaneous activation of multiple flexible resources on the LV network, e.g., to solve issues on the MV level, could cause congestions on that LV network. Therefore, the available headroom capacity for secure flexibility activation on the network is calculated as a second step in the Pythia flexibility value chain. This headroom capacity indicates the maximal flexibility that can be activated by all flexible devices combined without creating congestions for every time step. The available headroom capacity is reduced when the congestion probability is too high.

The headroom calculation is executed for a worst-case scenario, and thus with the assumption that all flexibility resources are activated at the same time. To be able to do this calculation, the input data must contain the location of the flexible resources and their maximum power. Also, it is important to know whether the resources have a three-phase or single-phase connection, since the network impact of a device with a three-phase connection will be much lower than the impact of a single-phase connected device with the same power level.

The flexibility resources included in the calculation are:

* Heat pumps

* Electric heating systems

* Batteries

* Electric vehicles

* Photovoltaic installations

In Figure 4.3 this process is illustrated: the congestion forecast of the default consumption is shown together with the worst-case flexibility forecast for one feeder of the Demonstrator. In this figure it can be observed that the offtake of the flexibility resource(s) is not captured by the default congestion forecast but is contained within the worst-case flexibility forecast.
<figure><img src="image_18.png" /></figure>

<figure><img src="image_19.png" /><figcaption>Figure 4.3 - Congestion forecasting of feeder 67729185</figcaption></figure>

* Default consumption forecast, shown in red, and worst-case flexibility forecast, shown in blue.

In a second phase, the resulting worst-case flexibility forecast is transformed into a congestion risk, on which the headroom calculation is based.

The congestion risks are defined as overvoltage, undervoltage or overcurrent congestion risks, defined by the risk that the voltage or current anywhere in the network surpasses a predefined voltage or current limit. The predefined voltage and current limits are set at +/-5% of the rated voltage and at 80% of the current rating, respectively.

Given the existing voltage and current limits, very low congestion risks are found, even for worst-case flexibility situations for every feeder present in the Demonstrator. An illustration is shown in Figure 4.4: the congestion risks for the feeder and measurement period are virtually non-existent, leading to a calculated headroom which always equals the maximum flexibility available in the feeder. As mentioned above, photovoltaic installations are flexible assets since they can be curtailed. How much capacity is available to be curtailed depends on the solar irradiation which is variable throughout the day. Therefore, the maximal available flexibility (and consequently the headroom) can vary over time, also shown in Figure 4.4.
<figure><img src="image_20.png" /><figcaption>Figure 4.4 - Congestion risks and headroom calculation results for feeder 67729185</figcaption></figure>

In a following phase of the Demonstrator, artificial limits for network voltage and current will be defined such that congestion risks are detected in the Demonstrator-feeders (although in reality the grid is far from congested). These artificial limits will be defined to enable the operation of the full flexibility value chain during the pilot phase.

The choice of the artificial limits, used during the pilot phase, will be elaborated in the following deliverable D8.3, next to a discussion on the pilot measurements and the analysis of the pilot KPIs.

### 4.1.2 Day-ahead flexibility needs assessment tool development – KUL

The flexibility needs assessment tool tailor-made for the German demo under the framework of the EUniversal project can be divided into the following steps:

* Parsing the grid data [1], [2],

* Creation scenarios using representative load profiles for all the nodes [3],

* Formulation of the optimization problem for quantifying temporal and nodal flexibility needs for avoiding voltage and thermal violations [4], [5], [6], [3], [7], [1],

* Clustering tool for formation of zones [2], and

* Docker implementation of the tool.
### 4.1.2.1 DigSilent (DGS) Parser and scenario generation

A parser has been created to convert the DGS (DigSilent) file format into a JSON file that is readable to the PowerModels script. The parser is derived from the GridCal python package. The main difference between the two formats is that the DGS data format contains different classes with different information in a hierarchical structure, whereas the JSON file just requires information on the buses, branches, and devices in the grid. For additional details on the parser, refer to [2].

Future uncertainties are considered in the form of scenarios. The scenario generation uses historical data and point forecasts with known forecast errors. In the present case, large amount of historical data is unavailable, instead, a point forecast along with its associated forecast error is known. In such a case, a multivariate Gaussian distribution can be formed by using a point time-series forecast as the mean value and the variance of the distribution is proportional to forecast error [3].

### 4.1.2.2 Flexibility needs assessment (FNA)

Flexibility needs assessment (FNA)<fnref n="3" /> refers to the amount of flexibility the DSO needs to plan or procure from the flexibility market to avoid probable Distribution Network Incidents (DNI). The probable DNI are captured using modeling uncertainties, and using generated scenarios that emulate the different Monte Carlo realizations<fnref n="4" /> which could happen. The scenario generation utilizes the nodal load and generation forecast along with historical forecast errors. A flexibility needs assessment-optimal power flow (FNA-OPF) problem is solved for each of the scenarios. The robust FNA, considering the worst-case scenario, if used for flexibility procurement would lead to substantial over-procurement. In order to avoid this, a risk-based index, e.g. a chance constraint (CC), is introduced. Higher values of the CC would project on to greater risk the DSO might have to encounter by facing unresolved DNIs. DNIs in low voltage grids are often local problems in which flexible resources in the proximity may respond to avoid these incidents [4], [3], [7].

<footnote n="3">³ The FNA algorithm does not assume the location of flexible resources. Although we assume that flexibility is derived at nodes where there is a load or generation source connected. For all the nodes with no load and generation connected, flexibility (up and down regulation) is assumed to be zero. Flexibility for upregulation (derived from load curtailment or consumption increase) is available only at nodes with loads (positive consumption), while ramp-up flexibility is available not only at nodes with DG (negative consumption) but also nodes where nodal load can be increased by activating flexible loads.</footnote>

<footnote n="4">⁴ One scenario is one snapshot that could happen. To consider uncertainty, we use large number of scenarios, in the order of 100s. These scenarios are analogous to Monte Carlo realizations of the uncertain parameters.</footnote>
<figure><img src="image_21.png" /><figcaption>Figure 4.5 - Flexibility needs assessment with the input and the output data</figcaption></figure>

### 4.1.2.3 Clustering and Zonal FNA

Identifying the zones of an LV DN will help the DSO in planning the flexibility needs of a network. The proposed zone formation solves the following challenges:

a. the formation of connected zones requires an incidence matrix-based measure; therefore, we consider admittance as a measure

b. the admittance matrix cannot be used directly; therefore, spectral decomposition of a doubly stochastic matrix is used, and

c. the selection of the appropriate number of zones is not known a priori.

To apply unsupervised clustering techniques such as k-means, one should know how many clusters are needed. We use the silhouette score as a measure for identifying the best number of clusters [3], [2].

### 4.1.2.4 Docker implementation

There are three elements that make up the code base. There is code written in Python, in Julia, and everything is implemented to work in one Docker environment. A brief overview will only be provided here and can be seen in Figure 4.6. The primary functions of the python code are:

1. A parser from digsilent files to matpower/powermodels files

2. A scenario generation script

3. Volume for data exchange between docker container #1 and #2

The primary function of the Julia script is to take the grid information and the different scenarios and generate a Nodal day ahead load profile for each bus.
<figure><img src="image_22.png" /><figcaption>Figure 4.6 - Docker architecture</figcaption></figure>

4.1.2.5 Numerical results for MLq0096

The goal of the case study is to apply the FNA framework for MLq0096. This numerical case study considers a real suburban German DN used for EUniversal demo. This demo network consists of 646 nodes and 331 loads are connected to the DN. Figure 4.7 shows the DN with 7 clusters identified using the DN clustering framework developed under EUniversal project [2].

<figure><img src="image_23.png" /><figcaption>Figure 4.7 - German DN Mlq0094 with zonal clusters</figcaption></figure>
<figure><img src="image_24.png" /><figcaption>**Figure 4.8 - Measurement points (in yellow) and consumers (in blue dots) for MLq0094**</figcaption></figure>

The load profiles are selected from a pool of historical load profiles based on prosumer meta-data such as annual kWh, and PV size installed. Based on historical data, the load profile forecast error is assumed to be 30% and PV generation forecast error of 40% is used for scenario generation. Based on these scenarios, the FNA is calculated. The temporal flexibility needs are shown in Figure 4.9. Note from Figure 4.9 that the ramp-up flexibility needs of this DN are both zero, as the PV penetration, in this case, was very low. The total installed PV is 61 kWp and the annual kWh served exceeds 923 MWh.

<figure><img src="image_25.png" /><figcaption>**Figure 4.9 - Day-ahead temporal flexibility needs for German DN.**</figcaption></figure>

Figure 4.10 shows the impact of chance constraint (CC) on the amount of flexibility needed. The CC level denotes the risk system operator wills to take in flexibility planning. A low value of CC denotes low risk but that leads to a high amount of flexibility needs. The pareto optimal point for these two conflicting goals is shown in Figure 4.10 [3].
<figure><img src="image_26.png" /><figcaption>**Figure 4.10 - Tuning CC level using Pareto optimality**</figcaption></figure>

Figure 4.11 shows the zonal FNA for the DN. Observe that most flexibilities needed are in zone 1, 3, and 4; all these zones are congested at the end of feeders. More than 80% (30.04, 30.45, 19.33% respectively) of the flexibility needed are in these three zones.

<figure><img src="image_27.png" /><figcaption>**Figure 4.11 - Temporal flexibility needs are calculated in a DA horizon**</figcaption></figure>

#### 4.1.2.6 Numerical results for MFn4420

The second demonstration network used is called MFn4420. The zonal clustering, location of measurement points and zonal FNA calculated for MFn4420 are shown in Figure 4.11 - Temporal flexibility needs are calculated in a DA horizon (Figure 4.14).
<figure><img src="image_28.png" /><figcaption>Figure 4.12 - Zonal cluster for demonstration network MFn4420</figcaption></figure>

<figure><img src="image_29.png" /><figcaption>Figure 4.13 - Measurement points (yellow dots) and consumers (blue dots) for MFn4420</figcaption></figure>

<figure><img src="image_30.png" /><figcaption>Figure 4.14 - Zonal FNA for MFn4420</figcaption></figure>

Note from Figure 4.14 that most of the flexibility is needed in zones 1, 2, and 13. Since the consumers do not have large amounts of distributed generation in this test case, we observe
the flexibility needs in down regulation or load curtailment only. No instances of generation curtailment needs were observed in the simulations.

For both sets of numerical results, the DN congestion is induced by inflating the representative load profiles, so FNA for the demonstration network can be quantified. Under normal loading conditions, we did not observe any voltage violations or congested lines, thus no flexibility was needed.

### 4.1.3 Data-driven State Estimator (DdSE) - INESC

The Data-driven State Estimator (DdSE) provides the most likely state of the grid, comprising voltages and active powers, departing from a subset of meters that communicate in real time and supported by historical data. This means that the real-time monitoring of a grid is achieved without a heavy communications infrastructure and without replacing all meters by technologies capable of broadcasting their measurements in real time.

In the current implementation of this LV monitoring Demonstrator, meters are split as follows:

* 10 meters communicate voltage and active power every 30 minutes.

* 47 meters store their readings of voltage and active power and communicate them by the end of the day.

The arrival of a new set of real-time measurements (every 30m) triggers the DdSE to reconstruct a new state of the system. The voltage estimations for two connection points of the Demonstrator grid over 10 days are shown in Figure 4.15 and Figure 4.16. According to the results, it is evident that the tool is highly reliable in providing estimations that closely match the actual values. This degree of accuracy offers significant reassurance to the system operator, as it enhances its ability to make informed decisions about the system's operations.

<figure><img src="image_31.png" /><figcaption>**Figure 4.15 - Comparison between estimated and real voltage values for one smart meter connected to phase a, over the period of 10 days**</figcaption></figure>
<figure><img src="image_32.png" /><figcaption>Figure 4.16 - Comparison between estimated and real voltage values for one smart meter connected to phase c, over the period of 10 days.</figcaption></figure>

At the current stage of integration of the following metrics characterize the accuracy of the estimations when evaluating 10 days of estimations:

* Maximum absolute deviation (MAD): 4.0110 V

* Mean average error (MAE): 0.4817 V

* Maximum square error (MSE): 0.4530 V

As the amount of historical data grows in the coming months, the algorithm will have more data to analyze and find patterns that can help reconstruct the system state more accurately. This increase in data is expected to lead to improvements in the metrics used to evaluate the algorithm's performance. In addition, with a sufficiently large dataset, the algorithm will be able to estimate active power injections, further enhancing its capabilities.

## 4.2 Market-based flexibility service selection and activation

The market-based procurement process in the Demonstrator is set up according to the digital flexibility value chain, illustrated in Figure 4.17, with the DSO MITNETZ STROM as a buyer, Centrica as Flexibility Service Provider (FSP), NODES as independent market operator and the UMEI as standard communication interface to enable the connection of the DSOs to multiple market platforms. N-SIDE's optimal bid recommender is interconnected on the buyer's side to ensure the selection of the most effective flexibility service for the specific grid problem as outlined in deliverable D8.1.
<figure><img src="image_33.png" /><figcaption>**Figure 4.17 - Digital Flexibility value chain (www.nodesmarket.com)**</figcaption></figure>

### 4.2.1 Optimal Bid Recommender - N-SIDE

At regular intervals, the DSO will launch the N-SIDE Optimal Bid Recommender (OBR) tool that will analyse and identify the combination of bids that solves as many congestions as possible and at the lowest price. Based on the output of the Optimal Bid Recommender (OBR), the DSO will then be able to submit 'buy' orders that match the recommended 'sell' orders on the market platform.

At every call, the Optimal Bid Recommender (running on the servers of the DSO) will receive the needed inputs, which can be separated into three categories (Figure 4.18)

- The grid static data: macro view of the topology (i.e. which zones are connected)

- The grid state forecast (dynamic): headroom per transformer, headroom per feeder

- The market-related information: baseline of each flexible asset, flexibility bids (price and volume)

Once all the required information is gathered, a market-clearing engine will determine the optimal bids to select to resolve the identified grid congestions at minimum costs for the DSO. This process is based on a mathematical optimization problem.
<figure><img src="image_34.png" /><figcaption>Figure 4.18 - Inputs and Outputs of the N-SIDE Optimal Bid Recommender</figcaption></figure>

Once a solution is found, the bids to be selected are transmitted to the DSO. Then, the DSO will connect to the flexibility market via the UMEI to activate the sell offers by submitting a corresponding buy order. In case some congestions cannot be solved with the flexibility offers available on the market (i.e. not enough flexibility is offered), the DSO needs will anyway be able to leverage the N-SIDE tool by publishing the exact missing needs on the market platform through flexibility ‘buy’ offers. In that case, the DSO will choose the price of these offers beforehand without recommendation of the OBR, likely based on a limit price allowed by the regulation.

To ensure the tool is working correctly, we conducted several test sets. These tests included checks of individual functions of the algorithm (unitary tests) and verification of the entire tool’s functionality with different input scenarios (functional/system tests). We used a test set of 30 scenarios with varying numbers of periods, headrooms and orders. The 30 scenarios passed according to all test success criteria defined, i.e. correct selections of bids, optimality of the solution proved and short sufficient computation time.

### 4.2.2 Flexibility service provider – Centrica

Centrica has the role of the FSP in the German Demonstrator and offers the flexibility services of one or multiple resource(s) through aggregation to system operators via a flexibility market. In this Demonstrator, flexibility should be provided for the DSO (MNS), while NODES is the Flexibility Market Operator (FMO).

The activities of FSP to provide flexibility for DSO in this Demonstrator can be divided into two categories:

* Category 1: random activities

- Registering flexible assets in the market platform and assigning them to a portfolio. This activity will be done in the beginning of the field test or will be repeated when a new flexible asset is available in one of the test grid zones of the Demonstrator.

- Developing the mathematical model for different type of flexible assets, which help afterward with the calculation of optimal bid.
## Category 2: Regular activities

Figure 4.19 Figure 4.19 illustrates different processes included in this category.

- Solving optimization to calculate optimal bid for each portfolio. The output of this optimization included the optimal flexibility volume together with its optimal cost to be offered via UMEI to FMO.

- Calculating the baseline for each portfolio and submit it to the FMO via the UMEI. Depending on the type of flexible asset and available historical data set, different methods can be used to calculate the baseline (as no standardized convention for baseline calculation is in place at this point).

- Receiving the trades information from the market via the UMEI and dispatching and disaggregating them to the flexible assets to deliver the activated flexibility. The Home energy management system (HEMS) will enable the interaction between Centrica's dispatch tool and the real flexible assets.

- Receiving sub-metering data via the HEMS to calculate flexibility and to monitor the real-time delivery of the flexibility.

<figure><img src="image_35.png" /><figcaption>Figure 4.19 - Organization of data flows and asset steering in the German Demonstrator</figcaption></figure>

### 4.2.3 Market-based flexibility procurement on NODES market platform via the UMEI

NODES as independent market operator provides the central environment for market-based procurement of flexibility in this Demonstrator ensuring correct and transparent transactions between buyers and sellers (without consideration of the post-trading activities, ie. validation and settlement, as these functionalities are not yet implemented in the UMEI V01. Using NODES integrated market design, shown in Figure 4.20, flexibility can be offered bottom-up and bought top-down allowing for an efficient use of available flexibility resources across all grid levels. Due to limited market liquidity at this point in time, NODES only applies a continuous market clearing via pay-as-bid.
<figure><img src="image_36.png" /><figcaption>**Figure 4.20 - NODES integrated market design (www.nodesmarket.com)**</figcaption></figure>

NODES flexibility market covers all necessary services related to each trading phase, i.e. registration and prequalification, flexibility procurement, and validation and settlement. Validation and settlement, however, will not be tested in the German Demonstrator because the major focus was setting up the operational flexibility value chain and the realization of market-based flexibility trading via the UMEI.

Due to the limited customer participation an initially defined KPI to reflect the market liquidity was not used as performance indicator.

### 4.2.3.1 Integration of NODES market platform and the UMEI

The functionalities required for the FMO and UMEI integration can be broadly divided into two categories:

* Category 1: Random operations: Registration & prequalification (grid data and nodes/asset data)

* Category 2: Regular/repetitive operations: Trading operations, baseline and meter readings registration and update

Due to the focus on the integration of the entire flexibility value chain for market-based flexibility procurement, and time constraints, only functionalities of category 2 have been implemented in the first version of the UMEI (Technical details about each operation and related functions are published in the UMEI API management and documentation (D2.4 - 2.6)). Therefore, operations of category 1 have been performed directly via NODES graphical user interface or NODES API. The main operations of category 2 have been tested on the NODES market platform via the UMEI API:

* Communicating demand for flexibility: DSOs and other market participants communicate their demand for flexibility by posting buy orders. Each buy order is connected to a specific previously defined node in the grid.
* Communicating availability of flexibility: FSPs communicate their availability of flexibility by posting sell orders. Each sell order is connected to an asset portfolio. Every asset is assigned to a specific grid node. The UMEI will support posting buy orders, fetching the user-specific orders, and deleting (deactivating) orders.

* Registering baselines for asset portfolios that participate in the market: Baselines are planned/forecasted power consumption and/or production profiles without activation of flexibility of a portfolio that must be submitted by FSPs together with a sell order. The UMEI will support registering/fetching/deleting baselines.

* Registering meter readings for asset portfolios: Meter readings represent actual measured power consumption and/or production of a portfolio. However, submission/fetching of meter reading is not supported by the UMEI V01 and hence not part of the tested scenarios

* Receiving notifications: NODES market allows for the configuration of notifications of specific information such as upon a match of corresponding buy and sell orders, specific order submission etc. This option was also implemented in the UMEI.

#### 4.2.3.2 Field test: Registration and prequalification

The operational steps categorized into of category 1 Registration and preregistration were conducted using NODES graphical user interface and API.

The system operator registers the grid license area on Nodes market platform and sets up the flexibility markets. The system operator thereby chooses the granularity and amount of detail required to effectively activate flexibility from distributed assets to solve local or regional grid congestions. The FSP(s) register the assets in the respective license area providing the geographic coordinates of the assets, installed capacity or max. available flexibility and the meterpoint ID. As a final step the system operator confirms the registered assets by assigning them to a grid node. Following this protocol, the flexibility markets that were tested in the Mitnetz license area are represented on NODES flexibility market as shown in Figure 4.21. Each feeder is represented by a grid node (circle) where the size of each grid node represents the respective MV and LV feeders and the associated order book (to activate the flexibility of DER assets. Dashed lines indicate connected grid nodes allowing flexibility to be activated in connected grid nodes. Congested grid areas and the associated grid node are marked in red. Figure 4.22 shows a detailed view on the registered assets at LV grid node KV Nordstr. /Wurzener Str. 7260/MV feeder MFn4420.
<figure><img src="image_37.png" /><figcaption>Figure 4.21 - Mitnetz license areas MV feeder MLq0094 (above) and MV feeder MFn4420 (below) and associated LV feeders on NODES market platform.</figcaption></figure>
<figure><img src="image_38.png" /><figcaption>Figure 4.22 - Detailed representation of registered assets at LV grid node KV Nordstr. /Wurzener Str. 7260/MV feeder MFn4420</figcaption></figure>

On the NODES market platform, a grid node corresponds to an order book (Figure 4.23). The flexibility procurement via the market platform is conducted in the order book that corresponds to the grid node where the congestion was identified.

<figure><img src="image_39.png" /><figcaption>Figure 4.23 - Order book structure according to the grid node organization in the Mitnetz license area</figcaption></figure>

#### 4.2.3.3 Field test: Flexibility trading

The following operational steps form part of category 2 and are conducted via the UMEI. The UMEI API orders for every operation are presented in Tables 4.1 to 4.3

Two test series were performed involving Mitnetz, Centrica and NODES:
1) UMEI API In-Depth Functional Testing using Postman and the Swagger UI (Table 4.1 and Table 4.2); to ensure a) the correct integration of the UMEI with the NODES market platform and b) that all operations and related functions that a relevant for the actual trading phase are performing correctly;

2) Concrete trading scenarios between FSP (Centrica), FMO (NODES) and DSO (Mitnetz) to verify the correct market operation and matching while considering the common components to characterize the requested or offered flexibility, ie. location, volume and price (Table 4.3).

Test series 1:

<table><caption>Table 4.1 - Token-based authentication of the client</caption><thead><tr><td>ID</td><td>Function Name</td><td>HTTP Method</td><td>Endpoint</td><td>Request description</td><td>Response Code / Status</td><td>Response description</td></tr></thead><tbody><tr><td>A.1</td><td>Verify the authentication (request for OAuth2 access token)</td><td>POST</td><td>Authorization endpoint</td><td>Require access to the UMEI – initiate request for Access Token after client id and client secret are acquired.</td><td>200 OK</td><td>Authentication is successful - Access Token issued, access to resources is granted.</td></tr><tr><td>A.2</td><td>Verify the Access Token</td><td>GET, POST, DELETE, PATCH, PUT</td><td>Test API URLs</td><td>Request access to appropriate resources using Access Token</td><td>200 OK</td><td>Access Token is accepted and validated. The required resources are returned as a response.</td></tr></tbody></table>

<table><caption>Table 4.2 - Basic requests</caption><thead><tr><td>ID</td><td>Function Name</td><td>HTTP Method</td><td>Endpoint</td></tr></thead><tbody><tr><td colspan="4">Portfolio</td></tr><tr><td>P.1</td><td>Get all available asset portfolios</td><td>GET</td><td>/portfolios</td></tr><tr><td>P.2</td><td>Get an asset portfolio by Id</td><td>GET</td><td>/portfolios/{id}</td></tr><tr><td>P.3</td><td>Post a new DSO/FSP asset portfolio on the platform</td><td>POST</td><td>/portfolios</td></tr><tr><td>P.4</td><td>Partially update (updating particular fields) an existing DSO/FSP asset portfolio by Id</td><td>PATCH</td><td>/portfolios/{id}</td></tr></tbody></table>
<table><tr><td>P.5</td><td>To replace an existing DSO/FSP asset portfolio entirely by Id</td><td>PUT</td><td>/portfolios/{id}</td></tr><tr><td>P.6</td><td>Delete an existing DSO/FSP asset portfolio</td><td>DELETE</td><td>/portfolios/{id}</td></tr><tr><td colspan="4">Baselines</td></tr><tr><td>B.1</td><td>Post a new baseline interval for DSO/FSP asset portfolio</td><td>POST</td><td>/BaselineIntervals</td></tr><tr><td>B.2</td><td>Partially update an existing DSO/FSP baseline interval</td><td>PATCH</td><td>/BaselineIntervals/{id}</td></tr><tr><td>B.3</td><td>Replace an existing DSO/FSP baseline interval</td><td>UPDATE</td><td>/BaselineIntervals/{id}</td></tr><tr><td>B.4</td><td>Delete a DSO/FSP baseline interval from the platform by Id</td><td>DELETE</td><td>/BaselineIntervals/{id}</td></tr><tr><td>B.5</td><td>Get all portfolio baselines available for DSO/FSPs incl. FSPs/DSOs submitted</td><td>GET</td><td>/BaselineIntervals</td></tr><tr><td>B.6</td><td>Get a baseline interval by Id</td><td>GET</td><td>/BaselineIntervals/{id}</td></tr><tr><td colspan="4">Market information</td></tr><tr><td>M.1</td><td>Get all markets registered on the market platform</td><td>GET</td><td>/Markets</td></tr><tr><td colspan="4">Orders</td></tr><tr><td>O.1</td><td>Get all public orders on the market platform</td><td>GET</td><td>/PublicOrders</td></tr><tr><td>O.2</td><td>Get all existing orders on the market platform</td><td>GET</td><td>/Orders</td></tr><tr><td>O.3</td><td>Get an existing order by Id</td><td>GET</td><td>/Orders/{id}</td></tr><tr><td>O.4</td><td>Submit a new buy/sell order by DSO/FSP</td><td>POST</td><td>/Orders</td></tr><tr><td>O.6</td><td>Update an existing order from the market platform</td><td>PUT</td><td>/Orders/{id}</td></tr><tr><td>O.7</td><td>Delete an existing order from the market platform</td><td>DELETE</td><td>/Orders/{id}</td></tr><tr><td colspan="4">Trades</td></tr><tr><td>T.1</td><td>Get all available trades on the platform</td><td>GET</td><td>/Trades</td></tr><tr><td colspan="4">Flexibility zone</td></tr><tr><td>F.1</td><td>Post a new flexibility zone</td><td>POST</td><td>/FlexibilityZones</td></tr><tr><td>F.2</td><td>Get all flexibility zones on the market platform</td><td>GET</td><td>/FlexibilityZones</td></tr><tr><td colspan="4">Meter Readings</td></tr><tr><td>MR.1</td><td>Post a new meter reading</td><td>POST</td><td>/MeterReadings</td></tr><tr><td>MR.2</td><td>Get all meter readings</td><td>GET</td><td>/MeterReadings</td></tr></table>

Task F.1 and F.2 were not tested in the German Demonstrator and instead inserted manually via NODES UI. The tasks MR.1 and MR.2 were not tested as the data at the point of connection to the grid will be provided by HEMS directly and Smart Meter rollout in the grid area of the German Demonstrator is scarce.

On NODES market platform every grid node corresponds to an orderbook. As such the DSO can procure the flexibility according to the inserted grid structures (Figure 4.24).
<figure><img src="image_40.png" /><figcaption>Figure 4.24 - NODES Market Platform: Trading in MFn4420 Orderbook</figcaption></figure>

Table 4.3 provides an overview of the testes market scenarios:

* Scenarios A+B cover the submission of order by all market participants in different order books considering different flexibility volumes and the direction of the regulated flexibility (up/down regulation).

* Scenario C was performed as a consequence of the scenarios A+B ensuring the correct submission of baselines for each sell order that has been created in scenarios A+B. The baselines are accessible as csv files.

* Scenario E was tested to prevent incorrect matching of orders.

* Scenario F was performed to ensure the correct purchase of flexibility across different grid levels via connected order books.

* Scenarios G serve to facilitate the operational routine for the DSO to get an overview of the flexibility offers and to feed the information into the optimal bid recommender to select the optimal offer for the respective grid problem.

* The notification function on NODES platform (Scenario H) was tested to configure the messaging service according to the needs of each market participant.

* Ultimately, all transactions were exported in Scenario J
<table><caption>Table 4.3 - Trading scenarios</caption><thead><tr><th>Scenario</th><th>Scenario</th><th>Role</th><th>Action</th><th>Grid Area</th><th>Time (CET)</th><th>Quantity [MW]</th><th>Direction</th><th>Price [€/MW]</th><th>UMEI API function</th></tr></thead><tbody><tr><td rowspan="2">Scenario A)</td><td rowspan="2">Offer FSP, need DSO on same grid area</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>A.1</td><td>FSP</td><td>Sell Order</td><td>MLq0094</td><td>17.06.2022 10am-2pm</td><td>3 down</td><td></td><td>10 POST/Orders</td><td></td></tr><tr><td></td><td></td><td>DSO</td><td>Match Order</td><td>MLq0094</td><td>17.06.2022 10am-2pm</td><td>3 down</td><td></td><td>10 POST/Orders</td><td></td></tr><tr><td rowspan="2">A.2</td><td></td><td>FSP</td><td>Sell Order</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>17.06.2022 5pm-7pm</td><td>2 up</td><td></td><td>8 POST/Orders</td><td></td></tr><tr><td></td><td>DSO</td><td>Match Order</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>17.06.2022 5pm-7pm</td><td>2 up</td><td></td><td>8 POST/Orders</td><td></td></tr><tr><td rowspan="2">A.3</td><td></td><td>FSP</td><td>Sell Order</td><td>9 - KV Nordstr./Wurzener Str. 7260</td><td>17.06.2022 6am-7am</td><td>5 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td></td><td>DSO</td><td>Match Order</td><td>9 - KV Nordstr./Wurzener Str. 7260</td><td>17.06.2022 6am-7am</td><td>5 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td rowspan="2">Scenario B)</td><td rowspan="2">Offer DSO, need FSP on same grid area</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>B.1</td><td>DSO</td><td>Buy Order</td><td>MFn4420</td><td>18.06.2022 10am-2pm</td><td>3 down</td><td></td><td>10 POST/Orders</td><td></td></tr><tr><td></td><td></td><td>FSP</td><td>Match Order</td><td>MFn4420</td><td>18.06.2022 10am-2pm</td><td>3 down</td><td></td><td>10 POST/Orders</td><td></td></tr><tr><td rowspan="2">B.2</td><td></td><td>DSO</td><td>Buy Order</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>18.06.2022 5pm-7pm</td><td>2 up</td><td></td><td>8 POST/Orders</td><td></td></tr><tr><td></td><td>FSP</td><td>Match Order</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>18.06.2022 5pm-7pm</td><td>2 up</td><td></td><td>8 POST/Orders</td><td></td></tr><tr><td rowspan="2">B.3</td><td></td><td>DSO</td><td>Buy Order</td><td>MV Feeder MFn4420</td><td>18.06.2022 6am-7am</td><td>5 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td></td><td>FSP</td><td>Match Order</td><td>MV Feeder MFn4420</td><td>18.06.2022 6am-7am</td><td>5 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td rowspan="2">Scenario C)</td><td rowspan="2">Baselining</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>C.1</td><td>FSP</td><td>Send Baselines</td><td>MLq0094</td><td>19.06.2022 10am-2pm</td><td></td><td></td><td></td><td>POST/BaselineIntervals</td></tr><tr><td></td><td></td><td>DSO</td><td>Get Baselines</td><td>MLq0094</td><td>19.06.2022 10am-2pm</td><td></td><td></td><td></td><td>GET/BaselineIntervals/(id)</td></tr><tr><td rowspan="2">C.2</td><td></td><td>FSP</td><td>Send Baselines</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>19.06.2022 5pm-7pm</td><td></td><td></td><td></td><td>POST/BaselineIntervals</td></tr><tr><td></td><td>DSO</td><td>Get Baselines</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>19.06.2022 5pm-7pm</td><td></td><td></td><td></td><td>GET/BaselineIntervals/(id)</td></tr><tr><td rowspan="2">C.3</td><td></td><td>FSP</td><td>Send Baselines</td><td>9 - KV Nordstr./Wurzener Str. 7260</td><td>19.06.2022 6am-7am</td><td></td><td></td><td></td><td>POST/BaselineIntervals</td></tr><tr><td></td><td>DSO</td><td>Get Baselines</td><td>9 - KV Nordstr./Wurzener Str. 7260</td><td>19.06.2022 6am-7am</td><td></td><td></td><td></td><td>GET/BaselineIntervals/(id)</td></tr><tr><td rowspan="2">Scenario D)</td><td rowspan="2">Offer DSO, Counteroffer FSP</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>D.1</td><td>DSO</td><td>Buy Order</td><td>MFn4420</td><td>20.06.2022 10am-2pm</td><td>3 down</td><td></td><td>10 POST/Orders</td><td></td></tr><tr><td></td><td></td><td>FSP</td><td>Sell Order</td><td>MFn4420</td><td>20.06.2022 10am-2pm</td><td>3 down</td><td></td><td>13 POST/Orders</td><td></td></tr><tr><td rowspan="2">D.2</td><td></td><td>DSO</td><td>Buy Order</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>20.06.2022 5pm-7pm</td><td>2 up</td><td></td><td>8 POST/Orders</td><td></td></tr><tr><td></td><td>FSP</td><td>Sell Order</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>20.06.2022 5pm-7pm</td><td>1 up</td><td></td><td>8 POST/Orders</td><td></td></tr><tr><td rowspan="2">D.3</td><td></td><td>DSO</td><td>Buy Order</td><td>MV Feeder MFn4420</td><td>20.06.2022 6am-7am</td><td>5 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td></td><td>FSP</td><td>Sell Order</td><td>MV Feeder MFn4420</td><td>20.06.2022 6am-7am</td><td>8 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td rowspan="2">Scenario E)</td><td rowspan="2">Offer FSP, Counteroffer DSO</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>E.1</td><td>FSP</td><td>Sell Order</td><td>MLq0094</td><td>21.06.2022 10am-2pm</td><td>3 down</td><td></td><td>10 POST/Orders</td><td></td></tr><tr><td></td><td></td><td>DSO</td><td>Buy Order</td><td>MLq0094</td><td>21.06.2022 10am-2pm</td><td>3 down</td><td></td><td>13 POST/Orders</td><td></td></tr><tr><td rowspan="2">E.2</td><td></td><td>FSP</td><td>Sell Order</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>21.06.2022 5pm-7pm</td><td>2 up</td><td></td><td>8 POST/Orders</td><td></td></tr><tr><td></td><td>DSO</td><td>Buy Order</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>21.06.2022 5pm-7pm</td><td>1 up</td><td></td><td>8 POST/Orders</td><td></td></tr><tr><td rowspan="2">E.3</td><td></td><td>FSP</td><td>Sell Order</td><td>9 - KV Nordstr./Wurzener Str. 7260</td><td>21.06.2022 6am-7am</td><td>5 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td></td><td>DSO</td><td>Buy Order</td><td>9 - KV Nordstr./Wurzener Str. 7260</td><td>21.06.2022 6am-7am</td><td>8 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td rowspan="2">Scenario F)</td><td rowspan="2">DSO MV need, FSP LV Offers</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>F.1</td><td>FSP</td><td>Sell Order</td><td>6 - KV Ebereschenweg</td><td>22.06.2022 10am-2pm</td><td>3 down</td><td></td><td>10 POST/Orders</td><td></td></tr><tr><td></td><td></td><td>DSO</td><td>Buy Order</td><td>MFn4420</td><td>22.06.2022 10am-2pm</td><td>20 down</td><td></td><td>10 POST/Orders</td><td></td></tr><tr><td rowspan="2">F.2</td><td></td><td>FSP</td><td>Sell Order</td><td>6 - KV Ebereschenweg</td><td>22.06.2022 5pm-7pm</td><td>2 up</td><td></td><td>10 POST/Orders</td><td></td></tr><tr><td></td><td>DSO</td><td>Buy Order</td><td>MV Feeder MFn4420</td><td>22.06.2022 5pm-7pm</td><td>15 up</td><td></td><td>8 POST/Orders</td><td></td></tr><tr><td rowspan="2">F.3</td><td></td><td>FSP</td><td>Sell Order</td><td>5 - KVS Goethe-Str./Körner-Str.</td><td>22.06.2022 6am-7am</td><td>5 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td></td><td>DSO</td><td>Buy Order</td><td>MLq0094</td><td>22.06.2022 6am-7am</td><td>25 up</td><td></td><td>9 POST/Orders</td><td></td></tr><tr><td rowspan="2">Scenario G)</td><td rowspan="2">Export all bids from Market</td><td></td><td></td><td></td><td></td><td></td><td></td><td></td><td></td></tr><tr><td>G.1</td><td>FSP</td><td>Send Bids</td><td>MLq0094</td><td>19.06.2022 10am-2pm</td><td>-</td><td>-</td><td>-</td><td>POST/Orders</td></tr><tr><td></td><td></td><td>DSO</td><td>Get Bids</td><td>MLq0094</td><td>19.06.2022 10am-2pm</td><td>-</td><td>-</td><td>-</td><td>GET/Orders</td></tr><tr><td rowspan="2">G.2</td><td></td><td>FSP</td><td>Send Bids</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>19.06.2022 5pm-7pm</td><td>-</td><td>-</td><td>-</td><td>POST/Orders</td></tr><tr><td></td><td>DSO</td><td>Get Bids</td><td>1 - KV Hainbuchenallee/Gerichshain</td><td>19.06.2022 5pm-7pm</td><td>-</td><td>-</td><td>-</td><td>GET/Orders</td></tr><tr><td rowspan="2">G.3</td><td></td><td>FSP</td><td>Send Bids</td><td>9 - KV Nordstr./Wurzener Str. 7260</td><td>19.06.2022 6am-7am</td><td>-</td><td>-</td><td>-</td><td>POST/Orders</td></tr><tr><td></td><td>DSO</td><td>Get Bids</td><td>9 - KV Nordstr./Wurzener Str. 7260</td><td>19.06.2022 6am-7am</td><td>-</td><td>-</td><td>-</td><td>GET/Orders</td></tr></tbody></table>
# 5 Conclusion and Outlook

This report documents the technical and operational integration of each tool and market component into the Mitnetz system to ensure a reliable and secure data exchange and interoperability between the systems. Furthermore, each smart grid tool, test set and result are presented to explain the objective and functioning of each tool for the purpose of congestion detection and flexibility need assessment to prove the reliability and accuracy of each tool considering the available data and data quality. The market participants interacting in the framework of market-based flexibility procurement presented their tools and platforms that are designed to facilitate the access to DERs for DSOs while aiming for an overall optimization in terms of use of resources, bid selection and cost minimization. Specific scenarios are tested to ensure the operational reliability between the systems via the UMEI, NODES UI and NODES API and to simulate trading scenarios.

The conducted test sets per tool and in the market environment successfully accomplished the initially defined MVPs, proving the usability within the digital flexibility value chain despite of limited data availability and partly regular quality of data sets to achieve the desired accuracy. Furthermore, the low number of participants and as such more diverse prosumer asset types and load profiles impedes the replication of more realistic scenarios in terms of grid load patterns, potential congestions and thus market situations in the tested grid areas.

This scarcity of data may be reduced through the progress of the Smart meter roll-out in Germany and enhanced, simplified, and standardized installation of HEMS and BEMS. Furthermore, current regulatory barriers affecting the implementation of flexibility markets such as grid tariff structure, taxation scheme as well as flexibility asset categorization disincentivizes industrial and residential prosumers to offer their flexibility for grid management.

The next step of the German Demonstrator will be the examination of the entire digital flexibility value chain as a combined process of all tools and market components. The objective is to evaluate the tool and system performance as well as numerical results using the common EUniversal project KPIs and the KPIs defined for the German Demonstrator. The results will be described in detail in D8.3.
# 6 References

[1] M. U. Hashmi, A. Koirala, R. Lundholm, H. Ergun and D. V. Hertem, "Evaluation of voltage magnitude-based unbalance metric for low voltage distribution networks," in *IEEE Power & Energy Society General Meeting (PESGM)*, Denver, Colorado, USA, 2022.

[2] M. U. Hashmi, D. Brummund, R. Lundholm, A. Koirala and D. V. Hertem, "Consensus based phase connectivity identification for distribution network with limited observability," *Sustainable Energy, Grids and Networks*, 2023.

[3] M. U. Hashmi, A. Koirala, H. Ergun and D. V. Hertem, "Robust flexibility needs assessment with bid matching framework for distribution network operators," *Sustainable Energy, Grids and Networks*, 2023.

[4] M. U. Hashmi, A. Koirala, H. Ergun and D. V. Hertem, "Flexible and curtailable resource activation in a distribution network using nodal sensitivities," in *International conference on smart energy systems and technologies (SEST)*, Finland, 2021.

[5] M. U. Hashmi, A. Koirala, H. Ergun and D. V. Hertem, "Flexible and curtailable resource activation in three-phase unbalanced distribution networks," *Electric Power Systems Research*, 2022.

[6] M. U. Hashmi, A. Koirala, H. Ergun and D. V. Hertem, "Perspectives on distribution network flexible and curtailable resource activation and needs assessment," *IEEE Transactions on Industry Applications*, 2023.

[7] M. U. Hashmi, A. Koirala, H. Ergun and D. V. Hertem, "Flexibility needs assessment for distribution networks," in *Risk Days*, London, 2023.

[8] C. Hauk, "Systemstudie Flexibilität Projektangebot für E.ON SE im Rahmen der SDES Roadmap," *RWTH Aachen University*, 2022.
# 7 Annex

<table><caption>Table 7.1 - Overview internal data exchange</caption><thead><tr><th rowspan="2">Phase</th><th rowspan="2">Step</th><th rowspan="2">Periodicity</th><th rowspan="2">Operation description</th><th rowspan="2">Requester tool</th><th rowspan="2">Replier tool</th><th colspan="3">Request</th><th colspan="3">Response</th></tr><tr><th>HTTP method</th><th>Parameters / Body</th><th>Format</th><th>Status</th><th>Content / Body</th><th>Format</th></tr></thead><tbody><tr><td rowspan="10">I</td><td rowspan="2">1.1.1</td><td>every 24 hours</td><td>Push historical data</td><td>Synchronizer</td><td>State Estimator</td><td>POST</td><td>Historical data</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td>every 15 min</td><td>Push real measurements</td><td>Synchronizer</td><td>State Estimator</td><td>POST</td><td>Real measurements</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td rowspan="2">1.1.2</td><td></td><td>Initiate state estimator</td><td>Synchronizer</td><td>State Estimator</td><td>GET</td><td>Network ID</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td>every 15 min</td><td>Request real-time state estimation results</td><td>Synchronizer</td><td>State Estimator</td><td>GET</td><td>Network ID</td><td>JSON</td><td>200 OK</td><td>Most recent snapshot of the network, optimal power flow (OPF) calculated</td><td>JSON</td></tr><tr><td rowspan="2">1.2.1</td><td rowspan="2">every 15 min</td><td>Push weather forecasts</td><td>Synchronizer</td><td>Congestion Forecasting & Prevention Tool</td><td>POST</td><td>Weather forecasts</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td>Push grid measurements</td><td>Synchronizer</td><td>Congestion Forecasting & Prevention Tool</td><td>POST</td><td>Grid measurements</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td>1.2.2</td><td>every 15 min</td><td>Trigger the calculation</td><td>Synchronizer</td><td>Congestion Forecasting & Prevention Tool</td><td>GET</td><td>List of cases to be calculated</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td>1.2.3</td><td>as soon as ready</td><td>Push calculation results</td><td>Congestion Forecasting & Prevention Tool</td><td>Synchronizer</td><td>POST</td><td>List of calculated results: headrooms for the specified list of cases</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td rowspan="10">II</td><td rowspan="3">2.1.1</td><td rowspan="3">every 15 min</td><td>Push grid layout</td><td>Synchronizer</td><td>Flexibility Needs Assessor</td><td>POST</td><td>The updated version of grid layout</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td>Push optimal power flow & generic load profiles</td><td>Synchronizer</td><td>Flexibility Needs Assessor</td><td>POST</td><td>OPF and generic load profiles provided by State Estimator (step 1.1.3)</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td>Push Annual Load Consumption</td><td>Synchronizer</td><td>Flexibility Needs Assessor</td><td>POST</td><td>Load consumption for the previous year</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td rowspan="2">2.1.2</td><td rowspan="2">every 15 min</td><td>Push nodal day-ahead forecast of P and Q</td><td>Synchronizer</td><td>Flexibility Needs Assessor</td><td>POST</td><td>Nodal day-ahead forecast of P and Q</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td>Initiate flex needs assessment</td><td>Synchronizer</td><td>Flexibility Needs Assessor</td><td>GET</td><td>t.b.d.</td><td>JSON</td><td>200 OK</td><td>-</td><td>-</td></tr><tr><td>2.1.3</td><td>as soon as ready</td><td>Retrieve the results of flex needs assessment</td><td>Synchronizer</td><td>Flexibility Needs Assessor</td><td>GET</td><td>t.b.d.</td><td>JSON</td><td>200 OK</td><td>Nodal and zonal flexibility needs assessment</td><td>JSON</td></tr><tr><td rowspan="2">2.2.1</td><td rowspan="2">every 15 min</td><td>Push updated grid hierarchy, sell-orders, baselines and headrooms + start the calculation session</td><td>Synchronizer</td><td>Optimal Bid Recommender</td><td>POST</td><td>Updated grid hierarchy, sell-orders, baselines and headrooms (step 1.2.3)</td><td>JSON</td><td>200 OK</td><td>Session ID</td><td>JSON</td></tr><tr><td>as soon as ready</td><td>Retrieve calculation results for the session</td><td>Synchronizer</td><td>Optimal Bid Recommender</td><td>GET</td><td>Session ID</td><td>JSON</td><td>200 OK</td><td>Activation Cost, Power Accepted in Orders, Congested Grid Zones</td><td>JSON</td></tr></tbody></table>
<figure><img src="image_41.png" /></figure>