Cloudification of the CATALYST market framework

(1)

START DATE OF THE PROJECT 01/10/2017

DURATION 36 months

The CATALYST project has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement No 768739. Any dissemination of results must indicate that it reflects only the author’s view and that the EASME is not responsible for any use that may be made of the information it contains.

(2)

PROGRAMME NAME ENERGY EFFICIENCY CALL 2016-2017

PROGRAMME IDENTIFIER H2020-EE-2016-2017

TOPIC Bringing to market more energy efficient and integrated data centres

TOPIC IDENTIFIER EE-20-2017

TYPE OF ACTION IA Innovation action

PROJECT NUMBER 768739

PROJECT TITLE CATALYST

COORDINATOR ENGINEERING INGEGNERIA INFORMATICA S.p.A. (ENG)

PRINCIPAL CONTRACTORS SINGULARLOGIC ANONYMI ETAIREIA PLIROFORIAKON SYSTIMATON KAI EFARMOGON PLIROFORIKIS (SiLO), ENEL.SI S.r.l (ENEL), ALLIANDER NV (ALD), STICHTING GREEN IT CONSORTIUM REGIO AMSTERDAM (GIT), SCHUBERG PHILIS BV (SBP), QARNOT COMPUTING (QRN), POWER OPERATIONS LIMITED (POPs), INSTYTUT CHEMII BIOORGANICZNEJ POLSKIEJ AKADEMII NAUK (PSNC), UNIVERSITATEA TEHNICA CLUJ-NAPOCA (TUC)

DOCUMENT REFERENCE CATALYST.D5.3.SiLO.WP5.v1.1

WORKPACKAGE: WP5

DELIVERABLE TYPE OTHER

AVAILABILITY PU

DELIVERABLE STATE Final

DATE OF DELIVERY 30/04/2020

DOCUMENT TITLE Cloudification of the CATALYST market framework

AUTHOR(S) Marzia Mammina (ENG), Alessio Roppolo (ENG) Terpsi Velivassaki (SiLO), Vlad Lazar (TUC),

Artemis Voulkidis (POPs)

(3)

(4)

List of Figures

FIGURE 1 - SECTOR INTEGRATION IS ESSENTIAL FOR A SUSTAINABLE ENERGY FUTURE (IEA, 2017) ... 12

FIGURE 2 - MARKET EQUILIBRIUM ... 18

FIGURE 3 - MARKET EQUILIBRIUM IN CASE OF PROSUMER’S ACTION PRIORITISATION ... 18

FIGURE 4 - THE REALIZATION OF MAAS IN CATALYST ... 20

FIGURE 5 - THE FINAL HIGH-LEVEL CATALYST MARKETPLACE ARCHITECTURE ... 24

FIGURE 6 – MULTI-ENERGY MARKETS ORCHESTRATOR INTERACTIONS WITH OTHER CATALYST COMPONENTS ... 26

FIGURE 7 - A CATALYST MARKETPLACE INSTANCE DEPLOYED ON KUBERNETES VIA MAAS ... 30

FIGURE 8 - MARKETPLACE DEPLOYMENT OVERVIEW WHEN INSTANTIATED BY MAAS. ... 31

FIGURE 9 - HIGH-LEVEL MAAS ARCHITECTURE ... 32

FIGURE 10 - HIGH-LEVEL VIEW OF THE MAAS OPERATIONS FOR INSTANTIATING A NEW MARKETPLACE DEPLOYMENT ... 34

FIGURE 11 - INFORMATION BROKER SPECIALIZED PER MARKET VARIANT ... 38

FIGURE 12 – INFORMATION BROKER INTERACTIONS WITH OTHER CATALYST COMPONENTS ... 39

FIGURE 13 - ACCESS MANAGER COMMUNICATING WITH MEMO TO RESOLVE INFORMATION BROKER ADDRESS ... 40

FIGURE 14 – AM COMMUNICATES WITH KEYCLOAK TO PERFORM ACCOUNT CREATION AND VALIDATE LOGIN OPERATION ... 41

FIGURE 15 – INTERACTION OF ACCESS MANAGER WITH OTHER CATALYST COMPONENTS ... 41

FIGURE 16 - MARKET CLEARING MANAGER INTERACTIONS WITH OTHER CATALYST COMPONENTS... 43

FIGURE 17 - MARKET BILLING MANAGER INTERACTIONS WITH OTHER CATALYST COMPONENTS ... 44

FIGURE 18 - COMPONENT REGISTRATION ... 45

FIGURE 19 - USER REGISTRATION ... 46

FIGURE 20 - STARTING OF A SESSION ... 47

FIGURE 21 - USER LOGIN ... 48

FIGURE 22 - POSTING ACTION ... 49

FIGURE 23 - CORRELATING ACTIONS ... 50

FIGURE 24 - MULTI-ENERGY MARKET CLEARING - PART 1 OF 3 ... 51

FIGURE 27 - FLEXIBILITY MARKET CLEARING - PART 1 OF 2 ... 54

FIGURE 28 - FLEXIBILITY MARKET CLEARING - PART 2 OF 2 ... 55

FIGURE 29 - IT LOAD MARKET CLEARING - PART 1 OF 3 ... 56

FIGURE 32 - LISTING OF THE KUBERNETES CONFIGURATION FILES OF MAAS ... 59

FIGURE 33 - SNAPSHOT OF AN INDICATIVE REPRESENTATION OF A FULLY WORKING MAAS INSTALLATION ... 60

FIGURE 34 - SNAPSHOT OF A A FULLY WORKING MAAS INSTALLATION REPRESENTATION IN KUBERNETES DASHBOARD ... 60

FIGURE 35 - LOGIN SCREEN OF MAAS UI ... 62

FIGURE 36 - TABULATED OVERVIEW OF THE MARKETPLACE DEPLOYMENTS ... 62

FIGURE 37 - OVERVIEW OF THE CATALYST FEDERATION COMPONENTS VIEW ... 62

FIGURE 38 - OVERVIEW OF THE EXISTING REGISTERED REGIONS OF MAAS ... 63

FIGURE 39 - OVERVIEW OF THE EXISTING REGISTERED MARKET OPERATORS OF MARKETPLACE DEPLOYMENTS ... 63

FIGURE 40 - CREATING A NEW MARKETPLACE DEPLOYMENT ... 63

FIGURE 41 - CREATING A NEW MARKETPLACE DEPLOYMENT – MARKETPLACE DEPLOYMENT NOT READY YET... 64

FIGURE 42 - CREATING A NEW MARKETPLACE DEPLOYMENT – MARKETPLACE DEPLOYMENT IS READY FOR USE ... 64

FIGURE 43 – CATALYST MARKETPLACE HOME PAGE... 65

(7)

FIGURE 45 - ACCOUNT REQUEST VALIDATION ... 66

FIGURE 46 - MARKET RULES ... 67

FIGURE 47 - MARKET SESSION SET UP ... 68

FIGURE 48 - LOGIN PAGE ... 68

FIGURE 49 - USER HOME PAGE ... 69

FIGURE 50 - HOW TO ACCESS THE FLEXIBILITY SERVICE MARKETPLACES ... 70

FIGURE 51 - VISUALISATION OF OFFERS/BIDS PLACED IN ACTIVE MARKET SESSIONS BY THE USER ... 71

FIGURE 52 - PLACING A NEW OFFER IN THE ELECTRICITY MARKETPLACE ... 71

