Energy Optimization and Management of Demand Response Interactions in a Smart Campus

: The proposed framework enables innovative power management in smart campuses, integrating local renewable energy sources, battery banks and controllable loads and supporting Demand Response interactions with the electricity grid operators. The paper describes each system component: the Energy Management System responsible for power usage scheduling, the telecommunication infrastructure in charge of data exchanging and the integrated data repository devoted to information storage. We also discuss the relevant use cases and validate the framework in a few deployed demonstrators.


Introduction
Making public and private buildings "smart" by integrating innovative Information and Communication Technologies (ICT) in domestic applications is envisioned as a pivotal requirement for a widespread diffusion of local Renewable Energy Sources (RESes), such as solar panels.In turn, the massive adoption of "green" energy sources and their integration in a Smart Grid ecosystem can foster the reduction of carbon emissions and increase efficiency in energy usage.Currently, building heating/conditioning in urban areas account for the largest fraction of the total energy usage [1].Hence, the application of the concept of Nearly Zero Energy Building (NZEB) [2] plays a fundamental role in the achievement of environmental sustainability objectives.
Several proposals for Energy Management Systems (EMSes) for smart buildings and microgrids have recently been discussed and the implementation details of some demonstrative deployments have been described [3][4][5].However, the peculiarities of an academic campus environment require methodological solutions capable of flexibly adapting to different typologies of buildings, according to their specific use (e.g., teaching rooms, laboratories, offices and dormitories), to the presence of controllable loads (e.g., water/heat pumps, Heating, Ventilating and Air Conditioning (HVAC) plants, trigeneration plants and Electric Vehicles (EV) charging points) and of local RESes, possibly in combination with energy storage banks.Decisions about the energy usage schedules must therefore be taken on the basis of prediction models for the energy production patterns of the local RESes (e.g., according to the current weather forecasts) and for the occupancy patterns and rooms temperature of each building (e.g., based on its thermal inertia).Such models rely on weather forecast data and on real-time data collection from sensor networks deployed within the campus environment to monitor the buildings occupancy and thermal conditions.Moreover, the schedules defined by the campus EMS must adhere to specific comfort constraints in order to guarantee the users' well-being.To this aim, users are enabled to provide comfort feedback to the EMS via software applications running on portable devices.The EMS must also interact with other actors within the Smart Grid ecosystem (e.g., Distribution and Transmission System Operators, utilities, users, and third party services), support Automatic Demand Response (ADR) in presence of time-variable energy tariffs, and ensure prompt reactions in case of emergencies (e.g., faults in the electricity dispatchment infrastructure).Therefore, a complex telecommunication infrastructure is required to manage the data exchange between the EMS and generators, loads and field sensors/actuators, as well as a data repository infrastructure for information storage and retrieval.
This work presents an energy management framework for a smart campus that encompasses all the above listed functions.Thanks to the flexibility of the proposed solution, such framework can be also adapted to different scenarios (e.g., residential buildings).The framework has been deployed in a set of demonstrators, i.e., office and teaching room buildings in Politecnico di Milano and a private household.
The remainder of the paper is structured as follows: Section 2 provides an overall view of related work, whereas Section 3 describes some use cases in which the proposed framework could be adopted.Section 4 first describes the general framework structure, then focuses on the optimization methods details implemented by the EMS and on the telecommunication infrastructure which manages information exchange, storage and retrieval.The exploitation and assessment of the framework are discussed in Section 5. Finally, Section 6 concludes the paper.

