cloudification of the catalyst market framework...catalyst.d5.3.silo.wp5.v1.0 h2020-ee-2016-2017...

D5.3

Cloudification of the CATALYST

market framework

WORKPACKAGE

WP5

DOCUMENT

D5.3

VERSION

1.0

PUBLISH DATE

30/04/2020

DOCUMENT REFERENCE

CATALYST.D5.3.SiLO.WP5.v1.0

PROGRAMME IDENTIFIER

H2020-EE-2016-2017

PROJECT NUMBER

768739

START DATE OF THE PROJECT

01/10/2017

DURATION

36 months

CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017

Cloudification of the CATALYST market framework 768739

1

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.0

WORKPACKAGE: WP5

DELIVERABLE TYPE OTHER

AVAILABILITY PU

DELIVERABLE STATE Final

CONTRACTUAL DATE OF DELIVERY 31/01/2020

ACTUAL 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)

REVIEWER(S) Vlad Lazar (TUC),

Artemis Voulkidis (POPs)

SUMMARY (See the Executive Summary)

HISTORY (See the Change History Table)

KEYWORDS CATALYST, Marketplace-as-a-Service; Market Orchestration



2

Change History

Version Date State Author (Partner) Description

0.1 11/11/2019 Table of Contents T. Velivassaki (SiLO) First version of Table of Contents

0.2 13/11/2019 Table of Contents T. Velivassaki (SiLO) Second version of Table of Contents,

after peer-review, guidance about inputs

per section

0.3 04/12/2019 Table of Contents T. Velivassaki (SiLO) Third version of Table of Contents, after

discussions during WP5 technical

meeting

0.4 19/12/2019 Draft M. Mammina (ENG) Multi-energy marketplace orchestration

0.5 12/12/2019 Draft T. Velivassaki (SiLO)

M. Mammina (ENG)

Updates based on Marketplace

redesign

0.5.1 19/12/2019 Draft M. Mammina (ENG) Updates on market correlation and

multi-market orchestration

0.5.2 18/02/2020 Draft M. Mammina (ENG)

A. Roppolo

Updates on process view

0.6 20/02/2020 Draft V. Lazar (TUC) Updates on Information Broker and

Access Manager

0.7 13/03/2020 Draft A. Voulkidis. (POPs),

G. Nikolakis (POPs),

T. Velivassaki (SiLO)

Contribution to CATALYST MaaS, overall

enhancements

0.7.1 17/03/2020 Draft M. Mammina (ENG)

A. Roppolo

Updates on Multi-energy marketplace

orchestration, Market Billing Manager,

Market Clearing Manager, process view.

0.8 26/03/2020 Consolidated T. Velivassaki (SiLO)

Overall enhancements and consistency

checks

0.8.1 27/03/2020 Reviewed A. Voulkidis (POPs) Peer review completed

0.8.2 31/03/2020 Reviewed V. Lazar (TUC) Peer review completed

0.9 31/03/2020 Release

Candidate


Peer review comments addressed

0.9.1 27/04/2020 Release

Candidate

M. Mammina (ENG)


Updates on User guidelines, based on

latest code updates

0.9.2 29/04/2020 Release

Candidate

V. Lazar (TUC)

A. Voulkidis (POPs)


Peer review on new content completed

and integrated

0.9.9 30/04/2020 Quality Checked D.Arnone (ENG) Quality check