FIGURE 53 - PLACING A NEW OFFER IN THE IT LOAD MARKETPLACE ... 72

FIGURE 54 - CORRELATING MARKET ACTIONS ... 73

FIGURE 55 - MARKET ACTIONS HISTORY... 73

FIGURE 56 - CORRELATIONS HISTORY ... 74

FIGURE 57 - CORRELATED MARKET ACTION DETAILS ... 74

FIGURE 58 - USER INVOICES ... 75

FIGURE 59 - SELECTING FLEXIBILITY OFFERS ... 76

FIGURE 60 - HOW TO CONFIRM THE DELIVERY OF A FLEXIBILITY SERVICE ... 77

(8)

List of Tables

TABLE 1 - D5.1 DEPENDENCIES AND LINKAGES ... 13

TABLE 2 - COMBINATIONS OF MARKET ACTIONS LEADING TO COUPLED MARKET ACTIONS ... 16

TABLE 3 - SESSIONS TIME SCHEDULING FOR THE ELECTRICITY, HEAT, AND IT-LOAD MARKETPLACES ... 17

TABLE 4 - MULTI-ENERGY MARKETS ORCHESTRATOR IDENTITY CARD UPDATE ... 26

TABLE 5 - MAAS IDENTITY CARD UPDATE ... 34

TABLE 6 - INFORMATION BROKER IDENTITY CARD UPDATE ... 39

TABLE 7 – ACCESS MANAGER IDENTITY CARD ... 42

TABLE 8 - MARKET CLEARING MANAGER IDENTITY CARD UPDATE ... 43

TABLE 9 - MARKET BILLING MANAGER IDENTITY CARD UPDATE ... 44

TABLE 10 - URLS TO OPERATE MAAS UPON SUCCESSFUL INSTANTIATION ... 61

TABLE 11 - DEFAULT CREDENTIALS OF A MAAS USER ... 61

(9)

List of Acronyms

AAA Authentication, Authorization, and Accounting

AM Access Manager

API Application Programming Interface BMS Building Management System BRP Balance Responsible Party

DB Database

DC Data Centre

DS Data Storage

DSO Distribution System Operator DSS Decision Support Systems HTTP HyperText Transfer Protocol IB Information Broker

IEA International Energy Agency IT Information Technology MaaS Marketplace as a Service MBM Market Billing Manager MCM Market Clearing Manager MDS Marketplace Data Storage MEM Multi-Energy Markets

MEMO Multi-Energy Marketplace Orchestrator MSM Market Session Manager

RBAC Role-Based Access Control RES Renewable Energy Sources REST Representational State Transfer UI User Interface

(10)

VRE Variable Renewable Energy

(11)

Executive Summary

The CATALYST project delivers a fully configurable and adaptable multi-carrier marketplace; the CATALYST Marketplace. It is composed of a set of mono-marketplaces across a number of dimensions, and time resolutions:

• The Electricity Marketplace, • The Flexibility Marketplace, • The Heat Marketplace, • The IT Load Marketplace.

The first three marketplace variants operate on a day-ahead or intra-day basis on a local context and target relevant energy prosumers, including Data Centres (DCs) or clusters of domestic prosumers, etc. The last variant is realized as a regional marketplace with day-ahead or intra-day timeframes, where only DCs are eligible for participation, due to the nature of the carrier.

The CATALYST Marketplace enables Data Centres to increase their potential for offering flexibility to the carrier networks and reducing the time for recovering the investments in energy efficiency, Renewable Energy Sources (RES) and waste heat reuse, while exploiting synergies among energy and non-energy carriers at the largest possible extent.

The third version of the CATALYST Marketplace delivers two key innovations:

• The implementation of the Multi-Energy Market Orchestration mechanism, which allows Market Participants, such as DCs, to benefit from combined trading of different, yet inter-dependent, carriers, such as electricity, heat or even Information Technology (IT) Load. In this way, the waste heat, resulting from green electricity consumption or IT Load execution, can be traded -thus reused- at district premises, maximizing the energy efficiency potential on a district/city context rather than a limited local -own- context.

• The Marketplace-as-a-Service (MaaS) framework, which allows easy automated deployment and configuration of operating instances of Marketplace Variants on demand, enabling third party stakeholders, as aggregators, retailers, suppliers, Balance Responsible Parties (BRPs) willing to offer aggregation or energy management services to DCs, to operate the marketplace.

The present document is the accompanying report of the CATALYST MaaS framework, coming with the final version of the CATALYST Marketplace. The main CATALYST outcomes presented in this report include:

• The presentation of the CATALYST Multi-Energy Market Orchestration, leveraging on correlated market actions’ placement by Market Participants, as well as on orchestrated market clearing and billing processes.

• The conceptualization of the CATALYST MaaS framework with the notion of Marketplace Deployments, Variants, as well as market actors’ access to it.

• The tools provided for third parties to exploit the CATALYST Marketplace services, opted for Marketplace Operators and Marketplace Participants.

• The final CATALYST Marketplace architecture, which has been refactored to support Multi-Energy Market Orchestration, as well as the MaaS model.

(12)

• Installation and users’ guide, allowing exploitation and experimentation of the CATALYST Marketplace operations and code.

Last, but not least, the source code of the final version of the CATALYST Marketplace is available as open source on the public GitLab group of CATALYST, accessible at:

https://gitlab.com/project-catalyst/releases/marketplace/marketplace-as-a-service.

(13)

Introduction

Today’s and tomorrow’s energy world are largely different from the past. The promise for energy for all, along with the stressing requirements for decarbonization against climate change alter significantly the energy landscape around the globe. Indeed, the energy landscape in view of the industry’s reboot under existing threats on economy and growth globally after the pandemic crisis of 2020 is still unpredictable.

A significant change in the power systems is driven by the increasing availability of low-cost variable renewable energy (VRE), the deployment of distributed energy resources, advances in digitalisation and growing opportunities for electrification [1].

Considering a power system’s flexibility level, demand-side flexibility and sector coupling can be seen as additional flexibility sources and potential game changers [2]. Indeed, the International Energy Agency (IEA) underlines that an integrated approach is essential for a sustainable energy future, as shown in Figure 1. Enabling the high penetration of demand-side response requires co-ordination across a range of sectors and infrastructure.

Figure 1 - Sector integration is essential for a sustainable energy future [3]

(14)

the district heating network. Indeed, the CATALYST Marketplace actually supports the business model which could be encouraging for Data Centres to participate in this sector coupling.

The present report is the third deliverable of Work Package (WP) 5 and describes the operation and the technical specifications of the final version of the CATALYST Marketplace. This final version integrates energy (electricity, heat, flexibility) and non-energy (IT load) carriers across different time resolutions (intra-day, day-ahead) and geographic coverage (local, regional). The CATALYST Marketplace variants may work as mono-carrier marketplaces or they may be orchestrated under correlation criteria driving the clearing and billing processes.

1.1 Intended Audience

The report could be especially useful to external stakeholders interested in the CATALYST approach to sector coupling. From the power/heat sector, Distribution System Operators (DSOs), Heat Grid Operators and Smart City Energy Managers, as well as DC Operators and Managers from the IT sector could get insights related to the correlation of market actions, multi-energy market orchestration and the Marketplace-as-a-Service (MaaS) approach, which could encourage them to participate in the CATALYST Marketplace. Moreover, third parties or even municipal services could be interested in the coupled CATALYST Marketplace operation and MaaS, so to act as single or multiple Marketplace Operators. Policy makers and regulation bodies are also among the interested stakeholders since the idea of the CATALYST sector coupling could be exploited for the advancement of the energy market towards achieving the European energy efficiency and carbon neutrality goals.

