Methodology for Designing an Electricity Demand System in the Context of IoT Household

Featured Application

Organize your IoT infrastructure and systematically collect usage data for specific contexts of use and optimize the use by reducing electrical consumption.

Abstract

Many efforts have been made to create scenarios whereby interconnecting IoT can be used. The primary objective of these efforts has been to centralize its access as a single list and to monitor its use and trigger its different functionalities from apps. However, few efforts have addressed the problem of electricity consumption from those devices in the context of a residence. Existing datasets for machine predictive systems are focused on data analytics for global consumption but neglect the use of such solutions by the common citizen as a means of re-educating our citizens and optimizing electricity consumption. Without considering the environmental impact and the urgent need to address this growing global emergency, ordinary citizens require systems that help them be aware of what they consume and thus aspire to make a change. In this work, we propose a methodology that builds on the formal mathematical modeling and development of a simulator to substitute the need to collect real data from real world context of use, as well as an interactive system that integrates the whole process. By adding this module to the architecture our prior work, this work is ready for use in real-life scenarios where electrical consumption could be significantly reduced.

1. Introduction

The importance of improving and above all making electricity consumption more efficient has been reported for a long time, pointing to the need for interactive systems that promote a change in the way consumers make their consumption more efficient [1] or make them aware of what they consume in order to favor a change [2]. In the end, it has been shown [3] that an interactive system can be an agent of change regarding our behavior at home regarding the use of electricity. The electricity consumption of a house can be monitored and controlled using a demand system (DS), which also serves to optimize the consumer’s electricity consumption [3]. The development of demand systems focuses on the monitoring and control of the electrical devices that characterize a scenario, as well as the regulation between the different generating sources of electrical energy that are available, and this is done according to specifics scenarios.

The problem is that general purpose software used to design those scenarios is missing for research purposes and to monitor devices as a householder. In general, current solutions focus on algorithms and techniques that can be implemented to optimize consumption while maintaining the comfort of the resident [4], that make efficient use of electrical energy [5], device classification for efficient use [6], and that include climatic and seasonal factors to optimize consumption [7]. Moreover, it is perfectly understandable that a greater effort is being devoted to optimization techniques for electricity consumption since, according to the International Energy Agency (IAEA), global energy demand is 8.3% higher than in 2000, and it is estimated that demand will increase by 2.1% annually until 2040. One fifth of global consumption is destined to cover heating and ventilation needs. Thirty per cent of the demand is used in the domestic sector [8,9]. If the user could participate actively by controlling and modifying the behavior of electricity consumption, then it could help to control the problems that have arisen due to the increase in electricity consumption [10]. Therefore, we need an interactive system to achieve this goal.

Based on the related works, the growing interest in developing energy management systems for the consumer has been observed [3,11,12]. The proposals are limited to considering either the development and implementation of a sensor architecture, the development of human-computer interfaces, modeling of the use of the devices by the user, or the use of metaheuristics to make efficient use of devices and thus meet specific implementation objectives.

In this context, we find that current studies present the following limitations:

• Single-user system: most of the solutions that exist in the market offer a monitoring, control and support tool for one person at a time and hardly provide an integrated global monitoring and control system.
• Absence of a monitoring and control system: because of the foregoing, Dashboard-type platforms that allow the integration of multiple users or multiple experimentation processes are not identified.
• Research-based solutions: normally, the works work in controlled contexts and hardly have a scope in the real life.
• Limited data availability: due to its nature, the data used for classifier training is stored in other media and is difficult to access, meaning that it is difficult to replicate the experiments and, above all, to train new algorithms.
• Limited explanation of the tools: almost all are black boxes from which explanatory models can hardly be generated and, above all, are impossible to extend or modify.
• Heterogeneity of users: this type of system is useful in principle for specialists with very advanced technical skills and leaves out specialists in related areas that could enrich their investigations.
• Limited device independency: a big challenge is the effective incorporation of multiple devices without any dependency on manufacturers. Collecting signals is something that can be done from any object of daily life enriched with some type of sensor.
• Limited tools to define scenarios of context of use: families may be interested in controlling the lifecycle of heir devices, creating, modifying, or deleting devices in specific contexts. For instance, one family member may be responsible for the bathroom, while the whole family is responsible for the rest of the house.

To effectively use in any house a software that monitors our electricity consumption and lets us be aware of the changes that we need no make, we must change the way in which we collect information from household contexts, but specifically to convey the data to users. In this paper, an architecture of an electricity consumption scenarios configuration system is presented as an alternative to the current limitations of existing work. Section 2 presents the related work review and the limitations we found in it. Section 3 presents the methodological development of home energy management system and IoT demand system architecture. Section 4 s presents the methodology followed to develop the simulator of household appliances consumption and behavior. The evaluation and discussion of the results is presented in Section 5. Lastly, in Section 6 the conclusions are presented.

2. Related Work

A literature review was carried out to detect those works related to the subject of this publication through a systematic process proposed by [13]. As a result of this review, the analysis and theoretical construction is presented, providing a critical perspective of the selected related works.

A home energy management system aims to find an optimal solution under a set of constraints; its architecture is composed of a scheduling module, monitoring module, prediction module, and a control unit [6].