Related Work
Several methodologies for the management of energy usage in smart buildings have recently been presented in the scientific literature: reference [6] is a complete survey on the possible approaches.Moreover, frameworks [7][8][9] provide either real-time or day-ahead energy consumption schedules on the basis of behavioural profiling mechanisms aimed at deducing dwellers habits and at identifying possible energy saving actions.Frameworks integrating local RESes and energy storage banks have also been designed [10,11].A comparative survey on demand side management systems involving smart buildings and electricity grid can be found in [12].
Focusing on the "Smart Office" scenario, Zarkadis et al. [13] design different algorithms for the control of solar shadings, electric lighting and heating equipment.To this aim, one university building has been extensively monitored through sensor networks for a six years period.Additionally, weather statistics have been recorded.The proposed algorithms led to a consistent reduction in energy consumption without degrading the comfort level perceived by users (and even improving it).Similarly, our proposed EMS includes constraints that guarantee the satisfaction of users' comfort levels.
Bull et al. [14] evaluate the influence of different engagement strategies on users' behavior and energy consumption reduction.Balaji et al. [15] include occupants' feedback into the HVAC management system, transforming the user in an "active sensor" within the building, capable of suggesting improved strategies.To involve users, in our framework we enable interactions between campus occupants and the EMS via a mobile App that allows users to express their perceived comfort level.
Other recent proposals addressing Smart Office environments include energy saving strategies for the management of room lighting based on occupancy detection (by Stojanovic et al. [16]), identification of lighting energy waste patterns in educational institutes by means of data mining techniques [17] and some demonstrative frameworks deploying self-sustained distributed energy systems [3][4][5]18].
Methodologies for knowledge extraction aimed at automatically inferring and/or updating rule sets for the energy management of a smart office (or a generic smart building) are discussed by Gupta et al. [19] and Anjos et al. [20]: these algorithms exploit data gathered from smart meters, sensors and actuators installed within the office building and combine them with the users' preferences in order to define control rules that can be dynamically generated, modified and deleted.However, these rule-inference methods do not guarantee optimality.Other contributions exploit data mining approaches to predict the building energy performance: Fan et al. [21] use ensemble models for predicting next-day energy consumption and peak power, whereas Balac et al. [22] develop a highly scalable framework capable of analysing and predicting the building behaviour considering alternative energy sources and smart grid constraints in real-time.
Among the frameworks specifically tailored for campus environments, Guan et al. [23] design a mixed integer linear model for the joint minimization of gas and electricity expenses of a university building equipped with a controllable combined heat-power system, a battery storage bank and solar panels.The optimization can be performed either relying on forecasting algorithms about future events, or modeling "scenario trees" encompassing multiple possible future production/consumption patterns, which may occur with different probabilities.Our proposed EMS adopts the former approach.However, the optimization procedure is invoked at regular time intervals during the optimization time span and decisions are dynamically updated, following a receding horizon strategy.
In the context of residential buildings, Bozchalui et al. [24] and Kriett et al. [25] propose optimization models for the schedule of domestic electric appliances usage, considering several objectives such as the minimization of the overall energy consumption/expenses, of carbon emissions, and of the peak energy absorption.Our EMS also combines multiple objective functions, including energy expenses, users' comfort, and the compliance to ADR requests issued by the Distribution System Operator (DSO).
Multiple contributions highlight the importance of the holistic management of building data: Curry et al. [26] exploit linked data as enabling technology to create an integrated graph of relevant knowledge including energy consumption, utility data, occupancy patterns and weather records; Agarwal et al. [27] propose an extensible, distributed and scalable system for storage, shared access and management of building-related information.The prototype facilitates access to the data collected using user management tools and allow standardized client applications to be built on top of it.For the management of relevant knowledge, our solution integrates a data repository devoted to data gathering from different sources (e.g., sensors, actuators, controllable devices) which can guarantee shared real-time access to all the entities within the energy management framework.
The solutions available in literature, both in terms of experimental case studies and approaches, usually tackle a subset of the issues we address in our proposed framework, which offers a scalable solution that integrates a multiplicity of heterogeneous energy sources and loads and directly involves the building occupants.

Usage Scenarios
The smart campus may interact with the power grid according to three different paradigms: market-driven, demand response, and emergency.In the market-driven scenario, the amount of power absorbed/injected from/into the grid is autonomously decided by the EMS depending on the current energy price and limited only by the contractual agreements.If such agreements include time-variable tariffs application, tariffs might either be known in advance (e.g., in this case they are computed applying a predefined price curve or according to the day-ahead market) or be dynamically updated with reference to real-time energy market fluctuations.
Conversely, in the demand response scenario, Demand Response Events (DREs) are periodically issued by the DSO.DREs are addressed to one or multiple Points of Delivery (PODs), i.e., electricity subscribers, and include: • a validity time period; • a monetary incentive; • one among the following specifications: an upper bound to the active power that the subscriber can absorb from the grid; -an upper bound to the active power that the subscriber can inject into the grid; -an amount of reactive power that the subscriber should inject into the grid.
The DRE is advertised 1.5 h up to one day in advance with respect to the beginning of the validity time period.When a DRE is received, the EMS evaluates different optimization strategies taking into account the DSO request.After the validity time period, the DSO verifies which PODs complied with the DRE requests and applies the monetary discount to the subscriber's bill.
Lastly, the emergency scenario enables the DSO to control directly the subscriber's load, bypassing the decisions taken by the EMS.Depending on the emergency condition nature, the DSO might, for instance, (i) detach the subscriber from the electricity grid; (ii) limit its power injection/absorption; or (iii) modify the amount of injected reactive power.
However, DSO control capabilities of campus loads are much coarser than the EMS ones and the emergency scenario should be considered as an extreme countermeasure, whereas DREs should be applied as a prevention mechanism, in order to shape the campus load consumption curve without upsetting the energy usage schedules independently defined by the EMS.