Moreover, the document provides technical specifications, as well as installation and user’s guidance about the CATALYST Marketplace software. Thus, energy solution providers, technology providers and developers can find useful information for deploying, testing, and potentially extending the Marketplace prototype functionality.

Finally, the report is useful internally, to the members of the development and integration team of the CATALYST consortium, involving mainly WP3, WP4, WP5 and WP6 partners, but also to the whole Consortium for validation and exploitation purposes. Useful feedback could be also received from the Advisory Board and the Green Data Centre Stakeholder Group, including both technical and impact creation comments.

1.2 Relations to other activities

This document is meant to report the final version of the CATALYST Marketplace, which takes into account work done in past deliverables and will affect future project activities. Table 1 lists dependencies and linkages to other CATALYST activities.

Table 1 - D5.1 dependencies and linkages

ID Title Remarks

D2.1 CATALYST Specification & Design The user and system requirements, as well as the use cases related to the CATALYST Marketplace in D2.1 are used as a basis for the Marketplace design.

D2.3 Final CATALYST Framework Architecture

(15)

D3.2 Energy aware IT Load Balancing D3.2 provides the basis for improving the clearing process of the IT Load Marketplace under the multi-energy market orchestration perspective.

D3.3 Federated DCs Migration Controller

D3.3 provides insights related to the integration of the DC Migration software with the CATLYST Marketplace, mainly via the IT Load Marketplace. Also, D3.3 provides updates useful to the clearing process of the IT Load Marketplace.

D5.1 CATALYST market infrastructure implementation

D5.1 provides the implementation of the first CATALYST Marketplace prototype that guides the next prototypes’ development.

D5.2 Optimal orchestration of CATALYST market mechanisms

D5.2 draws the CATALYST approach towards the orchestration of multi-carrier marketplaces and provides the second version of the CATALYST Marketplace, upon which the final version id built.

D6.1 Integration guidelines D6.1 provides development and integration guidelines to be used during relevant CATALYST activities, which are respected in the current prototype.

D6.2 Intermediate CATALYST

Framework D6.2 presents the intermediate integrated prototype of the CATALYST framework and provides useful feedback for enhancements towards the final integrated prototype. D6.3 Final CATALYST Framework D6.3 will provide the final integrated CATALYST prototype.

The final version of the CATALYST Marketplace presented in D5.3 will be integrated in the final integrated CATALYST framework.

Moreover, the outcomes presented in D5.3 can be exploited within WP8 activities towards the definition of new business models, potentially based on customized tariffs and incentive systems, as well as for dissemination purposes.

1.3 Document overview

The rest of the document is organized as follows:

• Section 0 presents the CATALYST MaaS concept, including a short reference to the CATALYST mono-carrier marketplaces, following with the definition of the multi-energy market orchestration and reaching MaaS and ways for its exploitation by third parties.

• Section 0 provides technical specifications of the MaaS framework, including a redefined architecture and properly updated components under the multi-energy market orchestration concept.

• Section 0 provides the manual of the CATALYST MaaS with installation and user guidance and release notes.

(16)

CATALYST MaaS

The CATALYST project introduces the concept of the “Marketplace as a service” (MaaS) model, allowing fast and easy, automated deployment and configuration of running marketplace instances in three emerging and innovative DC revenue streams/markets:

• the Electricity/Flexibility Marketplace between stakeholders, such as DCs and electricity stakeholders (ranging from Smart Grid operators, aggregators to end-user prosumers) for trading electricity generation, storage, resiliency, and flexibility services,

• the Heat Marketplace between the DCs and District Heating operators, heat suppliers for trading heat and

• the IT Load Marketplace for trading the resources for IT load execution among federated DCs, leveraging on IT Load migration as a source of DC energy flexibility.

1.4 The CATALYST Marketplace

The first prototype of the CATALYST Marketplace has been released as deliverable D5.1 [4]. In this first prototype version, based on the CATALYST envisioned scenarios presented in D2.1 [5], four commodity variants of the Marketplace have been implemented:

• Electricity Marketplace for electricity budget trading, aiming to balance energy demand with green electricity generation within the boundaries of a Smart City or Smart District, while minimising energy transmission losses and moving gradually urban agglomerations towards energy autonomy;

• Heat Marketplace for heat budget trading, aiming to satisfy part of district heat demand with waste heat reuse via a new DC service, trading off additional investments for waste heat regeneration (e.g., heat pumps) with incremental revenues from waste heat valorisation in a systemic framework; • Flexibility Marketplace for flexibility budget trading, allowing to undertake locally mitigation actions

in cases of grid stability threats;

• IT Load Marketplace for IT load trading, offering an additional opportunity for DC energy flexibility as a new source of revenue, materialized via geographical inference of IT Load execution among federated DCs.

The second prototype of the CATALYST Marketplace has been released as deliverable D5.2 [6] and presented enhancements on the four mono-carrier variants, while it introduced the Multi-Energy Orchestration concept under realistic market configurations.

(17)

1.4.1 Marketplace Variants

1.4.2 Correlated Market Actions

The vision of CATALYST transforms DCs into flexible multi-energy hubs, able to sustain their investments in energy efficiency solutions and renewable energy sources (RES) by providing mutualized energy and flexibility services to the smart energy grids (both electricity and heat grids).

The CATALYST Marketplace has been conceived with this aim, allowing not only to DCs but also to generic “multi-asset” participants, which can be realized as systems connected to different networks by which they exchange different types of assets, to submit combined market actions to more than one CATALYST Marketplace variant. As an example, participants could be interested in placing a bid in the CATALYST Electricity Marketplace for buying electricity in a certain time slot and in placing an offer in the CATALYST Heat Marketplace for selling heat in the same time slot; such bid and offer will be linked to each other by a constraint that explains how the two market actions are dependent each from the other. The market actions placed in different marketplaces can be correlated, for example, with a “weak” link, which entails that each of the correlated market actions can be traded in its marketplace independently from the results of the clearing process in the other marketplaces, or with a “strong” link, which means that the correlated market actions must be all accepted, or all rejected when the related marketplaces are cleared.

In case of correlated market actions, if the link between the correlated market actions is “strong”, the clearing of the Marketplaces where the actions have been posted must be done simultaneously and based on the clearing mechanisms adopted in CATALYST, which have been described in D5.1 [7] and in D5.2 [6], only the following marketplace variants can be cleared simultaneously and, thus, considered in Multi-Energy Market Orchestration:

• Electricity • Heat

• IT Load Marketplace

Combining market actions (i.e. bids or offers) on 2 or 3 marketplace variants, 20 different cases of coupled market actions can be derived, as shown in Table 2.

Table 2 - Combinations of market actions leading to coupled market actions

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Electricity O O B B -- -- -- -- O O B B O O B B O O B B

Heat O B O B O O B B -- -- -- -- O B O B O B O B

IT load -- -- -- -- O B O B O B O B O O O O B B B B

1.4.3 Multi-energy Market Orchestration

(18)

