deliverable d2.1: design of the greendc dss greendc

Deliverable D2.1:

Design of the GREENDC DSS

GREENDC

Brunel University London

TURKSAT

LK Knowledge Engineering

Gebze Technical University

David Holding

Project reference: 734273

GREENDC D21 – GREENDC DSS Design Document

Project no: 734273 2 31/10/2017

Project Number 734273 Acronym GREENDC

Full Title GEENDC

Project URL http://www.greendc.eu/

Project Officer Irina-Elena Tiron

Deliverable Nº D2.1 Title Design of the GREENDC DSS

Work Package Nº WP2 Title GREENDC DSS

Date of delivery Contractual 31 Oct 2017 Actual 31 Oct 2017

Version Submission

Nature* R

Access level** P

Status level***

Responsible Author Name Youngseok

Choi

Institute LKKE

Internal Reviewer 1 Name Habin Lee Institute Brunel University

London

Internal Reviewer 2 Name Stanimir

Yovchev

Institute DAVID

Email [email protected]

o.uk

Phone +44-7432-882521

Abstract (for

dissemination)

This deliverable aims to define the architecture of GREENDC DSS for

the implementation. Based on the result of focused group interviews in

D1.1, user requirements have been defined through this deliverable. To

realise the requirements, four interactional layers have been designed;

data layer, math model layer, business logic layer, and user interface.

This deliverable is describing not only the detail design of each layer,

but also the efficient way of interaction among the layers. The proposed

architecture in this deliverable will be a concrete skeleton that enable

this project to anchor the right direction for defined project objectives.

Keywords DSS architecture, GREENDC DSS, DSS Implementation


Project no: 734273 3 31/10/2017

Document Contributor

Table 1 Document contributor

Name Company e-Mail

Youngseok Choi LKKE [email protected]

Habin Lee UBRUN [email protected]

Marios Pournaris UBRUN [email protected]

Stanimir Yovchev DAVID [email protected]

Tuba Gozel GTU [email protected]

M. Hakan Hocaoglu GTU [email protected]

Onur Ozturk GTU [email protected]

M. Turker Takci GTU [email protected]

Ahmet Koksoy GTU [email protected]

Fatih Karatana TURKSAT [email protected]

Kaan Uzuner TURKSAT [email protected]

Document historic

Table 2 Document history

Version

NO Date Authors Description

v0.1 07/04/2017 Youngseok Choi The structure of the deliverable defined

v0.2 08/05/2017 Youngseok Choi Integrated initial draft for user stories

v0.3 02/06/2017 Tuba GÖZEL Integrated GTU input regarding math model

layer

v0.4 07/07/2017 Youngseok Choi Integrated LKKE/GTU input regarding user

requirements

v0.5 11/08/2017 M. Hakan Hocaoglu Integrated DAVID/TRUKSAT input regarding

architecture

v0.6 23/09/2017 Habin Lee Integrated technical details of each layers

v0.7 02/10/2017 M. Hakan Hocaoglu Minor editing for correcting typos

v0.8 25/10/2017 Fatih Karatana Revision based on review comments

v1.0 30/10/2017 Youngseok Choi Final version


Project no: 734273 4 31/10/2017

Glossary

Acronym Meaning

AF Application Functions

API Application Programming Interface

CPU Central Processing Unit

DC Data Centre

DCIM Data Centre Infrastructure Management

DRC Disaster Recovery Center

DSS Decision Support Systems

DVFS Dynamic Voltage Frequency Scaling

ELM Elaboration Likelihood Model

ERD Entity Relationship Diagram

IT Information Technology

JSON JavaScript Object Notation

LB Load Balancing

NIST The National Institute of Standards and Technologies

ORM Object Relational Mapping

PUE Power Usage Effectiveness

RAM Random Access Memory

REST Representational State Transfer

RFC Request for Comments

RP Relying party


Project no: 734273 5 31/10/2017

RPC Remote Procedure Call

RST Request Security Token

RSTR Request Security Token Response

SAML Security Assertion Markup Language

SOA Service-oriented Architecture

SOAP Simple Object Access Protocol

STS Security Token Service

UA User Authentication

UPS Uninterrupted Power System

VM Virtual Machine

WS Web Socket

WSDL Web Service Definition Language


Project no: 734273 6 31/10/2017

1. Contents

1. INTRODUCTION 11

1.1 Purpose and Scope 11

1.2 Relation to Work Packages and Deliverables 11

1.3 Document Structure 11

2. User Requirements Definition 13

2.1 GREENDC DSS Roles 13

2.2 GREENDC DSS Personas and Scenario 14

2.2.1. The Monitoring and Reporting of Energy Consumption 15

2.2.2 Energy Consumption Forecasting 15

2.2.3. Simulation and Real-time Intervention for Energy Saving (Simulation Dashboard)

16

2.3 GREENDC User Stories 18

2.3.1. Monitoring of Energy Consumption User Stories 18

2.3.2. Energy Consumption Forecasting User Stories 18

2.3.3. Simulation and Real-time Intervention User Stories 19

3. GREENDC Architecture 20

3.1 Overall architecture 20

3.2 Interfaces 22

3.2.1 Business logic layer 23

3.2.2 Math model layer 24

3.2.3 Data layer 26

3.3 Sequence Diagrams for User Stories 28

3.3.1 Monitoring energy consumption user stories 29

3.3.2 Energy Consumption Forecasting User Stories 30

3.3.3 DC Simulation User Stories 31

4. Data Layer 35

4.1 Components Architecture 35

4.1.1 Components Description of Data Layer 35

Components & Class/Interface Relations(bottom to top): 36

4.2 Data collection layer 37

4.2.1 Workloads Allocation 38

4.2.2 Data Entities and Models 42

4.2.3 Energy and workloads data 45


Project no: 734273 7 31/10/2017

4.2 Data normalization layer 53

5. Math Model Layer 56

5.1. Forecasting Method: 56

5.2. Optimization Method: 61

5.3. Class Structure of Math Model Layer 64

5.4. Sequence Diagram of Math Model Layer 71

5.4.1 Data Preparation for Math Layer 71

5.4.2. Forecasting 71

5.4.3. Optimization 73

6. Business Logic Layer 74

6.1 UserManager 74

6.2 DCMonitor & DCForecaster 80

6.2.1 Consumption Monitoring, Analysis and Control 80

6.2.2 Energy optimiser and smart grid integrator 92

6.3 DCSimulator 95

6.4 CloudSim 96

6.4.1 Architecture 97

6.4.2 Class Diagram 98

6.4.3 User Interaction with CloudSim 104

6.4.4 Power Consumption Models 105

6.4.5 Workload Distribution 106

6.4.6 User Activity Diagrams for Simulation and Real-time Intervention User Stories 107

7. User Interface - UI 112

7.1 Basic Interface Principles 112

7.2 User Interface Structure 112

7.3. Serving User Stories and Scenarios 119

7.4. General DASHBOARDS for user scenarios 123

8. Conclusion with Implementation Plan 127

8.1. Data Layer 127

8.2. Math Model Layer 127

8.3. Business Logic Layer 128

8.4. User Interface 129

8.5. Conclusion 130

APPENDIX A : REGISTRATION MAPS(DCIM) 131


Project no: 734273 8 31/10/2017

Table of Figure

Figure 1. GREENDC DSS Architecture ................................................................................20

Figure 2. Interface and three layers ......................................................................................22

Figure 3. Flow chart – Data Transmit between Layers ..........................................................28

Figure 4. Sequence Diagram to detect abnormal energy consumption (RM1) ......................29

Figure 5. Sequence Diagram to get event logs (RM2) ..........................................................29

Figure 6. Sequence Diagram to get daily energy summary (RM3) ........................................30

Figure 7. Sequence Diagram to get workloads forecasting (ECF1).......................................30

Figure 8. Sequence Diagram to forecast energy consumption (ECF2) .................................31

Figure 9. Sequence Diagram to set simulator parameters (SRI1) .........................................31

Figure 10. Sequence Diagram to analyse VMs Configuration (SRI2) ....................................32

Figure 11. Sequence Diagram to analyse impact of load balancing (SRI3)...........................33

Figure 12. Sequence Diagram to analyse impact of work migration (SRI4) ..........................34

Figure 13. Sequence Diagram to analyse network configuration operation (SRI5) ...............34

Figure 14. Component Architectures for Data Layer .............................................................35

Figure 15. Collect Component ..............................................................................................36

Figure 16. Serialise Component ...........................................................................................37

Figure 17. Data Collection Flow in Data Collection Layer .....................................................37

Figure 18. Sample Graph to examine connection requests to served URLs .........................39

Figure 19. Sample Reports for load per virtual machine .......................................................40

Figure 20. Load Balancing Example .....................................................................................41

Figure 21. Data Entity Diagram ............................................................................................42

Figure 22. Data Sources and Data Collector ........................................................................45

Figure 23. Data Source - UPS ..............................................................................................46

Figure 24. Smart PDUs Interface ..........................................................................................47

Figure 25. Energy Meter .......................................................................................................47

Figure 26. Power Monitoring through the Energy Meter........................................................48

Figure 27. Chiller and Its Interface ........................................................................................49

Figure 28. Air Conditioner Interface ......................................................................................50

Figure 29. Energy Consumption from Servers – Example from Zabbix .................................50

Figure 30. Energy Consumption of Server – CPU level ........................................................51

Figure 31. Memory Usage and Energy Consumption ...........................................................52

Figure 32. File I/O and Server Energy Consumption ............................................................52

Figure 33. Network Traffic and Energy Consumption ...........................................................52

Figure 34. ERD – Consumption and Its Types ......................................................................54

Figure 35. ORM Transaction and RPC Interface ..................................................................54

Figure 36. Flowchart for Forecasting Process ......................................................................57

Figure 37. Flowcharts of Forecasting Models .......................................................................59

Figure 38. Class Structure of Math Model Layer ...................................................................65

Figure 39. Sequence Diagram of Math Model Layer for forecasting .....................................72

Figure 40. Sequence Diagram of Math Model Layer for Optimization ...................................73

Figure 41. Logical entities for the authentication domain ......................................................75

Figure 42. Authentication Classes ........................................................................................79


Project no: 734273 9 31/10/2017

Figure 43. Authentication sequence diagram ........................................................................79

Figure 44. CloudSim Architecture .........................................................................................97

Figure 45. An overall class Diagram of CloudSim .................................................................98

Figure 46. User Interaction with CouldSim .......................................................................... 105

Figure 47. User Activity Diagram – Analyse Parameter Change using CloudSim ............... 107

Figure 48. User Activity Diagram – Analyse VMs Configuration using CloudSim ................ 108

Figure 49. User Activity Diagram – Analyse Load Balancing Tools Change using CloudSim

........................................................................................................................................... 109

Figure 50. User Activity Diagram – Analyse Workloads Rescheduling using CloudSim ...... 110

Figure 51. User Activity Diagram – Analyse Network Configuration Change using CloudSim

........................................................................................................................................... 111

Figure 52. User Interface - Log-in Form .............................................................................. 113

Figure 53. User Interface – Initial Dashboard ..................................................................... 114

Figure 54. User Interface – Top Navbar ............................................................................. 114

Figure 55. User Interface - Dynamic left navigation panel ................................................... 115

Figure 56. User Interface – Page Title and Quick DC Swicher ............................................ 116

Figure 57. User Interface – DC Data Loader Navbar .......................................................... 116

Figure 58. User Interface – DSS Simulation Monitor Panel ................................................ 117

Figure 59. User Interface – DC Nodes Panel ...................................................................... 118

Figure 60. User Interface – My Simulation Page................................................................. 118

Figure 61. User Interaction – Getting Useful Results in 3 Easy Steps ................................. 119

Figure 62. User Interface – Scenario Chooser .................................................................... 120

Figure 63. User Interface – Scenario Dashboard ................................................................ 121

Figure 64. DC Measured Nodes Panel ............................................................................... 122

Figure 65. User Interface – Actions .................................................................................... 122

Figure 66. 1. Energy Consumption Forecasting DASHBOARD ...................................... 123

Figure 67. 2. Simulation for Energy Saving DASHBOARD ............................................. 125

Figure 68. User Interface – UX configuration ...................................................................... 126


Project no: 734273 10 31/10/2017

Tables

Table 1. Sample Data Set For Neural Network 60

Table 2. Expected Services from Energy consumption monitoring .......................................80

Table 3. Expected Services from Energy consumption automatic data Analyser ..................88

Table 4. Expected Services from Control centre for consumption and distributed generation

.............................................................................................................................................89

Table 5. Expected Services from energy optimizer and smart grid integrator .......................93


Project no: 734273 11 31/10/2017

1. INTRODUCTION

1.1 Purpose and Scope

The objective of work package two “GREENDC DSS” is to provide a detailed specification for

the GREENDC DSS and present the implementation details of DSS accordingly. This

deliverable, “D2.1. GREENDC Architecture” is the blueprint for actual development of

GREENDC DSS. It has been prepared as part of the project’s agile management process

and is dedicated to design the GREENDC DSS in all its aspects to fulfil the minimum

functional and technical requirements for the implementation based on user scenarios that

have been selected and sorted out through the requirement specification process. The

requirement specification will derive not only the detail user scenario, but also the component

structure of GREENDC DSS.

1.2 Relation to Work Packages and Deliverables

The work presented here is based on the results of work package one “Requirements

for Energy Efficient Data Centre” that can be viewed in “D1.1 Data Centre Energy

Management Practices.” There, a concrete definition of the GREENDC DSS

methodology as well as an elicitation of agile requirements by means of roles,

scenarios and user stories has been conducted. This placed the first corner stone for

the design, architecture and definition of the functional requirements.

The outcomes of this deliverable will be the basis of the following deliverable D2.2

GREENDC DSS, which will show the detail implementation results.

1.3 Document Structure

In this deliverable, Section 2 “User Requirement Definition” presents the user scenarios

specified based on the results from focused group interview in D1.1 and how the specified

requirements will be realised in terms of module. This section will provide the overview of

main function of DSS – Setting Parameter, Real-time Monitoring of Energy Consumption,

Energy Consumption Forecasting, Simulation and Real-time Intervention, and Periodic

Reporting.


Project no: 734273 12 31/10/2017

Section 3 “GREENDC Architecture” presents the detail architecture of GREENDC DSS with

layer and component structures.

Section 4 “Data Layer” provides the details about data collection and normalization for

GREENDC DSS implementation.

Section 5 “Math Model Layer” show the mathematical formulation of forecasting and

optimisation model that will used for data centre decision making with their class structure.

Section 6 “Business Logic Layer” conveys the detail information regarding energy

consumption monitoring and forecasting. The simulator for data centre is also introduced.

Section 7 “User Interface” shows the progress on the interface implementation that will

interacted with the user. Some of tentative interface designs are presented.

Section 8 “Implementation of GREENDC DSS” outlines the implementation strategies for

each layer including development environment and important library for DSS implementation.

Last Section concludes with the future plan of GREENDC DSS implementation.


Project no: 734273 13 31/10/2017

2. User Requirements Definition

This section presents system scenarios and user stories by considering the user

requirements of GREENDC DSS. To construct system scenarios, GREENDC DSS

roles and the personas in these roles are also defined. User requirements, on the

other hand, are determined by using the deliverable D1.1. The generated user stories

at the end of this section are then used to construct the first prototype of GREENDC

DSS.

2.1 GREENDC DSS Roles

Roles combine a set of typical actions that will fulfil tasks in scenarios. Thus, roles are not

technical descriptions but mirror responsibilities in the workflows of processes. The scenarios

(see below) will illustrate these processes. The role concept typecasts users in different

categories. However, for a better usability of the GREENDC DSS, the implementation should

facilitate the use of all tools by group leader and member of Data Centre.

- Group Leader: As described in the personas in next section, a group leader

should make sure that every group member does his/her own duties right on

time and complete as defined by regulations. The very first responsibility for

this role starts from the energy consumption forecast and he needs to assign

proper actions and tasks to group members based on the forecasting result.

GREENDC DSS provide the long-term and short-term perspectives on the

energy consumption to the group leader so that he can cope with any

circumstances. Also, GREENDC DSS support the simulation for energy

consumption of data centre so that a leader can choose appropriate

intervention option with the support of group members.

- Group Member: Group members usually conduct overall management action

regarding the control of energy consumption level based on the supervision of

a leader. The fundamental role of members is to monitor the level of energy

consumption and GREEDNC DSS can provide whole functionality for

monitoring. GREENDC also support convenient simulation interface to adjust

the possible option for controlling energy consumption level. To cope with the

variability of knowledge and experience level of members, some simulation


Project no: 734273 14 31/10/2017

function can support automatic function to tune the variables based on the

computation using historical data.

2.2 GREENDC DSS Personas and Scenario

Using scenarios integrates the personas and gives them defined roles for a current situation.

By doing this, it shows the possible use of the tools provided by GREENDC DSS to

exemplify their interplay and usefulness for energy efficiency management in the data centre.

Scenario will be developed based on the result of focus group interview and we scoped down

the main functionality into five; setting of parameters, real-time monitoring of energy

consumption, energy consumption forecasting, real-time intervention for energy saving, and

periodic reporting. In particular, we will define several sub-scenarios for real-time intervention

function as this function can give enough functionality to the data centre manager to tune the

energy consumption options.

To describe the detail of GREENDC Scenario, we define the personas below. A persona

illustrates the reality of life with a multi-dimensional view on the possible men and women

behind a role in GREENDC DSS. The persona concept facilitates system architects to meet

the requirements of this analysis to put oneself in the position of possible system users with

their diverse social backgrounds. The personas described below can be imagined as taking

several roles for which reason there is less personas than roles

Johan Green (Group Leader)

- He has to make sure that every group member does his/her own duties right

on time and complete as defined by regulations.

- He makes assignment and coordinates the group member duties.

Melina Silverwood (Group Member)

- Manage and distribute all IP addresses which belong to XX Data centre.

- Manage and control all internal IP blocks which are used in Data Centre LAN

and E-government network

- Manage and control all active network devices and infrastructure of Data

Centre and E-government network

- Take and manage backups of all active network devices and infrastructure of

Data Centre and E-government network


Project no: 734273 15 31/10/2017

- Manage and configure VPN and other network configurations between/inside

E-government services, Data Centre regional branches and headend, call

centres, DRC(Disaster Recovery Centre), TV and Satellite broadcast units.

- Design system (network and infrastructure) architecture for required

governmental agencies and manage configured system(s).

- Prepare technical RFC.

2.2.1. The Monitoring and Reporting of Energy Consumption

Melina Silverwood is a Group Member of XX Data Centre. Her main role is to ensure the

data centre operations in an efficient and timely manner by monitoring the real-time energy

consumption. Melina’s daily task is always starting from investigation of real-time monitoring

dashboard in GREEN DC DSS, which shows the unified interface with DCIM tool.

Melina check the real-time line chart presenting energy consumption of every minutes.

Meanwhile, she needs to check the event logs in the dashboard that shows the event stamps

that may cause unusual energy consumption patterns. Also, she can check daily

consumption summary if today’s consumption is consistent with previous few days.

XX data centre management team has regular meeting in every weeks and weekly energy

consumption report is the most important material for in-depth analysis for data centre

maintenance. To get the periodic report, Melina or John open the Periodic Reporting

dashboard in the GREENDC DSS. It offers daily, weekly, monthly, and quarterly reporting

