Towards the Real-World Deployment of a Smart Home EMS: A DP Implementation on the Raspberry Pi

Abstract

As the adoption of distributed generation and energy storage grows and the attention to energy efficiency rises, Energy Management is assuming a growing importance in smart homes. Energy Management Systems (EMSs) should be easily deployable on smart homes and seamlessly integrate with the Internet of Things (IoT) ecosystem, including generators and storage devices. This paper redesigns a previously presented EMS to reduce its computational complexity, implement it on a Raspberry Pi, and make it compatible with the IoT paradigm. The EMS manages the power flows between smart home loads, renewable generators, electrical storage, and power grid. It communicates with a network of wireless sensors for electrical appliances and with a cloud-based utility data aggregator. The EMS uses Artificial Intelligence and a Dynamic Programming algorithm to fulfill two objectives at the same time: lowering the end user’s electricity bill and reducing the uncertainty on the power exchanged between the end user and the grid manager. The latter goal is obtained by an effective compensation of forecasting errors. A test bench emulating four smart homes was used to measure the effectiveness of the EMS and the efficiency of the proposed implementation. The results show an uncertainty of the aggregated exchanged power of only 2.88% and a reduction of the electrical bill for end-users of up to 3.23%. Furthermore, the EMS can complete its most onerous task in less than 9 min. The good performance of the proposed EMS makes it a candidate for fast adoption by the market.

1. Introduction

The increasing use of distributed renewable energy sources (RES) is one of the primary steps towards the global transition to the smart grid paradigm [1,2]. On the other hand, uncertainties and intermittency of RES result in unpredictable electricity generation profiles having an impact on power system balance and stability [3]. There are many technological and economic issues associated with high rates of renewables penetration in the electrical grid; in particular, daily and seasonal fluctuations in energy production and load demand profiles, high cost of energy storage, and the delicate balance between grid reliability and flexibility are among the most troubling aspects [4,5].

To deal with such issues, suitable Energy Management Systems (EMSs) have been discussed in the technical literature [6,7,8]. The key functions of EMSs are monitoring and optimization of power flows. These systems, at the end-user level, allow customers to play an active role in the energy market. On the other hand, they provide support to the grid operator in terms of optimized decisions, for example implementing Demand Side Management schemes [9,10].

Along with the industrial and commercial sectors, EMSs are also advantageous in the context of smart homes, where different kinds of system components (i.e., hardware elements, software algorithms, network connections, and sensors) cooperate with each other to provide various services supporting human lifestyle [11]. An EMS should exhibit distinct features to be engaging for end users. Besides providing a commodity and an advantage, it should seamlessly integrate with the ecosystem of home devices and appliances, it should require an effortless setup and a small amount of wiring, and it should not be bulky. Therefore, besides the research on the functional aspects of EMSs (e.g., how they are defined, what they optimize, and which strategy they use), for their real-world adoption, it is important to investigate how to perform their embedded implementation and to integrate them into a smart home more easily. To this aim, the Internet of Things (IoT) paradigm is currently the favored solution.

However, most works on EMSs disregard these aspects and focus solely on the implementation of support technologies (e.g., networking, smart metering, controllable devices and appliances), or architectural aspects. In fact, networking technologies such as Home Area Networks (HAN) or Personal Area Networks (PAN) are extensively studied to enable the implementation of EMSs [12,13]. Furthermore, some authors focus on the implementation of smart devices that support the interaction with an EMS. For example, the embedded implementation of network-enabled Battery Management System (BMS) is presented in [14]. Instead, Ozadowicz and Grela [15] proposed a smart meter that uses the IoT paradigm to provide a universal device interface. Other examples of IoT system prototypes have been proposed in the technical literature for home automation and energy monitoring inside the smart home/building [16,17,18].

Several works propose architectural approaches for the smart integration of appliances, devices, and energy management facilities. For example, Khamphanchai et al. [19] proposed a platform for energy management of buildings that is based on distributed agents. Furthermore, architectures based on the IoT paradigm are presented in [20,21]. A cloud-based architecture that permits data collection, control of appliances, and the definition of EMSs as cloud-based services is presented in [22]. Following a similar approach, Al Faruque and Vatanparvar [23] and Yaghmaee Moghaddam and Leon-Garcia [24] proposed architectures based on fog computing [25]. In particular, Al Faruque and Vatanparvar [23] proposed the concept of energy management as a service.

Few works have proposed embedded implementations of EMSs. The authors of [26] implemented an optimization algorithm on embedded devices but did not describe the details of the algorithm. Other works implemented just rule-based EMSs or short-term controllers. For example, some works implemented very simple on/off appliance switching functionalities based either on the hour of the day and the presence of users [27] or on a user-selected power consumption limit [28]. In other works, more complex EMSs are proposed. However, only the rule-based short-term layer of the EMS are implemented on microcontrollers, whereas the medium- and long-term layers run on a centralized outside-of-the-house controller [29] or a dedicated PC [30]. A more sophisticated approach is presented in [31,32], which implement EMSs on microcontrollers to perform load-shifting. These EMSs, however, do not use optimization techniques but a set of preprogrammed rules (fuzzy or deterministic). Although this choice simplifies the implementation, the obtained results are suboptimal in the medium/long term. To the authors’ knowledge, the literature misses a detailed description of an embedded EMS implementation that optimizes power flows among renewable generators, loads, and storage systems.