1.0 30/04/2020 Final D.Arnone (ENG Final approval and submission to the EC



3

Table of Contents

Change History ....................................................................................................................................................... 2

Table of Contents ................................................................................................................................................... 3

List of Figures ......................................................................................................................................................... 5

List of Tables .......................................................................................................................................................... 7

List of Acronyms ..................................................................................................................................................... 8

Executive Summary .............................................................................................................................................. 10

Introduction .......................................................................................................................................................... 12

1.1 Intended Audience .................................................................................................................................. 13

1.2 Relations to other activities .................................................................................................................... 13

1.3 Document overview ................................................................................................................................. 14

CATALYST MaaS ................................................................................................................................................... 15

1.4 The CATALYST Marketplace .................................................................................................................... 15

1.4.1 Marketplace Variants ........................................................................................................................... 16

1.4.2 Correlated Market Actions ................................................................................................................... 16

1.4.3 Multi-energy Market Orchestration ...................................................................................................... 16

1.5 A step forward: Marketplace as a Service ............................................................................................. 19

1.5.1 Marketplace-as-a-Service realized in CATALYST ................................................................................. 20

1.6 Use by third parties ................................................................................................................................. 21

1.6.1 Tools for Marketplace Operators ......................................................................................................... 21

1.6.2 Tools for Marketplace Participants ...................................................................................................... 21

MaaS Design ........................................................................................................................................................ 23

1.7 Architecture ............................................................................................................................................. 23

1.8 CATALYST Marketplace Platform Components ..................................................................................... 25

1.8.1 Multi-Energy Markets Orchestrator...................................................................................................... 25

1.8.2 MaaS Framework .................................................................................................................................. 29

1.8.3 CATALYST Marketplace Components .................................................................................................. 37

1.8.3.1 Information Broker ............................................................................................................................. 37

1.8.3.2 Access Manager ................................................................................................................................. 40

1.8.3.3 Market Clearing Manager .................................................................................................................. 42

1.8.3.4 Market Billing Manager ..................................................................................................................... 44

1.9 Process overview ..................................................................................................................................... 45

1.9.1 Component Registration ...................................................................................................................... 45

1.9.2 Marketplace Participant Registration .................................................................................................. 45



4

1.10 Orchestration processes ......................................................................................................................... 47

1.10.1 Starting sessions .................................................................................................................................. 47

1.10.2 User login .............................................................................................................................................. 47

1.10.3 Posting market actions......................................................................................................................... 48

1.10.4 Posting actions correlations and constraints...................................................................................... 49

1.10.5 Multi-energy market clearing ............................................................................................................... 51

CATALYST MaaS Manual ..................................................................................................................................... 59

1.11 Installation Guidelines ............................................................................................................................ 59

1.12 Release Notes ......................................................................................................................................... 61

1.13 User Guidelines ....................................................................................................................................... 61

1.13.1 MaaS user guidelines ........................................................................................................................... 61

1.13.2 Guidelines for the user for accessing and playing in the CATALYST Marketplace ........................... 64

Conclusions .......................................................................................................................................................... 78

References ........................................................................................................................................................... 79



5

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

FIGURE 44 - LOGIN PAGE ......................................................................................................................................... 65



6

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

FIGURE 61 - DELIVERY CONFIRMATION STATUS UPDATED ............................................................................................. 77



7

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

TABLE 12 - USER CREDENTIALS FOR PLAYING IN THE CATALYST MARKETPLACE ........................................................... 66



8

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

UML Unified Modelling Language

URL Uniform Resource Locator

UUID Universal Unique Identifier



9

VRE Variable Renewable Energy

WP Work Package



10

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.

• The final specification of the CATALYST Marketplace processes, as have been implemented in the

final CATALYST Marketplace prototype, via sequence diagrams.



11

• 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.

Interested readers are urged to visit this channel, download, test, and further extend the CATALYST

Marketplace.

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



12

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]

Although there is still no common interpretation of sector coupling or integration across different stakeholder

shares, the CATALYST Marketplace implements the vision of coupling the -still de-coupled- IT and multi-

carrier energy sectors. The four variants of the CATALYST Marketplace include the Electricity, Heat, Flexibility

and IT Load Marketplace. These variants may work independently from each other but can also be coupled

via correlated market actions across variants, posing relevance criteria on the market clearing. In this way,

CATALYST enables sector coupling scenarios which allow the use of renewable energy, wherever it is

available, to execute non time-critical IT loads, while emitting the heat dissipated by the hosting servers in



13

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

D2.3 provides the final CATALYST Framework software

architecture. Further updates in the CATALYST Marketplace

architecture are reported in D5.3.



14

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.

• Section 5 draws conclusions.



15

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.

In this third version of the CATALYST Marketplace, the Multi-Energy Orchestration (MEMO) has been

implemented, while the four mono-carrier variants can be provided via the Marketplace-as-a-Service model.

Both MEMO and MaaS support came with complete refactoring of the mono-carrier variants. The next

subsections present thoroughly the third version of the CATALYST Marketplace.



16

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

The final version of the CATALYST Marketplace has been enriched with an orchestration layer responsible

for coordinating a number of different simultaneous market mechanisms, ranging from sequential to

simultaneous market clearing, enabling participants to increase their potential for offering mutualised

energy services to the carrier networks.



17

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.

As can be seen in Figure 2 and in Figure 3, the prioritisation, on equal price, of a prosumer that has placed

correlated bids/offers (assume ProducerD) does not alter the equilibrium point. The ProducerC, who placed

a single offer in one marketplace, could be penalised, since, with the prioritisation of other prosumers, their