The Energy Management Framework
In this section we introduce the proposed EMS framework by discussing its architecture and internals.

System Overview
The EMS shares information and activities with a set of actors that contribute to its actions.Among them, the most relevant are: With reference to Figure 1, the energy management framework architecture is composed of different modules, which can be also considered as separate domains: • Demand Side Management Module: consists of the DSO energy management and dispatching infrastructure and its interfaces with TSO; • Back-End Module: is the core of the framework and comprises the EMS and the data repository.
The data repository stores the relevant information shared among the different modules and used by the EMS.The module has a set of interfaces towards the above-mentioned external entities and the repository to collect information, e.g., energy prices provided by energy providers, photovoltaic production and EV usage forecasts provided by profilers, and another set towards the EMS and the application module; • Front-end Module: includes field sensors and actuators which communicate with gateways and controllers, the latter map the EMS scheduling output into commands to control field devices; • Application Module: merges a set of applications supporting interactions between users and EMS, including interfaces for users' preferences setting about their electric appliances management, for the collection of users' feedback on their comfort level, and for data visualization and monitoring.Users' comfort feedback is expressed through a mobile App (developed in both iOS and Android) designed following the ANSI/ASHAREE Standard 55-2010.The App allows users to express their perceived comfort with reference to temperature, humidity and air quality.

The ICT Infrastructure
The ICT infrastructure has been designed to pursue a set of goals: 1. the field devices should work independently from the EMS in case of no provided input; 2.
the infrastructure should be flexible enough to accustom multiple adapters comprising a wide range of field devices; 3.
the data collection rate from field devices is independent of the EMS decisions and depends on the specific field device; 4.
the EMS takes its decisions evaluating system state snapshots at a given time and available forecasts regarding future energy production/consumption of generators/loads; 5.
the EMS chooses one energy production/consumption pattern for each generator/load: the pattern includes power consumption set points for each involved field device within a given time horizon.Field actuators are in charge of translating set points into commands to be issued to devices; 6.
the EMS running frequency and optimization horizon might change over time.
On the basis of the stated goals, the ICT infrastructure leverages the two main functional elements in the back-end: the data repository and the EMS.The data repository collects data from the field gateways (which read the field sensors), from the forecast models, and from the EMS (which logs its decisions).Data is available to the EMS, profilers, business intelligence processes and data presentation applications.
The EMS is designed to run at every time slot, but it can be configured to run with a different frequency (e.g., a lower one).The EMS collects the information needed for the optimization from the data repository and executes the optimization algorithm.The optimization output consists of power demand scheduling for passive loads, such as HVACs and EVs, and of storage scheduling for power generated by RESes.
In general, the EMS bases its decisions on predictions which field devices cannot always adhere to.For example, the energy production generated by PV units or power demanded by EVs can be lower than expected.For this reason, the EMS pushes field devices schedules to a group of controllers that transform set points into constraints on the maximum power that each device is allowed to drain from/inject into the system.Prediction errors are prevented in two ways: small errors are handled by running the EMS frequently and by using up-to-date data at each iteration.The EMS continuously updates its decisions to cope with changing conditions and to avoid large accumulated errors, thus limiting inefficiencies.Large errors, such as a completely wrong weather forecast, are dealt by each controller, which can raise the EMS constraints if the controlled field device cannot provide its minimum service.This happens, for example, with the HVACs: when the allocated power results in a too low (or too high) temperature and, consequently, in a too high users' discomfort, the controller could remove the constraint thus allowing the system to work freely.
The back-end domain comprises the data repository, the EMS and a set of forecast models.The data repository can be hosted either within campus data centers or at any Infrastructure/Platform as a Service (IaaS/PaaS) provider.Back-end components interact with external data sources such as the DSO or the weather forecast service using the Internet, and with the data presentation applications and field front-end by means of the campus LAN.
Gateways and controllers are physical devices equipped with a networking interface, thus enabling communication with sensors and actuators and with the back-end module.Moreover, they are supplied with sufficient computational capabilities to fulfill some predefined automated control operations, such as lifting power constraints if target values can not be met by sensors.Generally, controllers also behave as gateways and interact with the back-end domain.