Home automation systems have attracted considerable attention with the advancement of communication technology. A smart home is an IoT application that uses the Internet to monitor and control appliances through a home automation system. Lack of use of Internet of Things (IoT) technology, unfriendly user interfaces, a limited range of wireless transmission, and high costs are the limitations of existing home automation systems [14].

A smart home system can be an important part of a smart grid system. Smart homes are an important means of achieving real-time interactions between users and the network, increasing the capacity of integrated service networks, satisfying interactive marketing needs, and improving quality of service [15]. Gunawan et al., (2017) indicate that smart home control systems can be integrated into existing appliances, reducing human interference, improving safety, and saving energy [16]. However, this remains an open problem due to difficulties such as distance from the grid, crosstalk, lack of usability, and increased cost and energy consumption.

Significantly higher heat and power rations and high degree of integration between households and businesses in the industrial and utility sectors are needed in smart city energy systems. By implementing the IoT, smart cities can control energy in complex ways through ubiquitous monitoring and secure communications [17].

IoT-based energy management has revolutionized information and telecommunication technologies, inheriting the advantages of distribution access, computing, storage, and distribution to control the grid [18,19]. Zikria et al., (2018) point out that the vision of IoT is to achieve seamless integration between smart objects and the traditional internet [20]. In general, smart objects are very limited in terms of computational, memory, and energy resources. In addition, the wireless links commonly used between smart objects or to the internet are often slow and subject to high packet loss.

However, IoT offers significant advantages over traditional communication technologies for smart home and network applications are still rare [21,22].

Wang et al., (2021) present a multi-objective optimization method designed under the smart grid environment, which considers two main purposes: energy consumption cost and user satisfaction [23]. Their proposal is based on a new improved version of the butterfly algorithm to increase the convergence speed. The IoT system is based on ZigBee. In their results they show the efficiency of the system in terms of significant energy cost savings, demonstrating the simulation results in comparison with the normal home energy management system to state the efficiency of the system.

On their part, Swastika et al., (2018) point out that the conventional power grid system is outdated to achieve rapid growth in demand for electricity availability [19]. Energy use continues to increase in line with economic and population growth. In their research they make a smart grid system design based on IoT to be continuously monitored and controlled. They also mention that Indonesia is developing a smart grid that is expected before 2025 and how smart grid technology could be implemented in at least 50% of households to support the existence of a smart city.

Gunawan et al., (2017) make a proposal for home automation by allowing users to remotely turn on or off any IoT-based home appliance with the enhancement of a solar charger [16]. This prototype uses four types of sensors: PIR sensor, temperature sensor, ultrasonic sensor, and smoke gas sensor for automatic environmental control and intrusion detection. The appliances are successfully integrated into the smart home control system through relays; however, this proposal is prototyped, and a performance evaluation is proposed in future work.

Bassoli et al., (2018) present a new system architecture suitable for human monitoring based on Wi-Fi connectivity, reducing cost and implementation burden by using the Internet connection supported by standard home modem-routers, and reducing the need for range extenders thanks to the Wi-Fi signal range [24]. Their proposal is strictly IoT-compatible, presenting a hardware architecture designed to collect data usable by behavioral analysis models developed elsewhere. In the proposed architecture, sensors connect to the Internet via a Wi-Fi router in an IoT-compatible way, without the need of adding a dedicated home gateway to ensure connectivity or the range extenders that are typically required when using other standard protocols. The complete system has been tested in a real-world environment to assess the feasibility of its adoption in a real-world situation. After two months of testing, only one sensor ran out of battery power. For the other sensors, the lab set showed a residual charge of about 46%, while in the home environment this value was 34%. Power consumption did not affect usability, and performance was not influenced by the system architecture.

Jabbar et al., (2019) present a cost-effective, hybrid (local and remote) IoT-based home automation system with a user-friendly user interface for smartphones and laptops [14]. It develops a prototype called IoT@HoMe with an algorithm to monitor home conditions and automate the control of household appliances via the Internet anytime, anywhere. This system uses a node microcontroller unit (NodeMCU) as a Wi-Fi based gateway to connect different sensors and update its data to Adafruit IoT.

In this research we have focused on the development of a smart home system, with emphasis on the use of devices. Lu et al., (2010) conducted a systematic review where they found that 90% of the papers related to the development of smart home systems have datasets with details about devices, e.g., [6,25], but most of them do not focus on devices [26]. What we have found even more interesting is that, in these works, scenarios with one to four devices are described. The complexity of collecting real data is the main reason for the lack of more complex scenarios. Therefore, it is necessary to simulate and create synthetic data.

On the other hand, the control variables used, as well as the algorithms, are of interest to the authors as a means of replicating some of these solutions. Few papers [5,7,25,27] explicitly discuss these parameters, while others mention algorithms [6,10,28,29] to deal with them without communicating the details. The problem is that, without constraints, how can we know what is the optimal use of electricity in each scenario? This reinforces the need for a more robust specification of the scenarios and, even more, the possibility of defining the usage constraints of the devices in that scenario. The simplest solution would be to turn everything off. We know that there are devices that need to be kept on, some on standby, others switched off.