offer could be partially accepted or even rejected.



18

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.

In all marketplace mechanisms, in case of equal price and equal quantity of commodity, the arrival order is

considered.



19

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

for the generation of the final clearing results.



20

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.

Access rights are restricted per Marketplace Deployment. The Marketplace Operator is granted access to a

single Marketplace Deployment and all four of its variants, based on their role. On the other hand,

Marketplace Participants, the Distribution System Operator (DSO) and the Heat Grid Operator can access

only the variants they are subscribed to, with permissions respecting their role. Thus, the DSO can access



21

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

CATALYST provides two ways for participation in running CATALYST Marketplaces by registered Marketplace

Participants:



22

• 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.

• Automated participation to the CATALYST Marketplace is possible via the Marketplace Connectors,

i.e. modules which allow participants’ side integration into the CATALYST Marketplace variants. The

Marketplace Connectors can be used by any entity acting as Marketplace Participant (DC Operator,

Aggregator, DSO, etc.), in order to post bids and offers via programmatic calls. In other words, the

Marketplace Connectors allow the integration of market participation functionality into existing

platforms, delivering energy management services, decision support systems (DSS), building

management systems (BMS), etc.



23

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.

• The Market Billing Manager (MBM), which implements billing functionalities, such as generation of

billing information and reports, based on the clearing outcome, so far provided by MCM. MBM,

similarly to MCM, is specialized per Marketplace Variant.



24

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.

In this final architecture the Market Session Manager component, part of D5.2 architecture and so far in

charge of managing the market sessions, has been removed and the session management is now under the

responsibility of the new Multi-energy Marketplace Orchestrator (MEMO) component. In more detail, MEMO



25

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.

Interaction of MEMO with other Marketplace components is depicted in Figure 6.



26

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}/


Allowed Methods GET

postRegistrationRequest

Description Inserts the list of users during registration.


End-point URL /marketparticipant/request/



27



getRegistrationRequests

Description Returns the list of users under registration.


End-point URL /marketparticipant/all/requests/


Allowed Methods GET

postValidationRequest

Description Update the list of users after the registration phase.


End-point URL /marketparticipant/requests/


Allowed Methods PUT

getUserMarkets

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

associated.


End-point URL /userMarkets/{component}/{username}/


Allowed Methods GET

getConstraints

Description Returns the list of all constraints.


End-point URL /constraints/


Allowed Methods GET

postCorrelatedMarketsActions

Description Inserts a list of correlations between the actions.


End-point URL /marketplace/all/coupleble/actor/actions/coupled/



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}/


Allowed Methods GET

getCorrelatedMarketsActions



28

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}/


Allowed Methods GET

putCorrelatedMarketsActions

Description Updates the correlation related to market actions.




Allowed Methods PUT

deleteCorrelatedMarketsActions

Description Deletes the correlation relating to market actions.




Allowed Methods DELETE

createSystemParameter

Description Create a new system parameter.

Provided to Information Broker

End-point URL /systemparameter/



editSystemParameter

Description Updates the system parameters related to id.




Allowed Methods PUT

deleteSystemParameter

Description Deletes the system parameters related to id.


End-point URL /systemparameter/{id}/


Allowed Methods DELETE

getSystemParameter

Description Returns the system parameters related to id.


End-point URL /systemparameter/{id}/




29

Allowed Methods GET

getAllSystemParameter

Description Returns the list of all system parameters.




Allowed Methods GET

Required

Interfaces

startSession()

Provided by Information Broker

requestAID()


postValidationRequest()


closeSession()


getValidActionsOfSession()


billingProcess()

Provided by Market Billing Manager

endClearing()


completeSession()


getActionsToBilling()


clearingProcess()

Provided by Market Clearing Manager

postClearingProcess()


clearingProcess()


getMarketSession()


getForm()


getMarketplace()


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);

• Faster release pace (since the micro-services approach adopted in CATALYST, renders the updating

of single sub-components easier and hustle-free);



30

• 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,

whenever a container instance (named as pod in Kubernetes terminology) enters a failing state, another

instance is being spawned automatically so that the redundancy level (scale) of each Marketplace

component is always kept intact. The same happens when a new update of a component is being pushed; a

new container gets created using the updated software and when it gets spawned and is operational, the

old container gets deleted. Auto-configuration using plain text (configmaps in Kubernetes terminology) and

encoded key-value stores (secrets in Kubernetes terminology) allows MaaS to dynamically spawn and



31

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.

DBCluster

Load Balancer

Market Mechanisms