including energy consumption stats, major events/intervention, and future consumption trend

report. The reporting results also can be exported into doc or pdf file format.

2.2.2 Energy Consumption Forecasting

John Green, Group Leader, has a lot of concerns as the energy consumption of data centre

has been stiffly increased since last few years. Furthermore, in terms of long-term trend, the

increasing digitisation in all areas of the economy and society is resulting in an increasing

need for processing power. Based on his experience, he is also recognising seasonal trend

(short-term) of energy consumption. To build-up the plan to cope with this micro and macro

change of energy consumption, John Green wants to estimate the future energy

consumption for long-term and short-term perspective.


Project no: 734273 16 31/10/2017

John Green choose the “Energy Consumption Forecasting” menu from GREEN DC DSS and

the dashboard for consumption forecasting is shown to him. The dashboard shows the

daily/weekly/monthly-based energy consumption forecasting using the forecasting model that

has been fitted through the whole historical data of data centre. The forecasting result says

the consumption will increase so John tries to tune some variables in the forecasting model

through the simulation interface to see how these variables can affect to the future

consumption.

2.2.3. Simulation and Real-time Intervention for Energy Saving

(Simulation Dashboard)

Whilst Melina monitors the energy consumption in real-time, she realises that the current

consumption is higher than same time in previous few days. To sort out this situation, Melina

discusses with John Green, the centre manager, regarding intervention options. To choose

one of the options, they conduct the simulation of each possible intervention option. All these

actions can be done through the Simulation Dashboard that supports the energy

consumption simulation and real-time intervention interface.

- Simulation for Controlling the Variable in the Energy Consumption Model

GREENDC DSS embeds some energy consumption models and tunes their parameters

using historical data. One directive way to minimise the energy consumption is to adjust

some tuneable variables in the energy consumption model. Melina can choose one of

embedded energy consumption model to verify the main factor cause higher consumption.

Then she can check tune some variables that can be directly adjustable from DSS level.

Also, Melina can compare the performance of energy consumption model among embedded

ones as DSS shows the performance comparison tables among existing energy consumption

models. After this comparison, she can apply the variable into real-time service level.

Different parameters for the operation of data centres are used and the optimization of

settings is critical for the overall energy consumption and meeting service level agreement.

For example, temperature has bidirectional impacts between cooling system and servers.

Keeping a DC in the higher temperature will make the energy consumption by cooling

system less while the performance of servers worse therefore more energy consumption.

How much positive impacts for cooling system and negative impacts for servers are now

known and finding the optimal temperature for a given forecasted workloads.


Project no: 734273 17 31/10/2017

- Simulation for the impact of shutting down VMs

XX data centre management team know that how to effectively balance the power load in

data centres is an issue that every data centre manager is familiar with. When done

correctly, a properly balanced data centre helps to secure uptime and is often an important

avenue for the facility to utilize extra power capacity. When improperly balanced, available

power can become stranded, and the chance of damage to vital infrastructure increases.

Taking the time to optimize power distribution when installing or refitting a data centre is well

worth the effort and is another crucial step toward maximizing its performance.

To help avoid stranding power, Melina can conduct simulation for shutting down the idle VMs

to reach the optimal balanced status through the Load Balancing interface in Simulation

Dashboard. If the simulation result shows the expected level of consumption, then she can

push the “Apply to System” button with the setting used for simulation.

- Simulation for the impact of different load balancing tools

How to use servers and VMs within DC affects the overall energy consumption as

overloaded devices are expected to consume energy unnecessarily. Different load balancing

tools are used to have even usage of servers and VMs for high level of workloads. However,

the performance of load balancing tools is different for different tools therefore data centre

managers would like to know what are the net amount saved (or wasted) for using alternative

load balancing tools.

- Simulation for the impact of postponing workloads

Different workloads have different priorities depending on who the requests come from and

when they are created. Therefore, postponing workloads with low priority can prevent

overloads of servers and VMs and save energy consumption. Melina would be able to set the

rules for delaying certain workloads. This setting includes the level of priority, the duration of

postponing, in certain case designate such workloads to certain VMs or servers. Melina then

check how much energy was saved and the impact to overall service level agreement.

- Simulation for Setting the Network Configuration

The last option for Melina is to set the network configuration again. She can open the

network configuration menu on the Simulation Dashboard. The menu presents the graphic

user interface with network structure and enables her to configure the parameter of each

network node to minimise the energy consumption so that she can check the expected

energy consumption according to the network configuration setting. If the simulation result

shows the expected level of consumption, then she can push the “Apply to System” button

with the setting used for simulation.


Project no: 734273 18 31/10/2017

Worst network configuration causes the network devices consumes more resources to make

the topology works well. Suggest that, there may be lots of repeated or duplicated firewall

rules to filter the network content; it will take too long time to compile and apply any network

packages from L2 to L7 corresponding policies. Regarding content weight, network devices

will consume more resources to handle and filter the whole network traffic. However, the

optimum network setup will handle the traffic and filter the packages in a fast and efficient

way.

2.3 GREENDC User Stories

User stories are used in agile software development techniques. By switching the

perspective to individual (though typecasted) users they are used as the basis for defining

the functional requirements that a system must entail and lay the foundation for the system

design. The user stories will follow this general scheme to demonstrate the user requirement:

As a <role> I want to <action> in order to <value/benefit>.

The following user stories have all been directly or indirectly inferred from the above

presented scenarios.

2.3.1. Monitoring of Energy Consumption User Stories

RM1 (Detect abnormal energy consumption). As a Group Member, I want to monitor the

energy consumption in order to check if any abnormal consumption pattern happens from

time to time.

RM2 (Reach to the event log). As a Group Member, I want to reach the event log of data

centre in order to take action to the change of energy consumption more efficiently.

RM3 (Daily energy consumption summary). As a Group Member, I want to see the daily

energy consumption summary in order to check the trend of energy consumption.

RM4 (Periodic reports). As a Group Leader (member), I want to get the periodic report

regarding energy consumption in order to plan the energy consumption schedule and to

manage the overall energy consumption trend.

2.3.2. Energy Consumption Forecasting User Stories

ECF1 (Forecast workloads). As a Group Leader, I want to reach the result of workloads

forecasting (daily/weekly/monthly) in order to prepare server capacity and required energy

sources.


Project no: 734273 19 31/10/2017

ECF2 (Forecast energy consumption). As a Group Leader, I want to reach the result of

energy consumption forecasting (daily/weekly/monthly) in order to cope with the change of

the energy consumption.

2.3.3. Simulation and Real-time Intervention User Stories

SR1 (Analyse parameter changes). As a Group Leader, I want to run a simulation to learn

the impact of changing the parameters (such as cooling temperature, workload, humidity,

etc.) in order to find an optimal option to minimise energy consumption.

SRI2 (Analyse VMs configuration). As a Group Leader or Member, I want to run the

simulation to learn the impact of shutting down VMs in order to find an optimal option to

minimise energy consumption.

SRI3 (Analyse load balancing tools change). As a Group Leader or Member, I want to run

the simulation to learn the impact of changing load balancing algorithms in order to find an

optimal option to minimise energy consumption.

SRI4 (Analyse workloads rescheduling). As a Group Leader or Member, I want to run the

simulation for rescheduling of workloads (postponing) energy consumption in order to find an


SRI5 (Analyse network configuration changes). As a Group Leader or Member, I want to

run the simulation for setting the network configuration in order to find an optimal option to

minimise energy consumption.


Project no: 734273 20 31/10/2017

3. GREENDC Architecture

3.1 Overall architecture

Figure 1. GREENDC DSS Architecture

The GREENDC DSS has three-tier architecture including data, business logic, and

user interface layers (see Figure 1 above). Each layer will provide Interfaces for upper

layer to make them independent from each other.


Project no: 734273 21 31/10/2017

Data layer has two sub layers: data collection layer and data normalisation layer.

Data collection layer includes components that interact with devices or third-party

tools that generate or provide data from DC devices including IT and non-IT facilities.

Data normalisation layer components convert the collected data into data model of

the GREENDC DSS.

Mathematical layer will contain components that conduct estimation and optimisation

of energy use of DCs. Two major components are created: estimation component

and optimisation component. Estimation component will provide services related to

estimating energy consumption of devices and DC as a whole. Optimisation

component will provide services related to optimising the operation of DCs by

manipulating intervention mechanisms including optimal temperature for a given

predicted workloads, number of VMs to be shut down for a given time period, the

duration and which workloads to be postponed in case of high workloads, and

identifying the best load balancing mechanisms in different circumstances.

Business logic layer contains components that will deal with requests coming from

user interface layer components. The components include user manager, DC

Monitoring, and DC Simulator. User manager component will deal with authorisation

and authentication of users as well as user profile management. DC Monitoring

component will provide data on the DC usage for a given period including energy

consumption, workloads, status of facilities (IT and non-IT), and management

reports. Finally, DC Simulator will allow users conduct diverse simulations to test the

effectiveness of different intervention mechanisms. They include the impact of

changing temperature of a DC, load balancing mechanisms, the number of active

VMs, postponing the certain types of workloads.

Finally, the user interface layer includes user interface components for easy and

efficient interaction with users. The user interface components will be designed to

minimise users’ interactions with the system. The components in the user interface

layer will use services provided by the business logic layer components.


Project no: 734273 22 31/10/2017

3.2 Interfaces

This subsection defines major Interfaces provided by the components in each layer

to allow sequence diagrams for each user story (see Figure 2 below).

Figure 2. Interface and three layers


Project no: 734273 23 31/10/2017

3.2.1 Business logic layer

There are three Interfaces to serve for the user stories.

Interface UserManager {

// Declare basics of CRUD functions of a User model

void createNewUser (UserProfile up);

void removeUser(String user_id);

void getUser(String user_id);

void setUser(String user_id);

void getUsers();

boolean authenticateUser(String user_id, String passwd);

List authorisedServices(String user_id, String role);

}

The UserManager Interface will reveal four public methods: createNewUser,

removeUser, authenticateUser and authorisedServices. The first two methods are

used to register and remove a user in the system. The third method will be used to

authenticate if a given user_d and passwd pair is registered at the user database of

the system. The final method will be used to check if a user has access rights for a

given role and if so a list of allowed services will be returned.

Interface MonitorDC {

LIst detectAbnomalConsumption(List devices, DateTime start, DateTime end);

List getEnergyLog(List devices, DateTime start, DateTime end);

List getDailyConsumptionSummary(List devices, DateTime start, DateTime end);

List getPeriodicReports(String type, DateTime start, DateTime end);

}

The MonitorDC interface will provide four methods for the user stories for monitoring

energy consumption of data centres respectively for RM1, RM2, RM3 and RM4.

Interface ForecastDC {

LIst forecastWorkloads(List devices, DateTime start, DateTime end);

List forecastEnergyConsumption(List devices, DateTime start, DateTime end);

}


Project no: 734273 24 31/10/2017

Likewise, two public methods are defined for two user stories for forecasting energy

consumption scenario. The first one will return a list of forecasted workloads for a

given list of devices (or data centre as a whole). The latter one will return forecasted

energy consumption for a given list of devices (or data centre) for specified periods.

Interface SimulateDC {

List analyseParametersChange();

List analyseVMsShutdown();

List analyseLoadbalancers();

List analyseWorkloadRescheduling()

List analyseNetworkConfigChanges();

}

Finally, SimulateDC interface allow data centre managers to test impacts of different

interventions for saving energy by DC devices. The five methods are for five user stories as

defined in section 2.3.3. For example, analyseParametersChange() will be used when a user

select SR1 user story.

3.2.2 Math model layer

Math Model Layer is composed of two interfaces as EstimationModel and

OptimisationModel. The EstimationModel Interface will reveal six methods.

Interface EstimationModel {

List DeviceInfo();

List DataInfo();

DefineForecastingParameters();

List GetHistoricalData();

List AbnormalData();

List EstResults();

}

The first two methods; DeviceInfo and DataInfo provide the required information

about data centre configuration for each user story. The first method, DeviceInfo is

used to get the information of devices concerning the historical data such as device

type, number of the device, device settings etc. from Data Layer. The second one,

DataInfo is used to obtain the information about data with reference to devices and


Project no: 734273 25 31/10/2017

the other measured data (i.e. room temperature and humidity) from Data Layer. This

information helps to specify historical data type for DefineForecastingParameters.

DefineForecastingParameters is used to define the forecasting parameters

corresponding with the user stories ECF1 and ECF2. For ECF1, data type of IT

devices (i.e. CPU usage, CPU temperature, network traffic etc.) and the related other

parameters such as temperature, day of week and time will be considered for

defining. For ECF2, the power consumption of IT devices, cooling and power

systems will be evaluated separately. Parameters will be defined related with each

part.

GetHistoricalData provides the historical data from Data Layer according to the user

stories; ECF1 and ECF2. Historical data will be reached between the given time

interval and time step. The historical data consists of the regarding data types of the

forecast workloads or the energy consumption of devices and data centre. They will

be identified in the previous method.

AbnormalData is used to examine the historical data as to whether ordinary data or

abnormal data for RM1 user story. If it detects abnormal data, it will give information

about the abnormal data contents.

Interface OptimisationModel{

List DeviceInfo();

List DataInfo();

DefineOptimizationParameters();

List GetEstResults();

List OptResults();

}

The OptimisationModel interface will provide five methods to optimise data centre

energy cost. The first two methods bring information about device and data settings

for SR1 user story. They give information to the other stories as well.

DefineOptimizationParameters prepares the Optimization parameters according to

the user stories. GetEstResults takes the estimated data related with the

Optimization parameters and OptResults presents the Optimization results.


Project no: 734273 26 31/10/2017

These methods are used for all user stories but required info of parameters varies by

each story. For example, cooling set temperature info, humidity info, outside

temperature info can be given by these methods for SR2 at the same time info about

VM to determine how many VMs are needed to be shut down or to change their

settings. CPU configuration and data priority are for SR2. Likewise, SR3 deals with

the load balancing parameters, SRI4 considers the workload rescheduling and SRI5

examines network configuration in order to minimise the energy consumption cost.

3.2.3 Data layer

In data layer, the data will be provided upon request payload parameters. There is

only one interface to interact with 3rd party components, Business Logic Layer and

Math Model Layer and two internal interfaces which are supposed to be used by

other Data Layer classes and interfaces. These interfaces will be called as:

Interface Collection{

Data collect_data(Data data,Source source,Consume consump);

}

Collection interface will communicate physical devices and collect consumption data

from data center’ resources by given parameters which are explained already by

following chapters.

Interface Serialize{

JSON serialize(Data data);

}

Serialize interface will serialize the data which means verify and correct the data to

store into database as much as pure, clean and secure. It takes a Data object and

serializes to a JSON object.

Interface Transaction{

Boolean post(JSON data);

JSON get(Query query);

Boolean put(Query query);

Boolean delete(Query query);

JSON bulk(Query query);

Query toQuery(JSON query);

Query sanitize(JSON query);

}


Project no: 734273 27 31/10/2017

This Interface allows us, as 3rd party components or other layers, to post, get, put,

delete data.

Transaction.post(JSON data)

This method takes JSON data from inbound interface which is called Serialize, and

cast the data into related ORM model based object on the architecture and insert into

NoSQL database as an entity. Since, it will be already defined in the database while

creating tables and defines relations between tables, it is not necessary to redefine

foreign relations and constraints while inserting new rows. Please see further details

about the entities and models mentioned above, are shown as ERD in following

chapter 4.2.2 Data Entities and Models.

Transaction.get(Query query)

The get method gathered the required data from the database and respond it in

usual sequence to the request. The request sent will have some mandatory and non-

mandatory fields inside.

Transaction.put(Query query)

The put method will update/edit the data upon request.

Transaction.delete(Query query)

This method, as it can be understood from its declaration, will delete regarding data

which is submitted by the request.

Transaction.bulk(Query query)

Bulk method is defined to bulk operations such as multiple get or multiple delete at a

time.

Transaction.toQuery(JSON query)

This method will help us to generate or create new query object based on the

payload which is submitted by Math Model Layer and Business Logic Layer upon

their needs and requirements. It takes JSON payload and convert it into a internal

Query object after the sanitize method is executed.

Transaction.sanitize(JSON query)

The sanitize method is declared to clear, secure and verify data which is need to be

before submitting to other methods or objects.


Project no: 734273 28 31/10/2017

The following flowchart (Figure 3) explains how-to data flows all the way from other

layers down to Data Layer.

Figure 3. Flow chart – Data Transmit between Layers

3.3 Sequence Diagrams for User Stories

This sub-section provides a list of sequence diagrams for the user stories defined in

section 2. The sequence diagrams will show how the components in each layer will


Project no: 734273 29 31/10/2017

interact with each other to serve the user stories. Also, this can verify that the

Interfaces defined in section 3.2 are complete to meet the requirements in section 2.

3.3.1 Monitoring energy consumption user stories

RM1. As a Group Member, I want to monitor the energy consumption in order to

check if any abnormal consumption pattern happens from time to time.

Figure 4. Sequence Diagram to detect abnormal energy consumption (RM1)

RM2. As a Group Member, I want to reach the event log of data centre in order to

take action to the change of energy consumption more efficiently.

Figure 5. Sequence Diagram to get event logs (RM2)

RM3. As a Group Member, I want to see the daily energy consumption summary in

order to check the trend of energy consumption.


Project no: 734273 30 31/10/2017

Figure 6. Sequence Diagram to get daily energy summary (RM3)

3.3.2 Energy Consumption Forecasting User Stories

ECF1. As a Group Leader, I want to reach the result of workloads forecasting

(daily/weekly/monthly) in order to prepare server capacity and required energy

sources.

Figure 7. Sequence Diagram to get workloads forecasting (ECF1)


Project no: 734273 31 31/10/2017

ECF2. As a Group Leader, I want to reach the result of energy consumption

forecasting (daily/weekly/monthly) in order to cope with the change of the energy

consumption.

Figure 8. Sequence Diagram to forecast energy consumption (ECF2)

3.3.3 DC Simulation User Stories

SRI1. As a Group Leader, I want to set the parameters (such as cooling, workload,

humidity, etc.) in order to forecast the energy consumption and make an intervention

individually.

Figure 9. Sequence Diagram to set simulator parameters (SRI1)


Project no: 734273 32 31/10/2017

SRI2 (Analyse VMs configuration). As a Group Leader or Member, I want to run

the simulation to learn the impact of shutting down VMs in order to find an optimal

option to minimise energy consumption.

Figure 10. Sequence Diagram to analyse VMs Configuration (SRI2)

SRI3 (Analyse load balancing tools change). As a Group Leader or Member, I

want to run the simulation to learn the impact of changing load balancing algorithms

in order to find an optimal option to minimise energy consumption.


Project no: 734273 33 31/10/2017

Figure 11. Sequence Diagram to analyse impact of load balancing (SRI3)

SRI4 (Analyse workloads rescheduling). As a Group Leader or Member, I want to

run the simulation for rescheduling of workloads (postponing) energy consumption in

order to find an optimal option to minimise energy consumption.


Project no: 734273 34 31/10/2017

Figure 12. Sequence Diagram to analyse impact of work migration (SRI4)

SRI5 (Analyse network configuration changes). As a Group Leader or Member, I

want to run the simulation for setting the network configuration in order to find an


Figure 13. Sequence Diagram to analyse network configuration operation (SRI5)