The Data Repository
The EMS is able to take educated decisions based on the available information collected during the lifetime of the system and stored in the so-called data repository, depicted in Figure 2. In order not to overload the repository with too many data which are not of interest except for the data provider (which would see the repository as a local database) or for the single actor (that would use the repository as a data exchange mean), only information exploited by more than two (sub)systems is stored and shared.In particular, the following pieces of information are stored: • electricity market prices, collected daily; • data collected from sensors monitoring the building thermal conditions, energy consumption (within the buildings and from the EV chargers) and the users' feedback on their thermal comfort, collected with a tunable frequency; • weather forecasts used to support the estimation of PV energy production as well as the expected energy consumption to heat/cool the building spaces, collected daily;  As discussed, these data are used by the EMS to make decisions based on the historical behavior of the system and of the users (e.g., past energy consumption patterns) and on the forecasts of the future demands.In this case, data can be collected with the appropriate frequency (e.g., weather conditions are monitored every 30 min) and periodically pushed to the data repository, since it is not exploited in real-time by any actor, including the EMS.Indeed, there are situations where real-time interaction is needed between two actors (e.g., the EMS and the EV recharge station to interrupt the action in order to immediately reduce energy consumption) and thus direct communication is supported and only the result of the activity is then stored in the data repository.
As a consequence, data in the repository constitutes the system status, updated with a variable delay in the range of tens of minutes.They constitute the source for user applications (such as the one for providing the user comfort feedback), data audit and analysis (also with diagnostic aims), and public displays.
Since data is produced by different (and sometimes redundant) sources, data are integrated, cleaned and summarized, in order to be exploited by the EMS and other controllers.More in detail, a three-layer architecture has been designed for the data repository with the aim of providing a flexible and extensible framework, possibly dealing with different application environments and integrating commercial as well as proprietary data collection solutions.
The lower layer collects raw data from the field (i.e., from wired/wireless sensors, EV recharge stations and energy production/consumption monitors).Gateways have been used to decouple data collection from transmission to the data repository, adopting a polling-based acquisition approach, to manage the high (and possibly variable) number of sensors.This level has been implemented using a NoSQL datastore, Cassandra [28], a distributed database management system designed to handle large amounts of semi-structured heterogeneous data and providing high availability and fault tolerance.A set of distributed algorithms to perform data cleaning and summarization have also been implemented.Furthermore, the system provides online data analysis using an SQL-like query language and supports batch processing over its distributed file system, thus enabling additional data analytics and KPI evaluations to improve the EMS mission.
The middle layer of the architecture has been implemented with a relational database in PostgreSQL; it is used to store the processed raw data.Data coming from the electricity market, the weather forecast, and DRE manifests are directly stored in this middle layer.As mentioned, together with the dynamic data coming from the various sources, the data repository also stores all the static structured data on the (sub)systems and components characteristics.
The EMS and other controllers/actors access this data through the top layer, which consists in a set of REST APIs, for a coherent access to the information.

The EMS Interaction Protocol
The core of the EMS is the Optimizer, i.e., an algorithm which chooses the power usage profile of each electric actor that allows the system to minimize the cost function.We now list the parameters taken as input by the Optimizer, which are summarized in Table 1.Let L and G be the set of power loads and generation plants, respectively.Each plant g ∈ G is associated to an economic incentive a g which is remitted to the EMS for each unit of produced energy.Every electric subsystem (either load or generation plant) is managed by a Profile Generator (PG).Each PG comprises a prediction model of the managed subsystem and is capable of generating several feasible consumption/production profiles.The Optimizer and the PGs operate over a finite scheduling horizon partitioned in a set T of time slots of configurable duration (e.g., for a large campus environment, we consider 15-minute time slots, whereas for a private detached house we consider 5-min intervals).The Optimizer is scheduled to run at the beginning of each time slot and interacts with the other entities according to the protocol in Figure 3.  First, the Optimizer obtains the time-varying energy prices over the optimization horizon.The prices can be provided by the utility, fetched from the day-ahead market exchange, or predicted in case of participation to the real-time market.At the same time, the Optimizer obtains the list of active DREs.Let D be the set of DRE manifests the EMS may adhere to.Such requests are associated to a set of time slots T d ⊂ T indicating the request validity time window and to an economic incentive B d which is remitted to the EMS upon acceptance.The requests are categorized in four subsets: It follows that D = DE max ∪ DE min ∪ DV max ∪ DV min .Note that the sets T d are defined over non-overlapping time windows, i.e., each time slot is included in the validity time span of at most one request.In case no requests are available during a time slot, the maximum amount of injected/absorbed energy is limited by the contractual thresholds E t max , V t max .Then, the Optimizer queries the PG of the uncontrollable power loads and generators.These include e.g., lights, elevators, computing equipment, and power sources without energy storage devices.Each of these PGs provides a prediction of the expected energy consumption or generation in each time slot of the optimization horizon.