To provide a further step towards the real-world deployment of EMSs, this paper presents an embedded implementation and an extended validation of the EMS proposed in [33]. This EMS is very promising because it provides advantages for both the end user and the utility. In fact, it applies optimization algorithms: (1) to obtain a reduction of the end user’s electricity bill; and (2) to reduce the uncertainty, due to forecasting errors, on the daily profile of the power exchanged between the user and the public utility. The EMS is designed to preserve user habits and to require little communication with the grid manager. These are some of the key requirements for the domestic adoption of an EMS. However, another important requirement is the easy connection to home appliances and to the grid manager. To this aim, it is advantageous to implement the EMS as an IoT device (rather than as a software module of the smart meter) that connects wirelessly to the appliances’ sensors and actuators and exposes its services to the grid manager and the user [34].

For the above reasons, the EMS proposed in [33] is particularly suitable for the smart home context. Therefore, the main aim of the present paper is the embedded implementation of such an EMS in order to make it compatible with the IoT paradigm. To this aim, the EMS must be redesigned guaranteeing a feasible implementation and the optimality of the results. Specifically, Di Piazza et al. [33] used Mixed Integer Linear Programming (MILP) and exhibited software dependencies from third-party solvers, which are currently unavailable for embedded platforms; thus, MILP should be replaced with other techniques that do not impose such dependencies.

In general, other authors use heuristic algorithms such as Particle Swarm Optimization to implement EMSs [35,36]. These algorithms are quite simple and do not depend on third-party solvers, thus they satisfy the feasibility requirement. However, these authors only perform simulations and do not make an embedded implementation. In any case, heuristics-based algorithms can get stuck in local optima and do not always return the global optimum; therefore, they do not ensure the optimality of the results.

Based on such considerations, in this paper, the algorithm of Di Piazza et al. [33] is completely re-implemented using Dynamic Programming (DP) instead of MILP. The EMS is implemented and tested on a Raspberry Pi board [37], but can also run on any other Linux-based embedded platform. Its experimental validation was performed connecting it to a network of wireless sensors and actuators based on Wemos boards [38]. The differences between this paper and the work in [33] can be summarized as follows:

• DP is used instead of MILP for the previously explained reasons.
• Instead of considering only one dwelling, the EMS performance was evaluated considering a small grid of four smart homes; this aimed at measuring the increased advantage from the point of view of the utility when several users adopt the EMS.
• The EMS performance was also assessed experimentally by connecting it to a network of wireless sensors according to the IoT paradigm.

The goal of the investigation was twofold: (1) evaluating the theoretical and measured computational efficiency, showing the real-world feasibility of the implemented EMS; and (2) measuring the effectiveness of the EMS for both the utility and the users during a 30-day period.

The paper is organized as follows. The fundamentals of the chosen EMS are highlighted in Section 2, and the case study is described in Section 3. Section 4 is focused on the embedded implementation of the EMS. After describing the chosen embedded platform and the test bench, Section 5 presents and discusses the experimental results. Finally, some conclusions are drawn.

2. Fundamentals of the Chosen EMS

The chosen EMS has been presented in [33]; for the sake of brevity, only the main features and the optimization problems are recalled in the following.

2.1. Main Features

The flowchart of the chosen EMS is shown in Figure 1. As for many EMSs, the processing starts with the Forecasting stage, in which the 24-h ahead profiles of load demand and environmental variables tied to renewable generation are forecast on the basis of past data. To achieve good results, the Forecasting stage of the chosen EMS is based on the Nonlinear AutoRegressive network with eXogenous inputs (NARX). This Artificial Neural Network (ANN) has been successfully used in time-series modeling thanks to its simple implementation and its adaptive learning process, even with small-scale data [39,40,41]. In the considered case, the exogenous input is the environmental temperature.

The subsequent optimization stage considers forecast load demand and plans to satisfy it while pursuing the chosen goals. This stage is split into two tasks, i.e., Planning and Online Replanning, aiming to provide advantages both to the end user and to the grid manager at the same time.

The Planning task optimizes the user’s cash flow (CF) over the planned period (24 h) and produces a set of power reference values, one for each system component (i.e., electrical loads, storage systems, and renewable generators). In other EMSs, this set is directly sent to lower level devices that perform the instantaneous control of the hardware. This approach, therefore, neglects forecasting errors. Instead, in the chosen EMS, the output of the Planning task is only used to compute the optimal Grid-Exchanged Power Profile (GEPP) for the whole next day. The GEPP is a vector of power values across the time steps of a day. In particular, these values are positive when the grid supplies the smart house, or negative when the power from renewable generators is injected into the grid. The planned GEPP is transmitted over the Internet to the grid manager as an obligation, to which the user commits himself.