The orchestration layer manages the Flexibility Marketplace as well, even if the offers placed in it cannot be correlated with any other marketplaces, since the clearing process adopted is not immediate, but it is deferred until the grid operator (which is the unique buyer in this marketplace) communicates if the services corresponding to the offers previously selected have been delivered or not.

The description and a numerical example of the multi-markets clearing algorithm has been given in D5.2 [2]. In this final version of the CATALYST Marketplace, the algorithm has been improved, as below described, by adding a market actions prioritisation mechanism, which favours the prosumers taking the risk of playing simultaneously in different marketplaces with a constraint, without altering the market equilibrium.

Let assume that there is the same time schedule for the day-ahead time variant of the Electricity Marketplace, Heat Marketplace, and IT-Load Marketplace (Table 3). SESSION 2 of the DAY-AHEAD time variant is open for the Electricity, Heat, and IT-Load Marketplaces.

Table 3 - Sessions time scheduling for the Electricity, Heat, and IT-Load Marketplaces DAY AHEAD

SESSION 1 SESSION 2 SESSION 3

start time 00:00 08:01 16:01

end time 08:00 16:00 23:59

delivery start time 00:00 (day of delivery) 08:01 (day of delivery) 16:01 (day of delivery) delivery end time 08:00 (day of delivery) 16:00 (day of delivery) 23:59 (day of delivery)

session duration 8 hours 8 hours 8 hours

During the session timeframe (between start time and end time), all the interested participants place bids/offers on the three marketplaces and some of them inform (via Access Manager) that they intend to place correlated orders with specific constraints (for example, all-or-nothing). A priority will be assigned to the prosumers, based on the number of marketplaces where they place market actions (bids and/or offers). At the closure of the three concurrent market sessions, the three markets are cleared, considering that on equal price, the clearing process will give priority to the prosumer that has placed correlated actions; on equal price, the priority will be given based on the time of arrival.

(19)

Figure 2 - Market equilibrium

Figure 3 - Market equilibrium in case of prosumer’s action prioritisation

The same approach is applied in the IT Load Marketplace, giving priority in matching bids-offers to prosumers that have placed correlated bids/offer in different marketplaces.

(20)

When the clearing of the three simultaneous sessions ends, the “temporary”1_{market results are analysed} by the Orchestrator, which checks all the constraints provided by the participants in their correlated actions. If some constraints are violated, the related actions are removed from the list of bids/offers placed in the related marketplaces sessions and the impacted marketplaces are cleared again. All the constraints for the coupled orders are checked again and this process continues until a stable situation is achieved. In the worst case, all the coupled market actions are removed from all the market sessions to be cleared.

1.5 A step forward: Marketplace as a Service

The final version of the CATALYST Marketplace facilitates the deployment and administration processes on the running marketplace instances. The final version supports the “Marketplace-as-a- Service” model, which decouples the marketplace software deployment, configuration and delivery from owner’s hardware and truly introduces the CATALYST Marketplace in the cloud computing paradigm, offering a number of benefits which can be summarized as:

• Fast and easy deployment and configuration of running instances of the CATALYST Marketplace or just some of its variants on demand. The Marketplace Operator (owner) will only need to provide the resources for the deployment in the cloud environment. Similarly, the upgrade procedure is largely simplified, eliminating the issues/challenges that traditionally arise from the deployment of new releases. This fully automated and flexible deployment/upgrade of CATALYST Marketplace instances/variants is possible in two ways:

o Via a User Interface (UI), the MaaS UI, which can be accessed by the candidate Marketplace Operator and easily configure and deploy instances/variants of interest.

o Via a programmatic API, the MaaS Application Programming Interface (API), which allows instantiation of the CATALYST Marketplace via a simple API call, passing the required configuration information. Indeed, the MaaS API allows the integration of the CATALYST MaaS on third-party platforms and applications.

• Configuration-as-a-Service support, since the configuration process is fully automated and possible via the MaaS API with zero downtime. Main configuration options refer to set of marketplace variants deployed in the same area (city).

• Scalability and high availability for the CATALYST Marketplace instances. The CATALYST Marketplace follows a microservices-oriented architecture and runs as a cloud-native application, which is composed by clusters of microservices, supporting resilience and high availability. Thus, the CATALYST MaaS approach allows full resources’ virtualization and facilitates the allocation of additional resources for the running instances needed. Moreover, replication of the running instances (at component level) is possible, in order to ensure the always-on operation of the CATALYST Marketplace.

• Performance monitoring of the CATALYST Marketplace instances. CATALYST MaaS allows monitoring the running instances on a timeseries fashion, in order to support performance evaluation of those instances. This capability facilitates the instances’ administration from the Marketplace Operator’s side, while it implies high-quality services for the end-users, i.e. the Marketplace Participants. The

1_{“Temporary” market results are the clearing results of mono-carrier marketplaces, before being provided to multi-market clearing}

(21)

latter could be crucial to ensuring that no technical burden is issued by the CATALYST Marketplace software to effective participation in the CATALYST Marketplace.

1.5.1 Marketplace-as-a-Service realized in CATALYST

The Marketplace-as-a-Service concept in CATALYST allows automated, dynamically configured deployment and operation of CATALYST Marketplace instances. The approach is flexible enough to allow the instantiation, deletion, and general administration of single Marketplace variants within CATALYST Marketplace Deployments. The approach adopted by the CATALYST MaaS respects the design principles of the previous versions of the CATALYST Marketplace.

Within MaaS, a CATALYST Marketplace Deployment is considered as the “umbrella” under which one to four different Marketplace variants can be accommodated: Electricity, Heat, Flexibility and/or IT Load Marketplace. A single CATALYST Marketplace Deployment is valid in local context (e.g. at city level), as the three out of four Marketplace variants are local marketplaces (i.e. Electricity, Heat, Flexibility). So, market participation is intended only for participants of the hosting city for those three variants. However, especially for the IT Load Marketplace variant, participation in one city’s IT Load Marketplace is possible by Marketplace Participants in other cities as well, as this variant has a regional context.

Figure 4 - The realization of MaaS in CATALYST

Indicatively, a possible conceptual view of the CATALYST MaaS is shown in Figure 4. In this example, MaaS manages five Marketplace Deployments, or five cities’ Marketplaces, while the variants’ composition is shown for two of them. Specifically, Deployment_1 includes all four marketplace variants, while Deployment_4 operates only two variants. The running variants can be enriched with additional ones or some of them could be deleted, on demand.

(22)

all market actions placed on the Flexibility Marketplace they participate, while a registered Marketplace Participant (e.g. DC Operator, Aggregator) on the same marketplace variant can access only information related to their own activity. On the other hand, the Marketplace Operator or DSO of a single Marketplace Deployment cannot access any other Deployment.

1.6 Use by third parties

The CATALYST Marketplace provides technical tools for the interested stakeholders, in order to facilitate its exploitation on their field of interest. Relevant stakeholders could be interested in using the Marketplace as: • Marketplace Operators: This role could be of interest to Municipalities, DSOs, Energy Operators or any other third party wishing to run and operate the CATALYST Marketplace. The Marketplace Operator is responsible for managing and supervising the marketplace operation, ensuring that it complies with underlying regulation and does not violate market laws. This actor provides the market rules, sets market sessions, approves user registration and checks the eligibility of posted bids and offers, following legal and economic rules [7].

