cloudification of the catalyst market framework...catalyst.d5.3.silo.wp5.v1.0 h2020-ee-2016-2017...
Post on 07-Jul-2020
5 Views
Preview:
TRANSCRIPT
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
T. Velivassaki (SiLO)
Peer review comments addressed
0.9.1 27/04/2020 Release
Candidate
M. Mammina (ENG)
T. Velivassaki (SiLO)
Updates on User guidelines, based on
latest code updates
0.9.2 29/04/2020 Release
Candidate
V. Lazar (TUC)
A. Voulkidis (POPs)
T. Velivassaki (SiLO)
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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 25 - MULTI-ENERGY MARKET CLEARING - PART 2 OF 3 .................................................................................... 52
FIGURE 26 - MULTI-ENERGY MARKET CLEARING - PART 3 OF 3 .................................................................................... 53
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 30 - IT LOAD MARKET CLEARING - PART 2 OF 3 ............................................................................................... 57
FIGURE 31 - IT LOAD MARKET CLEARING - PART 3 OF 3 ............................................................................................... 58
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
9
VRE Variable Renewable Energy
WP Work Package
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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:
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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}/
Protocol used HTTP, REST
Allowed Methods GET
postRegistrationRequest
Description Inserts the list of users during registration.
Provided to Access Manager
End-point URL /marketparticipant/request/
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
27
Protocol used HTTP, REST
Allowed Methods POST
getRegistrationRequests
Description Returns the list of users under registration.
Provided to Access Manager
End-point URL /marketparticipant/all/requests/
Protocol used HTTP, REST
Allowed Methods GET
postValidationRequest
Description Update the list of users after the registration phase.
Provided to Access Manager
End-point URL /marketparticipant/requests/
Protocol used HTTP, REST
Allowed Methods PUT
getUserMarkets
Description Returns the list of components related to markets to which the username is
associated.
Provided to Access Manager
End-point URL /userMarkets/{component}/{username}/
Protocol used HTTP, REST
Allowed Methods GET
getConstraints
Description Returns the list of all constraints.
Provided to Access Manager
End-point URL /constraints/
Protocol used HTTP, REST
Allowed Methods GET
postCorrelatedMarketsActions
Description Inserts a list of correlations between the actions.
Provided to Access Manager
End-point URL /marketplace/all/coupleble/actor/actions/coupled/
Protocol used HTTP, REST
Allowed Methods POST
getHistoricalCorrelatedMarketsActions
Description Returns the list of correlations between the actions related to a timeframe and
a username.
Provided to Access Manager
End-point URL /marketplace/all/coupleble/actor/actions/coupled/{timeframe}/{username}/
Protocol used HTTP, REST
Allowed Methods GET
getCorrelatedMarketsActions
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
28
Description Returns the list of correlations between the actions related to a timeframe, a
timestamp period and a username.
Provided to Access Manager
End-point URL /marketplace/all/coupleble/actor/actions/coupled/{timeframe}/{start}/{end}
/{username}/
Protocol used HTTP, REST
Allowed Methods GET
putCorrelatedMarketsActions
Description Updates the correlation related to market actions.
Provided to Access Manager
End-point URL /marketplace/all/coupleble/actor/actions/coupled/
Protocol used HTTP, REST
Allowed Methods PUT
deleteCorrelatedMarketsActions
Description Deletes the correlation relating to market actions.
Provided to Access Manager
End-point URL /marketplace/all/coupleble/actor/actions/coupled/
Protocol used HTTP, REST
Allowed Methods DELETE
createSystemParameter
Description Create a new system parameter.
Provided to Information Broker
End-point URL /systemparameter/
Protocol used HTTP, REST
Allowed Methods POST
editSystemParameter
Description Updates the system parameters related to id.
Provided to Information Broker
End-point URL /systemparameter/
Protocol used HTTP, REST
Allowed Methods PUT
deleteSystemParameter
Description Deletes the system parameters related to id.
Provided to Information Broker
End-point URL /systemparameter/{id}/
Protocol used HTTP, REST
Allowed Methods DELETE
getSystemParameter
Description Returns the system parameters related to id.
Provided to Information Broker
End-point URL /systemparameter/{id}/
Protocol used HTTP, REST
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
29
Allowed Methods GET
getAllSystemParameter
Description Returns the list of all system parameters.
Provided to Information Broker
End-point URL /systemparameter/
Protocol used HTTP, REST
Allowed Methods GET
Required
Interfaces
startSession()
Provided by Information Broker
requestAID()
Provided by Information Broker
postValidationRequest()
Provided by Information Broker
closeSession()
Provided by Information Broker
getValidActionsOfSession()
Provided by Information Broker
billingProcess()
Provided by Market Billing Manager
endClearing()
Provided by Information Broker
completeSession()
Provided by Information Broker
getActionsToBilling()
Provided by Information Broker
clearingProcess()
Provided by Market Clearing Manager
postClearingProcess()
Provided by Market Clearing Manager
clearingProcess()
Provided by Market Clearing Manager
getMarketSession()
Provided by Information Broker
getForm()
Provided by Information Broker
getMarketplace()
Provided by Information Broker
1.8.2 MaaS Framework
The MaaS component is responsible for the dynamic configuration of Marketplace Deployments, effectively
supporting the notion of coordinated marketplaces clearing and homogenized user management at local
levels, as already mentioned in subsection 1.5. Another important motivation, driving the emergence of the
MaaS concept in CATALYST, is related to riding the wave of cloud-native design that, in turn, grants the
CATALYST Marketplace Deployments with:
• Improved reliability (in terms of availability);
• Faster release pace (since the micro-services approach adopted in CATALYST, renders the updating
of single sub-components easier and hustle-free);
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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;
▪ Load from the MaaS Recipes Repository, configure and apply Kubernetes
namespaced secrets for MEMO and MEM DS;
▪ Load from the MaaS Recipes Repository, configure and apply Kubernetes
namespaced deployments for AM and MEMO;
▪ Load from the MaaS Recipes Repository, configure and apply Kubernetes
namespaced services for AM and MEMO;
▪ Load from the MaaS Recipes Repository, configure and apply Kubernetes
namespaced ingress rules for AM;
• Create a Keycloak client application in the appropriate Realm;
• Create the client application users (DSO, Aggregator, MCM, MBM), the client authorization roles, the
client authorization scopes, the client authorization role-based policies and the client authorization
permissions based on those policies;
• Load from the MaaS Recipes Repository, configure and apply a Kubernetes persistent volume for IB
Marketplace Data Storage (MDS);
• Load from the MaaS Recipes Repository, configure and apply a Kubernetes related namespaced
persistent volume claim;
• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced configMaps
for IB (also holding the Deployment region, variant and Keycloak service endpoint base URL) and IB
MDS;
• Load from the MaaS Recipes Repository, configure and apply a Kubernetes namespaced secret for
IB (also holding the AAA client id, secret and realm) and IB MDS;
• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced deployments
for IB, IB MDS, MCM and MBM;
• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced jobs to
configure IB and IB MDS;
• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced services for
IB, IB MDS, MCM and MBM;
• Load from the MaaS Recipes Repository, configure and apply Kubernetes namespaced ingress rules
for IB;
• Inform MEMO on the new deployment activation.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
Provided to MaaS UI, External Actors
End-point URL /api/deployments/
Protocol used REST
Allowed Methods GET, POST
deploymentsByRequest
Description Retrieves a paginated list of the Marketplace Deployments related
to a given request..
Provided to MaaS UI, External Actors
End-point URL /api/deployments/by-request/{request_id}
Protocol used REST
Allowed Methods GET
singleDeployment
Description Retrieves or removes the Marketplace Deployment based on a
unique integer value identifying this deployment.
Provided to MaaS UI, External Actors
End-point URL /api/deployments/{id}
Protocol used REST
Allowed Methods GET, DELETE
federation
Description Retrieves the paginated list of a “Federation” object including the
URLs of the CATALYST Federation components.
Provided to MaaS UI, External Actors
End-point URL /api/federation/
Protocol used REST
Allowed Methods GET
modifyFederation
Description Modifies the “Federation” object based on a unique integer value
identifying this federation.
Provided to MaaS UI, External Actors
End-point URL /api/federation/{id}
Protocol used REST
Allowed Methods PUT, PATCH
marketVariants
Description Retrieves the paginated list of available marketplace variants.
Provided to MaaS UI, External Actors
End-point URL /api/flavours/
Protocol used REST
Allowed Methods GET
marketOperators
Description Retrieves the paginated list of Marketplace Operators registered on
MaaS.
Provided to MaaS UI, External Actors
End-point URL /api/operators/
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
36
Protocol used REST
Allowed Methods GET
singleOperator
Description Retrieves the Marketplace Operator based on the unique integer
value identifying them.
Provided to MaaS UI, External Actors
End-point URL /api/operators/{id}
Protocol used REST
Allowed Methods GET
regions
Description Retrieves the paginated list of or create new regions, where a new
Marketplace Deployment can be made.
Provided to MaaS UI, External Actors
End-point URL /api/regions/
Protocol used REST
Allowed Methods GET, POST
Countries
Description Retrieves the paginated list of countries, where a Marketplace
Deployment can be made.
Provided to MaaS UI, External Actors
End-point URL /api/regions/countries/
Protocol used REST
Allowed Methods GET
countryRegions
Description Retrieves the paginated list of regions along with specific
information, based on a given country.
Provided to MaaS UI, External Actors
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.
Provided to MaaS UI, External Actors
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.
Provided to MaaS UI, External Actors
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.
Provided to MaaS UI, External Actors
End-point URL /api/regions/{id}
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
Provided to MaaS UI, External Actors
End-point URL /api/requests/{id}
Protocol used REST
Allowed Methods GET
getToken
Description Retrieves authorization token based on provided credentials.
Provided to MaaS UI, External Actors
End-point URL /api/token/
Protocol used REST
Allowed Methods POST
logout
Description Submits a logout request for a given token.
Provided to MaaS UI, External Actors
End-point URL /api/token/logout
Protocol used REST
Allowed Methods POST
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
Framework Sub-System CATALYST Marketplace
Responsibility Persistence and management of Marketplace data
Protected access to marketplace data
requestAID
Description Registers a new market actor in MDS and receives their id.
Provided to MEMO
End-point URL /marketparticipant/details/
Protocol used HTTP, REST
Allowed Methods POST
postValidationRequest
Description Updates the status of a previously created actor, after the Market
Operator handles the account creation request.
Provided to MEMO
End-point URL /marketparticipant/details/
Protocol used HTTP, REST
Allowed Methods PUT
getAllMarketActions
Description Retrieves all valid market actions, from all the active market
sessions, for a specified timeframe.
Provided to AM
End-point URL /marketplace/timeframe/{timeframe}/actions/valid/
Protocol used HTTP, REST
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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/
Protocol used HTTP, REST
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
42
Table 7 – Access Manager Identity Card
Access Manager
Framework Sub-System CATALYST Marketplace
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
Framework Sub-System CATALYST Marketplace
Responsibility Execution of the Clearing process after the market actions’ insertion phase
clearingProcess
Description Triggers clearing of market actions and calculation of clearing price.
Provided to MEMO
End-point URL /clearingProcess/
Protocol used HTTP, REST
Allowed Methods POST
postClearingProcess
Description Updates the market actions, inserts the counteroffers, and updates
the market session.
Provided to MEMO
End-point URL /postClearingProcess/
Protocol used HTTP, REST
Allowed Methods POST
Required Interfaces
putClearedActions()
Provided by Information Broker
postMarketActions()
Provided by Information Broker
postCounterOffers()
Provided by Information Broker
putSession()
Provided by Information Broker
postPrioritisedActionsToClearing()
Provided by Information Broker
getCounterOffers()
Provided by Information Broker
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
44
deleteCounterOffers()
Provided by Information Broker
getSessions()
Provided by Information Broker
postMarketActions()
Provided by Information Broker
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
CATALYST Marketplace.
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
Framework Sub-System CATALYST Marketplace
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/
Protocol used HTTP, REST
Allowed Methods POST
Required Interfaces
postTransactions()
Provided by Information Broker
postInvoices()
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
45
Provided by Information Broker
GetMarketAction()
Provided by Information Broker
putMarketActionsBilled()
Provided by Information Broker
1.9 Process overview
The sections below give an overview of the interactions between components in the main processes of the
CATALYST Marketplace.
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
46
Figure 19 - User registration
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
50
Figure 23 - Correlating actions
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
52
Figure 25 - Multi-energy market clearing - Part 2 of 3
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
53
Figure 26 - Multi-energy market clearing - Part 3 of 3
The clearing of the Flexibility Marketplace will be operated separately, as depicted in Figure 27 and Figure
28.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
54
Figure 27 - Flexibility market clearing - part 1 of 2
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
55
Figure 28 - Flexibility market clearing - part 2 of 2
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
57
Figure 30 - IT Load market clearing - part 2 of 3
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
58
Figure 31 - IT Load market clearing - part 3 of 3
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
67
Figure 46 - Market rules
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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).
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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).
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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”.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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).
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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).
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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).
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
77
Figure 60 - How to confirm the delivery of a flexibility service
Figure 61 - Delivery confirmation status updated
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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:
https://gitlab.com/project-catalyst/releases/marketplace/marketplace-as-a-service
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.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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/.
CATALYST.D5.3.SiLO.WP5.v1.0 H2020-EE-2016-2017
Cloudification of the CATALYST market framework 768739
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.
top related