catalyst specification & design€¦ · catalyst specification & design 768739 10 together,...

D2.1

CATALYST Specification & Design

WORKPACKAGE

WP2

DOCUMENT

D2.1

VERSION

1.0

PUBLISH DATE

31/05/2018

DOCUMENT REFERENCE

CATALYST.D2.1.TUC.WP2.v1.0

PROGRAMME IDENTIFIER

H2020-EE-2016-2017

PROJECT NUMBER

768739

START DATE OF THE PROJECT

01/10/2017

DURATION

36 months

CATALYST.D2.1.TUC.WP2.v1.0 H2020-EE-2016-2017

CATALYST Specification & Design 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.D2.1.TUC.WP2.v1.0

WORKPACKAGE: WP2

DELIVERABLE TYPE R

AVAILABILITY PU

DELIVERABLE STATE Final

CONTRACTUAL DATE OF DELIVERY 31/05/2018

ACTUAL DATE OF DELIVERY 31/05/2018

DOCUMENT TITLE CATALYST Specification & Design



2

AUTHOR(S) Tudor Cioara (TUC), Ioan Salomie (TUC)Marzia Mammina (ENG), Marcel Antal

(TUC), Artemis Voulkidis (POPs), Athanasoulis Panagiotis (SILO), Claudia Pop

(TUC), Ariel Oleksiak (PSNC), Nicolas Sainthérant (QRN), Diego Arnone (ENG), Arjan Westerhoff (SBP), Marilena Lazzaro (ENG), Sieben Bram (ALD), Vasiliki

Georgiadou (GIT),

REVIEWER(S) Vasiliki Georgiadou (GIT), Wijnja Jelle (ALD)

SUMMARY (See the Executive Summary)

HISTORY (See the Change History Table)

KEYWORDS Requirements Specifications, Scenarios and Use-Cases, Framework

Architecture, Optimization Data Model.



3

Change History

Version Date State Author (Partner) Description

0.1 15/01/2018 ToC Tudor Cioara (TUC) First version of ToC

0.3 20/02/2018 Draft Tudor Cioara, Ioan Salomie,

Claudia Pop, Marcel Antal

(TUC)

Refined ToC and TUC contributions

0.5 20/03/2018 Draft Tudor Cioara (TUC), Marzia

Mammina (ENG), Artemis

Voulkidis (POPs), Athanasoulis

Panagiotis (SILO), Ariel

Oleksiak (PSNC), Nicolas

Sainthérant (QRN), Diego

Arnone (ENG), Arjan

Westerhoff (SBP), Marilena

Lazzaro (ENG), Sieben Bram

(ALD), Vasiliki Georgiadou

(GIT)

Draft with first round of contributions

from partners


Mammina (ENG), Athanasoulis

Panagiotis (SILO), Artemis

Voulkidis (POPs)

Draft with second round of

contributions from partners


Mammina (ENG), Athanasoulis

Panagiotis (SILO), Artemis

Voulkidis (POPs)

Draft with third round of

contributions from partners (updates

after face to face meeting and USEF

workshop)

0.9 30/05/2018 Consolidated Tudor Cioara, Ioan Salomie

(TUC)

Consolidated version ready for peer-

review

0.9.1 31/05/2018 Peer-reviewed Vasiliki Georgiadou (GIT),

Wijnja Jelle (ALD)

Peer reviewed

0.9.5 31/05/2018 Release

Candidate

Tudor Cioara (TUC) Reviewers comments addressed

0.9.9 31/05/2018 Quality Checked Diego Arnone (ENG) Quality check

1.0 31/05/2018 Final Massimo Bertoncini (ENG) Final version ready for submission to

EC



4

Table of Contents

Change History ............................................................................................................................................. 3

Table of Contents ......................................................................................................................................... 4

List of Figures ............................................................................................................................................... 6

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

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

Executive Summary...................................................................................................................................... 9

1. Introduction ........................................................................................................................................ 9

Intended Audience ....................................................................................................................... 11

Relations to other activities ......................................................................................................... 11

Document overview ...................................................................................................................... 12

2. Requirements Elicitation and Analysis Process Overview ............................................................ 13

Adopted Method ........................................................................................................................... 13

Actors ............................................................................................................................................ 14

Underlying Assumptions .............................................................................................................. 15

3. CATALYST Opportunities in Today’s DCs and Energy Market ....................................................... 17

Pilot #1: Green Pont Saint Martin DC ......................................................................................... 17

3.1.1 Overview ..................................................................................................................................... 17

3.1.2 Main Characteristics .................................................................................................................. 17

Pilot #2: Poznan Supercomputing Centre DC............................................................................. 20

3.2.1 Overview ..................................................................................................................................... 20


Pilot #3: Schuberg Philis DC ........................................................................................................ 22

3.3.1 Overview ..................................................................................................................................... 22


Pilot #4: Distributed Qarnot DC ................................................................................................... 24

3.4.1 Overview ..................................................................................................................................... 24


Universal Smart Energy Framework (USEF) ................................................................................ 26

3.5.1 Market Roles and Congestion Management Process ............................................................. 27

4. CATALYST Scenarios ....................................................................................................................... 30



5

5. CATALYST Use Cases ...................................................................................................................... 41

DC Optimization Engine ............................................................................................................... 42

Energy Networks Interface and Energy Marketplaces ............................................................... 48

Federated DCs Integration and IT Load Marketplace ................................................................ 61

6. CATALYST System Requirements................................................................................................... 64

Functional Requirements ............................................................................................................ 64

6.1.1 DC Optimization ......................................................................................................................... 64

6.1.2 Energy and IT Networks Integration ......................................................................................... 67

6.1.3 Marketplaces ............................................................................................................................. 67

Non-functional Requirements ..................................................................................................... 71

7. CATALYST Architecture – 1st version ............................................................................................. 73

Components and progress beyond pre-CATALYST results ......................................................... 75

CATALYST Optimization Data Model ........................................................................................... 77

8. Conclusions ..................................................................................................................................... 84

References ................................................................................................................................................ 85



6

List of Figures

FIGURE 1 – WP2 RELATION WITH OTHER WORK PACKAGES ................................................................................ 12

FIGURE 2 - CATALYST REQUIREMENTS ELICITATION AND ANALYSIS .................................................................... 13

FIGURE 3 - GEOTHERMAL COOLING SYSTEM OF PSM DC .................................................................................. 18

FIGURE 4 - ELECTRICAL SYSTEM LAYOUT OF PSM DC ....................................................................................... 19

FIGURE 5 - COOLING TOWERS FOR EXTRACTING / STORING COOLING CAPACITY ..................................................... 23

FIGURE 6 - ACTUAL HEAT GENERATION WITH NATURAL GAS ................................................................................. 24

FIGURE 7 - DIESEL GENERATOR AND ACTUAL PRE-HEATING ................................................................................. 24

FIGURE 8 - OVERVIEW OF DISTRIBUTED DC ARCHITECTURE ................................................................................ 26

FIGURE 9 - INTERACTION BETWEEN ACTORS/ROLES IN THE USEF MODEL. THE BLUE LINES ‘BUY FLEX’ AND ‘ENERGY

TRADING’ REPRESENT EXISTING ENERGY MARKETPLACES WHICH ARE ALREADY OPERATIONAL. THE GREEN LINES

REPRESENTING ‘BUY FLEX’ AND ‘REQUEST FLEX’ CAN BE DEFINED BY EITHER BILATERAL CONTRACTS OR A

FLEXIBILITY MARKET PLACE. .................................................................................................................... 28

FIGURE 10 - CATALYST FRAMEWORK ARCHITECTURE ....................................................................................... 73

FIGURE 11 - CATALYST MARKETPLACE DESIGN ............................................................................................... 74

FIGURE 12 - CATALYST OPTIMIZATION ENGINE DATA MODEL ........................................................................... 78



7

List of Tables

TABLE 1 - ACTORS IDENTIFIED WITHIN THE CATALYST FRAMEWORK ................................................................... 14

TABLE 2 - CATALYST SCENARIOS CLASSIFICATION ............................................................................................ 30

TABLE 3 - CATALYST USE CASE TEMPLATE ...................................................................................................... 41

TABLE 4. FUNCTIONAL REQUIREMENTS DEFINITION TEMPLATE ............................................................................ 64

TABLE 5 - FUNCTIONAL REQUIREMENTS DESCRIPTION TEMPLATE ........................................................................ 64

TABLE 6 - FUNCTIONAL REQUIREMENTS FOR DC OPTIMIZATION MACRO LAYER ..................................................... 64

TABLE 7 - FUNCTIONAL REQUIREMENTS FOR NETWORKS CONNECTION INTEGRATION MACRO TIER .......................... 67

TABLE 8 - FUNCTIONAL REQUIREMENTS FOR MARKETPLACES MACRO TIER ........................................................... 67

TABLE 9 - NON-FUNCTIONAL REQUIREMENTS CONSIDERED FOR THE CATALYST FRAMEWORK ............................... 71

TABLE 10 - CATALYST FRAMEWORK COMPONENTS AND REQUIREMENTS MAPPING ............................................. 75

TABLE 11 - LEGEND OF TABLE COLOURS .......................................................................................................... 78

TABLE 12 - SERVER DEVICE MEASURE PROPERTIES ......................................................................................... 79

TABLE 13 - RACK AND AISLE PROPERTIES ....................................................................................................... 80

TABLE 14 - VM/TASK PROPERTIES STORED IN THE DATA MODEL ........................................................................ 80

TABLE 15 - COOLING SYSTEM PROPERTIES ...................................................................................................... 81

TABLE 16 - HEAT REUSE SYSTEM PROPERTIES ................................................................................................. 81

TABLE 17 - PHOTOVOLTAIC PANEL DEVICE MEASURE PROPERTIES .................................................................... 82

TABLE 18 - ENERGY STORAGE PROPERTIES ...................................................................................................... 83



8

List of Acronyms

ACPI Advanced Configuration and Power Interface

ATES Aquifer Thermal Energy System

BRP Balance Responsible Party

DCIM DC Infrastructure Management

DC Data Centre

DFVS Dynamic Frequency and Voltage Scaling

DHC District Heating and Cooling

DLC Direct Liquid Cooling

DR Demand Response

DSO Distributed System Operator

FDU Fluid Distribution Unit

GPU Graphics Processing Unit

HGO Heat Grid Operator

HPC High Performance Computing

PUE Power Usage Effectiveness

RES Renewable Energy Sources

SLA Service Level Agreement

TRL Technology Readiness Level

TSO Transmission System Operator

UPS Uninterruptible Power supply

USEF Universal Smart Energy Framework

QoS Quality of Service

WP Work Package



9

Executive Summary

This document is the first deliverable of the CATALYST first technical work package, namely, WP2: “Pre-

CATALYST Results Analysis and Design” and it reports the work conducted in two tasks: Task 2.1: Use

cases & pre-CATALYST Results Analysis and Task 2.2: CATALYST framework architecture design.

This deliverable describes the preliminary set of the CATALYST specifications and design, which shall

be the basis for the CATALYST framework and its components.

To achieve our goal, we have started by investigating CATALYST opportunities in our pilot Data Centres

(DCs) identifying the core innovative features of each such as: the free air and water cooling (ENG),

passive water cooling connecting to the drinking water grid (SBP), waste heat/cold reuse via heat

pumps for district heating and space heating/cooling of co-location DC offices (SBP & PSNC), smart

waste heat reuse in pre-heating diesel engines in Uninterruptible Power supply (UPS) systems (SBP),

renewable integration with batteries and thermal management system (PSNC), heat demand-driven IT

workload balancing in a fully distributed DC (QRN), and IT load relocation between legacy/commercial

DCs belonging to different administrative domains (i.e. follow the energy). At the same time to ensure

compatibility and wide adoption, the opportunities provided by the Universal Smart Energy Framework

(USEF) have been investigated in depth to make CATALYST framework compliant with USEF

specifications.

Based on the current best practises regarding DC energy efficiency optimisation, demand flexibility

management and opportunities provided both by the CATALYST pilots and by USEF, we have defined

seven visionary scenarios. We have classified them according to the commodities (electricity and

energy flexibility, heat and IT Load) that the DCs may exploit to gain new revenue streams and decrease

they overall carbon footprint:

• Scenario 1: Single DC Providing Electrical Energy Flexibility – DC optimization to deliver energy

flexibility services to the surrounding electrical energy grids;

• Scenario 2: Single DC Providing Heat – deliver heat to the local heat grid;

• Scenario 3: Workload Federated Data Centres – Exploit relocation of traceable IT load between

federated DCs, to match the IT load demands with time-varying on-site renewable availability;

• Scenario 4: Single DC Providing both Electrical Energy Flexibility and Heat – DC optimization to

deliver both electrical energy flexibility services and heat to the surrounding energy (power and

heat) grids;

• Scenario 5: Workload Federated DCs Providing Electrical Energy Flexibility – migration of

traceable ICT-load between DCs to deliver energy flexibility services to the surrounding power

grids;

• Scenario 6: Workload Federated DCs Providing Heat – Relocate IT load between DCs to

improve the quantity and quality of heat delivered to local heat grids;

• Scenario 7: Workload Federated DCs Providing both Thermal and Electrical Energy Flexibility –

relocate traceable IT load between DCs to deliver both heat and energy flexibility.

The definition of scenarios is done incrementally, Scenarios 1,2 and 3 considering network

connections in isolations, Scenarios 4,5 and 6 consider combinations of the two network connections



10

together, while Scenario 7 is the most complex one, in which all three network connections are

considered at once.

An initial set of use cases, and subsequently system requirements, have been coherently and

consistently derived from these scenarios and grouped based on the main vertical functional macro

tiers that the CATALYST framework may provide:

• DC Optimization Engine - deals with individual DC optimization to offer energy flexibility

services, heat reuse, etc.

• Networks Interface – deals with integration with smart energy grids, thermal grid and DCs

federation;

• Marketplaces – feature Marketplace as a Service approach to instantiate various flavours for

trading electrical energy, flexibility, heat and IT load.

Of particular importance in requirements elicitation process was the DC and energy domain knowledge

gained in previous projects, such as GEYSER (Green Networked Data centres as energy prosumers in

smart city environments) [1] and DOLFIN (Data Centres Optimization for efficient and environmental

friendly internet) [2], upon which the CATALYST proposal was built and partially EURECA CSA project

which aims to innovatively bring energy efficiency in near-commercial ready status.

The functional system requirements were prioritized and grouped into components that where

coherently organized to provide the first version of the CATALYST framework architecture. The

investigation was also carried out in the context pre-CATALYST results to identify those components

that implement similar requirements and that can be reused. If such components are identified, then

their Technology Readiness Level (TRL) is assessed along with their TRL jump aimed to be achieved in

CATALYST. Otherwise new components to be implemented are defined.

Finally, all defined components, both new and existing, are coherently organized into a general

CATALYST framework architecture with three horizontal layers:

• Monitoring and Control Layer (electricity and heat/cool), including both generated, stored and

consumed energy by distributed sources across the ecosystem;

• ICT Layer, including innovative technologies and communications load in a single DC, in a

group of federated DC grids or in distributed DCs;

• Coordination Layer allowing unified access to both energy (electrical and thermal) and ICT

loads across the ecosystem.

This document will drive the efforts of the other technical WPs (WP3-WP6) in the implementation and

delivery of the CATALYST framework, while feedback received from integration, trials evaluation and

communication activities, especially in relation to the Green Data Centre Stakeholder Group and the

project’s Advisory Board (WP7 and WP8) will be used for further refinements and improvements of

CATALYST specifications and design.



11

1. Introduction

This document is the first deliverable of the CATALYST first technical work package, namely, WP2: Pre-

CATALYST Results Analysis and Design and it reports the work conducted in two tasks: Task 2.1: Use

cases & pre-CATALYST Results Analysis and Task 2.2: CATALYST framework architecture design.

In particular, in this deliverable we:

• define suitable scenarios and use cases to be analysed and provide directions toward novel

techniques for improving Data Centres (DCs) energy efficiency considering electricity, including

flexibility, heat and IT load;

• extract both functional and non-functional requirements that should be met by the CATALYST

framework;

• propose the first version of the CATALYST framework architecture along with the data model

to capture and optimize DCs operations.

Intended Audience

The intended audience of this report is primarily the members of the project’s consortium and

European Commission (EC) representatives tasked with reviewing the project and its progress towards

meeting the specified milestones. The document effectively communicates the CATALYST framework

specifications and design to the members of the development team as it will drive the efforts of the

other technical WPs. Project stakeholders (DC Operators, Distribution System Operators (DSOs), Heat

Grid Operators (HGOs), etc.) may also use it to evaluate the adequacy of the CATALYST framework from

the perspective of their individual areas of expertise.

Relations to other activities

As it can be seen in Figure 1, WP2 and in particular D2.1 deliverable, drives the efforts of the other

technical WPs (WP3, WP4 and WP5) in the implementation and delivery of CATALYST framework and

its tools. Also, WP2 defines the CATALYST architecture which will provide the basis for integration of

all technical components in a single near-commercial platform. This work will be carried out in WP6.

The scenarios and use cases defined serve as a starting point for defining and setting up the

evaluation trials in WP7 and for setting up exploitation and commercialization activities in WP8.

Feedback received from integration, trials evaluation and communication activities, especially in

relation to Green Data Centre Stakeholder Group (GDC-SG) and the project’s advisory board, (WP6,

WP7 and WP8) will be used for further refinements and improvements of the CATALYST specifications

and design.



12

Figure 1 – WP2 relation with other work packages

Document overview

The remainder of this report is organized as follows:

• Chapter 2 provides a description of the methodology followed during this first phase of

requirements elicitation and analysis. This chapter also includes an introduction of the main

actors in the CATALYST scenarios and use cases along with underlying assumptions used to

define the scope of the CATALYST framework.

• Chapter 3 provides an overview of the CATALYST pilot DCs and the Universal Smart Energy

Framework (USEF) to identify opportunities for the CATALYST framework.