Then, the Online Replanning task is repeated during each 24 h cycle. It aims at minimizing the deviation between the actual and the transmitted GEPPs and computes the actual set of power references to obtain this goal. These values are delivered to the different system components by the Local Command stage via an internal HAN. Besides minimizing the user’s cash flow, the proposed EMS reduces the uncertainty on the GEPP thanks to its Online Replanning stage. The public utility can exploit this last feature to optimize power generation/distribution and to improve its economic policy planning.

2.2. Optimization Problems

Both Planning and Online Replanning tasks are executed solving optimization problems. The considered variables are the battery state of charge (SOC) and the power flows between couples of system devices: loads, renewable generators, battery storage systems, and connection to the public grid.

In the optimization problem of the Planning stage, the objective function is the end user’s cash flow ($CF$), which is expressed as:

$$\begin{array}{c}{f}_{obj}\left(\mathit{x}\right)=\sum _{t=1}^{N}C{F}_t\hfill \end{array}$$

(1)

$$C{F}_t=\left\{\begin{array}{c}GEP{P}_t\Delta t{C}_{buy}\mathrm{if}GEP{P}_t\ge 0\hfill \\ GEP{P}_t\Delta t{C}_{sell}\mathrm{otherwise}\hfill \end{array}\right.$$

(2)

where $C_{sell}$ and $C_{buy}$ are the prices of sold/purchased energy, respectively; $\Delta t$ is the duration of each time step; t is a discrete variable representing the time step index; and N is the number of time steps in a day.

The objective function in Equation (1) must be minimized satisfying a set of physical and design constraints at each time step, namely:

• non-negative value for each variable;
• power balance at generation node;
• power balance at load node;
• maximum contractual grid-exchanged power;
• maximum battery charging/discharging power;
• minimum and maximum SOC values;
• continuity of SOC between consecutive days;
• evolution of SOC between time steps; and
• cyclicity of SOC profile between consecutive days.

The optimization problem of the Online Replanning stage aims at finding the solution that minimizes the maximum deviation between the actual GEPP and the self-committed GEPP ($\breve{\gamma }$). Such a deviation is due to forecasting errors. Hence, the objective function to minimize is:

$$f_{obj}\left(\mathit{x}\right)=\underset{i\le t\le N}{max}|{\breve{\gamma }}_t-GEP{P}_t|$$

(3)

To avoid greedy minimization of instantaneous differences, at each execution, the algorithm decides the variable values for the current time step $t=i$ (using measurements) and also for the following steps $t\le N$ (using forecast values). However, only the reference power values for the current time step ($t=i$) are sent to the hardware, whereas the other values (for $t>i$) are discarded.

The constraints for Equation (3) are readily adapted from those of the Planning stage by:

• changing the time intervals on which the constraints are defined; and
• splitting power balance constraints to account for measured values (at $t=i$) and for forecast values (at $t>i$).

3. The Case Study

The proposed technique was illustrated and validated referring to a small electrical grid that encompasses four networked dwellings. Each smart home was equipped with an EMS of the proposed type, which generated in real time the references for the power flows among the system components: loads, renewable generators, and battery storage systems. Furthermore, a series of previously devised wireless sensors [38] was connected to the electric appliances to send measured data to the EMS and to forward the power references set by the EMS to the power electronic converters that interface system components. The wireless sensors communicated using Message Queue Telemetry Transport (MQTT), a lightweight messaging protocol for the IoT based on the publish-subscribe paradigm. A pictorial view of each smart home is shown in Figure 2.

The four users (A÷D) had different habits, hence different load profiles. The main parameters of the system under study are shown in

Table 1. System parameters.

User	Parameter	Value	Description
all	$C_{buy}$	0.0921 ($/kWh)	price of purchased energy
all	$C_{sell}$	0.0765 ($/kWh)	price of sold energy
all	$V_n$	200 (V)	battery nominal voltage
all	$\eta$	0.95	battery efficiency
all	$SO{C}_{min}$	20%	lower bound for battery SOC
all	$SO{C}_{max}$	100%	upper bound for battery SOC
all	$SO{C}_{start}$	80%	initial value of battery SOC
A, C	$P_{xg}$	3 (kW)	maximum grid contractual power
B, D	$P_{xg}$	4 (kW)	maximum grid contractual power
A, B	$P_{xp}$	3 (kW)	maximum power of the PV generator
C	$P_{xw}$	3 (kW)	maximum power of the $\mu$WECS
D	$P_{xw}$	1.5 (kW)	maximum power of the $\mu$WECS
A, C	$C_b$	4.6 (kWh)	battery capacity
B	$C_b$	3.8 (kWh)	battery capacity
D	$C_b$	2.3 (kWh)	battery capacity
A, C	$P_{xb}$	1.5 (kW)	maximum battery charge/discharge power
B	$P_{xb}$	1.24 (kW)	maximum battery charge/discharge power
D	$P_{xb}$	0.75 (kW)	maximum battery charge/discharge power

, and the following working assumptions were made:

• The aggregated load profile is considered as an input; if needed, a lower-level control system can shift or schedule each load, while respecting the aggregated load profile.
• The maximum contractual power for Users A and C is 3 kW, whereas for Users B and D it is 4 kW.
• Each user has only one renewable generator; in particular, Users A and B have PV generators, whereas Users C and D have micro Wind Energy Conversion Systems ($\mu$WECSs).
• The renewable generators are always operated in the maximum power point for each environmental condition (wind speed, solar irradiance, and temperature) since they are usually equipped with maximum power point trackers (MPPT).
• Transferring power from the battery to the grid is not allowed by the utility, according to the technical rule for grid-connection in force in some European countries at the time of writing.
• The battery must be small and affordable for the end user, thus it is not suitable to sustain hours-long islanding; the considered capacity values for each user are given in Table 1.

Such working assumptions did not affect the general validity of the proposed EMS. With regard to Points 1 and 4, even if slight deviations occurred (e.g., the lower-level control system does not precisely respect the aggregated load profile or the renewable generator does not work exactly in its maximum power point), they were seen as forecasting errors. Hence, using the battery as an energy buffer, they were effectively corrected by the Online Replanning stage of the EMS, as happens for errors due to unexpected weather fluctuations [42]. As for Point 3, in the presence of more than one renewable generator, their power profiles could be aggregated following the same approach used for loads. However, this scenario is highly unusual in the smart home context because it would be very expensive. Finally, with regard to Point 6, the influence of battery size on the EMS performance has been already studied in [42], where a sensitivity analysis has been performed.

To send the self-committed GEPP once a day, each of the four smart homes was connected to the data aggregator of the grid manager through a secure Internet connection [13]. The data aggregator received and aggregated the user-committed GEPPs; the resulting profile could be exploited by the utility to improve its policy planning.

4. Embedded Implementation of the Chosen EMS

An effort was made to keep a low computational cost of the algorithm without sacrificing the optimality of the solution. The following subsections describe the details of the implementation. The algorithm was coded in C++ language. Since the chosen platform for the embedded implementation is a Raspberry Pi, as shown in Section 5, the code was compiled using Linaro GNU cross-toolchain armv8l-linux-gnueabihf version 7.2.

4.1. Dynamic Programming Algorithm

The Planning and Online Replanning problems of the chosen EMS were initially formulated and solved as MILP problems in [33]. However, in the present work, they have been reformulated using Dynamic Programming (DP) to remove software dependencies from third-party solvers and to simplify the overall implementation process. The algorithm for solving these problems has been designed following the approach presented in [43]. In particular, the state of the system corresponds to the battery SOC, which must be discretized using a suitable step size.

The Planning stage problem can be formulated as a DP problem if it is framed as the problem of choosing the optimal policy that reaches the best final state from an initial state in a limited time horizon. At each time step and state, the system can choose among a set of actions, i.e., the power reference values for the battery. This choice results in a state transition from a discretized SOC value to another. The Planning stage problem, therefore, consists in finding the best path from the initial state to a final state. From Equation (2) it is possible to obtain the cost of each action, i.e., the cost of a state transition. In fact, from a given power reference for the battery, the corresponding power exchanged with the grid (and thus the CF) can be obtained through power balance constraints. Furthermore, the optimization problem constraints define the admissibility of an action.

The problem, as just described, can be represented using a graph such as that in Figure 3. Graph vertices represent system states arranged in vertical layers according to the time step; edges account for the cost of the action that corresponds to the state transition between the states they link. An edge exists only if the corresponding state transition satisfies the constraints of the problem. Such a graph is generated as described in Algorithm 1. With reference to this graph, the best policy corresponds to the choice of the shortest path from the initial state to one of the vertices associated with the last time step of the planning period. Considering that edges can have negative values (negative CF corresponds to power sold to the utility), the shortest path problem can be solved using Bellman–Ford algorithm [44]. This algorithm computes the shortest paths from a single source vertex (the initial SOC) to all the other vertices in the graph. Then, among the vertices corresponding to the last time step of the planning period, the system chooses the vertex with the shortest path as the target state. In addition, it is worth pointing out that the check for negative cycles in Bellman–Ford algorithm can be skipped since the graph never contains cycles. The pseudo-code of the Planning algorithm is shown in Algorithm 2.

The computed optimal path represents the sequence of actions that the system plans, i.e., the profile of power reference values for the battery. From this profile, the Planning stage calculates the planned GEPP and finally transmits it to the utility.

Algorithm 1 Pseudo-code of graph building function. It builds a graph such as the one in Figure 3.

1: functionbuildGraph($t_0,genForecast,loadForecast,soc,currGen,currDemand$) 2:     $G(V,E)\leftarrow \left\{\right\}$                             ▹ Create empty graph 3:     $v_0\leftarrow createVertex(soc,t_0)$                    ▹ vertex for the initial SOC 4:     $addVertex(G,v_0)$ 5:     for $t\leftarrow t_0+1$, $N+1$ do            ▹ repeats for N time steps starting from the second 6:           for $next\_soc\_val$ in $discrete\_soc\_values$ do ▹ repeats for all the discretized values of SOC 7:              $v\leftarrow createVertex(next\_soc\_val,t)$ 8:              $addVertex(G,v)$ 9:              for $prev\_v$ in $getTimeStepNodes(t-1)$ do      ▹ repeats for all the vertices of $t-1$ 10:                  ${\Delta }_{soc}\leftarrow next\_soc\_val-getSoc(prev\_v)$       ▹ calculates difference of SOC 11:                  $pBatt\leftarrow batteryModel\left({\Delta }_{soc}\right)$               ▹ and corresponding power 12:                  if $t==t_0+1 \& replanning$ then 13:                         $pGrid\leftarrow pBatt+currDemand-currGen$ 14:                  else 15:                         $pGrid\leftarrow pBatt+loadForecast[t-1]-genForecast[t-1]$ 16:                  if $checkConstraints(pBatt,pGrid)$ then        ▹ if all constraints are satisfied 17:                                ▹ calculates weight and adds edge 18:                      if $planning$ then 19:                           $w\leftarrow calcCashFlow\left(pGrid\right)$ 20:                      else 21:                           $w\leftarrow abs(pGrid-plannedGepp[t-1\left]\right)$ 22:                      $addEdge\left(\right(prev\_v,v),w)$ 23:     return $G(V,E),v_0$

Algorithm 2 Pseudo-code of the Planning algorithm.

1: $t_0\leftarrow 0$ 2: $(genForecast,loadForecast)\leftarrow getForecasts\left(\right)$ 3: $init\_soc\leftarrow getInitSoc\left(\right)$                  ▹ retrieves SOC measurement at $t_0$ 4: $G(V,E),v_0\leftarrow$buildGraph( $t_0,genForecast,$$loadForecast,init\_soc,NULL,NULL$) 5: $(distances,predecessors)\leftarrow bellmanFordAlg(v_0,G)$ ▹ shortest paths from $v_0$ to all other vertices 6: $final\_states\leftarrow getTimeStepNodes(N+1)$        ▹ retrieves vertices of final time step 7: $target\leftarrow \mathrm{argmin}distances\left(x\right)\mathrm{for}x\in final\_states$ 8: $path\leftarrow getPath(predecessors,target)$          ▹ reconstructs path from $V_0$ to $target$ 9: $pBattProfile\leftarrow calcPBattProfile\left(path\right)$   ▹ calculates power corresponding to SOC sequence 10: $gepp\leftarrow pBattProfile+loadForecast-genForecast$ 11: sendGeppToUtility($gepp$)                ▹ sends the GEPP to the data aggregator

Algorithm 3 Pseudo-code of the Online Replanning algorithm.

1: $t_0\leftarrow currenttimestep$ 2: $plannedGepp\leftarrow readPlannedGepp\left(\right)$                 ▹ retrieves committed GEPP 3: $(genForecast,loadForecast)\leftarrow getForecasts\left(\right)$ 4: $curr\_soc\leftarrow readCurrSoc\left(\right)$ 5: $currGeneration,currLoadDemand\leftarrow readMeasures\left(\right)$ 6: $G(V,E),v_0\leftarrow$buildGraph($t_0,genForecast,$$loadForecast,curr\_soc,$$currGeneration,currLoadDemand$) 7: $(distances,predecessors)\leftarrow findMinMaxPaths(v_0,G)$▹ minmax paths from $v_0$ to all other vertices 8: $final\_states\leftarrow getTimeStepNodes(N+1)$         ▹ retrieves vertices of final time step 9: $target\leftarrow \mathrm{argmin}distances\left(x\right)\mathrm{for}x\in final\_states$ 10: $path\leftarrow getPath(predecessors,target)$       ▹ reconstructs path from target to $init\_soc$ 11: $pBattProfile\leftarrow calcPBattProfile\left(path\right)$   ▹ calculates power corresponding to SOC sequence 12: sendProfileToLocalCommand()              ▹ sends battery profile to local command

The same approach can be used to formulate the Online Replanning stage as a DP problem. Algorithm 3 reports the pseudo-code of the algorithm. Each time the Online Replanning task is executed, a new graph is built. However, the objective function in Equation (3) cannot be expressed as a sum of state transition costs. Thus, the problem cannot be formulated as a shortest path problem. Instead, the cost of each state transition, i.e., the weight of the edges of the graph, corresponds to the deviation of the planned GEPP from the GEPP that results from the state transition. Therefore, the cost of a path is the maximum weight of the edges composing it. The problem corresponds to the single source minmax path search problem. This is the dual of the single source bottleneck path problem [45], and it can be solved executing a modified version of Dijkstra’s algorithm [46]. After this execution, the target node and the best path are chosen as in the Planning stage.

From the obtained optimal path, at each execution of the Online Replanning task, only the first edge is used to compute the power reference values to be sent to hardware devices.

4.2. Computational Complexity Analysis

The computational complexity of the optimization stage depends on two variables. The first is the number of time steps in a day (N); and the second is the coarseness of the SOC variable discretization, i.e., the number of possible discrete SOC values (M), which allows computing the SOC discretization step as $\Delta SOC=M^{-1}·100\%$. The worst-case complexity of the Planning algorithm is $O\left(N^2{M}^3\right)$. On the other hand, the worst-case complexity of the Online Replanning algorithm is $O(N{M}^2+NMlogNM)$. As such, it is lower than the complexity of the Planning algorithm.

4.3. NARX ANNs

The NARX ANNs that forecast the 24-h ahead profiles of load demand and environmental variables were implemented using Matlab/Simulink R2014b with Neural Network Toolbox. Then, C/C++ code was generated taking advantage of Matlab Coder. Finally, the obtained code was further optimized and compiled with Linaro GNU cross-toolchain armv8l-linux-gnueabihf version 7.2.

5. Experimental Verification and Results

A dedicated test bench was set up to validate the embedded implementation of the chosen EMS under the hypothesis of controlling four smart homes of the type described in Section 3. Such a test bench is described in detail in the following subsection.

The input data came from publicly available datasets. Outdoor temperature, solar irradiance, and wind speed data came from the U.S. National Solar Radiation Database [47], whereas load demand data came from [48]. Prices for sold and purchased energy were retrieved from [49]. The data considered for the study referred to the city of Amarillo TX, USA. Given each dataset, a first part of the data was used to train and validate the related ANN. The remaining part was considered as the set of instantaneous measurements to be compared with the forecast profile.

The electrical behavior of the appliances of each smart home was emulated by the related wireless sensors, as explained in the following subsection. This approach was followed because the main aim of the work was to assess whether the EMS can run on the embedded platform, perform its computation within the required time frame, and exchange data with the wireless sensors.

5.1. Test Bench Description

Four EMSs of the proposed type were implemented on four Raspberry Pi 3 model B boards running the Linux operating system. This embedded platform was based on a quad-core Broadcom BCM2837 64-bit CPU clocked at 1.2 GHz and has 1 GB of RAM. Furthermore, it provides an onboard WiFi connection, a gigabit Ethernet port, and a Micro SD port to boot the Linux operating system [37]. As an alternative, the proposed EMS could be easily executed on other Linux-based embedded platforms such as the Zedboard [50] by just recompiling the same source code.

The wireless sensors used in the test bench have been previously devised in [38] and are based on Wemos D1 mini pro boards. These boards encompass an ESP8266 system-on-chip by Espressif Systems, which includes a low-cost IEEE 802.11b/g/n Wi-Fi chip with full TCP/IP support and a 32-bit RISC L106 microcontroller. For their use in the field, such devices are appropriately interfaced with physical sensors to acquire the variables of interest (e.g., voltage and current of each appliance, solar irradiance, wind speed, and outdoor temperature). At the same time, they send the appropriate power reference to each power electronic converter, and they read the instantaneous battery SOC. For the present work, instead, such wireless sensors were modified to bypass the physical sensors and to emulate the electrical equipment to which they were connected. In particular, the power profiles of renewable generators and electrical loads were computed on the basis of the considered public datasets. As for the storage system, instead, a simple static battery model was implemented; it is expressed by Equation (4), and it takes into account battery power reference ($P_{batt,ref}$) and charge/discharge efficiency ($\eta$) to compute SOC variation. On the other hand, the grid manager’s data aggregator was emulated using a desktop PC connected to the Internet and running a small server application written on purpose.

$$SO{C}_{t+1}-SO{C}_t=\left\{\begin{array}{c}\eta \frac{\Delta t}{C_b}{P}_{batt,ref}\mathrm{if}{P}_{batt,ref}\ge 0\hfill \\ \frac{\Delta t}{\eta C_b}{P}_{batt,ref}\mathrm{otherwise}\hfill \end{array}\right.$$

(4)

The synopsis of the experimental setup is shown in Figure 4, and its operation is briefly explained in the following. At the beginning of each considered day, each EMS read the instantaneous measurements of load demand, solar irradiance, and wind speed sent from the wireless sensors. Using these data, it performed the forecasting of renewable generation and load profiles thanks to the NARX ANNs. It executed the Planning task to compute the self-committed GEPP and sent it to the emulated grid manager’s data aggregator using the Internet connection of the Raspberry Pi. Then, it started performing the Online Replanning task obtaining power references to control the plant accordingly. In particular, at each time step, it read the current values from the wireless sensors, solved the optimization problem, and sent the power references for the electrical appliances. Given the working assumptions of Section 3, the battery was the only controllable device in each of the four plants. Hence, each EMS sent the battery power reference to the wireless sensor that emulated the battery power flow and updated the SOC. Then, these two quantities were plotted, as shown in Section 5.3. Concurrently, the emulated grid manager’s data aggregator performed the following operations:

• It listened to the messages with which each EMS sent its self-committed GEPP 24 h ahead via a secure Internet connection.
• It retrieved the measured power exchanged by the grid and each user via the network of wireless sensors.
• It compared each user-committed GEPP with the corresponding actual GEPP.
• It computed the error metrics on each user’s GEPP, which are shown in Section 5.3.
• It computed each user’s cash flow starting from the GEPP.
• It compared the aggregated actual GEPP with the aggregated user-committed GEPPs. The two power profiles were then plotted, as shown in Section 5.3.

5.2. Assessment of EMS Execution Time

The execution time of the Planning and Online Replanning tasks on the chosen embedded platform was measured in four scenarios to consider different sets of EMS parameters. In particular, two values of the SOC discretization step (i.e., 0.2% and 0.5%) and two values of the time step duration (i.e., 15 and 30 min) were considered.

The experimental results of such an analysis are shown in

Table 2. Execution time of the Planning task.

		$\mathbf{\Delta }\mathit{t}$
		15 min	30 min
$\Delta SOC$	0.2%	1177.3 s	512.9 s
	0.5%	98.6 s	40.3 s

and

Table 3. Execution time of the Online Replanning task (First Step).

		$\mathbf{\Delta }\mathit{t}$
		15 min	30 min
$\Delta SOC$	0.2%	2249 ms	1703 ms
	0.5%	292 ms	211 ms

, and they confirm that Planning is the most computationally intensive operation, as demonstrated in Section 4.2. The EMS must start and complete the execution of such a task during the last time step of the day. Therefore, its execution time must be smaller than $\Delta t$ (i.e., 900 or 1800 s). Table 2 shows that the execution time of the Planning task is well below the allowed time frame for the two scenarios with $\Delta t$ = 30 min. On the other hand, a SOC discretization step of 0.2% cannot be chosen if the user also wants to set the time step to 15 min.

As for the Online Replanning task, it has a significantly lower computational complexity. Furthermore, the related execution time decreases during the day. In fact, the number of remaining time steps gets smaller at each execution, and the graph becomes progressively less complex. Therefore, the first time step has the longest execution time of the Online Replanning task. As Table 3 shows, the execution of such a task took no more than 2.5 s in all considered scenarios.

On the basis of the results shown in Table 2 and Table 3, it is worth estimating whether older Raspberry Pi models are suitable platforms to run the proposed embedded EMS. The constraint to be satisfied is that both Planning and Online Replanning tasks should be executed during the last time step of the day. As an example, the scenario with $\Delta SOC$ = 0.2% and $\Delta t$ = 30 min was considered. Therefore, the maximum execution time must not exceed 1800 s. The performance degradation index (PDI) due to the use of older Raspberry Pi platforms could be estimated on the basis of benchmark indices such as single-core Million Instructions Per Second (MIPS) and Mega FLoating point Operations Per Second (MFLOPS) values; such indices were retrieved from [51] and are summarized in

Table 4. Estimated performance comparison of different Raspberry Pi models.

Model	CPU	Clock freq.	MIPS	MFLOPS	PDI	exec. Time
Raspberry Pi 3 B	A53	1.2 GHz	2201	176	-	515 s (meas.)
Raspberry Pi 2 B	A7	900 MHz	1538	120	1.47	757 s (est.)
Raspberry Pi 1 B	ARM11	700 MHz	847	42	4.19	2158 s (est.)
Raspberry Pi Zero	ARM11	1 GHz	1226	68	2.59	1334 s (est.)

. The performance of Raspberry Pi 3 model B was compared with that of the other models by computing the MIPS ratio and the MFLOPS ratio. For a more conservative estimation, the PDI was computed as the maximum of such ratios. Then, the execution time of the proposed embedded EMS on each Raspberry Pi platform was estimated by multiplying the PDI by the execution time measured on the Raspberry Pi 3 model B. As Table 4 shows, the proposed embedded EMS can be executed in all the considered platforms except for the Raspberry Pi 1 model B. Using the same approach, the comparison could be easily extended to the combination of other scenarios and other low-cost embedded platforms for IoT applications [52].

5.3. Assessment of the EMS Effectiveness

The above described experimental setup was used to assess the effectiveness of the implemented EMS in the scenario with $\Delta t$ = 30 min and $\Delta SOC$ = 0.5%. In fact, slightly better results could be obtained in the other scenarios. At the functional level, the performed tests showed that the EMS correctly interacted with the wireless sensors and the grid manager’s data aggregator. To assess the EMS effectiveness, the uncertainty of the output profile (i.e., the GEPP) must be compared with that of the input profiles (i.e., renewable generation and load demand), and the cash flow variation must be evaluated. The input data for emulating the electric appliances span thirty consecutive days and came from the aforementioned publicly available datasets. As an example, Figure 5a,b shows the comparison between the forecast profiles and the actual input data for the EMSs of Users B and C for the first three days. These plots are also representative of the other two user profiles.

Two metrics were computed for the forecasting errors, namely the Normalized Root Mean Square Error (NRMSE) and the Normalized Maximum Absolute Error (NMAE). It is worth noting that the error metrics of PV and wind generation were normalized with respect to the nominal power of each renewable generator. On the other hand, error metrics on load demand were normalized with respect to the maximum contractual power. The values of the forecasting error metrics for all users during the 30 days are shown in

Table 5. Error metrics on input profiles.

		User A	User B	User C	User D
generation	nrmse	0.0610	0.0620	0.0843	0.0855
	nmae	0.5014	0.4796	0.4163	0.4253
load	nrmse	0.0351	0.0576	0.0321	0.0648
	nmae	0.1616	0.2473	0.1590	0.2396
cumulated	nrmse	0.0704	0.0846	0.0902	0.1073

; the maximum NRMSE and NMAE values are about 8% and 50%, respectively. The same table also reports the cumulated errors obtained combining generation and load NRMSE values in quadrature.

As an example of the EMS outputs, the plots of battery power and SOC profiles for Users B and C in the first three days of the considered month are shown in Figure 5c,d. These plots are also representative of the profiles of the other two users. As expected, the maximum battery charging/discharging powers are not exceeded.

A plot of the aggregated user-committed GEPP versus the actual cumulative grid power in the same three days is shown in Figure 6. As the figure shows, the two curves overlap each other almost perfectly. Furthermore, Figure 7 shows the difference between planned and measured aggregated GEPP. In particular, the predictability of the power profile is clearly expressed by the error metrics that were computed on the GEPP, as shown in

Table 6. Error metrics on GEPP.

	User A	User B	User C	User D	Aggregated
nrmse	0.0452	0.0767	0.0135	0.0450	0.0288
nmae	0.4667	0.5521	0.1163	0.3694	0.2202

. The normalization factor for the metrics of each user was the maximum contractual power (i.e., 3 kW for Users A and C, and 4 kW for Users B and D). On the other hand, the normalization factor for the cumulative GEPP was the maximum cumulative contractual power, i.e., 14 kW.

It is worth noting that the maximum NRMSE and NMAE values in Table 6 are about 7% and 55%, respectively. Furthermore, the low NRMSE value on the aggregated profile (2.88%) shows that, from the utility perspective, the uncertainty can be even lower than that of the single households. This result is due to the statistical compensation of users’ deviations, and it also indicates the effectiveness of the EMS for the utility operator.

As an example of the end user’s cash flow, a sample day is discussed, i.e., day 4. Despite the forecasting errors and the effort to adhere to the committed GEPP, User B earns $2.46, i.e., 1.46% more than the income without any EMS; User C, instead, pays $0.70, i.e., 3.23% less than the expense without any EMS. The actual profit of both users could even be higher if economic incentives were proposed by the public utility to reward the uncertainty reduction on the GEPP.

6. Conclusions and Future Perspectives

An embedded and computationally efficient implementation of an EMS for smart homes has been proposed. The chosen EMS algorithm has been redesigned using DP instead of MILP to simplify the implementation process. As demonstrated by a computational complexity analysis, the obtained EMS is suitable for the embedded implementation. Furthermore, the optimality of the solutions has not been compromised in the algorithm redesign.

A suitable test bench was set up to assess the EMS performance in a chosen case study (i.e., four networked dwellings including renewable generators) that was emulated. The experimental results show that the EMS can perform each of its tasks on the embedded platform within the allowed time frames; they also show that the embedded EMS correctly exchanges data with the wireless sensors and the grid manager’s data aggregator. Furthermore, an extended validation of the EMS effectiveness was performed in terms of cash flow increase and uncertainty reduction.

In particular, the experiments showed that the EMS performs its computations in a few minutes for the Planning task and in less than 2.5 s for the Online Replanning task. Furthermore, the EMS performance is very good since the uncertainty on the daily profile of the power exchanged by the users with the utility is significantly mitigated (NMRSE = 2.88% and NMAE = 22%). This result is a first step towards the quick and affordable adoption of EMSs in smart homes.

As for the future development of this work, the short execution times obtained for the proposed embedded EMS suggest that there is sufficient margin to take into account other important aspects such as battery state of health in the EMS formulation. Furthermore, future activities will contemplate testing the embedded EMS on the field, i.e., within real-world smart homes.