Project no: 734273 35 31/10/2017

4. Data Layer

4.1 Components Architecture

Figure 14. Component Architectures for Data Layer

4.1.1 Components Description of Data Layer

Data Layer is splitted into two segments above the physical segments:

1. Data Collection Layer(DCLr)

2. Data Normalization Layer(DNLr)

These layers have their own components inside to implement their duties. In the

diagram, components names do not match related classes, objects or interfaces;

they are named metaphorical, based on what they do. Such as Serialize component

will serialize the data which is collected by Collect component. Here is Data Layer

components and it is found by following paragraphs further details:


Project no: 734273 36 31/10/2017

DCLr Components: DNLr Components

1. Collect

2. Serialize

3. Insert Database(Transactions)

1. ORM

2. Normalizer

3. RPC Interface(Web

Service/REST)

Components & Class/Interface Relations(bottom to top):

Collect: It is one the major components, contains base fundamentals to collect data.

Here is related objects and interfaces (Figure 15):

● DataCenter class ● DCData class ● Source class ● Consumption class

● RawData class ● Data class ● Collection interface

Figure 15. Collect Component

Serialize: It aims to Serialize the data which is collected by Collect component and

make the data ready for database operations (Figure 16). Here are related objects:

● Data class ● Serialize Interface


Project no: 734273 37 31/10/2017

Figure 16. Serialise Component

4.2 Data collection layer

Data Collection Layer will collect data from variant devices such as UPS, Air

Conditioners, IT devices(switches, firewalls, LB, etc.) and also will gather data via 3rd

party software APIs such Zabbix or DCIM softwares. Those softwares have their own

communication methods such as REST or WSDL to submit data via HTTP, SNMP or

ModBus. There are regarding tables that show us recent DCIM tools register map

which contains addresses and fields on Appendix A.

As it can be seen on the Component diagram in section 4.1, DCLs has a component

which collect data from several sources. It will have the class and interfaces for

different protocols (Figure 17).

Figure 17. Data Collection Flow in Data Collection Layer


Project no: 734273 38 31/10/2017

As it can bee seen in the figure below, there are 4 methods in a single thread and

three of them are interfaces to collect, serialize and transact the data. Here is further

explanation about these four methods:

● Sources: Is a list to keep the object called Source which defines data source

of DC operations such as AC, Chillers, IT devices(switches, firewalls, load

balancers, etc.). This object model has its own attributes which are internally

declared. It has generic OOP methods such as getter and setter inside the

boundary.

● RawData: RawData is the one of the main objects while the main thread

collects data. RawData is an object which is gathered from Sources and it has

required variables and based on resource context.

● Collection: This interface will help us to collect data from sources by a

specific methods which is called collect_data. This method collects data and

forwards to the Serialize interface. Collection interface has private methods to

implement a connection between source objects and manages those

connections.

● Serialize: As an interface, Serialize, since it is already self-described, is an

serializer interface to build serialized data transformed into a structured well-

formed JSON data from raw data.

● Transaction: Transaction interface includes insert serialized data after

transformed it by Serialize into the database or an external interface(s).

The data collection strategies are as follows.

4.2.1 Workloads Allocation

All workloads are received by firewall devices to secure, clear and authorize the

traffic. Then, all packets coming from outbound network are transferred to the load

balancer appliances. Load balancing mechanism is based on some LB algorithms

but, since enterprise appliances are used to balance the traffic load, we do not need

to know which load balancing algorithms that is used inside the appliance. It is

https://en.wikipedia.org/wiki/Load_balancing_(computing)


Project no: 734273 39 31/10/2017

explained in their own data-sheets and benchmarks. It is should be preferred to pick

the best option based on the traffic load, network topology and needs of the data

centre.

Figure 18 shows a sample LB(F5) graph to examine connection request to served

URLs:

Figure 18. Sample Graph to examine connection requests to served URLs


Project no: 734273 40 31/10/2017

Sample F5 report:

Figure 19. Sample Reports for load per virtual machine

Figure 19 present the report that shows us total network load per virtual machines

(only 1 VM is shown) which comes from the clients by request.


Project no: 734273 41 31/10/2017

Although there should be physical appliance in front of the whole network topology, in

some cases it is better to use a load balancing software such as Nginx, HAProxy,

etc. What we do while implementing is an architecture must be keeping our

application(s) reliable, sustainable, highly available and secured. Thus, it might be

efficient choice to put a load-balancer to balance the traffic through the clustered data

stores or application servers. In the Figure 20 below it is shown that there only is

physical load balancer and it is left to the application team to discuss either they use

load balancer software or not:

Figure 20. Load Balancing Example

They are distributed to one of hosts within the server rooms as can be seen Figure 20.

There are three server rooms and each server room handles different service

requests. The allocation of workloads to hosts are based on load balancing

appliance. The total workloads for the DC room can be measured by getting load

balancer software reports.


Project no: 734273 42 31/10/2017

4.2.2 Data Entities and Models

There will be required entities to be stored in database. This entities will help us to get

historical and runtime data in order to supply forecast and analytics to the user.

The entity diagram is shown below (Figure 21) which is contained field names and their types

though:

Figure 21. Data Entity Diagram

Here is model implementation samples including attributes and methods below to

identify entity objects:

Class DataCenter{

Integer id;

String name;

String desc;

String location;

Date create_date;

Date edit_date;

Date delete_date;

List<DCData> dcdata;

}


Project no: 734273 43 31/10/2017

DataCenter entity object is designed to implement an actual Data Center model. It

has its own attributes to store what a real-world Data Center would had. Class DCData{

Integer id;

Integer dc_id;

Date create_date;

Date edit_date;

Date delete_date;

Integer humidity;

Integer temp;

}

DCData is an only entity to store Data Center measurement which are related with only

physical assets of the Data Center, not with racks or servers.

Class Source{

Integer id;

String make;

String model;

String firmware_version;

Date date_assembled;

Date create_date;

Date delete_date;

Date edit_date;

DataCenter dc;

Integer conn_protocol;

IPv4 conn_ip;

Integer conn_port;

HashMap register;

void set_make();

void set_model();

void set_firmware_version();

void date_assebled();

void set_proto();

void set_register();

…

…

…

}

Source model is designed to identify physical or virtual resources which consume

energy by based on their workloads including CPU, memory, storage and network

usages. Since it may vary upon physical devices or appliances have their own

vendors, it has to be identified that which resource had what attributes such as make,


Project no: 734273 44 31/10/2017

model, firmware, connection protocol, connection ip, connection port, date of

assembled and which data center it was assembled to.

Class Consumption{

Integer id;

String _type; // consumption type such as electricity, heat, etc.

Uint measure;

Date measer_date; // self-descriptive attribute

void set_date_measured();

void set_measure();

void set_type();

…

…

…

}

Consumption model is built based on consumption entity which is required to store

energy measurement values consumed by resources which is submitted by Collect

interface.

Class RawData{

Date date_get;

Source source;

Consumption consump;

void set_consume();

void set_source();

void set_timestamp();

…

…

…

}

RawData class is an internal object to cast objects into each other and bring together

into a single model. This model is not related any entity and will not be stored in

database though.

Here are other classes which will not be stored in the database but only used in

internal processes and threads written:

Class Data extends RawData{

Integer id;

HashMap values;

…

…


Project no: 734273 45 31/10/2017

}

Class Query extends HashMap{

String id;

String _type;

Date start_date;

Date end_date;

Integer id_datacenter;

Source source;

Integer source_type;

}

4.2.3 Energy and workloads data

Energy and workloads data will be collected from three different types of devices: IT,

Cooling, and Power (Figure 22).

Figure 22. Data Sources and Data Collector

Data collecting may vary for every single device in Data Center; besides

software/simulator must use required communication protocols such as SNMP and/or

ModBus to collect data from any cooling and power devices. On the other hand it is


Project no: 734273 46 31/10/2017

possible to retrieve data from such Open Source Softwares (Zabbix etc.) for IT

devices.

UPS:

A UPS is typically used to protect hardware such as computers, data centers,

telecommunicatin equipment or other electrical equipment where an unexpected

power disruption could case injuries, fatalities, serious business disruption or data

loss. We could collect data from UPS that is shown below (Figure 23).

Figure 23. Data Source - UPS

Smart PDU:


Project no: 734273 47 31/10/2017

Smart PDUs offer a higher level of monitoring at the device or outlet-level via an

Ethernet port. Smart PDUs offer the ability to configure outlets into up tos ix groups

an assign use group Access to specific outlets groups. Smart PDUs collect also

humidity and temperature values for each rack. Example of the smart PDUs interface

is shown below (Figure 24).

Figure 24. Smart PDUs Interface

Energy Meter:

An electric meter, an electric meter, or an energy meter is a device that measures the

amount of electric energy consumed by a resident, a business, or an electrically

powered device (Figure 25).

Figure 25. Energy Meter


Project no: 734273 48 31/10/2017

When energy savings are desired, some meters may measure demand, the

maximum use of power in some interval. "Time of day" metering allows for an

increase in electricity prices during the day, to record during peak high-cost periods

and off-peak, lower-cost, periods.

Power Monitoring is possible with modbus for energy meters. Examples are shown

below about interface and energy meters (Figure 26).

Figure 26. Power Monitoring through the Energy Meter

Generator:

In electricity generation, a generator is a device that converts motive power into

electrical power for use in an external circuit. Sources of mechanical energy include

steam turbines, gas turbines, water turbines, internal combustion engines and even

hand cranks. Generators provide nearly all of the power for electric power grids.

Generators are a key to data center reliability. Supplementing a battery-based

uninterruptible power supply (UPS) with an emergency generator should be

considered by all data center operators.


Project no: 734273 49 31/10/2017

Chiller:

A chiller is a machine that removes heat from a liquid via a vapor-compression or

absorption refrigeration cycle. This liquid can then be circulated through a heat

exchanger to cool equipment, or another process stream (such as air or process

water). As a necessary by product, refrigeration creates waste heat that must be

exhausted to ambience, or for greater efficiency, recovered for heating purposes.

Chilled water is used to cool and dehumidify air in mid- to large-size commercial,

industrial, and institutional facilities. Water chillers can be water-cooled, air-cooled, or

evaporatively cooled. Water-cooled systems can provide efficiency and

environmental impact advantages over air-cooled systems.

If chillers allow to watch their energy values, energy values which is needed can

monitor easily. otherwise energy meters can use to get energy data from chillers.

There is an example below about chillers interface Figure 27.

Figure 27. Chiller and Its Interface

Air Conditioner:

Air conditioning is the process of removing heat from the interior of an occupied

space, to improve the comfort of occupants. Air conditioning can be used in both

domestic and commercial environments. This process is most commonly used to

achieve a more comfortable interior environment, typically for humans or animals;

however, air conditioning is also used to cool/dehumidify rooms filled with heat-

producing electronic devices, such as computer servers, power amplifiers, data

centers etc.


Project no: 734273 50 31/10/2017

If air conditioners allow to watch their energy values, energy values which is needed

can monitor easily. otherwise energy meters can use to get energy data from chillers.

There is an example below about air conditioners interface (Figure 28).

Figure 28. Air Conditioner Interface

Server:

Currently following data is collected from each server through Zabbix API*. There is

some zabbix examples of energy consumptions for servers below (Figure 29).

Figure 29. Energy Consumption from Servers – Example from Zabbix


Project no: 734273 51 31/10/2017

There are four fundemental workload contents that affect the energy consumption of

servers. these,

● CPU time

Figure 30. Energy Consumption of Server – CPU level


Project no: 734273 52 31/10/2017

● Memory usage

Figure 31. Memory Usage and Energy Consumption

● File I/O

Figure 32. File I/O and Server Energy Consumption

● Network Traffic

Figure 33. Network Traffic and Energy Consumption

Server Room:


Project no: 734273 53 31/10/2017

Sensors or thermometers can measure temperature and humidity of the server room

every 5 minute.

4.2 Data normalization layer

How to collect data is explained in section 4.1. However, collecting data is the

fundamental process of data layer. Data normalization is another operation to make

data available for any authorised request. Therefore, we need to implement a

generic-data normaliser and publish it into an API or SOA object.

Since we have an opinion to store the data in a schema-free structured data in

NoSQL datastore. By this approach, we will not need sophisticated and complicated

methods or entities in our architecture.

By this layer, we will have an ORM(Object Relational Mapping) library such as

Hibernate(Java) or SqlAlchemy(Python) or Doctrine(Php). This library helps us to

manage connection operations like open-close connections; execute SQL

statements, handle result-sets retrieved from database; map object models(classes)

with database entities. Create table from source code instead of SQL scripts. Using

an ORM library may increase development or production lifecycle. See a basic

Python model implementation to sample DSS data:

Class Consumption(Base):

__tablename__ = "tbl_consume_mtrx"

Id = Column(Integer, primary_key=True)

_type = Column(Integer, ForeignKey("tbl_consume_types", cascade="all, delete"))

measure = Column(Float, nullable=True)