• Marketplace Participants: This role could be attractive to DC Operators, Smart City Energy Actors, DSOs, Aggregators, Heat Brokers, etc., which could act on behalf of relatively high energy generation/consumption actors in order to trade energy budgets or IT loads -in an energy-aware fashion- on the CATALYST Marketplace. A Marketplace Participant may place bids/offers and get involved in market transactions.

CATALYST provides tools to third parties for integrating the CATALYST Marketplace services for both roles; as a Marketplace Operator or as a Marketplace Participant.

1.6.1 Tools for Marketplace Operators

Marketplace Operators are provided with the capability of instantiating Marketplace Deployments or variants in two ways:

• The MaaS UI, which can be accessed online. The Marketplace Operator can easily instantiate a Deployment or a Variant, providing configuration parameters in an online form, as guided by the MaaS UI. This option is encouraged as standalone use of the CATALYST MaaS.

• The MaaS API. Instantiation or management of Marketplace Deployments and Variants is possible programmatically via HyperText Transfer Protocol (HTTP) calls. The API allows integration of MaaS functionality in third-party software. So, in this way CATALYST MaaS can be easily exploited by stakeholders wishing to offer market operation and management services as an extension to their existing offerings via their own platforms.

Details on the APIs’ specification and use can be found in sections 1.8.2 and 1.13.1, respectively.

1.6.2 Tools for Marketplace Participants

(23)

• Online participation is possible via the CATALYST Marketplace portal. Authenticated users, recognized as Marketplace Participants, can access active market sessions of the marketplace variants they are registered to and place their bid or offer via a user-friendly UI.

(24)

MaaS Design

In this section the technical specifications of the final version of the CATALYST Marketplace are presented, including the high-level architecture definition, component-level specification, and the CATALYST Marketplace processes’ overview via Unified Modelling Language (UML) sequence diagrams.

1.7 Architecture

The final version of the CATALYST Marketplace has been re-architected into a more flexible, modular and microservices-oriented one. The refactored architecture is aimed to support a cloud-native Marketplace. The Cloud Native Computing Foundation (CNCF) defines “cloud-native” technologies [8] as open source, vendor-neutral projects, including containers, service meshes, microservices, immutable infrastructure, and declarative APIs, that allows building and running scalable applications in modern, dynamic environments such as public, private, and hybrid clouds, enabling loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The high-level architecture of the final version of the CATALYST Marketplace is realized as a set of microservices with discrete functionality, supporting the four variants of the CATALYST Marketplace, as depicted in Figure 5. This architecture delivers a fully configurable and adaptable multi-carrier marketplace through the MaaS component. The CATALYST Marketplace realizes a set of “Marketplace Deployments”, which can be understood as standalone instances -very close to the previous versions of the CATALYST Marketplace, although refactoring has taken place at that level, as well. Each “Marketplace Deployment” is composed of a set of “Marketplace Variants”, at maximum being those four:

• The Electricity Marketplace • The Flexibility Marketplace • The Heat Marketplace • The IT Load Marketplace

The composition of each Deployment is configurable, as the number and type of Marketplace Variants may vary among Deployments or may be changed at any time. Indeed, upon definition and availability of new Marketplace Variants, they can be added and instantiated upon request for new or existing Deployments. Each Variant is composed of the following components:

• The Information Broker (IB), which provides data persistence and controlled access to the CATALYST Marketplace data.

• The Market Clearing Manager (MCM), which undertakes the clearing of each Marketplace Variant, being specialised per market clearing mechanism. Especially for the IT Load Marketplace variant, this component interacts with the IT Load Balancer Server, presented in D3.2 [9] and slightly updated in D3.3 [10], which is responsible specifically for the IT Load Marketplace clearing.

(25)

Figure 5 - The final high-level CATALYST Marketplace architecture

On top of the Marketplace Variants’ set, the Access Manager provides the UI functionality of the current Marketplace Deployment and, thus, access to the Variants’ functionality.

The set of the Marketplace Variants is orchestrated by the Multi-Energy Marketplace Orchestrator (MEMO), which implements sector coupling among the Variants of the current Deployment, enabling combined market actions -bids or offers- to be considered within parallel market sessions of different carriers, as well as their coupled clearing. The Multi-Energy Markets Orchestration approach adopted in CATALYST is presented in D5.2 “Optimal orchestration of CATALYST market mechanisms” [6]. MEMO provides the logic of Multi-Energy Markets Orchestration, as well as persistence and access to data related to this orchestration.

(26)

is responsible for starting a market session, ending a market session, starting, and orchestrating the clearing phase for both the cases of mono-marketplace and coupled marketplaces.

Access to the CATALYST Marketplace resources is controlled via the Authentication, Authorization, and Accounting (AAA) framework, which supports all Deployments currently running within the CATALYST Marketplace.

Last, but not least, the CATALYST Marketplace Deployments are instantiated, monitored, removed, and overall managed by the Marketplace-as-a-Service framework of CATALYST. Following the cloud-native logic, MaaS keeps a repository of MaaS recipes, just like Marketplace Variants’ patterns, and includes the MaaS registry of running Deployments, as well as the Configuration Manager, delivering the Deployments’ management and monitoring functionality.

1.8 CATALYST Marketplace Platform Components

In this section the components of the CATALYST Marketplace are presented. Among those, the Multi-Energy Markets Orchestrator (MEMO) and Marketplace-as-a-Service (MaaS) are described in detail, while the updates on the Information Broker (IB), the Access Manager (AM), the Market Clearing Manager (MCM) and the Market Billing Manager (MBM) are presented.

1.8.1 Multi-Energy Markets Orchestrator

The Multi-Energy Markets Orchestrator is responsible for the orchestration of the various CATALYST Marketplace mechanisms, as explained in section 1.4.3, enabling marketplace participants to increase their potential for offering flexibility to the carrier networks exploiting synergies among energy and non-energy carriers. The Multi-Energy Markets Orchestrator is mainly responsible for opening and closing the market sessions. The time interval of a market session is scheduled by the Marketplace Operator. During a market session, Marketplace Participants may post offers/bids for pre-specified energy types or services for future usage under specific market rules. The Multi-Energy Markets Orchestrator is also responsible for starting the clearing and billing phases of both individual and correlated marketplaces. Further details on the orchestration processes can be found in section 1.10.

The Multi-Energy Markets Orchestrator also stores in the Multi-Energy Markets Data Storage (MEM DS) information related to a Marketplace Deployment, provided by MaaS, such as market type, energy form, Uniform Resource Locator (URL), and credentials for the authentication of the component. Each Marketplace Deployment is composed of Information Broker, Market Clearing Manager and Market Billing Manager instances.

(27)

Figure 6 – Multi-Energy Markets Orchestrator interactions with other CATALYST components

The Multi-Energy Markets Orchestrator Identity Card is given in Table 4.

Table 4 - Multi-Energy Markets Orchestrator Identity Card update Multi-Energy Markets Orchestrator

Framework

Sub-System CATALYST Marketplace

Responsibility Management of component registration. Management of starting and stopping sessions, clearing and billing.

registerMarket

Description Registers a list of new components related to any marketplace. Provided to MaaS

End-point URL /marketplace/ Protocol used HTTP, REST Allowed Methods POST getMarkets

Description Returns the list of components related to any marketplace. Provided to Access Manager

End-point URL /marketplaces/{component}/ Protocol used HTTP, REST