• Chapter 4 describes the seven (7) main CATALYST scenarios illustrating the project’s thesis

where DCs capitalise on their available commodities, that is electricity, heat and IT load, to

lower their operational costs while creating new revenue streams;

• Chapter 5 and 6 define the specific use cases along with the extracted high-level functional

requirements, establishing thus the first step towards the design of the overall system. The

non-functional requirements are also listed within chapter 6.

• Chapter 7 describes the first version of the CATALYST framework architecture, optimization

data model and expected progress beyond Pre-CATALYST results.

• Finally, Chapter 8 concludes this report.



13

2. Requirements Elicitation and Analysis Process

Overview

This chapter describes the method adopted by the CATALYST project so as to carry out the

requirements elicitation and analysis. Additionally, the main actors of the CATALYST framework are

identified along with the constraints and assumptions that are taken into consideration while defining

the CATALYST specifications and design.

Adopted Method

The goal of the requirement analysis and elicitation first phase is to discover the boundaries of the

CATALYST framework in relation with the problem domain and the objectives defined during the

proposal writing phase [1].

Figure 2 - CATALYST requirements elicitation and analysis

Figure 2 presents an overview of this process which involves the following phases:

• Requirements Discovery – the main objective of this phase is to gather and understand the

requirements of the CATALYST project. This information is gathered from stakeholders,

regulation entities, industry standard specifications and research references, etc. Of particular

importance is the DC and energy domain knowledge gained in previous projects such as

GEYSER, DOLFIN and EURECA upon which the CATALYST proposal was built. At the same time,

we are relying on the CATALYST pilot DCs and partners from the energy sector to provide state



14

of the art knowledge and identify opportunities from both the DC and energy domains. It

features the following steps:

o Collection of information from various sources on project main hypothesis (i.e. DC

energy efficiency, energy grids integration and energy markets).

o Scenarios elaboration – the information gathered is analysed, grouped and

summarized in several scenarios which are mainly stories that do not necessarily

reflect the framework actions and are technology agnostic.

o Use-cases definition – starting from the previously defined scenarios, use cases are

derived focusing on functionality and the interactions between an actor and the

envisaged CATALYST framework to achieve a certain goal.

• Requirements Classification & Prioritization - In this phase a general taxonomy for the

requirements set (both functional and non-functional) is specified, so that a coherent

classification of the requirements is established. In doing so, the number of requirements is

reduced, while their prioritisation is made easier. Requirements are then grouped together so

as to denote components of the general framework. Pre-existing CATALYST results are

considered so as to identify those components that implement similar requirements and can

be reused. If such components are identified, then their Technology Readiness Level (TRL) is

assessed along with the TRL jump to be achieved in CATALYST. Otherwise new components to

be implemented are defined.

• Architecture Definition – all components, both new and existing, are coherently organized into

a general CATALYST framework architecture.

Actors

Table 1 lists all actors identified within the CATALYST framework.

Table 1 - Actors identified within the CATALYST framework

The Data Centre Operator is responsible for maintaining a secure, scalable, and efficient DC

facility. The duties of the DC Operator entail oversight of the hardware infrastructure, network

infrastructure, provisioning and maintenance practices, security practices, disaster recovery

planning and execution, as well as general oversight of daily operations. The DC Operator is

also in charge of analysing and optimizing the energy balance of the DC operation.

The Prosumers have controllable assets and are thereby capable of offering flexibility. A

Prosumer can be regarded as an end user that no longer only consumes energy, but also

produces energy. CATALYST does not distinguish between residential end users, small and

medium-sized enterprises, or industrial users; they are all referred to as Prosumers. The DC

itself is seen as a prosumer. 1

The Flexibility Aggregator role is to accumulate flexibility from Prosumers and sell it to the DSO.

The Aggregator is also responsible for the invoicing process associated with the delivery of

flexibility. The Aggregator and its Prosumers agree on commercial terms and conditions for the

procurement and control of flexibility.1

1 As defined by the Universal Smart Energy Framework, https://www.usef.energy/

Prosumer

https://www.usef.energy/



15

The DSO is responsible for the active management of the distribution grid and for the cost-

effective distribution of energy while maintaining grid stability in a given region. To this end

the DSO may use flexibility from Aggregators to manage congestion points and can check

whether Demand Response (DR) activation within its network can be safely executed.1

Marketplace Operator (Flavours: Electricity, Flexibility, Thermal and IT Load) role is the

management, facilitation and operation of the marketplace.

The Heat Grid Operator (HGO) is responsible for the management of the heat distribution and

delivery system for both residential and commercial heating needs such as space heating and

water heating

The Heat Broker acts as an intermediator between the HGO(s) and heat producers who wish

to provide their residual heat to the local heating system. The Heat Broker is a transitional role

that combines the responsibilities of a heat aggregator and a supplier in the case of

decentralized heat networks.

This actor is a special electricity market participant responsible to bundle or aggregate clients

in an effort of gaining additional leverage over the buyers and suppliers when it comes to

negotiate offers and bids, and thus reaching agreements with more profitable prices.

Underlying Assumptions

A requirement assumption is a factor or condition that it is assumed to be true so that the CATALYST

framework operates successfully. Such assumptions are used to establish the boundaries of our

framework and directly influence the requirements context.

To determine the underlying assumptions considered by the CATALYST approach for DCs’ exploitation

of various commodities to gain new revenue streams and decrease carbon footprint we have leveraged

on the consoritum knowledge accummulated from combined experience and work in DOLFIN, GEYSER

and EURECA projects. During information collection step one-to-one and free-format conversations

discussions took place with various stakeholders’ members of CATALYST consortium such as the

representatives of pilot DCs (ENG, QRN, PSNC, SBP), distribution system operators (ALD) and USEF.

All the information gathered in the collection phase was exhaustively analysed and the following

assumptions were summarized:

• DCs are assumed to be at least Level 3 DCs as described in the Green Grid Maturity Model;

the DCs can be centralized or fully decentralized

• DCs are assumed to be located in an urban agglomeration benefiting from policies, operations

and infrastructure that enable smart transmission and distribution of electrical or thermal

energy;

• DCs have already in place the necessary sensors and systems for monitoring loads along with

the communication networks for collecting the monitored data. Also they use DC Infrastructure

DSO



16

Management (DCIM) software, or equivalent system(s), for monitoring and controlling the

facilities and IT resources including load balancing features;

• DCs have already in place the necessary actuators and control infrastructure for mapping the

high level energy flexibility optimization actions to physical resources and enforcing them

considering Quality of Service (QoS) requirements and time constraints;

• Whenever feeding electricity, thermal energy or a combination of them in the corresponding

grid is considered, it is assumed that the DCs have connection points and corresponding grid

connecting equipment (e.g. heat pumps for thermal);

• Whenever workload relocation to partner DCs is considered, it is assumed that the DCs have

established secure communication channels for IT workload migration;

• Whenever the possibility of incorporating the on-site generated energy is considered, DCs are

supposed to have in-house renewable energy sources in their premises.



17

3. CATALYST Opportunities in Today’s DCs and

Energy Market

In this chapter we describe briefly the hardware and software infrastructure of our pilot DCs. In doing

so we identify the opportunities the CATALYST framework can exploit so as to improve the efficiency

of their operations in relation with electrical energy flexibility, heat reuse and IT load relocation. They

provide the basis for prioritizing the CATALYST functional requirements and deriving the non-functional

requirements. The chapter also provides an overview of the USEF model used to derive the operating

rules and interfaces the CATALYST marketplaces should comply with.

Pilot #1: Green Pont Saint Martin DC

3.1.1 Overview

PSM is a colocation DC located in the namesake town in the Aosta Valley region of northwest Italy.

Green PSM is an industrial DC of 6,000 m2, with 4 levels of physical security to access the structure

of 2.700 m2 of separate and self-sufficient bunkers for power supply and connectivity. The main

business of PSM Green DC is to offer hosting and outsourcing services to its customers. PSM DC is

one of the 4 Engineering DCs spread throughout Italy and grouped in geographical HUBs. The North

West HUB is constituted by DCs in Turin and PSM; the North East Hub involves Vicenza and Milano

DCs. The 4 DCs are connected by a broadband fibre-ring; this configuration has been put in place in

order to guarantee easy accessibility and immediate responses to business requests for clients.

Vicenza DC, a Tier 4 DC, works in particular for disaster recovery and business contingency.

PSM DC uses a latest generation geothermic system that exploits the water at 13 degrees Celsius in

the underlying waterbed for the cooling system, offering the optimal setup for testing and evaluating

the use of non-electrical cooling as a potential source of electrical and thermal energy flexibility.

Although CATALYST ENG pilot will mainly focus on the PSM DC, Turin and Vicenza DCs will also be

involved to perform an internal workload federation among ENG DCs and test the potential of workload

relocation as a source of energy flexibility. More details are provided in the subsections that follow.

3.1.2 Main Characteristics

The PSM DC utilises a geothermal system for cooling purpose. The geothermal system currently in

place takes advantage of water (50 l/s at 13/14°C) that is extracted by water pump from an

underlying aquifer through 40 meters deep well. There are two deep wells in PSM since one of them

is used as backup. Moreover, there are two towers that can be used in case the well is empty or both

pumps do not work. The geothermal system, as it was conceived, is able to work continuously.



18

The PSM cooling system, as depicted in Figure 3, is composed by a closed loop: the geothermal water

(about 30 l/s) is used by the two Trane: Heating and Air Conditioning Systems2 (there is another one

that is used as backup) to refrigerate the water coming from the Air-Conditioning units located in the

bunkers, the Air Handling Units (AHU) and Fan Coil Office Air-Conditioning systems. In this way the

water temperature in the closed loop is lowered by four degrees (from 10°C to 6°C).

The water (about 20l/s) of the other loop, extracted by the underlying aquifer, is also used to lower the

water temperature before being dispersed in the river. This is because the water that is heated as a

result of the refrigeration process in the closed loop, cannot be dispersed in the river (Lys) as is but its

temperature has to be lowered as required by environmental regulations.

The geothermal system permits a 20% saving in electricity and an increased cooling capacity. The

geothermal system has allowed obtaining an average Power Usage Effectiveness (PUE) of 1.52.

Figure 3 - Geothermal Cooling system of PSM DC

The refurbishment of the Cooling System is planned to start at the beginning of next year (2019) and

should cover a period of about 5-6 months. Consequently, the cooling system of PSM DC, depicted

above will be modified. The main changes are related to the building of two new wells allowing to

2 www.trane.com/Index.aspx



19

increase the water flow rates. Moreover, next generation of air conditioners will be installed. This will

allow to dismantle the three Trane that will be replaced by heat exchangers; the two towers will be

removed too. Significant savings in energy consumption can be made since currently each Trane

requires a power consumption of about 100 kW.

The updated and improved cooling system will also include the installation of heat pumps to reuse the

heat generated in the DC. The heat recovery system will be used to heat the DC’s offices during the

winter months, allowing for evaluating the impact of thermal flexibility and additional thermal inertia.

It is important to underline that possible delays in the PSM Cooling system refurbishment may have

an impact on the practical pilot validation of some CATALYST scenarios.

Figure 4 - Electrical system Layout of PSM DC

Figure 4 presents the PSM DC electrical system which is composed of:

1. Three generator sets (synchronous machines), each one of 1750 kVA, 50 Hz, 1500 rpm

which are connected in parallel and provide energy to both backbones line A and to

backbone line B. Two generators out of three are enough for the needed power, the third is

for redundancy;

2. Four transformers, a couple per backbone, with each couple consisting of two transformers

connected in parallel in order to ensure redundancy from grid supply;

3. Three UPS of 800 kVA connected to the backbone line A and two UPS of 1000 KVA

connected to the backbone line B.



20

Three diesel generators (3 x 1750kVA, cosϕ 0,8) are used as emergency power-supplies if the grid

fails. Those engines are capable of ensuring 5 days of continuous energy supply to the DC, whose

energy consumption is about 1 GW/month. In order to avoid any interruption in providing electric power

to the IT equipment, PSM DC is equipped with batteries and Uninterruptible Power Supply (UPS) blocks,

which can supply the overall DC for more than 20 minutes.

The periodic maintenance of the backup generators in PSM can be exploited to test the cost-

effectiveness of self-supply when, for example, an increase in energy price is foreseen.

Several Honeywell meters and sensors are installed for monitoring and controlling the facility and the

IT equipment of PSM DC. They are installed at room level or DC site level and are using the Modbus

protocol for data communication.

Pilot #2: Poznan Supercomputing Centre DC

3.2.1 Overview

PSNC operates one of the 5 main national Polish High Performance Computing (HPC) centres. As such

its main focus is on delivering high class computing and storage resources for scientists who need

large-scale computations or advanced visualisation. Most of these advanced systems are installed in

the newest PSNC DC (started in 2015) collocated with the main office building and located in proximity

to the campus of the Poznan University of Technology.

PSNC also offers other types of services including IaaS and hosting/colocation (using its previous DC

infrastructure). These services are offered to industry. PSNC also collaborates with various scientific

and industrial partners using its laboratories for development, tests, and evaluation of new products

or technologies. Some of these laboratories concentrate on technologies related to DCs and energy

management. Important part of the PSNC’s infrastructure is networking, as PSNC leads the consortium

of the PIONIER optical network in Poland.

PSNC aims at adopting and developing solutions that reduce energy costs. Its infrastructure contains

the system for re-use of wasted heat from the DC to heat offices and the photovoltaic system for

renewable energy production on the roof of its building.

Taking into account the scale of the PSNC DC infrastructure, the reduction of its energy related costs

is a very important issue. On one hand, they affect costs of PSNC commercial offerings and, on the

other hand, have a big impact on operational costs of the research infrastructure (for which only capital

costs are usually funded by research infrastructure programmes).

As currently PSNC does not use any dynamic interactions with utilities, an analysis of potential profits

coming from interaction with marketplaces is needed. It should include investigation of possible

monitoring and control of DC flexibility. In particular, taking into account the significant amount of heat

produced by PSNC DC and the existing heat re-use system, it is important to study its control and

potential large scale use. To this end a thermal model of a DC is needed to assess its thermal flexibility.



21

PSNC also plans to optimize the use of renewable energy from its photovoltaic system. To achieve this,

it plans to deploy solutions from the CATALYST project in its testbed aiming to integrate thermal

models, energy storage management, and workload management.


PSNC main DC is located on two levels covering an area of 1600 square meters. Currently its maximum

power capacity is around 2MW (with possible maximum 16MW). The DC is partially equipped with

direct liquid cooling (DLC) and in-row cooling, which are used for the HPC part of the DC. The centre’s

IT equipment includes diverse top class systems such as clusters of high performance servers, SMP

machines (systems with large memory), and hybrid CPU-GPU systems. Measured Power Usage

Effectiveness (PUE) is equal to 1.3 whereas the partial PUE of the biggest system (described below)

reaches 1.05.

The most powerful supercomputer deployed in the PSNC DC is the “Eagle” cluster whose computing

power exceeds one peta flops (1372,13 TFLOPS). The cluster contains 32984 CPU cores of Intel Xeon

E5-2697 and 120,6 TB of memory. Eagle is on the list of fastest supercomputers all over the world

according to TOP500 ranking announced each year at the Supercomputing conference (around 100th

place at SC 2015 and ISC 2016 conferences). The system organized into hot isle cabinet is cooled

using direct liquid cooling technology from CoolIT company applied to cool CPUs and memory

accompanied by in-row cooling for the remaining heat. The total power usage of Eagle (running linpack

benchmark) is around 450kW.

The testbed to be used in CATALYST consists of small (micro) DC resources connected to a photovoltaic

system.

The infrastructure contains a setup based on the HUAWEI FusionServer X6800. Each of these nodes

comes with the following configuration: Intel Xeon E5-2600 v3 processor, 64GB DDR4, 2133MHz

memory, 1TB, 7200RPM storage, and 10GbE network. Moreover, there are 2 servers containing two

Intel Xeon E5-2600 v3 processors and two GPU Accelerators based on the NVIDIA Tesla K80. In total

this system provides 18 nodes, 36 CPUs, 288 CPU cores, and 4 GPU units. Half of the system is cooled

using Direct Liquid Cooling (DLC) method, while the other half exploits air based cooling (AC). The

former setup follows Ebullient3 approach, supporting two-phase cooling process based on liquid and

vapour heat removal. At the server level, DLC is applied to the processors, GPUS as well as to the

memory units. Applied Ebullient Fluid Distribution Unit (FDU) unit dissipates heat to the surrounding

environment via a liquid-to-air heat exchanger.

In addition to this system there are around 100 additional nodes of various architectures such as ARM,

AMD, GPU (including microservers). These servers are air-cooled.

3 http://ebullientcooling.com/

http://ebullientcooling.com/



22

The photovoltaic system (with 20kW of peak power) consisting of 80 PV panels is available and

integrated with a testbed. The system contains an energy storage consisting of batteries with a total

capacity of 75kWh.

As the primary goal of the PSNC DC is to serve scientific workloads, most of the time-consuming

computations are managed by the SLURM system (popular in today’s HPC centres). Other software

stacks include OpenStack for IaaS management, Ceph for storage, Zabbix for monitoring, Xen, KVM

for virtualisation, among others.

Most of this software is available in the testbed along with dedicated SLURM and OpenStack

installations. There are already extensions for SLURM for power management features. It is also

possible to add such features to OpenStack by extensions of the Nova compute module. Therefore,

using also appropriate server and OS features as well as PSNC tools it is possible to apply Dynamic

Frequency and Voltage Scaling (DFVS), power capping and Advanced Configuration and Power Interface

(ACPI) states management strategies to control the power usage.

The testbed infrastructure is monitored by the PSNC BEMOS software4, which integrates and visualises

data from servers, sensors, meters and photovoltaic system.

Pilot #3: Schuberg Philis DC

3.3.1 Overview

Schuberg Philis is operating a DC which has a very efficient cooling installation using a combination of

cooling towers and Aquifer Thermal Energy System (ATES). Next to these cooling generation systems,