For the development of a demand system, three factors are defined that influence the design of the architecture: the implementation objectives, the variables, and the factors derived from the scenario where the system is to be located. The type of data handled in a demand system refers to the electricity consumption of each of the devices that make up the physical architecture, which is the architecture that will be monitored and controlled. Each of these consumptions is within a range, which is determined by the minimum and maximum consumption of the device to which it refers. Consumption data in demand systems are used for decision making [12,30].

It is necessary to create a power consumption database by identifying device characteristics. The lack of a database that can be used for this purpose is documented in [31]. On the other hand, the parameters that must be considered for the development of a simulator, the main one being the one for which it is desired to develop. For the specific case of a home energy management system, the simulator is implemented with the aim of generating a behavior of use and consumption of devices that characterize the implementation context.

The implementation of an interactive system [29,32,33,34] as part of a home energy management system encourages the user to make changes in consumption behavior, as it makes him/her act efficiently and consciously, thus generating a transparent, dynamic, controllable, and intelligent environment [35,36,37]. It also provides convenience by simplifying the control and operation of electrical devices [38]. The interaction system is a means to make a virtual representation by creating objects [39] of the identified context, the interactive system groups the data with respect to the implementation target [31,40,41]. The system interface must have the characteristic of being flexible, accessible, and intuitive as a SCADA system [42], allowing the inclusion of more virtual objects to the system. The presentation of consumption data through the interface [38] reduces consumption by 3% to 13% [31].

The state of the art has been reviewed to justify the baseline methodology for the development of an energy management system for domestic contexts, studying what demand system and data flow in monitoring architectures consist of, which together allow the definition of a proposed methodology. The objectives of the design and implementation of electrical energy management systems for a household were identified in the literature, as well as how to generate usage and consumption profiles of the electrical devices that characterize a home when there is no physical infrastructure to provide this data. It also identifies the data that should be displayed in an interactive interface for these management systems, as well as the characteristics that identify the devices and that allow modeling of the electricity consumption of a home. Finally, the techniques most implemented in these management systems are mentioned to find the optimized consumption of the devices that characterize the implementation context.

3. Home Energy Management System with IoT Demand System Architecture

There are, at least, three main modules (see Figure 1) in a home energy management system. These are: the programming unit, monitor unit, and prediction and control unit [42]. In the programming module, preference data is entered, which are sent to the control unit. The control unit performs communication between the devices by sending and receiving the signals, and it communicates with the prediction module by sending data that allows a profile of household appliance use to be generated. The logical control unit sends the consumption of each appliance to the programming module. For the development of a demand system, three factors are defined which influence the architecture design: implementation objectives, variables, and the factors derived from the scenario where the system will be located. This scenario’s definition is our concern.

In software engineering, a specification-based (or model-driven) approach relies on the power of models to construct and reason about software systems. Our approach to build the architecture is based on models, and we use UML diagrams to express them, as well as task models [43] with canonical task definitions [44] as a baseline to document user needs and interaction in the user interface. The benefit of developing software with a rational set of principles includes, but is not limited to, reproducibility and its orientation towards quality criteria.

3.1. Conceptual Design of a Demand System

Task & Concepts (T&C) describe the various user’s tasks to be carried out and the domain-oriented concepts as they are required by these tasks to be performed. The task model provides a description of each task in a workflow of the IoT System; those tasks are Enable Access, User Functions, Device Functions, Scenario Functions, and Report Functions. The Enable Access workflow works like any login system, i.e., the system validates any user in the system and requires a username and password to access to the next abstract functions. The user’s needs identified include CRUDs for user, devices, scenarios, reports, and a special comment on data visualization. In this paper, the scenarios specification is our main concern. There is no magic around the tasks needed to handle scenario definitions (see Figure 2). It is also just to create a scenario task and to add devices to it. The interesting aspect is on how to convey this data to the user.

