D2.3 F in al CATALYST Framework
Architect ure
WORKPACKAGE PROGRAMME IDENTIFIER WP2 H2020-EE-2016-2017
DOCUMENT PROJECT NUMBER D2.3 768739
VERSION START DATE OF THE PROJECT 1.0 01/10/2017
PUBLISH DATE DURATION 03/06/2019 36 months
DOCUMENT REFERENCE CATALYST.D2.3.PARTNER.WP2.v1.0
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.3.PARTNER.WP2.v1.0
WORKPACKAGE: WP2
DELIVERABLE TYPE R (report)
AVAILABILITY PU (Public)
DELIVERABLE STATE Final
CONTRACTUAL DATE OF DELIVERY 31/05/2019
ACTUAL DATE OF DELIVERY 03/06/2019
DOCUMENT TITLE Final CATALYST Framework Architecture
AUTHOR(S) Marzia Mammina (ENG), Terpsi Velivassaki (SiLO), Tudor Cioara (TUC), Nicolas Sainthérant (QRN), Artemis Voulkidis (POPs), John Booth (GIT)
REVIEWER(S) Artemis Voulkidis (POPs) Terpsi Velivassaki (SILO)
SUMMARY (See the Executive Summary)
HISTORY (See the Change History Table)
KEYWORDS Use Cases; Architecture; Software Components; Data Model
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
1
Change History
Version Date State Author (Partner) Description 0.1 12/03/2019 ToC Marzia Mammina (ENG) First ToC
0.2 14/03/2019 ToC Artemis Voulkidis (POPs) ToC review
0.3 20/03/2019 ToC Terpsi Velivassaki (SiLO) ToC review
0.4 11/04/2019 ToC Marzia Mammina (ENG) Final ToC
0.5 06/05/2019 Draft Marzia Mammina (ENG) Introduction
0.5.1 06/05/2019 Draft Marzia Mammina (ENG) Use Cases updates, Architecture overview, 0.5.2 14/05/2019 Draft Tudor Cioara (TUC) Contribution on data model and on software components under TUC responsibilities 0.5.3 15/05/2019 Draft Nicolas Sainthérant (QRN) Contribution on software components under QRN responsibilities 0.5.4 16/05/2019 Draft Terpsi Velivassaki (SiLO) Contribution on software components under SiLO responsibilities 0.5.5 17/05/2019 Draft Artemis Voulkidis (POPs) Contribution on software components under POPs responsibilities 0.5.6 20/05/2019 Draft Marzia Mammina (ENG) Contribution on software components under ENG responsibilities 0.6 21/05/2019 Draft Marzia Mammina (ENG) Minor changes
0.9 24/05/2019 Complete Draft Marzia Mammina (ENG) Consolidated version ready for peer-review 0.9.1 27/05/2019 Peer-reviewed Artemis Voulkidis (POPs) Peer reviewed
0.9.2 30/05/2019 Peer-reviewed Terpsi Velivassaki (SiLO) Peer reviewed
0.9.5 03/06/2019 Release Candidate Marzia Mammina (ENG), Reviewers comments addressed John Booth (GIT) – integration of the GIT contribution (Appendix B) 0.9.9 03/06/2019 Quality Checked Diego Arnone (ENG) Quality check
1.0 03/06/2019 Final Diego Arnone (ENG) Final version ready for submission to EC
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
2
Table of Contents
Change History ...... 2 Table of Contents ...... 3 List of Figures ...... 5 List of Tables ...... 6 List of Acronyms ...... 7 Executive Summary ...... 9 1 Introduction ...... 10 1.1 Intended Audience ...... 10 1.2 Relations to other activities ...... 10 1.3 Document overview ...... 11 2 CATALYST use cases ...... 12 2.1 Federated DCs Integration and IT Load Marketplace ...... 12 3 CATALYST framework architecture ...... 17 3.1 Overview ...... 17 3.2 Development View ...... 18 3.2.1 Intra DC Energy Optimizer ...... 18 3.2.2 SLA (re)negotiation ...... 20 3.2.3 Energy Efficiency Metrics Calculator ...... 22 3.2.4 Electricity DR Prediction ...... 23 3.2.5 Heat DR Prediction ...... 24 3.2.6 Energy Control Manager ...... 26 3.2.7 DC Operator Console ...... 26 3.2.8 Monitoring System Interface ...... 27 3.2.9 Smart Grid Connector ...... 28 3.2.10 Data Storage and DB API ...... 29 3.2.11 Energy Aware IT Load Balancer ...... 39 3.2.12 Federated DC IT Load Migration Controller...... 42 3.2.13 Virtual Container Generator ...... 44 3.2.14 Marketplace Connector ...... 46 3.2.15 MaaS Platform ...... 48 3.2.16 Information Broker ...... 48 3.2.17 Market Session Manager ...... 61 3.2.18 Market Clearing Manager ...... 62
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
3
3.2.19 Access Manager...... 63 3.2.20 Multi-energy Market Manager...... 64 3.3 Processes View ...... 65 3.4 Deployment View ...... 71 4 CATALYST Data Model ...... 73 5 Conclusions ...... 75 References ...... 76 A. Appendix: From GEYSER to CATALYST ...... 78 B. Appendix: Green Data Certification and assessment Toolkit ...... 79 Green Data Centre Roadmap ...... 79 Data Centre Infrastructure Standards ...... 80 Metrics and Key Performance Indicators on Resources ...... 86 Assessment Toolkit Building Blocks ...... 87 Classification Scheme ...... 88 Grading System ...... 89 Themes ...... 90 Energy Efficient Infrastructure ...... 90 Resources Management ...... 90 The Value-Added Plan (VAP) ...... 91 Conclusions and Outlook ...... 91
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
4
List of Figures
FIGURE 1 - WP2 RELATION WITH OTHER WORK PACKAGES ...... 11 FIGURE 2 - CATALYST IT LOAD MARKETPLACE USE CASES DIAGRAM ...... 13 FIGURE 3 - CATALYST FRAMEWORK LOGICAL ARCHITECTURE ...... 17 FIGURE 4 - INTRA DC OPTIMISER INTERACTION WITH OTHER COMPONENTS ...... 19 FIGURE 5 - HIGH-LEVEL SLA (RE)NEGOTIATION INTERACTIONS ...... 21 FIGURE 6 - INTRA DC OPTIMIZER INTERACTIONS WITH OTHER CATALYST COMPONENTS ...... 22 FIGURE 7 - ELECTRICITY DR PREDICTION INTERACTIONS WITH OTHER CATALYST COMPONENTS ...... 23 FIGURE 8 - ELECTRICITY DR PREICTION INTERACTIONS WITH OTHER COMPONENTS ...... 25 FIGURE 9 - MONITORING SYSTEM INTERFACE INTERACTIONS WITH OTHER CATALYST COMPONENTS (IN GREEN)...... 27 FIGURE 10 - SMART GRID CONNECTOR INTERACTIONS WITH OTHER CATALYST COMPONENTS...... 28 FIGURE 11 - ENERGY AWARE IT LOAD BALANCER INTERACTIONS WITH OTHER CATALYST COMPONENTS ...... 40 FIGURE 12 - ENERGY AWARE IT LOAD BALANCER CLIENT BALANCER INTERACTIONS WITH OTHER COMPONENTS ...... 41 FIGURE 13 - INTERACTIONS INVOLVING THE FEDERATED DC IT LOAD MIGRATION CONTROLLER ...... 43 FIGURE 14 - VIRTUAL CONTAINER GENERATOR (VCG) HIGH-LEVEL INTERACTIONS WITH OTHER CATALYST COMPONENTS. 44 FIGURE 15 - MARKETPLACE CONNECTOR INTERACTIONS WITH OTHER CATALYST COMPONENTS ...... 46 FIGURE 16 - THE CATALYST IB ...... 49 FIGURE 17 - INFORMATION BROKER INTERACTIONS WITH OTHER CATALYST COMPONENTS ...... 50 FIGURE 18 - EXAMPLE OF USAGE OF IB API SWAGGER ...... 50 FIGURE 19 - EXAMPLE OUTPUT OF IB API CALL VIA SWAGGER ...... 51 FIGURE 20 - INTERACTIONS INVOLVING THE MARKET SESSION MANAGER ...... 61 FIGURE 21 - INTERACTIONS INVOLVING THE MARKET CLEARING MANAGER ...... 62 FIGURE 22 - INTERACTIONS INVOLVING THE ACCESS MANAGER ...... 63 FIGURE 23 - INTERACTIONS INVOLVING THE MULTI-ENERGY MARKET MANAGER...... 65 FIGURE 24 - CATALYST OPTIMISATION PROCESS ...... 67 FIGURE 25 - POSTING NEW OFFERS IN THE CATALYST ELECTRICITY MARKETPLACE ...... 68 FIGURE 26 - MARKET CLEARING IN THE CATALYST ELECTRICITY MARKETPLACE ...... 69 FIGURE 27 - MARKET CLEARING IN THE CATALYST FLEXIBILITY MARKETPLACE ...... 70 FIGURE 28 - DEPLOYMENT VIEW ...... 72 FIGURE 29 - CATALYST FINAL DATA MODEL (WITH ORANGE THE UPDATES BROUGHT) ...... 73
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
5
List of Tables
TABLE 1 - USE CASE S3.1: REQUEST AN IT LOAD MARKETPLACE ACCOUNT ...... 14 TABLE 2 - USE CASE S3.8: VIEW/UPDATE IT LOAD MARKETPLACE PARTICIPANT PROFILE ...... 14 TABLE 3 - USE CASE S3.7: CANCEL AN IT LOAD MARKETPLACE ACCOUNT ...... 15 TABLE 4 - USE CASE S3.9: VALIDATE NEW/UPDATED IT LOAD MARKETPLACE PARTICIPANT PROFILE ...... 15 TABLE 5 - USE CASE S3.10: VIEW HISTORY OF PARTICIPATION IN THE IT LOAD MARKETPLACE ...... 15 TABLE 6 - USE CASE S3.11: ACCESS IT LOAD MARKETPLACE SESSION RESULTS ...... 16 TABLE 7 - USE CASE S3.12: DEFINE DAY-AHEAD/INTRADAY IT LOAD MARKETPLACE SESSION ...... 16 TABLE 8 - INTRA DC ENERGY OPTIMIZER IDENTITY CARD ...... 20 TABLE 9 - SLA (RE)NEGOTIATION IDENTITY CARD ...... 22 TABLE 10 - ENERGY EFFICIENCY METRICS CALCULATOR IDENTITY CARD ...... 23 TABLE 11 - ELECTRICITY DR PREDICTION IDENTITY CARD ...... 24 TABLE 12 - HEAT DR PREDICTION IDENTITY CARD ...... 26 TABLE 13 - ENERGY CONTROL MANAGER IDENTITY CARD ...... 26 TABLE 14 - DC OPERATOR CONSOLE IDENTITY CARD ...... 27 TABLE 15 - MONITORING SYSTEM INTERFACE IDENTITY CARD ...... 28 TABLE 16 - SMART GRID CONNECTOR IDENTITY CARD ...... 29 TABLE 17 - DB API ...... 39 TABLE 18 - ENERGY AWARE IT LOAD BALANCER IDENTITY CARD ...... 40 TABLE 19 - ENERGY AWARE IT LOAD BALANCER CLIENT IDENTITY CARD ...... 42 TABLE 20 - FEDERATED DC IT LOAD MIGRATION CONTROLLER IDENTITY CARD ...... 44 TABLE 21 - VIRTUAL CONTAINER GENERATOR CLIENT IDENTITY CARD ...... 45 TABLE 22 - VIRTUAL CONTAINER GENERATOR SERVER IDENTITY CARD ...... 46 TABLE 23 - MARKETPLACE CONNECTOR IDENTITY CARD ...... 47 TABLE 24 - MAAS PLATFORM IDENTITY CARD ...... 48 TABLE 25 - INFORMATION BROKER IDENTITY CARD ...... 61 TABLE 26 - MARKET SESSION MANAGER IDENTITY CARD ...... 62 TABLE 27 - MARKET CLEARING MANAGER IDENTITY CARD ...... 63 TABLE 28 - ACCESS MANAGER IDENTITY CARD ...... 64 TABLE 29 - MULTI-ENERGY MARKET MANAGEMENT IDENTITY CARD ...... 65 TABLE 30 - CATALYST DEPLOYMENT REQUIREMENTS ...... 71 TABLE 31 - MAPPING OF SOFTWARE COMPONENTS INTO THE CATALYST NODES ...... 72
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
6
List of Acronyms
AM Access Manager
API Application Programming Interface
ASHRAE American Society of Heating, Refrigeration, and Air Conditioning Engineers
BREEAM Building Research Establishment Environmental Assessment Method
DB Data Base
DC Data Centre
DCIM Data Centre Infrastructure Management
DCMC Federated DC IT Load Migration Controller
DCMM Data Centre Maturity Model
DCSG Data Centre Specialist Group
DR Demand Response
DSO Distribution System Operator
EUCOC EU Code of Conduct for Data Centres (Energy Efficiency)
GDC Green Data Centre
GDC-SG Green Data Centre Stakeholder Group
HTTP HyperText Transfer Protocol
IB Information Broker
ICT Information and Communication Technology
ISO International Organization for Standardization
IT Information Technology
LB Energy Aware IT Load Balancer
LEED Leadership in Energy and Environmental Design
MaaS Market-as-a-Service
MDS Marketplace Data Storage
RES Renewable Energy Sources
SLA Service Level Agreement
SLO Service Level Objective
UML Unified Modelling Language
VAP Value-Added Plan
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
7
VC Virtual Container
VCG Virtual Container Generator vCMP Virtual Compute (server)
VM Virtual Machine
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
8
Executive Summary
This deliverable constitutes the CATALYST deliverable D2.3 “Final CATALYST Framework Architecture”.
Methodology of the initial architecture design followed state of the art review, definition of use-cases, requirements, and identification of key design principles, have been documented in the CATALYST report D2.1 “CATALYST Specification & Design” [1]. Of particular importance in requirements elicitation process was the Data Centre (DC) and energy domain knowledge and implementations gained in previous projects, such as GEYSER (Data Centres Optimization for Energy-Efficient and Environmentally Friendly Internet) [2] and DOLFIN (Data Centres Optimization for efficient and environmental friendly internet) [3], upon which the CATALYST proposal was built. The functional system requirements were prioritized and grouped into components that where coherently organized to provide the first version of the CATALYST framework architecture.
This document presents a refined and detailed version of the CATALYST framework architecture and updates on CATALYST data model, the initial version of which has been reported in D2.1 [1].
The CATALYST framework consists of three interacting sub-systems:
• The CATALYST DC-side group, responsible for improving the DC energy situational awareness and for improving constantly the DC energy efficiency, while exploiting their internal flexibility for providing energy services to “mutualised” power and heat energy grids, increasing resiliency and security of the power supply, and respecting or (re)negotiating Service-Level Agreements (SLAs); • The CATALYST Marketplace group, through which a DC can provide mutualised energy services; • The CATALYST DCs Federation group, responsible for orchestrating the workload relocation among federated DCs.
In this document:
• The functional blocks defined in D2.1 [1] are mapped in one or more CATALYST components, some of which were inherited fully or partly from the GEYSER [2] and DOLFIN projects [3]; • The identity card of each CATALYST component is given, including the interfaces provided and underlining possible dependencies; • The main CATALYST processes are detailed: to this end, sequence diagrams are used to describe the dynamic behaviour of the main processes (further details will be provided in the accompanying report of the prototypes); • A system deployment environment is suggested by mapping the software components onto the hardware; • Refinements and updates of the CATALYST data model that emerged from feedback of project tasks and developments after the submission of D2.1 [1] (where a first version of the CATALYST data model was presented) are reported.
Moreover, this report contains an update on the Green Data Centre Certification process and on the how the Consortium intends to evolve the CATALYST Green DC Assessment Toolkit, the first version of which was presented in D2.2-Green DC Assessment Toolkit [11].
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
9
1 Introduction
DCs are among the largest consumers of energy at global scale and their energy consumption is rapidly increasing due to the rising digitization of human activities. Over the last decade, DCs have made strides in successfully implementing energy efficient measures to reduce their energy and carbon footprint, while bringing down the related costs. Nevertheless, developments in integration of renewable energy sources to power grids, heat networks, and emerging energy services models provide fertile grounds for exploring further opportunity for DCs to interact with their local ecosystem and improve continuously their energy efficiency. Among other initiatives and projects, the EU FP7 GEYSER [2] and DOLFIN [3] projects have explored such opportunities and delivered technological and business proof of concepts to support the integration of DCs into the smart city ecosystem. Nevertheless, few such solutions have been deployed on operational DCs, mostly due to technological fragmentation, excessive CAPEX and lack of appropriate business models. Addressing these challenges, the CATALYST project aims to turn DCs into flexible multi- energy hubs, which can sustain investments in renewable energy sources and energy efficiency. Leveraging on results of the FP7 GEYSER [2] and DOLFIN [3] projects, CATALYST intends to adapt, scale up, deploy and validate an innovative technological and business framework that enables DCs to offer a range of mutualized energy flexibility services to both electricity and heat grids, while simultaneously increasing their own resiliency to energy supply.
This document provides details of the final version of the CATALYST framework architecture from both the static and dynamic behaviour point of view.
1.1 Intended Audience
The goal of this document is to communicate effectively the final architecture of the CATALYST framework to the members of the development team, as it will drive the efforts of the other technical WPs, as well as to the project stakeholders (DC Managers, Smart Energy City/District Managers, Marketplace Operators, and Distribution System Operators - DSOs), which could evaluate the adequacy of the CATALYST framework from the perspective of their individual areas of expertise, third-party developers, solution providers, wishing to adopt and extend the CATALYST developments. Moreover, DC Managers and technical staff could evaluate how the CATALYST framework can be integrated with the existing Information and Communication Technology (ICT) solutions.
Moreover, Advisory Board members of the project and the Green Data Centre Stakeholder Group may find in this report an understanding of the CATALYST framework technical details in order to provide their valuable feedback.
1.2 Relations to other activities
As it can be seen in Figure 1, WP2, and notably this deliverable D2.3, drives the efforts of the other technical WPs (WP3, WP4 and WP5) in the development and deployment of the CATALYST framework. Also, WP2 defines the CATALYST architecture which will provide the basis for integration of all technical components in a single near-commercial platform in WP6. D2.3 serves 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
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
10
Centre Stakeholder Group (GDC-SG) and the project’s advisory board, (WP6, WP7 and WP8) have been used for further refinements and improvements of the CATALYST specifications and design.
Figure 1 - WP2 relation with other work packages
1.3 Document overview
New uses cases with respect to the ones reported in D2.1 [1] are defined in chapter 2.
Chapter 3 describes the CATALYST architecture from the static and dynamic point of view. It includes the description of the software components, some of which have been inherited from the GEYSER [2] and DOLFIN projects [3], showing the interfaces provided and possible dependencies. The main CATALYST processes are detailed: to this end, sequence diagrams are used to describe the dynamic behaviour of the main processes. A system deployment environment is suggested by mapping the software components onto the hardware.
In chapter 4, refinements and updates of the CATALYST data model are included, as they emerged from feedback of project tasks and developments after the submission of D2.1 [1], where a first version of the data model was presented.
Chapter 5 concludes the document whereas Appendix A describes how the software implemented for the GEYSER Marketplace [2] has been enhanced for the CATALYST Marketplace.
Moreover, this report contains an update on the Green Data Centre Certification process and on the how the Consortium intends to evolve the CATALYST Green DC Assessment Toolkit in B.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
11
2 CATALYST use cases
This section reports use cases that have been identified after the release of D2.1 [1], where an initial set of use cases, and subsequently system requirements, have been derived from the seven visionary scenarios identified and grouped based on the main vertical functional macro tiers that the CATALYST framework may provide. The section 2.1 below is an update to section 5.3 Federated DCs Integration and IT Load Marketplace of D2.1 [1].
2.1 Federated DCs Integration and IT Load Marketplace
Figure 2 depicts the CATALYST IT Load Marketplace use cases diagram. Use cases that have been added to the ones already listed in D2.1 [1] have been highlighted in green.
The new use cases are detailed in Table 2, Table 3, Table 4, Table 5, Table 6, and Table 7 below.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
12
Figure 2 - CATALYST IT Load Marketplace use cases diagram
Use Case S3.1: Request an IT Load Marketplace account
In order to participate to the IT Load Marketplace, the DC Operator has to be a Brief Description registered user. Thus, the DC Operator requests an account. Parent Scenario 1, 4, 5, 7
Actor(s) DC Operator Priority High (must do) Trigger On demand. A DC Operator wishes to have an account so as to participate in the IT Load Marketplace. Pre-conditions The system is installed and active.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
13
Post-conditions The DC Operator requested an account for actively participating in the Flexibility Marketplace. Basic Flow Step 1: The DC Operator accesses the system and requests an account; Step 2: The DC Operator provides the profile information requested by the system; Step 3: The system sends a notification to the IT Load Marketplace Operator; Step 4: The DC Operator exits the system. Alternate Flow(s) Exception Flow(s)
Table 1 - Use Case S3.1: Request an IT Load Marketplace account
Use Case S3.8: View/Update IT Load Marketplace participant profile
Brief Description The IT Load Marketplace Participant wants to view/update their profile. Parent Scenario 3, 5, 7
Actor(s) DC Operator Priority High (must do) Trigger On demand. Pre-conditions The system is installed and active. The DC Operator has already an account. Post-conditions The DC Operator viewed/updated the profile. Basic Flow Step 1: The IT Load Marketplace Participant accesses the system with their account; Step 2: The IT Load Marketplace Participant views/updates their profile; Step 3: The system sends a notification to the IT Load Marketplace Operator; Step 4: The IT Load Marketplace Participant exits the system. Alternate Flow(s) N/A Exception Flow(s) N/A
Table 2 - Use Case S3.8: View/Update IT Load Marketplace participant profile
Use Case S3.7: Cancel an IT Load Marketplace account
The IT Load Marketplace Participant decides to cancel their registration to the IT Load Brief Description Marketplace. Parent Scenario 3, 5, 7
Actor(s) DC Operator (as IT Load Marketplace Participant) Priority High (must do) Trigger On demand. Pre-conditions The system is installed and active and the DC Operator has already an account. Post-conditions The DC Operator cancelled the registration to the marketplace. Basic Flow Step 1: The DC Operator accesses the system; Step 2: The DC Operator requests the cancellation of their account; Step 3: The DC Operator exits the system. Alternate Flow(s) N/A
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
14
Exception Flow(s) N/A
Table 3 - Use Case S3.7: Cancel an IT Load Marketplace account
Use Case S3.9: Validate new/updated IT Load Marketplace participant profile
The IT Load Marketplace Operator approves or rejects requests for account made by Brief Description a Marketplace Participant. Parent Scenario 3, 5, 7
Actor(s) IT Load Marketplace Operator Priority High (must do) Trigger The system notifies the IT Load Marketplace Operator that a DC Operator profile has been registered/updated Pre-conditions The system is installed and active. Post-conditions The DC Operator has got a login account and can actively participate in the IT Load Marketplace. Basic Flow Step 1: The IT Load Marketplace Operator accesses the system; Step 2: The IT Load Marketplace Operator validates the profile; Step 3: The system informs the DC Operator about the validation result; Step 4: The IT Load Marketplace Operator exits the system. Alternate Flow(s) N/A Exception Flow(s) N/A
Table 4 - Use Case S3.9: Validate new/updated IT Load Marketplace participant profile
Use Case S3.10: View history of participation in the IT Load Marketplace
The DC Operator wants to view the history of their participation to the Heat/Cold Brief Description Marketplace. Parent Scenario 3, 5, 7
Actor(s) DC Operator Priority High (must do) Trigger On demand. Pre-conditions The system is installed and active and the DC Operator has already an account for accessing the IT Load Marketplace. Post-conditions The DC Operator viewed their history. Basic Flow Step 1: The DC Operator accesses the system with their account; Step 2: The DC Operator accesses their history information; Step 3: The DC Operator exits the system. Alternate Flow(s) N/A Exception Flow(s) N/A
Table 5 - Use Case S3.10: View history of participation in the IT Load Marketplace
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
15
Use Case S3.11: Access IT Load Marketplace session results
At the end of the session, the market is cleared: all valid offers are put in increasing price order on an aggregate curve and all valid bids are put in decreasing price order on an aggregate curve. The intersection of the two curves determines the market Brief Description equilibrium, which gives the clearing price, at which all accepted bids and offers are remunerated, and the overall quantity of IT load traded in the session. The market session results are made available to the market participants. Parent Scenario 3, 5, 7
Actor(s) DC Operator Priority High (must do) Trigger A market session is closed. Pre-conditions The system is installed and active. The DC Operator has a login account. Post-conditions Market participants are informed about market session result. Basic Flow Step 1: The system clears the market; Step 2: The DC Operator accesses the system; Step 3: The DC Operator visualises market session results; Step 4: The DC Operator exits the system. Alternate Flow(s) N/A Exception Flow(s) N/A
Table 6 - Use Case S3.11: Access IT Load Marketplace session results
Use Case S3.12: Define Day-Ahead/Intraday IT Load Marketplace session
The IT Load Marketplace Operator defines timeframes during which bids/offer can be placed and be valid, referred to hereafter as market sessions. Market sessions can Brief Description be day-ahead/intraday and refers to a specific IT load delivery time period. While a market session is running, the IT Load buyers/sellers can place bids/offers. Parent Scenario 3, 5, 7
Actor(s) IT Load Marketplace Operator Priority High (must do) Trigger On demand. Pre-conditions The system is installed and active. The IT Load Marketplace Operator has a login account. Post-conditions Market sessions are scheduled. Basic Flow Step 1: The IT Load Marketplace Operator logs into the system; Step 2: The IT Load Marketplace Operator schedules the market sessions; Step 3: The IT Load Marketplace Operator exits the system. Alternate Flow(s) N/A Exception Flow(s) N/A
Table 7 - Use Case S3.12: Define Day-Ahead/Intraday IT Load Marketplace session
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
16
3 CATALYST framework architecture
This chapter presents the final CATALYST architecture, describing both the static and dynamic behaviour, and provides details on the software components.
3.1 Overview
The CATALYST Marketplace is part of the CATALYST Framework, whose block diagram is represented in Figure 3.
The CATALYST Framework consists of three interacting sub-systems:
• CATALYST DC-side, responsible for improving the DC energy situational awareness and for improving constantly the DC energy efficiency, while exploiting their internal flexibility for providing energy services to “mutualised” power and heat energy grids and increasing resiliency and security of the power supply; • CATALYST Marketplace, through which a DC can provide mutualised energy services; • CATALYST DCs Federation, responsible for orchestrating the workload relocation among federated DCs.
Figure 3 - CATALYST Framework Logical Architecture
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
17
The software components included in the CATALYST logical architecture are described in section 3.2.
3.2 Development View
This section provides details on each architectural component, in terms of general description, interfaces (expected input/provided output). In the next sub-sessions, the software components are grouped based on the three CATALYST interacting sub-systems described in 3.1.
3.2.1 Intra DC Energy Optimizer
The objective of the Intra DC Energy Optimizer is to decide on the optimization action plan that will allow the DC to exploit its latent energy flexibility to provide electricity flexibility services in its micro-grid, to re-use heat in nearby neighbourhoods, and finally to leverage on workload reallocation in other DCs as potential source of additional energy flexibility.
It uses (Figure 4) the thermal and electrical energy flexibility models defined for specific DC energy sub- systems (as defined in D4.1 “Smart Energy Flexibility Modelling” [4]) to identify the potential energy flexibility at individual sub-system level and to formalize the optimization problem as a constraint satisfaction problem. The inputs of the optimization component are the forecast energy consumption, production and flexibility at each individual sub system level as calculated by the Electrical and Heat DR Prediction components (will be delivered in D4.2 “DC Energy DR Prediction” due by M22) and the optimization goals configured by the DC Operator through the DC Operator Console (will be delivered in D4.3 “DC Energy Flexibility Management Tool” due by M26). The Intra DC Energy Optimizer will be delivered in D4.3 [5].
The component identity card is defined in Table 8.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
18
Figure 4 - Intra DC Optimiser Interaction with other components
Component Name Intra DC Energy Optimizer
Framework Sub-System CATALYST DC-side
Responsibility Determine action plans for DC operation optimization to exploit the latent thermal, electrical and workload relocation flexibility to provide various electricity flexibility and heat re-use services Provided Interfaces Optimization Strategy Setup
Description Through this interface, the weights corresponding to each aspect considered in the optimization objectives (electrical, thermal, IT load) will be set Provided to DC Operator Console End-point URL /optimization/weights Protocol used HTTP Allowed Methods POST Service to be Delivered Setup
Description Through this interface, the specific characters of the service that need to be delivered will be provided. It will be part of the optimization objective Provided to DC Operator Console End-point URL /optimization/targetService Protocol used HTTP Allowed Methods POST Optimization Action Plan Generation Notification
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
19
Description Through this interface, other components are notified that the optimization plan computation was finished, and they can get the action plan from the Data Storage Provided to DC Operator Console, IT Load Balancer, Energy Control Manager End-point URL /optimization/notify-plan Protocol used HTTP Allowed Methods GET Optimization Plan Computation
Description Through this interface, other components trigger the optimization plan computation with the target services and optimization weights already setup Provided to DC Operator Console End-point URL /optimization/compute Protocol used HTTP Allowed Methods GET Demand Response Plan Computation
Description Through this interface, other components trigger the optimization plan computation for responding to the DSO demand. Furthermore, it saves the DSO Target in the database using the DB API. Provided to DC Operator Console, Smart Grid Connector End-point URL /dsoDemand/{serviceType}/ Protocol used HTTP Allowed Methods POST Required Interfaces Retrieve Electrical Energy Consumption Prediction Retrieve Electrical Energy Production Prediction Retrieve Thermal Energy Production Prediction Retrieve Flexible Electrical Energy Prediction Retrieve Thermal Energy Flexibility Prediction Retrieve DC Optimization Actions Plan Retrieve DC Components Information Retrieve Historical Electrical Energy Consumption Data Retrieve Historical Electrical Energy Production Data Retrieve Historical Thermal Energy Production Data DC Component Information Insertion DC Actions Plan Insertion Provided by Data Storage and DB API Calculate Metric
Provided by Energy Efficiency Metrics Calculator Calculate Electrical Energy Consumption/Production/Flexibility Prediction
Provided by Electricity DR Prediction Calculate Thermal Energy Generation/Flexibility Prediction
Provided by Heat DR Prediction Table 8 - Intra DC Energy Optimizer Identity Card
3.2.2 SLA (re)negotiation
Taking up the relevant work performed in the context of the FP7 DOLFIN project [3], the SLA (re)negotiation component is responsible for interacting with the Virtual Container Generator (in short VCG, see paragraph 3.2.13) in order to keep track of the Service Level Agreement (SLA) status of the identified IT loads (see paragraph 3.2.13 and deliverable D3.1 [6] for details on tracking the IT loads across the CATALYST DC
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
20
Federation in a unique manner). Figure 5, presents a high-level overview of the interactions of the SLA (re)negotiation component.
Figure 5 - High-level SLA (re)negotiation interactions
In short, the Virtual Container Generator client will offer information related to the lifetime of the VCs, which will be, first, translated by the SLA (re)negotiation component into service licence objective (SLO) events and, next, into SLA status compliance. This information will be fed to the Energy Aware IT Load Balancer component (see paragraph 3.2.11) so that effective decisions on VC load migrations may be achieved. Notably, the SLA (re)negotiation component will feature two methods of information retrieval, that is both RESTful and publish subscribe, while for data feeding, pull requests towards the Virtual Container Generator will be performed. More information on the SLA (re)negotiation component will be provided in CATALYST deliverable D3.3.
The following Table 9 summarizes the core RESTful interfaces exposed by Virtual Container Generator (client and server).
Component Name SLA (re)negotiation
Framework Sub-System CATALYST DC-side
Responsibility Keeps track of the SLAs of VCs of the DCs.
Provided Interfaces Get the SLA status of a VC
Description Synchronously gets the SLA status of a particular VC tag Provided to Energy-Aware IT Load Balancer End-point URL /api/vc/{vc_tag}/status Protocol used HTTP Allowed Methods GET Register for updates
Description Allows instances of the Energy-Aware IT Load Balancer to register for asynchronous updates by the SLA (re)negotiation component over SLA statuses Provided to Energy-Aware IT Load Balancer End-point URL /api/vc/{vc_tag}/register Protocol used HTTP Allowed Methods POST Get an SLO of a VC
Description Emits SLO events to be consumed by the Energy-Aware IT Load Balancer. Provided to Energy-Aware IT Load Balancer End-point URL [Topic] /vc/{vc_tag}/slo/{slo} Protocol used Publish/Subscribe Allowed Methods N/A
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
21
Required Interfaces No interfaces required
Table 9 - SLA (re)negotiation Identity Card
3.2.3 Energy Efficiency Metrics Calculator
This component aims to calculate different metrics in close relation with decided optimization plans aiming to assess their impact onto the DC operation (Figure 6). The metrics are selected from the ones proposed in the Green Data Centre Assessment Toolkit and refer mainly to Adaptability Power Curve at RES, Data Centre Adapt, Grid Utilization Factor, Energy Reuse Factor, etc. The component will be delivered in D4.3.
The component identity card is defined in Table 10.
Figure 6 - Intra DC Optimizer interactions with other CATALYST components
Component Name Energy Efficiency Metrics Calculator
Framework Sub-System CATALYST DC-side
Responsibility Calculates different metrics for assessing the impact of the optimization action plan onto the DC operation
Provided Interfaces Calculate Metric
Description Determines the value of a specific metric on demand Provided to Intra DC Energy Optimizer, DC Operator Console End-point URL /metricsCalculator/{metric} Protocol used HTTP Allowed Methods GET Required Interfaces Retrieve DC Optimization Actions Plan Retrieve Historical Electrical Energy Consumption Data Retrieve Historical Electrical Energy Production Data Retrieve Historical Thermal Energy Production Data
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
22
Provided by Data Storage and DB API Table 10 - Energy Efficiency Metrics Calculator Identity Card
3.2.4 Electricity DR Prediction
This component provides forecast DC energy consumption, generation and flexibility both at aggregated level but also at individual sub-system level. It implements the forecasting of electrical loads at the following time scales as well: day ahead (24 hours ahead), intraday (4 hours ahead) and near real time (1 hour ahead). It implements a prediction infrastructure (Figure 7) able to deal with large amounts of energy data generated by the DC monitoring systems and stored in the CATALYST Data Storage (developed using a high availability database) on top of which ensemble based deep neural network prediction models had been developed and used. The component will be delivered in D4.2. The component identity card is defined in Table 11.
Figure 7 - Electricity DR Prediction interactions with other CATALYST components
Electricity DR Prediction
Framework Sub-System CATALYST DC-side
Responsibility Forecast DC energy demand, generation, and flexibility at each individual sub-system level and also aggregated at DC level.
Provided Interfaces Electrical Energy Consumption/Production/Flexibility Prediction
Description Through this interface, other components may trigger the electrical energy consumption/production/flexibility predictions for a specific DC system (datacenter, IT Servers,
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
23
Cooling System etc.) at various time granularities {Day-ahead, intra-day, near real time} Provided to Intra DC Energy Optimizer, DC Operator Console End-point URL /electrical/prediction/{prediction- type}/{granularity}/{dataCenterID}/ entireDC/{startTime}/{endTime}
/electrical/prediction/{prediction- type}/{granularity}/{dataCenterID}/ {component- type}/{component-id}/{startTime}/{endTime}
/electrical/prediction/{prediction- type}/{granularity}/{dataCenterID}/ {component- type}/{component-id}/{startTime}/{endTime}
/electrical/prediction/{prediction- type}/{granularity}/{dataCenterID}/ {component- type}/{component-id}/{startTime}/{endTime} Protocol used HTTP Allowed Methods GET Required Interfaces Retrieve DC Components Information Retrieve Historical Electrical Energy Consumption Data Retrieve Historical Electrical Energy Production Data Electrical Energy Consumption Prediction Insertion Electrical Energy Production Prediction Insertion Provided by Data Storage and DB API Table 11 - Electricity DR Prediction Identity Card
3.2.5 Heat DR Prediction
This component aims to forecast the amount of waste heat available to be re-used in nearby neighbourhoods (Figure 8). It leverages on Computational Fluid Dynamics simulations to estimate the temperature of the hot air recovered by the heat pumps from the server room in various configurations. The generated data are used to train thermal prediction model based on Multi-Layer Perceptron neural network to forecast the amount of heat to be reused. The identity card of the component is defined in Table 12.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
24
Figure 8 - Electricity DR Preiction interactions with other components
Heat DR Prediction
Framework Sub-System CATALYST DC-side Responsibility This component aims to forecast the amount of waste heat and thermal energy flexibility available to be exploited and re-used in nearby neighbourhoods
Provided Interfaces Thermal Energy Generation/Flexibility Prediction
Description Through this interface, other components may trigger the thermal energy generation/flexibility predictions for a specific DC system (datacenter, IT Servers, Cooling System etc.) at various time granularities {Day-ahead, intra-day, near real time} Provided to Intra DC Energy Optimizer, DC Operator Console End-point URL /thermal/prediction/{prediction- type}/{granularity}/{dataCenterID}/ entireDC/{startTime}/{endTime}
/thermal/prediction/{prediction- type}/{granularity}/{dataCenterID}/{component- type}/{component-id}/{startTime}/{endTime}
/thermal/prediction/{prediction- type}/{granularity}/{dataCenterID}/{component- type}/{component-id}/{startTime}/{endTime}
/thermal/prediction/{prediction- type}/{granularity}/{dataCenterID}/{component- type}/{component-id}/{startTime}/{endTime} Protocol used HTTP Allowed Methods GET
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
25
Required Interfaces Thermal Energy Generation Prediction Insertion DC Components Information Retrieval Retrieve Historical Thermal Energy Production Data Provided by Data Storage and DB API Table 12 - Heat DR Prediction Identity Card
3.2.6 Energy Control Manager
This component interfaces the DC appliances and local renewable energy sources (RES) via existing data centre infrastructure management system (DCIM), or other control systems (e.g., OPC server), implements, and executes the optimization action plans.
Energy Control Manager
Framework Sub-System CATALYST DC-side
Responsibility Interfaces the DC appliances and local RES, implements, and executes the optimization action plans
Provided Interfaces N/A
Required Interfaces N/A
Table 13 - Energy Control Manager Identity Card
3.2.7 DC Operator Console
This component is responsible for displaying relevant information for the DC Operator concerning the electrical and thermal energy forecasting process as well as on flexibility optimization decision making. Moreover, it will allow the DC operator to select and validate an optimization plan and to configure the DC optimization goals/strategies. It will be delivered in D4.3 together with the Intra DC Energy Optimizer.
The interfaces used by the component are listed in Table 14.
DC Operator Console
Framework Sub-System CATALYST DC-side
Responsibility Web interface showing relevant information to the DC Operator and allowing it to configure optimization goals and validate optimization action plans
Required Interfaces Retrieve Electrical Energy Consumption Prediction Retrieve Electrical Energy Production Prediction Retrieve Thermal Energy Production Prediction Retrieve Flexible Electrical Energy Prediction Retrieve Thermal Energy Flexibility Prediction Retrieve DC Optimization Actions Plan Retrieve DC Components Information Retrieve Historical Electrical Energy Consumption Data
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
26
Retrieve Historical Electrical Energy Production Data Retrieve Historical Thermal Energy Production Data DC Component Information Insertion Provided by Data Storage and DB API Optimization Strategy Setup Service to be Delivered Setup Optimization Action Plan Generation Notification Optimization Plan Computation Provided by Intra DC Energy Optimiser Calculate Metric
Provided by Energy Efficiency Metrics Calculator Electrical Energy Consumption/Production/Flexibility Prediction
Provided by Electricity DR Prediction Thermal Energy Generation/Flexibility Prediction
Provided by Heat DR Prediction Table 14 - DC Operator Console Identity Card
3.2.8 Monitoring System Interface
This component interfaces with existing monitoring systems already installed in a DC, adapts the monitoring data received periodically, and provides this data to the data storage through the DB API (Figure 9). Further details will be provided in next CATALYST reports.
Figure 9 - Monitoring System Interface interactions with other CATALYST components (in green)
Monitoring System Interface
Framework Sub-System CATALYST DC-side
Responsibility This component interfaces with existing monitoring systems already installed in a DC.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
27
Provided Interfaces N/A
Required Interfaces CATALYST DB API, interfaces provided by the monitoring systems, interfaces provided by custom protocol adapters Table 15 - Monitoring System Interface Identity Card
3.2.9 Smart Grid Connector
The Smart Grid Connector is the interface component towards the Smart Grid. It is responsible for listening Demand Response (DR) signals sent by the Distribution System Operator (DSO) for reducing the Data Centre energy consumption at critical times or in response to market prices. This component is an OpenADR controller to simulate the interface of DC with Electricity Smart Grids. The DR request is forwarded to the Intra DC Energy Optimiser, which evaluates the possibility for the DC to opt in the request from the DSO on the basis of the optimisation criteria.
Figure 10 - Smart Grid Connector interactions with other CATALYST components
SGC interaction with other CATALYST modules is presented in Figure 10
Smart Grid Connector
Framework Sub-System CATALYST DC-side
Responsibility Bi-directional Interface with the Smart Grid/Smart City for the provision of DR services. Internal Interfaces getOadrEvent provided by the Demand Response Adapter Description Through this interface, the Demand Response Adapter gets an OpenADR event from the queue managed by the OpenADR VEN client. Provided to OpenADR VEN End-point URL openAdrVen/oadrDistributeEvent/{marketcontext}/next Protocol used HTTP Allowed Methods GET postOadrCreatedEvent
Description Through this interface, the Demand Response Adapter posts a DR event to the OpenADR VEN client. Provided to OpenADR VEN End-point URL openAdrVen/oadrCreatedEvent/{marketContext} Protocol used HTTP Allowed Methods POST getOadrReportRequest
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
28
Description Through this interface, the Demand Response Adapter gets an OpenADR report request from the queue managed by the OpenADR VEN client. Provided to OpenADR VEN End-point URL oadrCreateReport/{marketContext}/next Protocol used HTTP Allowed Methods GET postOadrUpdateReport Description Through this interface, the Demand Response Adapter posts an OpenADR report to the OpenADR VEN client. Provided to OpenADR VEN End-point URL /openAdrVen/oadrUpdateReport/ Protocol used HTTP Allowed Methods POST Required Interfaces DC DSO Target Retrieval for Demand Response
Provided by Intra DC Energy Optimizer Table 16 - Smart Grid Connector Identity Card
3.2.10 Data Storage and DB API
This component implements the CATALYST data model and stores the following type of data: DC main sub- system characteristics, thermal and energy monitored data, prediction outcomes and optimization action plans. Updated description of the data model can be found in section 6. The data base (DB) application programming interface (API) defined on top is a REST API allowing other components to extract and save relevant data in the Data Storage (Table 17).
DB API
Framework Sub- CATALYST DC-side System Responsibility Store information relevant for the DC optimization processes
Provided Interfaces Retrieve Electrical Energy Consumption Prediction
Description Through this interface, other components may retrieve {day-ahead (24 hours ahead), intra-day (4 hours ahead), near real time (1 hour ahead) electrical energy consumption predictions for a specific sub-system or for the entire DC. Provided to Intra DC Energy Optimizer, DC Operator Console End-points URL /electrical/prediction/consumption/dayahead/{dataCenterID}/entire DC/{startTime}
/electrical/prediction/consumption/dayahead/{dataCenterID}/itCom ponent/{startTime}
/electrical/prediction/consumption/dayahead/{dataCenterID}/coolin gSystem/{startTime}
/electrical/prediction/consumption/dayahead/{dataCenterID}/serve r/{serverID}/{startTime}
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
29
/electrical/prediction/consumption/intraday/{dataCenterID}/entireD C/{startTime}
/electrical/prediction/consumption/intraday/{dataCenterID}/itComp onent/{startTime}
/electrical/prediction/consumption/intraday/{dataCenterID}/cooling System/{startTime}
/electrical/prediction/consumption/intraday/{dataCenterID}/server/ {serverID}/{startTime}
/electrical/prediction/consumption/nearRealTime/{dataCenterID}/e ntireDC/{startTime}
/electrical/prediction/consumption/nearRealTime/{dataCenterID}/it Component/{startTime}
/electrical/prediction/consumption/nearRealTime/{dataCenterID}/c oolingSystem/{startTime}
/electrical/prediction/consumption/nearRealTime/{dataCenterID}/s erver/{serverID}/{startTime} Protocol used HTTP Allowed Methods GET Retrieve Electrical Energy Production Prediction
Description Through this interface, other components may retrieve {day-ahead (24 hours ahead), intra-day (4 hours ahead), near real time (1 hour ahead) electrical energy production predictions for a specific sub-system or for the entire DC. Provided to Intra DC Energy Optimizer, DC Operator Console End-point URL /electrical/prediction/production/dayahead/{dataCenterID}/entireD C/{startTime}
/electrical/prediction/production/intraday/{dataCenterID}/entireDC/ {startTime}
/electrical/prediction/prodcution/nearRealTime/{dataCenterID}/enti reDC/{startTime}
Protocol used HTTP Allowed Methods GET Retrieve Thermal Energy Production Prediction
Description Through this interface, other components may retrieve {day-ahead (24 hours ahead), intra-day (4 hours ahead), near real time (1 hour ahead) heat production predictions for a specific sub-system or for the entire DC Provided to Intra DC Energy Optimizer, DC Operator Console End-point URL /thermal/prediction/production/dayahead/{dataCenterID}/entireDC /{startTime}
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
30
/thermal/prediction/production/dayahead/{dataCenterID}/itCompon ent/{startTime}
/thermal/prediction/production/dayahead/{dataCenterID}/coolingSy stem/{startTime}
/thermal/prediction/production/dayahead/{dataCenterID}/server/{s erverID}/{startTime}
/thermal/prediction/production/intraday/{dataCenterID}/entireDC/{ startTime}
/thermal/prediction/production/intraday/{dataCenterID}/itCompone nt/{startTime}
/thermal/prediction/production/intraday/{dataCenterID}/coolingSys tem/{startTime}
/thermal/prediction/production/intraday/{dataCenterID}/server/{ser verID}/{startTime}
/thermal/prediction/production/nearRealTime/{dataCenterID}/entir eDC/{startTime}
/thermal/prediction/production/nearRealTime/{dataCenterID}/itCo mponent/{startTime}
/thermal/prediction/production/nearRealTime/{dataCenterID}/cooli ngSystem/{startTime}
/thermal/prediction/production/nearRealTime/{dataCenterID}/serve r/{serverID}/{startTime} Protocol used HTTP Allowed Methods GET Retrieve Flexible Electrical Energy Prediction
Description Through this interface, other components may retrieve {day-ahead (24 hours ahead) and intra-day (4 hours ahead)} electrical energy flexibility predictions for a specific sub-system or for the entire DC Provided to Intra DC Energy Optimizer, DC Operator Console End-points URL /electrical/prediction/flexibility- above/dayahead/{dataCenterID}/entireDC/{startTime}
/electrical/prediction/flexibility- below/dayahead/{dataCenterID}/entireDC/{startTime}
/electrical/prediction/felxibility- above/dayahead/{dataCenterID}/itComponent/{startTime}
/electrical/prediction/felxibility- below/dayahead/{dataCenterID}/itComponent/{startTime}
/electrical/prediction/felxibility- above/dayahead/{dataCenterID}/coolingSystem/{startTime}
/electrical/prediction/felxibility- below/dayahead/{dataCenterID}/coolingSystem/{startTime}
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
31
/electrical/prediction/flexibility- above/dayahead/{dataCenterID}/server/{serverID}/{startTime}
/electrical/prediction/flexibility- below/dayahead/{dataCenterID}/server/{serverID}/{startTime}
/electrical/prediction/flexibility- above/intraday/{dataCenterID}/entireDC/{startTime}
/electrical/prediction/flexibility- below/intraday/{dataCenterID}/entireDC/{startTime}
/electrical/prediction/flexibility- above/intraday/{dataCenterID}/itComponent/{startTime}
/electrical/prediction/flexibility- below/intraday/{dataCenterID}/itComponent/{startTime}
/electrical/prediction/flexibility- above/intraday/{dataCenterID}/coolingSystem/{startTime}
/electrical/prediction/flexibility- below/intraday/{dataCenterID}/coolingSystem/{startTime}
/electrical/prediction/flexibility- above/intraday/{dataCenterID}/server/{serverID}/{startTime}
/electrical/prediction/flexibility- below/intraday/{dataCenterID}/server/{serverID}/{startTime} Protocol used HTTP Allowed Methods GET Retrieve Thermal Energy Flexibility Prediction
Description Through this interface, other components may retrieve {day-ahead (24 hours ahead) and intra-day (4 hours ahead)} electrical energy flexibility predictions for a specific sub-system or for the entire DC Provided to Intra DC Energy Optimizer, DC Operator Console End-points URL /thermal/prediction/flexibility- above/dayahead/{dataCenterID}/entireDC/{startTime}
/thermal/prediction/flexibility-below/ dayahead/{dataCenterID}/entireDC/{startTime}
/thermal/prediction/flexibility- above/dayahead/{dataCenterID}/itComponent/{startTime}
/thermal/prediction/flexibility-below/ dayahead/{dataCenterID}/itComponent/{startTime}
/thermal/prediction/flexibility- above/dayahead/{dataCenterID}/coolingSystem/{startTime}
/thermal/prediction/flexibility- below/dayahead/{dataCenterID}/coolingSystem/{startTime}
/thermal/prediction/flexibility- above/dayahead/{dataCenterID}/server/{serverID}/{startTime}
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
32
/thermal/prediction/flexibility- below/dayahead/{dataCenterID}/server/{serverID}/{startTime}
/thermal/prediction/flexibility- above/intraday/{dataCenterID}/entireDC/{startTime}
/thermal/prediction/flexibility-below/ intraday/{dataCenterID}/entireDC/{startTime}
/thermal/prediction/flexibility- above/intraday/{dataCenterID}/itComponent/{startTime}
/thermal/prediction/flexibility-below/ intraday/{dataCenterID}/itComponent/{startTime}
/thermal/prediction/flexibility- above/intraday/{dataCenterID}/coolingSystem/{startTime}
/thermal/prediction/flexibility- below/intraday/{dataCenterID}/coolingSystem/{startTime}
/thermal/prediction/flexibility- above/intraday/{dataCenterID}/server/{serverID}/{startTime}
/thermal/prediction/flexibility- below/intraday/{dataCenterID}/server/{serverID}/{startTime} Protocol used HTTP Allowed Methods GET Retrieve DC Optimization Actions Plan
Description Through this interface, other components may retrieve information related to different actions that can be taken for energy optimization inside a DC. Provided to Intra DC Energy Optimizer, DC Operator Console, Energy Efficiency Metrics Calculator End-point URL /action/shiftWorkload/{dataCenterID}/{startTime}/{endTime}
/action/chargeBattery/{dataCenterID}/{startTime}/{endTime}
/action/dischargeBattery/{dataCenterID}/{startTime}/{endTime}
/action/chargeTES/{dataCenterID}/{startTime}/{endTime} Protocol used HTTP Allowed Methods GET Retrieve DC Components Information
Description Through this interface, other components may retrieve information related to different measures defined for several DC modeled subsystems: DC, IT Server, Cooling System, etc. Provided to Intra DC Energy Optimizer, DC Operator Console, Heat DR Prediction, Electricity DR Prediction End-point URL /measure/{dataCenterID}/entireDC
/measure/{dataCenterID}/itComponent
/measure/{dataCenterID}/rack/{rackID}
/measure/{dataCenterID}/server/{serverID}
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
33
/measure/{dataCenterID}/vm/{vmID}
/measure/{dataCenterID}/cooling-system/{coolingSystemID}
/measure/{dataCenterID}/battery/{batteryID}
/measure/{dataCenterID}/heat-pump/{heatPumpID} Protocol used HTTP Allowed Methods GET Retrieve Historical Electrical Energy Consumption Data
Description Through this interface, other components may retrieve information related to historical monitored electrical energy per relevant sub- system and for DC as a whole for different time granularities {24 hours before, 4 hours before, 1 hour before} Provided to Intra DC Energy Optimizer, DC Operator Console, Electricity DR Prediction, Energy Efficiency Metrics Calculator End-point URL /electrical/history/monitored-values/consumption/24hoursbefore/ {dataCenterID}/entireDC/{startTime}
/electrical/history/monitored-values/consumption/24hoursbefore/ {dataCenterID}/itComponent/{startTime}
/electrical/history/monitored-values/consumption/24hoursbefore/ {dataCenterID}/coolingSystem/{startTime}
/electrical/history/monitored-values/consumption/24hoursbefore/ {dataCenterID}/ server/{serverID}/{startTime}
/electrical/history/monitored-values/consumption/4hoursbefore/ {dataCenterID}/entireDC/{startTime}
/electrical/history/monitored-values/consumption/4hoursbefore/ {dataCenterID}/itComponent/{startTime}
/electrical/history/monitored-values/consumption/4hoursbefore/ {dataCenterID}/coolingSystem/{startTime}
/electrical/history/monitored-values/consumption/4hoursbefore/ {dataCenterID}/ server/{serverID}/{startTime}
/electrical/history/monitored-values/consumption/1hourbefore/ {dataCenterID}/entireDC/{startTime}
/electrical/history/monitored-values/consumption/1hourbefore/ {dataCenterID}/itComponent/{startTime}
/electrical/history/monitored-values/consumption/1hourbefore/ {dataCenterID}/coolingSystem/{startTime}
/electrical/history/monitored-values/consumption/1hourbefore/ {dataCenterID}/ server/{serverID}/{startTime} Protocol used HTTP Allowed Methods GET Retrieve Historical Electrical Energy Production Data
Description Through this interface, other components may retrieve information related to historical monitored electrical energy production per
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
34
relevant sub-system and for DC as a whole for different time granularities {24 hours before, 4 hours before, 1 hour before} Provided to Intra DC Energy Optimizer, DC Operator Console, Electricity DR Prediction, Energy Efficiency Metrics Calculator End-point URL /electrical/history/monitored-values/production/24hoursbefore/ {dataCenterID}/entireDC/{startTime}
/electrical/history/monitored-values/production/4hoursbefore/ {dataCenterID}/entireDC/{startTime}
/electrical/history/monitored-values/production/1hourbefore/ {dataCenterID}/entireDC/{startTime}
Protocol used HTTP Allowed Methods GET Retrieve Historical Thermal Energy Production Data
Description Through this interface, other components may retrieve information related to historical monitored thermal energy generation per relevant sub-system and for DC as a whole for different time granularities {24 hours before, 4 hours before, 1 hour before} Provided to Intra DC Energy Optimizer, DC Operator Console, Heat DR Prediction, Energy Efficiency Metrics Calculator End-point URL /thermal/history/monitored-values/production/24hoursbefore/ {dataCenterID}/entireDC/{startTime}
/thermal/history/monitored-values/production/24hoursbefore/ {dataCenterID}/itComponent/{startTime}
/thermal/history/monitored-values/production/24hoursbefore/ {dataCenterID}/coolingSystem/{startTime}
/thermal/history/monitored-values/production/24hoursbefore/ {dataCenterID}/ server/{serverID}/{startTime}
/thermal/history/monitored-values/production/4hoursbefore/ {dataCenterID}/entireDC/{startTime}
/thermal/history/monitored-values/production/4hoursbefore/ {dataCenterID}/itComponent/{startTime}
/thermal/history/monitored-values/production/4hoursbefore/ {dataCenterID}/coolingSystem/{startTime}
/thermal/history/monitored-values/production/4hoursbefore/ {dataCenterID}/ server/{serverID}/{startTime}
/thermal/history/monitored-values/production/1hourbefore/ {dataCenterID}/entireDC/{startTime}
/thermal/history/monitored-values/production/1hourbefore/ {dataCenterID}/itComponent/{startTime}
/thermal/history/monitored-values/production/1hourbefore/ {dataCenterID}/coolingSystem/{startTime}
/thermal/history/monitored-values/production/1hourbefore/ {dataCenterID}/ server/{serverID}/{startTime}
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
35
Protocol used HTTP Allowed Methods GET Electrical Energy Consumption Prediction Insertion
Description Through this interface, other CATALYST components may insert the electrical energy consumption predictions computed over {day-ahead, intra-day, near real time} time intervals and different system level granularities. Provided to Electricity DR Prediction End-point URL /electrical/prediction/consumption/{dataCenterID}/entireDC
/electrical/prediction/consumption/{dataCenterID}/itComponent
/electrical/prediction/consumption/{dataCenterID}/coolingSystem
/electrical/prediction/consumption/{dataCenterID}/server/{serverID } Protocol used HTTP Allowed Methods POST Electrical Energy Production Prediction Insertion
Description Through this interface, other CATALYST components may insert the electrical energy production predictions computed over {day-ahead, intra-day, near real time} time intervals and different system level granularities. Provided to Electricity DR Prediction End-point URL /electrical/prediction/production/{dataCenterID}/entireDC/ Protocol used HTTP Allowed Methods POST Thermal Energy Generation Prediction Insertion
Description Through this interface, other CATALYST components may insert the thermal energy generation predictions computed over {day-ahead, intra-day, near real time} time intervals and different system level granularities. Provided to Heat DR Prediction End-point URL /thermal/prediction/{dataCenterID}/entireDC
/ thermal/prediction/{dataCenterID}/itComponent
/ thermal/prediction/{dataCenterID}/coolingSystem
/ thermal/prediction/{dataCenterID}/server/{serverID} Protocol used HTTP Allowed Methods POST Monitored Values Insertion
Description Through this interface, other components will insert the monitored data collected from various sensors dispatched in the DC environment. Provided to Monitoring System Interface End-point URL /monitored/value Protocol used HTTP Allowed Methods POST DC Component Information Insertion
Description Through this interface, other components are able to configure DC sub- systems characteristics at different levels: DC, IT Servers, Cooling System, etc.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
36
Provided to Intra DC Energy Optimizer, DC Operator Console End-point URL /measure/{dataCenterID}/entireDC
/measure/{dataCenterID}/ITcomponent
/measure/{dataCenterID}/rack/{rackID}
/measure/{dataCenterID}/server/{serverID}
/measure/{dataCenterID}/vm/{vmID}
/measure/{dataCenterID}/cooling-system/{coolingSystemID}
/measure/{dataCenterID}/battery/{batteryID}
/measure/{dataCenterID}/heat-pump/{heatPumpID} Protocol used HTTP Allowed Methods POST DC Actions Plan Insertion
Description Through this interface, other components can insert actions related to energy optimization inside a DC. Provided to Intra DC Energy Optimizer End-point URL /action/plan/{dataCenterID}/{startTime}/{endTime} Protocol used HTTP Allowed Methods POST DC DSO Target Insertion for Demand Response
Description Through this interface, other components can insert the targets of the Demand Response Services and save the estimated adapted profile. Provided to Intra DC Energy Optimizer End-point URL /demand-response/target/insert/ Protocol used HTTP Allowed Methods POST DC DSO Target Retrieval for Demand Response
Description Through this interface, other components can retrieve the targets of the Demand Response Services and the estimated adapted profile. Provided to Intra DC Energy Optimizer End-point URL /demand-response/target/retrieve/ Protocol used HTTP Allowed Methods GET Get Authentication token Description Gets an authentication token to interact with the DB API. Provided to IT Load Balancer End-point URL /api/tokens/ Protocol used HTTP Allowed Methods POST Information on DC elements Description Inserts, retrieves, deletes, updates information related to the DC infrastructure (rooms, racks, cooling-systems, lighting infrastructure, network elements and servers) Provided to IT Load Balancer
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
37
End-point URL /api/rooms/ /api/rooms/{room_id}/
/api/racks/ /api/racks/{rack_id}/
/api/cooling/ /api/cooling/{cooling_system_id}/ /api/cooling/by-room/{room_id}/
/api/lighting/ /api/lighting/{lighting_system_id}/
/api/network_elements/ /api/network_elements/{element_id}/ /api/network_elements/by-type/{element_type}/ /api/network_element_types/ /api/network_element_types/{element_type_id}/
/api/servers/ /api/servers/{serial_number}/ /api/servers/by-cooling-system/{cooling_system_id}/ /api/servers/by-energy-efficiency/sorted/
Protocol used HTTP Allowed Methods POST, GET, PUT, DELETE Information on IT loads Description Gets information related to IT loads Provided to IT Load Balancer End-point URL /api/itl/ /api/itl/{uuid}/ /api/itl/by-server/{serial_number}/ /api/itl/by-vcTag/{vcTag}/
/api/flavours/ /api/flavours/{id}/
Protocol used HTTP Allowed Methods POST, GET, PUT, DELETE Information on IT loads-related measurements Description Gets information related to IT loads measurements Provided to IT Load Balancer End-point URL /api/measurement_types/ /api/measurement_types/{mearument_type_id}/
/api/measurements/ /api/measurements/{measurement_id}/ /api/measurements/by-type/{measurement_type}/
/api/measurements/by- type/{measurement_type}/{start_time}/{end_time}/
/api/measurements/by-type- resource/{measurement_type}/{resource_type}/
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
38
/api/measurements/by-type- resource/{measurement_type}/{resource_type}/{resource_id}/
/api/measurements/by-type- resource/{measurement_type}/{resource_type}/{resource_id}/{start_ time}/
/api/measurements/by-type- resource/{measurement_type}/{resource_type}/{resource_id}/{start_ time}/{end_time}/
/api/measurements/by-type- resource/{measurement_type}/{resource_type}/{resource_id}/{start_ time}/{end_time}/interval/{inter}
/api/measurements/by-resource/{resource_type}/
/api/measurements/by-resource/{resource_type}/{resource_id}/ /api/measurements/by- resource/{resource_type}/{resource_id}/{start_time}/{end_time}/
/api/measurements/aggregate/power/{measurement_type}/{time}/ /api/measurements/aggregate/energy/{measurement_type}/{start_ time}/{end_time}/ Protocol used HTTP Allowed Methods POST, GET
Table 17 - DB API
3.2.11 Energy Aware IT Load Balancer
At the federation level, the Energy Aware IT Load Balancer role is to perform the IT Load Marketplace clearing by optimising IT loads placement. This optimisation is based on Knap Sack algorithm, combined with Branch and Bound techniques. The goal is to place IT loads in DCs offering capacity in the most efficient way. Explained differently, the Energy Aware IT Load Balancer will define the actual IT loads relocation plan based on the offers and bids placed on the IT Load Marketplace to ensure the efficient application and completeness of the Intra DC Energy Optimiser plan. The Energy Aware IT Load Balancer will be integrated in the CATALYST Marketplace in the second version of the CATALYST Marketplace prototype as deliverable D5.2. This component is also in charge of actually triggering the relocation through the Federated DC IT Load Migration Controller.
The interactions of the Energy Aware IT Load Balancer with the other CATALYST software components are depicted in Figure 11; details are provided in Table 18. The effective operation of this component is being detailed in the deliverable D3.2 planned for delivery at month M20, i.e. May 2019.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
39
CATALYST DCs FEDERATION CATALYST MARKETPLACE Federated DC IT Load Virtual Container Energy aware IT Migration Controller Generator Load Balancer MaaS Platform
Energy Marketplace CATALYST DC- SIDE Flexibility Marketplace Heat Marketplace Federation Market Participation IT Load Marketplace
Virtual Container Energy aware IT Load Generator Client Balancer Client Access Manager
Federated DC IT Load Optimisation Market Migration Market Session Clearing Controller Manager DC Operator Intra DC Energy SLA Client Manager Console Optimiser (re)negotiation
Energy Marketplace Information Broker Efficiency Heat DR ElectricityDR Connector Metrics Prediction Prediction Access IB Marketplace Calculator Control API Data Storage
DB API Smart Grid Connector Energy Monitoring IT & Energy Control Data Storage System Supervisor Interface Manager Multi-energy Market Management
Figure 11 - Energy Aware IT Load Balancer interactions with other CATALYST components
Energy Aware IT Load Balancer
Framework Sub-System CATALYST DCs FEDERATION
Responsibility The role of this component is to actually optimise IT load placement according to offers and bids placed on the IT Load Marketplace.
Provided Interfaces Post clearing request Description Send IT load relocation offers and bids for the load balancer to decide upon an assignation Provided to Information Broker End-point URL /clearingRequest Protocol used HTTP Allowed Methods POST Required Interfaces ActionsOfMarketSession Provided by Marketplace Information Broker Table 18 - Energy Aware IT Load Balancer Identity Card
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
40
On the DC side, an agent called Energy Aware IT Load Balancer Client is in charge of applying part of Intra DC Energy Optimiser plans within the federated DCs. The Energy Aware IT Load Balancer Client is especially in charge of managing the following Intra DC Energy Optimiser actions: shift, get, relocate kWh of energy through IT loads management.
The Energy Aware IT Load Balancer Client is in charge of identifying either the hardware resources corresponding to available energy, or the actual IT loads (virtual machines or containers) to be migrated. These hardware resources will consist in the relocation bids, respectively the relocation offers are the actual IT loads identified by the Energy Aware IT Load Balancer Client according to parameters such as energy consumption and SLA status.
The interactions of the Energy Aware IT Load Balancer Client with the other CATALYST software components are depicted in Figure 12; details are provided in Table 19.
The exact operation process of the Energy Aware IT Load Balancer Client is being detailed in the D3.2 planned for delivery at month M20, i.e. May 2019.
CATALYST DCs FEDERATION CATALYST MARKETPLACE Federated DC IT Load Virtual Container Energy aware IT Migration Controller Generator Load Balancer MaaS Platform
Energy Marketplace CATALYST DC- SIDE Flexibility Marketplace Heat Marketplace Federation Market Participation IT Load Marketplace
Virtual Container Energy aware IT Load Generator Client Balancer Client Access Manager
Federated DC IT Load Optimisation Market Migration Market Session Clearing Controller Manager DC Operator Intra DC Energy SLA Client Manager Console Optimiser (re)negotiation
Energy Marketplace Information Broker Efficiency Heat DR ElectricityDR Connector Metrics Prediction Prediction Access IB Marketplace Calculator Control API Data Storage
DB API Smart Grid Connector Energy Monitoring IT & Energy Control Data Storage System Supervisor Interface Manager Multi-energy Market Management
Figure 12 - Energy Aware IT Load Balancer Client Balancer interactions with other components
Energy Aware IT Load Balancer Client
Framework Sub-System CATALYST DC-side
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
41
Responsibility The Energy Aware IT Load Balancer Client has the responsibility to identify in the DCs the actual ITL to be moved, or the resources to be proposed to the IT Load Marketplace to ensure actual execution of the Energy Optimiser plans.
Provided Interfaces Migration
Description Post migration Provided to DCMC Client End-point URL /migration Protocol used HTTP Allowed Methods POST MigrationById
Description Edit migration status Provided to DCMC Client End-point URL /migration/{migration_id} Protocol used HTTP Allowed Methods PUT Required Interfaces Retrieve IT-related optimisation action plans Set status of IT-related optimisation actions Retrieve available hardware info Retrieve running IT loads Provided by Data storage and DB API Get SLA status of IT load Renegotiate SLA status of IT load Provided by SLA Renegotiation manager Post relocation offers and bids
Provided by DCMC Client Table 19 - Energy Aware IT Load Balancer Client Identity Card
3.2.12 Federated DC IT Load Migration Controller
The Federated DC IT Load Migration Controller (DCMC) is responsible for performing IT load migration between federated DCs, which belong to different administrative domains. A client version of DCMC will be running on each of the federated DCs’ controller, communicating with the DCMC server, at a remote deployment. The DCMC clients interact with the Energy-aware IT Load Balancer (LB) and the Marketplace Connector about participating in the IT Load Marketplace, while they interact with the DCMC server, in order to actually perform IT Load migration between federated DCs, as depicted in Figure 13.
In detail, the DCMC clients will receive migration offers or bids requests by the Energy-aware IT Load Balancer, originally spurred by the Intra-DC Energy Optimizer. The DCMC client will also inform the LB of potential rejection of the placed migration bid/offer while the market session is active or as a result of market clearing. Upon acceptance of the migration bid/offer, DCMC clients will inform the DCMC server that they are ready for migration; in case of a migration bid, the DCMC client will first set up the virtual Compute (vCMP) node, to host the migrated load. Then, DCMC server is responsible for setting up a secure communication channel between the two DCs; the source and the destination of the IT load. After communication is set up and the source DC is connected to the vCMP at the destination DC, the migration actually starts. Then, the
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
42
DCMC clients inform both the Energy Aware IT Load Balancer and the Marketplace Connector about the success or failure of the migration, thus flagging the relevant marketplace actions as delivered or not delivered, in order to be considered in the billing process. The DCMC operation will be detailed in D3.3 “Federated DCs Migration Controller”, due at the end of September 2019, while the specified interfaces of DCMC at the time of writing are listed in the Component’s Identity Card, in Table 20.
Figure 13 - Interactions involving the Federated DC IT Load Migration Controller
Federated DC IT Load Migration Controller
Framework Sub-System CATALYST DCs FEDERATION
Responsibility Receive requests for placing migration bids or offers in the IT Load Marketplace Forward such requests to the Marketplace Connector Perform IT load migration for accepted bids/offers within the market session delivery period Inform IT Load Balancer and Marketplace Connector about the migration status Provided Interfaces MigrationRequest
Description Post pending migration Provided to Energy-aware IT Load Balancer End-point URL /migration/request/ Protocol used REST Allowed Methods POST Migration
Description Update migration status Provided to Marketplace Connector End-point URL /load/{load_id}/migration/ Protocol used REST Allowed Methods PUT MigrationDetails
Description Retrieve information about session start and end times and the identity of the source/destination DC. Provided to Marketplace Connector End-point URL /migration/{migration_id}/details/ Protocol used REST Allowed Methods POST Required Interfaces Actions Migration Provided by Marketplace Connector
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
43
Get details over a DC Get the VC tag after a successful registration Register a new VC Get the flavour of a VC Get the history of a VC Get the migration status of a VC Provided by Virtual Container Generator Table 20 - Federated DC IT Load Migration Controller Identity Card
3.2.13 Virtual Container Generator
The Virtual Container Generator (VCG) is a distributed (reversed client-server model) component responsible for information related to the lifetime of IT virtual loads, that is virtual machines or containers, on the blockchain, effectively transforming them into virtual containers (VCs). Under a federated DCs perspective, the VCG enables IT loads trackability and allows for indisputable SLA monitoring (see paragraph 3.2.2 for details). The component has already been detailed in deliverable D3.1 [6], where information related to the component architecture, deployment options and interactions are analysed. Figure 14 depicts, in high-level, the components that the VCG interfaces with.
Figure 14 - Virtual Container Generator (VCG) high-level interactions with other CATALYST components.
The following Table 21 and Table 22 summarizes the core RESTful interfaces exposed by VGC (client and server), full documentation being available in D3.1 [6].
Virtual Container Generator Client
Framework Sub- CATALYST DCs FEDERATION System Responsibility Persist information related to the lifetime of the virtual IT loads to the blockchain and allow easy access to such information. Provided Interfaces Get details over a DC
Description Serves details over a currently known DC Provided to Federated DC IT Load Migration Controller End-point URL /datacentre/{address}/details/ Protocol used HTTP Allowed Methods GET Get the VC tag after a successful registration
Description Allows for the retrieval of a generated VC tag Provided to Federated DC IT Load Migration Controller End-point URL /transaction/{tx_hash}/vctag/ Protocol used HTTP Allowed Methods GET Register a new VC
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
44
Description Delivers the details of a particular VC Provided to Federated DC IT Load Migration Controller End-point URL /container/{vc_tag}/details/ Protocol used HTTP Allowed Methods GET Get the flavour of a VC
Description Allows for the retrieval of the flavour of a VC Provided to Federated DC IT Load Migration Controller SLA (re)negotiation End-point URL /container/{vc_tag}/migration/pending/ Protocol used HTTP Allowed Methods GET Get the history of a VC
Description Allows for the retrieval of the history of a VC Provided to Federated DC IT Load Migration Controller SLA (re)negotiation End-point URL /container/{vc_tag}/history/ Protocol used HTTP Allowed Methods GET Get the migration status of a VC
Description Serves details over the pending migrations (if any) of a given VC Provided to Federated DC IT Load Migration Controller SLA (re)negotiation End-point URL /container/{vc_tag}/flavor/ Protocol used HTTP Allowed Methods GET Required Interfaces No interfaces required
Table 21 - Virtual Container Generator Client Identity Card
Virtual Container Generator
Framework Sub- CATALYST DC-side System Responsibility Persist information related to the lifetime of the virtual IT loads to the blockchain and allow easy access to such information. Provided Interfaces Register a new DC
Description Registers a new DC in the list of currently known ones. Provided to Federated DC IT Load Migration Controller End-point URL /datacenter/register/ Protocol used HTTP Allowed Methods POST Register a new VC
Description Registers a VC into the BC infrastructure Provided to Federated DC IT Load Migration Controller End-point URL /datacenter/{dc_name}/container/register/ Protocol used HTTP Allowed Methods POST Register a VC availability change
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
45
Description Register an availability change for a given VC. Provided to Federated DC IT Load Migration Controller End-point URL /datacenter/{dc_name}/container/{vc_tag}/availability/change/ Protocol used HTTP Allowed Methods POST Register a new VC relocation request
Description Register the intention of initiating the migration of a VC from a DC to another Provided to Federated DC IT Load Migration Controller End-point URL /datacenter/{dc_name}/container/{vc_tag}/migrate/pending/ Protocol used HTTP Allowed Methods POST Confirm a VC relocation
Description Inform the VCG that a DC confirms the completion of the migration of a VC Provided to Federated DC IT Load Migration Controller End-point URL /datacenter/{dc_name}/container/{vc_tag}/migrate/confirm/ Protocol used HTTP Allowed Methods POST Required Interfaces No interfaces required
Table 22 - Virtual Container Generator Server Identity Card
3.2.14 Marketplace Connector
The Marketplace Connector acts as a mediator between the DC and the CATALYST Marketplace, enacting automated DC participation in the four CATALYST Marketplace variants, implementing relevant actions of an Optimization Plan, generated by the Intra DC Energy Optimizer. Specifically, the Marketplace Connector receives a request for creating a bid or offer in the Energy, Flexibility or the Heat Marketplace by the Intra DC Energy Optimizer, while a request for a bid or offer in the IT Load Marketplace is placed by the Federated DC IT Load Migration Controller Client, as shown in Figure 15. Also, Table 23 presents the component identity card of the Marketplace Connector.
Figure 15 - Marketplace Connector interactions with other CATALYST components
Marketplace Connector
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
46
Framework Sub-System CATALYST DC-side
Responsibility Post market actions in the CATALYST Marketplace Provide details for migration to Federated DC IT Load Migration Controller Client, after the relevant offer or bid is accepted in the IT Load Marketplace Communicate the migration status to DCMC and IB Provided Interfaces Actions
Description Provide information about market actions, to be posted on the respective marketplace/market session Provided to to Federated DC IT Load Migration Controller Client, Optimizer End-point URL /actions/{form}/ Protocol used REST Allowed Methods POST ActionsToTimeframe
Description Provide information about market actions, to be posted on the respective marketplace/market session of given timeframe Provided to to Federated DC IT Load Migration Controller Client, Optimizer End-point URL /actions/{form}/{timeframe}/ Protocol used REST Allowed Methods Allowed Methods Prices
Description Retrieve the reference price of given service and timeframe Provided to Energy Aware IT Load Balancer, Optimizer End-point URL /prices/{form}/{timeframe}/ Protocol used REST Allowed Methods GET PriceByDate
Description Retrieve the reference price of given service and timeframe for a given date Provided to Energy Aware IT Load Balancer, Optimizer End-point URL /prices/{form}/{timeframe}/date/{date}/ Protocol used REST Allowed Methods GET Migration
Description Retrieve, add or update migration. Provided to Federated DC IT Load Migration Controller Client End-point URL /migration/ Protocol used REST Allowed Methods PUT Required Interfaces MarketActions MarketActionById Provided by Information Broker Migration MigrationDetails Provided by Federated DC IT Load Migration Controller Client ActionOfClearedSession
Provided by Information Broker Table 23 - Marketplace Connector Identity Card
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
47
3.2.15 MaaS Platform
The Market-as-a-Service (MaaS) Platform supports the on-demand instantiation of one or more CATALYST Marketplace variants. It will allow third party stakeholders (such as aggregators, retailers, suppliers, balancing responsible parties) to easily deploy fully operational running instances of the CATALYST Marketplace, under defined configuration. Such instantiation will be possible either via its User Interface or via its RESTful API, with no user intervention (other than the configuration details for the instantiation) just exploiting publicly available CATALYST Marketplace dockerized images. Details on the MaaS platform implementation and operation will be included in D5.3 “Cloudification of the CATALYST market framework”, due at the end of January 2020. The MaaS platform identity card can be found in Table 24.
MaaS Platform
Framework Sub-System CATALYST Marketplace
Responsibility On-demand instantiation of CATALYST Marketplace Management of marketplace instances
Provided Interfaces MarketplaceInstantiation
Description Request marketplace instantiation Provided to N/A End-point URL /maas/create/ Protocol used REST Allowed Methods POST MarketplaceManagement
Description Retrieve one’s marketplace instances Provided to N/A End-point URL /maas/marketplaces/ Protocol used REST Allowed Methods GET MarketplaceManagementById
Description Retrieve or delete one’s marketplace instances Provided to N/A End-point URL /maas/marketplaces/{marketplace_id}/ Protocol used GET, DELETE Required Interfaces No interfaces required
Table 24 - MaaS Platform Identity Card
3.2.16 Information Broker
The Information Broker (IB) is a core component of the CATALYST Marketplace, providing persistence and management of Marketplace data, as well as access to them by both internal and external entities, analysed in D5.1 “CATALYST market infrastructure implementation” [7]. IB is composed of three subcomponents, as depicted in Figure 16;
• The IB Application Programming Interface (API), exposing IB services via 70 RESTful interfaces • Access control, applying token-based authentication for accessing the Marketplace data. This layer ensures that registered users can access only information according to read or right permissions assigned to them, following role-based permissions defined per IB interface. To this, 15 permission
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
48
classes have been defined, assigning read and /or write permissions to the Marketplace Data Storage through the IB services. Moreover, custom filtering mechanism has been designed and implemented to enable access only to data according to defined permissions. • The Marketplace Data Storage (MDS), which provides persistence and management of the Marketplace data.
Figure 16 - The CATALYST IB
IB interacts with all the marketplace components, as shown in Figure 17:
• The Access Manager (AM) consumes a number of IB services, in order to retrieve the information displayed about marketplaces, market sessions, market actions, profile information, etc. Also. AM may update information persisted in MDS. • The Market Session Manager consumes IB services, in order to retrieve information about market sessions, update their status, ensuring smooth market session operation and delivery, and send new actions for validity check. • The Market Clearing Manager, which consumes IB services, in order to retrieve sorted -by price- actions of the market sessions being cleared. • The Marketplace Connector interacts with IB in order to retrieve information about market sessions, place market actions, but also retrieve the market clearing results.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
49
Figure 17 - Information Broker interactions with other CATALYST components
In any case, IB provides a rich set of services, which facilitate access to the marketplace data for the interacting entities, applying proper filtering criteria. As the list of IB interfaces is quite long, online interactive documentation is supported via Swagger [8]. Indicatively, Figure 18 depicts the usage of an IB API call via Swagger, where the endpoint URL and a short description of the interface are presented, while the user may insert desired values for the path parameters. By hitting “Execute”, the output -in this case the list of active market sessions for the marketplace of ID 3- is provided, as appearing in Figure 19.
Figure 18 - Example of usage of IB API Swagger
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
50
Figure 19 - Example output of IB API call via Swagger
The full list of the IB API RESTful interfaces is provided in Table 25.
Information Broker
Framework Sub- CATALYST Marketplace System Responsibility Persistence and management of Marketplace data Protected access to marketplace data Provided Interfaces MarketPlaceList Description Retrieve list of marketplaces or add a new one Provided to N/A End-point URL /marketplace/ Protocol used REST Allowed Methods GET, POST
MarketPlaceDetail Description Retrieve, update or delete a specific marketplace by id Provided to N/A End-point URL /marketplace/{marketplace_id}/ Protocol used REST Allowed Methods GET, PUT, DELETE
allUpdateMarketSessions Description Retrieve or update market sessions of given status. Provided to Market Session Manager End-point URL /marketplace/all/update/marketsessions/{status}/ Protocol used REST Allowed Methods GET, PUT
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
51
MarketPlaceOfFormWithActiveSession Description Retrieve the list of marketplaces of given form and timeframe, which have active market sessions. Provided to N/A End-point URL /marketplace/form/{form}/timeframe/{timeframe}/ Protocol used REST Allowed Methods GET
MarketPlaceOfForm Description Retrieve the list of marketplaces of given form and timeframe. Provided to N/A End-point URL /marketplace/form/{form}/timeframe/{timeframe}/all/ Protocol used REST Allowed Methods GET
MarketActionCounterOffers Description Retrieve the list of or create counteractions of a specific marketplace Provided to N/A End-point URL /marketplace/{id}/counteroffers/ Protocol used REST Allowed Methods GET, POST
getReferencePrice Description Retrieve the current reference price for the target market id for a specific form Provided to N/A End-point URL /marketplace/{id}/form/{form}/date/now/referencePrice/ Protocol used REST Allowed Methods GET
getReferencePrice Description Retrieve the reference price for a specific date for the target market id for a specific form Provided to N/A End-point URL /marketplace/{id}/form/{form}/date/{date}/referencePrice/ Protocol used REST Allowed Methods GET
FindMarketActorInMarketplace Description Returns true if the given Marketplace Actor is registered in the specific Marketplace, “false” otherwise Provided to N/A End-point URL /marketplace/{id}/marketactor/{actor}/exists/ Protocol used REST Allowed Methods GET
actionByUser Description Retrieve the list of market actions of a specific user or all the actions, if the issuer is DSO or Market Operator, in a specific market session Provided to N/A End-point URL /marketplace/{id}/marketparticipants/{username}/dso/{is_dso}/mark etsessions/{sid}/actions/ Protocol used REST Allowed Methods GET
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
52
MarketSessions Description Retrieve or add market sessions of a specific marketplace Provided to N/A End-point URL marketplace/{marketplace_id}/marketsessions/ Protocol used REST Allowed Methods GET, POST
ModifyMarketSession Description Retrieve or update a specific market sessions of a specific marketplace Provided to N/A End-point URL marketplace/{marketplace_id}/marketsessions/{sid} Protocol used REST Allowed Methods GET, PUT
ActiveMarketSessions Description Retrieve the active market sessions of a specific marketplace Provided to N/A End-point URL marketplace/
AllActive Description Retrieve the list of active bids, offers or both of a specific active marekt session. Provided to N/A End-point URL /marketplace/{id}/marketsessions/active/{type}/active/ Protocol used REST Allowed Methods GET
BilledActions Description Update the status of billed market actions of cleared market sessions Provided to N/A End-point URL /marketplace/{id}/marketsessions/cleared/actions/billed/ Protocol used REST Allowed Methods PUT
NotBilledOffers Description Retrieve the list of not billed offers of cleared market sessions of thespecific marketplace Provided to N/A End-point URL /marketplace/{id}/marketsessions/cleared/offers/notbilled/ Protocol used REST Allowed Methods GET
NotBilledOffersOfFlex Description Retrieve the list of not billed offers of cleared market sessions of the Flexibility Marketplace Provided to N/A End-point URL /marketplace/gam/marketsessions/completed/offers/notbilled/ Protocol used REST Allowed Methods GET
findLastMarketSessionClearingPrice
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
53
Description Retrieve the last clearing price of closed market sessions of a specific marketplace and of specific form. Provided to N/A End-point URL /marketplace/{id}/marketsessions/form/{form}/sessionstatus/closed /lastClearingPrice/ Protocol used REST Allowed Methods GET
selectMarketSessionByForm Description Retrieve the market sessions of a specific marketplace and form and with given status. Provided to N/A End-point URL /marketplace/{id}/marketsessions/form/{form}/{status}/ Protocol used REST Allowed Methods GET
MarketActions Description Retrieve or add market actions of a specific market session in a specific marketplace. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/actions/ Protocol used REST Allowed Methods GET, POST
editSingleAction Description Update a specific market action of a specific market session in a specific marketplace. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/actions/{action_id}/edit/ Protocol used REST Allowed Methods PUT
SelectedActionsOfGamSession Description Update the status of valid offers of the Flexibility Marketplace to ‘selected’. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/actions/{action_id}/selected / Protocol used REST Allowed Methods PUT
getBids Description Retrieve the bids of a specific market session of a specific marketplace. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/bids/ Protocol used REST Allowed Methods GET
putCompletedSessions Description Update the status of a market session from “cleared” to “completed”. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/completion/ Protocol used REST Allowed Methods PUT
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
54
putEndedSessions Description Update the status of a market session from “active” to “closed” and posts sorted actions to the Market Session Manager. Provided to Market Clearing Manager End-point URL /marketplace/{id}/marketsessions/{sid}/end/ Protocol used REST Allowed Methods PUT
putClearedSessions Description Update the status of a market session from “closed” to “cleared”. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/endclear/ Protocol used REST Allowed Methods PUT
Invoices Description Retrieve the list of or add invoices a specific market session of a specific marketplace. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/invoices/ Protocol used REST Allowed Methods GET, POST
getOffers Description Retrieve the list of offers for a specific market session of a specific marketplace. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/offers/ Protocol used REST Allowed Methods GET
getTransactions Description Retrieve the list of or add transactions for a specific market session of a specific marketplace. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/transactions/ Protocol used REST Allowed Methods GET, POST
ActionsOfMarketSession Description Retrieve the list of active or sorted or delivered actions, bids or offers or add cleared ('accepted’, 'partially_accepted’, 'rejected) actions or update the status of market actions to checked (valid or invalid) in a specific market session of a specific marketplace. Provided to N/A End-point URL /marketplace/{id}/marketsessions/{sid}/{action_type}/{action_status} / Protocol used REST Allowed Methods GET, POST, PUT
StatusParticipant Description Through this interface, the Market Operator updates the status of a Marketplace Participant. Provided to N/A End-point URL /marketplaces/admin/participant/status/ Protocol used REST
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
55
Allowed Methods PUT
MarketSessionById Description Retrieve a single market session by its ID. Provided to N/A End-point URL /marketsessions/{sid}/ Protocol used REST Allowed Methods GET
electricityPrice Description Retrieve or add the price of electricity. Provided to N/A End-point URL /price/electricity/ Protocol used REST Allowed Methods GET, POST
postReferencePrice Description Add refeenece prices. Provided to N/A End-point URL /referencePrice/ Protocol used REST Allowed Methods POST
getRules Description Retrieve, add, update or delete markeplace rules. Provided to N/A End-point URL /rules/ Protocol used REST Allowed Methods GET, POST, PUT, DELETE
viewRule Description Retrieve or delete a specific markeplace rule. Provided to N/A End-point URL /rules/{id}/ Protocol used REST Allowed Methods GET, DELETE
selectMarketplace Description Retrieve marketplaces by market service type and timeframe Provided to N/A End-point URL /select/marketplace/{servicetype}/{timeframe}/ Protocol used REST Allowed Methods GET
selectMarketplaceByUsername Description Retrieve marketplaces in which a specific Marketplace Participant joins by market service type, timeframe and their username. Provided to N/A End-point URL /select/marketplace/{servicetype}/{timeframe}/{username}/ Protocol used REST Allowed Methods GET
sessionStatus Description Retrieve the list of session status records. Provided to N/A
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
56
End-point URL /sessionstatus/ Protocol used REST Allowed Methods GET
returnSpecificActor Description Retrieve information about a specific Marketplace Participant by their username. Provided to N/A End-point URL /spec-actor/{username}/ Protocol used REST Allowed Methods GET
TimeframeList Description Retrieve the list of timeframe records. Provided to N/A End-point URL /timeframe/ Protocol used REST Allowed Methods GET
AuthToken Description Retrieve authentication token for a specific Marketplace Participant, providing their username and password. Provided to N/A End-point URL /tokens/ Protocol used REST Allowed Methods POST
UpdateUserProfile Description Update profile of a specific Marketplace Participant by their username. Provided to N/A End-point URL /update/{username}/ Protocol used REST Allowed Methods GET
actionStatus Description Retrieve the list of action status records. Provided to N/A End-point URL /actionstatus/ Protocol used REST Allowed Methods GET
actionStatusById Description Retrieve a specific action status by its id. Provided to N/A End-point URL /actionstatus/{action_status_id}/ Protocol used REST Allowed Methods GET
actionType Description Retrieve the list of action types. Provided to N/A End-point URL /actiontypes/ Protocol used REST Allowed Methods GET
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
57
AdminDetail Description Retrieve information about the Market Operator Provided to N/A End-point URL /admin-detail/ Protocol used REST Allowed Methods GET
SessionView Description Retrieve the list of all market sessions. Provided to N/A End-point URL /allSession/ Protocol used REST Allowed Methods GET
AssignActorToMarketplace Description Assign or remove a specific Marketplace Participant to or from a specific marketplace. Provided to N/A End-point URL /assign/actor/{actor}/marketplace/{id}/ Protocol used REST Allowed Methods POST, DELETE
AccessManagerDec Description Retrieve information about Marketplace Particpant by their username. Provided to N/A End-point URL /decorators/{username}/ Protocol used REST Allowed Methods GET
GetDSO Description Retrieve the list registered of or add new DSOs. Provided to N/A End-point URL /dso/ Protocol used REST Allowed Methods GET, POST
FormList Description Retrieve the lisy of available energy or energy services’ forms. Provided to N/A End-point URL /form/ Protocol used REST Allowed Methods GET
FormById Description Retrieve a specific energy or energy services’ formby its ID. Provided to N/A (Mainly aimed for the AM) End-point URL /form/{form_id}/ Protocol used REST Allowed Methods GET
signupForm Description This endpoint provides the supported market actor types and the list of DSOs for filling the sign up form of the Access Manager accordingly Provided to N/A End-point URL /form/details/
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
58
Protocol used REST Allowed Methods GET
getProfileData Description Retrieve the profile information for a given username. Provided to N/A (Mainly aimed for the AM) End-point URL /getProfile/{username}/ Protocol used REST Allowed Methods GET
generalHistory Description Retrieve the history of market actions for a specific actor. Provided to N/A (mainly aimed for the AM) End-point URL /history/{pathHistory}/{username}/ Protocol used REST Allowed Methods GET
Invoices Description Retrieve the list of or add new invoices. Provided to N/A End-point URL /invoices/ Protocol used REST Allowed Methods GET, POST
postLoad Description Add new load records. Provided to N/A End-point URL /load/ Protocol used REST Allowed Methods POST
postLoadValues Description Add new loadvalue object or list of objects. Provided to N/A End-point URL /loadvalues/ Protocol used REST Allowed Methods POST
getLoadValuesByLoad Description Retrieve the list of load values for a specific load by its ID. Provided to N/A End-point URL loadvalues/load/{load_id}/ Protocol used REST Allowed Methods GET
MarketActionCounterOfferById Description Retrieve a specific counter action by its ID. Provided to N/A (Mainly aimed for the Market Clearing Manager) End-point URL /marketactioncounteroffers/{counter_id}/ Protocol used REST Allowed Methods GET
MarketActionById Description Retrieve a specific market action (bod or offer) by its ID. Provided to N/A
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
59
End-point URL /marketactions/{action_id}/ Protocol used REST Allowed Methods GET
MarketActorMplaces Description Retrieve the list of marketplaces in which a given Marketplace Participant is registered by their ID. Provided to N/A End-point URL /marketactor/{actor}/marketplaces/ Protocol used REST Allowed Methods GET
MarketOperator Description Retrieve or add the Market Operator(s) for a given marketplace by its ID. Provided to N/A End-point URL /marketoperators/{id}/ Protocol used REST Allowed Methods GET, POST
GenericParticipantofMarketplace Description Retrieve or add Market Participants registered in a given Provided to N/A End-point URL /marketparticipants/{id}/ Protocol used REST Allowed Methods GET, POST
GenericParticipant Description Update information of registered Marketplace Participants. Provided to N/A End-point URL /marketparticipants/ Protocol used REST Allowed Methods PUT
selectMarketSessionByForm Description Retrieve the market sessions with given status of a specific marketplace of a specific form Provided to N/A End-point URL /marketplace/
ActionOfClearedSession Description Provide the Marketaction object to subscribed DCs when the hosting market session is cleared. Provided to Marketplace Connector (Subscribed DCs) Topic /cleared/{actor_id}/{action_id}/ Protocol used Publish/Subscribe Allowed Methods - Required postListActionsToClearing Interfaces postListActionsToCheck Provided by Market Session Manager Post clearing request Provided by Energy Aware IT Load Balancer
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
60
Table 25 - Information Broker Identity Card Last, but not least, it is worth noting that the CATALYST IB builds on the GEYSER IB, re-engineered and properly enhanced. Details can be found on Appendix A.
3.2.17 Market Session Manager
The Market Session Manager is responsible for managing market sessions in all the four market sessions. The duration of a market session is fixed by the Marketplace Operator and during a market session Marketplace Participants may post offers/bids for pre-specified energy types or services for future usage under specific market rules. Market Session Manager notifies the end of a session to the Information Broker and it is also in charge of starting the market clearing process. Figure 20 depicts the interactions of the Market Session Manager with other CATALST software components.
Figure 20 - Interactions involving the Market Session Manager
The Market Session Manager realizes the implementation of the RESTful APIs, as defined in Table 26.
Market Session Manager
Framework Sub- CATALYST Marketplace System Responsibility Starts market sessions, checks market actions validity, and end market sessions. It is also in charge of the economic transaction related to the energy/IT selling. Provided postListActionsToClearing Interfaces Description Carries out the clearing price operation of the Market Action sent Provided to Information Broker End-point URL /marketplace/{marketId}/form/{form}/marketsessions/{sessionId}/action s/sorted/ Protocol used REST Allowed Methods POST postListActionsToBilling
Description Carries out the billing operation of the Market Action sent Provided to Market Clearing Manager End-point URL /marketplace/{marketId}/form/{form}/marketsessions/{sessionId}/billing /actions/ Protocol used REST Allowed Methods POST
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
61
postListActionsToCheck
Description Carries out the validity check operation of the Market Action sent Provided to Information Broker End-point URL /marketplace/{marketId}/marketsessions/{sessionId}/marketactions/ Protocol used REST Allowed Methods POST Required postListActionsToClearing Interfaces End-point URL AuthToken allUpdateMarketSessions NotBilledOffersOfFlex MarketActionCounterOffers getTransactions ActionsOfMarketSession Invoices MarketActions Provided by Information Broker postListActionsToClearing
Provided by Market Clearing Manager Table 26 - Market Session Manager Identity Card
3.2.18 Market Clearing Manager
This component is in charge of clearing the CATALYST marketplace. Different market clearing mechanism are applied based on the marketplace variant, as described in CATALYST D5.1 section 2.2.
Figure 21 - Interactions involving the Market Clearing Manager
Market Clearing Manager
Framework CATALYST Marketplace Sub-System
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
62
Responsibility Clears the marketplace. Provided postListActionsToClearing Interfaces Description Carries out the clearing price operation of the Market Action sent. Provided to Market Session Manager End-point /marketplace/{marketId}/form/{form}/marketsessions/{sessionId}/actions/sorted/ URL Protocol REST used Allowed POST Methods Required postListActionsToBilling Interfaces End-point Provided by Market Session Manager URL Table 27 - Market Clearing Manager Identity Card
3.2.19 Access Manager
The Access Manager is the User Interface of the CATALYST Marketplace, providing frontend functionality for the CATALYST Marketplace and allowing role-based access to the marketplace contents for authenticated users. Details on the functionality, installation and usage of the can be found in D5.1 [9].
Figure 22 - Interactions involving the Access Manager
Access Manager
Framework Sub-System CATALYST Marketplace
Responsibility Frontend User Interface User authentication and authorization Role-based access to frontend functionality Provided Interfaces No interface provided
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
63
Required Interfaces signupForm RelationDetails GetDSOFormListSessionViewTimeframeListpendingRequestsgetRules viewRule selectMarketplace selectMarketplaceByUsername
editSingleAction MarketSessions actionByUser selectMarketSessionByForm getReferencePrice ModifyMarketSession MarketPlaceDetail ActiveMarketSessions StatusParticipant generalHistory getProfileData UpdateUserProfile AssignActorToMarketplace getActionById actionStatus actonType sessionStatus MarketActorMplaces displaySpecificInvoices AuthToken signupUser Provided by Information Broker Table 28 - Access Manager Identity Card
3.2.20 Multi-energy Market Manager
This component implements the orchestration layer of the various CATALYST market mechanisms, ranging from sequential to simultaneous market clearing, with a view to enable DCs to increase their potential for offering flexibility to the carrier networks and reducing the time for recovering the investments in energy efficiency, RES and waste heat reuse, while exploiting synergies among energy and non-energy carriers at the largest possible extent.
Figure 23 offers an overview of the interactions that are relevant to the operation of the Multi-energy Market Manager component.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
64
Figure 23 - Interactions involving the Multi-energy Market Manager
Multi-energy Market Management
Framework Sub-System CATALYST Marketplace
Responsibility Implements the orchestration layer of the various CATALYST market mechanisms, ranging from sequential to simultaneous market clearing Provided Interfaces N/A (updates will be added in D5.2)
Required Interfaces N/A (updates will be added in D5.2)
Table 29 - Multi-energy Market Management Identity Card
3.3 Processes View
In this section, the dynamic behaviour of the CATALYST system is described through UML sequence diagrams.
Figure 24 depicts the process view and interactions for deciding on energy efficiency optimization actions.
Figure 25 shows the interactions between the CATALYST components involved in posting a bid/offer in the CATALYST Marketplace, which is conceived as an electronic market platform, where DCs and other energy actors trade in energy budgets. Bids/offers need to pass successfully the validity checks, ensuring that market session rules are not violated. Details on this process can be found in D5.1 [9].
As described in D5.1 [9], different market clearing mechanism are applied to the CATALYST Marketplace based on the marketplace variant. As an example, Figure 26 depicts the sequence diagram represents the interactions between the CATALYST components involved in the clearing of the CATALYST Electricity Marketplace, which is based on the market equilibrium approach: 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 sequence diagram applies also to the clearing of the CATALYST Heat Marketplace. The same process has been used for the implementation of the first version of the CATALYST IT Load Marketplace, while The Energy Aware IT Load Balancer will be involved for the clearing of the IT Load Marketplace in the second version of the CATALYST Marketplace prototype. Further details can be found in D5.1 [9].
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
65
In Figure 27, the clearing of the CATALYST Flexibility Marketplace is represented. At the end of each market session, within a predefined period (“clearing period”), offers are ranked in decreasing price order and the DSO selects the offers that best cover their requirements, based on current distribution requirements and smart grid status. The remuneration of the flexibility services provided will take place after their actual delivery; this implies that the DSO, (e.g. at the end of the day), has to inform the Flexibility Marketplace if a demanded flexibility service has been delivered. If the service provider was not able to provide the promised service when requested, as penalty, the fixed fee will not be paid. Further details can be found in D5.1 [9].
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
66
Figure 24 - CATALYST Optimisation process
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
67
Figure 25 - Posting new offers in the CATALYST Electricity Marketplace
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
68
Figure 26 - Market clearing in the CATALYST Electricity Marketplace
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
69
Figure 27 - Market clearing in the CATALYST Flexibility Marketplace
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
70
3.4 Deployment View
The hardware requirements for deploying the CATALYST framework are summarized in Table 30: the main functionalities have been grouped in five nodes and the hardware requirements of each node are given. Table 31 maps the CATALYST software components to the nodes. The table includes components which have not been developed yet, but they will be provided in the next prototypes versions.
Node Id Node name vCPU RAM HDD 1 optimization 4 8GB 20 GB 2 monitoring 2 4 GB 20 GB 3 federation 4 8 GB 10 GB 4 marketplace 2 4 GB 20 GB 5 blockchain 4 8 GB 80 GB
Table 30 - CATALYST deployment requirements
Software component Node name Migration Blockchain blockchain Virtual Container Generator Client blockchain Energy Aware IT Load Balancer Server federation Virtual Container Generator Server federation Federated DC IT Migration Controller Server federation SLA (re)negotiation Server federation MaaS Platform marketplace Information Broker marketplace Market Session Manager marketplace Market Clearing Manager marketplace Access Manager marketplace Multi-energy Market Manager marketplace SLA (re)negotiation Client monitoring Energy Aware IT Load Balancer Client monitoring Energy Control Manager monitoring IT & Energy Supervisor monitoring Monitoring System Interface monitoring Virtual Container Generator Client monitoring Smart Grid Connector monitoring Marketplace Connector monitoring Federated DC IT Migration Controller Client monitoring Intra DC Energy Optimizer optimization Energy Efficiency Metrics Calculator optimization
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
71
Electricity DR Prediction optimization Data Storage and DB API optimization Heat DR Prediction optimization DC Operator Console optimization
Table 31 - Mapping of software components into the CATALYST nodes
The deployment architectural view provides a basis for understanding the physical distribution of the system across a set of processing nodes. It illustrates the distribution of processing across a set of nodes in the system, including the physical distribution of processes and threads. and the components that live on them. Figure 28 depicts the suggested CATALYST deployment.
Figure 28 - Deployment view
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
72
4 CATALYST Data Model
In this section we present the final CATALYST Data Model highlighting the main changes and updates brought on top of the initial version presented in D2.1 [1]. The CATALYST final data model is presented in Figure 29.
Figure 29 - CATALYST final data model (with orange the updates brought) The initial version was focused on storing information about the physical elements of the DC (both static and monitoring data) and associated properties. The main tables are:
• 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 Resource Table contains the physical or logical devices (sub-systems) from the data centre and also has a type defined. The resource can have as parent another resource or a topology. The other physical
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
73
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 Resource table. • The Measure Table stores the measured properties for each resource 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 resource instances defined in the Resource table. It defines a timestamp for each value, the monitored value, the ID of the measured property and the ID of the resource instance that is monitored.
The new elements added are aiming to store and persist the outcomes of the prediction and optimization decision making to be then shared though defined DB API with other modules of the system. The following tables have been defined:
• Energy Prediction Table stores the output of the energy forecasting components (i.e. Heat DR Prediction and Electricity DR Prediction) at different system/sub-system scales and time granularities; • Action Type Table stores the classes of energy flexibility actions that can be potentially used in optimization action plans generated by the Intra DC Energy Optimizer; • Action Property Table stores properties associated with an optimization action class and they are being provided with specific values during actions instantiations in optimization action plans; • Action Instance and Action Values store the values of the actual optimization actions part of an optimization action plan. • DR Target stores the Demand Response targets curves, the energy demand baseline of the data centre and the adapted energy profile after applying an optimization plan.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
74
5 Conclusions
Leveraging on results of past GEYSER [2] and DOLFIN [3] projects, CATALYST intends to adapt, scale up, deploy, and validate an innovative technological and business framework that enables DCs to offer a range of mutualized energy flexibility services to both electricity and heat grids, while simultaneously increasing their own resiliency to energy supply.
This document presents a refined and detailed version of the CATALYST framework architecture and updates on use cases, whose initial version has been reported in D2.1 [1].
The CATALYST framework consists of three interacting sub-systems:
• CATALYST DC-side, responsible for improving the Data Centre energy situational awareness and for improving constantly the Data Centre energy efficiency, while exploiting their internal flexibility for providing energy services to “mutualised” power and heat energy grids and increasing resiliency and security of the power supply; • CATALYST Marketplace, through which a DC can provide mutualised energy services; • CATALYST DCs Federation, responsible for orchestrating the workload relocation among federated DCs.
The functional blocks defined in D2.1 [1] have been mapped in one or more CATALYST components, some of which have been inherited from the GEYSER [2] and DOLFIN projects [3].
Details of each CATALYST component have been provided, underlining possible interactions with other components.
The main CATALYST processes have been described through UML sequence diagrams.
A typical CATALYST framework deployment environment has been suggested by showing the mapping of the software components onto the hardware.
Moreover, in this report, refinements and updates of the CATALYST data model, which emerged from feedback of project tasks and developments after the release of D2.1 [1], have been given.
Finally, updates on the Green Data Centre Certification process and on the how the Consortium intends to evolve the CATALYST Green DC Assessment Toolkit have been provided.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
75
References
[1] H2020 CATALYST project, Deliverable D2.1 - CATALYST Specification & Design, H2020-768739 CATALYST project, 2018.
[2] “GEYSER - Green nEtworked data centers as energY proSumers in smaRt city environments,” [Online]. Available: https://cordis.europa.eu/project/rcn/110989/factsheet/en.
[3] “DOLFIN - Data Centres Optimization for efficient and environmental friendly internet,” [Online]. Available: https://cordis.europa.eu/project/rcn/110268/factsheet/en.
[4] H2020 CATALYST project, Deliverable D4.1 - Smart Energy Flexibility Modelling, H2020-768739 CATALYST project.
[5] H2020 CATALYST project, Deliverable D4.3 - DC Energy Flexibility Management Tool, H2020-768739 CATALYST project.
[6] H2020 CATALYST project, Deliverable D3.1 - VC Generation and Migration, H2020-768739 CATALYST project, 2018.
[7] CATALYST, “Deliverable D5.1 - CATALYST market infrastructure implementation,” H2020-768739 CATALYST Deliverable Report, 2019.
[8] SmartBear, “Swagger,” 2019. [Online]. Available: https://swagger.io/solutions/api-documentation/.
[9] H2020 CATALYST project, Deliverable D5.1 - CATALYST market infrastructure implementation, H2020- 768739 CATALYST project.
[10] Django 1.11.6, [Online]. Available: https://docs.djangoproject.com/en/1.11/.
[11] Django REST framework, “Django REST framework,” 2019. [Online]. Available: https://www.django- rest-framework.org/.
[12] H2020 CATALYST project, Deliverable D2.2 - Green DC Assessment Toolkit, H2020-768739 CATALYST project.
[13] H2020 CATALYST project, Deliverable D4.2 - DC Energy DR Prediction, H2020-768739 CATALYST project.
[14] “ISO/IEC 30134-1:2016 - Information technology -- Data centres -- Key performance indicators -- Part 1: Overview and general requirements,” [Online]. Available: https://www.iso.org/standard/63450.html.
[15] “CEEDA,” [Online]. Available: https://www.ceedacert.com/.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
76
[16] “BREEAM,” [Online]. Available: https://www.breeam.com/.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
77
A. Appendix: From GEYSER to CATALYST
The CATALYST Marketplace exploits and evolves the knowledge and software developed for the realization of the GEYSER Marketplace, So, CATALYST builds upon and reuses the GEYSER Marketplace outcomes, improved and extended to address current market needs, CATALYST requirements, as well as benefit from the latest technological advances to the extent possible.
The CATALYST IB and AM are based on the GEYSER IB and AM, which both have been rather re-engineered and duly improved. The main areas in which enhancements over the GEYSER IB and AM have been applied are the following;
• GEYSER IB development was based on the Java Spring Framework, exposing RESTful interfaces. The CATALYST IB was derived by porting the GEYSER IB functionality into python, exploiting Django [10] and Django rest framework [11] benefits. • CATALYST IB incorporates the functionality of the GEYSER IB, Bids/Offers Collector (BOC) and Marketplace Data Storage (MDS). The MVC pattern of the CATALYST IB encourages the integration of the web application and the data sources, while the GEYSER experience led us to the BOC integration, as well, which simplified interactions and internal marketplaces processes, so it yields a lighter Marketplace implementation. • Incorporated the Bids/Offers. • CATALYST IB has realized significant security and privacy enhancements. Token-based authorization along with a custom, CATALYST-oriented permissions and filtering scheme ensure that a) unauthorized users cannot access any marketplace data and b) data access for even registered users is restricted based on the permissions assigned to them, as well as the API filters applied, allowing access only on own data. • CATALYST error handling has been duly enhanced, in order to provide sensible error codes, greatly facilitating development and debugging. Specifically, exception handling is associated with HTTP error codes, often described in verbosely. • CATALYST IB is properly online documented via Swagger. Online documentation simplifies the test and usage of RESTful interfaces, providing short description of the interface, information on the endpoint URL, potential path parameters, as well as request and response bodies’ format and response codes. Significantly, Swagger online documentation is bound to the source code, so any changes can be easily incorporated in the online API upon deployment of the updated instance. • Both CATALYST IB and AM support dynamic operation in the sense that they are not bound to any static database configurations. The initial MDS configuration is rather bound to descriptive fields, than indexing.
On the other hand, CATALYST IB provides, though extended, the list of services already presented in GEYSER IB, BOC and MDS. In this way, CATALYST IB is backwards compatible and does not burden the exploitation and extension of other GEYSER software components in CATALYST.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
78
B. Appendix: Green Data Certification and assessment Toolkit
In this section an update on the Green Data Centre Certification process is provided. Moreover, it is reported how the Consortium intends to evolve the CATALYST Green DC Assessment Toolkit presented in D2.2-Green DC Assessment Toolkit [12].
Green Data Centre Roadmap
In the Green DC Assessment Toolkit (D2.2) we outlined the need for certification, the principle reason being “development that meets the needs of the present without compromising the ability of future generations to meet their own needs” as defined in the Brundtland Report [13] and that the next generation of DCs should, by design, utilise resources effectively, whilst ensuring seamless integration with their smart city ecosystem.
We surmised that a simple focus on energy reduction and efficiency practices applied only within the boundaries of a single DC is no longer an option for those with an ambition to own and operate the GDCs of the future. And that current silos must be broken down for DCs to reach their full potential capitalizing on their unique position as overlaying multiple networks, IT systems, electricity and heat.
We commented that there is a “paradox” of cities and regions promoting their areas as ideal locations for DCs whilst simultaneously berating them for high energy consumption and underestimating its impact on local employment.
We noted that, nevertheless DCs are the main enablers of the digital economy and that they underpin a wide range of activities across Government, Business and Society and an important part of national, indeed international critical infrastructure, and some would say more energy efficient, insofar that they concentrate IT equipment in one place and that by operating these facilities more efficiently and professionally our society reduced the use of energy. That is to say over organisations operating their own DCs on their own premises.
We found that DCs find themselves in a challenging environment, seeking to remain insulated from local communities to meet their core business requirements, uptime and resilience, but needing to be included in the energy question, participating in Demand/Response programs and providing waste heat to surrounding heat networks.
We suggested that for DCs to reach their full potential the sector needed to open dialogue with the energy community and start including in their everyday operations and business jargon, the terms, metrics and processes recognised by a wide audience and vice versa and that Standards may support this process.
We made comment upon the immaturity of the sector, if it is indeed a sector, and evaluated a confusing landscape of competing standards (mostly regional or in some cases private organisations) whose “standard” has not been peer reviewed by the official Standard Development Organisations (SDOs) but has been accepted as a “de facto” standard simply because it is global, and is in use by over a 1000 organisations across the world and was the first of its type on the scene.
We considered the possibility of setting up a certification programme against well established and accepted standards whilst keeping it flexible enough to keep up with current and upcoming innovations not yet reflected in formal procedures and commented that this would be a “daunting task” as it appears to be a far more congested space that many would realise.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
79
We looked at the current Standards, KPIs, Metrics and Guidelines and then outlined a possible approach to cut through the undergrowth and to provide a clear path to build the toolkit to be used as a guide for measuring a DCs sustainability.
Before, we continue, we must advise that the author of the Deliverable D2.2 Green Data Centre Assessment Toolkit has been replaced with a new project officer, this new project officer is well known with the global DC community, works with the EU Code of Conduct for Data Centres (Energy Efficiency) for the EU-JRC as a committee member and provides review services under contract, was a contributing member to the Green Grid, sits on the BSI TCT7/3 committee, that is responsible for the EN50600 series, and has assessed over 60 DCs for the Certified Energy Efficient Data Centre Award programme (CEEDA), The CEEDA criteria being a subset of the EUCOC best practices including KPIs and some advance practices (EUCOC optional practices), his company was a member of the EURECA project consortium and he is aware of the CLUSTER programmes. He also provides training to the DC sector on energy efficient and sustainable DCs. He provides a unique bridge between the DC sector and the project.
After a review of the proposed certification criteria contained in D2.2 and considering the intention of the project is to raise the bar for DCs to report their environmental credentials, we make comment in the following sections.
Data Centre Infrastructure Standards
The following is a refresh of those Standards as listed in D2.2 with any specific updates or developments that will be considered for inclusion in the Green DC Roadmap and Green DC Assessment Toolkit.
[All of the Standards included in D2.2 provided a vague outline of what a data centre of the future should look like, that is one that matches the desire of the CATALYST project, the best and main contenders being the EUCOC and the Green Grid DCMM, especially the Level 5 criteria]
American Society of Heating, Refrigeration, and Air Conditioning Engineers (ASHRAE)
ASHRAE published 2 documents that are of interest to the project in April 2019, these were a press release published on the 2nd April 2019 entitled “The Advancement of Liquid Cooled Solutions: The Perfect Storm Brewing” and “Water-Cooled Servers – Common Designs, Components and Processes”, published on the 11th April 2019.
Both these documents will have an impact on the development of the Green DC Roadmap and Green DC Assessment Toolkit, and we are currently reviewing both the documents.
The former deserves special attention for a number of statements.
“The data centre industry is at a crossroads when it comes to cooling technologies and solutions. Though the most common and most recognized cooling solutions utilize air, new technologies are just on the horizon which requires liquid direct to rack and chip. The timeline for availability and adoption appears to be accelerating. It is the express interest of the ASHRAE TC9.9 technical committee, who is the industry authority on power & cooling trends and best practices, to author this technology brief to accelerate the preparedness and readiness of the industry. This article will not only highlight industry factors and influences anecdotally but will articulate the urgent need to prepare for liquid cooling technologies now”.
Factors and Influences
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
80
“Had this brief been written a year ago, the following factors would have been discussed as reasons to consider liquid cooling:
1. Disruption from workload type - driven by insatiable demand for more data, and the need for real-time data consumption and analytics. High performance analytics and AI crossing market segments from pure HPC play to more central, edge, and colo data center solutions
2. Data center infrastructure limitations - high heat density solutions utilizing air, driving footprint with capacity limited CRAHs. By using liquid direct to chip, or a hybrid variant, significant improvement in heat density can be attained extending the useful life of the data center
3. Energy reduction - pressure being applied to reduce the energy consumption of data center power. Water cooled solutions allow you to reduce PUE from greater than ~1.6 to less than ~1.1
4. Reduced capital- capital expense reduction for new data center builds
5. Waste heat reuse – predominately a European driven initiative to put the heat back into the grid”
Summary
“The data center industry has rejected the notion that water would ever again be a mainstream play. The history of Bi-Polar to CMOS, along with multi-core advances has created a false sense of security that technological advances would thwart the return to liquid. As experts and industry authorities in the field of electronics cooling, the return to liquid is imminent; it’s back to the future. Engage with the IT manufacturers and equipment providers to make plans for water soon. Though a more comprehensive whitepaper will be released by TC9.9 later this year to further discuss this topic, the rate of evolution required this advance communication”.
Whilst the press release mentioned a driver being “Waste heat reuse – predominately a European driven initiative to put the heat back into the grid” it did not go into any more specific detail.
The “Water-Cooled Servers – Common Designs, Components and Processes” document comprised the following sections:
• Introduction to Water Cooled Servers • Design Considerations for CDU Implementations • Design Considerations for Non-CDU Implementations • Water Quality • Wetted Materials • Filtration • Pressure Testing Requirements for Water Cooled Servers • Flexible Hose Used in Water Cooled Systems • Clarifications on the FCS and TCS Loops Described in Liquid Cooling Guidelines for Datacom Equipment Centres 2nd Edition • Future Work and Additional Resources
From an initial review of this document, it was clear that the it was a technical document concerned with the use of water internally to a DC rather than a concise document providing guidance for connection to district heating grids externally to the DC.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
81
Uptime Institute
No updates (May 2019)
The Green Grid
No Updates (May 2019) however the project team is not a member of the Green Grid and as such would not receive notifications of updated or new documents.
Data Centre Maturity Model (DCMM)
There has never been a requirement to report initial status or update progress as part of the DCMM, the tool was specifically designed to be used as a self-assessment tool and as such results or progress are hard to determine.
The DCMM is due to be updated as part of the CEN/CENELEC/ETSI GDC Standards development process, further information is currently being sourced with a view that the CATALYST project can provide content and review the updated model once completed.
The Chartered Institute for IT (DataCentre Dynamics CEEDA)
The correct title for this element should be the BCS – The Chartered Institute for IT, the BCS stands for the British Computer Society, however given recent developments as outlined below, in future the CATALYST project will refer to the element as DataCentre Dynamics CEEDA
Since D2.2 the BCS has sold the CEEDA programme to DataCentre Dynamics (known as DCD), it is no longer managed by the Data Centre Specialist Group (DCSG) within the BCS and is now solely managed by DCD.
The CEEDA assessment criteria are in the process of being reviewed and expanded, the project team are in contact with the development committee to request that they consider the use of the CATALYST project KPIs as outlined in D2.2, this is likely to be as a separate section that is NOT assessed and would not be considered in the overall grading of the DC for the accreditation, but may be considered for assessment purposes at the next revision, which is unlikely to be during the project.
The US Green Building Council
No updates (May 2019)
The Building Research Establishment Group
In D2.2 we referred to this organisation as the Building Research Establishment Global, however it is actually the Building Research Establishment Group (known as the BRE Group)
They have been reviewing the criteria concerned with DCs and have decided to not maintain a DC specific certification, however they will maintain a separate document that will used if a building has a DC within. This document is under review and a CATALYST project team member is part of the review group, there is a meeting scheduled for mid-June. Any discussions relating to CATALYST will be reported in D8.6 and D8.11.
The International Telecommunication Union
In D2.2 we identified that ITU-T L.1300 was a recommendation that described best practices aimed at reducing the negative impact of DCs on the climate, during the review for the update of D2.3 we have
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
82
identified a further series of Standards and recommendations that will be need to reviewed and considered for the development of the Green DC Assessment Toolkit. This work will begin immediately and will be reported in D8.11
For reference the work will cover the following ITU elements:
• L.1300 Best practices for Green Data Centres • L.1301 Minimum data set and communication interface requirements for data centre energy management • L.1302 Assessment of energy efficiency on infrastructure in data centres and telecom centres • L.1303 Functional requirements and framework of green data centre energy-saving management system • L.1310 Energy efficiency metrics and measurement methods for telecommunication equipment • L.1315 Standardization terms and trends in energy efficiency • L.1320 Energy efficiency metrics and measurement for power and cooling equipment for telecommunications and data centres • L.1321 Reference operational model and interface for improving energy efficiency of ICT network hosts • L.1325 Green ICT solutions for telecom network facilities • L.1330 Energy efficiency measurement and metrics for telecommunication networks • L.1331 Assessment of mobile network energy efficiency • L.1332 Total network infrastructure energy efficiency metrics • L.1340 Informative values on the energy efficiency of telecommunication equipment • L.1350 Energy efficiency metrics of a base station site • L.1351 Energy efficiency measurement methodology for base station sites • L.1360 Energy control for the software-defined networking architecture • L.1361 Measurement method for energy efficiency of network functions virtualization • L.1370 Sustainable and intelligent building services • L.1400 Overview and general principles of methodologies for assessing the environmental impact of information and communication technologies • L.1410 Methodology for environmental life cycle assessments of information and communication technology goods, networks and services • L.1420 Methodology for energy consumption and greenhouse gas emissions impact assessment of information and communication technologies in organizations • L.1430 Methodology for assessment of the environmental impact of information and communication technology greenhouse gas and energy projects • L.1440 Methodology for environmental impact assessment of information and communication technologies at city level • L.1450 Methodologies for the assessment of the environmental impact of the information and communication technology sector • L.1460 Connect 2020 greenhouse gases emissions - Guidelines • L.1500 Framework for information and communication technologies and adaptation to the effects of climate change • L.1501 Best practices on how countries can utilize ICTs to adapt to the effects of climate change • L.1502 Adapting information and communication technology infrastructure to the effects of climate change • L.1503 Use of information and communication technology for climate change adaptation in cities • L.1504 ICT and adaptation of agriculture to the effects of climate change
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
83
• L.1505 Information and communication technology and adaptation of the fisheries sector to the effects of climate change • L.1506 Framework of climate change risk assessment for telecommunication and electrical facilities • L.1600 Overview of key performance indicators in smart sustainable cities • L.1602 Key performance indicators related to the sustainability impacts of information and communication technology in smart sustainable cities • L.1700 Requirements and framework for low-cost sustainable telecommunications infrastructure for rural communications in developing countries • L.1601 Key performance indicators related to the use of information and communication technology in smart sustainable cities • L.1603 Key performance indicators for smart sustainable cities to assess the achievement of sustainable development goals • L.Sup1 ITU-T L.1310 - Supplement on energy efficiency for telecommunication equipment • L.Sup2 ITU-T L.1410 - Case studies • L.Sup3 ITU-T L.1430 - Guidance on practical application of ITU-T L.1430 to a real-time navigation service • L.Sup4 Guidelines for developing a sustainable e-waste management system • L.Sup5 Life-cycle management of ICT goods • L.Sup6 ITU-T L.1300 - Supplement on a validation test of a data centre cooling method using renewable energy in a cold region • L.Sup7 ITU-T L.1300 - Supplement on rationale for minimum data set for evaluating energy efficiency and for controlling data centre equipment in view of power saving • L.Sup8 ITU-T L.1300 - Supplement on potential for primary energy savings in TLC/ICT centres through free cooling • L.Sup9 ITU-T L.1300 - Supplement on case study of reduction of air-conditioning energy by optical fibre based thermometry • L.Sup10 ITU-T L.1300 - Supplement on verification experiments related to increase of efficiency of air- conditioning and control technologies at a data centre • L.Sup11 ITU-T L.1300 - Supplement on verification test and feasibility study of energy and space efficient cooling systems for data centres with high density ICT devices • L.Sup12 ITU-T L.1300 - Supplement on experimental studies on plates and ducts installed at equipment inlets and outlets • L.Sup13 ITU-T L.1410 - Case study: A hybrid approach-based comparative analysis of the environmental impact of a baseline data centre and an energy-efficient data centre • L.Sup14 ITU-T L.1500 - Standardization gap analysis for smart water management • L.Sup15 ITU-T L.1500 series - Requirements for water sensing and early warning systems • L.Sup16 ITU-T Y.4550-Y.4699 - Smart water management in cities • L.Sup17 ITU-T L.1600 - Definition for smart sustainable city • L.Sup18 ITU-T Y.4050-Y.4099 - Smart sustainable cities: An analysis of definitions • L.Sup19 ITU-T Y.4900 Series - Key performance indicators definitions for smart sustainable cities • L.Sup20 Green public ICT procurement • L.Sup21 Implementation guidance for small- and medium-sized enterprises on information and communication technology supply chain due diligence concerning conflict minerals • L.Sup22 ITU-T L.1700 - Low-cost sustainable telecommunication for rural communications in developing countries using fibre optic cable • L.Sup23 ITU-T L.1700 - Low-cost sustainable telecommunications for rural communications in developing countries using microwave and millimetre radio links • L.Sup24 ITU-T L.1500 - Overview of climate change effects and possible impacts
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
84
• L.Sup25 ITU-T L.1502 - Best practices for infrastructure adaptation to climate change • L.Sup26 ITU-T L.1410 - Case study: The assessment of greenhouse gas emissions of a hybrid satellite broadband system over its life cycle • L.Sup27 Supplement on success stories on e-waste management • L.Sup28 Circular economy in information and communication technology; definition of approaches, concepts and metrics • L.Sup29 ITU-T L.1700 - Low-cost sustainable telecommunication for rural communications in developing countries using cellular radio technologies • L.Sup30 ITU-T L.1700 - Setting up a low-cost sustainable telecommunication network for rural communications in developing countries using cellular network with capacity transfer • L.Sup31 ITU-T L.1700 - Setting up a low-cost sustainable telecommunication network for rural communications in developing countries using satellite systems • L.Sup32 Supplement for eco-specifications and rating criteria for mobile phones eco-rating programmes • L.Sup33 Assessment of energy consumption of information and communication technology services • L.Sup34 Example of hybrid lice cycle assessment of the aggregated second order effects of selected information and communication technology services • L.Sup35 Framework of disaster management for network resilience and recovery • L.Sup36 ITU-T L.1310 - Study on methods and metrics to evaluate energy efficiency for future 5G systems. • The International Organization for Standardization (ISO) • The European Telecommunications Standards Institute • The Coordination Group on Green Data Centres
As these three organisations are linked it makes sense to treat them as one organisation, since D2.2 there has been a considerable amount of updates that need to be considered prior to the development of the Green DC Assessment Toolkit, especially as we have a direct link into the Coordination Group on Green Data Centres. From the minutes of the meeting on the 25th April 2019 there are a number of aspects that CATALYST needs to consider these are listed below:
Impact of ISO50001:2018 There are two separate issues:
• Continuous performance improvement • Solutions for a near perfect solution • Deferred Investment • Conflict with our KPIs Objectives of resource management rather than simple energy consumption
SC39 will have to contact TC301 in order to resolve
GPP project (Green Public Procurement)
Input from Research programmes – EURECA
EU Commission project review
CATALYST Project – Green DC Assessment Tool
National Reports
France – French Government is pushing for energy efficiency regulations based upon PUE and EUCOC objectives by 2030
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
85
GB – BREEAM will no longer maintain a “DC” specific certification (Noted in BRE Group updated above)
Netherlands – No building permits if DC does not meet certain PUE criteria & Multi-tenant energy efficiency laws potentially allows impact on co-location (The DC owner become responsible for the energy efficiency of its clients)
Germany – Blue Angel being revised to apply to colocation sites & BSI (Bundesamt fur Sicherheit in der Informationstechnik) have revised its requirements (including geo-redundancy separation) for government facilities. These would apply to financial institutions and this would cause issues.
Update to Landscape and Brochure documents:
• Landscape • Update references for definitions • New section for WUE and CUE • Brochure • o Check on 2Ed EN50600-1, 2-2 and 2-3 against existing text • o Maturity Model is it a KPI • Redrafts to be prepared for comment
It should be noted that since the publication of D2.2, the CEN/CENELEC/ETSI Joint Coordination Group Green Data Centre has published 2 revisions of their documents:
• Standardisation landscape for the energy management and environmental viability of data centres 5th Edition 2018 • Review of standardisation activities Energy Management and Environmental Viability of Data Centres Based on the Edition 5 Report of the CEN/CENELEC/ETSI Coordination Group on Green Data Centres
There are also a number of 2nd edition revisions to the EN50600 series that are currently undertaking final voting prior to publication.
Metrics and Key Performance Indicators on Resources
In D 2.2 we outlined 8 metrics that would be considered in a certification process:
These were:
• Power Usage Effectiveness – PUE Source: EN50600-4-2 or ISO/IEC 30134-2
• Renewable Energy Factor –REF Source: EN50600-4-3 or ISO/IEC 30134-3
• Energy Reuse Factor – ERF Source: EN50600 -6 and Cluster
• Water Usage effectiveness – WUE Source: the Green Grid Whitepaper #35
• Adaptability Power Curve at RES – APCren Source: Cluster
• Data Centre Adapt – DCA Source: Cluster
• Primary Energy Savings – PES Source: Cluster
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
86
• CO2 Savings Source: Cluster
As can be seen in 1.2 some of these are now being re-evaluated notably WUE and CUE
Of these metrics, we expected that most of the professional community (colocation operators) would be reporting real-time or almost real-time values of PUE and if applicable REF, ERF and WUE, for all their locations, however through our research we were unable to obtain this data.
The hyperscale community, those providing social networks, search engine or cloud services, have a great deal of data available but not in a consistent format and only one of them is reporting real time PUE and WUE values.
It is therefore, as expected, a “daunting task” to create an assessment tool that would be attractive to data centre operators.
Given the amount of re-evaluation work required to “map” the updated standards as listed above, we suggest that D8.6 Green DC Assessment Tool is delayed taking into account the amendments and updates.
Assessment Toolkit Building Blocks
In D2.2 we stated that “Bearing in mind the analysis presented in the previous sections, how one can measure in practice their DC’s environmental impact? Which KPIs and metrics should one use to evaluate the various aspects of their DC’s environmental performance? How does one go about assessing the options towards improving their position in terms of environmental sustainability?”
We can now add “especially in light of the fact that the standards and guidelines are evolving on an almost continual basis”
However, we further stated in D2.2 that with this Toolkit we aspire to answer exactly these questions, laying down stepping stones for DC operators to stand upon and cut their path towards self-assessment, whilst planning follow up actions to improve their DC facility and operations in terms of environmental sustainability.
We suggested a toolkit comprising of two sections:
• A, The Building Blocks • B. The workflow that transforms these building blocks into a Value-Added Plan (VAP)
We further described in detail the Toolkits building blocks and the proposed workflow.
We stated that the Toolkit was NOT meant to compare DCs and that it was to be used to support the self- assessment process, and due to problems with the reporting of PUE that such an assessment scheme would be “challenging” to follow in practice and counterproductive when considering holistic solutions.
We then mooted that “Nevertheless, the combination of the Toolkit with the classification scheme and the possibility of the certification programme – to be further explored at later stages in the project – may provide a fair and solid approach towards DC specialization and ranking in terms of their environmental sustainability performance.”
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
87
Classification Scheme
It was suggested in D2.2 that all types of DCs could use the Toolkit and the VAP approach defined within, and that it was designed to bear in mind the various existing types of DCS as well as the continuous diversification and emergence of new business models for the sector. Thus, we aimed to achieve a balance between a flexible but abstract approach that could be easily adapted for any current and future needs and a clear, valuable set of well-defined practices to validate and support our later certification efforts.
As the Toolkit is meant to be used for self-assessment of a DCs own environment performance and impact and the further possibility of evaluating related technologies and solutions to improve via the VAP we opted to keep the grade system simple and not linked with the value of the metrics selected and reported. At the time of the publication of D2.2 we were unsure whether we had sufficient data to decide on realistic thresholds and that the results of the pilots could provide test data to remedy this.
We considered that the values of the metric were not of importance but that the metric selected, and the calculation methodology used was, whilst understanding that optimal values should be kept in mind for all 8 metrics outlined in 1.3.
This, of course, presupposes that DCs have the necessary monitoring and measuring equipment in place and the means to accurately report the values
We were also going to consider the feedback from the GDC-SG and the pilots before finalising the certification programme for GDCs.
Unfortunately, due to the changeover in project officers, information on the proposed classification system has not be published to the GDC-SG and we have not been provided with any data from the pilot sites, although this is being treated as an urgent matter within the project and we will report this by the end of September 2019 which is the end of the project for Task 2.
That is not to say that work has not continued on the Toolkit, rather that we are evaluating the classification system and may extend it based on the elements as outlined in 1.6.
The Classification Scheme as suggested in D2.2 required that DC operators would use the Toolkit as a compass to navigate through the ever-changing landscape of metrics, solutions and best practices and select those that made sense of their own facilities based upon:
• The DC business model and type • The readiness level in terms of monitoring and control • The local of regional priorities in environmental polices • The improvement schedule and change management
In D2.2 We stated that “At this first edition of the Toolkit we have opted for an abstract, general classification as follows.
• Centralized cloud DCs
This class includes DCs that fall under the traditional sense of the word. Subclasses may be further identified such as Colocation; High Performance Computing (HPC); and Hyper-scale. In this context an enterprise DC
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
88
may be perceived as a centralized private cloud DC, since most applications offered by an enterprise facility are or will be in the near future cloud enabled.
• Edge DCs
This class accommodates for the emerging edge applications which bring data processing closer to its users to improve performance and user experience (lower backhaul, latency and potential network congestion). Subclasses may be further identified as Regional; and Local. For example, a server room or networking closet may be considered a local edge DC [14], [15].
We do not envisage any changes to this description as it in essence covers all prospective categories of DCs.
Grading System
Our grading system was defined simply:
• Bronze • Silver • Gold
Based upon metrics selected per theme, the granularity of measurements if applicable or both. The grading system is built up incrementally, enacting a step by step plan of action towards the continuous improvement of the environmental performance of the DC facility.
We provided the following diagram to represent the measurement boundaries and metering points.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
89
And provided the following text as an explanation:
“In this example, the total energy consumed by the data centre is measured at the Point of Delivery (PoD) and assuming negligible transmission losses this would be the sum of energy coming from the grid, A, plus energy that may be produced and consumed onsite, B. Assuming the latter represents electricity generation on site, it is proposed to include the quantity of electricity, measured at B, and not the source energy associated with the generation. This can be considered as drawing the Control Volume (CV) to exclude generation onsite, however the units may also function as standby generation capacity, in which case they should be included, for the purposes of heating, parasitic load, and so on. The letters denote metering points. For example, heat recovered by the data centre, H, may represent either hot air or water that is being fed into a heat pump and further used by an external facility such as a nearby greenhouse, or the district heating grid.”
We will provide more detailed diagrams in the final edition to indicate the correct measurement boundaries and metering points for each of the selected metrics (as applicable)
Themes
In general, we refer to back to our comments in 1.3 regarding the reporting metrics and express a fear that even the most advanced DCs will not have sufficient monitoring or measuring tools to calculate the required metrics. However, we will have discussions with Data Centre Infrastructure Management (DCiM) tool suppliers to see if it is possible to develop software that can be offered as part of the DCiM toolsets (Most DCiM tools provide a suite of management tools over and above PUE reporting)
Theme A – Renewable Energy
We expect that most DC operators will be able to report for BRONZE and SILVER but not for Gold, this is due to the fact that the APCren flexibility metric is not widely known or calculated.
Theme B – Heat Reuse
As stated in D2.2 reporting above BRONZE level is not available at the present time, although once the ISO/IEC DC 30134-6 is published we would expect to see reporting at this level, in the meantime, DC operators can use the metrics as detailed in the GOLD section.
Energy Efficient Infrastructure
All DCs should be able to report at PUE L1, DCs will DCiMs and the necessary additional sensors and meters should be able to report at SILVER and GOLD.
Resources Management
Energy
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
90
All DCs should be able to report at all levels if the CEF is available in their geographic region.
Water
The 2nd Edition of the Classification will seek to expand on the use of WUE and WUEs if the data is available in that geographic region. e-Waste
As per the definition in D2.2 we will seek to include more information in the 2nd Edition.
The Value-Added Plan (VAP)
The VAP processes for each section are to be re-evaluated in the 2nd Edition.
Conclusions and Outlook
In D2.2 Our conclusions were as stated below:
“This first edition of the Toolkit has focused on developing a straightforward, easy-to-use process for the DC operator to follow when assessing the current state of their facility’s performance and impact in terms of environmental sustainability, and possibly evaluating options for improvement. In the CATALYST context a toolkit is perceived as a set of tools alongside a process to navigate through and showcase their use. As such, the Toolkit collects information on the most known and accepted metrics and indicators on a DC’s environmental sustainability and organizes them in themes that together cover all such aspects during operations. It then introduces a simple classification and grading system that maps the metrics associated with each theme. In doing so, it sets the foundation of a roadmap towards higher performance and positive impact of a DC’s operations in terms of environmental sustainability.
The Toolkit will be further refined based on the feedback from the core members of the GDC-SG and the results from the project’s validation pilots. In particular, an updated version of the Toolkit will be reported within the last deliverable of WP2 expected by May 2019. In this second edition, we may also consider translating the Toolkit’s proposed workflow into a form that may be directly in use by for example a DC operator, such as a simple spreadsheet or interactive (web) app. This option is to be explored especially in combination with incorporating the Toolkit within the GDC Roadmap first version to be reported in D8.6 expected in April 2019. Details on the proposed classification scheme and initial ideas on setting up an associated certification programme are also to be included in the D8.6 report, where refinements related to the final – from the CATALYST perspective – edition of the Toolkit will be included as well.”
As a result of the change in personnel in March 2019 publication of D2.2 to the GDC-SG and preparation of the GREEN DC Roadmap for D8.6 has been delayed, we therefore propose the following steps to enable the project to get back on track with the time schedule:
That this content and the actions contained within namely:
• The rapid and significant changes to the Standards Landscape as listed in 1.2 Data Centre Infrastructure Standards require that careful consideration is given to these changes to ascertain where the CATALYST project could be impacted, this applies to the ASHRAE documents, the impending changes to the DCMM,
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
91
the imminent changes to the CEEDA criteria, the significant amount of ITU documents, and the ISO/ETSI/CG-GDC. • We appreciate that given that these Standards are under constant review, and that we may never reach a stable environment, we need to draw a line in the sand and decide what guidance should be used, we propose that the second evaluation period ceases at the end of the period for the tasks in WP2, September 2019 and that an interim certification process is delivered the 30th. September 2019, and that the final certification process is delivered as part of Del 8.11 Green DC Energy Efficiency Roadmap v2 which is due by M35. • A further and widespread consultation of stakeholder’s exercise, to include the GDC-SG but also more widely, be made on the proposal to use the 8 metrics as cited in 1.3. We propose that the information is syndicated to various trade press outlets as a consultation exercise and requests made for feedback over the summer 2019 with an end date of August 2019 in order to collate the results for publication on the 30th September 2019 as part of the interim report as outlined above. • We do not believe that the Green DC Energy Efficiency Roadmap can properly deliver the information that would be required for a DC to fully follow the path as indicated by the Certification Process and as indicated in the DoW as follows: • “Develop a roadmap to address Green DC regulations and legal aspects of collaboration, leveraging existing and forthcoming agreements and gain support for roadmap implementation efforts; • Identify and disseminate best practices that focus on techniques, interfaces, procedures, business models and polices for connecting DCs with the Smart Grid, distributed electricity storage devices and district heating networks (e.g., deploy and properly configure interfaces);
We believe that a document of this kind needs to be in the form of a Green DC Energy Efficiency Handbook and comprise the following elements:
• Introduction/Executive Summary • Background (Climate Change/Energy Security/EU Energy & Sustainability Policy) • Data Centre Taxonomy • Standards Landscape (Content from CG-GDC 6th Edition 2019) • Legacy Environment Improvement Methodology (EUCOC Guidance) • New Build Design Process (EUCOC/DCMM Level 3+) • Smart City Co-Ordination (ITU/ISO) • Planning Guidance (National Planning Guidance) • Utility Co-Ordination (USEF, Euro Heat & Power) • Business Models and Contractual Information (CATALYST/USEF) • The Data Centre of the Future • Summary • Appendices • CATALYST Assessment & Certification • EUCOC • DCMM
We see these actions bringing the project back on track in terms of the original intent of the project and also in terms of the timelines which have been challenged recently.
CATALYST.D2.3.PARTNER.WP2.v1.0 H2020-EE-2016-2017 Final CATALYST Framework Architecture 768739
92