the distribution of the cooling water and in-room cooling units have been optimized. The ATES is “in

balance”: during the summer we extract cooling capacity and during the winter we store cooling

capacity.

Next to this, Schuberg Philis recently implemented an innovative technology for water treatment in

DCs. Using this water treatment installation more than 90% discharge water of cooling towers is saved,

we are chemical free, and the installation is cleaner than before.

Since Schuberg Philis already optimized the cooling installation, the company wants to take the next

step in optimization towards re-using the residual heat of its DC. Schuberg Philis aims at using a water

distribution system for transportation of heat capacity from DCs to nearby green houses.

Schuberg Philis is providing IT services while using an office that serves approximately 250 colleagues.

Currently this office is heated during the winter period using natural gas. The goal is to become natural

gas free by using the generated heat in the DC for heating the office.

4 http://labee.psnc.pl

http://labee.psnc.pl/



23

The DC is using diesel engines for the UPS installation and these diesel engines need to be pre-heated.

Pre-heating is currently electrical and as such is consuming too much energy. Part of the pilot would

be to investigate how to reuse residual heat in the installation to pre-heat the diesel engine as well.

The diesel engines are part of a Dynamic Rotating UPS system. During one of the pilots Schuberg Philis

we will investigate the efficiency differences between a dynamic rotating UPS system and a static UPS

system as well as their usage as potential source of energy flexibility.

Together with Alliander we will investigate the necessary agreements and communications for UPS

owners and operators to start their systems when prompted as a preventive measure to “relieve net -

supply”.

In addition, within the Schuberg Philis DC there is colocation capacity available for Qarnot Computing.

Since both Qarnot and Schuberg Philis are partners of Asperitas, an Immersed Computing SME in the

Netherlands, we will investigate opportunities to connect this trial with possibilities of such promising

technology.


The cooling installation within the DC is comprised of two cooling towers with a total cooling capacity

of 1500 kW and three ATES with a total cooling capacity of 1500 kW (see Figure 5).

Figure 5 - Cooling towers for extracting / storing cooling capacity

Calculation during the last year resulted between the 150—200 kW of heating with a maximum of 55

degrees Celsius. Figure 6 shows the heat generation infrastructure.



24

Figure 6 - Actual heat generation with natural gas

Figure 7 shows the diesel engines that need between 15-25 kW of heating with a temperature

around the 45 degrees Celsius and the actual gas based preheating system. The dynamic rotating

UPS systems from Hitec Power Protection have an apparent power of 4 1700 kVA.

Figure 7 - Diesel generator and actual pre-heating

Pilot #4: Distributed Qarnot DC

3.4.1 Overview

Qarnot DC is fully distributed among buildings spread over different cities, in France for now but

hopefully in a broader area in the near future.

The “DC” within the buildings is split into smaller units called QBox composed of 3 servers each. These

smaller units are also used as electric heater with a thermostat. According to the thermostat target



25

temperature, set by inhabitants, the “heaters” will request more or less IT loads to heat the premises.

Thus QRN virtual DC is sensible to actual weather and ambient temperature.

Mainly at this point Qarnot propose computing intensive services as PaaS. IT loads consists mainly in

3D rendering and financial risk analysis. As PaaS, Qarnot provides the following services: tasks

scheduling, data transfer (base system, container images / VM disks, user resources, results), actual

execution of task instances, internet access from a running user task (from inside a Docker container)

and finally live monitoring of executing tasks and reports of completed tasks.

Qarnot also offers IaaS services. Regarding storage and data, Qarnot only offers data synchronisation

between a central, S3-compatible object storage (what OpenStack Swift would offer) and the

computing sites, reliably at computing tasks start up and completion, and as an optional best effort

synchronisation during execution. The computing nodes do not embed any storage devices, data is

stored on the QBox and accessed through the network. In particular, Qarnot does not offer any of the

following:

- fast ephemeral local storage usable as a scratchpad or swap (we can fake it using a ramfs,

but it’s very limited in capacity);

- globally available network storage, shared and synchronised throughout our whole distributed

DC (what OpenStack Manila would offer);

- network block devices (what OpenStack Cinder would offer).

The current infrastructure is fit (and optimised for) for batch or clustered computing tasks (3D

rendering, Monte-Carlo, physics, genetics, blockchain mining, etc.), but not for some other traditional

DC hosted services like web fronts, database hosting, message brokers, etc. at least not where high

performance is needed.


The Qarnot distributed organization is achieved through a REST API connect clients to storage and the

computing infrastructure (see Figure 8). The virtual access points are named Qnode and are hosted in

regular DC. Then through the internet we access Qbox that are the actual entry points in each building.

These Qbox are then connected to Qrad (our heater that enclose 3 servers) through regular gigabit

Ethernet private network.

Qnodes in DC are regular servers with contractual Service Level Agreements (SLAs), negligible

compared to the overall infrastructure. In every building, at least one Qbox, connected to the internet

through optical fibre, is the entry point to the private network managed by Qarnot (which can be gigabit

Ethernet, optical fibre, or a mix). The Qbox is constituted of a server, storage, and a switch. The Qbox

capacity is depends on the number of computing units attached to it. Each Qrad, the space heater, is

composed of a manageable switch and 3 motherboards. The current generations do not embed any

local storage.



26

Figure 8 - Overview of distributed DC architecture

Regarding the power supply, it depends on installation site. Either electricity is provided by inhabitants

and measured by Qarnot to be reimbursed. Or Qarnot is also managing the electricity supply in order

to avoid reimbursement administrative work. The available data is limited to actual electrical

consumption of each Qrad and the maximum available power per site, per flat.

On software side Qarnot had developed its own resource manager, Qware, to exploit its unique

platform. Basically, the Qware monitors actual needs (request) for heat as the very local level to decide

the where to send IT loads. The Qware is also responsible for synchronising input data from a central

(Internet available) storage, making it accessible to the computing nodes through network shares, and

uploading results to a central data store. IT loads are containerized using Docker technology. As

computing loads are deployed directly on bare metal, the use of virtualization inside the container is

possible, but not generally recommended.

Universal Smart Energy Framework (USEF)

The Universal Smart Energy Framework (USEF) was established to enable a smart energy market

encompassing all players including the DSO and (residential) prosumers through energy aggregators.

The framework includes a market structure and the associated rules and tools required to integrate

flexibility. It fits on top of most energy market models, extending existing processes to offer the

integration of both new and existing energy markets.

USEF aims to provide an integral flexibility market model which includes all stakeholders in the energy

system. Flexibility requirements and offers are traded on a flexibility market centred on the aggregator

role. The Aggregator’s goal is to maximize the value of that flexibility by providing it to the service

defined in the USEF flexibility value chain that has the most urgent need for it. The Aggregator must

cancel out the uncertainties of non-delivery from a single Prosumer so that the flexibility provided to



27

the market can be guaranteed. This prevents Prosumers from being exposed to the risks involved in

participating in the flexibility markets.

Nowadays focus is on encouraging its adoption in EU as a standard template for national markets that

want to integrate flexibility into their energy system and regulatory framework. It has already been

applied in multiple projects and by two DSOs and several aggregators in the Netherlands. Further

implementations are planned or already in progress in the Netherlands, Scotland and Germany.

3.5.1 Market Roles and Congestion Management Process

The main roles in USEF processes are the flexibility aggregator and DSO (see Section 2.2), and Balance

Responsible Party (BRP) which have a direct access to the market. A Balance Responsible Party (BRP)

is responsible for actively balancing supply and demand for its portfolio of Producers, Suppliers,

Aggregators, and Prosumers. The Prosumer’s balance responsibility is generally transferred to the

BRP, which is usually contracted by the Supplier. Hence the BRP holds the imbalance risk on each

connection in its portfolio of Prosumers. In addition, the Transmission System Operator (TSO) (via the

BRP) and the prosumer (via the aggregator) are involved having an indirect access to the market

through respective third parties. The role of the Transmission System Operator (TSO) is to transport

energy in a given region from centralized Producers to dispersed industrial Prosumers and DSOs over

its high-voltage grid. The TSO safeguards the system’s long-term ability to meet electricity transmission

demands. The TSO is responsible for keeping the system in balance by deploying regulating capacity,

reserve capacity, and incidental emergency capacity. Also, the role of the Supplier is to supply energy,

to buy the energy, hedge its position, manage the energy and the associated risks, and invoice energy

to its customers. The Supplier and its customers agree on commercial terms for the supply and

procurement of energy.

Supporting roles are the common reference operator, responsible for linking flexibility sources to

specific congestion points, and the meter data company. The interaction between the actors/roles are

depicted in a standard interaction template in Figure 9. The TSO and DSO are responsible for detecting

and forecasting congestion, defining the congestion area, receiving load forecast from aggregators

and requesting flexibility offers from aggregators. Congestion areas are published in an open access

repository and forecasting is mandatory for the published congestion areas. Congestion management

is performed by issuing flexibility requests to aggregators active in the congestion areas in advance of

expected congestion periods. The volume and price of the flexibility offered by aggregators is

negotiated in an iterative process, where the aggregator program is validated and offered to and/ or

with the BRP. The DSO is obliged to buy the offered flexibility at the price offered (single buyer must

buy).

In USEF, Active Demand & Supply (ADS) represents all types of systems that either demand energy or

supply energy which can be actively controlled. This enables the ADS device to respond to price and

other signals from the Aggregator and to provide flexibility to the energy markets via the Aggregator.

The Prosumer owns the device and defers responsibility for controlling its flexibility to the Aggregator.

The Prosumer has final control over its assets, which means the Aggregator’s control space is limited

by the Prosumer’s comfort settings. Hence the Prosumer is always in control of its comfort level; if the



28

associated remuneration is high enough however, the Prosumer might be willing to compromise on its

comfort levels. In this text we also use the terms units, assets or resources when referring to ADS.

In summary the congestion management process has the following steps:

• The DSO begins by communicating the congestion points and underlying connections with the

relevant stakeholders (aggregators, meter data companies) via the common reference

register.

• Next, the DSO receives a day-ahead plan (D-prognoses) from every aggregator in a congested

area and determines for which periods and congestion points overload situations are

expected.

• DSO formulates a corresponding flexibility request which is then sent to all related aggregators.

• The DSO assesses all received offers and orders flexibility based on best fit to the need and

price.

The DSO works through this process for all congestion points, the actions described above being all

executed up front, either day-ahead or intraday. At the time of execution, the DSO monitors the

situation to see whether the requested capacity stays within the limits and, where it doesn’t, he orders

flexibility based on open offers.

Figure 9 - Interaction between actors/roles in the USEF model. The blue lines ‘buy flex’ and ‘energy trading’

represent existing energy marketplaces which are already operational. The green lines representing ‘buy flex’

and ‘request flex’ can be defined by either bilateral contracts or a flexibility market place.

Sometimes insufficient flexibility is available to avoid an overload so the regime for that grid part

switches to orange. The DSO then directly intervenes in the market and in the relations between

prosumers and aggregators, by technically limiting connection capacity or using an alternative direct

measure to control the load. The technical and contractual requirements and implementation of this

direct control depend on the country or distribution grid where the framework is applied. During this

period, the market is overruled by the DSO. As soon as the situation allows it, the regime returns to

yellow.



29

In general, for the sake of security of supply and proper business evaluation, the aggregator and DSO

agree a long-term flexibility contract and activation well in advance of any expected congestion.



30

4. CATALYST Scenarios

Table 2 below show the CATALYST scenarios classification according to our vision of seeing the DCs

as technological hubs operated at the cross roads of data, electrical energy and thermal energy

networks trading electricity, energy flexibility, heat and IT Load as commodities. The definition of

scenarios is done incrementally, Scenarios 1,2 and 3 considering network connections in isolations,

Scenarios 4,5 and 6 considers combinations of the two network connections together, while Scenario

7 is the most complex one in which all three network connections are considered at once. The

scenarios highlight the importance of various commodities in gaining new revenue stream and

decreasing carbon footprint, the network connections providing the necessary infrastructure is

achieving this.

Table 2 - CATALYST scenarios classification

Scenario No.

Electrical Energy Network Thermal Energy Network IT Network

Electrical Energy and

Flexibility

Heat IT Load

CENTRALIZED or FULLY DESCENTRALIZED DCs

Scenario 1

Scenario 2

Scenario 3

Scenario 4

Scenario 5

Scenario 6

Scenario 7

Scenario 1: Single DC Providing Electrical Energy Flexibility

Objective

Optimize the DC operation to deliver energy flexibility services to the surrounding electrical

energy grids ecosystems to create new income source and reduce DC energy costs. Assess

resiliency of energy supply and flexibility, against adverse climatic events or abnormal demand,

trading off DC assets energy generation/consumption against local/distributed RES, energy

storage and efficiency.

Actor(s) DC Operator, Distribution System Operator, Energy Aggregator, Flexibility Aggregator, Prosumer,

Energy Marketplace Operator, Flexibility Marketplace Operator

Background The DC is a prosumer of electrical energy in the sense that it can be both a consumer and a

provider.

DC operator has established a flexibility purchase contract with a Flexibility Aggregator in the

sense considered in the Universal Smart Energy Framework (USEF), as in charge of ‘acquiring

flexibility from Prosumers, aggregating it into a portfolio, creating services that draw on the

accumulated flexibility, and offering these flexibility services to different markets, serving

different market players’ [1]. The contract includes the operating conditions for the flexibility



31

service executed by the Flexibility Aggregator and the details on the settlement of the flexibility

provided by the DC.

Flexibility Aggregator has implicitly established a flexibility service contract (through the

Flexibility Marketplace) with the local Distribution System Operator (DSO). Also, it is registered

in the Common Reference, which contains the list of each Congestion Areas published by the

DSO. This can be accessed by Flexibility Aggregator to check whether it has enough aggregated

flexibility from its customers in the congested area to be able to offer to the DSO.

DC is acting as a prosumer participant on the Local Electrical Energy Marketplace buy or selling

energy directly to/from other energy prosumers or from an Energy Aggregator.

At the same time the DC has collaboration agreement with the DSO for participating in direct

electricity Demand Response (DR) programs in case of emergencies (i.e. the grid is in the

orange or red management zone) contributing to smart grid stability and security of energy

supply at district level.

DC is able to evaluate and forecast its actual IT load capability and energy demand on daily

basis. DC is able to provide internal forecasts related to energy consumption and production

to both Flexibility and Energy Aggregators on a daily basis.

The DC has the technical capability of internally rearranging its operation so as to meet the

underlying flexibility requirements by, for example:

i. falling back to their own energy storage reserves;

ii. exploiting free-air and water cooling techniques;

iii. properly managing renewable energy generation at onsite RES;

iv. exploiting the maintenance process of diesel generators

v. considering IT workload consolidation or temporal shifting, etc.

Narrative DCNAME is a green hybrid DC located in the city of CITYNAME. DSONAME identifies a

congestion point, identifies the grid connections to this congestion point and declares it in the

Common Reference Operator (CRO) registry. AGGREGATORNAME1 can contract prosumers,

including DCNAME, connected to this congestion point to offer flexibility.

On daily basis (day-ahead trading of flexibility):

• AGREGATORNAME1 creates and sends a forecast of the aggregator energy demand

of all its clients to de DSO;

• DSO uses these forecasts to create a forecast of the total load on the congestion

points

• In case congestion is forecasted:

a. DSO sends a flexrequest to the Flexibility Marketplace;

b. AGGREGATORNAME1 respond to this flexibility request by placing a flexibility

offer in the Flexibility Marketplace;

c. DSO can accept one or multiple flexibility offers and if so, the DSO sends a

flexibility order;

d. AGGREGATORNAME1 will adjust the load of its clients to fulfil the flexibility

need

• Intraday: the above steps are repeated

Settlement: AGGREGATORNAME1 will pay DCNAME for the flexibility provision based on the

previously agreed flexibility contract.

During the next operational day due to weather conditions there is an increased demand of

energy and the energy price is high. DCNAME is able to decrease its energy consumption in

intraday and to make additional profits by selling through the Electrical Energy Marketplace the

on-site electrical energy generated.



32

Diagram(s)

Scenario 2: Single DC Providing Heat

Objective

Optimize DC operations to deliver heat to the local heat grid. Recover, redistribute and reuse

DC residual heat for building space heating (residential and non-residential such hospitals,

hotels, greenhouses and pools), service hot water and industrial processes. DC participates to

the local Heat Marketplace trading heat and as such creating a new revenue source over longer

period for the DC. In doing so, the DC achieves significant energy & cost savings, reduces its

CO2 emissions, contributes to reducing the system-level environmental footprint and supports

smart city urbanization.

Actor(s) DC Operator, Heat Grid Operator, Heat/Cold Broker, Heat/Cold Marketplace Operator

Background The DC can be centralized or fully decentralized. The DC is assumed to be located in an urban

agglomeration benefiting from policies, operations and infrastructure that enable recovery,

redistribution and reuse of residual heat.

The DC is fully monitored in terms of energy consumption, heat generation and actual IT loads

and is able to evaluate and forecast its actual IT load capability and energy demand on daily

basis. Additionally, the DC cooling infrastructure should allow for the recovery of its residual

heat and its subsequent delivery to the local heat grid. Figure below provides an illustration of

the various DC temperature levels and their potential end-users. 5

Depending on the cooling technology in use, the DC may harvest heat at the desirable

temperature level. In any case, a heat pump may be in place to increase as necessary the low

calorific heat generated by the DC before its delivery to the heat grid. The DC may adjust its

server room temperature set points for limited time periods to increase the quality of the heat

to be reused. DC may capitalize on the use of a heat storage, such as a thermal energy storage

system, to store heat and deliver it to the heat grid in addition to the direct heat normally

supplied, increasing thusly its heat capacity.

5 M. Arts, Z. Ning (Royal Haskoning DHV), Datacenters connected to an intelligent energy network, TTVL Magazine, 2016 DATACENTERS. (Publication in Dutch)



33

The DC is a heat prosumer meaning that beside de delivering heat to the grid it can take back

the return flows to help its internal cooling processes.