Cluster

Market MechanismMarket

MechanismMarket Mechanism

DB

APIClusterΙΒ

Dashboard Cluster

DashboardAccess Manager

AAA



32

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 below3 4:

• 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 InstanceMarketplace

InstanceMarketplace Deployment

Configuration Manager

MaaSRegistry

MaaS Recipes Repository

DB

Failure &Performance

Monitoring (Prometheus)

DB

AAA



33

▪ 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;


namespaced secrets for MEMO and MEM DS;


namespaced deployments for AM and MEMO;


namespaced services for AM and MEMO;


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;

• Inform MEMO on the new deployment activation.



34

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

Description Retrieves the list of available market clearing mechanisms.

Provided to MaaS UI, External Actors



35

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.


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..


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.


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.


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.


End-point URL /api/federation/{id}

Protocol used REST

Allowed Methods PUT, PATCH

marketVariants

Description Retrieves the paginated list of available marketplace variants.


End-point URL /api/flavours/

Protocol used REST

Allowed Methods GET

marketOperators

Description Retrieves the paginated list of Marketplace Operators registered on

MaaS.


End-point URL /api/operators/



36

Protocol used REST

Allowed Methods GET

singleOperator

Description Retrieves the Marketplace Operator based on the unique integer

value identifying them.


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.


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.


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.


End-point URL /api/regions/{id}



37

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.


End-point URL /api/requests/{id}

Protocol used REST

Allowed Methods GET

getToken

Description Retrieves authorization token based on provided credentials.


End-point URL /api/token/

Protocol used REST


logout

Description Submits a logout request for a given token.


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).

In this new CATALYST Marketplace version, one Information Broker component (API + Data Storage) will be

deployed for every market variant, as can be observed from Figure 11. Indeed, using one Information

Component per market variant supports the distributed architecture of the CATALYST Marketplace, as each

Information Broker instance can be deployed on a different physical machine. Even more, the data and



38

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.

Interaction of IB with other Marketplace components is depicted in Figure 12.



39

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/



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/


Allowed Methods PUT

getAllMarketActions

Description Retrieves all valid market actions, from all the active market

sessions, for a specified timeframe.

Provided to AM

End-point URL /marketplace/timeframe/{timeframe}/actions/valid/




40

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/


Allowed Methods GET

Required Interfaces

Provided by

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.

Figure 13 - Access Manager communicating with MEMO to resolve Information Broker address



41

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

The updated Access Manager Identity Card is given in Table 7.



42

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.

Interaction of MCM with other Marketplace components is depicted in Figure 16.



43

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/



postClearingProcess

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

the market session.

Provided to MEMO

End-point URL /postClearingProcess/



Required Interfaces

putClearedActions()


postMarketActions()


postCounterOffers()


putSession()


postPrioritisedActionsToClearing()


getCounterOffers()




44

deleteCounterOffers()


getSessions()


postMarketActions()


1.8.3.4 Market Billing Manager

The Market Billing Manager (MBM) components are responsible for the computation of the invoices, based

on the agreements for each Marketplace; they could implement different billing mechanism. Each Market

Billing Manager component implements the same billing mechanism for the current four variants of the


Interaction of Market Clearing Manager with other Marketplace components is depicted in Figure 17.

Figure 17 - Market Billing Manager interactions with other CATALYST components

The updated Market Billing Manager Identity Card is given in Table 9.

Table 9 - Market Billing Manager Identity Card update

Market Billing Manager


Responsibility Execution of the Billing process after the clearing phase

billingProcess

Description Records transactions and invoices for all counteroffers generated by

the post clearing process.

Provided to MEMO

End-point URL /billingProcess/



Required Interfaces

postTransactions()


postInvoices()



45


GetMarketAction()


putMarketActionsBilled()


1.9 Process overview

The sections below give an overview of the interactions between components in the main processes of the


1.9.1 Component Registration

The MaaS provides MEMO with information about the marketplace components (IB, MCM, and MBM) related

to an instance of Marketplace, such as market type, energy form, URL (Figure 18). MEMO assigns an ID to

each component and stores the related information received.

Figure 18 - Component registration

1.9.2 Marketplace Participant Registration

At sign-up, the user requests to be registered as Marketplace Participant and chooses a username and a

password. In this phase the AAA system will assign a universal unique identifier to the user (UUID). Moreover,

the user provides details and selects the marketplaces where she would like to be registered in. The user

details and the selected markets are stored into the MEMO database, from where the AM will retrieve that

