1. Introduction
Many attractive definitions are currently used for demand response (DR); two of them are: “today’s killer app for smart grid” and “the key for engaging consumers in the smart grid”. A conventional definition states that DR is a program of actions, aimed at changes in habits of end-use customers in consuming energy [
1]; these changes are mainly driven by price signals and discounted rates that discourage the use of electricity during peak hours and allow savings on bills [
2]. The easiest way to induce a customer to change his habits in using electricity is to schedule its electric loads; the bigger the savings in the bill achieved through loads scheduling, the higher the participation of the customer in a DR program. A comprehensive view on technical methodologies and architecture, and socioeconomic and regulatory factors that could facilitate the uptake of DR is reported in [
3]. In the path of change mentioned above, the customer does not act as an individual; on the contrary, the customer is a member of an integrated community, coordinated by an intermediary named aggregator or coalition coordinator [
4,
5,
6,
7].
In the framework of this integrated community, the aggregator and the customer communicate with each other very frequently; the energy box (EB) is the device, which interfaces the aggregator and the customer [
3]. For instance, in [
8], the EB is the instrument placing bids on the Portuguese tertiary market. The aggregator negotiates with the grid operator, placing a bid, which depends on bids previously returned by all EBs. Each EB can provide two different bids where the first pays for a change in the state of charge of batteries—optimally sized as in [
9] and placed in the residential unit—whereas the second pays for a change in the temperature set point of air conditioning of the residential unit. In [
10], the EB is a full energy home controller able to manage between five and ten loads; two Linux-based EBs mounted with a ZigBee controller for the Spanish and French trial are presented. Also in [
11], the EB is a home controller for a cost-effective nonintrusive load monitor, which provides a mechanism to easily understand and control energy consumption as well as to securely permit reconfiguration and programming from anywhere. On the contrary, the EB presented in [
12] is a sophisticated software for energy management systems, consisting of a suite of algorithms which support the sequential decision-making process under uncertainty in a stochastic dynamic programming network. Also, the EB presented in [
13] is a software; more precisely, it is a unique decision-making algorithm which serves an automated DR program where the automated characteristic aims to reduce uncertainty and complexity of daily price fluctuation from the customer’s perspective. Lastly, the EB proposed in [
14] provides the wind power measurements via a multilayer feed-forward back-propagation neural network.
Given the aforementioned, the design of an EB is a hard task and full of challenges; a first and well-known challenge is to design the EB as a useful tool for communication between the consumer and the aggregator. A further challenge is to design an EB able to interact with the home energy management system (HEMS); this is because an HEMS, in general, does not necessarily share information and data (e.g., energy consumption measurements) with third parties, and it does not necessarily accept commands (e.g., turn on/off appliances) from third parties. In a residential unit, the HEMS is the device that monitors, controls and optimizes all peripherals, storage systems, distributed generators and smart meters, as illustrated in
Figure 1. The HEMS asks the smart meters for energy consumptions so as to build a detailed and comprehensive status of the residential unit. Such a status is useful to precisely model and estimate energy consumption of the residential unit by using, as an example, a learning-based mechanism as in [
15,
16]. Therefore, the interoperability between EB and HEMS is a crucial point for implementation of a DR program in a framework of integrated community. Interoperability must be ensured regarding the communication protocols, the data format and the physical media used for communication; interoperability must also be extended to smart meters and all peripherals [
17] which operate in islanded mode or in absence of a HEMS. When the same vendor produces the EB, the HEMS, the smart meters, the smart plugs and peripherals, the full interoperability is implicitly achieved; on the contrary, the management of devices produced by different vendors is much more difficult. A last challenge is to design the EB as a cost-effective tool if this technology is intended for a large number of customers, including less affluent people.
This paper proposes a new EB as a viable solution to the challenge of the communication between consumer and aggregator, and to the challenge of the interaction between an EB and HEMS. The paper also illustrates two prototypes of the proposed EB to have a clear overview of management and material requirements, as well as of cost-effectiveness; both prototypes are tested in the lab using a real home automation system.
Concerning the communication between the consumer and the aggregator, the proposed EB communicates with the aggregator’s IT platform and requires access to an application, service or system [
18]. Communication is over the Internet and is based on the traditional client–server paradigm; HyperText Transfer Protocol over Secure Socket Layer (HTTPS) is the communication protocol used for secure communication. As illustrated in
Figure 1, the proposed EB connects to the aggregator, uploads the user’s preferences and requires access to the application called prosumer problem; the application responds by providing the optimal loads scheduling. Furthermore, as in
Figure 1, the EB uploads power/voltage/current measurements and it requires access to the service called monitoring and calculation; the service responds by providing reports and statistics.
Concerning the interaction with a HEMS, the proposed EB overcomes the problem of interaction because it directly communicates with all peripherals of the home automation system, bypassing the HEMS as in
Figure 1. In particular, the proposed EB generates the control frames to turn on/off a load or to acquire a measurement from a meter; then, the EB sends these frames to loads and meters via the physical media for the communication of the home automation system, i.e., the typical shielded-twisted pair cable. Since the proposed EB bypasses the HEMS, two significant benefits are achieved. The first advantage is to overcome the obstacles placed by the HEMSs currently available on the market regarding the connection to devices supplied by third parties. Indeed, while HEMS are equipped with USB, RJ45 or RS482 ports for a peer-to-peer connection to EBs, a time-consuming configuration of both of these devices is usually necessary, in absence of any guarantee of obtaining a proper interaction and interoperability. The second advantage is to provide the DR program with the diagnostic, monitoring and control functions. While very important, these functions are not performed by the HEMSs currently available on the market or they are performed with insufficient quality. As a remedy, the proposed EB can be successfully adopted because it is unchained to HEMS and the valuable functions implemented by the EB are not stifled by the limits of the HEMS itself. In particular, the proposed EB uses easy programming languages to enable the expert customer to autonomously run a DR program and implement new functions and procedures that best meet its own needs.
Concerning the management and material requirements also in terms of cost-effectiveness, the two prototypes of the proposed EB were designed and tested in the laboratory; tests were carried out in conjunction with a demonstration panel of a residential unit, equipped with a real home automation system by Schneider Electric. The first prototype has a limited calculation capability and a low-cost (low-EB), the second prototype has a higher cost but also a higher capacity for solving calculation problems (high-EB). The low-EB prototype communicates with the aggregator over the internet to exchange data and submit service requests; in particular, it asks and receives from the aggregator the optimum scheduling of the consumer’s loads. The low-EB prototype applies scheduling without the help of HEMS by sending the on/off commands to the peripherals of the automation system. The high-EB prototype performs the same functions as the low-EB prototype, and in addition, it is capable of calculating optimum scheduling of consumer loads.
This paper is organized as follows.
Section 2 illustrates a home energy management system problem, namely “prosumer problem”; it optimizes the loads scheduling of a customer taking into account the distributed generators, the energy storage systems, the daily fluctuation in electricity prices and loads demand.
Section 3 illustrates the case study of a grid-connected customer with a 3 kW PV plant and a 0.8 kW wind turbine; the customer is also equipped with a 3–6 kWh lithium-ion battery pack. Finally,
Section 4 anticipates the conclusions and illustrates two laboratory prototypes of the proposed EB, namely low-EB and high-EB. The first of two prototypes uses an Arduino MEGA 2560, while the second prototype uses a Raspberry Pi3.
2. The Prosumer Problem
A home energy management system problem, henceforth referred to simply as «prosumer problem» and previously presented by the authors in [
19], is illustrated in this section. The prosumer problem optimizes the operation of domestic appliances taking into account the daily fluctuation in electricity prices, an electric energy storage system of electrochemical cells, the power generated by distributed generators exploiting renewable energy sources (RESs) and by other programmable generators. Nonprogrammable distributed generators exploiting RESs are a photovoltaic (PV) plant and a micro wind turbine (WT); their 24 h production forecast is assumed to be available. In addition, a biomass boiler mounted with a free-piston Stirling engine and a linear electric generator realizes a micro combined heat and power generator (mCHP); this generator provides thermal power in the form of hot water and electric power [
20]. It represents a programmable generator. The electric loads are divided into two groups, group A and group B. Schedulable loads and curtailable loads belong to group A; the lower case letter a is the index over this group. Non-controllable loads belong to group B; and the lower case letter b is the index over this group. As illustrated in
Figure 2, the operating cycle of a non-controllable load is not subject to changes by third parties, therefore, this cycle is an input data for the prosumer problem. On the contrary, the operating cycle of a schedulable load can be entirely shifted in the time interval
, whereas the operating cycle of a curtailable load can be entirely or partially shifted in the time interval
. An optimization problem encapsulates the prosumer problem to return the load scheduling which minimizes the daily electricity cost:
subject to:
Equation (1) is the cost function, which calculates the daily net electricity cost as the difference between the import price multiplied by the imported energy and the export price multiplied by the exported . Equation (2) is the power balance and imposes equality between the generated powers (exported to the grid, supplied by the batteries, produced by distributed generators) and the requested ones (imported from the grid, fed into the batteries, demanded by schedulable loads, demanded by non-controllable loads). are the 24 h power generation forecast for the photovoltaic system, the micro wind turbine and the mCHP, respectively. The binary variable is 1 when the a-th schedulable load is turned ON at the h-th hour, it is zero and vice versa. Similarly, is the load demand of the b-th non-controllable schedulable load at the h-th hour. Equation (3) sets the duration of the operating cycle of each schedulable load, whereas Equations (4) and (5) define the start time of the operating cycle. Equations (6)–(8) ensure that the operating cycle is not divided into sub-cycles for non-curtailable loads. Equation (9) constrains the power flow between the grid and the prosumer at the point of delivery; power flow is upper bounded by the committed power. Equations (10) and (11) constrain the battery charge and discharge power flow. In particular, Equation (10) limits the recharge power up to the batteries’ rated power multiplied by the coefficient m, defined in Equation (14) as the ratio between the recharge current and the discharge current. Equations (12) and (13) calculate the hourly state of charge (SOC) of the batteries, taking into account the state of charge at the beginning of the day, i.e., ESTO. Equation (14) returns the coefficient m as the ratio between the recharge and the discharge battery current; evidently, this coefficient takes into account battery technologies and the ability to charge the batteries with the current m times the discharge one. As an example, m is higher than 1 when Li-ion batteries are used, and m is lower than 1 when lead-acid batteries are used. The input data of the prosumer problem are:
- -
the power forecast for generators, and ;
- -
the hourly electricity prices, and ;
- -
the load profiles of non-controllable loads, ;
- -
the customer’s parameters, and .
4. The Laboratory Prototypes of the Proposed Energy Box
This section presents two laboratory prototypes of the proposed energy box, namely low-EB and high-EB; the cost for each prototype is about 100 € or lower. The first prototype low-EB has a limited computing capacity and an Arduino MEGA 2560 (Arduino Holding, Ivrea, Italy) performs it; the second prototype high-EB has a greater computing capacity and a Raspberry Pi3 (Raspberry Pi Foundation, Cambridge, United Kingdom) performs it. Both prototypes are mounted on a demonstration panel of a residential unit together with a real home automation system. A personal computer and Matlab software (R2010a, Mathworks, Natick, MA, USA, 2010) are used to implement the aggregator.
4.1. The Demonstration Panel of a Residential Unit Togheter with a Real Home Automation System
The front and rear sides of the above-mentioned demonstration panel of a residential unit are shown in
Figure 11; the demonstration panel is connected to the 230 V/50 Hz utility grid and it is equipped with a real home automation system. The front side of the panel shows the plan of the house. Some icons with LED-lights link to appliances, meters, indoor and outdoor lights; when the LED lights are on, the corresponding peripheral is activated. Nine plugs are placed at the bottom left corner; six of these are smart plugs (see label a in
Figure 11) and refer to an equal number of schedulable loads, the remaining three plugs refer to non-controllable loads. The on/off status of smart plugs can be manually set by means of the six smart buttons (see label b in
Figure 11) equipped with a KNX interface device model n. MTN670804 (Schneider Electric, Rueil-Malmaison, France).
The rear side of the panel shows the electrical equipment, thermal-magnetic circuit breakers and the home automation system. At the pressure of a smart button, control frames are generated by the button itself and sent via the shielded twisted pair (STP) cable to a switch actuator (see label c in
Figure 11) model n. REG-K/8×/16×/10 A; the actuator opens or closes the electrical circuit supplying the corresponding plug and load. A smart energy meter (see label d in
Figure 11), model n. REG-k/3 × 230 V, measures the total electrical energy consumption.
Lastly, the label e in
Figure 11 indicates a small case (width 240 mm, length 200 mm, depth 100 mm); both the low-EB and high-EB prototypes are mounted inside that case, as better illustrated in the following subsections.
4.2. The Aggregator
The customer coordinates the integrated community, it communicates to customers via the internet by means of the EBs so as to provide services such as the calculation of the optimal scheduling of customers’ loads. In the laboratory setup, the aggregator is a software, implemented in Matlab and running on a conventional personal computer.
Figure 12 shows the aggregator’s graphic-user-interface (GUI) (see label a); the GUI is a conventional web page that the customer visits to upload his preferences regarding the operation of schedulable loads, i.e., the input parameters
αa and
βa of the prosumer problem. The aggregator solves the prosumer problem and calculates the optimal scheduling;
Figure 12 also shows the Matlab software and the loads scheduling (see label b).
Furthermore, the aggregator receives and stores the energy consumption measurements returned by EBs; these data allow the aggregator to act as intermediary between the community and the distributed system operator. In particular, the aggregator executes the real-time calculation of power imbalances at the community level and implements strategies to provide ancillary services. With this in mind,
Figure 12 (see label c) shows two lines where line d represents the daily forecast of the power flow at the point of delivery of a customer, while the line e represents the actual power flow as returned by the EB of the customer. It is worth noting that in
Figure 12, line e stops at the last EB communication, i.e., at 3 p.m.
4.3. The Low-EB Prototype with Arduino
The prototype of the proposed energy box with a limited computing capacity is named low-EB and it mainly consists of: one liquid crystal display (LCD) with four lines and twenty characters per line, one Arduino Mega 2560, one WiFi shield for Arduino, one micro SD card and one sim Tapko KNX (TAPKO Technologies GmbH, Regensburg, Germany).
Figure 13 illustrates the low-EB when installed into the case of the demonstration panel of
Figure 11. The mission of the low-EB is exclusively to ask the aggregator for the load scheduling, i.e., the prosumer problem solution, and apply the scheduling. More precisely, the low-EB connects to the internet via a local router and synchronizes its internal clock to that provided by the National Institute of Meteorological Research [
25]. Then, the low-EB sends a request to the aggregator for the load scheduling. The aggregator calculates the load scheduling in agreement with the customer’s preferences, i.e., the parameters
αa and
βa that the customer previously uploaded when he visited the aggregator’s GUI (see
Figure 11, label a). The load scheduling is delivered to the low-EB in the form of a non-encrypted text file, as illustrated in
Figure 14.
The text file starts with the reserved word BEGIN; three comments follow (a double slash “//” anticipate each comment). The first comment reports the name of the procedure psol that performed the load scheduling and the date/time when the scheduling has been calculated 26_04_2016_10_41; remaining comments report the sender aggregator and the recipient low-EB. These comments are definitely essential and useful because the low-EB may ask the aggregator for multiple solutions; for instance, the low-EB may ask for “emergency solutions” that is solutions where batteries are out of service or where the customer is suddenly disconnection from the utility grid. Therefore, the low-EB already has a loads scheduling to meet an emergency, pending the aggregator submitting an updated scheduling. Then, the text file reports the loads scheduling in the form of a table with five columns and 24 lines; the first column INTER relates to the daily hours from 1 to 23, while the remaining columns refer to the schedulable electrical loads (i.e., the washing machine WM, the tumble drier TD, the dishwasher DW, the electric vehicle EV). Each row is the hourly scheduling and it defines the state on/off of each schedulable load. For instance, the fourth row INTER = 4 indicates the time interval from 4:00 a.m. to 4:59 a.m.; for this interval the washing machine is off as the scheduling says “-” as well as the tumble drier and the dishwasher. On the contrary, the recharging of the batteries is running because the scheduling says “ON”.
At the beginning of every hour, the low-EB reads the corresponding row of the loads scheduling, it generates a set of control frames for each schedulable load, it converts control frames into analog signals and writes them to serial port pins where the sim Tapko KNX is connected. The sim Tapko, in turn, converts analog signals into control frames using the KNX protocol and writes them on the shielded twisted pair (STP) cable of the home automation system. Lastly, every five seconds the low-EB invokes the smart meter for the power measurement at the point of delivery, every minute it calculates the average value of the last 30 values, every 15 min it sends the last 15 mean values to the aggregator.
4.4. The High-EB Prototype Using Raspberry Pi3
The prototype of the proposed energy box with a higher computing capacity is named high-EB and it mainly consists of: a 7 inches touchscreen, one Raspberry Pi3 and sim Tapko KNX.
Figure 15 illustrates the High-EB when installed into the case of the demonstration panel of
Figure 11. The high-EB performs the same functions performed by the low-EB and, in addition, it is capable to self-calculate the optimal scheduling of consumer’s loads. At this scope, the high-EB facilitates the customer in indicating their preferences,
αa and
βa, because the aggregator’s GUI (see
Figure 12 label a) now locally runs on the Apache web server application installed on the Raspberry Pi3 (see
Figure 15 label a). The high-EB communicates with the aggregator and asks for services such as the hourly electricity prices and the hourly PV-wind generation forecast for the customer’s site. The high-EB uses the customer’s preferences, prices and forecasts to calculate the optimal loads scheduling; the high-EB hourly generates and writes control frames on the STP cable using the sim Tapko KNX in order to apply the loads scheduling.
As well as the low-EB, every five seconds the high-EB carries out a reconnaissance on the system’s power consumption; in particular, it invokes the smart meter for the power measurement at the point of delivery and every 15 min it sends the last 15 mean values to the aggregator.
In order to allow the high-EB to self-calculate the loads scheduling, we programmed the prosumer problem into the Raspberry Pi3 using the development environment named Eclipse for Java programming. In order to solve the prosumer problem, we used the IBM ILOG CPLEX Optimization Studio solver (CPLEX); such a solver uses the simplex method, it runs on Linux (i.e., the Raspberry Pi3 operative system) and it solves the prosumer problem within 10–15 s.
5. Conclusions
This paper proposed an energy box (EB) as a viable solution to the challenge of the communication between a consumer and an aggregator; indeed, the proposed EB communicates with the aggregator’s IT platform and requires access to an application, service or system. For instance, the proposed EB uploads the user’s preferences to obtain optimal loads scheduling and savings on the electricity bill. Furthermore, the proposed EB uploads power/voltage/current measurements to obtain reports and statistics. The proposed EB is also a viable solution to the challenge of the interaction between an EB and home energy management systems (HEMSs); indeed, the proposed EB overcomes the problem of interaction because it directly communicates with all peripherals of the home automation system, bypassing the HEMS. In particular, the proposed EB self-generates the control frames to turn on/off a load or to acquire a measurement from a smart meter; then, the EB sends these frames to loads and smart meters via the physical media for the communication of the home automation system.
The paper also illustrated two prototypes of the proposed EB to have a clear overview of management and material requirements, as well as of cost-effectiveness; both prototypes were tested in the laboratory using a real home automation system. The two prototypes are relevantly cost-effective and effectively serve prosumers and prosumages in autonomous demand response program in cloud-based architectures. The first prototype has a limited calculation capability and a very low cost (low-EB), the second prototype has a higher cost but also a higher capacity for solving calculation problems (high-EB). The low-EB communicates with the aggregator over the internet to exchange data and submit service requests; in particular, the low-EB asks and receives the optimal scheduling of the consumer’s loads from the aggregator. The low-EB applies the load scheduling by sending the on/off commands directly to the peripherals of the home automation system, bypassing the HEMS. The high-EB performs the same functions as the low-EB and, in addition, it is capable to self-calculate the optimal scheduling of the consumer’s loads. The low-EB uses on an Arduino MEGA 2560, whereas the high-EB uses a Raspberry Pi3.
Future work and research will focus on the relationship between the goals at the aggregator’s level and the preferences at the customers’ level; at this scope, many field measurements are necessary. With this in mind, we are already involved in a project on power cloud and distributed energy storage systems; we plan to build a certain number of EBs and give them to real customers. In this way, an appropriate quantity of data, information and measurements will be available to evaluate the relationship between goals at the aggregator’s and customer’s levels.