The DC has a contractual agreement with the Heat Grid Operator to provide residual heat to

the local heat grid. The Heat Grid Operator is responsible for the transportation and distribution

of the heat to end consumers.

At the same time the DC may participate as a heat prosumer on the local Heat/Cold

Marketplace where it can trade its residual heat with other prosumers directly or with

Heat/Cold Brokers. The Heat/Cold Broker has the responsibility for the supply of heat at all

times and as such guarantees its continuous supply.

Narrative It is winter time in CITYNAME and an actual cold snap is forecasted for the next day, therefore

people will need more heat for heating building space. The local Heat Grid Operator would like

to reduce its heat production costs by replacing more expensive peak load production that will

be generated by the cold snap. Thus it sends a heat request to the DCNAME to buy its residual

heat for the next day. During the next operational DCNAME delivers the heat at the in the Heat

Grid at the contractual stated quality.

At the same time there is a high demand of hot tap water in the morning and a Heat/Cold

Broker HEATBROKERNAME publish a bid accordingly to the Heat/Cold Marketplace. DCNAME

operator see this as an opportunity for making extra profits and decides to act as a prosumer

participant to the Heat/Cold Marketplace. To increase the amount and quality of heat to be

traded as hot water DC operator decides to set higher temperature set points in the server

room for limited time period. It places an offer to the Heat/Cold Marketplace. All valid supply

offers are put in increasing price order on an aggregate supply curve and all valid demand bids

are put in decreasing price order on an aggregate demand curve, the clearing price at which

the offers are being remunerated being determined at the intersection of the two curves.

As result of delivering heat DCNAME will not only gain the financial benefits stipulated in the

Heat Grid Operator contractual offer but it will also gain additional benefits for selling hot tap

water. Also it will contribute to the reduction of emissions by substituting the peak load

production of heat being typically produced by the Heat Grid Operator using fossil fuels.



34

Diagram(s)

Scenario 3: Workload Federated Data Centres

Objective

Exploit migration of traceable ICT-load between federated DCs, to match the IT load

demands with time-varying on-site RES availability (including Utility/non-Utility owned legacy

assets) thus reducing the operational costs and increasing the share of renewable energy

used.

Actor(s) DC Operator, IT Load Marketplace Operator

Background DCNAME1, DCNAME2, and DCNAME3 are registered to the IT Load Marketplace, through

which they are able to relocate IT workload among each other using the marketplace

interaction mechanism. They can also opt for workload relocation based on bilateral

agreements if they have previously signed such an agreement with partner DCs. DCs is

aiming to increase the amount of renewable energy used for its operation.

NETWORKEDCSNAME is a Networked Cloud provider, owning DCNAME1 located in

CITYNAME1 and DCNAME2 located in CITYNAME2. DCNAME1 has photovoltaic panels

deployed on-site, while DCNAME2 has wind turbines. DCNAME3 is located in CITYNAME3

has no renewable energy generation deployed on site. All three data centres a registered as

participants to the IT Load Marketplace.

Narrative Today is a sunny day in CITYNAME1; thus, a lot of solar energy is available at DCNAME1. In

consequence, on the basis of the bilateral agreement between DCNAME1 and DCNAME2, it

is decided to temporary shift some non-critical load from DCNAME2 and to migrate to

DCNAME1. As result the energy demand of DCNAME1 is increased being able to exploit the

solar energy peak.

As the performance of the services/applications associated to the workload relocated in

DCNAME1 may get worse for some customers, DCNAME2 has to renegotiate and decrease

their contracted Service Level Agreements (SLAs) for limited period of time.

For the afternoon weather forecasts show the wind will start to blow hard in CITYNAME2,

thus there is a peak of wind energy production. To exploit renewable energy generation to

the extent possible, some workload will be relocated back from DCNAME1 to DCNAME2. As

it can serve more IT load, DCNAME2 uses the IT Load Marketplace to place a bid in the



35

current market session for workload to be relocated so it can match the wind energy

production peak. DCNAME3 has available some load to be temporary relocated so it answers

to the DCNAME2 bid with a workload relocation offer. At the end of the session the bid and

offers are matched and the workload from DCNAME3 will be relocated to DCNAME2.

DCNAME3 will be rewarded considering the calculated market session clearing price while

DCNAME2 will decrease its CO2 footprint as results of using as much as possible wind energy

when available.

Diagram(s)

Scenario 4: Single DC Providing both Electrical Energy Flexibility and Heat

Objective

Optimize the DC operation to deliver both electrical energy flexibility services and heat to the

surrounding energy (power and heat) grids ecosystems. The DC will act as convertor between

electrical and thermal energy and vice versa to gain extra revenue on top of normal operation.

Actor(s) DC Operator, Energy and Flexibility Marketplace Operators, Heat/Cold Marketplace Operator,

Distribution System Operator, Heat Grid Operator, Flexibility Aggregator, Heat/Cold Broker

Backgroun

d

All the background assumptions from scenarios 1 and 2 are kept but this time the DC may

interact (through the corresponding aggregator when it is the case) with all three marketplaces

for: delivering flexibility services (on Flexibility Marketplace), providing heat (on Heat/Cold

Marketplace) and buying / selling electrical energy (on Energy Marketplace). In doing so it may

be the case that it has to deal with potential conflicting / complementary objectives in relation

with electricity, flexibility and heat trading to increase the overall revenue or to decrease the

environmental impact.

Narrative It is forecast to be a cold but sunny day in CITYNAME thus an increased amount of solar energy

will be produced and need to be consumed. To avoid a congestion point in the local grid level

previously declared in the Common Reference, the DSONAME publish a request for flexibility in

the Local Flexibility Marketplace. AGGREGATORNAME and other flexibility aggregators become

active and send their flexibility offers using the marketplace but finally the one of

AGGREGATORNAME is accepted by DSONAME. During the day AGGREGATORNAME sends a

flexibility order to DCNAME (enrolled with the AGGREGATORNAME) to increase its load profile

during the renewable energy production peak.

DCNAME will leverage on its internal sources of energy flexibility delivering the desired levels of

flexibility in terms of an increased energy demand being paid by AGGREGATORNAME

accordingly to the agreed flexibility contract. Thus, DCNAME schedules the execution of some

delay tolerant workload to the time interval when the renewable energy peak is forecasted.



36

Being a cold day there is an increase of thermal energy demand in the local grid thus

HEATBROKER name publish high price bids for heat in the Heat/Cold Marketplace. DCNAME

see this as a potential complementary source of extra revenues and since it has already

increased its electrical energy demand by scheduling the execution of more load for a time

interval it places offers of heat in the Heat/Cold Marketplace. Using the market mechanism,

the clearing price at which all accepted bids and offers are remunerated is determined and

DCNAME will make available the increased amount of heat in the local thermal grid through its

heat pumps.

Diagram(s)

Scenario 5: Workload Federated DCs Providing Electrical Energy Flexibility

Objective

Exploit migration of traceable ICT-load between federated DCs to deliver energy flexibility

services to the surrounding power grids ecosystems aiming to increase DC income for trading

flexibility.

Actor(s) DC Operators, Energy and Flexibility Marketplace Operators, IT Load Marketplace Operator,

Distribution System Operator (Electricity)

Backgroun

d

All the background assumptions from Scenario 1 and 3 are kept but this time the DCs use the

workload relocation as an additional source of electrical energy flexibility. As result the DCs will

have an increased amount of energy flexibility to offer in their local smart power grid thus

gaining more incentives.

NETWORKEDCSNAME is a Networked Cloud provider, owning DCNAME1 located in CITYNAME1

and DCNAME2 located in CITYNAME2. DCNAME1 has a collaboration agreement with

AGGREGATORNAME1 to offer is energy flexibility.

Narrative Weather forecasts announce that today, Sunday, will be a rainy and cold day in CITYNAME1,

with a consequent decrease in renewable energy supply and greater use of air heaters. The

local distribution system operator DSONAME foresees a congestion point four hours ahead

during lunch time and places a request for flexibility in the Flexibility Marketplace (i.e. a

decrease in energy demand for a specific time interval in intra – day). AGGREGATORNAME1

and other aggregators from the congested area respond with offers of flexibility in the Flexibility

Marketplace. DSAONAME selects the flexibility offer of AGGREGATORNAME1 which at its turn

send a flexibility order to all enrolled prosumers including DCNAME1.



37

By leveraging on its internal source of energy flexibility DCNAME1 estimates that it will not

manage to meet the AGGREGATORNAME1 demand for decreasing energy consumption. Thus,

in order to follow the profile expected by the AGGREGATORNAME1 and get contractual revenue

it decides to schedule the relocation of some of its delay tolerant loads to DCNAME2 during

flexibility event time interval.

At the same time in CITYNAME2 due to weather conditions there is a high availability of

renewable energy which makes the energy prices in the Local Energy Marketplace to drop.

DCNAME2 see this as an opportunity and since it already demands more energy to

accommodate the workload relocated from DCNAME1 is leverages on Local Energy

Marketplace to buy cheap energy when available.

Diagram(s)

Scenario 6: Workload Federated DCs Providing Heat

Objective Exploit migration of traceable ICT-load between federated DCs to deliver heat to their local

heat grids aiming to increase the revenue for the reuse of their residual heat.

Actor(s) DC Operator, Heat/Cold Broker, Heat/Cold Marketplace Operator, Heat Grid Operator

Background All the background assumptions from Scenario 2 and 3 are kept but this time the DCs use

the workload relocation as an additional source of thermal flexibility for increasing the

amount and/or quality of heat delivered to the heat grid. As a result, the DCs will have an

additional degree of freedom to accommodate for the needs of their local heat grid and

profit from their participation to their local Heat/Cold Marketplace.

Narrative CITYNAME1 experiences a series of especially cold days with low temperatures thus the

needs for building space heating are high, stressing the current capacity of the local heat

grids. On such the local heat grid where DCNAME1 operates and delivers heat, the Heat

Grid Operator sends a request for heat to HEATBROKER1 with which it has a contractual

agreement for heat delivery. In response the HEATBROKER1 submits a bid to the local

Heat/Cold Marketplace so as to cover the missing amounts for the coming day without

having to operate the back-up fossil fuels or gas production units. DCNAME1, with the



38

support of the CATALYST framework, can respond to the offer by increasing the amount of

heat generated, recovered and delivered to the heat grid. DCNAME1 responds with an offer

in the Heat/Cold Marketplace for the amount that is able to cover. HEATBROKER1 will

ensure that the full amount is supplied capitalizing on its entire portfolio of local heat

producers.

DCNAME1 places a bid in the IT Load Marketplace for additional workload to be relocated

and executed so it may generate more heat. DCNAME1 requests for additional IT load to

match the increased heat demand on their side, since the cost benefit for such an exchange

(buy extra data to sell extra heat) is substantial. DCNAME3 located at CITYNAME3 has

workload to be relocated and place its offer. DCNAME3 in turn, also with the support of the

CATALYST framework, responds to the offer by migrating the necessary load, after also

obtaining the approval from the end-users associated to the IT loads, since SLAs will be

invariably affected (network latency).

In addition, DCNAME3 decides to reduce temporarily the amount of heat delivered to their

own local grid since the CATALYST framework has indicated that the gain from selling the IT

load is higher than the one coming from selling the heat locally, assuming no penalty is

enacted in this case. In any case, the Heat/Cold Broker from CITYNAME3 guarantees the

heat supply to the local heat grid by capitalizing on the other heat producers from its

portfolio.

Diagram(s)

Scenario 7: Workload Federated DCs Providing Both Thermal and Electrical Energy Flexibility

Objective Exploit migration of traceable ICT-load between federated DCs to deliver: (i) heat to the

surrounding thermal grids and (ii) energy flexibility to the surrounding power grids.

Actor(s) DC Operator, Prosumer, Energy Aggregator, Distribution System Operator, Heat Grid Operator

Backgroun

d

All the background assumptions from Scenario 5 and 6 are kept but this time the DCs use the

workload relocation to increase the share of both electrical energy flexibility and heat which

may be delivered alternatively.

DCNAME1 is located in CITYNAME1 and is partially powered by onsite PV panels. DCNAME2 is

located in CITYNAME2 and supports renewable energy generation via wind turbines. DCNAME3

is also located in CITYNAME1 and has no RES on site. The three DCs participate to and



39

exchange IT Load via the IT Workload Marketplace and all of them have connections to

electrical energy and flexibility aggregators allowing them to offer their flexibility and buy/sell

electricity. At the same time, they are able to trade heat with Heat/Cold Brokers via local

Heat/Cold Marketplace.

Narrative It is a sunny day in CITYNAME1, which leads to increase on site energy generation in DCNAME1.

DCNAME1 uses the green energy for energy-heavy operations, such as IT cooling, while it

prefers to execute now both delay-tolerant and time-critical loads. DCNAME1 may benefit from

excess energy via selling energy in the Energy Marketplace, to an energy aggregator

(AGGREGATORNAME2) or other prosumers. Also it may accept IT loads to be relocate from other

DCs by participating to the IT Load Marketplace. But there are low energy prices in the Energy

Marketplace thus DCNAME1 prefers to participate in the IT Load Marketplace.

As there is low green energy generation in CITYNAME2, DCNAME2 finds using the IT Load

Marketplace that it is beneficial to offload some non-critical tasks to DCNAME1. Also, DCNAME2

has already chosen to use free-air or water cooling to avoid energy-consuming electrical cooling

for executing critical IT loads. Both DCNAME1 and DCNAME2 negotiate SLAs for the load under

relocation, if there is such a need.

At the same time, DSONAME1 forecast that the increased energy generation in CITYNAME1 will

result in unbalances between production and consumption at local grid level which will be

addressed by the flexibility aggregator AGGREGATORNAME1. Since DCNAME1 is heavily using

both energy and IT resources, it cannot offer its energy flexibility to AGGREGATORNAME1. On

the other hand, DCNAME3 being also located in CITYNAME1 has already bought energy at low

prices in the Energy Marketplace (from AGGREGATORNAME2), and it still has computing

resources not running workload. So, DCNAME3 can combine a flexibility offer (i.e. increase

energy demand to cover RES peak) to the AGGREGATORNAME1 with an offer in the IT Load

Marketplace for buying workload to relocate. So, DCNAME3, although it has no onsite RES, it

still gains cost benefits from increased green energy generation to cover existing operations

and undertake remote loads.

Also, the increased IT load execution resulted in increased heat generation at the IT

infrastructures. Both DCNAME1 and DCNAME3 activated any heat reuse operations available,

such as offices’ heating and preheating dynamic rotating UPS systems or diesel engines, if

possible. Moreover, they both provided excess heat to a Heat/Cold Broker for domestic heating

through the Heat/Cold Marketplace. Although heat is sold now at low prices, it is still an

additional source of revenue.

Similar is the situation during windy days in CITYNAME2, as it will result in increased green

energy generation in DCNAME2.



40

Diagram(s)



41

5. CATALYST Use Cases

A Use Case describes the interaction between an actor and system to achieve a certain goal using a

list of actions or event steps. Use Cases are used to inform business analyst and developers on the

logical steps that need to be considered during the development cycle6.

As seen in the previous section, scenarios are mainly stories that do not reflect the system's activities

(except as experienced by the actors) and are technology agnostic as much as possible. On the other

hand, the Use Cases are more focused on functionality and can take into consideration both the actors

and the technology. Thus, in the following sub-sections we have defined the main identified CATALYST

use-cases grouped onto individual scenarios.

Within CATALYST, use cases are used for clarifying concepts implemented in the project, deriving

functional and non-functional requirements, and providing the scope for test cases that will be later

used to validate the CATALYST framework. Table 3 shows the template used within the CATALYST

project to describe the elements of the use case required to understand its definition. This includes

the storyline, goals, actors, components, conditions and trigger events.

Table 3 - CATALYST use case template

Use Case <S#.#>: <Use Case Name (best use a verb of action)>

Brief Description <A brief description of the use case, no longer than a small paragraph; preferably keep

it one clear goal per use case>

Parent Scenario <Scenario number>

Actor(s) <All users interacting with the CATALYST System; preferably identified by role name>

Priority

<Depending on how many use cases we end up with we may need to prioritize them

based on importance to meeting the project’s objective: high (must do) | medium

(should do, time permitted) | low (nice to do, but most likely not)>

Trigger <Concrete actions by users interacting with the CATALYST System to initiate use case>

Pre-conditions <System State prior to launching the use case >

Post-conditions <System State expected after the use case has been completed >

Basic Flow <Describe the basic flow of events during use case

Step 1.

Step 2.

… Step N. >

Alternate Flow(s) <If applicable, provide the steps of less common user/system interactions>

Exception Flow(s) < Anything that may happen that would prevent the user from achieving their goal >

6 http://en.wikipedia.org/wiki/User-centered_design

http://en.wikipedia.org/wiki/User-centered_design



42

In the next sub sections, the use cases derived are grouped according to the CATALYST main

functionality macro tier they are referring: DC optimization engine, integration with energy networks

and federated DCs integration.

DC Optimization Engine

The following use cases have been defined considering how the DC Operator actor interacts with the

DC Optimization Engine to decide on the optimal exploitation of electricity (including flexibility), heat

and IT load as commodities.

Use Case S1.1: Configure multi-objective optimization strategy

Brief Description

The DC Operator configures the multi-objective optimization strategy adopted by the

CATALYST system by assigning different weights for trading DC electricity (including

flexibility), heat, IT Load or a combination of the aforementioned.

Parent Scenario Scenarios 4 ,5, 6, 7

Actor(s) DC Operator

Priority high (must do)

Trigger The DC Operator launches the graphical user interface of CATALYST system

optimization engine

Pre-conditions The CATALYST system is deployed and operational

Post-conditions The multi-objective strategy is configured and selected

Basic Flow Step 1: DC Operator launches graphical user interface of CATALYST system

optimization engine

Step 2: DC Operator assigns specific weights to each of the sub objectives related to

DC electricity (including flexibility), heat and IT Load

Step 3: The system stores the configured optimization strategy for future use;

Alternate Flow(s) Not applicable