date_measured = Column(DateTime, nullable=False, default=text('NOW()')

…

…

…

As it is seem above, we only need to declare a class as a model with its attributes

and ORM will create required tables, relations, entities, etc. The declaration of a


Project no: 734273 54 31/10/2017

model will create an entity in the database with its attributes shown as below ERD

(Figure 34):

Figure 34. ERD – Consumption and Its Types

The fields declared above are only suggestions. Real fields will be defined based

upon real data retrieved from DCLr.

ORM transactions will transmit the data to the Normalization class, which is a sub-

layer between ORM and RPC interface (Figure 35).

Figure 35. ORM Transaction and RPC Interface

RPC interface responds data in required format to any requester component (class or

interface). Basically, it is assumed that that responded data might be in JSON format

or WSDL. It depends on what is required upon Mathematical layer interface or 3rd

party component or software. This interface will transmit data to external pipes

outside of the Data Layer. RPC response may probably be like below:

{

code: 200, // should be based on HTTP status codes which are globally standard by

Client-Server conventions

msg: "Status OK" //

content: {

data: {

...


Project no: 734273 55 31/10/2017

}

}


Project no: 734273 56 31/10/2017

5. Math Model Layer

This section describes the algorithm of the forecasting and optimization process in

GreenDC DSS interface. In the next section forecasting process of the DSS is briefly

explained. In section 5.2 optimization process is detailed. In the last sections class

structure and sequence diagrams of math model layer is explained.

5.1. Forecasting Method:

The required workflow diagram for forecasting process is explained in Figure 36.


Project no: 734273 57 31/10/2017

Figure 36. Flowchart for Forecasting Process


Project no: 734273 58 31/10/2017

Firstly, the user selects the energy consuming/generating devices (IT, Cooling,

Power Units) that will be estimated in DSS. According to the selected devices and

data type, the required data are called from Data Layer. In Data Layer historical data

is converted to normalized data through normalization process. After that, time

duration and resolution are selected by the user. Time duration setting is defined the

start and end time of estimation and resolution is frequency of the duration. After

settings are done, Forecasting method is selected whether Neural Network or

Regression. Both forecasting methods are explained separately. If Neural Network

Model is selected, the steps of the flowchart shown in Figure 37-a are followed. If the

Regression Model is selected, the steps of the flowchart shown in Figure 37-b are

followed.


Project no: 734273 59 31/10/2017

Figure 37. Flowcharts of Forecasting Models

For Neural Network Method, firstly, the input and target data are determined. After

time interval and resolution of data are determined neural network will run for each

device of IT equipments, cooling or power units separately or together. Data layer

provides historical data of each device parameters which are input data and the

measured power consumption of that device which is the target data. With this

method the aim is to create a network to estimate power consumption of each device


Project no: 734273 60 31/10/2017

under certain conditions. For example if we want to create a network for a server

power consumption, which is one of IT equipment, input and target data imported

from historical data can be defined as follows (Table 1):

Table 1. Sample Data Set For Neural Network

CPU Input data Target

historical

data

CPU usage CPU

temperature

RAM usage etc. P_server

training

data

val val val val val

val val val val val

val val val val val

val val val val val

... ... ... ... ...

test data

val val val val val

... ... ... ... ...

These data are divided as training and test data. After that Neural Network

architecture is identified with the number of neurons for inputs and outputs and

number of hidden layers and network is created. The network is trained and if results

satisfy, network is simulated. As a result of the simulation, the data to be estimated

like 𝑃𝐼𝑇 , 𝑃𝑐𝑜𝑜𝑙𝑖𝑛𝑔,𝑃𝑝𝑜𝑤𝑒𝑟_𝑢𝑛𝑖𝑡𝑠 are calculated.

Similarly, in Regression method, required historical data are obtained as inputs from

data layer. Then, regression parameters and regression type are defined. There are

different types of regression techniques in the literature to make estimates. These

techniques are usually based on three metrics that are type of dependent variables,


Project no: 734273 61 31/10/2017

number of independent variables and shape of regression line. Since we have a

polynomial function depending on outside temperature, set temperature and IT load,

we will use polynomial regression technique to forecast 𝑃𝐼𝑇 , 𝑃𝑐𝑜𝑜𝑙𝑖𝑛𝑔, 𝑃𝑝𝑜𝑤𝑒𝑟_𝑢𝑛𝑖𝑡𝑠

which are represent power consumption of IT, power consumption of Cooling Units

and power consumption of Power Units respectively. For example, the equation of

energy consumption of cooling is shown as:

𝑃𝑐𝑜𝑜𝑙𝑖𝑛𝑔,𝑡 = ∑

𝑐_𝑑𝑛

[ 𝑎0 + (𝑏1,𝑡 𝑋1,𝑐_𝑑𝑛,𝑡 +𝑏2,𝑡 𝑋2,𝑐_𝑑𝑛,𝑡 + ⋯ + 𝑏𝑐_𝑝𝑛,𝑡 𝑋𝑐_𝑝𝑛,𝑐_𝑑𝑛,𝑡)

+ (𝑐1,𝑡 𝑋1,𝑐_𝑑𝑛,𝑡 +𝑐2,𝑡 𝑋2,𝑐_𝑑𝑛,𝑡 + ⋯ +𝑐𝑐_𝑝𝑛,𝑡 𝑋𝑐_𝑝𝑛,𝑐_𝑑𝑛,𝑡)2]

a, b and c represent constant. Required historical data such as room temperature,

outdoor temperature, delivery air temperature, chilled water temperature, room

relative humidity etc. are indicated by (𝑋1,𝑐_𝑑𝑛,𝑡 + 𝑋2,𝑐_𝑑𝑛,𝑡 + ⋯ + 𝑋𝑐𝑝𝑛,𝑐𝑑𝑛,𝑡). There are

similar equations to calculate energy consumption of IT and power units. After

solving each polynomial equation to forecast 𝑃𝐼𝑇 , 𝑃𝑐𝑜𝑜𝑙𝑖𝑛𝑔, 𝑃𝑝𝑜𝑤𝑒𝑟_𝑢𝑛𝑖𝑡𝑠, forecasted

results are obtained.

5.2. Optimization Method:

The main objective of GREENDC DSS tool is to minimize the electric energy

consumption cost of data centre by incorporating into the energy market. Thus, the

objective function is formulated with two parts; energy consumption cost of DC and

the profit from demand side participation.

The objective function

The two parts of objective function are 𝐸𝑐𝑜𝑠𝑡𝐷𝐶 and 𝐸𝑝𝑟𝑜𝑓𝑖𝑡𝐷𝑆𝑀 which are explained

in detail below. 𝐸𝑐𝑜𝑠𝑡𝐷𝐶presents the energy consumption cost of DC and 𝐸𝑝𝑟𝑜𝑓𝑖𝑡𝐷𝑆𝑀

is the profit from demand side participation.

min 𝐶𝑜𝑠𝑡𝐷𝐶 = 𝐸𝑐𝑜𝑠𝑡𝐷𝐶 − 𝐸𝑝𝑟𝑜𝑓𝑖𝑡𝐷𝑆𝑀


Project no: 734273 62 31/10/2017

𝑠. 𝑡. ∑

𝑡

𝑃𝑢𝑝𝑠_𝑔,𝑡 + 𝑃𝑏𝑎𝑐𝑘𝑢𝑝_𝑔,𝑡 + 𝑃𝑔𝑟𝑖𝑑,𝑡 − (𝑃𝑠𝑒𝑟𝑣𝑒𝑟,𝑡 + 𝑃𝑠𝑡𝑜𝑟𝑎𝑔𝑒,𝑡 + 𝑃𝑛𝑒𝑡𝑤𝑜𝑟𝑘,𝑡 + 𝑃𝑐𝑜𝑜𝑙𝑖𝑛𝑔,𝑡

+ 𝑃𝑢𝑝𝑠𝑐,𝑡 + 𝑃𝑏𝑎𝑐𝑘𝑢𝑝_𝑔𝑐,𝑡) = 0

𝑚𝑖𝑛𝑣𝑎𝑙𝑢𝑒 < 𝑃𝑢𝑝𝑠,𝑡 < 𝑚𝑎𝑥𝑣𝑎𝑙𝑢𝑒

𝑚𝑖𝑛𝑣𝑎𝑙𝑢𝑒 < 𝑃𝑏𝑎𝑐𝑘𝑢𝑝 < 𝑚𝑎𝑥𝑣𝑎𝑙𝑢𝑒

𝑚𝑖𝑛𝑣𝑎𝑙𝑢𝑒 < 𝑃𝑠𝑡𝑜𝑟𝑎𝑔𝑒 < 𝑚𝑎𝑥𝑣𝑎𝑙𝑢𝑒

𝑚𝑖𝑛𝑣𝑎𝑙𝑢𝑒 < 𝑃𝑐𝑜𝑜𝑙𝑖𝑛𝑔 < 𝑚𝑎𝑥𝑣𝑎𝑙𝑢𝑒

𝑚𝑖𝑛𝑣𝑎𝑙𝑢𝑒 < 𝑇𝑒𝑚𝑝𝑒𝑟𝑎𝑡𝑢𝑟𝑒𝑠𝑒𝑟𝑣𝑒𝑟 < 𝑚𝑎𝑥𝑣𝑎𝑙𝑢𝑒

𝑃𝑢𝑝𝑠_𝑔,𝑡 + 𝑃𝑏𝑢𝑔_𝑔,𝑡 + 𝑃𝑔𝑟𝑖𝑑,𝑡 − (𝑃𝐼𝑇,𝑡 + 𝑃𝑐𝑜𝑜𝑙𝑖𝑛𝑔,𝑡 + 𝑃𝑢𝑝𝑠𝑐,𝑡 + 𝑃𝑏𝑢𝑔𝑐,𝑡 ) = 0 𝑓𝑜𝑟 𝑒𝑎𝑐ℎ "𝑡"

where,

𝑃𝑢𝑝𝑠,𝑡 is the consumed or generated power by UPS at t.period.

𝑃𝑏𝑎𝑐𝑘𝑢𝑝,𝑡 is the consumed or generated power by back-up units.

𝑃𝑔𝑟𝑖𝑑 is the provided power from grid.

𝑃𝑛𝑒𝑡𝑤𝑜𝑟𝑘,𝑡 , 𝑃𝑠𝑡𝑜𝑟𝑎𝑔𝑒,𝑡 , 𝑃𝑠𝑒𝑟𝑣𝑒𝑟,𝑡 are the consumed power by IT equipment of DC.

𝑃𝑐𝑜𝑜𝑙𝑖𝑛𝑔 is the consumed power by cooling units.

Energy consumption cost of DC (𝐸𝑐𝑜𝑠𝑡𝐷𝐶) can be formulated as follows;

𝐸𝑐𝑜𝑠𝑡𝐷𝐶 = ∑(𝑃𝑢𝑝𝑠,𝑡 ∗ 𝑀𝑢𝑝𝑠,𝑡)

𝑡

+ ∑(𝑃𝑏𝑎𝑐𝑘𝑢𝑝,𝑡 ∗ 𝑀𝑏𝑎𝑐𝑘𝑢𝑝,𝑡)

𝑡

+ ∑(𝑃𝑐𝑜𝑜𝑙𝑖𝑛𝑔,𝑡 ∗ 𝑀𝑐𝑜𝑜𝑙𝑖𝑛𝑔,𝑡)

𝑡

+ ∑[(𝑃𝑠𝑒𝑟𝑣𝑒𝑟,𝑡 + 𝑃𝑠𝑡𝑜𝑟𝑎𝑔𝑒,𝑡 + 𝑃𝑛𝑒𝑡𝑤𝑜𝑟𝑘) ∗ 𝑀𝑢𝑝𝑠,𝑡]

𝑡

𝐸𝑐𝑜𝑠𝑡𝐷𝐶 consists of the energy consumption cost of IT (server, storage and network)

and non-IT devices (ups, backup unit and cooling) in DC. Their energy consumption

can be calculated with their consumed power in t time period (i.e.𝑃𝑠𝑒𝑟𝑣𝑒𝑟,𝑡), and its unit

energy cost (i.e.𝑀𝐼𝑇,𝑡).


Project no: 734273 63 31/10/2017

Every device type has its parameters and its model. They are constituted from device

and data information settings and the historical data by the forecasting model.

The consumed power of each device, modelled by nonlinear regression method, can

be calculated with the related parameters determined from the forecasting methods.

For example, the consumed power of the servers can be calculated as follows:

where a, 𝑏 and 𝑐 are the constants that previously modelled related with the server

characteristics and the historical data parameters, (𝑋1,𝑠_𝑑𝑛,𝑡 + 𝑋2,𝑠_𝑑𝑛,𝑡 + ⋯ + 𝑋𝑠𝑝𝑛,𝑠𝑑𝑛,𝑡)

is the server parameters specified from the historical data parameters. s_pn is the

number of server parameters, s_dn is the number of server and t is time period. Such

server parameters are CPU temperature, CPU usage, RAM usage etc.

Similarly for UPS, power equation can be written as follows:

as in the servers 𝑎 , 𝑏 and 𝑐are the constants that previously modelled related to the

historical data parameters, (𝑋1,𝑢_𝑑𝑛,𝑡 + 𝑋2,𝑢_𝑑𝑛,𝑡 + ⋯ + 𝑋𝑢,𝑢𝑑𝑛,𝑡) is the UPS parameters

specified from the historical data parameters. u_pn is the number of UPS

parameters, u_dn is the number of UPSs and t is time period. Parameters of UPS are

input voltage, frequency, current, total active and apparent power; bypass voltage,

frequency, current, total active and apparent power, nominal output rating, output

voltage, frequency, current, peak output current, total active and apparent power;

UPS installation load percentage, estimated charge time of battery, battery system

temperature, battery power, available amp hours etc.

Power consumption for cooling can be calculated as follows and it may have different

parameters depending on the system;


Project no: 734273 64 31/10/2017

For example if it is a water cooled chiller system, the parameters are room

temperature, outdoor temperature, delivery air temperature, chilled water

temperature, room relative humidity etc. Formulations for each device can be created

in this way to model energy consumption of DC most properly.

Second part of objective function, 𝐸𝑝𝑟𝑜𝑓𝑖𝑡𝐷𝑆𝑀 , the profit from demand side

participation, can be formulated as follows;

where each part has saving power, which can be calculated with their

operation conditions and constraints at a time period t. Power of each part has some

unit price given by energy market.

5.3. Class Structure of Math Model Layer

Math Model Layer interconnects with Data Layer and Business Logic Layer. Class

structure of Math Model Layer composes with two main parts; Data Preparation and

Math Model as shown in Figure 38. Data Preparation part has five classes which are

MathDeviceSetup, MathDeviceList, MathDataSetup, MathDataFlowSetup,

MathDataFlow and Math Model part consists of two classes: MathForecasting,

MathOptimization.


Project no: 734273 65 31/10/2017

Figure 38. Class Structure of Math Model Layer

MathDeviceSetup class is identified the device setup concerning the estimation and

optimisation methods. This class will contribute to understand properties and

information such as device type, limits, status etc. It does not represent physical

setup of the device. Math Model Layer gets to know all devices of data centre with

this class.

Each device has its attributes; name, type and ID. DeviceName, DeviceID and

DeviceType member represent these attributes respectively. Device type can be

considered as UPS, Backup generator, server, storage etc. DeviceID is unique

member of MathDeviceSetup class. An information of device related to this class is

obtained via DeviceID. Devices can be grouped as generating (back-up generator),

consuming (servers, storages etc.) and both generating and consuming device (UPS

etc.) according to energy flow direction. IsConsuming and IsGenerating member will

be used to get energy flow direction. StartUpEnergy member corresponds to

consuming energy while initialization of the device. DeviceStatus member shows us

whether device in use or not. The class includes minimum and maximum energy

consumption and/or generation information. If the device is only energy consuming

device, minimum and maximum energy generation of the device should be zero. On

the other hand, if the device is only energy generating device, minimum and


Project no: 734273 66 31/10/2017

maximum energy consumption of the device should be zero. StartUpTime member

mean that required time during initialization. In the same way, ShutDownTime

represents elapsed time until completely close. In addition, the class has lower and

upper temperature limit information of the device.

Class MathDeviceSetup{

int Device_ID;

string DeviceName;

string DeviceType; //UPS, Back-up generator, server, storage etc.

boolean IsConsuming;

boolean IsGenerating;

double StartUpEnergy;

double NoLoadEnergyInput;

boolean DeviceStatus;

double MinEnergyConsumption;

double MaxEnergyConsumption;

double MinEnergyGeneration;

double MinEnergyGeneration;

double StartUpTime;

double ShutDownTime;

double LowerTempLimit;

double UpperTempLimit;

DeviceSetup()

}

MathDeviceList class represents the list of all devices in data centre. List will be

created with Device_ID of all devices as an array. The class also includes number of

device in data centre.

Class MathDeviceList{

int[] Device_ID;

double NumberofDevice;

MathDeviceSetup[] DevicesSetup;

DeviceList()

}


Project no: 734273 67 31/10/2017

MathDataSetup class provides general information about data unit, availability status

(IsAvailable). This class also provides understanding of data source type (UPS,

server etc.) and data type (temperature, power, workload, etc.). DeviceType and

DataType represents these parameters, respectively. Each data has data ID

(Data_ID) and required parameter of the related data setup obtained by this ID. Data

can be used in math model parts; forecasting and/or optimization . UseInEst and

UseInOpt define data usage in math model parts. The last three boolean variables

are used to identify control variables of optimization function (Power unit, Cooling

and/or IT). Data_ID is unique member of MathDataSetup class.

Class MathDataSetup{

int Data_ID;

string DataName;

int DeviceID;

string DataType; // Temperature, power, workload, Network traffic, CPU usage

etc.

string DeviceType; //UPS, Back-up generator, server, storage etc.

string DataUnit;

boolean UseInOpt;

boolean UseInEst;

boolean IsAvailable;

boolean DataOptPower;

boolean DataOptCooling;

boolean DataOptIT;

Dataetup()

}

MathDataFlowSetup class corresponds to time information of data acquisition (start

time, end time, time step). This class determines starting and end time of flowed data

from data layer via DataFlowSetup() constructor method.

Class MathDataFlowSetup{

int DeviceID;

int DataID;

string DataType;


Project no: 734273 68 31/10/2017

string DataName;

double StartTime

double EndTime;

double TimeStep;

DataFlowSetup();

}

MathDataFlow class specifies data flow features. TimeStamp is an real time

information about acquisition of the data. CheckBit controls data integrity. If there is

no measurement or misinformation belong to this data, CheckBit will be zero

otherwise one. Data value can be queried by ID from different function.

DataFlowSetup() is used to get flow setup information. GetDataFlow() method gets

data flow information from data layer and sets member of the class.

Class MathDataFlow{

int DataID;

double TimeStamp;

double DataValue;

boolean CheckBit;

DataFlowSetup();

GetDataFlow();

}

MathDataSetup, MathDataFlowSetup and MathDataFlow classes mentioned above

are generic for all acquired data type.

MathForecasting and MathOptimasation classes include parameters and methods

related to forecasting and Optimization, respectively.

Firstly, input parameter is determined in order to forecast user-defined parameters in

a forecasting operation. Input parameters consist of various data type such as

temperature, network traffic, power etc. FCInputParamsID_List is an array composed


Project no: 734273 69 31/10/2017

of data ID of required input parameters. There are two types of time information in

this class. The first one represents time duration and time step for historical data. The

second one represents desired timeframe of the forecast and time step.

HistoricalDataSetup() method specifies the historical data. Getting of historical data

related to input parameters is executed by means of GetHistoricalData() method in

the class. Neural Network and Regression will be used for forecasting.

FCMethod_NN() and FCMethod_Reg() functions execute these forecasting methods.

RunForcasting() function perform forecasting operation according to selected

methods. Forecasting results can be showed in a routine by using FCResults()

methods.

Class MathForecasting{

double[] FCInputParamsID_List; //includes Data_ID

/* Start time,end time and time step information acquired from data preparation interface

*/

double HistData_starttime;

double HistData_endtime;

double HistData_timestep;

double FCtOutputParamID; //. It represents data type.of objective

double FCData_starttime;

double FCData_endtime;

double FCData_timestep;

DefineForecastingParameters(); //Required parameters for forecasting

HistoricalDataSetup(); //specifies the historical data

List GetHistoricalData();

double FCMethod_NN (); //Forecasting Method-1

double FCMethod_Reg (); //Forecasting Method-2

RunForecasting(); //Perform selected forecasting

method.

List FCResults();

}


Project no: 734273 70 31/10/2017

MathOptimization class includes required optimisation parameters and methods.

Input parameter types (temperature, power etc.) have to be determined before

optimization execution. OptInputParamsID_list is the list of data ID of optimisation

input parameters. It can be reached data type of input parameters via this ID list.

Output parameter ID (OptOutputParamID) is used for identifying data type of output

parameter as in MathForecasting class. Numerical normalized data of input

parameters are obtained in GetEstimatedData method via OptInputParamsID_list.

OptPower, OptCooling and OptIT members identify control variables of optimization

function. Two methods will be used for optimization. Methods will be decided in

progress. Constraints of optimization problem are taken from MathDeviceSetup in

DefineConstraints(). Optimization results can be listed by using OptResults() in a

routine.

Class MathOptimization{

/* OptInputParamsID_List defines list of input parameter types for optimastion. It

includes Data_ID information */

double[] OptInputParamsID_List;

/*OptOutputParamID defines output parameters type for optimastion. It includes

Data_ID information */

double OptOutputParamID;

/*identify control variables of Optimization function*/

boolean OptPower;

boolean OptCooling;

boolean OptIT;

DefineOptimizationParameters();

DefineConstraints(); //These constraints are taken from

MathDeviceSetup.

GetOptParameterList();

List GetEstimatedData();

double OptMethod1 ();


Project no: 734273 71 31/10/2017

double OptMethod2 ();

RunOptimization ();

List OptResults();

}

5.4. Sequence Diagram of Math Model Layer

The Math Model Layer consists of two sublayer which are Data Preparation and Math

Model. The Math Model has two subsections: Forecasting and Optimization. Each

section is expressed in different colours for easy understanding. As shown figure 10,

Data preparation Layer is represented by purple colour. The forecasting section is

indicated by red colour and the optimization section is represented by blue colour.

The arrows providing the information flow are represented by the color of the section

where the arrow goes. For example, to define optimization parameters, GreenDC

DSS need to know the info are taken from DeviceSetup,DataSetup and EstResult .

Because of these info are related with optimization section the arrows which

represent info flows are represented by blue colour. Although, DeviceSetup and

DataSetup functions send data to the forecasting section, data flow is represented by

red colour.

5.4.1 Data Preparation for Math Layer

Data preparation for math layer section provide the required information to

forecasting and optimization sections. The historical data which include device type,

number of device, device settings, room temperature, humidity etc. are provided by

Data Layer to Data preparation section. List DeviceInfo and List DataInfo functions

are used to obtain these data. DeviceSetup and DataSetup functions identify the

devices and data specifications and set the relevant setup information of devices and

data for the estimation and optimization methods. The DataFlowSetup function is

used to specify historical data flow. List GetDataFlow function is used to get the

specified historical data list from data layer.

5.4.2. Forecasting

Sequence Diagram of Math Model Layer for forecasting is shown in figure 10. As

shown in Figure 39, firstly, DefineForecastingParameters and HistoricalDataSetup

functions are used to take and define the data from DeviceSetup and DataSetup for


Project no: 734273 72 31/10/2017

each forecasting parameters such as:. CPU usage, CPU temperature, network traffic,

room temperature, day of week etc.

Figure 39. Sequence Diagram of Math Model Layer for forecasting

List GetHistoricalDataSetup function is used to get specified data from list

GetDataFlow and helps to DataFlowSetup to specify historical data which required

for FC Methods. FCMethod1 and FCMethod2 represent the Neural Network and

Regression methods and these functions execute the forecasting method that is

selected by user. According to selected methods, forecasted data are calculated and

results are sent to the Business Logic Layer by CalculateFC and List FCResults.


Project no: 734273 73 31/10/2017

5.4.3. Optimization

In Figure 40, Sequence Diagram Of Math Model Layer for Optimization is shown.

DefineOptimizationParameters takes information about devices and data settings

from DeviceSetup and DataSetup.

Figure 40. Sequence Diagram of Math Model Layer for Optimization

Input parameters are determined in this function. Estimated data needed for

optimization are provided by List FCResults by means of List GetFCResults.

Optimization Parematers values and its constraints are defined in

OptimizationParameterSetup function. One of optimization method is chosen by user

and according to selected method, optimization tool executed and results are

obtained. List OptResult function sends the results to Business Logic Layer.


Project no: 734273 74 31/10/2017

6. Business Logic Layer

The business logic layers include components that provide services required by the

components of the user interface layer.

6.1 UserManager

The major responsibility of UserManager component is to authenticate users and

ensure service access based on their roles. In this section we describe the user

authentication mechanism to be used by the GREENDC DSS when invoking

operations on the web services provided by the application server. The process of

Authentication means to verify that a specific entity is who or what it claims to be. In

other words, authentication is the verification of an identity containing at least an

identifier. Authentication can also be understood as the process of establishing

confidence in the authenticity of a claim made by an entity.

Authentication requires the usage of at least one authentication factor. Authentication

factors commonly are classified in three categories:

● something you know (password, personal identification number (PIN),

symmetric or asymmetric cryptographic key)

● something you have (smartcard, other hardware tokens)

● something you are (biometric data such as iris, fingerprint)

In order to increase the strength of the authentication, several authentication factors

can be combined. Commonly known examples are a PIN or a signature for your bank

card or the PIN in conjunction with your SIM-Card to authenticate towards a mobile

phone network.

The National Institute of Standards and Technologies (NIST) has defined 4

assurance levels in (NIST 2008) that should be considered in the design of the

GREENDC DSS:

● Level 1: Little Confidence - allows all kinds of authentication and provides little

or no confidence in the authentication such as username and password.

● Level 2: Some Confidence - still allows single factor authentication but

demands encryption.


Project no: 734273 75 31/10/2017

● Level 3: High Confidence - requires multi-factor authentication using highly

secure authentication factors such as biometrics or one-time passwords.

● Level 4: Very High Confidence - provides the highest possible level of

confidence and requires hardware tokens, multi-factor authentication and hard

cryptography.

There will be two logical entities involved to handle user authentication:

● Authentication Domain: Handles the authentication of the requesting principal.

● Identity Token Issuance Domain: Issues identity tokens and using the protocol

specific communication between the end-user and the relying party (RP).

The authentication domain includes all necessary components, functions and

capabilities to authenticate a user or other external entities. It includes several

classes of functions coordinating and performing the authentication. These functions

perform all necessary processes to determine the identity of an external entity that

requests access to the identity manager's functionalities. Beyond the mere

authentication process, the functions determine and express the level of trust in the

assurance of the identity gained by a successful performance of authentication

processes and hold that knowledge in a context which can be re-used for

authenticating further interactions as long as it is valid (Figure 41).

Figure 41. Logical entities for the authentication domain

The Authentication Controller summarizes the capacities to determine and keep an

authentication context based on a previous successfully conducted authentication


Project no: 734273 76 31/10/2017

process. This authentication context should include data about the time of

authentication, the methods of authentication, time of the validity of the authentication

and information about the level of trust. The controller has to possess knowledge

about all available authentication methods and the level of trust those methods

justify. The functions performing authentication control have to determine if an entity

requesting access has a previously established valid authentication context and if the

authentication context meets the respective security requirements. If not, the

authentication control has to determine which of the available authentication methods

or which combination of authentication methods would be sufficient.

The Authentication Selector is a capability that determines which specific

authentication method will be used for authenticating the user/service. The selection

is based on the results of the authentication controller, i.e. the selector has to perform

a selection or it offer a pre-selected scheme based on the set of authentication

methods determined by authentication control to be sufficient. If the principal

requesting authentication is a web service client, regardless whether it is an UA

wielded by a human end user or a service, authentication selection is done implicitly.

Therefore, the web service clients have to attach authentication credentials to the

initial request in order to receive an identity token.

The Authentication Executor represents the concrete implementation of an

authentication method. It is separated from the controller and the selector in order to

be generic, distributable and extensible to support a wide variety of different

authentication methods (X.509 certificates, username/password, SAML, etc.). This

design also provides the feature to implement each authentication method in a

physically distinct entity and being dynamically deployable and un-deployable.

Furthermore, an executor might be implemented and deployed in an external domain

(e.g. using a specific authentication method from business partner who operates as

an Identity Provider). In the mentioned scenario, neither the operator nor the token

provider will relinquish control over their infrastructure to the other.

User Authentication in the GREENDC project will be based on the brokered

authentication and heavily rely on the WS-Security specification, more precisely WS-

Trust and WS-SecureConversation, respectively. The authentication process

includes two levels of authentication: (1) authentication against the STS and (2)


Project no: 734273 77 31/10/2017

“anonymous” authenticated, secure conversation at the GREENDC service level

(using a so called “Communication Manager”). This approach separates the real

identity of the end user from the identity that is used inside of the GREENDC DSS,

allowing for a more finely granulated and flexible architecture in terms of security,

privacy and extensibility.

There will be a single web service operation dedicated to authentication. When

authentication is successful a security token is returned. This token needs to be

passed as an argument to all other operations that require previous authentication.

On the server side, the token is then used as key to the session data for the user.

The design also considers supporting Web Service Federation later on. To do so, the

realization of the identity and security manager‟s respective communication endpoint

for secure, session-based conversation leads to the implementation of an ITF-WS for

both WS-Trust and WS-SecureConversation. Depending whether the mobile

application fully/partially supports WS-* or not, a fully set/subset of the specifications

or just the general approach will be implemented. This ITF-WS fill be called Security

Token Service (STS).

The STS offers at least one method by the description of the web service via a

WSDL file which also contains a list of supported authentication methods or

authentication profiles:

● public void authenticate();

The method is called by the client who sends Request Security Token (RST)

message in form of an authentication request to the STS. In case of a successful

authentication, the STS issues a Security Context Token (SCT) to the client by

responding with a Request Security Token Response (RSTR) message. The SCT is

used by the client to request a session token from the STS in order to communicate

with the intended GRENDC service. The submitted credentials are included in the

SOAP request due to the concept of message layer security. The issued tokens,

attributes or error codes are included in the appropriate SOAP response.

The user authentication itself will be executed in the authentication domain, namely

one of the provided Application Functions. The authentication is triggered by the STS

which sends an authentication request to the AF. The AF that will be invoked

depends on the type of authentication that is in use. That means that different


Project no: 734273 78 31/10/2017

authentication operations need to be invoked (and implemented on the server side)

for different types of authentication.

We now introduce as examples two types of authentication:

a) Authentication with username and password.

b) Authentication with client certificates.