DSO
If the optimization window includes any time slot which falls in a DRE specifying an upper bound for the absorbed power, the Optimizer calculates, for those time slots, the controllable power limit that can be absorbed from the grid by subtracting the uncontrollable power consumption and adding the uncontrollable power generation.Then, the Optimizer executes an algorithm for splitting the controllable power limit into a power limit mask for each PG managing a controllable load (i.e., a manageable appliance whose consumption can be deferred, interrupted and/or tuned).In our implementation, each PG is associated with a predefined weight and the Optimizer simply splits the limit according to these weights.The Optimizer employs a similar algorithm to calculate a power limit mask for PGs managing controllable sources if the optimization windows contains DREs specifying an upper bound to the injected power.
Next, the Optimizer sends to each controllable PG the power limit mask and queries for a set of profiles over the optimization horizon.Each PG must propose one or more feasible profiles corresponding to different comfort levels and different energy consumption or generation schedules.In case the EMS advertises a power limit, then the PGs should also propose profiles that satisfy the limit in addition to the usual profiles, so that the EMS can decide whether to comply to the DRE requests.The strategy used to elaborate the proposal is PG-specific and depends on the available field data and available models.In general, each PG should be able to provide at least one backup profile, which might be suboptimal.
The separation between Optimizer and PGs makes it possible to cope with time-varying, non-linear constraints without jeopardizing the manageability of the linear optimization model.For example a storage system might have constraints with respect to the number of daily charge/discharge cycles.This can be easily implemented in the PG for the storage system, which proposes only solutions with a duty cycle compatible with the expected battery aging.In turn, the optimizer is bound to choose one of the proposed profiles.
Each power load (generation plant) is then characterized by a set of power consumption/production profiles P l ∀l ∈ L (P g ∀g ∈ G).Note that the optimization algorithm of the EMS is agnostic w.r.t. the criteria the profile generation process is based on.Such criteria may take into account several factors such as the weather forecasts, the trend of the electricity prices, and the users' preferences.Each generated profile comprises: • a unique ID; • a list of set points and their corresponding time schedule to enforce the system to behave according to the profile shape; • a 24-h profile q t l p (q t gp ), indicating the expected average power consumption or generation for each time slot t ∈ T ; • a 24-h profile c t l p of the expected comfort for each time slot (this profile may represent thermal comfort, or the satisfaction of the users of the electric vehicles: the exact semantic depends on the specific PG); a threshold ca t l on the minimum comfort level that each load must ensure for every time slot is also included.• a gain or cost F l p (F gp ) associated to the profile, which may take into account the usage of non-electric power sources such as gas for heating, the exploitation of economic incentives for using RESes, or different wear and tear costs.Gains are expressed with negative values, whereas costs are expressed with positive values.
Once all the queried PGs provide their list, the Optimizer chooses the best combination of profiles by means of the algorithm described in Section 4.5 and sends the chosen profile ID back to each PG.Each PG is then responsible of enforcing the chosen profile by configuring the relevant controllers so that the field devices behave as desired.
It is worth noting that controllers are configured for an entire optimization horizon, but the configuration can be overwritten at each optimization time slot if external conditions change, (e.g., better predictions are available or new DRE is published by the DSO).

The EMS Optimization Model
Whenever a new time slot starts, the EMS receives the energy production/consumption profiles generated by the PGs and the energy buying/selling prices f t , v t ∀t ∈ T .The EMS then runs the following Mixed Integer Linear Programming (MILP) model to schedule the energy usage plan over the horizon T .

Objective Function
The goal of the EMS is to decide which power production/consumption profile each load/generator must follow over the horizon T with the aim of minimizing the total energy expenses while maximizing the users' utility.To this end, the objective function is modelled as follows: where the first contribution represents the total cost incurred by the system, obtained as the difference between the daily energy expenses and the economical incentives remitted through ADR, whereas the second contribution represents the comfort of users.The coefficients α and β are weights used to control the trade-off between costs and comfort.Two additional weights α 1 , α 2 are used to magnify/reduce the value of the demand response incentives w.r.t. the energy consumption expenses.Similarly, the coefficients γ t p are used to vary the impact of the comfort provided by a specific load l during a given time interval t.

Constraints
Constraints 2 and 3 impose that only one profile is chosen for each load/generator.The energy balance of the system in each time slot is ensured by Constraint 4, whereas Constraints 5 and 6 maintain the energy absorption/injection within the contractual limits.Moreover, Constraint 7 imposes that the system either absorbs power from the grid or injects power into the grid (i.e., the unidirectionality of the power flow) during each time slot.Constraint 8 ensures that the comfort level provided by each does not drop below a minimum acceptability level.The final group of equations imposes the compliance to the demand response requests (in case they are accepted), according to their type: Constraint 9 limits the power absorption below the threshold qDE dt max ; Constraint 10 maintains the power absorption above the threshold qDE dt min ; Constraint 11 limits the power injection below the threshold qDV dt max ; Constraint 12 maintains the power injection above the threshold qDV dt min ; Constraint 13 imposes that the above mentioned limitations are activated for the whole validity time span of the demand response requests. ∑