Exception Flow(s) Not applicable

Use Case S1.2: Select single or multi-objective optimization strategy

Brief Description The DC Operator selects the optimization strategy to be used by the CATALYST system

in the optimization process

Parent Scenario Scenarios 1,2,3,4,5,6,7



Trigger The DC Operator launches the graphical user interface of the CATALYST system

optimization engine

Pre-conditions The CATALYST system is deployed and operational

Post-conditions The optimization strategy to be used by the optimization engine is selected



43

Basic Flow Step 1: The DC Operator launches the graphical user interface of the CATALYST system

optimization engine;

Step 2: The DC Operator selects the optimization strategy to be used;

Step 3: The selected strategy is used by the optimization engine in its calculations

Step4: An optimization action plan is generated



Use Case S1.3: View / Validate optimization plan

Brief Description

As result of the running the optimization processes with the strategy selected the

CATALYST system generates an optimization action plan which is displayed to the DC

Operator. DC Operator can view it in detail and can validate its execution. If the

optimization action plan is validated, its execution is carried out.

Parent Scenario Scenarios 1,2,3,4,5,6,7



Trigger An optimisation strategy has been selected and the optimisation plan generated

Pre-conditions The optimization action plan is generated and already saved

Post-conditions The optimization action plan is valid and its execution is launched

Basic Flow Step 1: The DC Operator launches the graphical user interface of the CATALYST system

optimization engine;

Step 2: The optimization action plan generated by the system is loaded in the

graphical user interface;

Step 3: The DC Operator may check it in detail action by action;

Step 4: The DC Operator validates the optimization action plan

Step 5: Each optimization action of the optimization plan is picked up for execution by

specific actuating components of the CATALYST system

Alternate Flow(s) Step 4: The DC Operator does not validate the optimization plan and its status is not

updated thus it will not be executed


Use Case S1.4: View DC forecasted total energy flexibility availability

Brief Description

The DC wants to have a new revenue stream out of trading its electrical energy

flexibility to a flexibility aggregator. In response to a flexibility aggregator request the

DC Operator uses the CATALYST system to forecast the energy flexibility the DC may

offer for day ahead or intraday.

Parent Scenario Scenario 1, 4, 5, 7





44

Trigger A flexibility request is received by the DC from a Flexibility Aggregator and the DC

Operator wants to assess the DC electrical energy flexibility the DC may provide

Pre-conditions The CATALYST system has been deployed and is operational. A flexibility request is

received from Flexibility Aggregator

Post-conditions The DC energy flexibility availability for specific time window is calculated

Basic Flow Step 1: The DC Operator launches the CATALYST system forecasting graphical user

interface

Step 2: The DC Operator selects the time window to forecast the DC energy flexibility

availability (day ahead or intraday)

Step 3: The CATALYST system uses the DC components characteristics and flexibility

models;

Step 4: The prediction algorithms are run considering also historical electrical energy

flexibility data stored by the system;

Step 5: Energy flexibility values forecasted are displayed to the DC Operator



Use Case S1.5: View current and forecasted DC electrical demand / production

Brief Description The DC Operator wants to assess the current and forecasted DC energy budget

(demand vs production)




Trigger The DC Operator turns on the CATALYST system forecasting graphical user interface

Pre-conditions The CATALYST system is deployed and operational, historical energy data are available

Post-conditions Availability of current and forecasted DC energy budget values


interface;

Step 2: The DC Operator selects the time window to forecast the DC energy demand

and production

Step 3: The CATALYST system gets DC components characteristics as well as current

and historical energy consumption and production data;

Step 4: The CATALYST system prediction algorithms are executed;

Step 5: Current and forecasted energy budget values are displayed to the DC Operator.



Use Case S1.6: View min, max energy flexibility per individual DC components

Brief Description The DC Operator wants to assess the flexibility values of individual DC component.

They might be then aggregated to determine the total DC energy flexibility availability



45




Trigger The DC Operator assesses the electrical energy flexibility of individual DC components

Pre-conditions Flexibility models of individual components available as well as their characteristics

Post-conditions The electrical energy flexibility of individual DC components are available


interface

Step 2: The DC Operator selects the individual components for assessing flexibility

values

Step 3: The CATALYST system gets DC components characteristics and flexibility

models;

Step 4: The CATALYST system runs the assessment mathematical formalism for

determining individual levels of flexibility;

Step 5: The system displays the results to the DC Operator and stored to be used in

the optimization process



Use Case S1.7: View current and forecasted DC thermal budget

Brief Description

The DC Operator wants to assess the thermal (heat/cold) budget of the DC to be able

to place bids on the Heat/Cold Marketplace or to respond to requests coming from

Heat/Cold Brokers

Parent Scenario Scenario 2,4,6,7



Trigger The DC Operator assesses the current and forecasted amounts of heat/cold which

can be reused in nearby neighbourhoods

Pre-conditions Thermal models of individual components available as well as their characteristics

Post-conditions The DC current and forecasted thermal budget is available


interface;

Step 2: The DC Operator selects the time window to forecast the DC available heat /

cold

Step 3: The CATALYST system uses DC components characteristics as well as current

and historical thermal energy data

Step 4: CATALYST system runs prediction algorithms;

Step 5: Current and forecasted thermal budget values are displayed to the DC

Operator.





46

Use Case S1.8: Set the threshold of DC KPIs of interest

Brief Description The DC Operator sets the threshold values for target DC KPIs and views their actual

values

Parent Scenario All scenarios



Trigger Define the DC metrics target values or view their actual values

Pre-conditions System is deployed and operational

Post-conditions The target values for DC metrics is set

Basic Flow Step 1: The DC Operator launches the CATALYST system graphical user interface;

Step 2: The DC Operator selects the metrics and KPIs tab;

Step 3: The DC Operator can select the interested metrics and KPIs to be calculated;

Step4: The DC Operator defines the threshold values for the selected metrics and KPIs



Use Case S1.9: Display the actual values of metrics and KPIs

Brief Description The DC Operator set the threshold values for target KPIs of DC and can also to view

check their values

Parent Scenario All scenarios



Trigger Define the DC metrics target values or view their actual values

Pre-conditions System is deployed and operational

Post-conditions The target values for DC metrics is set

Basic Flow Step 1: DC Operator launches the CATALYST system graphical user interface;

Step 2: DC Operator selects the metrics and KPIs tab;

Step 3: the system calculates the actual values for selected metrics and KPIs

Step 4: DC Operator check metrics and KPIs calculated values.



Use Case S1.10: Select workload to be offered in the IT Load Marketplace

Brief Description The DC Operator can check and validate the workload that can be offered for

relocation in the IT Load Marketplace



47




Trigger The DC operators want to trade IT workload in the IT Load Marketplace

Pre-conditions The CATALYST System is deployed and operational

Post-conditions The workload to be relocated is validated

Basic Flow Step1: The DC Operator launches the CATALYST system graphical user interface;

Step 2: The CATALYST system displays the list of workload which may be relocated in

other DCs;

Step 3: The DC Operator validates the list;

Step 4: The CATALYST system save the list to be used in creating IT Load marketplace

bid.

Alternate Flow(s) Step 4: DC Operator does not validate the workload list thus it will not be available for

relocation in other DCs


Use Case S1.11: Configure thresholds for SLA re-negotiation

Brief Description The DC Operator can set the threshold limits for SLA re-negotiation




Trigger The DC operator selects an optimization plan requiring to temporarily increase or

decrease the provided QoS characteristics to a set of virtual load, in a controllable, a

priori contractually defined and mutually agreed manner.

Pre-conditions The current SLA status of the users is properly monitored and known to the DC

operator.

Post-conditions The new SLA thresholds fall under the mutually agreed and a priori defined set of SLA

thresholds.

Basic Flow Step 1: The optimization engine stores an optimization plan according to which a set

of VMs should be treated in a way that their SLAs will be decreased (e.g. they should

be relocated to another DC, increasing their down time).

Step2: The DC operator selects this plan to be applied for DC optimization purposes.

Step3: The system sets the new threshold values.

Alternate Flow(s) Step1: The DC Operator manually requires a SLA (re)negotiation for a set of virtual

load, indicating the

Step 1: The SLA (re)negotiation checks the new threshold values are following the

contractually available options.

Exception Flow(s) The selected virtual load is managed by a non-negotiable SLA contract.

Use Case S1.12: Validate new SLA values



48

Brief Description The DC Operator can validate the new SLA values obtained after re-negotiation




Trigger The DC operator requires for billing purposes the achieved SLA at the end of the billing

period.

Pre-conditions The system is operational throughout the whole billing period.

Post-conditions The SLA (re)negotiated is available

Basic Flow Step 1: The DC operator asks the system to get the achieved SLA during this billing

period.

Step 2: The system calculates and provides the achieved SLA.

Alternate Flow(s) Step 1: The billing system get the achieved SLA.

The rest of the steps should follow the basic flow


Energy Networks Interface and Energy Marketplaces

Use Case S2.1: Define Day-Ahead/Intraday Flexibility Marketplace session

Brief Description

The Flexibility Marketplace Operator defines timeframes during which an offer can be

placed and be valid, referred to hereafter as market sessions. Market sessions can

be day-ahead/intraday and refers to a specific flexibility delivery time period. While a

market session is running, the flexibility providers can place offers.

Parent Scenario 1, 4, 5, 7

Actor(s) Flexibility Marketplace Operator

Priority High (must do)

Trigger On demand.

Pre-conditions The system is installed and active. The Flexibility Marketplace Operator has a login

account.

Post-conditions Market sessions are scheduled

Basic Flow Step 1: The Flexibility Marketplace Operator logs into the system;

Step 2: The Flexibility Marketplace Operator schedules the market sessions;

Step 3: The Flexibility Marketplace Operator exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.2: Request a Flexibility Marketplace account

Brief Description In order to participate to the Flexibility Marketplace, the Flexibility Aggregator/DSO has

to be a registered user. Thus, the Flexibility Aggregator/DSO requests an account.




49

Actor(s) Flexibility Aggregator, DSO


Trigger On demand. An aggregator wishes to have an account so as to participante in sessions

Pre-conditions The system is installed and active.

Post-conditions The Flexibility Aggregator/DSO requested an account for actively participating in the

Flexibility Marketplace.

Basic Flow Step 1: The Flexibility Aggregator/DSO accesses the system and requests an account;

Step 2: The Flexibility Aggregator/DSO provides the profile information requested by

the system;

Step 3: The system sends a notification to the Flexibility Marketplace Operator;

Step 4: The Flexibility Aggregator/DSO exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.3: Cancel a Flexibility Marketplace account

Brief Description The Flexibility Aggregator/DSO decides to cancel their registration to the Flexibility

Marketplace.




Trigger On demand.

Pre-conditions The system is installed and active and the Flexibility Aggregator/DSO has already an

account.

Post-conditions The Flexibility Aggregator/DSO cancelled the registration to the marketplace.

Basic Flow Step 1: The Flexibility Aggregator/DSO accesses the system;

Step 2: The Flexibility Aggregator/DSO requests the cancellation of their account;


Alternate Flow(s)

Exception Flow(s)

Use Case S2.4: View/Update Flexibility Marketplace participant profile

Brief Description The Flexibility Aggregator/DSO wants to view or update their profile registered in the



Actor(s) Flexibility Aggregator, DSO, Flexibility Marketplace Operator


Trigger On demand.



50


account for accessing the Flexibility Marketplace.

Post-conditions The Flexibility Aggregator/DSO viewed/updated their profile.

Basic Flow Step 1: The Flexibility Aggregator/DSO accesses the system with their account;

Step 2: The Flexibility Aggregator/DSO views/updates their profile;

Step 3: The system sends a notification to the Flexibility Marketplace Operator.


Alternate Flow(s)

Exception Flow(s)

Use Case S2.5: Validate new/updated Flexibility Marketplace participant profile

Brief Description The Flexibility Marketplace Operator approves or rejects requests for account made

by the Flexibility Aggregator/DSO.


Actor(s) Flexibility Marketplace Operator, Flexibility Aggregator, DSO

Priority

Trigger The system notifies the Flexibility Marketplace Operator that a Flexibility

Aggregator/DSO profile has been registered/updated


Post-conditions The Flexibility Aggregator/DSO has got a login account and can actively participate in

the Flexibility Marketplace.

Basic Flow Step 1: The Flexibility Marketplace Operator accesses the system;

Step 2: The Flexibility Marketplace Operator validates the Flexibility Aggregator/DSO

profile;

Step 3: The system informs the Flexibility Aggregator/DSO about the validation result;

Step 4: The Flexibility Marketplace Operator exits the system.

Alternate Flow(s) Step 2.a: The Flexibility Marketplace Operator rejects the account request.

Exception Flow(s)

Use Case S2.6: View history of participation in the Flexibility Marketplace

Brief Description The Flexibility Aggregator/DSO wants to view the history of their participation to the





Trigger On demand.


account for accessing the Flexibility Marketplace.

Post-conditions The Flexibility Aggregator/DSO viewed their history.



51

Basic Flow Step 1: The Flexibility Aggregator/DSO accesses the system with their account;

Step 2: The Flexibility Aggregator/DSO accesses their history information;


Alternate Flow(s)

Exception Flow(s)

Use Case S2.7: Place offer in the Flexibility Marketplace (day ahead, intra-day)

Brief Description While a market session is running, the Flexibility Aggregator offers their flexibility.


Actor(s) Flexibility Aggregator


Trigger A market session is active.

Pre-conditions The system is installed and active. The Flexibility Aggregator has a login account for

accessing the Flexibility Marketplace.

Post-conditions The Flexibility Aggregator has posted an offer.

Basic Flow Step 1: The Flexibility Aggregator logs into the system and accesses the market

session;

Step 2: The Flexibility Aggregator posts an offer;

Step 3: The system validates the offer;

Step 4: The Flexibility Aggregator exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.8: Select an electricity flexibility offer from the Flexibility Marketplace (day ahead, intra-day)

Brief Description At the end of the market session the DSO accesses the system and selects offers most

fitting their needs.


Actor(s) DSO , Flexibility Aggregator


Trigger

Pre-conditions A market session ended.

Post-conditions The system is installed and active. The DSO has a login account.

Basic Flow The DSO selected the flexibility offers.

Alternate Flow(s) Step 1: The DSO logs into the system and accesses the offers posted in a specific

market session;

Step 2: The DSO select offers;



52

Step 3: The DSO exits the system.

Exception Flow(s)

Use Case S2.9: Access Flexibility Marketplace session results

Brief Description The market session results are made available to the market participants.


Actor(s) DC Operator/Heat Broker/Other prosumer


Trigger A market session is closed.

Pre-conditions The system is installed and active. The Flexibility Aggregator has a login account.

Post-conditions Market participants are informed about market session result.

Basic Flow Step 2: The Flexibility Aggregator accesses the system;

Step 2: The Flexibility Aggregator visualises market session results;

Step 3: The Flexibility Aggregator exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.10: Receive electricity flexibility request from Flexibility Aggregator

Brief Description

The Flexibility Aggregator decides to participate to the Flexibility Marketplace since

active at a congestion point declared by the DSO. Thus, the Flexibility Aggregator

requests flexibility to their prosumer, one of which is a DC.




Trigger On demand


Post-conditions

Basic Flow Step 1: The system receives a flexibility request from the Flexibility Aggregator;

Step 2: The system notifies the request to the DC Operator;

Alternate Flow(s)

Exception Flow(s)

Use Case S2.11: Define Day-Ahead/Intraday Heat/Cold Marketplace session

Brief Description The Heat/Cold Marketplace Operator defines timeframes during which bids/offer can

be placed and be valid, referred to hereafter as market sessions. Market sessions can



53

be day-ahead/intraday and refers to a specific heat/cold delivery time period. While a

market session is running, the heat/cold buyers/sellers can place bids/offers.


Actor(s) Heat/Cold Marketplace Operator


Trigger On demand.

Pre-conditions The system is installed and active. The Heat/Cold Marketplace Operator has a login

account.

Post-conditions Market sessions are scheduled.

Basic Flow Step 1: The Heat/Cold Marketplace Operator logs into the system;

Step 2: The Heat/Cold Marketplace Operator schedules the market sessions;

Step 3: The Heat/Cold Marketplace Operator exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.12: Request a Heat/Cold Marketplace account

Brief Description

In order to participate to the Heat/Cold Marketplace, the Heat Broker/DC Operator/

Other Prosumer has to be a registered user. Thus, the Heat Broker/ DC Operator/

Other Prosumer has to register to the Heat/Cold Marketplace in order to obtain an

account.


Actor(s) Heat Broker/DC Operator/Other Prosumer, Heat/Cold Marketplace Operator

Priority

Trigger On demand.


Post-conditions The Heat Broker/DC Operator/Other Prosumer requested an account for actively

participating in the Heat/Cold Marketplace.

Basic Flow Step 1: The Heat Broker/DC Operator/Other Prosumer accesses the system and

requests an account;

Step 2: The Heat Broker/DC Operator/Other Prosumer provides the profile information

requested by the system;

Step 3: The system sends a notification to the Heat/Cold Marketplace Operator;

Step 4: The Heat Broker/DC Operator/Other Prosumer exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.13: Cancel a Heat/Cold Marketplace account

Brief Description The Heat Broker/DC Operator/Other Prosumer decides to cancel their registration to

the Flexibility Marketplace.



54


Actor(s) Heat Broker/DC Operator/Other Prosumer


Trigger On demand.

Pre-conditions The system is installed and active and the Heat Broker/DC Operator/Other Prosumer

has already an account.

Post-conditions The Heat Broker/DC Operator/Other Prosumer cancelled the registration to the

marketplace.

Basic Flow Step 1: The Heat Broker/DC Operator/Other Prosumer accesses the system;

Step 2: The Heat Broker/DC Operator/Other Prosumer requests the cancellation of

their account;


Alternate Flow(s)

Exception Flow(s)

Use Case S2.14: View/Update Heat/Cold Marketplace participant profile