Allowed Methods GET postRegistrationRequest

Description Inserts the list of users during registration. Provided to Access Manager

(28)

Protocol used HTTP, REST Allowed Methods POST getRegistrationRequests

Description Returns the list of users under registration. Provided to Access Manager

End-point URL /marketparticipant/all/requests/ Protocol used HTTP, REST

Allowed Methods GET postValidationRequest

Description Update the list of users after the registration phase. Provided to Access Manager

End-point URL /marketparticipant/requests/ Protocol used HTTP, REST

Allowed Methods PUT getUserMarkets

Description Returns the list of components related to markets to which the username is associated.

Provided to Access Manager

End-point URL /userMarkets/{component}/{username}/ Protocol used HTTP, REST

Allowed Methods GET getConstraints

Description Returns the list of all constraints. Provided to Access Manager

End-point URL /constraints/ Protocol used HTTP, REST Allowed Methods GET postCorrelatedMarketsActions

Description Inserts a list of correlations between the actions. Provided to Access Manager

End-point URL /marketplace/all/coupleble/actor/actions/coupled/ Protocol used HTTP, REST

Allowed Methods POST

getHistoricalCorrelatedMarketsActions

Description Returns the list of correlations between the actions related to a timeframe and a username.

End-point URL /marketplace/all/coupleble/actor/actions/coupled/{timeframe}/{username}/ Protocol used HTTP, REST

(29)

Description Returns the list of correlations between the actions related to a timeframe, a timestamp period and a username.

End-point URL /marketplace/all/coupleble/actor/actions/coupled/{timeframe}/{start}/{end} /{username}/

Protocol used HTTP, REST Allowed Methods GET putCorrelatedMarketsActions

Description Updates the correlation related to market actions. Provided to Access Manager

Allowed Methods PUT deleteCorrelatedMarketsActions

Description Deletes the correlation relating to market actions. Provided to Access Manager

Allowed Methods DELETE createSystemParameter

Description Create a new system parameter. Provided to Information Broker

End-point URL /systemparameter/ Protocol used HTTP, REST

Allowed Methods POST editSystemParameter

Description Updates the system parameters related to id. Provided to Information Broker

Allowed Methods PUT deleteSystemParameter

Description Deletes the system parameters related to id. Provided to Information Broker

End-point URL /systemparameter/{id}/ Protocol used HTTP, REST

Allowed Methods DELETE getSystemParameter

Description Returns the system parameters related to id. Provided to Information Broker

(30)

Allowed Methods GET getAllSystemParameter

Description Returns the list of all system parameters. Provided to Information Broker

Allowed Methods GET

Required

Interfaces startSession() _{Provided by} _{Information Broker}

requestAID()

Provided by Information Broker postValidationRequest()

Provided by Information Broker closeSession()

Provided by Information Broker getValidActionsOfSession()

Provided by Information Broker billingProcess()

Provided by Market Billing Manager endClearing()

Provided by Information Broker completeSession()

Provided by Information Broker getActionsToBilling()

Provided by Information Broker clearingProcess()

Provided by Market Clearing Manager postClearingProcess()

Provided by Market Clearing Manager clearingProcess()

Provided by Market Clearing Manager getMarketSession()

Provided by Information Broker getForm()

Provided by Information Broker getMarketplace()

Provided by Information Broker

1.8.2 MaaS Framework

The MaaS component is responsible for the dynamic configuration of Marketplace Deployments, effectively supporting the notion of coordinated marketplaces clearing and homogenized user management at local levels, as already mentioned in subsection 1.5. Another important motivation, driving the emergence of the MaaS concept in CATALYST, is related to riding the wave of cloud-native design that, in turn, grants the CATALYST Marketplace Deployments with:

• Improved reliability (in terms of availability);

(31)

• Reduced cost through containerization and cloud standards (by default, container-technologies are thin-provisioned in contrast to traditional virtual machine based approaches that are fat-provisioned).

Further contributing to achieving avoidance of vendor lock-ins, MaaS has been designed, implemented, configured and tuned on top of open technologies and standards, so that anybody can download, try, evaluate and operate an operational CATALYST Marketplace Deployment.

Considering that already the core CATALYST Marketplace components had been designed and implemented as containerized stateless microservices, the only thing that was needed in order to enable cloud-native operation was related to the orchestration plane of the containers. To this end, the CATALYST consortium chose to employ Kubernetes [11]. Since the Kubernetes pros, cons, concepts and operational characteristics are out of the context of both the project and the deliverable, a relevant discussion is deliberately omitted. The interested reader is requested to refer to [12] for details and discussion. Instead, a short discussion on the high-level concepts that are of interest to MaaS with respect to how the various core Marketplace components are deployed is provided. Specifically, in Figure 7 a typical Marketplace Deployment instantiated by MaaS in a Kubernetes cluster defined as “a set of node machines for running containerized applications” [13] is shown.

Figure 7 - A CATALYST Marketplace instance deployed on Kubernetes via MaaS

As per Figure 7, supposing that enough cluster nodes are available to the cluster, it is readily possible to run

multiple load-balanced instances of the same Marketplace component in different cluster nodes. Further,

(32)

manage Marketplace Deployments without the need of re-building the containers or disrupting the running services.

Typically, MaaS envisages to be invisible to the various Marketplace actors and participants; its existence is merely relevant to the CATALYST Federation and the Marketplace users should not (and cannot) be aware of it. Figure 8 depicts the actual effects of applying Kubernetes to manage the Marketplace Deployments; each component gets a cluster flavour2_{and everything is masked behind load balancers and reverse proxies}

(effectively implemented as dynamically configured Kubernetes ingress rules). Hence, every Marketplace Deployment (regardless of its variant) features a cluster of Access Manager instances.

Figure 8 - Marketplace Deployment overview when instantiated by MaaS.

The MaaS architecture is, in turn, depicted in Figure 9. As shown therein, the main resources of MaaS may be aggregated and summarized as:

• The Configuration manager (comprising Kubernetes itself, a User Interface and an API component where the latter one is actually a set of microservices) which allows the creation and management of Marketplace Deployments;

• The MaaS Registry containing the list of running Marketplace Deployments (this is actively managed by Kubernetes itself);

• The MaaS recipes repository, which is defined as a set of yaml [14] files that contain pre-defined Marketplace components configuration that, upon Marketplace Deployment creation, get dynamically updated to match the Deployment needs.

• The AAA module that should be interpreted as an OpenID and OAuth2.0 server that implements a Role-Based Access Control (RBAC) AAA scheme to protect the resources of both MaaS and of the generated Marketplace Deployments. The implementation of the AAA module is based on the open-source Keycloak service [15].

2_{in this case a cluster should be considered as a multitude of load-balanced pods running the same container image.}

(33)

The Kubernetes orchestration layer could also be implicitly considered as an indirect MaaS component, allowing for the coordinated deployment of both MaaS and the Marketplace Deployments. Interestingly, the Kubernetes environment is both an enabler for MaaS (since the Configuration Manager and AAA are both hosted by it) and a toolchain (since MaaS manages it in order to instantiate the Marketplace Deployments). In the same context, on top of the above core MaaS components, exploiting the natively integrated resource monitoring features of Kubernetes [16] coupled with Prometheus [17] as a time series Database (DB) and pre-configured Grafana dashboards [18], MaaS is backed up by a set of failure and performance monitoring services that allow for the real-time failure resolution as well as monitoring at the level of performance/traffic/failures of Kubernetes pods, deployments etc.