Framework Validation
A pilot version of the proposed framework has been implemented and is currently in service at the Politecnico di Milano Campus to manage the controllable production, storage, and loads of a large building.The building comprises four floors used for various university activities.Roughly classrooms make up 60% of the building, whereas 15% is occupied by classrooms equipped with electric plugs available to students and the remaining 25% by administrative offices.The building frame is mainly composed of reinforced concrete while the external walls are composed by glass and reinforced concrete with insulating material in between.Double layer strip windows surround all the building.The gross floor area is equal to 3,344 m 2 , requiring 58 kWh/m 3 per year for heating.The building operates in grid-connected mode, so any mismatch between consumption and production results in a power exchange with the grid different than expected and, consequently, in a suboptimal usage of resources.The electric actors serving the building are three: 1.
Photovoltaic system.The photovoltaic plant is an integrated rooftop solution capable of supplying both electric and thermal energy.The maximum electric power reached in standard conditions is 10 kW with an electric efficiency of 15.06%, while the thermal contribution can reach 1,040 W at 80 ℃.The plant receives incentives for production, therefore a g = 0.35 e/kWh.Currently, the PG associated to the PV plant is very simple and only considers hourly and seasonal variations.The design of a more sophisticated predictor that considers both weather forecast [29] and short term dynamics [30] is left for future work.

2.
Heating, Ventilating and Air Conditioning system (HVAC).Two heat pumps are used for heating and cooling.The first one can supply up to 374 kW of cooling power and up to 429 kW of heating power (ESEER 5.65, COP 4.1) for an overall maximum electric consumption of 82.4 kW.
The second one can supply a cooling power up to 114 kW, heating power up to 110 kW and is characterized by a maximum electric consumption equal to 21.4 kW.For what concerns the air distribution system, two collectors receive the carrier coming from the heat pumps and feed the air handling units (AHUs) and all the fan coils of the building.Moreover, a 23 m 3 thermal storage has been installed exploiting the fire system tank which can be used during the summer season.Set points can be automatically imposed thanks to a Supervisory Control and Data Acquisition (SCADA).The building also comprises a natural gas boiler as a backup for the HVACs.In case it is necessary to turn on the boiler to achieve a desired comfort level, the PG will provide a profile with nonzero F l p t .

3.
Electric Vehicles recharge system.The building includes a recharging station that can supply up to 20 kW to a connected electric vehicle.Testing was conducted using a Renault Zoe with a battery capacity of 22 kWh.This car model accepts variable AC input power from 9 kW up to 43 kW, allowing for quick recharge in less than one hour.The supported variable input power is crucial for the energy scheduling defined by the EMS.
Overall, the demonstrator has a maximum power supply equal to 200 kW and can feed the network up to 10 kW depending on the photovoltaic energy available.For each electric actor we implemented a suitable Profile Generator (PG), so G = {PV system} and L = {HVAC, EV, uncontrollable loads}, where the third element of the set groups all the non-controllable appliances.In the experimental setup, each hour the EMS uses the protocol described in Section 4.4 to collect from each PG the set of proposed profiles and runs the MILP model described in Section 4.5 to choose the optimal combination, which is then delivered to the actuators.The environmental and thermal data are sampled and stored every 6 min.HVACs, EV recharge stations and building loads energy consumption are collected with a 1-minute frequency.Sensed data are stored locally on the ICT infrastructure gateways, and pushed to the data repository every 15 min.These parameters provided a good trade-off between access frequency to the data repository and amount of stored data.
In this section, we briefly report on the collected data and discuss how the exploitation of the framework allows for a modulation of the energy consumption.