Brief Description The Heat Broker/DC Operator/Other Prosumer wants to view/update their profile.




Trigger On demand.

Pre-conditions The system is installed and active. The Heat Broker/DC Operator/Other Prosumer has

already an account.

Post-conditions The Heat Broker/DC Operator/Other Prosumer vied/updated the profile.

Basic Flow Step 1: The Heat Broker/DC Operator/Other Prosumer accesses the system with their

account;

Step 2: The Heat Broker/DC Operator/Other Prosumer views/updates their profile;

Step 3: The system sends a notification to the Flexibility Marketplace Operator;


Alternate Flow(s)

Exception Flow(s)

Use Case S2.15: Validate new/updated Heat/Cold Marketplace participant profile

Brief Description The Heat/Cold Marketplace Operator approves or rejects requests for account made

by a Heat Broker/DC Operator/Other Prosumer.


Actor(s) Heat/Cold Marketplace Operator



55


Trigger The system notifies the Heat/Cold Marketplace Operator that a Heat Broker/DC

Operator/Other Prosumer profile has been registered/updated


Post-conditions The Heat Broker/DC Operator/Other Prosumer has got a login account and can

actively participate in the Heat/Cold Marketplace.

Basic Flow Step 1: The Heat/Cold Marketplace Operator accesses the system;

Step 2: The Heat/Cold Marketplace Operator validates the profile;

Step 3: The system informs the Heat Broker/DC Operator/Other Prosumer about the

validation result;

Step 4: The Heat/Cold Marketplace Operator exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.16: View history of participation in the Heat/Cold Marketplace

Brief Description The Heat Broker/DC Operator/Other Prosumer wants to view the history of their

participation to the Heat/Cold Marketplace.




Trigger On demand.

Pre-conditions The system is installed and active and the Heat Broker/DC Operator/Other Prosumer

has already an account for accessing the Heat/Cold Marketplace.

Post-conditions The Heat Broker/DC Operator/Other Prosumer viewed their history.

Basic Flow Step 1: The Heat Broker/DC Operator/Other Prosumer accesses the system with their

account;

Step 2: The Heat Broker/DC Operator/Other Prosumer accesses their history

information;


Alternate Flow(s)

Exception Flow(s)

Use Case S2.17: Place bid/offer in the Heat/Cold Marketplace (day ahead, intra-day)

Brief Description While a market session is running, the DC Operator/the Heat Broker/Other Prosumer

place bids/offers into the marketplace.






56


Pre-conditions The system is installed and active. The DC Operator/the Heat Broker/Other prosumer

has a login account.

Post-conditions An offer/bid for heat/cold was placed.

Basic Flow Step 1: The DC Operator/the Heat Broker/Other Prosumer logs into the system;

Step 2: The DC Operator/the Heat Broker/Other Prosumer places an offer/bid;

Step 3: The DC Operator/the Heat Broker/Other Prosumer exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.18: Access Heat/Cold Marketplace session results

Brief Description

At the end of the session, the market is cleared: all valid supply offers are put in

increasing price order on an aggregate supply curve and all valid demand bids are put

in decreasing price order on an aggregate demand curve. The intersection of the two

curves determines the market equilibrium, which gives the clearing price, at which all

accepted bids and offers are remunerated, and the overall quantity of energy traded

in the session. The market session results are made available to the market

participants.





Pre-conditions The system is installed and active. The DC Operator/the Heat Broker/Other prosumer

has a login account.


Basic Flow Step 1: The system clears the market;

Step 2: The DC Operator/the Heat Broker/Other Prosumer accesses the system;

Step 3: The DC Operator/the Heat Broker/Other Prosumer visualises market session

results;

Step 4: The DC Operator/the Heat Broker/Other Prosumer exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.19: Define Day-Ahead/Intraday Electricity Marketplace session

Brief Description

The Electricity Marketplace Operator defines timeframes during which bids/offer can

be placed and be valid, referred to hereafter as market sessions. Market sessions can

be day-ahead/intraday and refers to a specific electricity delivery time period. While a

market session is running, the electricity buyers/sellers can place bids/offers.


Actor(s) Electricity Marketplace Operator



57


Trigger On demand.

Pre-conditions The system is installed and active. The Electricity Marketplace Operator has a login

account.

Post-conditions Market sessions are scheduled.

Basic Flow Step 1: The Electricity Marketplace Operator logs into the system;

Step 2: The Electricity Marketplace Operator schedules the market sessions;

Step 3: The Electricity Marketplace Operator exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.20: Request an Electricity Marketplace account

Brief Description

In order to participate to the Electricity Marketplace, the DC Operator Other Prosumer

has to be a registered user. Thus, the DC Operator/Other Prosumer has to register to

the Electricity Marketplace in order to obtain an account.

Parent Scenario 1, 5, 7

Actor(s) DC Operator/Other Prosumer, Electricity Marketplace Operator


Trigger On demand.


Post-conditions The DC Operator/Other Prosumer requested an account for actively participating in

the Electricity Marketplace.

Basic Flow Step 1: The DC Operator/Other Prosumer accesses the system and requests an

account;

Step 2: The DC Operator/Other Prosumer provides the profile information requested

by the system;

Step 3: The system sends a notification to the Electricity Marketplace Operator;

Step 4: The DC Operator/Other Prosumer exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.21: Cancel an Electricity Marketplace account

Brief Description The DC Operator/Other Prosumer decides to cancel their registration to the Electricity

Marketplace.


Actor(s) DC Operator/Other Prosumer

Priority

Trigger On demand.



58

Pre-conditions The system is installed and active and the DC Operator/Other Prosumer has already

an account.

Post-conditions The DC Operator/Other Prosumer cancelled the registration to the marketplace.

Basic Flow Step 1: The DC Operator/Other Prosumer accesses the system;

Step 2: The DC Operator/Other Prosumer requests the cancellation of their account;


Alternate Flow(s)

Exception Flow(s)

Use Case S2.22: View/Update Electricity Marketplace participant profile

Brief Description The DC Operator/Other Prosumer wants to view/update their profile.




Trigger On demand.

Pre-conditions The system is installed and active. The DC Operator/Other Prosumer has already an

account.

Post-conditions The DC Operator/Other Prosumer vied/updated the profile.

Basic Flow Step 1: The DC Operator/Other Prosumer accesses the system with their account;

Step 2: The DC Operator/Other Prosumer views/updates their profile;

Step 3: The system sends a notification to the Electricity Marketplace Operator;


Alternate Flow(s)

Exception Flow(s)

Use Case S2.23: Validate new/updated Electricity Marketplace participant profile

Brief Description The Electricity Marketplace Operator approves or rejects requests for account made

by a DC Operator/Other Prosumer.


Actor(s) Electricity Marketplace Operator


Trigger The system notifies the Electricity Marketplace Operator that a DC Operator/Other

Prosumer profile has been registered/updated


Post-conditions The DC Operator/Other Prosumer has got a login account and can actively participate

in the Electricity Marketplace.

Basic Flow Step 1: The Electricity Marketplace Operator accesses the system;

Step 2: The Electricity Marketplace Operator validates the profile;



59

Step 3: The system informs the DC Operator/Other Prosumer about the validation

result;

Step 4: The Electricity Marketplace Operator exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.24: View history of participation in the Electricity Marketplace

Brief Description The DC Operator/Other Prosumer wants to view the history of their participation to the

Electricity Marketplace.




Trigger On demand.

Pre-conditions The system is installed and active and the DC Operator/Other Prosumer has already

an account for accessing the Electricity Marketplace.

Post-conditions The DC Operator/Other Prosumer viewed their history.

Basic Flow Step 1: The DC Operator/Other Prosumer accesses the system with their account;

Step 2: The DC Operator/Other Prosumer accesses their history information;


Alternate Flow(s)

Exception Flow(s)

Use Case S2.25: Place offer in the Electricity Marketplace (day ahead, intra-day)

Brief Description While a market session is running, the DC Operator/ Other Prosumer place bids/offers

into the marketplace.


Actor(s) DC Operator/ Other prosumer



Pre-conditions The system is installed and active. The DC Operator/ Other prosumer has a login

account.

Post-conditions An offer/bid for electricity was placed. At the end of the session, the market is cleared:

all valid supply offers are put in increasing price order on an aggregate supply curve

and all valid demand bids are put in decreasing price order on an aggregate demand

curve. The intersection of the two curves determines the market equilibrium, which

gives the clearing price, at which all accepted bids and offers are remunerated, and

the overall quantity of energy traded in the session.

Basic Flow Step 1: The DC Operator/ Other Prosumer logs into the system;

Step 2: The DC Operator/ Other Prosumer places an offer/bid;



60

Step 3: The DC Operator/ Other Prosumer exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.26: Access Electricity Marketplace session results

Brief Description

At the end of the session, the market is cleared: all valid supply offers are put in

increasing price order on an aggregate supply curve and all valid demand bids are put

in decreasing price order on an aggregate demand curve. The intersection of the two

curves determines the market equilibrium, which gives the clearing price, at which all

accepted bids and offers are remunerated, and the overall quantity of energy traded

in the session. The market session results are made available to the market

participants.


Actor(s) DC Operator/ Other prosumer



Pre-conditions The system is installed and active. The DC Operator/ Other prosumer has a login

account.


Basic Flow Step 1: The system clears the market;

Step 2: The DC Operator/ Other Prosumer accesses the system;

Step 3: The DC Operator/ Other Prosumer visualises market session results;

Step 4: The DC Operator/ Other Prosumer exits the system.

Alternate Flow(s)

Exception Flow(s)

Use Case S2.27: Authorise DR request

Brief Description The DC Operator receives a notification of a DR event. The DC Operator can approve or

reject the DR request.




Trigger A DR event is notified to the DC Operator

Pre-conditions The system is installed and active

Post-conditions DR request approved and executed

Basic Flow Step 1: The system receives a DR event notification;

Step 2: The system notifies the DR request to the DC Operator;

Step 3: The DC Operator authorise the DR request;



61

Step 4: The system computes an optimization action plan to address to implement the

DR.

Alternate Flow(s) The DC Operator rejects the DR request

Exception Flow(s)

Federated DCs Integration and IT Load Marketplace

In this section we present the identified use cases in relation with the DC IT connection exploitation

for workload relocation in other partner DCs or through an IT Load Marketplace aiming to gain financial

benefits of to decrease the DCs carbon footprint by implementing “follow the (renewable) energy

optimization strategies.

Use Case S3.1: Register DC as participant in IT Load Marketplace

Brief Description The DC operator registers the DC in the IT Load Marketplace

Parent Scenario Scenario 3, 5, 7



Trigger The DC operator would like to join the CATALYST IT Load Marketplace

Pre-conditions The DC is configured to support the virtual containers technology of CATALYST and is

equipped with all necessary components CATALYST to operate in federated DC

environment.

Post-conditions The DC is registered into the IT Load Marketplace

Basic Flow Step 1: The DC operator accesses the registration page of the IT Load Marketplace,

fills in the necessary forms and accepts the terms of use;

Step 2: The DC operator receives a confirmation email from the IT Load Marketplace

with a confirmation link;

Step 3: The DC operator clicks on the link to confirm its registration intent.



Use Case S3.2: Place workload relocation bid in IT Load Marketplace

Brief Description The DC operator registers in the IT Load Marketplace their intent to offload a certain

set of computational resources.




Trigger The DC operator selects an optimization plan indicating that set of virtual load

containers (VCs) should be relocated for execution to another DC



62

Pre-conditions The DC is registered into the IT Load Marketplace and is configured to support the VC

technology of CATALYST and is equipped with all necessary components CATALYST to

operate in federated DC environment.

Post-conditions The DC has successfully placed the workload relocation bid.

Basic Flow Step 1: The DC operator logs into the IT Load marketplace

Step 2: The DC operator places a bid publicizing their intent to relocate a properly

defined workload.

Alternate Flow(s) Same as the basic flow, however the login and bid placement operations are handled

by the marketplace connector.


Use Case S3.3: Place workload relocation offer in the IT Load Marketplace

Brief Description The DC operator registers in the IT Load Marketplace their intent to accommodate a

certain set of computational resources from another DC




Trigger The DC operator selects an optimization plan indicating that set of VCs could be

accommodated for hosting by another DC

Pre-conditions The DC is registered into the IT Load Marketplace and is configured to support the VC

technology of CATALYST and is equipped with all necessary components CATALYST to

operate in federated DC environment.

Post-conditions The DC has successfully accepted the workload relocation offer.

Basic Flow Step 1: The DC operator logs into the IT Load marketplace

Step 2: The DC operator places an offer publicizing their intent to accommodate a

properly defined workload.

Alternate Flow(s) Same as the basic flow, however the login and bid placement operations are handled

by the marketplace connector.


Use Case S3.4: View / Validate workload relocation actions

Brief Description Two DCs have agreed to exchange IT load in the form of VCs and should have the

option to overview the state of this IT load exchange.


Actor(s) DC operators


Trigger A mutual agreement between two DCs is reached through the IT Load Marketplace

regarding the workload relocation from one of the DCs to the other.

Pre-conditions Both DCs are configured to support the VC technology of CATALYST and support the

CATALYST system.

The load to be migrated has already been registered as a VC in the CATALYST system



63

Post-conditions Both DCs are able to overview and validate workload relocation actions

Basic Flow Step 1: DC 1 informs the system about the load it will relocate, also letting it know

about the relevant micro contract signed in the IT Load Marketplace between DC 1

and DC 2.

Step 2: DC 1 initiates the relocation to DC 2, assisted by the CATALYST system

Step 3: DC 1 and DC 2 authenticate against the CATALYST system and check the

progress of the relocation operations.





64

6. CATALYST System Requirements

Functional Requirements

This section describes the requirements applicable to CATALYST framework mapped on three macro-

tiers we have identified on the basis of use-cases analysis: DC Optimization, Energy and IT Networks

Integration and Marketplaces.

To describe the functional requirements the template shown in Table 4 has been defined and used.

Table 4. Functional requirements definition template

ReqID Description Priority Derived from Changing History

< unique id of

the functional

requirement >

< well –formed

description of

functional

requirement >

high | medium | low <Scenarios,

use cases>

<changes brought to the

functional requirement

during the iterative

requirements definition

process>

The functional requirements will accurately capture the various actors’ needs in relation with the

CATALYST framework. To achieve this, they have to be unambiguously described thus we have followed

the ISO/IEC/IEEE 29148 standard temple on requirements defining process. All CATALYST functional

requirements are described in the form presented in Table 5 as example, where:

• Subject – is the component / process of the CATALYST framework implementing defined

requirement

• Action – the functionality it should expose;

• Verb – SHALL – priority high, should – priority medium, may – priority low

• Value – the results / output value expected in result of functionality execution.

Table 5 - Functional requirements description template

[Subject] [Action] [Value]

EXAMPLE: The System [Subject], SHALL / SHOULD / MAY [Action] in / to [Value]

6.1.1 DC Optimization

Table 6 - Functional requirements for DC Optimization macro layer

ReqID Description Priority Derived from Changing

History

REQ_F01 The system shall be able to store data gathered

from the DC monitoring system and generated

optimization plans

High All Scenarios Initial

Version

REQ_F02 The system shall permit defining customized

optimization strategies by setting weights to each of

the optimization multi-objectives according to their

importance for DC operator

High Scenarios

4,5,6,7, Use-case

S1.1

Initial

Version



65

REQ_F03 The system shall have predefined optimization

strategies

High All scenarios,

Use-case S1.2

Initial

Version

REQ_F04 The system shall allow the DC operator to select the

optimization strategy to be used

High All scenarios,

Use-case S1.2

Initial

Version

REQ_F05 The system shall calculate optimization action

plans according to customized multi-objectives

optimization strategy

High Scenarios

4,5,6,7, Use-case

S1.2, 1.3

Initial

Version


plans to allow DC to trade electrical energy

High Scenario 1, Use-

case S1.2, 1.3

Initial

Version


plans to allow DC to trade energy flexibility


case S1.2, 1.3

Initial

Version


plans to allow DC to trade thermal energy


case S1.2, 1.3

Initial

Version


plans to allow DC to trade IT load


case S1.2, 1.3

Initial

Version

REQ_F10 The system shall allow the validation for execution

of optimization actions plans

High All scenarios,

Use-case S1.3

Initial

Version

REQ_F11 The system shall permit selecting forecasting time

frame (day ahead, intraday)

High Scenario 1, 4, 5,

7, use-case 1.4,

1.5

Initial

Version

REQ_F12 The system shall predict the DC electrical energy

flexibility values in future time frames


7, use-case 1.4

Initial

Version

REQ_F13 The system shall display the DC forecasted energy

flexibility availability for different time frames


7, use-case 1.4

Initial

Version

REQ_F14 The system shall calculate the current total DC

energy flexibility availability


7, use-case 1.4,

16

Initial

Version

REQ_F15 The system shall calculate the flexibility availability

at individual DC component level


7, use-case 1.6

Initial

Version

REQ_F16 The system shall calculate the current DC electrical

energy budget (production vs consumption)


7, use-case 1.5

Initial

Version

REQ_F17 The system shall predict the DC electrical energy

budget (production vs consumption)


7, use-case 1.5

Initial

Version

REQ_F18 The system shall permit selecting the forecasting

time frame (day ahead, intraday) for thermal energy

related predictions

High Scenario 2,4,6,7

Use-case 1.7

Initial

Version

REQ_F19 The system shall calculate the current DC thermal

energy available


Use-case 1.7

Initial

Version

REQ_F20 The system shall predict the DC thermal energy in

future time frames


Use-case 1.7

Initial

Version

REQ_F21 The system shall permit the selection of metrics

and KPIs for a DC from a defined list

High All scenarios,

Use-case 1.7

Initial

Version

REQ_F22 The system shall permit the definition of target

values for selected metrics and KPIs

High All scenarios,

Use-case 1.7

Initial

Version

REQ_F23 The system shall calculate the value of target

metrics and KPIs

High All scenarios,

Use-case 1.7, 1.8

Initial

Version