These two types of authentication are described in the following sections. As only the

initial request requires an authentication, all other web service operations do not

require to authenticate again. This will make the SSL connections between the client

and the server more lightweight, improving performance and lowering request

latency.

To obtain the token the mobile application invokes an operation that performs the

authentication using a username and password. Therefore, the client generates an

RST that contains a UsernameToken. In order to create the token, this operation

expected two arguments: username and password. It will return the SCT upon

successful authentication, or an error status. The SCT will be used in a subsequent

request to obtain a service token from the STS.

In the following paragraphs, we sketch a possible AF implementation of the operation

on the identity manager. The AF needs to invoke AuthManager.authenticate(...) with

the appropriate credentials object. The implementation of the operation obtains a

reference to the AuthManager object through a dependency injection mechanism.

In the scenario where authentication requires username and password, the

AuthManager used is an instance of MuxPwdAuthManager.

The implementation of “authenticate(…)” on class “MuxAuthManager” checks the

type of authentication for the user (Figure 42). The type of authentication is defined in

“UserAuthSource”. It then selects an apropriate “PwdAuthManager” instance and

invokes its “checkPassword(…)” method (Figure 43). The DbPwdAuthSource has to

encrypt the password, e.g. by using the MD5 algorithm, before storing it.


Project no: 734273 79 31/10/2017

Figure 42. Authentication Classes

Figure 43. Authentication sequence diagram


Project no: 734273 80 31/10/2017

6.2 DCMonitor & DCForecaster

6.2.1 Consumption Monitoring, Analysis and Control

Consumption monitoring, analysis and control module comprises a set of

components destined to know and understand in detail energy consumption and

generation in the data centres and characterize how energy is employed, with the

ultimate objective of controlling and managing distributed generation to the best

possible configuration, tending to the maximum efficiency of resources.

The three identified components related to this module correspond to

· Energy consumption monitoring

· Energy consumption automatic data Analyser

· Control centre for consumption and distributed generation

Energy consumption monitoring:

This component will collect actual and valuable data from data centres which serve to

generate feedback from DCs regarding their energy use. At the same time, it will

allow DC managers to have semi-real time information of their consumptions, profiles

and emissions. Currently, in most cases, the DC managers’ access to information

about their electricity use is limited to the data that is included in the bill from their

utility company. The system will provide semi-instant feedback on energy

consumption. This will give rise to applications, information and processes that

automatically adapt the behaviour of the manageable resources of the DC depending

on network situation. In this context we identify the following services, described in

detail in the Table 2.

Table 2. Expected Services from Energy consumption monitoring

Component name Energy consumption monitoring

Service name Target user Description


Project no: 734273 81 31/10/2017

Monitor energy

consumption at

DC level

DC

managers

Description: This service will collect all the

data which is created by metering devices

and generate energy usage information in the

DC. The gathered information will then be

available for the users, arranged in the most

appropriate way for their use through the

visualization service which will be detailed in

this section.

All data will be provided homogeneously,

which will facilitate the comprehension of the

information.

Thanks to the monitoring service, users will

have information about energy use of and

energy flow in a DC in several ways.

Input: Consumption information (Energy and

thermal) and other types of sensing

(Temperature, lighting…).

Output: Consumption profiles, comparisons

between servers or racks, consumption

information aggregated by time, gas

emissions, categories and processes.

Additional comment:

This service is meant for every user of the

platform but at the same time the information

which is gathered by monitoring will serve to

other components of the system, for example


Project no: 734273 82 31/10/2017

in order to perform forecasting analysis.

A key aspect on this service is the

homogeneous and proper data handling that

must be ensure through the complete

information process. In this sense, the data

management components (data aggregator

and normalised data base) will work in

connection to the monitoring services.


Project no: 734273 83 31/10/2017

Store aggregated

energy information

from different

measurement

devices

DC members Description: All the information that the

system receives through the monitoring

service could be classified in different ways,

aggregated by time or period, type of

consumer, energy tariffs, DC, etc.

This will enlarge the raw data from metering

devices and enrich system information which

will be available to users by creating

multidimensional data.

Every piece of information that is aggregated

by the analytical processing will be stored in

the system for further queries of users or

other components.

Inputs: Processed information from

consumption monitoring services, energy

prices, energy tariffs, energy policies,

sensing, and any other relevant data for

aggregation.

Outputs: Aggregated information by the

different parameters concerning

consumption.

Additional comment:

As the monitoring service, the aggregated

energy information would be available to

every user in the system and other

components that may require the aggregated

info for further analysis.


Project no: 734273 84 31/10/2017

The importance of the role of storing the

aggregated information is the advantage of

having that info automatically, since it is

produced before it is actually needed by other

components. This saves a valuable amount

of time and computing resources to other

components and improves system

performance.


Project no: 734273 85 31/10/2017

Aggregate data

query

DC

manager,

members

Description: This service will provide users

with a tool to retrieve the aggregated

information that is stored in the system so the

complexity of the aggregation is invisible to

the users, simplifying the labour of generating

particular information already adjusted to

their needs. Besides, the aggregate data

query service could serve to provide

summarized information and aggregated

information that is automatically created by

the system during its continuous data

processing.

Inputs: User’s queries and aggregated data.

Outputs: Aggregated energy consumption

information following query’s specifications.

Additional comment:

A key aspect on the aggregate data query

service is the view selection problem which

will depend on the semantic engine behind

the analysis process. Answer data queries

should not take much resource in order to

guarantee a correct performance and the

system stability.

If data is automatically aggregated then query

process will be quick. However, if the data is

aggregated following a particular query, then

it is traduced into a costly time-consuming

process.


Project no: 734273 86 31/10/2017

Visualize and

compare energy

consumptions

DC

manager,

members

Description: Through users’ interfaces it

would be possible to visualize energy

consumption and make comparisons

between various consumption profiles so that

users can analyse the information by

themselves.

Data should be available in several formats

and in different units. Energy use could

appear in terms of kWh, tons of CO2 or €

depending on what does the user prefer.

For example, a DC manager will be able to

inspect its DC energy use through the

information which is managed by this service

and be aware of how much energy it

employed in air conditioning, lighting, etc.

Inputs: User’s request. Sensing, energy data

and aggregated data.

Outputs: Energy consumption information,

comparisons between DC rooms,

consumption information aggregated by time,

etc.

Additional comment:

This service will act as the last element in the

monitoring process as it will present to users

the information they need. That information

would have been gathered by the monitoring


Project no: 734273 87 31/10/2017

service, adapted and transform to a coherent

shape, aggregated if necessary and stored in

the system before it is shown to the user.

Target users of this service are the human

users of the application who need the

information they want to know to be adapted

to their requirements.

Energy consumption automatic data Analyser

The consumption automatic data analysis component will utilize the data gathered by

monitoring and will be able to automatically generate high level information which

facilitates energy management at the system. It will detect inadequate energy uses,

and rise alarms related to energy consumptions by a prior configured rule base for


Project no: 734273 88 31/10/2017

example. This information will be a complementary tool for achieving energy

management. The automatic data analysis would be performed following certain

preconfigured declarations, which could be rule-based defined for example and

enable the system to generate that high level information autonomously.

The main service offered by this component is the automation alarm for energy miss-

consumption which is described in detail below Table 3.

Table 3. Expected Services from Energy consumption automatic data Analyser

Component name Energy consumption automatic data Analyser


Automation alarm

for energy miss-

consumption

DC manager,

members

Description: This service offers

automatically generated alarms to alert of any

energy consumption deficiencies. The service

delivers the results of a sentinel who is

continuously analysing energy consumption

in the system to detect and prevent any

undesirable event.

Input: Processed information from monitoring

services, energy prices, energy tariffs,

consumer characteristics, energy policies,

energy consumption aggregated information.

Output: Automatic generated alarms to

inform of unexpected consumptions.

Information for future detection of energy

deficiencies.


Project no: 734273 89 31/10/2017

The service of this component is for DC manager and members in the system and is

designed to support them in the energy consumption analysis. Instead of users

preferences the service could be automatically configured by the system, which

contrast with the services related to the Energy consumption monitoring component.

Control centre for consumption and distributed generation

To orchestrate energy management it is required knowledge from various billing

components, the behaviour of the hourly demand and the consumption pattern of

each DC room. This component is intended to be as a general control centre for

consumption and distributed generation, which will guide the energy balance to the

economic optimum. In order to do that the system will send signals to the local

controllers of distributed generation modifying energy flow according to the demand.

The component will be based its processes on simulations of the whole system

taking into account diverse parameters as energy tariffs, energy prices for the next

periods or technical features of distributed generation systems. These simulations

will provide a series of possible scenarios for the next hours among which the

optimum will be chosen. Besides, once the simulations are completed and an

optimum is chosen, every element in the system needs to be inquired in order to

know the feasibility of the elected scenario and validate the result, or in the opposite

case, restart the process in the search of a new solution.

In this context we identify the following services, described in detail in the following

Table 4.

Table 4. Expected Services from Control centre for consumption and distributed generation

Component name Control centre for consumption and distributed

generation

Service name Target

user

Description


Project no: 734273 90 31/10/2017

Forecast energy

bill

DC

manager

Description: This service will provide an

estimation of the energy bill for the following

hours at a certain consumption point based on

its previous patterns, energy tariff, estimated

energy demand and ambient conditions.

This could be understood as a tool to influence

in energy demand too, because if users have

information of what are they going to spend in

energy they may reduce their consumption to

reduce their energy bill.

Input: Weather conditions, energy tariffs,

consumption patterns and other additional

influential parameters that affect energy

demand and therefore the resulting energy bill.

Output: An estimation of the energy bill of

certain consumption point.

Send energy

prices for next

periods

DC

managers

Description: This service will send to users the

latest energy prices that have been published

according to the electricity market. Thanks to

this service, users will be aware of how much

would they spend on electricity in each hour of

the day as well as notice the active nature of the

price seeing how is the shape of price curves

and how does the price actually changes during

the day.

Input: Energy market prices, users’ energy

tariffs.


Project no: 734273 91 31/10/2017

Output: Users energy prices for next periods.

Send signal to

local controllers of

distributed

generation

DC

managers

This service will send signals to local controllers

of distributed generation in order to organize

energy flow according to the demand and the

best feasible scenario for the distributed

generation which leads to the global benefit.

Input: Optimum scenario of energy balance,

technical features of distributed generation

systems.

Output: Signals to local controllers to

orchestrate distributed generation.


Project no: 734273 92 31/10/2017

Level of acceptance

of proposed

generation plan

DC

manager

Description: This service will serve to collect

the response from distributed generation

systems to the proposed generation plan given

by the control centre for consumption and

distributed generation.

After the control centre for consumption and

distributed generation has establish a possible

generation plan for the following periods, this

service will give the system a feedback of how

willing are distributed generation elements to

observe the suggestion given to them. As a

result of the survey, it might be necessary to

search a new generation plan that could be

accepted by most of the generators.

Input: Optimum scenario of energy balance.

Generation configuration for the following hours.

Output: Level of acceptance of the proposed

plan from distributed generation.

6.2.2 Energy optimiser and smart grid integrator

Energy optimiser component provides support for energy monitoring and

consumption analysis to energy efficiency and the proper integration between

consumption and generation.

The energy optimizer and smart grid integrator component would be the part of the

system in charge of deciding for each period of the day which is the optimal

configuration for the consumption and generation of both electrical and thermal


Project no: 734273 93 31/10/2017

production in DC rooms. Besides it will integrate and optimize the use of renewable

energy by automatically adjusting distributed generation systems to general

conditions.

This component will act at the local scope directing tasks as:

· Coordinated management of electric energy.

· Combine the supply (and availability) of the grid with batteries and renewable

energy sources.

· Take into account consumption forecast.

· Take into account guidance signals from the Control centre for consumption

and distributed generation

The fulfilment of these tasks will require a complex management of various

information regarding measurements of consumption and generation, components of

billing, consumption patterns of a DC room, fixed and variable generation costs and

technical features of renewable sources and batteries. The component will manage

local consumption and generation by deciding the best configuration of the elements

under its control and providing energy saving recommendations and notifications of

upgradeable use for energy for a DC room.

The identified services related to the local energy optimizer and smart grid integrator

are described in the following Table 5.

Table 5. Expected Services from energy optimizer and smart grid integrator

Component name Local energy optimizer and smart grid integrator



Project no: 734273 94 31/10/2017

Manage and

optimize energy

flow

DC manager Description: By means of simulations

based on a DC room’s consumption

patterns, energy tariff, estimated energy

demand, distributed generation technical

features and the rest of influential

parameters as expected weather conditions

or central system indications, the best

configuration for a DC’s energy demand and

generation will be proposed. The result will

indicate whether is better to produce energy

locally rather than purchase it from the grid,

which is the best use for local energy

storage elements or how should be the

energy produce by distributed generation

systems.

Input: Measures of consumption and

generation, components of billing,

consumption patterns, fixed and variable

generation costs, available information of

renewable energy sources and batteries.

Rules for best energy consumption

practices.

Output: Set points of generation and

consumption elements that allow control, set

points for battery management, energy

saving recommendations.


Project no: 734273 95 31/10/2017

Manage rule base

for best energy

consumption

practices

DC member This service will serve to manage predefined

rules to optimize energy use in the DC

rooms. Rules could comprise act and control

of certain elements of the system as well as

perform informative actions addressed to

users.

One rule could be as ‘if contracted power is

exceeded during a certain time then a

message will be sent’ to inform DC manager.

Upper layer managers could contribute to

the creation of this database by defining

rules associate with energy efficiency

measures.

Input: Rules definition for best energy

practices.

Output: Rules database with the established

configuration for each case.

6.3 DCSimulator

The goal of the DCsimulation component is to allow data centre managers to understand the

impacts of different strategies for energy-efficient data centre operations.

For the design or configuration of a data centre we need to consider using appropriate

metrics and tools evaluating how much computation or data processing can be done within a

given power and energy budget and how it affects temperatures, heat transfers, and airflows

within the data centre. Therefore, there is a need for simulation tools and models that


Project no: 734273 96 31/10/2017

approach the problem from a perspective of end users and take into account all the factors

that are critical to understanding and improving the energy efficiency of data centres, in

particular, hardware characteristics, applications, management policies, and cooling.