information when necessary. User details are provided to IBs as well; the IB assigns an ActorID to the user

that is mapped with the UUID assigned by the AAA system. The UUID is included in the token string generated

by the AAA system to secure the communication exchanges. The user registration phase is depicted in Figure

19.



46

Figure 19 - User registration



47

1.10 Orchestration processes

In this section, the processes related to multi-market orchestration are presented in the form of sequence

diagrams. In the pictures below, “i” represents number (id) of the marketplace instance, while IBi represents

the IB of the i-th marketplace instance.

1.10.1 Starting sessions

MEMO asks the IBi to start the sessions based on the time schedule (Figure 20).

Figure 20 - Starting of a session

1.10.2 User login

The sequence diagram in Figure 21 depicts the user login process.



48

Figure 21 - User login

1.10.3 Posting market actions

Figure 22 depicts the action posting process. In this final version of the CATALYST Marketplace, IB is in

charge of checking the action validity. This task had been assigned to the Market Session Manager (MSM)

in the previous versions of the Marketplace, which is now an obsolete component.



49

Figure 22 - Posting action

1.10.4 Posting actions correlations and constraints

As depicted in Figure 23, once market actions are placed in simultaneous active sessions of different

markets (Flexibility market excluded), the user is allowed to correlate those actions applying a constraint.

Correlated actions IDs and related constraints are stored in the MEM DS.



50

Figure 23 - Correlating actions



51

1.10.5 Multi-energy market clearing

The MEMO coordinates the clearing of the markets, both mono or coupled, in this latter case using the

algorithm described in section 1.4.3 (Figure 24 to Figure 26) for the previously selected offers if the service

has been delivered whenever requested or not.

Figure 24 - Multi-energy market clearing - Part 1 of 3



52




53


The clearing of the Flexibility Marketplace will be operated separately, as depicted in Figure 27 and Figure

28.



54

Figure 27 - Flexibility market clearing - part 1 of 2



55

Figure 28 - Flexibility market clearing - part 2 of 2



56

The IT Load Marketplace follows a separate clearing process, involving the Energy-aware IT Load Balancer,

as depicted in Figure 29 to Figure 31.

Figure 29 - IT Load market clearing - part 1 of 3



57




58




59

CATALYST MaaS Manual

1.11 Installation Guidelines

The installation of MaaS assumes a working installation of Kubernetes, holding at least the following

Kubernetes services: api-server, controller-manager, scheduler, kubelet, cni, kube-proxy, ingress, metrics-

server, prometheus and storage. Once a working Kubernetes environment has been set, one should

download first the MaaS Kubernetes configuration files from the maas-api gitlab repository, located under

the k8s/yaml/maas directory. The directory listing should be similar to the one depicted in Figure 32.

Figure 32 - Listing of the Kubernetes configuration files of MaaS

To create a MaaS deployment, the following commands should be performed:

$ kubectl apply -f storages

$ kubectl apply -f configmaps

$ kubectl apply -f secrets

$ kubectl apply -f deployments

$ kubectl apply -f jobs

$ kubectl apply -f services

$ kubectl apply -f ingress

Then, if everything went ok, the MaaS base components should be operational under the default namespace

of Kubernetes, as depicted in Figure 33, or if the dashboard Kubernetes plugin is enabled as in Figure 34.



60

Figure 33 - Snapshot of an indicative representation of a fully working MaaS installation

Figure 34 - Snapshot of a a fully working MaaS installation representation in Kubernetes dashboard



61

The URLs exposed by the MaaS UI and API are tabulated below.

Table 10 - URLs to operate MaaS upon successful instantiation

Component Service endpoint URL

MaaS UI http(s)://{server:port}/catalyst/maas/v1/

MaaS API http(s)://{server:port}/catalyst/maas/api/v1/

MaaS Swagger http(s)://{server:port}/catalyst/maas/api/v1/docs/

By default, one MaaS user is being created, holding the following credentials:

Table 11 - Default credentials of a Maas User

Credential type Value

Username maas_operator

