Research and development results

DC4Cities (D4C) goal is to tune the data centre software execution load in such a way, that the data centre power consumption matches the renewable energy source availability in compliance to energy/power goals, set by an Energy Management Authority.

Northbound Subsystem is responsible to provide, and continuously update, information related to energy availability, source mix forecasts, environmental data (such as detailed weather info) and locally produced power data.

The D4C Control System, first computes the max/ideal power targets for the next time window (approx. 24 hours) for a data centre. It then gathers information about the software running inside the data centre and provides directions on its expected energy behaviour through Southbound Interface.


The D4C Control System periodically executes following three control loops:



Power Planning Loop

During this step, the D4C Process Controller module retrieves through Northbound Interface:

  • Energy Availability Forecast (from the Grid) that provide the amount of power that will be available, the sources used and related percentage of power obtained from those renewables;
  • Amount of green power provided by Renewable Energy Providers (or by PV panels installed in the roof of the building) or Weather Forecast in order to calculate the related forecast.


EASC Control Loop

The D4C Process Controller module coordinates all activities of this step:

  • Uses the information previously retrieved and the data centre power consumption plan in order determine the overall data centre power consumption plan;
  • The overall data centre power plan is then split into quotas for each software application/system running in the data centre;
  • The different power plan quotas will be passed to the Energy Adaptive Software Controllers (EASC) through the Southbound Interface;


  • Each EASC responds with a set of alternative power plan options that try to match as close as possible the power plan quota;
  • The total set of all power plan options are analysed and consolidated into a single data centre plan by computing the best combination of the plan options;
  • The global data centre plan is built through the selection of one specific plan option for each controlled software application/system;
  • The output of this step, together with power/energy goal metrics and possible constraint violations are sent to the Escalation Manager;
  • Escalation Manager (EM) analyses retrieved data and provide short, medium and long term status as well as metrics and alarms that will be displayed inside the dashboard. The EM will also be used to involve DCBM and possibly EMA-SC into an escalation process;
  • This process refines data centre service priorities or power/energy goals and retry the problem resolution again;



  • If no exception occurred or the exception is solved, EASC will be informed about the chosen option using the using the Southbound Interface.

EASC Monitoring Loop

During this step, EASCs provide information related to business performance and power consumption and to provide them in a structured method to the D4C Monitoring Interface to avoid loss of information and to upload consistent data to the historical data base, so that forecasting models can be updated and provide consistent results.

Northbound Subsystem

The Northbound Subsystem supports DC4Cities to collect both environmental data (such as detailed weather information) and data on locally produced power. These data are used to forecast future renewable energy availability by the Forecast Controller.

DC4Cities currently uses “Connectors” to connect the peculiarities of the different data providers with respect to the unified “Renewable Energy Forecasting Interface” but there might be a possibility that the Monitoring Interface that offers a unified way to submit data will be implemented by ERDSs in the future.

Southbound Subsystem

The DC4Cities Control System interacts with the modules of the Southbound subsystem using the EASC Interface. The Southbound subsystem is composed of three generic modules:

EASC Planning module: This module provides a few option plans which schedules workload execution. These option plans are returned to the central system that consolidates and optimizes workload scheduling selecting the best and the most optimized option plans. The result of this step is an activity plan for each application.

EASC Execution module: This module receives the activity plan from the central system and enacts workload execution based on that.

EASC Monitoring module: This module monitors application execution to measure energy consumption of each application under its control.

Power Planner

DC4Cities goal is to tune the data center software execution load in such a way, that the data center power consumption matches the renewable energy source availability in compliance to energy/power goals, set by a Smart City Authority. DC4Cities therefore will give boundaries on power consumption for all time slots in the considered future time frame to determine its reference consumption levels (called max/ideal power). These levels are based on the predictions of the availability and properties of future energy of the power connection of the data center (Grid, Micro Grid, local plants). This information will be received from the Northbound Subsystem via the Renewable Energy Forecasting Interface. This power plan will be used as a guide line to satisfy the correct usage of renewable energy for the next defined timeframe (e.g. the next 24 hours).


System Optimization – Federation

Federation is a mechanism to balance eco-friendly data centres workload according to reneable energy. In the context of DC4Cities, federation enables to achieve higher RenPct levels than would be possible for individual data centers. Federation among data centers with identical connections to the same power sources (e.g. the same Smart Grid) will not be able to improve their RenPct value by shifting load. Inside the context of DC4Cities, two main logical models have been considered as viable options for an energy aware data centre federation for Smart Cities:

The Smart City Assisted/On Demand federation model

  • “On demand” federation
  • DC4Cities has the role of a decision support system
  • Called if DC fails to comply with power budget
  • Two independent DC4Cities control systems


Autonomous peer to peer federation

  • “Continous” federation
  • Two federated DCs in the same smart city context
  • DC4Cities has the role of controlling all data centres of the federations
  • DC4Cities will take autonomously decisions on the optimal strategies