There are several submodels to represent dynamics of energy consumption in DCs but the

GREENDC project considers two major energy consumers in DCs: IT facility and non-IT

facility. For the IT-facility, servers are the major devices for energy consumption and cooling

devices for non-IT facilities. Therefore, the GREENDC DSS will develop two submodels for

the energy consumption of the two devices.

A simulator tool helps in evaluation of an hypothesis where different scnearios could be

simulated and tested the outcomes of those scenarios. The simulation tools are generally

used before the actual prototype development of the solution and enables testing different

solutions in an efficient and cost effective manner. In cases of DC energy consumption tests,

a simulator allows evaluating studies with different resource allocation and leasing scenarios

under different load and pricing distributions. The studies help the DC team to optimize the

energy consumption models to achieve least energy consumption with maximum

performance possible from the infrastructure.

6.4 CloudSim

The GreenDC project adopts the CloudSim tool to achieve its simulation of DC energy

consumption models. CloudSIM is a tool that provides a framework to model and simulate

Cloud Computing infrastructures And services. It was developed and presented by the

researchers from Australian universities. It is mainly designed to evaluate the performance of

Cloud provisioning policies, application workload models, and resources performance

models via simulation tests that can be repeatable with different system and user

configurations. Some of the main features of the CloudSim functionalities are:

● large scale DC can be modelled and simulated

● server hosts, policies for resource allocation to hosts can be customized

● supports modelling and simulation of application containers

● supports modelling and simulation of nergy-aware computational resources

● DC network topologies can be modelled for simulation

● Allows dynamic insertion of simulation elements, start, stop and resuming of

simulations


Project no: 734273 97 31/10/2017

● Enables creation of user-defined policies for allocation of hosts to virtual machines

and policies for allocation of host resources to virtual machines

6.4.1 Architecture

Figure 44. CloudSim Architecture

Figure 44 above presents the architecture of CloudSim. The architecture is a multi

layered design. The CloudSim simulation layer is responsible for providing support

for modelling and simulation of DC environments that includes management

interfaces for VMs, memory and bandwidth allocation. This layer handles various

tasks that includes: the provisioning of hosts to VMs, managing application

execution, and monitoring of the dynamic system state. The manager or team

member who want to study the efficiency of different energy consumption policy for

allocating hosts to VM would implement the strategies in this layer via programming

functionalities. From this layer, the programmer can explore the functionalities of the

tool to perform complex workload profiling and application performance study.


Project no: 734273 98 31/10/2017

At the User Code layer, the entities of the host, such as hosts (number of machines,

their specification, and so on), applications (number of tasks and their requirements),

VMs, number of users and their application types, and broker scheduling policies is

available. The developer can perform activities here, such as: creating a combination

of workload distribution and application configuration, model scenarios and

customise configurations to perform tests, and implement custom application

provisioning techniques for the DC.

6.4.2 Class Diagram

Figure 45. An overall class Diagram of CloudSim

The above Figure 45 shows the overall class diagram of the CloudSim tool. Some of

the important classes are discussed below.

BwProvisioner: It is an abstract class that is used for modelling the policy of

bandwidth provisioning to the VMs. It is responsible for bandwidth allocation for the

VMs in the DC. This class along with BwProvisioningSimple allows the developers to

allocate or reserve bandwidths to the VMs and use it to design the allocation policies

according to the application requirements.