REQ_F24 The system shall interface with the monitoring

system operating in DC for gathering all needed

information

High All Scenarios and

use-cases

Initial

Version

REQ_F25 The system should interface with the control system

operating in DC for controlling load/demand.

Mediu

m

All Scenarios and

use-cases

Initial

Version



66

REQ_F26 Communication interfaces with the monitoring and

control subsystems may be based on bi-directional

standardised protocols.

low All Scenarios and

use-cases

Initial

Version

REQ_F27 The system must be able to store various options of

available SLAs for VCs. High Scenario 3, 5, 6,

7, use-case

S1.11, S1.12

Initial

version

REQ_F28 The system must be able to automatically derive the

SLA state of a given VC. High Scenario 3, 5, 6,

7, S1.11, S1.12

Initial

version

REQ_F29 The system should be able to automatically decide

on the SLA level to be pursued Medium

Scenario 3, 5, 6,

7, S1.11, S1.12

Initial

version

REQ_F30 The system may automatically provide suggestions

on SLA negotiation depending on the chosen

optimization policy governing the DC operation

Low Scenario 3, 5, 6,

7, S1.11, S1.12

Initial

version

REQ_F31 The system may be able to reject the SLA

renegotiation of a VC if deemed necessary Low Scenario 3, 5, 6,

7, S1.11, S1.12

Initial

version

REQ_F32 The system must be able to perceive the

effectiveness of energy usage at intra-DC level High All scenarios and

use cases

Initial

version

REQ_F33 The system must be able to perceive the

effectiveness of energy usage at distributed DC

level

High All scenarios and

use cases

Initial

version

REQ_F34 The system may be able to perceive the

effectiveness of energy usage at federated DCs

level (supporting DCs of different administrative

domains)

Low Scenario 3, 5, 6,

7, use cases

S3.1-4

Initial

version

REQ_F35 The system must be able to optimally schedule the

IT load in a single DC context High All scenarios and

use cases

Initial

version

REQ_F36 The system must be able to optimally schedule the

IT load in a distributed DC context to realise the

“follow the energy” approach


7, use cases

S3.1-4

Initial

version

REQ_F37 The workload relocation system must be able to

interface with the optimization engine High Scenario 3, 5, 6,

7, use cases

S3.1-4

Initial

version

REQ_F38 The system should be able to translate IT load

monitoring metrics into energy/power consumption

metrics

Medium

All scenarios and

use cases

Initial

version

REQ_F39 The system shall display optimization multi-

objectives regarding electrical energy, flexibility,

thermal energy and IT load in a friendly manner

High Scenarios

4,5,6,7, Use-case

S1.1

Initial

Version

REQ_F40 The system shall display the optimization strategies

defined

High All scenarios,

Use-case S1.2

Initial

Version

REQ_F41 The system shall allow the visualization of

optimization action plans

High All scenarios,

Use-case S1.3

Initial

Version

REQ_F42 The system shall display the DC forecasted energy

flexibility availability for different time frames


7, use-case S1.4

Initial

Version

REQ_F43 The system shall display the value for defined

metrics and KPIs High All scenarios,

Use-case 1.8

Initial

Version

REQ_F44 The system should provide an optimization action

plan in respond to a DR event or flexibility order High Scenario 1, 4, 6,

7, use case

S2.27, S2.1, S2.2

Initial

Version



67

6.1.2 Energy and IT Networks Integration

Table 7 - Functional requirements for networks connection integration macro tier


History

REQ_F45 The system must be able to register new DCs in its

global instance context7 High Scenario 3, 5, 6,

7, use case S3.1

Initial

version

REQ_F46 The system must be able to register VCs and handle

their details High Scenario 3, 5, 6,

7, use case S3.1

Initial

version

REQ_F47 The system must be able to register VC migration

intents High Scenario 3, 5, 6,

7, use case S3.1

Initial

version

REQ_F48 The system must be able to register VC migration

confirmations High Scenario 3, 5, 6,

7, S3.1, S3.4

Initial

version

REQ_F49 The system must be able to provide historical data

over the lifecycle of a VC High Scenario 3, 5, 6,

7

Initial

version

REQ_F50 They system must be able to establish secure

communication channels so that workload relocation

operations are secure


7, use cases

S3.1-4

Initial

version

REQ_F51 The system should provide a graphical way for

overviewing VC details and lifecycle history Medium Scenario 3, 5, 6,

7

Initial

version

REQ_F52 The system may offer support for safe storage of SLA

renegotiations Low Scenario 3, 5, 6,

7

Initial

version

REQ_F53 They system should allow for workload relocation at

both distributed and federated DCs level Medium Scenario 3, 5, 6,

7

Initial

version

REQ_F54 The system must provide support for safe and

untamperable storage of all data related to VC

handling and lifecycle events.


7

Initial

version

REQ_F55 The system shall be able to receive DR event based on

standard communication interface. High Scenario 1, 2 and

4

Initial

Version

REQ_F56 The system shall be able to replay to opt in or opt out

a DR event based on standard communication

interface.

High Scenario 1, 2 and

4

Initial

Version

REQ_F57 The system shall be able to notify the DR request to

the DC Operator. High Scenario 1, 2 and

4

Initial

Version

REQ_F58 The system shall allow the DC Operator to

accept/reject the DR request High Scenario 1, 2 and

4

Initial

Version

6.1.3 Marketplaces

Table 8 - Functional requirements for marketplaces macro tier


History

REQ_F59 The system shall allow prosumers to

register/deregister as participants to the

Day-Ahead/Intraday IT Load Marketplace.

High Scenarios 3, 5, 6, 7,

Use-cases 3.1-4

Initial version

7 This component is considered to be distributed, partly running in a centralized manner and partly residing as a client in the CATALYST compliant DCs.



68

REQ_F60 The system shall manage a database where

IT Load Marketplace participants profile and

logon details will be kept.


Use-cases S3.1,

S3.2

Initial version

REQ_F61 The system shall be able to display stored

data related to IT Load Marketplace

participants.


Use-cases S3.2,

S3.3

Initial version

REQ_F62 The system shall allow the IT Load

Marketplace Operator to validate the

registration.


Use-case S3.4

Initial version

REQ_F63 The system shall notify IT Load Marketplace

participant of the profile validation process

result.


Use-case S3.4

Initial version

REQ_F64 The system shall allow prosumers to update

a IT Load Marketplace profile.


Use-case S3.3

Initial version


Marketplace Operator to validate updates in

the participant profile.


Use-cases S3.4

Initial version


Marketplace Operator to schedule market

sessions.


Use-case S3.1

Initial version

REQ_F67 The system must be able to generate and

safely store micro contracts properly

documenting workload relocation

agreements among DCs achieved through

the IT Load Marketplace


Use-cases 3.1-4

Initial version



Day-Ahead/Intraday Flexibility Marketplace.


use cases S2.2,

S2.3

Initial Version


Flexibility Marketplace participants profile

and logon details will be kept.


use cases S2.2,

S2.3

S2.4, S2.5

Initial Version


data related to Flexibility Marketplace

participants.


use case S2.3

Initial Version

REQ_F71 The system shall allow the Flexibility

Marketplace Operator to validate a request

for account.


use case S2.5

Initial Version


a Flexibility Marketplace profile.


use case S2.4

Initial Version





use case S2.5

Initial Version

REQ_F74 The system shall notify Flexibility

Marketplace participant of the profile

validation process result.


use case S2.4

Initial Version



sessions.


use case S2.1

Initial Version

REQ_F76 The system should be able to store Flexibility

Marketplace sessions scheduling.


use case S2.1

Initial Version



69


Marketplace participants to place offers to

sell flexibility.


use case S2.7

Initial Version

REQ_F78 The system shall manage a database to store

offers related to Flexibility Marketplace

sessions.


use cases S2.7,

S2.6,

S2.8, S2.9

Initial Version

REQ_F79 The system shall be able to validate offers

respecting Flexibility Marketplace rules.


use case S2.7

Initial Version

REQ_F80 The system shall allow the DSO to elicit

accepted offers in the Flexibility Marketplace

session.


use case S2.8

Initial Version

REQ_F81 The system shall inform Flexibility

Marketplace participants about market

sessions results


use case S2.9

Initial Version



Day-Ahead/Intraday Heat/Cold

Marketplace.


use case S2.12,

S2.13

Initial Version


Heat/Cold Marketplace participants profile


High Scenarios 2,4,6,7

use cases S2.12,

S2.13, S2.14,

S2.15

Initial Version


data related to Heat/Cold Marketplace

participants.


use case S2.13

Initial Version

REQ_F85 The system shall allow the Heat/Cold

Marketplace Operator to validate a request

for account.


use case S2.15

Initial Version


a Heat/Cold Marketplace profile.


use case S2.14

Initial Version





use case S2.15

Initial Version

REQ_F88 The system shall notify Heat/Cold




use case S2.14

Initial Version



sessions.


use case S2.11

Initial Version

REQ_F90 The system should be able to store

Heat/Cold Marketplace sessions scheduling.


use case S2.11

Initial Version


Marketplace participants to place

bids/offers to buy/sell heat/cold.


use case S2.17

Initial Version


bids/offers related to Heat/Cold

Marketplace sessions.


use cases S2.17,

S2.16, S2.18

Initial Version

REQ_F93 The system shall be able to validate bid/offer

respecting Heat/Cold Marketplace rules.


use case S2.17

Initial Version

REQ_F94 The system shall provide a mechanism to

elicit accepted bids/offers in the Heat/Cold

Marketplace session.


use case S2.18

Initial Version



70

REQ_F95 The system shall be able to determine the

equilibrium price in the Heat/Cold



use case S2.18

Initial Version

REQ_F96 The system shall inform Heat/Cold


sessions results.


use case S2.18

Initial Version



Day-Ahead/Intraday Electricity Marketplace.


use cases S2.20,

S2.21

Initial Version


Electricity Marketplace participants profile



use cases S2.20,

S2.21, S2.22,

S2.23

Initial Version


data related to Electricity Marketplace

participants.


use case S2.21

Initial Version

REQ_F100 The system shall allow the Electricity

Marketplace Operator to validate the request

for account.


use case S2.23

Initial Version


an Electricity Marketplace profile.


use case S2.22

Initial Version



the profile.


use case S2.23

Initial Version

REQ_F103 The system shall notify Electricity



High Scenarios 1,4,5,7,

use case S2.23

Initial Version



sessions.


use case S2.19

Initial Version

REQ_F105 The system should be able to store Electricity



use case S2.19

Initial Version


Marketplace participants to place

bids/offers to buy/sell electricity.


use case S2.25

Initial Version


bids/offers related to Electricity Marketplace

sessions.


use cases S2.25,

S2.24, S2.26

Initial Version

REQ_F108 The system shall be able to validate bid/offer

respecting Electricity Marketplace rules.


use case S2.25

Initial Version

REQ_F109 The system shall provide a mechanism to

elicit accepted bids/offers in the Electricity



use case S2.26

Initial Version

REQ_F110 The system shall be able to determine the

equilibrium price in the Electricity



use case S2.26

Initial Version

REQ_F111 The system shall inform Electricity


sessions results


use case S2.26

Initial Version

REQ_F112 The system shall be able to receive flexibility

request from the Flexibility Aggregator.


use case S2.10

Initial Version



71

REQ_F113 The system shall be able to notify the DC

Operator that a flexibility request from the

Flexibility Aggregator has been received.


use case S2.10

Initial Version

REQ_F114 The system shall be able to manage IT Load

Marketplace sessions.


Use-case S3.2

Initial Version

REQ_F115 The system shall be able to manage

Flexibility Marketplace sessions.


use case S2.7

Initial Version


Heat/Cold Marketplace sessions.


Use-case S2.17

Initial Version


Electricity Marketplace sessions.


use case S2.25

Initial Version

REQ_F118 The system should be able to store IT Load



Use-case S3.1

Initial Version

REQ_F119 The system shall be able to instantiate and

properly configure new marketplace

instances of any type (electricity, flexibility,

heat/cold, IT load) upon request.

High Scenarios 1,4,5,7 Initial Version

REQ_F120 The system shall provide a communication

interface between optimization engine and

relevant marketplaces

High All Scenarios Initial Version

Non-functional Requirements

This section describes the services offered by the system, defining properties and constraints such as

reliability, robustness, usability, time and memory constraints.

The following non-functional requirements will be considered:

i. Reliability, i.e. system availability to the end user actor at any given time

ii. Efficiency, e.g. throughput, response time, transit delay, latency

iii. Performance

iv. Scalability, i.e. the system is available to more users and cover wider areas

v. Expandability, i.e. the system can be expanded with new types of service

vi. Interoperability, i.e. the system is able to interact with other external systems

vii. Security

viii. Privacy

ix. Maintainability

x. Resilience

Non-functional requirements analysed in this section are listed in Table 11 below showing the following

properties:

i. ID: univocal identifier of the requirements

ii. Type: type of requirements

iii. Priority: priority in requirement implementation (mandatory 1, desirable 2, optional 3)

iv. Description: brief description of the functionality expressed

Table 9 - Non-functional requirements considered for the CATALYST framework

ID Description Type Priority

REQ_NF01 The communication among the CATALYST framework

components and with monitoring devices must be secure.

Security high



72

REQ_NF02 The CATALYST framework shall provide measure to prevent

unauthorized access to personal information.

Security high

REQ_NF03 The CATALYST framework shall provide functionality that

operates in a safe manner during degraded modes of

operation.

Reliability high

REQ_NF04 The CATALYST framework should be able to inform user about

any malfunctions.

Reliability medium

REQ_NF05 Required resources of the system should increase

proportionally with the number of loads.

Scalability medium

REQ_NF06 The system shall provide open interface specification to

facilitate integration of new services as plug-ins.

Interoperability high

REQ_NF07 The system shall provide open interface specification to allow

data exchange with external systems.

Interoperability high

REQ_NF08 The system shall be developed to be simple and efficient for

the end users and easy to understand.

Usability high

REQ_NF09 Data exchanged with external systems shall be protected. Privacy high

REQ_NF10 The system shall prevent loss of information. Resilience high

REQ_NF11 The system shall be able to be upgraded without any

disturbances to the services

Maintainability high



73

7. CATALYST Architecture – 1st version

Figure 10, below presents the first version of the CATALYST framework architecture.

Figure 10 - CATALYST framework architecture

To support the CATALYST innovative vision, the DC optimization process requires addressing diverse,

so far disjoint, disciplines of the DC industry. Such consideration of the “DC as a system of systems”

determines precise architectural choices for the architectural design, which derive horizontal layers

and vertical tiers of coordinated optimization. Three layers are defined:

• Monitoring and Control Layer (electricity and heat/cool), including both generated, stored and

consumed energy by distributed sources across the ecosystem;

• ICT Layer, including innovative technologies and communications load in a single DC, in a

group of federated DC grids or in distributed DCs;

• Coordination Layer allowing unified access to both energy (electrical and thermal) and ICT

loads across the ecosystem.

The vertical tiers and their components offer technical support in scaling up optimization capabilities

of single DC loads ensuring effective RES integration, as well as scaling out optimization to the holistic

ecosystem of federated DCs, electricity and heat/cooling networks. Three tiers are defined:

• Optimization Engine Tier – deals with individual DC optimization to offer energy flexibility

services or heat reuse, etc.

• Networks Interface Tier – deals with integration with smart energy grids, DCs federation and

CATALYST Marketplaces

• CATALYST Marketplace Tier – Marketplace as a Service approach to instantiate various

flavours of CATALYST marketplaces

The Mutualized Energy Integration Services enacted by CATALYST will be consisting of energy flexibility,

security and optimized management tailored to DC operators, targeting at managing the available non-

grid renewable (PV, local storage, heat pumps) and non-renewable (backup generators) energy assets

as well as the IT assets (via cloud-based geo-spatial-temporal IT virtualization). Such energy services



74

will be provided by DCs through appropriate open, standardized energy marketplaces, instantiated

either as mono-carrier energy marketplaces (electricity vs heat marketplace) cleared sequentially, or

as multi-energy marketplaces (energy marketplaces). Along this innovative value chain, new

stakeholders will be willing to provide these Energy services to DCs, like ESCOs, energy suppliers,

aggregators, IT/cloud solution/technology providers. Cross-energy carrier synergies among electricity

and heat will be also exploited and managed with a view to leverage and exploit flexibility potential of

one energy carrier to offer energy services to another.

The mutualized energy services provisioning and integration will be assured using a Marketplace as a

Service platform instantiated in four emerging and innovative DC revenue streams (see Figure 11

below):

• IT Load Marketplace, among DCs which covers workload relocation to gain financial revenues or follow the renewable energy;

• Electricity Marketplace between DCs and other electrical energy prosumers to trade electricity;

• Flexibility Marketplace between aggregators and their enrolled prosumers (including DCs) and DSO to trade flexibility services;

• Heat/Cold Marketplace between the DC operator and heat aggregators to trade heat and cooling.

Figure 11 - CATALYST marketplace design

Especially the latest marketplace is quite interesting as waste heat reuse especially in District Heating

Networks oriented to Smart Thermal Grid paradigm (e.g. Low Temperature DH Networks) is expected

to become a considerable financial revenue stream for DCs, trading off additional costs for waste heat

regeneration (e.g. heat pumps) with incremental revenues from waste heat valorisation. In such a

framework, DCs may enjoy either heat/gas procurement costs savings when excess heat is used for

internal offices heating/cooling and/or SH, or additional revenues if surplus heat is offered through

appropriate marketplaces to potentially interested users, typically DHC operators and heat suppliers,

achieving an overarching win-win system-level collaboration.



75

Components and progress beyond pre-CATALYST results

In this section we have analysed and grouped functional requirements onto CATALYST framework

architecture components. At the same time, we have analysed them in the context of pre-CATALYST

projects results to identify the ones addressed in previous projects and for those the expected TRL

jump to be achieved in CATALYST has been defined (see Table 10 below).

Table 10 - CATALYST framework components and requirements mapping

Module / Tool

Name

Partner /

Project