Password _9(G+czHXgsPyKGr

Both values may be changed by appropriately updating the secrets/api.yaml file, particularly the user

and password values as base64-encoded strings.

1.12 Release Notes

The third release of the CATALYST Marketplace features a completely refactored microservices-oriented

architecture, able to be provided as a service. Also, multi-markets clearing is available for correlated actions

placed on the Electricity, Heat and/or IT Load Marketplace.

This third release of the CATALYST Marketplace is provided as open source under the LGPLv3 license [20].

Any issues or suggestions regarding the installation or functionality of the current release can be raised on

our public Marketplace Gitlab group [21].

1.13 User Guidelines

In this section, the user guidelines are provided for both the MaaS and a single CATALYST Marketplace

deployment. These guidelines have been extracted using an intermediate integrated version of the CATALYST

Marketplace, as the fully integrated CATALYST Marketplace will be released as part of WP6 activities.

1.13.1 MaaS user guidelines

As already documented in section 1.11, in order to use the UI of MaaS (being the core entry point to the

MaaS overall functionality), one should head to http(s)://{server:port}/catalyst/maas/v1/.

Therein, only a login button is available. When clicking it, a form is presented to the user to enter their

username and password as in Figure 35.



62

Figure 35 - Login screen of MaaS UI

After having logged into the MaaS UI, the next step is to click on the newly-appearing Deployments option on

the UI menu bar. Then, the existing deployments are demonstrated as in Figure 36.

Figure 36 - Tabulated overview of the Marketplace Deployments

Similarly, the configuration button showcases some default configuration for the CATALYST federation

components as in Figure 37.

Figure 37 - Overview of the CATALYST federation components view



63

Pressing the Regions button, one is able to view the already registered regions and create new ones, as

depicted in Figure 38. The same holds for the operators view, as depicted in Figure 39.

Figure 38 - Overview of the existing registered regions of MaaS

Figure 39 - Overview of the existing registered Market operators of Marketplace Deployments

In order to create a new Market Deployment, one should go to the Deployments view and hit the green plus

(“+”) button. On the appearing screen, a Name should be given to the Deployment, then the market variant,

the clearing mechanism, the region and the market operator should be created as in Figure 40. Note that

all dropdown menus are dynamically populated.

Figure 40 - Creating a new Marketplace Deployment

When clicking on the save button, a new Deployment starts getting deployed; since it takes some time to

finalize the deployment, at first the status of it appears as pending, as seen in Figure 41.



64

Figure 41 - Creating a new Marketplace Deployment – Marketplace Deployment not ready yet

After some time has passed (normally at the seconds scale), the new deployment should be available and

operational as in Figure 42.

Figure 42 - Creating a new Marketplace Deployment – Marketplace Deployment is ready for use

1.13.2 Guidelines for the user for accessing and playing in the CATALYST

Marketplace

The home page of the final CATALYST Marketplace Access Manager is as depicted in Figure 43.

Since the provided services should not be used by unauthorized users, the various sections of the CATALYST

Access Manager are not available until the user logs into the platform. This functionality is provided through



65

the login service of the Access Manager, accessible through the “Log in” tab of the upper right side of the

home page. Credentials for accessing and playing in the CATALYST Marketplace can be requested accessing

the “Sign up” page, or clicking on “Create new account” in the “Login” page (Figure 44).

Figure 43 – CATALYST Marketplace home Page

Figure 44 - Login page



66

The users’ credentials shown in Table 12 can be used for playing in the CATALYST Marketplace.

Table 12 - User credentials for playing in the CATALYST Marketplace

Username Password User type

admin catalystOp Market Operator

dso catalystDSO DSO

participant1 Marketplace2019 Generic Participant

participant2 Marketplace2019 Generic Participant

The Access Manager allows the marketplace operator to manage the overall marketplace operation.

Accessing the “Admin” page, the marketplace operator can validate or remove account requests (Figure 45),

set up Marketplace rules (clicking on “Add new rule” button in Figure 46), set up market sessions (clicking

on “Generate inactive session” button in Figure 47). The marketplace operator is also able to monitor the

activities of the registered users. Activities in active sessions can be monitored selecting a marketplace

variant from the main menu, while activities related to closed sessions can be monitored accessing the

“History” page. As mediator of the transactions done in the Marketplace, the marketplace operator can

visualize the invoicing information produced after the clearing of the markets from the “Invoice” page.

Figure 45 - Account request validation



67

Figure 46 - Market rules



68

Figure 47 - Market session set up

The user wishing to access the CATALYST Marketplace as Marketplace Participant can enter through the

“Login” page (Figure 48) and use all the functionalities for which he/she is authorized.

Figure 48 - Login page



69

Once logged into the Marketplace (Figure 48), the user is enabled to play in active marketplace sessions in

the Marketplace variants selected during the registration phase. Figure 49 shows in the main menu the

Marketplace variants where the user “participant1” has been registered.

Figure 49 - User home page

The Flexibility Marketplace is structured in “services” that can be provided to the grid operator through the

CATALYST Marketplace (Figure 50).



70

Figure 50 - How to access the Flexibility service marketplaces

Once the Marketplace variant is selected, the user can visualize details about offers/bids already placed in

active market sessions or can add new offers/bids by clicking on the “Add offer/bid” button on the top left

side of the table in Figure 51, that is the action start and end time, the value of the energy requested or

offered, the unit of measurement, the maximum price he/she intends to pay for accepting an offer (in case

of placing a bid) or the minimum price he/she intends to accept (in case of placing an offer), the type of the

Market Action placed (Buy or Sell, corresponding to a bid or an offer, respectively), and further details

depending on the Marketplace variant, for example the delivery point in the Electricity and Heat Marketplace

variants (Figure 52), IT load information (such as CPU, RAM, and DISK) in the IT Load Marketplace (Figure

53). The market action is then placed in the Marketplace with the “unchecked” status that is updated to

“validated” or “rejected” after some validity checks done by the system (as in Figure 51).



71

Figure 51 - Visualisation of offers/bids placed in active market sessions by the user

Figure 52 - Placing a new offer in the Electricity Marketplace



72

Figure 53 - Placing a new offer in the IT Load Marketplace

The user is allowed to correlate market actions placed in concurrent sessions of the Electricity, Heat, and IT

Load Marketplaces by applying correlations with a “weak” link (“At least one” constraint), 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 (“All or nothing” constraint), which means

that the correlated market actions must be all accepted, or all rejected when the related marketplaces are

cleared. Correlations can be applied to bids/offers placed on concurrent market sessions by clicking on

“Correlations” in the main menu and then selecting “Create correlations”; once the type of correlation is

selected from the “Selection correlation type” list, market actions can be correlated by clicking on the

checkbox in “Manage” column and then clicking on the “Add” button (Figure 54). Correlations applied to

bids/offers placed on concurrent market sessions can be visualized by clicking on “Correlations” in the main

menu and then selecting “View active correlations”. Those constraints are taken into consideration during

the clearing of the correlated Marketplace variants (as described in sections 1.4.2 and 1.4.3). Based on the

clearing mechanism adopted, the Flexibility Marketplace cannot be correlated to other Marketplaces.

Correlations applied to market action related to closed market sessions can be visualised by clicking on

“History” in the main menu and then selecting “Correlations”.



73

Figure 54 - Correlating market actions

After the closure of the session, once the markets are cleared, the market participant can visualize the

market results by clicking on “History” in the main menu and selecting the Marketplace variant (Figure 55).

Based on the market clearing approach adopted in that Marketplace, market actions can be accepted,

partially accepted, or rejected in Electricity, Heat, and IT Load Marketplaces and selected, delivered, not

delivered in the Flexibility Marketplace.

Figure 55 - Market actions history



74

Correlations applied to the placed market actions are accessible to the user also by clicking on “History” in

the main menu and selecting Correlations (Figure 56). The user can view details of the correlated market

actions by clicking on the action identifier in the column “Actions” (Figure 57).

Figure 56 - Correlations history

Figure 57 - Correlated market action details

The user can also access the invoicing information produced after the markets clearing phase by clicking on

“Invoices” in the main menu and selecting a marketplace variant (Figure 58).



75

Figure 58 - User invoices

The DSO is the unique buying counterparty in the Flexibility Marketplace. As long as a Flexibility Marketplace

session is active, market participants can place offers, as described above. After the closure of the market

session, the DSO is allowed to select the offers that best fit the grid’s needs by clicking on “Flexibility” and

selecting a timeframe and a flexibility service (Figure 59).



76

Figure 59 - Selecting flexibility offers

After the delivery time defined in the market session, the DSO must inform the system if a service requested

(corresponding to an offer previously selected) has been delivered or not by accessing a time variant in a

flexibility service marketplace and clicking on the icon in “Delivered”/“Undelivered” column (Figure 60). The

status of the offers will be updated accordingly (Figure 61).



77

Figure 60 - How to confirm the delivery of a flexibility service

Figure 61 - Delivery confirmation status updated



78

Conclusions

In this document, the final version of the CATALYST Marketplace has been presented to follow the “as-a-

Service model and support orchestration of multi-energy carriers. Both the CATALYST MaaS and MEMO

present significant achievements towards facilitating/leveraging the adoption of sector coupling across

energy or energy related domains; electricity, heat, DC core business.

Those achievements have been made possible via significant redesign of the CATALYST Marketplace

architecture and refactoring of the implementation of the core Marketplace components. The current

document presented the functionality and design specifications of all components of the CATALYST

Marketplace, including MaaS and MEMO. Also, the software processes and interactions through which the

operation of the CATALYST Marketplace is realized, have been presented. As the present report is

accompanying the CATALYST Marketplace software, readers are urged to download it at:


The GitLab repository for the CATALYST Marketplace keeps updated with latest enhancements, providing

due guidance on installation and use. Indeed, the APIs of the CATALYST Marketplace components offer

online documentation, which is available upon installation.




79

References

[1] IEA, “System integration of renewables - Decarbonising while meeting growing demand,” 2020.

[Online]. Available: https://www.iea.org/topics/system-integration-of-renewables.

[2] IRENA, “Sector Coupling,” 2020. [Online]. Available: https://www.irena.org/energytransition/Power-

Sector-Transformation/Sector-Coupling.

[3] IEA, “Energy Technology Perspectives 2017 - Catalysing Energy Technology Transformations,” 2017.

[4] CATALYST, “D5.1 - CATALYST market infrastructure implementation,” H2020-768739 CATALYST

Deliverable Report , 2019.

[5] H2020-768739 CATALYST project, “Deliverable D2.1 - CATALYST Specification & Design,” [Online].

Available: http://project-catalyst.eu/wp-

content/uploads/2019/01/CATALYST.D2.1.WP2_.TUC_.v1.0.pdf.

[6] H2020-768739 CATALYST project, “D5.2: Optimal orchestration of CATALYST market mechanisms,”

[Online]. Available: http://project-catalyst.eu/wp-

content/uploads/2019/09/CATALYST.D5.2.ENG_.WP5_.V1.0.pdf.

[7] H2020-768739 CATALYST project, “D5.1: CATALYST market infrastructure,” [Online]. Available:

http://project-catalyst.eu/wp-content/uploads/2019/06/CATALYST.D5.1.ENG_.WP5_.V1.0.pdf.

[8] Cloud Native Computing Foundation, “CNCF Cloud Native Definition v1.0,” GitHub, 2018.

[9] CATALYST, “D3.2 - Energy aware IT Load Balancing,” H2020-768739 CATALYST Deliverable Report,

2019.

[10] CATALYST, “D3.3 - Federated DCs Migration Controller,” H2020-768739 CATALYST Deliverable Report,

2019.

[11] The Linux Foundation, “Kubernetes - Production-Grade Container Orchestrationv,” 2020. [Online].

Available: https://kubernetes.io. [Accessed 12 Mar. 2020].

[12] The Linux Foundation, “Kubernetes - Concepts,” 2020. [Online]. Available:

https://kubernetes.io/docs/concepts/. [Accessed 12 Mar. 2020].

[13] RedHat Inc, “What is a Kubernetes cluster?,” [Online]. Available:

https://www.redhat.com/en/topics/containers/what-is-a-kubernetes-cluster. [Accessed 12 Mar.

2020].