The concepts are stored in a database connected through the class model. To get this model we followed to following approach: first, the scenarios to be characterized were identified (home, apartment, office, and living room), for which it was necessary to identify the devices that were most frequently found in that scenario. Second, a search was made for frequently used devices in the desired setting. The search was carried out through an internet search on the pages of the consumer federation procuracy (PROFECO, for the acronym in Spanish) in the governmental institution in Mexico, using data about devices, their attributes, and statistics about consumption. Third, the list of devices and characteristics of the devices frequently used in the selected scenarios were taken. Fourth, for each of the devices the data (most common) of minimum, maximum, and standby power, and the time of daily frequent use were identified. When creating the list, the designer is the one who identifies if the device can be disconnected or not, and the type of device to which it belongs given the way in which it works. Fifth, the devices were categorized with respect to the group to which they belonged (office and living room, video games, appliances, electronics, security, lighting, and ventilation and heating. Based on this data characterization is the fact that the Device class is decomposed into Sensor or product with its corresponding fields. In our understanding, this is the best way of characterizing IoT household contexts of use and scenarios definitions.

The dynamics of the interactive system is modelled with UML sequence diagrams showing the interaction in time sequence of each activity; the activities included are those mentioned early in the task model section. The first sequence diagram is from the user login and logout. The next sequence diagrams are for the CRUD functions explained before: the User CRUD functions, the Device CRUD functions, the Stage CRUD functions, and the Report CRUD functions. We focus on the flow of the scenario’s definition. As you can see, the system is modelled with error handling as a mechanism to guarantee the correct use of the interactive system. The concept of stage or scenario is defined and then it can be read and edited with anything that is related to typical objects’ handling.

Moreover, for the static structural architecture, the Abstract Factory pattern is proposed to deal with the problem of adding unknown devices. This idea fits very well in the context of IoT appliances as it is not just about adding a new device, but also, to be prepared for unknown, with new reports, and the new analysis processes could be implemented without there being a big problem in integrating them in the same way. IoT connections can be quite diverse—different brands, different kind of devices (smart light, smart plugs, smart switches, and more)—but in the end all of them are similar and can be grouped into families. Here is where Abstract Factory pattern makes a lot of sense as an architectural solution because it adds compatibility with new devices by simply implementing new interfaces. In the case of IoT connections, an abstract factory and abstract connection would need to be defined for each kind of device, and then implementation of concrete kind of connections would be implemented for each brand.

The strategy, Observer, and Command Design Patterns are also considered. The Strategy Pattern implements functions for every user and has four interfaces for the control of the CRUD functions. The Observer Pattern implements functions to keep all users informed about the state of each device. Last, the Command Pattern implements functions to control the state of each intelligent; the implemented functions are turn on and turn off.

3.2. Home Demand System User Interface Design

The User Interface design followed an extended version of the codesign Framework proposed in [45]. It does this, first, by introducing sources of data to the discussion and then by introducing aspect of social computing to reinforce the current perspective of the framework and gamification strategies. Finally, the prototyping is created by considering UI design patterns. The Safari technique is a useful tool, which makes designers to put in the shoes of potential users. By doing that, further techniques such as participatory observation, interviews, focus groups, might flow easily as everyone is aware of the context of use. Consequently, problems might be anticipated that our product may have in certain situations. It is important to perform a scan of the system in the perspective of the user without any experience and to answer key questions such as: What can happen during the use of the system? What can go wrong with the system? How many difficulties can someone encounter when trying to solve their energy cost calculations? To better exemplify the challenges that our potential users may face, we propose the use of storytelling in which you can see different situations from a general point of view as designers of the project, to see everyday situations as ordinary people who may need our proposed solution throughout the project. The list of situations identified is the following:

• A person is surprised because he realizes that after three months his electricity bill has increased excessively, so he urgently seeks an explanation for this so that he can find a solution in his favor and not have to pay for it all.
• A person is very desperate because he needs to use three different applications to control his devices connected to his home.
• One lady’s son always leaves all the lights on, does not unplug infrequently used devices, and forgets to turn off the TV before going to bed, and all these bad habits are being reflected in the electric bills.
• What happens here is that we have subject matter experts, so the questions asked are more system focused. Therefore, they realize that they may suffer from cyber-attacks, system infections, and server crashes. So, all of this must be considered for the development of the system.

There is nothing new to be said about the results but just that they confirm the previous steps. We will come back to the interviews as they were relevant in the decision making for the UI. The result from the first stage was PERSONAS using Card Sorting technique. Complementary to this model, the Journey Map allows us to build and share customer knowledge across the organization about what they need at each point in their day and how these requirements are being met and provide insight into customer pain points. Thanks to this type of mapping, we can see how in the day people require better control over their energy consumption. A normal day involves someone of mature age working from home; so, to some extent, this shows the excessive expenditure that can be generated day by day by just small insignificant and controllable things. Finally, the empathy map is a model that shows a user who really cares about his electricity consumption and the environment, so the user is looking for a solution to his “small” problem.

A complete overview of user needs is the result of previous steps. An understanding of how they perceive the problem is needed. Then, the co-design process starts. In the middle of Figure 3, the board for the co-design is shown. The results of the process are the vision board of the project, PERSONAS, user need, and functionalities, and the value added to user’s life is written at the end. Functionality is defined by working around canonical task types [44]. Tasks were defined in the previous steps; at this point, the question is how they are going to be implemented. For instance, a selection of how many objects are involved is determined by the number of possible answers, with 2 to 4 radio buttons or checkboxes used as an option. If the numbers of options increases, then a different interactive object might be used.

The question goes a little bit further when defining the interaction technique, as a selection might be influenced by social computing or gamified strategies. To address the gamification aspect, the Octalysis Framework [46] provides a complete guide on how to effectively consider some strategies. In the context of the demand home energy management system, this is a challenge as the human behavior, we hope, might change thanks to the awareness of electricity consumption.

Finally, the codesign Framework focuses on Social Computing to achieve a perfect balance between social behavior and computational systems, and it seeks to create new practices that allow socialization through technology. The demand home management system includes certain actions that family members or acquaintances, in the case of shared floors, can perform, since the application will be used by any member of a community using the same devices. For instance, to share a limit of energy expenditure, an alert will be sent to each of the participants warning them of their current consumption with the aim of thm knowing a little more about the depth of their electrical activity, and this can be complemented with smart connection devices to the current in which, through Siri or Alexa, you can identify the devices that consume more energy. In this way the different members can see the consumption of other participants and send messages warning of excessive consumption in some area of the house or even emojis, allowing interaction between participants of the same family. Plus, if the monthly goal of maximum energy consumption is achieved, it can be shared on social networks such as Facebook.

This way of working, of co-design, allows the design of a solution close to the context of use, and that, in principle, is a good first step towards the solution.

4. Methodology to Simulate Household Appliance Consumption and Behavior

A mathematical representation of electric consumption in a house is developed by a mathematical model. The sort of devices and their characterization are used for modeling. The devices description is conducted by kind of device, the minimum and maximum consumption, and the frequent use time. The on/off devices’ states are represented by 1 and 0, respectively.

Depending on the way in which the household appliances work, they can be sorted into flexible, not flexible, interruptible, and uninterruptible devices. The flexible devices are the devices of electric consumption whose function can be interrupted and continue in another moment.

Flexible devices can be put on stand-by. The not-flexible appliances are devices of electric consumption that cannot be turned off; this type of appliance has a constant operation. Interruptible appliances are the electrical consumption devices that can be used at any time; their time of use varies according to the user´s needs. Uninterruptible appliances are electrical devices that stop when their function has finished; the electric consumption can be constant or variable.

The set of devices in a context is represented by A, and i-esime device is represented by ai. In the set A, there are four subsets A_I, A_U, A_F, A_NF, and A = A_I U A_U U A_F U A_NF, where every subset represents a kind of device: a_I ꞓ A_I, a_U ꞓ A_U, a_F ꞓ A_F, a_NF ꞓ A_NF.

The on/off devices state in the ꞇ moment is represented by (ꞇ) = [0, 1], 1 represents turned device on, and 0 turned device off. There are 24 moments considered in the modelling, ꞇ ꞓ T, T = [ꞇ1, ꞇ2, …, ꞇ24].

The cardinality of set A and its subsets are represented in Equations (1)–(3):

|A| = m, |AI| = n, |AU| = p, |AF| = q

(1)

|ANF| = r. So, n + p + q + r = m

(2)

A = {a1, a2, …, am}

(3)

Set A can have devices belonging to the same type of device with different identifiers. The function of the consumption Equation (4) of the devices takes the elements of the set A in each of the moments contemplated in T and generates the consumption measured in watts. The hourly consumption of a device at a specific time is given in Equation (5).

$$\epsilon :A\times T \to R^{+}$$

(4)

$$\epsilon \left(a_i,{\tau }_i\right)={\mathsf{\Upsilon }}_{a_i}^{\tau }$$

(5)

The total consumption of the set is represented by Equation (6), which is the sum of the consumption made by all the devices daily. The hourly consumption Equation (7) of all the devices is the sum of the consumption that is carried out at a specific moment by each of the device groups.

$$\epsilon ={\epsilon }_I+{\epsilon }_{NI}+{\epsilon }_F+{\epsilon }_{NF}$$

(6)

$${\mathsf{\Upsilon }}^{\tau }={\mathsf{\Upsilon }}_I^{\tau }+{\mathsf{\Upsilon }}_{NI}^{\tau }+{\mathsf{\Upsilon }}_F^{\tau }+{\mathsf{\Upsilon }}_{NF}^{\tau }$$

(7)

The minimum consumptions per day are shown by Equation (8), those per hour by Equation (9).

$${\epsilon }_{min}={\epsilon }_{NF}={\displaystyle \sum }_{a_{NF}\in A_{NF}}{{\displaystyle \sum }}_{\tau =1}^T{\mathsf{\Upsilon }}_a{}_{NF}^{\tau }$$

(8)

$${\mathsf{\Upsilon }}_{min}^{\tau }={\displaystyle \sum }_{a_{NF}\in A_{NF}}{\mathsf{\Upsilon }}_{NF}^{\tau }\hspace{1em}\forall \tau ,\tau \in T$$

(9)

The maximum consumptions per day and per hour are represented by Equations (10) and (11), respectively.

$${\epsilon }_{max}={\epsilon }_I+{\epsilon }_{NI}+{\epsilon }_F+{\epsilon }_{NF}={\displaystyle \sum }_{a_i\in A}{{\displaystyle \sum }}_{\tau =1}^T{\mathsf{\Upsilon }}_a{}_i^{\tau },{\alpha }_{a_i}\left(\tau \right)=1$$

(10)

$${\mathsf{\Upsilon }}_{max}^{\tau }={\mathsf{\Upsilon }}_I^{\tau }+{\mathsf{\Upsilon }}_{NI}^{\tau }+{\mathsf{\Upsilon }}_F^{\tau }+{\mathsf{\Upsilon }}_{NF}^{\tau }={\displaystyle \sum }_{a_i\in A}{\mathsf{\Upsilon }}_{a_i}^{\tau }\hspace{1em}\forall \tau ,\tau \in T$$

(11)

The mode is identified by Equation (12), where ε_opt meets the needs of the user, minimizes consumption, and reduces peaks average ratio.

$${\epsilon }_{min}<{\epsilon }_{opt}<{\epsilon }_{max}$$

(12)

Set A has four subsets: A_I, A_U, A_F, A_NF. A_I represents all interruptible devices, a_i ꞓ A_I. A_I = {a_I1, a_I2, …, aIn}, |A_I| = n < m, where n is the cardinality of A_I. This is true of Equation (13):

$$\exists a_{Ii},a_{Ij}\in A_I,i\ne j\to a_{Ii}=a_{Ij}$$

(13)

The total consumption of the subset A_I is obtained from Equation (14) and represents the sum of the total consumption of each of the devices belonging to this subset and whose consideration depends on the state of the device (on/off) for each moment. The partial consumption obtained is shown by Equation (15), which is the sum of the consumption made by all the devices that are on in the moment T.

$${\epsilon }_{max}={\epsilon }_I+{\epsilon }_{NI}+{\epsilon }_F+{\epsilon }_{NF}={\displaystyle \sum }_{a_i\in A}{{\displaystyle \sum }}_{\tau =1}^T{\mathsf{\Upsilon }}_a{}_i^{\tau },{\alpha }_{a_i}\left(\tau \right)=1$$

(14)

$${\mathsf{\Upsilon }}_I^{\tau }={\displaystyle \sum }_{a_{Ii}\in A_I}\left({\mathsf{\Upsilon }}_{a_{Ii}}^{\tau }x{\alpha }_{a_{Ii}}\left(\tau \right)\right)\forall \tau ,\tau \in T$$

(15)

To define the subsets A_U, A_F, and A_NF are used similar expressions to those exposed for the subset A_I. For A_NF, $\alpha \left(\tau \right)=$1 because they are on all day. The window representing the range of hours between which the device can operate is showed in Equation (19). To define the window device are identified four parameters:

• The device on time ${\sigma }_{a_{Ii}}$,
• The time for which the device will no longer turn on ${\psi }_{a_{Ii}}$,
• The frequent operating time ${\xi }_{a_{Ii}}$, and
• The time ${\varsigma }_{a_{Ii}}$ at which the device $a_{Ii}$ has been turned on.

These four parameters fulfill Equations (16)–(18)

$$\left[{\sigma }_{a_I},{\psi }_{a_I}\right]$$

(16)

$${\sigma }_{a_{Ii}}\le {\psi }_{a_{Ii}}$$

(17)

$${\varsigma }_{a_I}\ge {\sigma }_{a_I}\hspace{1em}y{\varsigma }_{a_I}\le {\psi }_{a_I}-{\xi }_{a_I}$$

(18)

$${\varsigma }_{a_I}\in \left[{\sigma }_{a_I},{\psi }_{a_I}-{\xi }_{a_I}\right]$$

(19)

The objective function is shown by Equation (20) and is defined from the total daily consumption, the consumption per hour, and by considering the objective of minimizing the system consumption.

$$min {\displaystyle \sum }_{\tau =1}^T({\displaystyle \sum }_{a_iϵA}{\mathsf{\Upsilon }}_{a_i}^{\tau })$$

(20)

For he consumption array Mε, see Equation (21), with all the consumptions for every device per hour.

$$M\epsilon =\left[\begin{array}{cccccccccccc}{\gamma }_{{\mathrm{I}}_1}^{{\tau }_1}& \dots & {\gamma }_{{\mathrm{I}}_n}^{{\tau }_1}& {\gamma }_{{\mathrm{N}\mathrm{I}}_1}^{{\tau }_1}& \dots & {\gamma }_{{\mathrm{N}\mathrm{I}}_{\rho }}^{{\tau }_1}& {\gamma }_{F_1}^{{\tau }_1}& \dots & {\gamma }_{{\mathrm{F}}_{\varrho }}^{{\tau }_1}& {\gamma }_{{\mathrm{N}\mathrm{F}}_1}^{{\tau }_1}& \dots & {\gamma }_{{\mathrm{N}\mathrm{F}}_{\tau }}^{{\tau }_1}\\ ⋮& \ddots & & & & & & ⋮& & & & ⋮\\ {\gamma }_{{\mathrm{I}}_1}^{{\tau }_{24}}& \dots & {\gamma }_{{\mathrm{I}}_n}^{{\tau }_{24}}& {\gamma }_{{\mathrm{N}\mathrm{I}}_1}^{{\tau }_{24}}& \dots & {\gamma }_{{\mathrm{N}\mathrm{I}}_{\rho }}^{{\tau }_{24}}& {\gamma }_{F_1}^{{\tau }_{24}}& \dots & {\gamma }_{{\mathrm{F}}_{\varrho }}^{{\tau }_{24}}& {\gamma }_{{\mathrm{N}\mathrm{F}}_1}^{{\tau }_{24}}& \dots & {\gamma }_{{\mathrm{N}\mathrm{F}}_{\tau }}^{{\tau }_{24}}\end{array}\right]$$

(21)

The simulator construction process consists of two stages: conceptual and technical. The conceptual stage consists of three phases: the problem definition, the system’s conceptualization, and the model representation. The technical stage has three phases: the behavior model, the model´s evaluation, and the use and analysis model.

A strategy to approximate an unknown quantity $\mu$ is using random sampling, referred to as Monte Carlo Methods. This method is based on finding a sequence $X_1,X_2,\dots ,X_n$ of mutually independent and identically distributed random variables, such that the expectation $E{X}_i=\mu$ exits for $i=1,2,\dots ,n$. Assuming that $S_n=X_1+X_2+\cdots +X_n$, the Weak Law of Large Numbers states that, for every $\epsilon >0$, $\underset{n\to \infty }{\lim }pr\left(\left|\frac{S_n}{n}-\mu \right|>\epsilon \right)=0$.

Moreover, when the expectation ${\sigma }^2=E{\left(X_i-\mu \right)}^2$ exits the Central Limit theorem asserts that $pr\left(\left|\frac{S_n}{n}-\mu \right|<\frac{3\sigma }{\sqrt{n}}\right)\approx 0.997$, then the arithmetic mean of $S_n/n$ will be approximately equal to $\mu$.

5. Discussion

The experiment is twofold: on the one hand, we will discuss the Monte Carlo method and the results; on the other hand, the user interface designed is to be used by any citizen. We will discuss the Monte Carlo Method first.

5.1. Evaluation of the Monte Carlo Simulation

The simulator was programmed in MatLab R2018a following the Monte Carlo method with the Acceptance–Rejection technique [30] used to generate the fins. This technique supposes that there is a method for simulating a random variable from probability mass function. First is simulated a random variable “Y” from the mass function “qj” and then, accepting this simulated value, with a probability of pj/qj. The constant c is defined by getting the maximum of pj/qj, where pj > 0. Therefore, the simulated value Y with the probability mass function qj generates a random number U, if U > pj/cqj set X = Y and stop; otherwise it generates a new Y.

The diagram of the Acceptance–Rejection technique is showed in the Figure 4:

Before use, the simulator was validated by generating almost 1000 pieces of data, which were graphed in a histogram, doing that for every appliance (furnace fan, space heater, room air conditioner, and clothes heater). The waves between the histograms and probability distribution function (PDF) devices were so similar.

In Figure 5A is showed furnace fan histogram. It is possible to see from this that the shape is like PDF´s furnace fan, as reported in [47]. The same thing happens with Figure 5B–D compared with PDS’s corresponding devices.

After validating the correctly simulator function, it was used to generate devices´ profiles of use and consumption. The simulation of trials was carried out for furnace fan, space heater, air conditioner, and clothes heater. Four arrays of number of experiments by 24 (row—columns) were developed per device (every array corresponds to schedules of turning on device, usage profile, consumptions, and consumption profile); two arrays of number of experiments per device (where every array corresponds to the total use and total consumption per test); and, lastly, were obtained two data, the general consumption and general use time per test device.

The number of experiments by each simulation is defined as follows:

• Choose an acceptable value for D (d = 10⁻³) to estimate the standard estimation.
• Generate 100 experiments.
• Generate more experiments, when k values and $\frac{s}{\sqrt{k}}<d$ have been generated, where s is the standard deviation of k test sampling
• To estimate θ is from $\overline{X}={\displaystyle \sum }_{i=1}^k\raisebox{1ex}{$X_i$}\!\left/ \!\raisebox{-1ex}{$k$}\right.$

Therefore, the number of experiments necessary per device for the furnace fan is almost 189 experiments, for the space heater 388 experiments, for the room air conditioner 419, and for the clothes heater 100 experiments. Based on these results we do know that we are able to generate, based on this method, real-life user behavior electrical consumptions for electrical devices in specific context of use.

5.2. Evaluation of the Physical Layer: User Interface

The design of the interface focuses on making the user experience understandable and quick to understand. Using the interface, the physical space you want to characterize is represented. The interface design makes use of icons that allow the user to interact intuitively. The characterization of the rooms is conducted by identifying the electrical devices, Figure 6.

Once the rooms have been created, it is possible to make the consumption visualization by selecting either the month or the week that is desired. If the selected period is monthly, the display of consumption can be conducted by device or by scenario. In the visualization of consumption by device, a graph is presented that projects consumption over the course of the month, as well as the percentage to which it corresponds according to total consumption (Figure 7A). In the option of the visualization by scenario, the consumptions and the percentage of each of the scenarios for the selected period are shown (Figure 7B).

If the viewing period is weekly, the graph shown for this option shows the percentages of consumption per week (Figure 8). In the fusion module the consumption and status profiles of ten devices are created (heater, air, fan, dryer, dishwasher, stove, microwave, washing machine, refrigerator, spotlight), the data corresponding to the washing machine, fan, heater, and dryer devices being provided by the simulator, and the data of the remaining six devices being generated thereby. Each of the files corresponds to each of the twelve months that make up a year. The number of rows in each of the files is the result of multiplying the number of days according to the month it refers to by 24.

5.3. Evaluation of the Prediction Module

For each of the status and consumption files generated for a month, 100 repetitions of the experiment are performed (100 consumption proposals are generated). To make the analysis of the data are concentrated in a single file to the set of all the generated of each month. For this data, the statistical average for each of the devices is obtained, the device-experiment standard deviation, and the average of the standard deviation per device is obtained.

The results of the analysis; the washing machine, dryer, spotlight, and stove devices report normal consumption averages and the standard deviation is zero since the consumption data (minimum, maximum and average) stored in the file used by the procedures is the same. The proposal generated in this module is displayed in the interface by transposing the graphs of actual consumption and that of the proposed consumption (Figure 9). Although you have this information at hand, many of the users we interviewed were not very enthusiastic about attending to the recommendations to modify the habits of using their equipment.

5.4. Evaluation of the Methodology

The validation of the research is of two kinds. On the first hand, empirical validation of the approach with real-world designers was conducted with the case study. A set of 10 developers were needed to create the software based on the architecture. We have the following descriptive analysis resulting from interviews and observation, with the software showing the following attributes:

• Method explicitness. The component of the architecture is comprehensive, and logic and application were clear.
• Extensible. It is perceived that the architecture, programmed with design patterns respecting the different proposed modules, could easily be extended.

The development team have perceived the correctness of the methodology. Moreover, the feasibility of the methodology has been tested with the implementation and the case study presented in this paper. The goal that this could be mapped to a real software and be used by real people is a proof of the concept of the different principles introduced in the method and proves the feasibility of the method through the implementation. Therefore, we can monitor and control electrical consumption in a household context, even without devices with connection to the internet.

The users of the system, of course, do not prove whether the reality or electrical consumption will change massively; however, tests were conducted to obtain some approximation of how people would perceive and estimate the benefits of the method. In a first pilot of the experiment, the participants were required to design a user interface in which they could define the electrical devices they have at home. In our experiment, we targeted prospective users; electrical consumption awareness is in the interest of anyone who is using electricity and is part of a group of people living in the same location. The unique condition was that they did not have any prior experience with any similar system. Therefore, the sample of participants was large and diverse. Ten participants were presented our graphical user interface and evaluated with IBM CSUQ [48] as usability measurements.

To better understand the interpretation of the data, it is necessary to remember the evaluation criteria are:

• Evaluation below 4, on average, is not satisfactory
• Evaluations between 4 and 5, on average, are moderately satisfactory
• Evaluations between 5 and 6, on average, whose minimum does not fall short of 4, are considered good, although they can improve
• Evaluations between 6 and 7, on average, are in the best condition and likely have little to improve.

In general, in Figure 10 the results are displayed, the platform developed is perceived as acceptable (6 global average) by most users. To interpret what it means we must go into the details of each group of questions. In the first instance, the first block of questions (1–8) analyzes the quality of the system in the functional sense, “It solves or not my needs and I feel satisfied”, from any point of view, globally or by a particular group of users; this is the criterion that has the 5.8, so the functionality of the system is quite acceptable. The second block of questions refers to the quality of messages, texts, and all kinds of written language present on the platform. This item was also perceived as acceptable in general (4.5). However, this block of questions reflects what is interpreted as the most significant usability problem of the platform. It can be summarized as the lack of feedback in any modality, visual or auditory, on the actions that the user is executing on the platform. Feedback is defined as the mechanism used to communicate the result of an action to users. It can involve using any sensory channel (auditory, visual, tactile). Finally, the analysis of the User Interface (questions 16–17) is presented, with a value of 6, which is the highest criterion evaluated by users. Design is everything in our proposal and this was well perceived and accepted by users. Our feeling is that we need to improve the way we communicate information in order to get a better value when asking users about using the platform in the future.

6. Conclusions

In this work we have presented the development of a software for an electrical demand system. Related work teaches us that current solutions around this problem focus on developing applications that serve to provide the user with the necessary information so that the user can observe the way in which they are carrying out their electrical consumption and its economic effects. The absence of a general scheme for the development of a system that proposes a methodology stating the part that makes up a total and complete system has been identified, since the current solutions around the development of software for an electricity demand system focus on the data processing and show little by way of the interactive application that can be used by any user.

The design of the application and its process is carried out with the co-design technique and is supported by known techniques of analysis and user experience design. The prototype proposal was evaluated with a convenience sample, and the final decision gives us a clue as to what the interactive system should look like that will help people to take decisions regarding their electricity consumption, the way in which they can design spaces or scenarios such as houses´ rooms. Much has been discussed about how to communicate this information and we found that the solution must go beyond the sketches; however, without a list of devices, a common solution in most device apps is far from being an adequate solution.

The problem can be formalized through a mathematical model that explains the way in which electricity consumption occurs and can be replicated in other contexts. Likewise, the methodology of electricity analysis allows for the defining of a strategy for solving problems with similar characteristics.

The taxonomy of electrical devices can be determined according to the way in which they operate, and they are classified as interruptible, non-interruptible, flexible, and non-flexible. The device management descriptors are the average time of use, average consumption, minimum and maximum consumption, if the device can be turned off, and its taxonomy. The electrical variable can be defined from the taxonomy, the time of use, and its range of electrical consumption.

To capture human behavior in an electricity consumption analysis system requires the identification of the devices´ taxonomy in their context of use. Moreover, to make the mathematics modeling in the process of electricity consumption and to make use of the devices’ distribution functions of use to simulate usage and consumption profiles, the identification of the parameters that shape the electrical variables is required.

Further work that needs to be carried out includes the development of a multi-user application with security and authentication protocols for entering it, as well as the implementation of analysis techniques that include environmental factors and the ability to perform data analysis in real time. All of this is needed to control the devices identified in the context.