DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc ¸ alo Nuno de Brito Galado da Costa Grazina Thesis to obtain the Master of Science Degree in Telecommunications and Informatics Engineering Supervisor: Prof. Paulo Jorge Pires Ferreira Examination Committee Chairperson: Prof. Rui Jorge Morais Tomaz Valadas Supervisor: Prof. Paulo Jorge Pires Ferreira Member of the Committee: Prof. Ricardo Jorge Feliciano Lopes Pereira November 2016
94
Embed
DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
DroidEnergy - Detecting and Alerting Users of PowerSupply Failures
Goncalo Nuno de Brito Galado da Costa Grazina
Thesis to obtain the Master of Science Degree in
Telecommunications and Informatics Engineering
Supervisor: Prof. Paulo Jorge Pires Ferreira
Examination Committee
Chairperson: Prof. Rui Jorge Morais Tomaz ValadasSupervisor: Prof. Paulo Jorge Pires Ferreira
Member of the Committee: Prof. Ricardo Jorge Feliciano Lopes Pereira
November 2016
Acknowledgments
To Professor Paulo Ferreira a sincere thank you for supervising this work and sharing his knowledge
with me.
To my parents for all the support during the difficult times we passed. They are proof that anyone
can overcome difficulties if surrounded by the ones we love and care for us. I hope I make you proud.
To my grandparents Antonio, Lino and Alda for giving me good memories that I will always keep in
my heart. Although you can not be here physically, I know you are watching and enjoying this moment
with me.
To my sweet little goddaughter Mariana, my brother Marcos, Joao Miguel, Leonel, Gilda, Joao Paulo
and uncle Helder for also being part of my life.
To my girlfriend Ines for giving me the motivation to finish this work and never doubting that I could
do it. For making me a better person each day and supporting my decisions. For listening, supporting
and making me as happy as I have never been. I hope you are as proud of me as I am of you.
A special thank you to my grandmother Mariana for teaching me one of the most beautiful qualities
a person can have: helping others without asking something in return. For being part of my life and for
being one of my best friends, for making me go from being upset to start laughing with only a smile.
All of you are part of this and I can not thank you enough.
Abstract
In a society where the number and variety of in-house technological devices continues to increase,
some of these devices can not tolerate long power supply failures an require its user to be warned.
For instance, a power loss of more than a couple of hours may spoil the food in the refrigerator, or
the video surveillance system may become unusable. Currently, existing solutions either provide only a
limited outages monitoring (on or off), or are specific products connected to a cloud server that can be
scheduled to activate/deactivate outlets and provide a limited set of configurations. The goal of this work
is to develop a system that is able to detect power supply failures, their duration, and alert the user of
such events according to a flexible range of configurations. The proposed solution, called DroidEnergy,
is a smartphone application (along with a server for back-office purposes) that is plugged into an electric
outlet, and is able to detect outages and alert users. DroidEnergy has several easy to configure features,
e.g. alerting the user via e-mail or Short Message Service (SMS), can be configured remotely or locally,
creating a highly configurable system. Furthermore, we describe the solution design options, as well as
the challenges to overcome in order to validate the proposed solution.
Keywords
Outage detection; Android; Home Automation; User alert.
iii
Resumo
Numa sociedade em que o numero de dispositivos electronicos aumenta cada vez mais, muitos destes
dispositivos nao toleram falhas de energia prolongadas. Por exemplo, uma falha de energia com uma
duracao superior a duas horas podera estragar a comida dentro de um frigorıfico ou um sistema de
videovigilancia podera ficar inutilizavel. Actualmente as solucoes que tentam tratar esta problematica
apenas oferecem um leque limitado de monitorizacao e controlo de dispositivos electronicos ou sao
produtos proprietarios que se ligam a um servidor na nuvem e em que podem ser programados para
activar/desactivar tomadas eletricas. O objectivo deste trabalho passa por desenvolver e avaliar um sis-
tema que seja capaz de detectar e monitorizar falhas de energia, de avisar os utilizadores da ocorrencia
destes eventos, atraves de SMS ou e-mail, e que ofereca um conjunto de configuracoes flexıveis para
que o utilizador o possa configurar de acordo com as suas preferencias. A solucao proposta, chamada
DroidEnergy, e um sistema composto por uma aplicacao desenvolvida em Android e por um servidor
web para funcoes de back-office, em que apenas e necessario ligar o telemovel a qualquer tomada
electrica. Para alem disso o utilizador podera configurar varias caracterıstica de forma facil e rapida,
tanto directamente no telemovel como tambem atraves de uma pagina web. Por fim, descrevemos o
desenho e implementacao da aplicacao, assim como os desafios que terao de ser ultrapassados de
modo a que o solucao seja validada.
Palavras Chave
Deteccao de falhas de energia; Android; Automacao; Alerta ao utilizador
There is vast literature regarding energy-efficient mechanisms and power management in smart envi-
ronments. Most works are focused in energy monitoring in order to provide suggestions to the users
regarding energy efficient mechanisms to save or optimize their home electrical consumption. Other
research works focus on providing comfort to users by enabling them to have control over their devices
or to have the devices auto adjusting their settings according to the user’s preferences. The interest in
this topic and the ever-growing digital services world extended the smart devices offer and consequently
let to the reduction of their price. In this section we review relevant literature that addresses this topic.
We divide this chapter in three sections where in Section 2.1 we introduce basic concepts of our work,
in Section 2.2 we review existing solutions in home automation approaches. In Section 2.3 we present
an overview of technologies that exist to tackle our or similar problems and in Section 2.4 we discuss
the several solutions presented and explain why they do not meet the requirements defined previously.
2.1 Basic Concepts
In this section we present some basic concepts related with the field of our work that are important to
understand the related work addressed in Section 2.3.
2.1.1 Uninterruptible Power Supply (UPS)
An Uninterruptible Power Supply (UPS) consists of an electrical equipment that provides emergency
power from batteries in unexpected power supply failures. This is typically used to protect computers,
data centers, telecommunication equipment or other electrical equipment where unexpected power out-
age could disturb businesses or cause data loss [8]. In data centers UPSes are also used to supply
power while an automatic transfer switch (ATS) selects the source of power [9], which takes about 10-20
seconds [10].
2.1.2 Smart Meters
Smart Meters are metering devices embedded in systems such as electrical meters [11]. When com-
pared to the conventional electrical meters, they offer a large array of new functionalities such as remote
readout of data measurement and provide the user with the current energy consumption. Also, when
used to support eletric smart grids, energy providers can use the gathered data to automatically adjust
the amount of produced energy according to the demand [11].
7
2.1.3 Advanced Metering Infrastructure (AMI)
An AMI consists of one or more smart meters, communication technology, meter data management and
associated software and hardware [12]. It is viewed as a fundamental component of the smart grid
because it provides a two-way communication network between utility companies and a set of smart
meters at the customer side [13,14].
Figure 2.1 shows the four blocks that compose an AMI. The first block represents the smart meters
on the costumer side, that are responsible for collecting consumption data such as electrical, water or
gas usage. The second block represents the communication layer, where the raw data collected by the
smart meters is securely sent to an AMI Host (third block). This block is the server that controls all the
communications between the company and the customer side. The last block represents the Meter Data
Management System (MDMS) who is responsible for filtering the extensive raw data that was collected
in order to extract the relevant information.
Figure 2.1: AMI Building Blocks [1]
The deployment of AMI has several associated benefits, such as reducing the meter reads, provid-
ing higher accuracy in meter readings, providing statistical information of outages, providing the user
with better power profiles according to his energy usage and helping in the reduction of utility costs
that companies have with equipment and maintenance [1]. It can also be used with conjunction with
Home Automation Systems (HAS) to provide adjustments in the electrical devices according to the user
preferences via context-awareness, activity recognition or proactive interaction [15].
2.2 Energy Monitoring at Home
In recent years the number of devices in our homes has increased significantly. With this increase,
the users want agile ways of operating, connecting and controlling the state of the devices. In 1984,
8
the National Association of Home Builders (NAHB) introduced the concept of a “smart house” where a
system would control automatically or manually various functions in the house, such as turning on/off
a light based on daylight, therefore offering interoperability between devices [2]. The concept was later
materialized into HAS. HAS connects the “smart devices” in a house with the objective of providing
comfort to users in a ubiquitous way.
With the functionality increase offered by HAS and consequent escalation of energy consumption,
researchers started focusing more in energy efficient solutions. One interesting fact is that HAS are
not only the cause of energy consumption increase as they are also a solution. In 2002, Banerjee et.
al inquired a user about the performance of his solar panel installation to which the user responded
that he monitored the reading manually [16]. Later on, technologies such as WattsUpMeter [17] and
Android@Home as well as services such as Google PowerMeter or Microsoft Hohm began the process
of providing users access to raw data. Monitoring systems, capable of analyzing the raw data, can have
a high impact in lowering the energy consumption by creating profiles and presenting it to the user in
a human readable format. Dobson [18] and Chetty’s [19] research has shown that granting the user
visibility into the energy consumption can reduce the electricity usage in 5-20% [20]. These monitoring
systems, based in data collected from smart meters, can be further integrated with AMI in order to create
a power system capable of automatically diagnose, monitor and repair a smart grid [12]. Nezhad et.
al [5] propose SmartD, a easy to use and to extend dashboard to visualize and analyze data gathered by
smart meters. Based on GNS middleware [21] it can be integrated with almost every existing smart meter
to provide real-time readings. By being capable of analyzing the gathered data according to different
contexts, it provides the user with visualization of different power consumption profiles according to
temporal aggregations and consumer segments. Being a smart meter ”aggregation” system, it requires
the installation of smart meters throughout the house which can prove to be expensive. More recently
Apple launched an iOS application is serves as a gateway for smart devices such as wireless light bulbs.
Although the amount of research work in this subject is high, houses that use AMI are still only a few.
The three main factors that cause this low “acceptance” are the costs of installation, learning of user’s
preferences that do not fully fulfill their needs and the wide range of customization that research solutions
offer [15].
Banerjee et. al [16] propose a monitoring station which makes energy recommendations in order to
lower consumption based on the energy profile of the house. The recommendation system can advise
users of when to use high-power applications or how to minimize the energy waste. Although the solution
is capable of monitoring energy consumption and detected power outages, the main goal is to provide
energy efficient suggestions to the user. It also requires additional equipment, increase the installation
complexity.
Although the primary focus of energy management research is monitoring, controlling the electronic
9
devices is also an important step towards power efficiency. Some research works propose systems
based on the ZigBee technology that are able to turn off power outlets when the maximum power load is
reached [22,23], but they do not offer real time control over the devices. Zigbee is a mesh network which
uses low-power digital radios to allow control and monitoring over appliances such as light switches
[24]. Its power consumption is lower when compared to system based in Bluetooth and Wi-Fi which
represents a long battery life and therefore relieves the burden of having failures in the system due to
the need of battery replacement. Han et. al [25] propose a remote-controllable and energy-saving room
architecture that provides the user with a way to control the state of the power outlets using a hand held
device.
Another way to manage and adjust the appliances is to use policies. Policies are a set of rules that
can be used to define user preferences on various electrical devices and based on these preferences,
adjust the state of the devices and resolve possible conflicts [26]. They can also be used to describe
device behavior according to the energy usage. For instance Kaliappan et. al [27] propose a policy
based framework which can be used to control the state of electrical devices based on the current
energy consumption and the amount of devices that are being used. Most the policy based research
work has the objective of defining a framework which permits the gateway to aggregate the device’s
information and use this information to adjust the device properties according to the defined policies.
One characteristic that is common to most research works is that the smart devices must be config-
ured individually. Although this may be relatively easy to do in a smaller environment, if we consider a
house closer to a fully smart environment in terms of the number of devices, this may pose as a burden.
Regarding this potential problem there are three types of approaches. The first one is a centralized
approach where the power consumption is analyzed and disaggregate to identify each electrical appli-
ance [28–31]. This approach can be useful to minimize the number of sensors, since it only needs a
centralized one, although it may have problems when detecting low-power appliances [32]. One of the
contributions that uses a centralized approach was made by Englert et. al, which developed an approach
that permits the building to receive information of the electrical appliances regarding their presence and
activity [33]. Their solution consists in sampling the alternate voltage and current signals and running
the samples through a machine learning algorithm, which predicts what type of electrical appliance the
samples correspond to.
Another approach is to measure the power consumption at appliance level. This can be achieved by
using a wireless mesh network such as Zigbee, ACme [34], where each appliance has a sensor which
sends the power consumption reading to the gateway. For instance, Kim et. al propose ViridiScope, a
power monitoring system that uses several non-intrusive sensors to identify the appliances [35]. This
design reduces the need to re-wire the devices since the sensors are placed near the devices and have
different types, such as light intensity, microphones and magnetometers. For instance, by using a light
10
intensity sensor near a refrigerator, the sensor can determine if the refrigerator is open since the light
inside it turns on when the door is opened.
The last approach is using electrical devices that already have network capabilities. These appli-
ances can then be aggregated in a common smartphone or web based application to send information
regarding their state and, if possible, allow control over themselves. In the last years these appliances,
such as remote-controlled outlets or lamp dimmers, have emerged at a relatively low price. These three
types of solutions can have a high impact in the deployment of fully equipped smart houses by reducing
the complexity of the configuring all the devices and the price of installation.
Security is also a concern when developing automation systems, since the gathered information can
have information regarding the electronic devices of a house and private user information. Fuchs et.
al [11] introduced the formal model of a system for transmission of measurement gathered by smart
meters based on the Security Modeling Framework (SeMF) [36]. The model defines a secure and
trustworthy way of specifying the security requirements that need to be considered in a metering system.
2.3 Technologies
In this section we refer to power backup products (Section 2.3.1) and in Section 2.3.2 we present Home
Automation solutions that are related with this research work. We describe the various solutions ac-
cording to our requirements, in order to make a proper comparison between them and the proposed
solution.
2.3.1 Power backup solutions
Regarding power supply failures there are products in the market that are able to provide backup power
during a small amount of time. Most of the products already have the ability of detecting power outages
and automatically switch the house power supply to the secondary supplier.
No Outage [37] offers some home backup systems. Their House UPS System is fully automatic
in power switching when an outage is detected, provides an estimated running time up to 10 hours,
depending on the powered devices, and the total cost of the product plus installation varies from $2,000
to $3,000.
Automatic Standby Generator & Automatic Transfer Switch (ASG) solutions consists in a diesel gen-
erator with a fully automatic Transfer Switch that does not require user intervention. Since it runs of fuel it
can operate for days or even weeks and has an estimated cost between $5,000 and $10,000 depending
on the size of the generator.
Portable Generator with Manual Transfer Switch (PG) solutions consist in a portable generator that
requires manual intervention to switch between power sources. The time delay caused by the manual
11
switching varies from 15 to 45 minutes, the product installation cost varies between $1,000 and $3,000
and permits a run time from 3 to 8 hours, also depending on the devices that are supplied during the
outage.
The first and second solutions have the ability of detecting the power supply failures and are able to
supply some electrical appliances in the house for an extensive period of time, but their price is extremely
high and they are not able to alert a user if he is not present, which are requirements of our solution, as
stated in Section 1.2.
2.3.2 Home Automation
Klugman et. al [38] propose GridWatch, one of the most similar solutions to our work. Their solution was
developed based on the idea that by using a everyday device, such as a smartphone, users can have
a better understanding of the power conditions and energy usage without the need of utility companies.
In addition, the solution does not require the installation of smart meters, lowering the complexity and
cost of implementation. Using the sensors of the smartphone to analyze the power states while the
smartphone is charging, their solution can retrieve information of power outages, such as GPS location
of the outage and duration time. The results of the evaluation show that the prototype can detect power
outages with high accuracy. The main constraints in using GridWatch are that it does not allow remote
access or alerts users when an outage occurs. Another limitation is that it required a large community
to fully function as expected, since the main purpose is to present information based on a large set of
retrieved data.
Chacon [39] has a simple energy meter product that is able to measure in real-time the energy
consumption of an electrical device or household. By using this solution a user can determine which
actions have a higher impact in power consumption and therefore build a more energy efficient profile.
They also have a Wi-Fi smart plug which can be controlled by an Android and iOS application. Although
it can detect power outages, the objective of the first product is only to monitor the electrical events. The
smart plug can not monitor outages but it may be possible to detect outages. If the user tries to connect
to the plug and it fails there are two possible explanations, (i) an outage occurred and (ii) there was a
problem with the plug. The main limitation is that the user can not know if an outage occurred without
interacting with the application, which would probably not occur very often.
HomeSeer [40] has several products in home automation controllers. The controllers can be used to
control or monitor almost every appliance in the house such as light switches, thermostats, door locks
and so on. The system is configurable through a web or smartphone application and offers an heavy set
of possible configurations according to the user‘s intents. The price of the controllers vary from $199.95
to $1,199.95 plus the price of each sensor the user wishes to acquire, which can prove to be very
costly when installing a monitoring system. While HomeSeer‘s products offer a wide range of features in
12
monitoring, the devices require a constant power supply, therefore being unable to detect power outage.
Luan et. al [12] implemented a ZigBee-based smart power meter to measure detailed power con-
sumption, register outage event data and send the data to a processing system. By using ZigBee, the
gathered data from smart meters can be wirelessly sent to the processing system, reducing the instal-
lation complexity, since there is no need of re-wiring the electrical devices. Since it depends on smart
meter deployment, the cost of implementing this system can prove to be high and the feature of alerting
users is not guaranteed.
Patel et al. [28] presents an approach that uses a single sensor that monitors the electrical noise
made by electrical applicants in order to recognize a variety of events. Apart from the sensor this
approach only requires a computer to collect and analyze the incoming electrical noise. This approach
was influenced by PowerLine Positioning System [41], where the detection of electrical events is based
on the electrical noise in the power line made by the switching of electrical devices. Although this solution
is able to detect several electrical events, it requires special equipment. Furthermore the system must
be handled locally and can not provide the results remotely.
Banerjee et. al [16] proposes a monitoring station which makes energy recommendations in order to
lower consumption based on the energy profile of the house. The recommendation system can advise
users of when to use high-power applications or how to minimize the energy waste. Although the solution
is capable of monitoring energy consumption and detected power outages, the main goal is to provide
energy efficient suggestions to the user. It also requires additional equipment, increase the installation
complexity.
De Russis et. al [15] developed a prototype of a smart watch application that is able to communicate
with an AMI environment. The objective of this work is to be able to react to suggestions, such as
disconnecting a certain device according to the current energy consumption or alerting the user that
a device may have a power supply problem, made by the AMI environment without direct interaction
with the devices. Most, or probably all current wrist smart devices include the requirements of the wrist
device the authors defined in 2013, while most low specification devices are in the price range defined
(between 25 and 50$). The main limitations of this prototype are that the message queue is limited
to two messages and that the device uses Bluetooth or SimpliciTI protocols, therefore, it is unable to
receive alerts or interact with the system when the user is not at home.
Das et. al [42] propose an Android application to manage electrical devices using Zigbee. The
application provides both speech recognition and touch commands to control the relays connected to
the devices so they can be switch ON/OFF, as well as statistical information such as power consumption.
The state of the devices is stored in a database present at the server. The server is connected to
the Zigbee components (transmitter and receiver). The receiver reads the state of a micro controller
connected to each device and sends it to the server via the transmitter. To interact with the devices the
13
application connects to the server and retrieves the database information. Every command sent follows
the opposite path describe before, i.e. application→ server→Zigbee transmitter→Zigbee receiver→
micro controller. The authors do not refer to outage detection although it may be possible, since the
database reads the state of each appliance. But if the server is connected to a local router, the smart
phone will not be able to connect to the server. This can be assume to be an outage or it can be a failure
in the PC running the server or in any other component. Furthermore this implementation requires
components that can be expensive depending on the number of appliances the user wants to monitor
and does not provide a way to alert the users of the occurrence of the outage.
Weng et. al [43] propose a management system to control and analyze power consumption in
buildings. It is divided in three different software services, (i) DataService (DS) responsible for storing
the data retrieved from sensors and make it accessible via several interfaces; (ii) CentralService which
stores the building and user information; (iii) ApplicationService which is a server that offers a library
to facilitate the development of applications that use or interact with the system. By using well defined
templates for the sensors and the building they define a common language and therefore, simplify the
interaction and implementation of the system.
These approaches ensure that every user is able to adapt the configurations to fit his preferences and
that each electrical device can be monitored and controlled without direct interaction. Their results show
that the development of such systems is viable and can be applied to every room in a home, however it
may be extremely complex to implement since it requires the installation of sensors in the devices and
connect the sensors to a gateway which is the entity that controls/monitors the devices. Furthermore
they are more focused in the energy management and some fail to include the outage detection and
monitoring in their solutions.
2.4 Summary
The previous sections present related work that cover the research fields in which we believe our solution
is enclosed. However, the presented solutions do not cover all of the requirements we define in Section
1.2 and some of them do not aim for our main objective, which is to detect power supply failures and
notify the users, but they are still presented because they are related to our research. Table 2.1 presents
an overview of the solutions described in the previous sections, according to the requirements we define
in this research work. The requirements presented in Table 2.1 are defined as follow:
• Cost - Represents the estimated cost of the solution. Not applicable if the solution does not have
a retail price.
• Detection - Is the solution capable of detecting power supply failures and reestablishments?
14
• Configurable - Is the solution highly configurable?
• Notifications - Can the solution notify the user? Not applicable if information regarding the notifi-
cations is not present
Table 2.1: Comparison between the presented solutions according to the objectives
System Cost Detection Configurable Notifications
No Outage UPSSystem [37] $2,000 - $3,000 Yes No N/A
ASG $5,000 - $10,000 Yes No N/A
PG $1,000 - $3,000 Yes No N/A
GridWatch [38] No information 1 Yes No N/A
Chacon [39] ' $30 Yes No No
HomeSeer [40] $199.95 -$1,199.95 No Yes Yes
At the Flick of aSwitch [41] No information Yes Yes N/A
Smart PowerMeter [12] No information Yes No N/A
Android Zigbeenetwork [42] No information 2 No Yes No
Wrist homecontroller [15] $58 3 No Yes No
BuildingDepot2.0 [43] No information No Yes No
1 (Used) Price range from $60.98 to $160.95 according to the phones used for evaluatingthe solution
2 There is limited information in what components were used. The price of the Zigbee’scomponents is around $40 and the current transformer is around $3
3 Based on the watch used by the authors (Texas EZ430-CHRONOS)
As mentioned before and as we can see in Table 2.1, none of the solutions presented fulfill all the
requirements we described in Section 1.2. GridWatch [38] is close to our objective, but it does not cover
all the requirements since it was developed with the objective of categorizing the power grid conditions to
provide data regarding the power grid. Furthermore it is not able to alert a user without direct interaction
with the application. At the Flick of a Switch [28] is also very similar to our solution since it is able to
detect power outages, but its primary objective is to identify certain electrical events, such as turning
on or off a television by analyzing the electrical noise. Smart plugs can also be used to detect outages
but similar to the previous solutions, to accomplish that goal, they depend on constant interaction by the
15
user, meaning that an outage can go unnoticed if the user does not check regularly the electrical state
of the house. As such the solution we propose is the only that is able to detect power supply failures,
can be highly configurable and can notify a user by e-mail/SMS.
In the previous chapter, we introduce the problem we are aiming to solve and present related work. In this
chapter we analyze the solution requirements and introduce the architecture of the solution we propose,
DroidEnery. In Section 3.1 we present the detailed system overview. In Section 3.3 we introduce the
skeleton of the algorithm that is used to detect and monitor power outages. In Section 3.4 we describe
which configurations the user can make and how he can adjust them according to his preferences.
3.1 System overview
This section presents a global view of DroidEnergy’s architecture. DroidEnergy is a system that detects
power outages and alerts the users of these events using a smartphone. It is divided in two major com-
ponents, a smartphone application and a web server. Figure 3.1 shows a global view of the proposed
solution. Most houses have an electrical installation that uses a single electrical switchboard to power
all the appliances. Figure 3.1 not only shows the architecture of the system but also represents the
general electrical infrastructure of a house. By inference and by excluding the cases where the appli-
ances are faulty, if the electrical switchboard is unable to power the appliances, an outage occurs. The
smartphone running DroidEnergy connects to any power outlet in the house and detects the outage by
using its charging state. While most solutions presented in Section 2.3 require additional wiring in the
infrastructure or more complex system, our solution takes advantage of the house electrical infrastruc-
ture to reduce the complexity and cost of installation since it does not require re-wiring or any additional
component.
As we previously explained, the smartphone running the application must be connected to a power
outlet. This power outlet can be one of two possibilities, a (i) common wall socket or an (ii) extension
cord. To obtain better results, it is suggested that the smartphone is plugged directly into the wall
socket to prevent other points of failures. It should also be connected to the local internet router and
have a cellular internet connection. The local Wi-Fi or wired network provide remote access to system
configurations via a web server. When an outage occurs, it is almost certain that the local network will
also be affected by the outage. When this occurs the application uses the mobile connection to send
any alerts, since this connection is usually not affected.
The application requires an initial configuration where the user adds his home devices and what kind
of alerts he wants to receive. He also should set his e-mail account which is used to send any e-mail
alerts, the phone number to which the application should send SMS alerts and create a web server
account which is used to access the configurations remotely.
The system can detect power outages by monitoring the charging state of the smartphone. When
this occurs it starts monitoring the outage. At this point the system can immediately alert the user that
an electrical event was detected. It continues to check if any device has been out of power for longer
19
than its corresponding time. Furthermore, when the outage ends, another alert can be sent to notify the
user of such electrical event.
The user can access the configurations directly on the phone or via a web server, which is not
available during an outage. Besides the configurations, the web server also has statistical information,
e.g. frequency of detected outages in the last year and their duration.
Figure 3.1: Solution overview
3.2 Application components
The software architecture of DroidEnergy is divided in five modules. Figure 3.2 shows the application
modules of DroidEnergy. It is divided in five main modules which control the base operation of the
application.
The activities of the application represent the screens where the user can perform actions and where
the information is presented. The main activity is where battery and charging information is presented.
The location activity is where the user can add house areas and corresponding devices. The third activity
is the preferences menu. Here the user can set all the necessary configurations for the application
to correctly monitor the power outages. These configurations include, e.g. setting the type of alert to
receive, configuring the e-mail properties, adding house areas and corresponding devices. For instance,
a simple set of configurations can be (i) choosing to be alerted on outage detection after five minutes,
20
(ii) choosing to be alerted via e-mail and (iii) adding the e-mail credentials. Additional configurations
include setting e.g. the web server port or setting the web server account list.
Figure 3.2: DroidEnergy application components
The web server is the component of the solution which provides all the configurations in a remote
environment. For this remote access to work there are additional configurations to make. Besides being
responsible for controlling the private network in the house, the local area router also has a public
Internet Protocol (IP) which can be used to make requests from outside the Local Area Network (LAN).
If even the user is not at home, he is able to make requests to the router, but the router needs to be
configured to port forward these requests to the receiver. The first step is to configure a static IP on
the phone. Most of the existing Operating Systems (OS) already allow this change. The second step
is to create a rule in which the user specifies the receiver port and protocol. For instance, to forward
the TCP/UDP requests to the port 8000, the user creates a rule where he indicates that every request
made to <public IP , 8000 > should be translated to the local IP 192.168.1.80:8000. Furthermore, every
action the user takes in the web server is communicated to the data storage via a web interface. This
interface converts the request into an application specific format. This way we are able to reuse the
existing implementation instead of creating a complete set of new actions for the web server calls with a
different format.
In the web server the information is divided in four pages. The home page is where the user can
check the charging and battery state of the smartphone. The second page is where the user can view,
add or remove any devices configured in the application. The third page presents all the configurations
of the application. These are divided in the same way as in the smartphone and every configuration
presented can be changed. The last page in where it presents the statistical information that is gathered
during an outage.
The broadcast receivers are components that react to special events, such as changes in the battery
charging state. They are registered throughout the application and can react to the events independently
21
of the activity where the user is. One of these receivers is the EnergyReceiver. This receiver reacts to
the connection/disconnection of the AC charger and determines if the monitoring services should be
started/stopped. The services include the outage and reestablishment services. The outage service is
used to count the current outage time and check if the user should be alerted for any of the configured
devices. It is also responsible for saving the outage information in the database when the outage ends.
The reestablishment service is only called if the user chooses to be alerted on reestablishment detection.
When an outage ends, the service reads the time set by the user for this alert and starts counting the
time until it reaches zero, sending the alert after.
The LoggerReceiver is responsible for writing and reading the log file. This log is written every time a
change is detected, such as adding a new device, or when an alert is sent. Furthermore the log file can
be exported via e-mail. The SMSReceiver is responsible for activating/deactivating the web server. The
user has an option in the web server configurations to enable this feature. While this feature is active the
user can send an SMS to the phone running the system to enable or disable the web server. The last
receiver is the InternetConnectionReceiver. When the system can not send an alert due to an internet
connection problem, it stores the alert. When the connection is available, it sends the stored alerts.
The last components are the alerts. These correspond to the type of alert an user wants to receive
and are associated with a time. Basically, this time is used by the system to determine when to alert the
user after the corresponding electrical event is detected. There are three types of alerts:
• Alert on Outage (AoO) - alerts the user if an outage has occurred and if the current outage time
exceeds the time set on this alert configuration;
• Check Devices (CD) - during the outage checks if the current outage time exceeds the time con-
figured for each device;
• Alert on Reestablishment (AoR) - alerts the user when the outage ends, after a pre-specified time
has passed.
In the case of the AoO and AoR alerts, if the user does not specify a time, the system will notify him
of the corresponding alert as soon as it is detected. In the other case, the time is used to determine
when to check if any of the devices are affected. For instance, if the user sets this time to 10 minutes,
the system will check every 10 minutes if any devices are affected.
The persistent data is stored in files and in a database. Figure 3.3 shows the database model
DroidEnergy uses to store part of the persistent data. As we can see, there are four classes where the
Location and Devices are related. Although we could have opted for a relation model where Device had
a foreign key location, the amount of entries in the Device table does not require a relation between
the two tables. The other two classes represent the Outage table where the application stores all the
22
Figure 3.3: Database class UML
information regarding the outage monitoring and the web server user table where the accounts to access
the web server are stored.
3.3 Algorithm overview
The solution we propose includes an algorithm which continuously monitors the charging state of the
smartphone. When it detects that the smartphone stopped charging, it starts the monitoring phase.
During this phase it verifies if an alert should be sent according to the application configurations. Figure
3.4 illustrates the state machine diagram that represents the functionality of DroidEnergy. The states and
functions of the diagram are defined in Table 3.1. Prior to start using the system, the user configures it
by choosing which kind of alerts he wants to receive (refer to Section 3.2).
The smartphone exposes the current state of charging to DroidEnergy, which can be of two types:
charging and not charging. As we can see in Figure 3.4 when the charge state is not charging, DroidEn-
ergy deploys a Sentinel. The Sentinel is responsible for launching the timers according to the battery
state and for sending the alerts and logging the registered activity. If the user chooses to monitor the
devices CD, DroidEnergy checks if the current outage time exceeds the time set by the user for each
device. If it does, the Sentinel sends an alert to the user, which contains information regarding the out-
age time of occurrence, the current outage time and which devices were affected. If none of the devices
23
Figure 3.4: Machine state diagram representation of the proposed solution
are affected, this verification is delayed for a pre-specified time (by default 5 minutes) to minimize the
impact in battery duration. If the local router is not accessible, since it may be affected by the outage,
and the user chose to receive alerts by e-mail the Sentinel sends the alert using the cellular network if it
is available. If none of the internet connections are available, the Sentinel stores the alert and sends it
when one of the connections become available. When the power is reestablished, the user can also be
alerted. The system retrieves the information of the outage (duration, devices affected, alerts sent) and
stores this data persistently, to build statistical information, which can be visualized in the web server.
3.4 User configurations
Since one of the objectives of this work is to provide a wide set of configurations on the application, the
user can change almost every aspect of the application to fit his needs. These configurations can be
made directly on the phone or via the web server.
The objective of the web server is to provide a way to configure the system without direct interaction
with it, which is particularly useful if the user is not at home. Since Windows, Android and Apple phones
already have the option to set up a static IP on their smartphones, we decided to only provide the con-
24
Table 3.1: Description of each class and function in our solution
Class DescriptionSentinel Responsible for deploying the monitoring tools
Device Home device (e.g. refrigerator, dryer) which contains informationabout the device (e.g name)
Function Description
Deploy Sentinel When an outage is detected, the system deploys a sentinel, thatwill monitor the outage
Power On? Verifies if the smartphone is chargingSend Reestablishment
Alert?Verifies if the user chose to receive an alert when the outageends
Alert Type? Verifies which kind of alerts the user wants to receive.
Alerts can have two types:[alert on outage] - if the user chose to be notified when an outageoccurs;[check devices] - if the user chose to monitor the devices.
Check Devices Retrieves the device list and for each device checks if corre-sponding time was exceeded by the outage time
Send Alert Sends an alert to the user with information about the occurrenceof the outage and the devices affected
On success, this function sends a message according tothe alert type:[reestab. alert sent] - outage ended, go back to battery monitor;[outage alert sent] - continue to monitor the outage;[device alert sent] - same as above.
Sleep Sentinel sleeps for a defined amount of time too emulate a real-time system
Log Changes Logs the outage event, the devices affected and alerts sent
figuration of the port in which the web server is listening for requests (port 80 by default). Nevertheless,
the user still needs to assign a static IP address to the smartphone and port forward the requests made
to the public IP of the LAN router to the smartphone IP and server port. One important aspect to notice
is when the outage occurs, if the device can not access the Local Area Networks (LANs) in which it has
registered, the web server is not available.
As previously stated (see 3.3) there are three different alerts. While the time set for the AoO and
AoR alerts is used to send an alert after the time is exceeded, the time set in the CD configuration is
different. It is the frequency used by DroidEnergy to check if any devices are affected by the outage and
send the corresponding alert. The user can change these alerts anytime, even during an outage. This is
particularly important for the device configuration, since the user may want to adjust the corresponding
timer during an outage.
The alerts can be sent via SMS or e-mail, or both. The user may specify a different e-mail account
25
from the sign in account to send the e-mail alerts. We chose this configuration option since some e-mail
SMTP servers block e-mail accounts that generate too many messages. To receive the alerts via SMS,
the user only needs to input the recipient phone number, although the smartphone running DroidEnergy
requires a Subscriber Identification Module (SIM) card to properly function with this option.
The user can also enable the system to collect information about the electrical events such as number
of outage occurrences, the mean time of an outage, the average of devices affected, among others.
This information can be visualized in the application but it is more detailed in the web server since it is
18 ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
19 activityManager.getMemoryInfo(memoryInfo);
20 return memoryInfo;
21 }
To determine the threshold for each of the devices in Table 5.1 we made two slight modifications to
the application. The first one was to add the snippet code explained previously. We then launched the
application in each device and retrieved the following information.
53
Table 5.2: Comparison between the available memory in both devices
Devices
White-branded phone Nexus 6
Total 1 468 2968
Available 1 133 2186
Heap size 1 96 256
Threshold 1 56 1441 In MB
As expected the heap size and threshold are higher in the Nexus, since it has six times more RAM
that the other device. These values are used to determine if the RAM usage of the application is in the
accepted value range and that memory problems will not occur during the application life cycle.
The second modification was to remove the need to connect an AC charger prior to start the moni-
toring. This modification was made to be able to simulate an outage while keeping the device connected
to Android Studio via USB. Therefore we are able to visualize and retrieve information from the Android
Monitor during an outage.
The procedure to profile the RAM usage is defined as follows. We connected the device via USB
to Android Studio and gathered the RAM usage during the execution of the three scenarios described
previously. In the beginning of the test we configured all the necessary details for the scenarios, such
as the e-mail configuration and the web server accounts. We then performed each scenario separately
and with a period of approximately two minutes between them. The reason why we chose not to do the
scenarios consequently is because we wanted to check if any Garbage Collections (GC) were triggered
by each of the scenarios. Android documentation points the number of GC as an indicator of excessive
allocation of temporary objects and therefore as an indicator of a potential memory usage problem.
Therefore, besides measuring the peek RAM usage in the scenarios, we also counted the number of
GC. Table 5.3 show the measured results for each scenario, during the length of the test.
As we can see, in the Nexus there was only one GC during the three scenarios while in the other
phone there were two. After the second scenario both devices issued a GC. This is probably related with
the end of the outage service, since it is destroyed when the outage ends. The peek RAM usage was on
average 30,90 MB for the Nexus and 9,72 MB for the other phone. If we compare the obtained results
with the Heap Size for each device (refer to Table 5.2) we can see that the measured values correspond
to approximately 12% of the heap size in the Nexus and 10% in the other case. From these tests we
can conclude that the applications used approximately the same proportion of RAM in both devices and
the values represent a small percentage of the total available memory for applications.
54
Table 5.3: Results of the three hour RAM usage test
Scenario # RAM peek 1 Number of GC 2
White-brandedScenario 1 9.84 0
Scenario 2 9.95 1
Scenario 3 9.38 1
Nexus 6Scenario 1 31.60 0
Scenario 2 29.72 1
Scenario 3 31.39 01 RAM maximum value (in MB) measured during the execution of the correspond-
ing scenario2 Counted between the previous scenario and the end of following scenario
5.1.2 Battery usage
Battery usage is also a problem that is not easily resolved. While smartphone hardware components
keep increasing every year in terms of performance, the battery life and cycle duration do not follow the
hardware trend. When developing a mobile application the performance is probably the most important
aspect but the battery duration also has a high importance to the user. In this work we use two smart-
phones with a noticeable difference in performance as well in battery duration. Since we developed
the application with backward compatibility until Android KitKat (4.4.2), most of the devices still running
this version will not have a great battery duration. For this reason it is important to make sure that
DroidEnergy uses the minimum battery as possible. This will result in a longer monitoring time during
an outage.
In Table 5.1 we described the devices and the battery duration of each device when they are in
standby. Of course this does not correspond to the real duration when the device is, e.g. running an
application, using the Wi-Fi or mobile connections or has the display turned on.
Google provides two tools that are able to extract and analyze the battery information of the smart-
phone. The BatteryStats is part of the Android framework and is responsible for retrieving the smart-
phone power usage and the BatteryHistorian analyzes the extracted data and presents it in an HTML
page. Unfortunately these tools only work in Android 5 or above, so we were only able to use these tools
to determine the application power usage in the Nexus. To determine the power usage of DroidEnergy
we defined an hour long scenario. We chose this time interval so that the RAM and CPU usage could
stabilize between events. Since these resources have a direct relation with battery consumption and the
events in the scenario will not occur at the same time, the estimation is more accurate. Furthermore,
a measured time in a fixed interval of one hour can be easily used to estimate battery consumption in
different time intervals. The steps of the additional scenario are the following:
• Enable the mobile internet connection
55
• Configure the e-mail and SMS settings
• Enable the web server
• Add the house area ”bedroom” with the devices (<device A, 20 minutes >, <device B, 30 minutes
>)
• Add the house area ”kitchen” with the devices (<device C, 40 minutes >, <device D, 20 minutes
>)
• Choose to receive the device alert
• Start the monitoring
• An outage occurs
• After one hour, the outage ends
Android smartphones gather battery information between full charges. In order to have a reliable
battery usage reading, the battery stats must be cleared. To do so we connected the Nexus 6 to a
computer and removed all battery stats using the Android Debug Bridge (adb). The adb is a command-
line tool that enables the communication between a computer and an Android emulator or a Android-
powered device. After connecting the device to the computer we can confirm that the devices are detect
by calling the adb devices in the command-line. Figure 5.1 shows the list of devices detected by the
adb. As we can see, the adb is able to detect the Nexus.
Figure 5.1: Android devices connected to the computer
After confirming that the device is detected we use the adb shell dumpsys batterystats –reset com-
mand to reset the battery statistics gathered by the phone. After the reset we disconnected the devices
from the computer and started the testing. After completing the scenario we reconnected the phone to
the computer and extracted the battery information gathered by executing the command abd bugreport
>nexus bugreport.txt. A small part of this information can be viewed in the Apps − > Name of the App
− > Battery. The full report can be viewed by launching the battery historian server. In this server we
can upload the bug report retrieved from the phone. The server analyzes the data and builds a chart
where we can see many characteristics such as the CPU time, battery level and temperature. The server
also has another section where we can select the application and check the individual statistics. Figure
5.2 shows the gathered statistics of DroidEnergy. As we can see the estimated power consumption of
DroidEnergy is 0,14% of the battery capacity of the Nexus. If we take into account that the application
was used over a period of one hour, the estimated value of 0,14% battery per hour is a promising value.
As an example, in a case where only our solution was draining power from the battery, it would take
56
approximately 39 days and 3 hours for a full discharge. Taking into account that most outages last for a
period of few hours, the application would be able to run trough almost every outage.
Figure 5.2: Information retrieved using BatteryStats
Although we are not able to use the same method to retrieve the battery information of the other
device, the CPU usage in the Nexus indicates that our application does not use much CPU time since
the higher CPU usage was 2%. Another important aspect to notice is that the application also does not
require constant rendering of the screens, which is a common source of considerable battery drain. In
the case of the other phone, during the RAM usage testing we were able to observe the CPU usage.
Naturally it was higher than in the Nexus but the highest registered value was 20% during one second.
We also registered two other CPU usage peeks but they were less than 10%, also during one second.
These values are high for an application but they occurred only three times during one hour of testing and
during very short periods of time (one second maximum). We can not make a direct relation between
the observations and how much battery the application would drain in the cheaper phone, but we can
have an insight on how much work intensive the application is and therefore, determine that the power
usage of the application would not be high.
5.2 Usability tests
Usability tests are an important part of validating a platform. User experience provide an accurate way
to determine the aspects to improve by testing the application in a real environment. Prior to testing the
57
application with users, we elaborated a survey to validate the idea behind the prototype. The questions
presented in the survey are more focused in determining if the users find the idea and its features useful
and interesting.
5.2.1 Validation Survey
Before the validation specific questions, we asked a few questions to characterize the group of partici-
pants. Figures 5.3(a) to 5.3(c) show the responses for the questions that allowed us to characterize the
participants. From the 53 responses in the survey, 73.6% are the in group age between 18 and 24 years
old, while 22.6% are between 25 and 30, as we can see in Figure 5.3(a). 60.4% of the participants are
currently studying and 24.5% are working-students, and in terms of gender distribution it was roughly
50%.
(a) Number of participants by age group (b) Number of participants by gender
(c) Number of participants by occupation
Figure 5.3: Chart representation of the answers given in the validation survey
After characterizing the participants, we selected the ones which are qualified to participate in the
rest of the study using two questions. Figures 5.4(a) and 5.4(b) show the responses to those questions.
58
As we can see in Figure 5.4(a) from the 53 subjects that answered the survey, 92.5% of the responses
were affirmative to the question ”Do you own a smartphone?”. Since part of this work is prototyping a
smart phone application, the remaining 7.5% were excluded.
The last question to filter the appropriate subjects was ”Would you consider using a system that
detects power outages and alerts you even if you are not at home?”. As we can see in Figure 5.4(b),
85.7% of the subjects responded affirmatively, ending up with a total of 42 test subjects to continue the
survey. We asked one final question to the 14.3% which did not find the application useful to determine
why the subjects did not find the idea appealing. The justification that most participants gave was that
they do not find it useful due to the rareness of the outages. We also inquired the participants that
answered yes to the previous question to know if they would pay for such a system, to which almost
40% would pay at least 0.99e as we can see in Figure 5.4(c).
(a) Chart representation of the answers given to thequestion ”Do you own a smartphone ?”
(b) Chart representation of the answers given to thequestion ”Would you consider using a mobile appthat detects power outages and alerts you even ifyou are not at home?”
(c) Percentage of participants that would pay for eachprice group
Figure 5.4: Chart representation of the answers given to filter the appropriate participants to participate in the restof the survey and to determine if they would pay for the presented system
59
The second part of the survey has the objective of determining which features the test subjects find
more useful. To do so we asked the users to rate from a scale of 1 to 5 the following four questions
according to their usefulness, where 1 means Not useful, 3 means no opinion and 5 Very useful.
1. Would you find useful that the app could monitor different home devices?
2. Would you find useful accessing the app configurations even if you are not at home?
3. Would you find useful to receive outage alerts via SMS ?
4. Would you find useful to be able to configure almost every aspect of the app?
Figures 5.5 to 5.8 show the chart representation of the answers given to the corresponding question.
For the first question the users were informed of the context of the application, where they were told
that the monitoring of devices is to associate a time which will be used to determine if the user should
be alerted for that device, during an outage. As we can see in Figure 5.5, 95.2% of the participants
find it useful to monitor different devices while only a minority of the participants (4.8%) do not have
opinion. Regarding question number 2, again most of the participants found the feature of accessing
to the application from outside the house at least useful (refer to 5.6). The responses to this question
were not as good as the responses of the previous question. A reason for this may be the fact that the
participants know that outages are usually rare or do not last for a period that could affected the home
devices. In fact this was the justification of most of the participants that answered no to the question in
Figure 5.4(b).
Figure 5.5: Chart representation of the answers given to the question 1 (yy axis: number of responses)
Regarding question 3, since the objective of this work is to alert users of power outage, we chose to
question the participants if they would find useful to be alerted of such events. As we can see 54,5% of
the participants find this feature useful, which is worse than expected. Similar to the previous question,
we feel that the participants answered from the context of non-smart houses or houses where there
are no or few services or devices that need continuous power supply. Nevertheless the majority of
the participants find this feature useful. Finally, in question 4 we inquired the participants about the
60
Figure 5.6: Chart representation of the answers given to the question 2 (yy axis: number of responses)
customization one can make in the application. Similar to the previous questions, the majority of the
participants (80,9%) find the customization useful.
Figure 5.7: Chart representation of the answers given to the question 3
Figure 5.8: Chart representation of the answers given to the question 4
As described before, the results of this initial survey show that the main features we included in the
application are useful and are suitable in the context of this work. As a summary of the answers given
in the four questions we asked, from a total of 168 given answers, 80 correspond to the useful option
(number 4) of the scale and 54 correspond to the highest positive option (number 5), summing a total of
134 (79.8%) positive answers and only 6% of negative answers.
61
5.2.2 Testing with users
The second phase of usability tests is testing with users. This is important to evaluate aspects of the
application such as how the information is presented or if it is easy to use. We selected a group of
ten people where half of them are experienced users and the other half is not. An experienced user is
a person that interacts with smartphone applications everyday and an inexperienced user is a person
which does not have much knowledge with application interaction, although four out of five inexperienced
participants own a smartphone.
In these tests we aim to learn if both types of users can easily adapt to the application after using it
a couple of times. To do this we measure the time it took for the participants to complete each scenario
and after completing all three scenarios they answered a quick survey. Besides being able to determine
if the users can learn to interact with the application easily, we can also retrieve from the survey aspects
that need to be corrected.
Before the beginning of the tests we set up the testing area. We used the Nexus 6 for testing to
improve the user experience during the scenarios. We connected it to the AC charger and the charger
to a power outlet with a on/off switch in order to simulate the outages. Additionally we equipped the
smartphone with a SIM card and configured the application with the e-mail credentials needed to send
the e-mail alerts.
After setting up the testing area, we made an introduction of the objective of the work to each user,
as well as an explanation of the application and its features. This explanation was focused in what each
feature does without giving any hints on how to do it, so we would not influence the testing. Furthermore,
the application was previously configured in terms of e-mail account and web server settings since these
configurations are not needed to validate the application and therefore, we can minimize the difficulty of
completing the scenarios.
For each scenario described previously we handed out a script containing the actions that each user
should perform during the scenarios. The scrips do not teach the user on how to use the application, in-
stead they describe all the actions that need to be performed in order to complete each of the scenarios.
The scrips are described as follow.
Scenario 1
1. Add a new house area called bedroom
2. Add two devices to the bedroom (<device A, 1 minute >, <device B, 3 minutes >)
3. Choose to receive the alert defined in the scenario description
4. Start the monitoring
5. An outage occurs and after one minute the user is alerted
62
Scenario 2
1. Add a new house area called bedroom
2. Add two devices to the bedroom (<device A, 1 minute >, <device B, 3 minutes >)
3. Choose to receive the alert defined in the scenario description
4. Start the monitoring
5. An outage occurs and after one minute the user is alerted
Scenario 3
1. Check the Activate Web Server via SMS
2. Send an SMS to the phone running DroidEnergy
3. Go to the web server and select ”Receive reestablishment alert”
Prior to start testing, the users had two minutes to interpret the scenario and clarify any doubts
about the context of the application. After this, each user completed each one of them individually.
Figures 5.9(a) and 5.9(b) show the measured time that each user took to completed each scenario. The
measured time presented in the figure does not include the time that users had to wait for an alert to be
sent. For instance, in Scenario 1 the user had to wait one minute for the alert for device A to be sent,
but since this time is independent of the user which is testing the application, it was subtracted from the
measured time.
(a) Representation of the time each experienced usertook to complete the three scenarios
(b) Representation of the time each inexperienceduser took to complete the three scenarios
Figure 5.9: Time each user took to complete each scenario in mm:ss
As we can see in Figure 5.9(a) the experienced users took average of 3 minutes and 16 seconds
to complete scenario 1. If we compare to scenario 2, which is very similar to the first one, we see a
63
reduction of approximately 27% (one minute) in completion time. When comparing the average time be-
tween scenarios 1 and 3 the time was almost equal, differing in only two seconds. These two scenarios
tested different features and the results show that the users took almost the same time to adapt to the
execution of new objectives, although the third scenario was harder than the first.
Regarding the inexperienced users, on average each user took 5 minutes and 54 seconds to com-
plete scenario 1, 3 minutes and 23 seconds for scenario 2 and 4 minutes and 43 seconds for scenario 3.
Comparing the first and seconds scenarios, we see a noticeable difference, where the users took almost
45% less time completing scenario 2. We observed another noticeable difference between scenarios
1 and 3, where the third took almost 20% less time. This difference is justified by the adaptation effort
users with low or no experience have in using smartphone applications. Although they take almost 45%
more time to complete the first scenario compared to the experienced users, they reduce the time in
approximately 15% in the other two scenarios. One interesting observation is that User 2 of the inexpe-
rienced group took only 3 minutes and 1 second to complete scenario 3, which is less than the average
for the experienced group in the same scenario.
After the test phase each user was asked to fill a survey regarding their experience using the ap-
plication and how difficult they found the scenarios to be. Figures 5.10(a) and 5.10(b) show the results
of the scenario difficulty evaluation for the experienced and inexperienced users. As we can see in the
green bar in figure 5.10(a) the experienced users found on average all the scenarios easy, being the
second scenario the easiest. We can directly relate these results with the time spent by the users in
each scenario. The users found scenario 2 as the easiest and took less time completing the scenario.
Regarding scenarios 1 and 3 the time spent was almost the same and as we can see, both scenarios
were rated with an average of 4. Analyzing figure 5.10(b) we can see the inexperienced users also found
that scenario 2 was very easy but found the other two more difficult when comparing to the experienced
users. This is an expected difference, since users with less contact with these technologies take more
time to adapt to new scenarios, but inexperienced showed throughout the tests that they were able to
rapidly learn the application with only a few guidelines.
The second part of the survey has the objective of knowing the general opinion about the system
after completing the tests. Figures 5.11(a) to 5.11(c) show the results of the survey. As we can see in
Figures 5.11(a) and 5.11(b) all the users that participated in the tests had a positive experience using
the system. Regarding the final survey question three of the users felt that the information was not clear.
These users belong to the inexperienced group (Users 1, 3 and 4 in figure 5.9(b)) and justified their
choice for the time it took to find the path to complete the scenario. However after the initial adaptation
period, they lowered the completion time in the remaining scenarios for values near the rest of the
participants.
64
(a) Results of the scenario difficulty for the experi-enced users
(b) Results of the scenario difficulty for the inexperi-enced users
Figure 5.10: Rated scenario difficulty by user
5.3 Summary
In the previous sections we describe the methodologies to evaluate the proposed solution. These
methodologies are divided in performance and usability tests. In terms of performance, we measured
the RAM and CPU usage as well as the battery power drain. Regarding the CPU, the measured value
was around 2% in the Nexus and peeked at 20% in the other phone. The occurrence of these peeks
was sparse and they had a duration of only a few seconds, so we determined that the CPU usage was
not able to significantly influence the battery duration. To evaluate the RAM usage of the system we
first determined the interval where the system could have memory problems by gathering the maximum
heap size and memory threshold of the two devices we used to test the system. The results show that
the average RAM usage throughout the test was 12% for the Nexus and 10% of the heap size for the
other phone. The last performance test consisted in profiling the battery usage using BatteryStats and
BatteryHistorian. The results show that the estimated power consumption is 0.14% which is very low.
This value can be justified by the RAM and CPU measures and the fact that the application does not
need constant rendering of the views.
The second part of the evaluation are the usability tests which we divided in two sections, (i) Vali-
dation survey 5.2.1 and (ii) User testing 5.2. In the first one we inquired a group of 53 people where
we presented the idea behind this work and asked them a few questions. From the 53 initial we sub-
tracted 4 that did not own a smartphone and from the 49 we subtracted 7 that would not use a system
like DroidEnergy. The follow-up questions were made for the users to evaluate some of the features of
DroidEnergy and overall the answers positive.
The user testing was made with a group of experienced users and another of inexperienced users.
During these tests we measure both the time to complete each scenario and the overall reaction and
difficulty while using the system. The experienced users had a time reduction of 27% from the first to the
65
(a) Representation of the overall reaction to the appli-cation
(b) Representation of the user satisfaction
(c) Representation of the information organization
Figure 5.11: Results of the post-testing survey
second scenarios while the inexperienced users had a noticeable reduction of 47%. The inexperienced
users took on average 37% more time completing the scenarios although they improved throughout
the tests. Finally, in terms of satisfaction while using the system, the majority of the users found the