Figure 9 - High-level MaaS architecture

In Figure 10, a high-level view of the MaaS internal interactions, that take place when a request for a new Marketplace Deployment is submitted, is provided. In more detail, the exact steps followed are summarized in the list below34_:

• Receive (through the MaaS API) a new Marketplace Deployment request from the MaaS UI (or via a direct call to the MaaS API);

• Mark the relevant request as received, then, started;

• Check if the selected region already holds any existing Deployments; o If no, then:

▪ Create a new Realm in Keycloak. The Realm is named as {country}-{region of country}-{city};

▪ Create the necessary Keycloak Realm scopes, roles and users (related to the Market Participant and Market Operator market actors). These will be held valid throughout all market variants of this Deployment;

3_{Again, the Kubernetes terminology is omitted and the interested users should refer to [12] for detailed information on it.}

4_{Notably, all the parts related to creating Kubernetes-related resources are taken from the configurations available from the MaaS}

services repository. Marketplace Instance Marketplace Instance Marketplace Deployment Configuration Manager MaaS

(34)

▪ Load from the MaaS Recipes Repository, configure and apply a Kubernetes namespace for the new Deployment. The namespace is named as {country}-{region of country}-{city};

▪ Load from the MaaS Recipes Repository , configure and apply a Kubernetes persistent volume for MEM DS;

▪ Load from the MaaS Recipes Repository , configure and apply a Kubernetes related namespaced persistent volume claim;

▪ Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced configMaps for AM, MEMO and MEM DS;

▪ Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced secrets for MEMO and MEM DS;

▪ Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced deployments for AM and MEMO;

▪ Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced services for AM and MEMO;

▪ Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced ingress rules for AM;

• Create a Keycloak client application in the appropriate Realm;

• Create the client application users (DSO, Aggregator, MCM, MBM), the client authorization roles, the client authorization scopes, the client authorization role-based policies and the client authorization permissions based on those policies;

• Load from the MaaS Recipes Repository, configure and apply a Kubernetes persistent volume for IB Marketplace Data Storage (MDS);

• Load from the MaaS Recipes Repository, configure and apply a Kubernetes related namespaced persistent volume claim;

• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced configMaps for IB (also holding the Deployment region, variant and Keycloak service endpoint base URL) and IB MDS;

• Load from the MaaS Recipes Repository, configure and apply a Kubernetes namespaced secret for IB (also holding the AAA client id, secret and realm) and IB MDS;

• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced deployments for IB, IB MDS, MCM and MBM;

• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced jobs to configure IB and IB MDS;

• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced services for IB, IB MDS, MCM and MBM;

• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced ingress rules for IB;

(35)

Figure 10 - High-level view of the MaaS operations for instantiating a new Marketplace Deployment

Last, it is worth noting that the MaaS API comprises a self-documenting API page available under http(s)://<host:port>/catalyst/maas/api/v1/docs/.

Overall, the MaaS Identity Card is given in Table 5.

Table 5 - MaaS Identity Card update Information Broker

Framework Sub-System CATALYST Marketplace

Responsibility Deployment and configuration of Marketplace instances as a service

clearingMechanism

(36)

End-point URL /api/clearing_mechanisms/ Protocol used REST

Allowed Methods GET marketplaceDeployments

Description Retrieves the list of current Marketplace Deployments or posts new deployments to a given request for the deployment.

Provided to MaaS UI, External Actors End-point URL /api/deployments/ Protocol used REST

Allowed Methods GET, POST deploymentsByRequest

Description Retrieves a paginated list of the Marketplace Deployments related to a given request..

Provided to MaaS UI, External Actors

End-point URL /api/deployments/by-request/{request_id} Protocol used REST

Allowed Methods GET singleDeployment

Description Retrieves or removes the Marketplace Deployment based on a unique integer value identifying this deployment.

Provided to MaaS UI, External Actors End-point URL /api/deployments/{id} Protocol used REST

Allowed Methods GET, DELETE federation

Description Retrieves the paginated list of a “Federation” object including the URLs of the CATALYST Federation components.

Provided to MaaS UI, External Actors End-point URL /api/federation/ Protocol used REST

Allowed Methods GET modifyFederation

Description Modifies the “Federation” object based on a unique integer value identifying this federation.

Provided to MaaS UI, External Actors End-point URL /api/federation/{id} Protocol used REST

Allowed Methods PUT, PATCH marketVariants

Description Retrieves the paginated list of available marketplace variants. Provided to MaaS UI, External Actors

End-point URL /api/flavours/ Protocol used REST

Allowed Methods GET marketOperators

Description Retrieves the paginated list of Marketplace Operators registered on MaaS.

(37)

Protocol used REST Allowed Methods GET singleOperator

Description Retrieves the Marketplace Operator based on the unique integer value identifying them.

Provided to MaaS UI, External Actors End-point URL /api/operators/{id} Protocol used REST

Allowed Methods GET regions

Description Retrieves the paginated list of or create new regions, where a new Marketplace Deployment can be made.

Provided to MaaS UI, External Actors End-point URL /api/regions/

Protocol used REST Allowed Methods GET, POST Countries

Description Retrieves the paginated list of countries, where a Marketplace Deployment can be made.

Provided to MaaS UI, External Actors End-point URL /api/regions/countries/ Protocol used REST

Allowed Methods GET countryRegions

Description Retrieves the paginated list of regions along with specific information, based on a given country.

End-point URL /api/regions/countries/{country}/regions/ Protocol used REST

Allowed Methods GET cities

Description Retrieves the paginated list of cities, where a Marketplace Deployment can be made, for a given country and region.

End-point URL /api/regions/countries/{country}/regions/{region}/cities/ Protocol used REST

Allowed Methods GET cityDeployment

Description Retrieves the paginated list of marketplace deployments, belonging to a given country, region and city.

End-point URL /api/regions/repr/{country}/{region}/{city}/ Protocol used REST

Allowed Methods GET region

Description Retrieves or modifies a region, based on a unique integer value identifying this region.

(38)

Protocol used REST

Allowed Methods GET, PUT, PATCH, DELETE getRequest

Description Retrieves information on a request to MaaS, based on a unique integer value identifying this request.

Provided to MaaS UI, External Actors End-point URL /api/requests/{id} Protocol used REST

Allowed Methods GET getToken

Description Retrieves authorization token based on provided credentials. Provided to MaaS UI, External Actors

End-point URL /api/token/ Protocol used REST Allowed Methods POST logout

Description Submits a logout request for a given token. Provided to MaaS UI, External Actors

End-point URL /api/token/logout Protocol used REST

Required Interfaces registerMarket

Provided by MEMO

1.8.3 CATALYST Marketplace Components

1.8.3.1 Information Broker

The Information Broker (IB) is responsible for persistence, update, delivery and access to the CATALYST Marketplace information, according to the access rights of the entity it is invoked by. It comprises three main subcomponents, as depicted in Figure 11:

• The IB API, which exposes Representational State Transfer (REST)-ful interfaces;

• Access control, which is responsible for token-based authentication with non-expiring token to prevent unauthorized access to Marketplace data;

• The Marketplace Data Storage (MDS), which provides persistence and management of the CATALYST Marketplace data.