public abstract class BwProvisioner {


Project no: 734273 99 31/10/2017

/** The total bandwidth capacity from the host that the provisioner can allocate to

VMs. */

private long bw;

/** The available bandwidth. */

private long availableBw;

/**

* Creates the new BwProvisioner.

*

* @param bw The total bandwidth capacity from the host that the provisioner can

allocate to VMs.

*

* @pre bw >= 0

* @post $none

*/

public BwProvisioner(long bw) {

setBw(bw);

setAvailableBw(bw);

}

In the above example code, the bandwidth allocation classes form the CloudSim is

demonstrated. From the user stories, the SRI user stories would use this class. For

instance, the SRI3 user story of workload balancing and the SRI5 user story of

network configuration changes use these classes to set bandwidth allocation and

analyse its impact on the energy consumption of the DC.

CloudCoordinator: This class is responsible for monitoring the state of the DC

based on which load shedding decisions can be made. It includes the sensors and

the policies that should be used for the load shedding. The updateDatacenter()

method performs the monitoring of the DC by sending queries to the sensors. The

setDatacenter() abstract method is used for implementing custom protocols and

mechanisms such as multicast, broadcast, peer-to-peer. It can also be used for

simulating cloud services such as Amazon Load-Balancer.


Project no: 734273 100 31/10/2017

This class corresponds to the user story RM4, where the group leader monitors and

gets periodic reports of the performance of DC energy consumption. This allows

them to perform energy consumption schedule and make load shedding decisions.

Datacenter and DatacenterCharacteristics: This class is responsible for setting the

hardware configurations such as memory, cores, capacity, and storage. Every DC

implements a set of policies for allocating bandwidth, memory, and storage devices

to hosts and VMs and this handled by the Datacenter class. Further, the

DatacenterCharacteristics is responsible for configuring information related to DC

resources.

public Datacenter(

String name,

DatacenterCharacteristics characteristics,

VmAllocationPolicy vmAllocationPolicy,

List<Storage> storageList,

double schedulingInterval) throws Exception {

super(name);

setCharacteristics(characteristics);

setVmAllocationPolicy(vmAllocationPolicy);

setLastProcessTime(0.0);

setStorageList(storageList);

setVmList(new ArrayList<Vm>());

setSchedulingInterval(schedulingInterval);

for (Host host : getCharacteristics().getHostList()) {

host.setDatacenter(this);

}

// If this resource doesn't have any PEs then no useful at all

if (getCharacteristics().getNumberOfPes() == 0) {

throw new Exception(super.getName()

+ " : Error - this entity has no PEs. Therefore, can't process any

Cloudlets.");

}

// stores id of this class

getCharacteristics().setId(super.getId());


Project no: 734273 101 31/10/2017

}

public DatacenterCharacteristics(

String architecture,

String os,

String vmm,

List<? extends Host> hostList,

double timeZone,

double costPerSec,

double costPerMem,

double costPerStorage,

double costPerBw) {

setId(-1);

setArchitecture(architecture);

setOs(os);

setHostList(hostList);

/*@todo allocationPolicy is not a parameter. It is setting

the attribute to itself, what has not effect. */

setAllocationPolicy(allocationPolicy);

setCostPerSecond(costPerSec);

setTimeZone(0.0);

setVmm(vmm);

setCostPerMem(costPerMem);

setCostPerStorage(costPerStorage);

setCostPerBw(costPerBw);

}

The above example codes illustrate the Datacenter and DatacenterCharacteristics

class. The user can set various configuration parameters using these two classes.

From the user stories, all the user stories from the .Simulation and Real-time

Intervention (SRI) User Stories can be managed from this class. For instance, in

SRI1, the user can analyse parameter changes by configuring them here and running

the simulation. The SRI2 user story of setting VM configuration can also be done

from here. Further, the network configuration by a group member or leader in SRI5

user story can be done from here too.

Other Classes

The other classes in CloudSim include classes such as:


Project no: 734273 102 31/10/2017

➢ Host – It models an entity like a server or computer. It encapsulates

information such as amount of memory and storage, a list and type of

processing cores (to represent a multi-core machine), an allocation of policy

for sharing the processing power among VMs, and policies for provisioning

memory and bandwidth to the VMs.

➢ NetworkTopology – As the name suggests, contains information that can be

induced for network behaviour.

➢ RamProvisioner – This is responsible for provisioning policy for allocating

primary memory (RAM) to the VMs. When this class approves a host, then the

execution and deployment of it is feasible.

Non-IT Classes: Power Package

The power package in CloudSim includes various classes that are related to the

power management of the DC. Some of the classes from the power package are

briefly described.

PowerDataCenter

This class enables simulation of power-aware DCs. The example code of the

PowerDataCenter class is presented below.

public PowerDatacenter(String name,

DatacenterCharacteristics characteristics,

VmAllocationPolicy vmAllocationPolicy,

List<Storage> storageList,

double schedulingInterval)

throws Exception

In the above public function, the PowerDataCenter has various parameters that

include its name, the characteristics of the Datacenter that would be simulated, the

allocation of the VMs in the network designed, the list of data storage sources and

the scheduling interval of the simulation and workload on the simulated network.

Further, this class includes other relevant methods that verifies various factors such

as cloudlet submission, getting power status and setting Power, processing VM

migration, processing a cloudlet submission and updating them, and scheduling the

future events in the cloudlet. Thus, the PowerDataCenter simulates the power

management of the DC.

http://download.oracle.com/javase/6/docs/api/java/lang/String.html?is-external=true

http://www.cloudbus.org/cloudsim/doc/api/org/cloudbus/cloudsim/DatacenterCharacteristics.html

http://www.cloudbus.org/cloudsim/doc/api/org/cloudbus/cloudsim/VmAllocationPolicy.html

http://download.oracle.com/javase/6/docs/api/java/util/List.html?is-external=true

http://www.cloudbus.org/cloudsim/doc/api/org/cloudbus/cloudsim/Storage.html

http://download.oracle.com/javase/6/docs/api/java/lang/Exception.html?is-external=true


Project no: 734273 103 31/10/2017

PowerHost

This class enables simulation of power aware hosts. This class instantiates the

powerhost and also manages the power model used by the host. The example code

of the PowerHost class is presented below.

public PowerHost(int id,

RamProvisioner ramProvisioner,

BwProvisioner bwProvisioner,

long storage,

List<? extends Pe> peList,

VmScheduler vmScheduler,

PowerModel powerModel)

The PowerHost public function has various parameters such as the id of the host, the

RAM and bandwidth allocation of the hosts, the storage associated to the host, the

processing elements (cores) associated with the host, and the scheduling of the host

VM and the power model used by it. This class manages the power consumption of a

host as a single unit. This class also inherits data from other methods that are

associated with aspects such as getting the power consumption by a PE, maximum

power consumed by the host, energy consumption during the utilization, getting and

setting the power model. Thus, all the power management decisions related to a host

are managed by the PowerHost class.

PowerVmAllocationPolicyAbstract

The above class performs the power allocation policy for a VM. It is a simple class

that instantiates the power allocation policy for a VM. The class is represented by the

public function below.

public PowerVmAllocationPolicyAbstract(List<? extends Host> list)

The only parameter in this function is the host list. According to the list of host

provided as the parameter, the power allocation policy is configured. This function

calls some important methods that process the allocation policy. The methods

include allocating host for a given VM along with its allocation policy, finding host for

the VM, getting the host that is executed by the given VM, and deallocation of the

http://www.cloudbus.org/cloudsim/doc/api/org/cloudbus/cloudsim/provisioners/RamProvisioner.html

http://www.cloudbus.org/cloudsim/doc/api/org/cloudbus/cloudsim/provisioners/BwProvisioner.html


http://www.cloudbus.org/cloudsim/doc/api/org/cloudbus/cloudsim/Pe.html

http://www.cloudbus.org/cloudsim/doc/api/org/cloudbus/cloudsim/VmScheduler.html

http://www.cloudbus.org/cloudsim/doc/api/org/cloudbus/cloudsim/power/models/PowerModel.html


http://www.cloudbus.org/cloudsim/doc/api/org/cloudbus/cloudsim/Host.html


Project no: 734273 104 31/10/2017

host for the VM. The allocation policy is abstract in this function, however, other

classes allocate policies such as QuartileRange or LocalRegression.

6.4.3 User Interaction with CloudSim

The flowchart presented below illustrates the user journey in their interaction with the

ClooudSim simulator. A typical user interaction with CloudSim can be described with

the below main steps (Figure 46).

a. The first step is the user selects a scenario to simulate. The scenario can be

pre-designed and provided in the simulator

b. The next step is when the user designs the DC network. This step would

include addition of components such as VMs, routers, switches, softwares,

applications and the sharing of resources within the network

c. The third step is an important one as it involves configuring the input and

output parameters to the DC network. The user here specifies the workload on

each VM, rank the importance of the VM in the network, the minimum or

maximum bandwidth to be allocated and various other such parameters that

defines the functioning of the DC

d. The final steps involve running the simulator. The output of the simulator can

be displayed on a web application where the user can see the running of the

DC, current status, and its output.

e. Finally, the user can reconfigure the parameters to define new scenarios for

the given DC simulation and test the outputs of its simulation


Project no: 734273 105 31/10/2017

Figure 46. User Interaction with CouldSim

6.4.4 Power Consumption Models

The CloudSim provides various power consumption models. The power models listed

in the CloudSim repository include linear, cubic, square, square root, models based

on SPEC power benchmarks, and models designed for different models of IBM

servers and HP machines.

The consumption of power by a VM configured in a DC depends on the power model

chosen. For instance, if the VM power consumption model is configured to be a linear

model, then the power consumption can be calculated as:


Project no: 734273 106 31/10/2017

where, 𝑃𝑐 is the power consumption

𝑃𝑚𝑖𝑛 is the minimum power consumed at idle state

𝑃𝑚𝑎𝑥 is the maximum power consumption at peak load

𝑈𝑡𝑖𝑙𝑖𝑧𝑎𝑡𝑖𝑜𝑛 is between 0 and 1 and is the utilization of the VM at a given time

instance.

Using the above equation, the expected power consumed by the VM can be

computed. Different power models can be used based on the requirements of the DC

and the components used. The relevant energy consumption can be calculated using

the associated power consumption equations of the chosen model.

6.4.5 Workload Distribution

In DC environments, the workload distribution may change dynamically according to

the requirements of the application and the deployment methods. CloudSim supports

dynamic modelling and distribution of workloads via several components that are

provided in its framework. In particular, the cloudlet entity has extensions such as

Utilization model that provides the user methods and variables that can be

configured at the time of the deployment by the user to meet the resource and VM

requirements. The Utilization model is an abstract class in the CloudSim framework

that can be used to implement the workload distribution according to the application

requirements. For instance, the CloudSim framework provides a stochastic process

based workload distribution pattern that can be used to simulate the workload

distribution stochastically. Similarly, the user can design the utilization model

according to the application requirements.


Project no: 734273 107 31/10/2017

6.4.6 User Activity Diagrams for Simulation and Real-time Intervention

User Stories

SR1 (Analyse parameter changes). As a Group Leader, I want to run a simulation

to learn the impact of changing the parameters (such as cooling temperature,

workload, humidity, etc.) in order to find an optimal option to minimise energy

consumption.

Figure 47. User Activity Diagram – Analyse Parameter Change using CloudSim


Project no: 734273 108 31/10/2017

SRI2 (Analyse VMs configuration). As a Group Leader or Member, I want to run

the simulation to learn the impact of shutting down VMs in order to find an optimal


Figure 48. User Activity Diagram – Analyse VMs Configuration using CloudSim


Project no: 734273 109 31/10/2017

SRI3 (Analyse load balancing tools change). As a Group Leader or Member, I

want to run the simulation to learn the impact of changing load balancing algorithms

in order to find an optimal option to minimise energy consumption.

Figure 49. User Activity Diagram – Analyse Load Balancing Tools Change using CloudSim


Project no: 734273 110 31/10/2017

SRI4 (Analyse workloads rescheduling). As a Group Leader or Member, I want to

run the simulation for rescheduling of workloads (postponing) energy consumption in

order to find an optimal option to minimise energy consumption.

Figure 50. User Activity Diagram – Analyse Workloads Rescheduling using CloudSim


Project no: 734273 111 31/10/2017

SRI5 (Analyse network configuration changes). As a Group Leader or Member, I

want to run the simulation for setting the network configuration to find an optimal


Figure 51. User Activity Diagram – Analyse Network Configuration Change using CloudSim


Project no: 734273 112 31/10/2017

7. User Interface - UI

7.1 Basic Interface Principles

The interface of the DSS platform solution is based on those days contemporary

WEB standards for user usability, device independency and lightweight

programming.

The main intention of the UI designers are to keep its simplicity and consistency,

delivering maximum possible results to end-user, with minimum interface

interactions.

7.2 User Interface Structure

Overall look and common elements - ver. 1

1. Login form - see it online

http://test3.kz.archimed.bg/inspinia


Project no: 734273 113 31/10/2017

Figure 52. User Interface - Log-in Form

2. Initial Dashboard - see it online

http://test3.kz.archimed.bg/inspinia/greendc_dashboard_simulator.html


Project no: 734273 114 31/10/2017

Figure 53. User Interface – Initial Dashboard

● Top Navbar

Figure 54. User Interface – Top Navbar

Consists of (left to right):

● DSS logo

● Left navigation panel switcher to minimized mode

● Simple search

● Salutation info (based on User credentials)

● Log out button.


Project no: 734273 115 31/10/2017

Panel represents basic interaction for:

● Users Profile info

● User Role info

● Profile management

● Log-out

● Quick Access to many DC’s Dashboards (based on User Access Rights)

● Quick Access to Simulations archive performed by specific User

● Hidden on mobile devices

Figure 55. User Interface - Dynamic left navigation panel


Project no: 734273 116 31/10/2017

Main Page Elements

● Page Title and Quick DC Switcher

Figure 56. User Interface – Page Title and Quick DC Swicher

Displays current Page Title and DC switcher control. Points to current DC name,

under Page Title.

● DC Data Loader navbar

Figure 57. User Interface – DC Data Loader Navbar

Displays initiation button for collected data loading for specific DC. Notification if data

loading is successful or failed displayed at the right.


Project no: 734273 117 31/10/2017

DSS Simulation Monitor panel

Figure 58. User Interface – DSS Simulation Monitor Panel

1. Displays information about last performed simulation by date of

performance (if any), otherwise panel appears closed.

2. Visualizes Predicted power consumption based on loaded data.

3. On the right section of the DSS Simulation Monitor the interface

brings tools for loaded data changing values (unlimited number), based

on certain DSS mathematical model requirements for the exact

scenario.

4. Displays RUN Simulation! button to initiate simulation, after changing

the Test values.

5. Displays new graphical results for the performed simulation.

6. Bring to user Actions drop-down selector at the right of the Simulation

results title for Save, Load, Export and Reset actions for the

simulation.


Project no: 734273 118 31/10/2017

● DC Nodes panel

Figure 59. User Interface – DC Nodes Panel

1. Displays all measured device nodes for specified DC

2. Provides list of nodes by name and option for their exclusion/inclusion

into new performed simulation.

My Simulations page (Accessible via Left navigation panel) - see it online

Figure 60. User Interface – My Simulation Page

http://test3.kz.archimed.bg/inspinia/greendc_dashboard_simulations.html


Project no: 734273 119 31/10/2017

1. Displays list of performed simulations by Number, (ID), Performer and date in

standard Data Table.

2. Actions table column provides buttons for performing View (Using DSS

Simulation Monitor), Export and Delete actions.

3. Pagination functionality is provided at the bottom for managing long lists of

records.

7.3. Serving User Stories and Scenarios

Simplified UI interpretation

In terms of “User interface - UI”, the following schema represents the logical

interaction workflow of the DSS UI, concerning User Scenarios and Stories.

Figure 61. User Interaction – Getting Useful Results in 3 Easy Steps


Project no: 734273 120 31/10/2017

Common example: Getting Useful Results in 3 easy steps (user

interactions)

Step 1. Scenario Chooser - see it online

After successful DC data loading from DC Data Warehouse (DC DW), user should

perform his first interaction with DSS, using simple web control to choose the

scenario/direction of future steps/interactions.

Figure 62. User Interface – Scenario Chooser

Step 2. Scenario option/story selection

The User can make himself familiar with each option details, using More details

button on the right of each option/story. After selecting chosen option the Apply

Scenario button became enabled, instead of disabled.

After performing the Apply Scenario interaction, as a result, the particular Scenario

DASHBOARD appears, based on chosen Scenario + selected User story.

http://test3.kz.archimed.bg/inspinia/greendc_dashboard_scenario_chooser.html


Project no: 734273 121 31/10/2017

Initial graphical results are displayed, based on DC data, loaded from DC Data

Warehouse (DC DW).

Each selected User Story, uses his own Mathematical Model (MM), as a template

for graphical interpretation of loaded DC data.

Sample Result - Scenario DASHBOARD - see it online

Figure 63. User Interface – Scenario Dashboard

Step 3. Working with test values

Using standard Web controls (sliders, switches, include/exclude controls, etc.), user

can interact with these tools to change available test values and to perform unlimited

number of simulations, based on (MM) for the chosen Scenario + selected User

Story.

http://test3.kz.archimed.bg/inspinia/greendc_dashboard_scenario_dashboard.html


Project no: 734273 122 31/10/2017

Include/Exclude Measured nodes

DC Measured nodes panel under the Scenario dashboard is attended to support the User

with additional functionality. - see it online

Figure 64. DC Measured Nodes Panel

Using DC Measured nodes panel, the User is able to simulate exclusion of a

particular equipment by type, not to be included in performed simulation.

Proceeding with Visualized results

After successfully performed Simulation, user is able

to use “Actions” drop-down menu to proceed with

simulation results further in several different ways:

Figure 65. User Interface – Actions

http://test3.kz.archimed.bg/inspinia/greendc_dashboard_scenario_dashboard.html


Project no: 734273 123 31/10/2017

● Save simulation results

● Load saved simulation results

● Export simulation results (PDF)

● Reset simulation to initial loaded data

7.4. General DASHBOARDS for user scenarios

1. Energy Consumption Forecasting DASHBOARD - see it online

Figure 66. 1. Energy Consumption Forecasting DASHBOARD

Dashboard represents all user tools needed to perform Forecasting scenario,

based on already collected data.

http://test3.kz.archimed.bg/inspinia/greendc_dashboard_scenario_dashboard_forecasting.html


Project no: 734273 124 31/10/2017

Graphical visualization of the Power consumption is generated by chosen types of

Input parameters, based on what user needs to estimate (in this case: Power

consumption of server).

Using Settings panel on the right, user could perform different combinations of

Included data, Mathematical models, Time period and Time step, to visualize

different estimation results.

ESTIMATION Output! button initiates the calculations, after choices have been

made.


Project no: 734273 125 31/10/2017

2. Simulation for Energy Saving DASHBOARD - see it online

Figure 67. 2. Simulation for Energy Saving DASHBOARD

Dashboard represents all user tools needed to perform Simulation for Energy

Saving scenario, based on already collected data.

Graphical visualization of the Predicted power consumption is generated by

modification of parameters on the right. The changeable parameters number varies.

The variations depending on data loaded for certain type of equipment, using

include/exclude functionality of the DC Measured nodes panel.

http://test3.kz.archimed.bg/inspinia/greendc_dashboard_scenario_dashboard_simulation


Project no: 734273 126 31/10/2017

RUN Simulation! button initiates the calculations, after choices and modifications

have been made.

User experience configuration

UI configurator could be reached at the top-right corner of the screen via its

control button.

It allows Users to set the UI parameters for

individual user experience, such as:

● Collapsing menu

● Fixing sidebar

● Top navbar ON/OFF

● Switching from Boxed layout to Full

Screen

● Fixing the footer

● Changing Theme color skins

Figure 68. User Interface – UX configuration


Project no: 734273 127 31/10/2017

8. Conclusion with Implementation Plan

The purpose of this deliverable was to suggest the blueprint for actual development

of GREENDC DSS within the aim of the work package two. Based on the result of

DSS requirement collection from the work package one, this deliverable designs the

GREENDC DSS in all its aspects to fulfil the minimum functional and technical

requirements for the implementation based on user scenarios that have been

selected and sorted out through the requirement specification process.

The extended findings from D1.1, system requirement definition and user stories

gave us the critical ideas to design the overall architecture, which has three-tier

architecture including data, business logic and user interface layer. The subsection

below presents the summary of the works in this deliverable and implementation plan

for each main layer.

8.1. Data Layer

Data layer has its two sub-layer – data collection and data normalisation layer. Data

collection layer will collect the data from various devices in the data centre as well as

from the third-party software such as Zabbix. Collected data will be normalised so

that the data can be published in to an API or SOA object.

8.2. Math Model Layer

Math model layer will be the core of forecasting and optimisation of energy

consumption. Neural network and/or multiple regression model will be used for the

forecasting process. The optimisation of energy consumption, which is the main

objective of GREENDC DSS tool, will be obtained by resolving sophisticated

objective function regarding cost and profit of data centre.

Mathematical methods will be developed in MATLAB environment. Math Layer will

connect the other layers with python programming language. The key point in the

software development process is the software quality. The main goal of the Software

quality management is to reduce the risks such as the misuse of code by client,


Project no: 734273 128 31/10/2017

memory leakage, logical errors that cannot be detected by compiler etc. The

requirements of the qualified software are;

· Minimum error

· To satisfy user requirements

· To fix errors as soon as possible

Errors like Syntax or logic error must be avoided in programming. Error handling is a

process to make the program well-written while ensuring that unexpected errors are

eliminated properly. By means of "error handling", unexpected situations are caught

in run time and necessary actions are taken. Due to unpredictable problems

mentioned above, error handling will be taken into account in the DSS code.

Before development process of the software, User requirements should be

determined. It is controlled gradually whether these requirements are satisfied in the

development process. It is necessary to construct a tractable, predictable and easy

understandable code in order to fix errors quickly.

8.3. Business Logic Layer

Business logic layer will deal with the services required by the components of the

user interface layer. Data centre energy consumption monitoring and forecasting will

be the main tasks that will be sorted out by this layer and DC simulation component

will also implemented to allow data centre managers to understand the impacts of

different strategies for energy-efficient data centre operations.

DC Simulator will be implemented using CloudSim

(http://www.cloudbus.org/cloudsim/). CloudSim is a generalized, and extensible

simulation framework that enables seamless modeling, simulation, and

experimentation of emerging Cloud computing infrastructures and application

services. It allows researchers and industry-based developers can focus on specific

system design issues that they want to investigate, without getting concerned about

the low level details related to Cloud-based infrastructures and services.


Project no: 734273 129 31/10/2017

CloudSim is selected in the GREENDC project as it provides meta data model and

architecture for representing the major components of DCs. It has also been widely

used in the literature for simulating DCs.

Communication between User Interface layer and Business logic layer will use

RestfulAPI and architecture diagram to be included

Outline to discuss:

● RestfulAPI endpoints

● RestfulAPI request/response payload structure

● Status codes and message conventions to declare API content

● Decide data types to generate screens, tables or other objects(graphs,

streams, etc.)

8.4. User Interface

User interface will be realised based on those days’ contemporary WEB standards

for user usability, device independency and lightweight programming. The main

intention of the UI design in GREENDC DSS are to keep its simplicity and

consistency, delivering maximum possible results to end-user, with minimum

interface interactions.

The User Interface Layer will be integrated, using the following technical principles

for implementation of the DSS:

• Usability standards

o Powered by Bootstrap 3.0 web interface library

o Standardized User web controls

o Fully customizable additional User web controls

• Device Independency

o Responsive (screen resolution independent) User views layout

o Dynamical Interaction Panels

o Maximum Browser compatibility


Project no: 734273 130 31/10/2017

• Lightweight Programming Approach

The technology used, consists of three main web standards:

o HTML5

o CSS 3

o Javascript

These standards allowing the interface developers to deploy any needed additional

interactivity quickly and independently to main business logic.

8.5. Conclusion

With this deliverable, we reached the first small iteration of implementation by

drawing big picture for the real implementation of GREENDC DSS and this will be the

successful starting point to future implementation of the DSS. Though there will be an

evaluation phase for the implemented outcomes of DSS and new improvement

points will be coming out, the proposed architecture in this deliverable will be a

concrete skeleton that enable this project to anchor the right direction for defined

project objectives.


Project no: 734273 131 31/10/2017

APPENDIX

APPENDIX A : REGISTRATION MAPS(DCIM)

● UPS

Name Category Data Type Value/Unit

UPS Status Status BOOLEAN 1

Load is being powered from

battery

Status BOOLEAN 1

Low-Battery Status BOOLEAN 1

Bypass Status BOOLEAN 1

Self-Test Status BOOLEAN 1

Load not Powered Status BOOLEAN 1

Power Module Failure Status BOOLEAN 1

Battery System Failure Status BOOLEAN 1

Intelligence Module Status BOOLEAN 1

Static Switch Failure Status BOOLEAN 1

Power Supply Unit Failure Status BOOLEAN 1

Informational Alarm Present Status BOOLEAN 1

Warning Alarm Present Status BOOLEAN 1

Critical Alarm Present Status BOOLEAN 1


Project no: 734273 132 31/10/2017

Lost Local Network

Management Interface

Status BOOLEAN 1

UPS Serial Number Text ASCII

UPS Firmware Version Text ASCII

Time On Battery Values UINT32 Seconds

Runtime Remaining Values UINT32 Seconds

Estimated charge time Values UINT32 Seconds

Estimated charge % Values UINT32 %

Battery (+) Voltage Values UINT16 VDC

Battery (-) Voltage Values UINT16 VDC

Battery (+) Current Values SINT16 amps

Battery (-) Current Values SINT16 amps

Total time on battery Values UINT32 Seconds

Total number of times on

battery

Values UINT16 counts

APC Battery Breaker Status

/User supplied battery

Breaker Status(mutually

exclusive)

Status BOOLEAN 0=Open, 1=

ClosedBit 0 to

Bit 7 represent

Frame 0 to 7

respectivley.Fo

r User supplied


Project no: 734273 133 31/10/2017

battery bit 0

Battery System Temperature Values UINT16 °C

Battery Power Values INT16 kW

Available Amp Hours Values UINT16 Amp Hours

Frequency (input) Values UINT16 Hz

Voltage L1-2 (input) Values UINT16 Vms



Current L1 (input) Values UINT16 amps



Active power L1 (input) Values UINT16 kW




Project no: 734273 134 31/10/2017

Apparent power L1 (input) Values UINT16 kVA



Total Active Power (input) Values UINT16 kW

Total Apparent power (input) Values UINT16 kVA

Current L1 (parallel input) Values UINT16 amps



Frequency (bypass) Values UINT16 Hz

Voltage L1-2 (bypass) Values UINT16 Vms



Current L1 (bypass) Values UINT16 amps



Active power L1 (bypass) Values UINT16 kW



Project no: 734273 135 31/10/2017


Apparent power L1 (bypass) Values UINT16 kVA



Total Active Power (bypass) Values UINT16 kW

Total Apparent power

(bypass)

Values UINT16 kVA

Current L1 (parallel bypass) Values UINT16 amps



Nominal(Apparent) output

rating

Values UINT16 kVA

Frequency (output) Values UINT16 Hz

Voltage L1-2 (output) Values UINT16 Vms



Current L1 (output) Values UINT16 amps




Project no: 734273 136 31/10/2017

Peak Current L1 (output) Values UINT32 amps



Active power L1 (output) Values UINT16 kW



Apparent power L1 (output) Values UINT16 kVA



% Load L1 Values UINT16 %



Total Active Power (output) Values UINT16 kW

Total Apparent power

(output)

Values UINT16 kVA

Total Percent Load Values UINT16 %

Power factor L1 (output) Values UINT16 power factor




Project no: 734273 137 31/10/2017

Current crest factor L1

(output)

Values UINT16 crest factor


(output)



(output)


Parallel System Output

CurrentAC L1

Values UINT16 amps


CurrentAC L2

Values UINT16 amps


CurrentAC L3

Values UINT16 amps


Active Power L1

Values UINT16 kW


Active Power L2

Values UINT16 kW


Active Power L3

Values UINT16 kW


Apparent Power L1

Values UINT16 kVA


Apparent Power L2

Values UINT16 kVA


Apparent Power L3

Values UINT16 kVA

ParallelSystem Output %

Load L1

Values UINT16 %


Load L2

Values UINT16 %


Load L3

Values UINT16 %


Project no: 734273 138 31/10/2017


Active Power

Values UINT16 kW


Apparent Power

Values UINT16 kVA


Load

Values UINT16 %

Energy Meter kWh Values UINT32 kWh

UPS Installation Load %

(Standalone)

Values UINT16 %

UPS Installation Load %

(Parallel )

Values UINT16 %

Ambient temperature Values UINT16 °C

Number of Power Modules Values UINT16 Unitless

Number of Battery Monitor

Boards

Values UINT16 Unitless

Number of Battery Breaker

Motors


Number of Battery Modules Values UINT16 Unitless

Number of Battery

Enclosures


Number of PSUs Values UINT16 Unitless

● PDU


Project no: 734273 139 31/10/2017


DEVICE_TYPE Status ENUM 10

OVERALL_STATUS Status ENUM 0

COMM_STATUS Status ENUM 0

MODULE_N_SERIAL_NUMBER Status ASCII N/A

MODULE_N_DATE_OF_MANUF

ACTURE

Status ASCII N/A

MODULE_N_MODEL_NUMBER Status ASCII N/A

MODULE_X_BREAKER_Y_RATI

NG

Values INTEGER Amps

MODULE_X_BREAKER_Y_CUR

RENT

Values INTEGER A(Tenths)

MODULE_X_BREAKER_Y_POW

ER

Values INTEGER kW(Hundredths

)

MODULE_X_BREAKER_Y_PER

CENT_CURRENT

Values INTEGER %(Tenths)

MODULE_X_BREAKER_Y_kWh

_ENERGY

Values LONG %(Tenths)

MODULE_X_BREAKER_Y_THR

ESHOLD_MIN

Values INTEGER %


ESHOLD_LOW

Values INTEGER %


ESHOLD_HIGH

Values INTEGER %


ESHOLD_MAX

Values INTEGER %


Project no: 734273 140 31/10/2017

SUBFEED_BREAKER_N_RATIN

G

Values INTEGER Amps

SUBFEED_BREAKER_N_CONFI

GURATION

Status ENUM 0 = Not

Installed 1

= Distribution

Subfeed

2 = Total

Panel Load

SUBFEED_N_STATUS Status ENUM 0 = No Comm

1 = Not

Installed 2

= Normal

3 =

Warning

4 =

Critical

SUBFEED_N_BREAKER_POSIT

ION

Status ENUM 0 = No

Subfeed

1 =

Open

2 =

Closed

SUBFEED_X_BREAKER_Y_CU

RRENT

Values INTEGER A(Tenths)

SUBFEED_X_BREAKER_Y_PO

WER

Values INTEGER kW(Tenths)

SUBFEED_X_BREAKER_Y_PER

CENT_CURRENT

Values INTEGER %(Tenths)

SUBFEED_X_BREAKER_Y_ENE

RGY

Values LONG kWh(Tenths)

SUBFEED_N_THRESHOLD_MIN Values INTEGER %

SUBFEED_N_THRESHOLD_LO

W

Values INTEGER %


Project no: 734273 141 31/10/2017

SUBFEED_N_THRESHOLD_HIG

H

Values INTEGER %

SUBFEED_N_THRESHOLD_MA

X

Values INTEGER %

OUTPUT_VOLTAGE_L1 Values INTEGER V(Tenths)



OUTPUT_VOLTAGE_L1-2 Values INTEGER V(Tenths)



NOMINAL_VOLTAGE_L-N Values INTEGER Volts

NOMINAL_VOLTAGE_L-I Values INTEGER Volts

OUTPUT_VOLTAGE_THRESHO

LD_MIN

Values INTEGER % below

normal


LD_LOW

Values INTEGER % below

normal


LD_HIGH

Values INTEGER % above

normal


LD_MAX

Values INTEGER % above

normal

NOMINAL_FREQUENCY Values INTEGER Hz(Tenths)

OUTPUT_FREQUENCY Values INTEGER Hz(Tenths)


Project no: 734273 142 31/10/2017

● CHILLER


Not used Status DIGITAL

VARIABLES

Compressor 1 ON- 25% step Status DIGITAL

VARIABLES

Compressor 1-50% step Status DIGITAL

VARIABLES

Compressor 1- 75% step Status DIGITAL

VARIABLES


VARIABLES

Compressor 2 ON-25% step Status DIGITAL

VARIABLES


VARIABLES


VARIABLES


VARIABLES


Project no: 734273 143 31/10/2017

Pump 1 on Status DIGITAL

VARIABLES

Pump 2 on Status DIGITAL

VARIABLES

Freecooling pump on Status DIGITAL

VARIABLES

Antifreeze heaters (option) Status DIGITAL

VARIABLES

100% Heat recovery (option) Status DIGITAL

VARIABLES

Regulated condensing Fans Status DIGITAL

VARIABLES

Direct condensing Fans Status DIGITAL

VARIABLES

Regulated condensing Fans 2 Status DIGITAL

VARIABLES

Direct condensing Fans 2 Status DIGITAL

VARIABLES

Circuit 1 Defrost (Heat pump

only)

Status DIGITAL

VARIABLES

Circuit 2 Defrost (Heat pump

only)

Status DIGITAL

VARIABLES

Low power consumption mode Status DIGITAL

VARIABLES

Winter mode (Heat pump only) Status DIGITAL

VARIABLES


Project no: 734273 144 31/10/2017

Summer/Winter mode remote

control

Status DIGITAL

VARIABLES

Unit Remote Switch-On/Off

Control

Status DIGITAL

VARIABLES

Buzzer and Alarm Remote Reset

Control

Status DIGITAL

VARIABLES

Pump 1-2 Switch-over remote

control

Status DIGITAL

VARIABLES

Set Back Mode (Sleep Mode) Status DIGITAL

VARIABLES

Reserved variable Status DIGITAL

VARIABLES

Usage of Temp. Values: Local

(0) / Mean (1)

Status DIGITAL

VARIABLES

No. Of Stand-by Units: one (0) /

two (1)

Status DIGITAL

VARIABLES

Water tank range Status DIGITAL

VARIABLES

Presence of the 2nd water pump Status DIGITAL

VARIABLES

Water Outlet Temperature Values ANALOG

VARIABLES

°C

Water Outlet Temp. used by

regulator

Values ANALOG

VARIABLES

°C


Project no: 734273 145 31/10/2017

Water Inlet Temperature Values ANALOG

VARIABLES

°C

Water Tank Temperature Values ANALOG

VARIABLES

°C

Outdoor Air Temperature Values ANALOG

VARIABLES

°C

Circuit 1 Condensing

Temperature

Values ANALOG

VARIABLES

°C

Circuit 2 Condensing

Temperature

Values ANALOG

VARIABLES

°C

Circuit 1 Evaporating

Temperature

Values ANALOG

VARIABLES

°C


Temperature

Values ANALOG

VARIABLES

°C

Circuit 1 Condensing Pressure Values ANALOG

VARIABLES

Bar

Circuit 2 Condensing Pressure Values ANALOG

VARIABLES

Bar

Circuit 1 Evaporating Pressure Values ANALOG

VARIABLES

Bar

Circuit 2 Evaporating Pressure Values ANALOG

VARIABLES

Bar

Discharge temperature

compressor 1

Values ANALOG

VARIABLES

°C

Discharge temperature

compressor 2

Values ANALOG

VARIABLES

°C


Project no: 734273 146 31/10/2017

Fan Speed Modul.Ramp (circuit

1) (0-100,0%)

Values ANALOG

VARIABLES

%

Fan Speed Modul. Ramp circuit

2 (0-100,0%)

Values ANALOG

VARIABLES

%

Delivery Water Temp. Actual Set

Point

Values ANALOG

VARIABLES

°C

Delivery Water Temp. Max.

Hysteresi

Values ANALOG

VARIABLES

°C

Offset supervisor Values ANALOG

VARIABLES

°C

Delivery Water Temp. Summer

STD Set Point

Values ANALOG

VARIABLES

°C

Delivery Water Temp. Summer

OPT Set Point

Values ANALOG

VARIABLES

°C

Del.Water T. Summer SetBack

mode SetP.

Values ANALOG

VARIABLES

°C

Delivery Water Temp. Winter Set

Point

Values ANALOG

VARIABLES

°C

Del.Water T. Winter SetBack

mode SetP

Values ANALOG

VARIABLES

°C

CW inlet High Temp.Summer

Alarm Threshold

Values ANALOG

VARIABLES

°C

CW inlet Low Temp.Summer

Alarm Threshold

Values ANALOG

VARIABLES

°C

CW inlet High Temp. Alarm

Winter Threshold

Values ANALOG

VARIABLES

°C


Project no: 734273 147 31/10/2017

CW inlet Low Temp. Alarm

Winter Threshold

Values ANALOG

VARIABLES

°C

Summer T.ext Compens.: P1

T.ext SetP.

Values ANALOG

VARIABLES

°C


T.wout SetP.

Values ANALOG

VARIABLES

°C


T.ext SetP.

Values ANALOG

VARIABLES

°C

Winter T.ext Compens.: P1 T.ext

SetP.

Values ANALOG

VARIABLES

°C

Winter T.ext Compens.: P2

T.wout SetP.

Values ANALOG

VARIABLES

°C

Winter T.ext Compens.: P2 T.ext

SetP.

Values ANALOG

VARIABLES

°C

Free-Cooling Activation Set

Point

Values ANALOG

VARIABLES

°C

Circuit 1 Superheating Values ANALOG

VARIABLES

°C

Circuit 2 Superheating Values ANALOG

VARIABLES

°C

Circuit 1 Suction Pressure Values ANALOG

VARIABLES

°C

Circuit 2 Suction Pressure Values ANALOG

VARIABLES

°C

Circuit 1 Suction Temperature Values ANALOG

VARIABLES

°C


Project no: 734273 148 31/10/2017

Circuit 2 Suction Temperature Values ANALOG

VARIABLES

°C

Circuit 1 Liquid temperature Values ANALOG

VARIABLES

°C

Circuit 2 Liquid temperature Values ANALOG

VARIABLES

°C

Pump Inverter request (Optional) Values ANALOG

VARIABLES

%

Pump % working (Optional, with

inverter)

Values ANALOG

VARIABLES

%

EXV PID Superheat Setpoint Values ANALOG

VARIABLES

°C

EXV PID Superheat Proportional

Gain

Values ANALOG

VARIABLES

EXV PID Superheat derivative

time

Values ANALOG

VARIABLES

sec

EXV PID Superheat Dead zone Values ANALOG

VARIABLES

°C

EXV Low superheat threshold Values ANALOG

VARIABLES

°C

EXV Costant time low superheat Values ANALOG

VARIABLES

sec

EXV MOP threshold Values ANALOG

VARIABLES

°C

EXV LOP threshold Values ANALOG

VARIABLES

°C


Project no: 734273 149 31/10/2017

EXV Costant time MOP

threshold

Values ANALOG

VARIABLES

sec

EXV Costant time LOP threshold Values ANALOG

VARIABLES

sec

Reserved (Advanced antifreezed

set)

Values ANALOG

VARIABLES

°C

Fans speed Temperature cond.

ON

Values ANALOG

VARIABLES

°C


OFF

Values ANALOG

VARIABLES

°C


Begin

Values ANALOG

VARIABLES

°C


End

Values ANALOG

VARIABLES

°C


Begin 2 (optional)

Values ANALOG

VARIABLES

°C


End 2 (optional)

Values ANALOG

VARIABLES

°C

dT Water IN-Ambient SetPoint Values ANALOG

VARIABLES

°C

Compressor 1 hour counter Values INTEGER

VARIABLES

h

Compressor 2 hour counter Values INTEGER

VARIABLES

h


Project no: 734273 150 31/10/2017

Circulating Pump 1 hour counter Values INTEGER

VARIABLES

h

Circulating Pump 2 hour counter Values INTEGER

VARIABLES

h

Free-cooling Pump hour counter Values INTEGER

VARIABLES

h

Compressor 1 Starting counter Values INTEGER

VARIABLES

h

Compressor 1 Starting counter

x10.000

Values INTEGER

VARIABLES

nx104

Compressor 2 Starting counter Values INTEGER

VARIABLES

n

Compressor 2 Starting counter

x10.000

Values INTEGER

VARIABLES

nx104

Circuit 1 Defrost counter Values INTEGER

VARIABLES

n

Circuit 1 Defrost counter x10.000 Values INTEGER

VARIABLES

nx104

Circuit 2 Defrost counter Values INTEGER

VARIABLES

n

Circuit 2 Defrost counter x10.000 Values INTEGER

VARIABLES

nx104

Both Circuit Defrost counter Values INTEGER

VARIABLES

n

Both Circuit Defrost counter

x10.000

Values INTEGER

VARIABLES

nx104


Project no: 734273 151 31/10/2017

Non Performing Defrost counter Values INTEGER

VARIABLES

n

Non Performing Defrost counter

x10.000

Values INTEGER

VARIABLES

nx104

Unit Type (0= STD Chiller,

1=Low Temp. Ch., 2=Ch.+Heat

Rec.; 3=Heat Pump, 4=HP+Heat

Rec. 5=Ch.+Energy Saving)

Values INTEGER

VARIABLES

n

Circulating Pump Config. (0,1 or

2 Pumps)

Values INTEGER

VARIABLES

n

Total of units connected in LAN Values INTEGER

VARIABLES

n

Comp.1 Status

(0=Off,1=On,2=AL,3=Pump.Dow

n)

Values INTEGER

VARIABLES

n

Comp.2 Status Values INTEGER

VARIABLES

n

Comp.1 Step Status Values INTEGER

VARIABLES

n

Comp.2 Step Status Values INTEGER

VARIABLES

n

Pump 1 Status Values INTEGER

VARIABLES

n

Pump 2 Status Values INTEGER

VARIABLES

n

FC Pump Status Values INTEGER

VARIABLES

n


Project no: 734273 152 31/10/2017

Actual set Point mode (0=std,1=

T.ext Compens., 2=OPT SetP.,

3=Setback SetP., 4=Remote

Offset

Values INTEGER

VARIABLES

n

Reserved variable Values INTEGER

VARIABLES

r

Reserved variable Values INTEGER

VARIABLES

r

Last Defrost Lenght Values INTEGER

VARIABLES

s

Restart Delay Values INTEGER

VARIABLES

s

Regulation Start Transitory Values INTEGER

VARIABLES

s

Low Pressure Delay Values INTEGER

VARIABLES

s

Water High/Low Temp. Alarm

Delay

Values INTEGER

VARIABLES

min

Excursion time Values INTEGER

VARIABLES

s

Stand-by Unit Switch-over time Values INTEGER

VARIABLES

h

Run-Stand-by pump switch-over

time

Values INTEGER

VARIABLES

H

Setback Mode Cyclical start Values INTEGER

VARIABLES

Min


Project no: 734273 153 31/10/2017

Compr.1 working hours

threshold

Values INTEGER

VARIABLES

h *100

Compr.2 working hours

threshold

Values INTEGER

VARIABLES

h *100

Pump 1 working hours threshold Values INTEGER

VARIABLES

h *100

Pump 2 working hours threshold Values INTEGER

VARIABLES

h *100

FC Pump working hours

threshold

Values INTEGER

VARIABLES

h *100

Reserved Values INTEGER

VARIABLES


VARIABLES

Compressor 1 Current Absorbed Values INTEGER

VARIABLES

A

Compressor 2 Current Absorbed Values INTEGER

VARIABLES

A

Circuit 1 EXV Position Values INTEGER

VARIABLES

Step

Circuit 2 EXV Position Values INTEGER

VARIABLES

Step

Hour Values INTEGER

VARIABLES

H

Minute Values INTEGER

VARIABLES

Min


Project no: 734273 154 31/10/2017

Day Values INTEGER

VARIABLES

D

Month Values INTEGER

VARIABLES

M

Year Values INTEGER

VARIABLES

Y

Bios release Values INTEGER

VARIABLES

boot release Values INTEGER

VARIABLES

SW release Values INTEGER

VARIABLES

Head pressure setpoint Values INTEGER

VARIABLES

kPa

Head pressure value Values INTEGER

VARIABLES

kPa

Water IN pressure Values INTEGER

VARIABLES

kPa

Water OUT pressure Values INTEGER

VARIABLES

kPa


Project no: 734273 155 31/10/2017

● AIR CONDITIONER


System On (Fan) Status DIGITAL

Compressor 1 Status DIGITAL




El. Heater 1 Status DIGITAL

El. Heater 2 Status DIGITAL

Hot gas ON Status DIGITAL

Dehumidification Status DIGITAL

Humidification Status DIGITAL

Emergency Working Status DIGITAL

DX/CW Switch on TC Units Status DIGITAL

Summer/Winter Switch Status DIGITAL

Unit ON/OFF Switch Status DIGITAL


Project no: 734273 156 31/10/2017

Setback Mode (Sleep Mode) Status DIGITAL

Sleep Mode Test Status DIGITAL

Local/Mean Usage of Values Status DIGITAL

Room Temperature Values ANALOG °C

Outdoor Temperature Values ANALOG °C

Delivery Air Temperature Values ANALOG °C

Chilled Water Temperature

(circ.1)

Values ANALOG °C

Hot Water Temperature Values ANALOG °C

Room Relative Humidity Values ANALOG rH%

Outlet Chilled Water

Temperature

Values ANALOG °C

Circuit 1 Evaporating Pressure Values ANALOG bar

Circuit 2 Evaporating Pressure Values ANALOG bar

Circuit 1 Suction Temperature Values ANALOG °C

Circuit 2 Suction Temperature Values ANALOG °C


Temperature

Values ANALOG °C


Temperature

Values ANALOG °C


Project no: 734273 157 31/10/2017

Circuit 1 Superheat Values ANALOG °C

Circuit 2 Superheat Values ANALOG °C

Cold Water Valve Ramp

(circ.1)

Values ANALOG %

Hot Water Valve Ramp Values ANALOG %

Evaporating Fan Speed Values ANALOG %

Cooling Setpoint

Return Air Temperature

Values ANALOG °C

Cooling Setpoint

Delivery Air Temperature

Values ANALOG

Cooling Sensitivity


Values ANALOG °C

Cooling Sensitivity

Delivery Air Temperature

Values ANALOG

Second Cooling Setpoint


Values ANALOG °C

Second Cooling Delivery Air

Temperature

Values ANALOG

Heating Setpoint Values ANALOG °C

Second Heating setpoint Values ANALOG °C

Heating Sensitivity Values ANALOG °C

High Room Temperature

Alarm Threshold

Values ANALOG °C

Low Room Temperature Values ANALOG °C


Project no: 734273 158 31/10/2017

Alarm Threshold

Setback Mode: Cooling

Setpoint

Values ANALOG °C

Setback Mode: Heating

Setpoint

Values ANALOG °C

CW Setpoint to Start

Dehumidification

Values ANALOG °C

CW High Temperature Alarm

Threshold (c.1)

Values ANALOG °C

CW Setpoint to start CW

Operating Mode (Only TC

Units)

Values ANALOG °C

Radcooler Setpoint in Energy

Saving Mode

Values ANALOG °C

Radcooler Setpoint in DX

Mode

Values ANALOG °C

Delivery Temperature Low

Limit Setpoint(1)

Values ANALOG °C

Delta Temperature for

Automatic Mean/Local

Changeover

Values ANALOG °C

LAN Unit N Room

Temperature

Values ANALOG °C

LAN Unit N Room Humidity Values ANALOG °C

Compensation: Room

Temperature (T1)

Values ANALOG °C

(With Delivery Temp.

Regulation)

Values ANALOG °C

Compensation: Setpoint 2 Values ANALOG °C


Project no: 734273 159 31/10/2017

(SP2)


Regulation)

Values ANALOG °C

Compensation: Room

Temperature (T2)

Values ANALOG °C


Regulation)

Values ANALOG °C

Cold Water Valve Ramp

(circ.2)

Values ANALOG %

CW High Temperature Alarm

Threshold (c.2)

Values ANALOG °C

Humidifier 0-10V Ramp Values ANALOG %

Chilled Water Temperature

(circ.2)

Values ANALOG °C

Room Temperature Mean

Value

Values ANALOG °C

Room Relative Humidity Mean

Value

Values ANALOG rH%

Room Absolute Humidity Values ANALOG g/Kg

Dehumidification Setpoint Values ANALOG g/Kg

Dehumidification Prop.Band Values ANALOG g/Kg

Setback Mode:

Dehumidification Setpoint

Values ANALOG g/Kg

High Humidity Alarm

Threshold

Values ANALOG g/Kg

Humidification Setpoint Values ANALOG g/Kg


Project no: 734273 160 31/10/2017

Humidification Prop.Band Values ANALOG g/Kg

Setback Mode: Humidification

Setpoint

Values ANALOG g/Kg

Low Humidity Alarm

Threshold

Values ANALOG g/Kg

Condensing Pressure (Circuit

1)

Values ANALOG bar

Condensing Pressure Circuit 2 Values ANALOG bar

Condensing Temperature

(Circuit 1)

Values ANALOG °C

Condensing Temperature

(Circuit 2)

Values ANALOG °C

Energy Meter: Phase 1

Current

Values ANALOG A


Current

Values ANALOG A


Current

Values ANALOG A

Energy Meter: Neutral Current Values ANALOG A

Energy Meter: Line 1 to Line 2

Voltage (PM9C model)

Values ANALOG V


Voltage

Values ANALOG V


Voltage (PM9C model)

Values ANALOG V

Energy Meter: Line 1 to

Neutral Voltage (PM9C

model)

Values ANALOG V


Project no: 734273 161 31/10/2017


Neutral Voltage

Values ANALOG V


Neutral Voltage (PM9C

model)

Values ANALOG V

Energy Meter: Frequency

(PM9C model)

Values ANALOG Hz

Energy Meter: Total Active

Power (PM9C model)

Values ANALOG kW

Energy Meter: Total Reactive

Power (PM9C model)

Values ANALOG kvar

Energy Meter: Total Apparent

Power (PM9C model)

Values ANALOG kVA

Energy Meter: Total Power

Factor (PM9C model)

Values ANALOG -

Outlet Chilled Water

Temperature (circ.2)

Values ANALOG °C

Freecooling Air Damper Ramp Values ANALOG %

Return Air Damper Ramp Values ANALOG %

Freecooling Sensitivity Values ANALOG °C

Air Filter Run Hours Values INTEGER h

Unit Run Hours Values INTEGER h

Compressor 1 Run Hours Values INTEGER h


Project no: 734273 162 31/10/2017




Heater 1 Run Hours Values INTEGER h

Heater 2 Run Hours Values INTEGER h

Humidifier Run Hours Values INTEGER h

Restart Delay Values INTEGER sec

Regulation Start Transitory Values INTEGER sec

Low Pressure Delay Values INTEGER sec

Temp./Humid.Limits Alarm

Delay

Values INTEGER min

Anti-Hunting Constant Values INTEGER min

Stand-by Cycle Base Time Values INTEGER h

Number of LAN Units Values INTEGER n

Fan: Cicle Time (Sleep mode) Values INTEGER min

Circuit 1 Electronic Valve

Position

Values INTEGER step

Circuit 2 Electronic Valve

Position

Values INTEGER step

AFPS: Integral time Values INTEGER s

AFPS: Derivative Time Values INTEGER s


Project no: 734273 163 31/10/2017

AFPS: Fan Min. Speed (mode

CW)

Values INTEGER %

AFPS: Fan Max Speed Values INTEGER %

AFPS: Alarm Delay Values INTEGER s

High Delivery Temp. Alarm

Threshold

Values INTEGER °C

Day Values INTEGER

Month Values INTEGER

Year Values INTEGER



Hour Values INTEGER

Minute Values INTEGER

AFPS: Fan Min. Speed (mode

DX)

Values INTEGER %

MODE CW+DX Run Hours Values INTEGER h

MODE DX Run Hours Values INTEGER h

MODE CW Run Hours Values INTEGER h

Dehumidification Run Hours Values INTEGER h

Stand-By Mode Run Hours Values INTEGER h


Project no: 734273 164 31/10/2017

Ultracapacitor Status (UCAP) Status INTEGER 0=Power

Supply

Fail.(UCAP on

working);

1=UCAP in

charge;

2=UCAP Full

Charge

Power Supply Fail.(UCAP on

working) Time

Values INTEGER s

UCAP Charge Time Values INTEGER s

Status Energy Saving Status INTEGER

Energy Meter: Active Energy

Total Counter part 1

Values INTEGER kWh



Values INTEGER kWh

Energy Meter: Reactive

Energy Total Counter part 1

Values INTEGER kvarh



Values INTEGER kvarh

Energy Meter: Emissions of

CO2 part 1

Values INTEGER g

Energy Meter: Emissions of

CO2 part 2

Values INTEGER g

Water flow rate Values INTEGER l/min

Total cooling capacity Values INTEGER kW

Freecooling Run Hours Values INTEGER h


Project no: 734273 165 31/10/2017

Freecooling Limits:

Max.Rel.Humid.

Values INTEGER rH%

Freecooling Limits:

Min.Rel.Humid.

Values INTEGER rH%

Freecooling Status

( 0=Off; 1=waiting to

start; 2=On)

Status INTEGER -

Double Power Supply: Active

Line

( 0=A;1=B )

Status INTEGER -


Voltage

Values INTEGER V


Voltage

Values INTEGER V


Voltage

Values INTEGER V


Neutral Voltage

Values INTEGER V


Neutral Voltage

Values INTEGER V


Neutral Voltage

Values INTEGER V

Energy Meter: Frequency Values INTEGER Hz

Energy Meter: Total Active

Power

Values INTEGER kW

Energy Meter: Total Reactive

Power

Values INTEGER kVAr


Project no: 734273 166 31/10/2017

Energy Meter: Total Apparent

Power

Values INTEGER kVA



Values INTEGER Wh



Values INTEGER Wh



Values INTEGER Wh



Values INTEGER Wh



Values INTEGER VARh



Values INTEGER VARh



Values INTEGER VARh



Values INTEGER VARh

Energy Meter: Total Power

Factor (x100)

Status INTEGER -

deliverable d2.1: design of the greendc dss greendc

Documents