# Towards the Real-World Deployment of a Smart Home EMS: A DP Implementation on the Raspberry Pi
## 4 Embedded Implementation of the Chosen EMS
### Dynamic Programming Algorithm
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. \[SOC_{t+1}-SOC_{t}= \begin{cases}\eta\frac{\Delta t}{C_{b}}P_{batt,ref}&\text{if }P_{batt,ref}\geq 0\\ \frac{\Delta t}{\eta C_{b}}P_{batt,ref}&\text{otherwise}\end{cases}  \tag{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 GEPs. The two power profiles were then plotted, as shown in Section 5.3. Figure 4: Synopsis of the experimental setup. ### 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 Tables 2 and 3, 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.