Preliminary Analysis of the Collected Data
A preliminary analysis has been performed to compare the comfort level perceived and reported by the occupants by means of the mobile App, and the comfort level that can be inferred from the sensor data by applying the classification defined by the Italian national regulation.The App has been designed following the ANSI/ASHAREE Standard 55-2010 that recommends a 5-labels scale to survey users' opinion, as summarized in Table 2.In particular, the purpose of our work is to get useful insights on specific scenarios that require marked attention by the EMS.Our preliminary analysis stresses the urgency of adopting an intelligent system able to smooth critical recurrent scenarios, e.g., remarkable changes in weather conditions, and to adopt long-term smart strategies, e.g., improving the management during non-working days.Indeed, the aim of the optimization algorithm is twofold: improving the comfort perceived by occupants while possibly reducing the energy consumption due to HVACs.Since April 2015, we have been monitoring a sets of variables inside and outside a group of university buildings: in each building we gather data regarding temperature, humidity, lightness and air quality on a selected subset of rooms.We further record data from the weather station installed on the rooftop of one block which includes air temperature, relative humidity, pressure, etc.The buildings are close enough to use a single weather station to monitor weather conditions.The analysis has been carried on in a market driven scenario as previously detailed in Section 3.
For the sake of conciseness, we report data collected in the building where the EMS is installed during one summer month and one winter month.In both periods the HVAC system is turned on.
The following analysis focuses on temperature, as the main factor influencing the comfort perceived by the occupants.We examined the data collected during the first phase of our experimentation with reference to the current Italian national regulation ISO 7730/2005, briefly summarized in Table 3.Each class corresponds to an operative temperature interval in winter and summer time, and the last column provides the Predicted Percentage of Dissatisfied occupants (PPD).Winter and summer times are discriminated according to the external average daily air temperature; if the temperature exceeds 15 °C, the summer case should be applied.Results have been computed assuming that the operative temperature is approximated by the sensed air temperature.The temperature has been calculated by averaging the data collected by all the temperature sensors installed inside the building, within 15 min, during working hours (i.e., from 8 am to 6 pm).More sophisticated techniques, such as mode or median, introduce complexity considering the high number of sensors and the short sampling time, while carrying little benefit to this approximate analysis.The charts in Figures 4 and 5 depict the disjointed percentage of temperatures falling within class A and B, i.e., classes with dissatisfied users percentages below 6% and 10%, respectively.In addition, internal and external average daily temperatures are plotted on the secondary vertical axis to offer a deeper understanding.It is worth noting that days with no plotted percentages show average temperatures falling out of the ranges of classes A and B, thus highlighting high discomfort or high energy waste due to overcooling or overheating.
Indeed, the worst results occurred in presence of a steep change in the outside temperature: this suggests that the EMS needs to improve its strategies during these days.As it can be noted in Figures 4 and 5, in the last part of May, after the sudden temperature decrease from 21.7 °C to 14.6 °C within two days, the user comfort decreases.A similar pattern can be identified during the first week of November, when the building was overheated to 27 °C to counteract the sharp decrease of the outside temperature.In brief, the system needs better tuning with reference to the weather forecast, to provide an appropriate comfort to the occupants while saving energy, e.g., to avoid overheating.
A further point to consider concerns non-working days when the comfort goal is neglected by the EMS, being the building supposedly empty.This means setting the comfort level to be ensured to its minimum, thus allowing the EMS to maximize other goals.During these days (e.g., from 1 to 3 May, 23-24 May and 21-22 November), the inside temperature is more closely related to external conditions and to the other objectives considered by the EMS (e.g., cost and power consumption), indeed on holidays and weekends the objective is to maintain a certain temperature in order to avoid a greater effort on HVAC restarting.
Tables 4 and 5 show the percentage of users in each comfort class measured (a) through the mobile App feedback or (b) inferred by applying the ISO regulation in the same instant when a user reported a feedback and considering comfort classes disjointedly.Summer period comprises May, June, July and September while winter period includes November, December, January and February.The analysis of the comfort feedback collected through the mobile App shows that satisfied users are around 50% in each period.On the other hand, very dissatisfied users, i.e., users who vote −2 or 2, range between 15% and 30%.In each period the results are consistent since class A contains the highest percentage of comfortable users, as pointed out by the gathered feedback.In the Demand-Response scenario, the DSO can send DREs to the low voltage and medium voltage customers in presence of issues related to the energy dispatchment within the distribution network (e.g., overloads).Every hour, the EMS checks the presence of new requests.If one or more DREs are found, it includes them in the set D. If the incentive offered in the DRE manifest compensates the efforts for a rescheduling, the EMS may alter the load profiles of the electric actors during the subsequent 24 h.
We show how the system reacts to DRE events by comparing the EMS schedule in a typical day without DREs versus the schedule obtained in presence of a DRE event.For this experiment, the MILP formulation proposed in Section 4.5 has been implemented and solved with the AMPL-CPLEX solver.We set the cost-comfort tradeoff coefficients α, α 1 , and α 2 equal to 1.This means that a euro saved by shifting a load or a euro gained by satisfying a DRE event are equivalent.Therefore, assuming two possible schedules result in the same comfort level, the EMS will reschedule a load whenever the DRE incentive will, at least, cover any additional cost.The coefficients γ t p are set to 1/24 so that the daily comfort for each PG is the average comfort in each time slot and ranges from 0 to 1.The coefficient β is set to e 20, which means that the optimizer chooses to reduce the daily comfort by 10% if it results in saving 2 euros.This value is intentionally high.With typical energy prices, it impossible for the optimizer to decide to simply reduce the comfort in order to save money.In normal conditions, the EMS will try to provide the maximum comfort at the minimum cost.On the other hand, the EMS could reduce the comfort if a DRE incentive is large enough to make up for the comfort loss.In all the considered instances, the computational time was in the order of a few seconds.
Figure 6 shows the power consumption scheduled by the EMS at 17:45 by considering the expected production of the PV plant (red curve) and the sum of the expected consumption of the uncontrollable appliances, the HVACs and the EV recharge stations.It is worth noting that, at the time the optimizer is executed, the HVAC is going off and it is not scheduled to run on the following day.When no DRE manifest is present, the decision only depends on the energy prices, which are shown in Figure 7.The power consumption spikes at 12:30 is due to recharge of the EV.In this experiment the EV was scheduled to be available during office hours and the EMS schedules its recharge when the energy prices are at their lowest within such time interval.As reported in Figure 8, the results of the new optimization shift the EV recharge schedule of a few hours in advance with respect to the previous configuration because, when taking the incentive into account, the new schedule becomes cheaper.This choice of the EMS heavily depends on the incentive amount.If the incentive is low, the EMS will not alter the consumption schedule of the campus.
If the incentive is too high, the EMS might lower the campus users' comfort level in order to fulfill the DRE.In turn, this could increase the number of unsatisfied occupants.We plan to study the impact of different incentives on the discomfort and on the willingness to experiment discomfort in exchange for a lower probability of emergency actions.The goal is to provide data to the DSO regarding the effectiveness of a DSO-driven incentive-based policy to increase system availability.