[14] “The official yaml website,” 2020. [Online]. Available: https://yaml.org/.



80

[15] Red Hat Inc, “Keycloak - Open Source Identity and Access Management,” [Online]. Available:

https://www.keycloak.org/. [Accessed 12 Mar. 2020].

[16] The Linux Foundation, “Kubernetes - Tools for Monitoring Resources,” [Online]. Available:

https://kubernetes.io/docs/tasks/debug-application-cluster/resource-usage-monitoring/. [Accessed

12 Mar. 2020].

[17] The Linux Foundation, “Prometheus - Home page,” [Online]. Available: https://prometheus.io/.

[Accessed 12 Mar. 2020].

[18] Grafana Labs, “Grafana - The open observability platform,” [Online]. Available: https://grafana.com/.

[Accessed 12 Mar. 2020].

[19] H2020-768739 CATALYST project, Deliverable D5.1 - CATALYST market infrastructure

implementation, http://project-catalyst.eu/wp-

content/uploads/2019/06/CATALYST.D5.1.ENG_.WP5_.V1.0.pdf.

[20] Open Source Initiative, “GNU Lesser General Public License version 3,” [Online]. Available:

https://opensource.org/licenses/lgpl-3.0.html.

[21] “CATALYST Marketplace GitLab group - Issue Tracker,” [Online]. Available:

https://gitlab.com/groups/project-catalyst/releases/marketplace/-/issues.

cloudification of the catalyst market framework...catalyst.d5.3.silo.wp5.v1.0 h2020-ee-2016-2017...

Documents