In the previous versions of the CATALYST Marketplace, the architecture of the system contained only one Information Broker component, responsible for persisting, updating and securing the access for all market variants (Electricity, Heat, IT Load and Flexibility).

(39)

access of different markets is decoupled and stored in different locations, thus supporting the load balancing of the entire CATALYST framework. Hence, each Marketplace instance, regardless of the traded form, can be viewed as an independent service, thus contributing the concept of MaaS.

An additional benefit of this new approach is the flexibility offered to the user, who can choose in which market variants he/she wants to be registered. The user may choose to participate only in two markets, for example the IT Load Marketplace and Electricity Marketplace, and register only in those.

Figure 11 - Information Broker specialized per market variant

Moreover, since every market variant is now decoupled from the rest, special clearing and billing mechanism can be used for each variant, giving more flexibility in the way the whole CATALAYST Marketplace framework is configured. The implementation of this idea consists of assigning a different Market Clearing Manager and Market Billing Manager for each Information Broker component.

Considering the fact that each Information component will be deployed at a different physical location, the Multi-Energy Marketplace Orchestrator will assume the role of a Global Registry, persisting the address of each deployed Information Broker component, along with details specific to it. In this way, MEMO will know, at the moment of clearing, how to communicate correctly with each IB corresponding to the cleared market. The process of persisting the location of each IB instance will be initiated by MaaS, upon its deployment. MEMO will be informed about the deployment’s location and will store this information in its local persistence component. Other components of the CATALYST Marketplace (Access Manager for example) could use the registry stored by MEMO to access the individual IB instances, knowing their physical location.

(40)

Figure 12 – Information Broker interactions with other CATALYST components

The updated Information Broker Identity Card is given in Table 6.

Table 6 - Information Broker Identity Card update Information Broker

Responsibility Persistence and management of Marketplace data Protected access to marketplace data

requestAID

Description Registers a new market actor in MDS and receives their id. Provided to MEMO

End-point URL /marketparticipant/details/ Protocol used HTTP, REST

Allowed Methods POST postValidationRequest

Description Updates the status of a previously created actor, after the Market Operator handles the account creation request.

Provided to MEMO

End-point URL /marketparticipant/details/ Protocol used HTTP, REST

Allowed Methods PUT getAllMarketActions

Description Retrieves all valid market actions, from all the active market sessions, for a specified timeframe.

Provided to AM

(41)

Allowed Methods GET getValidActionsOfSession

Description Retrieves all valid actions of a market session, corresponding to a specific market actor.

Provided to MEMO

End-point URL /marketplace/{marketId}/marketsessions/{sid}/actor/{marketActo rId}/actions/valid/

Protocol used HTTP, REST Allowed Methods GET

Required Interfaces

Provided by

1.8.3.2 Access Manager

The Access Manager provides frontend functionality for the CATALYST Marketplace as a web console and allows role-based access to the marketplace contents for authenticated users. Details on the functionality, installation and usage of the Access Manager can be found in D5.1 [19].

In contrast with the previous CATALYST Marketplace architecture, where Access Manager communicated with only one Information Broker instance in order to provide the user with access to all market variants, in the current architecture the Access Manager interacts with all deployed instances of the Information Broker component.

As described in section 1.8.1, MEMO keeps a Global Registry with all the deployed instances of Information Broker and their physical addresses. Depending on the web page the user is accessing in the Access Manager and the market variant which corresponds to that page (Electricity, Heat, Flexibility and IT Load), MEMO will provide the Access Manager with the correct IP address of the Information Broker designated to that variant.

(42)

The Access Manager component is also responsible for communicating with Keycloak. When a new account is created through the AM interface, the details along with the credentials are communicated to Keycloak, so a new account can be created. At a later point in time, when the user accesses the AM interface to perform the login operation, their credentials are forwarded to Keycloak which checks them against a persistent account, and validates the login, providing a token which guarantees the identity of the user.

Figure 14 – AM communicates with Keycloak to perform account creation and validate login operation Interaction of Access Manager with other CATALYST components is depicted in Figure 15.

Figure 15 – Interaction of Access Manager with other CATALYST components

(43)

Table 7 – Access Manager Identity Card Access Manager

Responsibility Frontend User Interface

User authentication and authorization Role-based access to frontend functionality

Provided Interfaces No interface provided

Required Interfaces getMarkets getUserMarkets getRegistrationRequest postRegistrationRequest getValidationRequest getConstraints postCorrelatedMarketActions getCorrelatedMarketActions putCorrelatedMarketActions deleteCorrelatedMarketActions getHistoricalCorrelatedMarketActions Provided

by Multi-Energy Marketplace Orchestrator

1.8.3.3 Market Clearing Manager

The Market Clearing Manager (MCM) components are responsible for clearing a CATALYST Marketplace variant on the basis of specific clearing mechanisms. Each Market Clearing Manager component implements a different market clearing mechanism.

The clearing of the Electricity and Heat Marketplaces is based on the market equilibrium approach (intersection of aggregated demand curve and aggregated supply curve).

The clearing of the IT Load Marketplace is based on the optimal matching of bids and offers of server resources for the technical part (started by the Market Clearing Manager, but operated by the Energy Aware IT Load Balancer); the clearing price is computed by the Market Clearing Manager as medium price of the bid and offer matched.

The clearing period for the Flexibility Marketplace is a timeframe that follows the closure of each session, during which the DSO selects the offers, placed by the Marketplace participants, that best fit their needs. In a second step, the DSO informs the system if the services corresponding to the offers selected have been provided or not.

(44)

Figure 16 - Market Clearing Manager interactions with other CATALYST components

The updated Market Clearing Manager Identity Card is given in Table 8.

Table 8 - Market Clearing Manager Identity Card update Market Clearing Manager

Responsibility Execution of the Clearing process after the market actions’ insertion phase clearingProcess

Description Triggers clearing of market actions and calculation of clearing price. Provided to MEMO

End-point URL /clearingProcess/ Protocol used HTTP, REST Allowed Methods POST postClearingProcess

Description Updates the market actions, inserts the counteroffers, and updates the market session.

Provided to MEMO

End-point URL /postClearingProcess/ Protocol used HTTP, REST

Required Interfaces putClearedActions()

Provided by Information Broker postMarketActions()

Provided by Information Broker postCounterOffers()

Provided by Information Broker putSession()

Provided by Information Broker postPrioritisedActionsToClearing() Provided by Information Broker getCounterOffers()

Cloudification of the CATALYST market framework

Table of Contents

List of Figures

List of Tables

List of Acronyms

Executive Summary

Introduction

1.1 Intended Audience

1.2 Relations to other activities

1.3 Document overview

CATALYST MaaS

1.4 The CATALYST Marketplace

1.4.1 Marketplace Variants

1.4.2 Correlated Market Actions

1.4.3 Multi-energy Market Orchestration

1.5 A step forward: Marketplace as a Service

1.5.1 Marketplace-as-a-Service realized in CATALYST

1.6 Use by third parties

1.6.1 Tools for Marketplace Operators

1.6.2 Tools for Marketplace Participants

MaaS Design

1.7 Architecture

1.8 CATALYST Marketplace Platform Components

1.8.1 Multi-Energy Markets Orchestrator

1.8.2 MaaS Framework

1.8.3 CATALYST Marketplace Components

1.8.3.1 Information Broker

1.8.3.2 Access Manager

1.8.3.3 Market Clearing Manager