Conclusions
This paper proposes an energy management framework for a smart campus including local renewable energy sources, a storage bank, and several controllable loads.The framework incorporates an optimizer which schedules the usage of electric loads, various predictors for the energy production/consumption patterns, a repository and an ICT infrastructure dedicated to data collection and management.The paper discusses relevant use cases and evaluates the performance of the proposed framework.
In the market-driven scenario, the EMS minimizes the cost of energy by, among others, fostering self-consumption.On the other hand, the impact on the comfort and the total energy consumption is minimal.
In the DSO-driven scenario, the EMS reacts to DSO requests by modifying and rescheduling energy consumption and/or production depending on the associated incentive.This is an entirely new scenario enabled by the EMS that results in an economic advantage for the final user.The monetary impact depends on the amount of incentives that are provided by the DSO, which is still under study.

PG
Profile generator POD Point of delivery RES Renewable energy source SCADA Supervisory control and data acquisition TSO Transmission system operator

Figure 6 .
Figure 6.Average Power Schedule E t /(1 h) and V t /(1 h) during the test day in absence of DREs.

Figure 7 .
Figure 7. Energy prices f t and v t during the test day.

Figure 8 .
Figure 8.Average Power Schedule E t /(1 h) and V t /(1 h) during the test day in presence of one DRE.

Table 1 .
List of main symbols.DE max ∪ DE min ∪ DV max ∪ DV min ) T d ⊂ T set of validity time slots of request d ∈ D expected average power consumption characterizing profile p ∈ P l of load l ∈ L for each time slot t ∈ T expected comfort level associated to profile p ∈ P l of load l ∈ L for each time slot t ∈ T threshold on the minimum comfort level to be guaranteed by load l ∈ L for each time slot t ∈ T p weights used to vary the impact of the comfort provided by a specific load l ∈ L during a given time interval t ∈ T

•
DE max : set of requests d to limit the power absorption below the threshold value qDE dt max for each time slot t ∈ T d ; • DE min : set of requests d to maintain the power absorption above the threshold value qDE dt min for each time slot t ∈ T d ; • DE max : set of requests d to limit the power injection below the threshold value qDV dt max for each time slot t ∈ T d ; • DE min : set of requests d to maintain the power injection above the threshold value qDV dt min for each time slot t ∈ T d ; (V t ): non-negative variables, indicate the total absorbed/injected energy during time slot t; • y l p (y gp ): boolean variables, set to 1 if profile p ∈ P l (p ∈ P g ) is chosen for plant l ∈ L (g ∈ G), : boolean variable, it is 1 if request d ∈ D is satisfied during time slot t, 0 otherwise; • z d : boolean variable, it is 1 if request d ∈ D is satisfied in every time slot t ∈ T , 0 otherwise. dt

Table 3 .
Comfort classes defined by the Italian national regulation ISO 7730/2005.

Table 4 .
Comfort analysis w.r.t.ISO 7730/2005 May 2015, comfort classes daily percentage plotted on the main vertical axis.Comfort analysis summer 2015.(a) Feedback collected through the mobile App; (b) ISO 7730/2005 comfort class.