Description Functional Requirements

New Addressed in Pre-CATALYST

project

Requireme

nt id

Curre

nt

TRL

Target

TRL

Optimization Engine

Intra DC Energy

Optimizer

GEYSER

TUC /

GEYSER

This component is

responsible for the overall

optimization at DC level,

taking into account the

trading of electrical energy,

energy flexibility, heat and IT

workload;

REQ_F39

REQ_F02

REQ_F05

REQ_F07

REQ_F08

REQ_F03

REQ_F40

REQ_F04

REQ_F06

REQ_F09

REQ_F41

REQ_F10

4 6

SLA

(re)negotiation

POPs /

DOLFIN

This component is

responsible for negotiating,

monitoring and renegotiating

(if needed) the end-users

SLAs via flexible contracts

REQ_F27

REQ_F28

REQ_F31

REQ_F52

REQ_F29

REQ_F30

4 6

Energy

Efficiency

Policy Actuator

TUC /

GEYSER

This component is

responsible for calculating

and supervising the DC

metrics and KPIs.

REQ_21

REQ_23

REQ_22

REQ_43

4 6

Energy Aware IT

Load Balancing

QRN &

POPs /

NEW

This component will be in

charge of identifying and

shifting IT load inside the DC,

and implementing “follow the

heat” strategy in case of a

distributed DC

REQ_F32

REQ_F33

REQ_F34

REQ_F35

REQ_F36

- - 5

Electricity

DR Prediction

TUC /

GEYSER

This component is


current and forecasted DC

electrical energy budget as

well as the current and

forecasted energy flexibility

REQ_F12

REQ_F13

REQ_F14

REQ_F15

REQ_F11

REQ_F16

REQ_F17

4 6

Optimization

Database and

REST API

TUC /

NEW

Database for storing

monitoring data and action

plans and interface for

inserting and sharing data

REQ_F01 - - 6

Heat/Cold

DR Prediction

PSNC /

NEW

This component is


current and forecasted DC

thermal energy budget

REQ_F18

REQ_F19

REQ_F20

- - 5



76

IT & Energy

Control

Manager

ENG /

NEW

This component interfaces

the DC appliances & RES, (via

existing DCIM), implements

and executes the

optimization action plans

REQ_F25

REQ_F26

- - 5

DC Manager

Console

SILO /

GEYSER

This component enables the

DC Manager to configure,

administrate and control the

CATALYST DC Energy

Awareness and Efficiency

Framework installed in DC

- REQ_F04

REQ_F11

REQ_F13

REQ_F39

REQ_F40

REQ_F41

REQ_F42

REQ_F43

6 7

IT & Energy

Supervisor

POPs,

QRN /

DOLFIN

This component supervises in

real time the Energy

consumption/generation

- REQ_F38 4 5

Monitoring

System

Interface

ENG /

NEW

This component interfaces

with existing DCIM systems

and BMS already installed in

a DC

REQ_F24 - - 5

Federated DC IT

Orchestration

POPs /

DOLFIN

This component is

responsible for IT

orchestration including

negotiation of VC migration

among synergetic / federated

DCs grids

REQ_F37

REQ_F46

REQ_F47

REQ_F48

REQ_F49

REQ_F50

REQ_F51

REQ_F53

REQ_F45

4 6

Networks Integration Interface

Smart Grid

Connector

ENG /

GEYSER

This component is an

OpenADR controller to

simulate the interface of DC

with Electricity Smart Grids

- REQ_F55

REQ_F56

REQ_F57

4 6

Marketplace

Connector

ENG,

SILO /

NEW

This component is

responsible for interfacing

the DC with various energy

marketplaces

REQ_F120 - - 5

Federated DC IT

Migration

Controller

POPs,

QRN /

NEW

This component will cater for

the secure migration of VCs

migrated across DCs/Clouds

and catalyse the actual VCs

migration

REQ_F50

REQ_F51

REQ_F53

- - 5

Marketplaces

MaaS Platform SILO,

POPs /

NEW

This component is

responsible for CATALYSTS

Marketplaces instantiation

REQ_F119 - - 5

Information

Broker

SILO /

GEYSER

This component is

responsible for facilitating

information exchange inside

the marketplace delivering

the right piece of information

to interested parties.

REQ_F91

REQ_F106

REQ_F75

REQ_F77

REQ_F81

REQ_F89

REQ_F91

REQ_F106

4 6



77

Market Session

Manager

ENG /

GEYSER

This component is

responsible for managing

market sessions

REQ_F114

REQ_F116

REQ_F93

REQ_F94

REQ_F95

REQ_F115

REQ_F117

REQ_F108

REQ_F109

REQ_F110

4 6

Bids/Offers

Collector

SILO /

GEYSER

This component is

responsible for collecting any

information associated with

bids and offers made by the

Marketplace participants

- REQ_F79

REQ_F93

REQ_F108

6 7

Security

Manager

SILO /

NEW

This component is

responsible for handling

authentication and

authorization for marketplace

users.

All

marketplac

e REQ

- - 7

Access

Manager

SILO /

GEYSER

This component provides with

the actors the web interface

of the marketplace

REQ_F59

REQ_F61

REQ_F62

REQ_F63

REQ_F64

REQ_F65

REQ_F66

REQ_F84

REQ_F85

REQ_F86

REQ_F87

REQ_F88

REQ_F89

REQ_F91

REQ_F93

REQ_F96

REQ_F113

REQ_F74

REQ_F75

REQ_F77

REQ_F79

REQ_F80

REQ_F81

REQ_F82

REQ_F97

REQ_F99

REQ_F100

REQ_F101

REQ_F102

REQ_F103

REQ_F104

REQ_F106

REQ_F111

4 6

Marketplace

Data Base

ENG /

GEYSER

It keeps information on

marketplace actors,

marketplace instances,

marketplace sessions,

bids/offers

REQ_F60

REQ_F67

REQ_F83

REQ_F90

REQ_F92

REQ_F118

REQ_F69

REQ_F76

REQ_F78

REQ_F98

REQ_F105

REQ_F107

4 6

CATALYST Optimization Data Model

In this section we describe the first version of the CATALYST framework optimization data model

implemented by the Optimization Database component. In the elaboration of the CATALYST

Optimization Engine data model we have adapted and improved the design of the ICT Topology Graph

Database developed in the EU FP7 Dolphin project and described in Deliverable D3.1 (Data Centre

energy consumption optimization platform (eCOP) Design). The CATALYST data model is using a set of

tables that store the DC components and their measurable properties (see Figure 12).



78

Figure 12 - CATALYST Optimization Engine Data Model

The data structure is hierarchical and can support graph structures. It is based on four main tables to

store information about the physical elements of the DC and four tables to store the associated

properties (Device Type, the Measure Unit, the Property Source and the Value Type):

• The Topology Table stores the root of the DC topology and may correspond to the entire data

centre or the inlet stem of the electrical wiring system.

• The Device Table contains the physical or logical devices from the data centre and also has a

type defined. The device can have as parent another device or a topology. For instance, in

Figure 11 the Device table contains the list of Servers, having the type SERVER defined in the

Device Type table and as parent another device element Rack1. The other physical elements

of the data centre, such as racks, the list of virtual machines, the cooling system, the battery

and the heat pump are defined in the Device table.

• The Measure Table stores the measured properties for each device type. It is always a leaf

element of the Graph Topology and it defines the measured property, the property source and

the measuring unit of the property.

• The Monitored Value table stores the timestamp and the value monitored for the measures

defined in the Measure table for each of the device instances defined in the Device table. It

defines a timestamp for each value, the monitored value, the ID of the measured property and

the ID of the device instance that is monitored. The Monitor table can have a NoSQL format

and can be implemented using technologies such as Apache Cassandra.

Table 11 below shows the colouring legend of the properties, only for reading purposes, the manual

or static properties being coloured in light blue, while the monitored properties being coloured in light

green or light red. Some properties are labelled as manual, meaning that they represent the

characteristics of the physical devices, while others are labelled as monitored meaning that their

values are continuously updated by sensors.

Table 11 - Legend of table colours

Static or Manual Properties



79

Electrical Energy Consumption Optimization

Thermal and Heat Reuse Optimization

The Servers are defined as devices and have the measured properties defined in Table 12.

Table 12 - Server Device Measure Properties

Parent Property Measure Unit Property

Source

Measured

Value Type

Observation

Server CPU Cores # (number) Manual Integer

CPU Power Consumption Watt Manual Double

RAM Capacity Giga Byte Manual Double

HDD Capacity Giga Byte Manual Double

GPU Cores # (number) Manual Double

GPU Power Consumption Watt Manual Double

GPU Memory Giga Byte Manual Double

Network Interface Speed Giga Byte

/Sec

Manual Double

Maximum Power

Consumption

Watt Manual Double

Idle Power Consumption Watt Manual Double

Maximum Operating

Temperature Limit ℃ Manual Double

Rack ID # (number) Manual Integer

Position in Rack # (number) Manual Integer

Actual Power

consumption

Watt Measured Double

Inside Server

Temperature ℃ Measured Double Measure Temperature

inside the server (CPU

temperature)

Input coolant

temperature ℃ Measured Double For air cooled servers,

measure the input /

output air

temperature. For

liquid cooled servers,

measure the coolant

temperature.

Output coolant

Temperature ℃ Measured Double

Input Coolant Flow 𝑚3

𝑠

Measured Double Flow of coolant over

server (either air or

liquid)

CPU Load %

(percentage)

Measured Double

CPU Cores Used # (number) Measured Double

RAM Used Space Giga Byte Measured Double

RAM Input / Output Rate Giga Byte

/Second

Measured Double Only if possible

HDD Used Space Giga Byte Measured Double

HDD Input / Output Rate Giga Byte

/Second

Measured Double Only if possible

Network Usage Giga Byte

/Second

Measured Double

GPU Load %

(percentage)

Measured Double



80

GPU Cores Used # (number) Measured Double

GPU RAM Used Space Giga Byte Measured Double

Table 13 below show the properties of the Racks and Aisle as devices stored by the CATALYST data

model.

Table 13 - Rack and Aisle Properties


Source

Measured

Value Type

Observation

Rack Number of Servers # (number) Manual Integer

Actual power consumption Watt Measured Double

Aisle Number of Racks # (number) Manual Integer

Type ENUM Manual HOT/COLD

Actual power consumption Watt Measured Double


The VMs or Tasks their properties defined in Table 14 below.

Table 14 - VM/Task properties stored in the data model


Source

Measured Value

Type

Observation

Task/VM scheduling class # (number) Measured ENUM Real-time/ Delay

tolerant

User/Owner ID # (number) Measured Integer Owner ID (to

cluster Tasks)

priority # (number) Measured Integer

requestArrivalTime Time Measured Long

requestDeadLine Time Measured Long

resource request

for CPU cores

Measured Integer

resource request

for RAM

Giga Byte Measured Double

resource request

for local disk space

Giga Byte Measured Double

resource request

for GPU Cores

# (number) Measured Integer

Server ID # (number) Measured Integer

task index # (number) Measured Integer Task ID

event type ENUM Measured DEPLOY, MIGRATE,

SCHEDULE, etc.

Event on Task

CPU Cores used # (number) Measured Integer

RAM memory used Giga Byte Measured

HDD usage Giga Byte Measured

Network Usage

Bandwidth

Giga Byte

/Second

Measured

GPU Cores Used # (number) Measured Integer

GPU RAM Used Giga Byte Measured

Table 15 below presents the properties of the cooling system stored in the data model.



81

Table 15 - Cooling System properties

Parent

Property Measure Unit Property

Source

Measured

Value Type

Observation

Cooling System Cooling System

Type

- Manual ENUM Liquid Cooling/ Air

Cooling

Cooling

Capacity

kW Manual Double

Maximum

Power

Consumption

kW Manual Double

Maximum

Direct Circuit

Flow

L/h Manual Double The Direct Circuit

Extracts the heat from

the Servers

Direct Circuit

Coolant Specific

Heat

𝑘𝐽

𝐾𝑔 ∗ 𝐾

Manual Double

Maximum

Secondary

Circuit Flow

L/h Manual Double The Secondary Circuit

Dissipates the heat in

the environment

Secondary

Circuit Coolant

Specific Heat

𝑘𝐽

𝐾𝑔 ∗ 𝐾

Manual Double

Coefficient of

Performance

for Cooling

# (number) Manual Double Coefficient that

correlates the heat

extraction to energy

consumption

Actual Power

Consumption

kW Measured Double

Actual Direct

Circuit Flow

L/h Measured Double

Actual

Secondary

Circuit Flow

L/h Measured Double

Server Room

Temperature

Set point

℃ Measured Double

Input Air

(Coolant)

Temperature

℃ Measured Double

Return Air

(Coolant)

Temperature

℃ Measured Double

Cold Aisle

Temperature ℃ Measured List<

Double>

Hot Aisle

Temperature ℃ Measured List<

Double>

The Heat Reuse system is defined as device and have the measured properties defined in Table 16.

Table 16 - Heat Reuse System properties


Source

Measured

Value Type

Observation



82

Heat Pump Maximum Heat Extraction kW Manual Double

Maximum Heat Reuse kW Manual Double

Maximum Electrical Power

Consumption

kW Manual Double

Direct Circuit Maximum Flow L/h Manual Double The Direct

Circuit Extracts

the heat

Direct Circuit Maximum

Temperature Difference ℃ Manual

Direct Circuit Coolant Specific

Heat

𝑘𝐽

𝐾𝑔 ∗ 𝐾

Manual Double

Secondary Circuit Maximum

Flow

L/h Manual Double The Secondary

Circuit Reuses

the heat

Secondary Circuit Maximum

Temperature Difference ℃ Manual Double

Secondary Circuit Coolant

Specific Heat

𝑘𝐽

𝐾𝑔 ∗ 𝐾

Manual Double

Coefficient of Performance

for Cooling

# (number) Manual Double

Coefficient of Performance

for Heating

# (number) Manual Double

Direct Circuit Input


Direct Circuit Output


Direct Circuit Flow L/h Measured Double

Secondary Circuit Input


Secondary Circuit Output


Secondary Circuit Flow L/h Measured Double

Actual Power Consumption kW Measured Double

Actual Heat Extracted kW Measured Double

Actual Heat Reused kW Measured Double

The renewable energy generation system is defined as device and have the measured properties

defined in Table 17.

Table 17 - Photovoltaic Panel Device Measure Properties


Source

Measured

Value Type

Observation

Photovoltaic

Panels

maxCapacity kWh Manual double

totalSolarPanelArea 𝑚2 Manual double

solarPanelYield °(𝑑𝑒𝑔𝑟𝑒𝑒𝑠) Measured double

averageIrradiationOnTiltedPanels 𝑘𝑊

𝑚2

Measured double

performanceRatio %

(percentage)

Manual double

energyProduction kWh Measured double

Frequency Hertz Measured double

Voltage V Measured double



83

Wind

Generators

maxCapacity kWh Manual double

Blade length L Manual double

Wind speed m/s Measured double

energyProduction kWh Measured double

frequency Hertz Measured double

Voltage V Measured double

Energy storage devices properties are described in Table 18 below.

Table 18 - Energy storage properties


Source

Measured

Value Type

Observation

Batteries maximumCapacity kWh Manual double

maxDischargeRate kW Manual double

maxChargeRate kW Manual double

energyLossRate % (percentage) Manual double

chargeLossRate % (percentage) Manual double

dischargeLossRate % (percentage) Manual double

loadedCapacity kWh Measured double

ChargeRate kW Measured double

DischargeRate kW Measured double

Thermal

Storage Tank

maximumCapacity kWh Manual double

𝐿 𝑜𝑟 𝑚3 Manual double

maxDischargeRate kW Manual double

𝐿

𝑠 𝑜𝑟

𝑚3

𝑠

Manual double

maxChargeRate kW Manual double

𝐿

𝑠 𝑜𝑟

𝑚3

𝑠

Manual double

Coolant specific

heat

𝑘𝐽

𝐾𝑔 ∗ 𝐾

Manual double

energyLossRate % (percentage) Manual double

chargeLossRate % (percentage) Manual double

dischargeLossRate % (percentage) Manual double

loadedCapacity kWh Measured double

𝐿 𝑜𝑟 𝑚3 Measured double

ChargeRate kW Measured double

𝐿

𝑠 𝑜𝑟

𝑚3

𝑠

Measured double

DischargeRate kW Measured double

𝐿

𝑠 𝑜𝑟

𝑚3

𝑠

Measured double



84

8. Conclusions

In this deliverable we have reported the initial set of the CATALYST framework requirements and first

version of its architecture.

In detail, we have defined the requirements elicitation and analysis method we used to establish the

CATALYST framework boundaries and relation with domain problem which is the DC optimization

considering the integration with energy, thermal and IT networks. For requirements discovery we have

investigated current best practices in relation with DC optimization and potential, opportunities in our

project pilots and flexibility markets and have defined 7 main scenarios based on potential

combination of assets (individual or in combination) the DC may activate in order to gain new revenue

streams and decrease their carbon footprint: electrical energy and flexibility, heat/cold and IT load.

From this scenarios use-cases, functional and non-functional have been derived grouped in macro

tiers identified DC optimization, energy networks integration, and federated DCs integration. The

functional requirements are defined and then mapped onto components integrated in a first version

of the architecture highlighting the new and already existing ones form previous projects. For already

existing ones the current and target TRL is presented.

This specifications and requirements will be refined considering feedback received from integration

and trials evaluation activities and reported in D2.3 Final CATALYST framework architecture in project

month 20.



85

References

[1] “GEYSER - Green nEtworked data centers as energY proSumers in smaRt city environments,”

[Online]. Available: http://www.geyser-project.eu/.

[2] “DOLFIN - Data Centres Optimization for efficient and environmental friendly internet,” [Online].

Available: http://www.dolfin-fp7.eu/.

[3] G. Mussbacher, G. Bochmann and N. Niu , Requirements Analysis and Specification.

catalyst specification & design€¦ · catalyst specification & design 768739 10 together,...

Documents