FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

PowerGame: A support application forserious games using real life energy

measurements

José Carlos Cadilha Coelho

DISSERTATION

Mestrado Integrado de Engenharia Informática e de Computação

Supervisor: Rui Rodrigues

July 18, 2013

c© José Carlos Cadilha Coelho, 2013

PowerGame: A support application for serious gamesusing real life energy measurements

José Carlos Cadilha Coelho

Mestrado Integrado de Engenharia Informática e de Computação

Approved in oral examination by the committee:

Chair: Doctor António Augusto de Sousa

External Examiner: Doctor Maximino Esteves Correia BessaSupervisor: Doctor Rui Pedro Amaral Rodrigues

July 18, 2013

Resumo

Nesta tese vamos descrever os problemas encontrados pela SmartWatt, uma empresa de consul-tadoria no domínio de consumo e gestão energética, no que toca a transferência de conhecimentocom os seus clientes e colaboradores em boas praticas de gestão de energia, e o cumprimento deditas práticas no dia a dia. Para o fazer, vamos estudar a influência e eficácia dos jogos sérios naaprendizagem, e como os mecanismos de recompensa nos jogos de video conseguem aumentar avontade do jogador absorver conhecimento novo. Adicionalmente, vamos pesquisar sobre como aopinião subconsciente dos utilizadores pode ser influenciada usando técnicas persuasivas e comoao incluir essas técnicas num jogo sério se pode traduzir no regular e consistente uso de boaspráticas de gestão energética.

Iremos falar sobre os desafios de modificar a lógica interna da aplicação responsável por mon-itorizar remotamente sobre TCP/IP a unidade de medição, convertendo-a numa aplicação que tiravantagem de uma ligação série local e corre num sistema Linux ao invés de Windows.

De modo a criar um protótipo eficaz, foi feita pesquisa sobre vários jogos sérios cujo objectivoprincipal era convencer e aliciar os utilizadores a utilizar uma série de boas práticas ao longo dotempo, tais como aquelas exigidas para uma boa gestão energética e uma alimentação saudável.Ao estudar as mecânicas de jogo e mecanismos de recompensa utilizados em cada jogo, vamosser capazes de definir um conjunto de funcionalidades cativantes que estão provadas funcionar naaprendizagem a longo prazo.

Para nos ajudar a alcançar os efeitos a longo termo de boas práticas de gestão energéticas, foicriada uma aplicação que usa medições de energia reais para servir como suporte a jogos sérios.Usando um conjunto de mecanismos de aprendizagem previamente provados úteis, em conjuntocom o uso de tecnologia persuasiva para diminuir a intrusividade da mensagem a ser assimilada,esta aplicação actuará como um sistema visual de feedback no que toca ao desempenho de gestãoenergética, enquanto serve simultaneamente como back-end para jogos sérios.

Um conjunto de linhas de guia para futuros testes foi criado de modo a ajudar a determinara utilidade do protótipo, e a guiar na descoberta de quais funcionalidades de jogo são mais efi-cientes em mudar o comportamento dos utilizadores. Adicionalmente propomos uma sequênciade trabalho futuro a ser concretizado de modo a continuar a melhoria do sistema Power Game.

i

ii

Abstract

In this thesis we will describe the problems faced by SmartWatt, a consulting company in the do-main of energy consumption and management, when it comes to knowledge transfer to its clientsand associates of the best practices in energy management, and the enforcement of said practiceson a daily basis. To do so, we will take a look over the influence and effectiveness of serious gamesin learning, and how the reward mechanisms in video games can increase the willingness of theplayer to absorb new knowledge. In addition, we will glance over how the users subconsciousopinion can be influenced using persuasive techniques and how by including those in a seriousgame it can translate into a consistent and customary use of best practices.

In order to create an effective prototype, research was made on several serious games whosemain objective was to convince and entice users to apply a series of good practices over time, likethose required for good energy management or healthy eating. By studying the game mechanicsand reward mechanisms employed in each game, we will be able to define a set of interesting andengaging features that are proven to work on long term learning.

We talk about the challenges of modifying the inner logic of the application responsible forremotely monitoring the measuring terminal unit over TCP/IP, turning it into an application whichtakes advantage of a local serial connection and runs on a Linux system instead of Windows.

To help achieve the long term effects of good energy management, an application that usesreal life measurements was created to act as support to serious games. Using a set of learningmechanisms previously proven useful, in conjunction with the use of persuasive technology to di-minish the intrusiveness of the message to be assimilated, this application acts as a visual feedbacksystem regarding energy management performance, while simultaneously serving as a back-endfor serious games.

The created Test Scenario Guidelines will help overseers assess the usefulness of the proto-type on their particular environment, and will guide them in discovering what game features aremost effective in changing user behaviour. We further propose a sequence of future work to beaccomplished in order to further improve the Power Game system.

iii

iv

Acknowledgements

To my teachers, from the first to the lastTo my family, for always being thereTo my friends, for all the fun timesTo my girlfriend, for all the supportTo my colleagues, for all the help givenTo Ruben Costa, Tiago Santos, the folk at SmartWatt and Professor Rui Rodrigues for all the

availability and feedback providedTo all the great people before and afterMy deepest thanks

José Coelho

v

vi

“Don’t compare yourself with anyone in this world...if you do so, you are insulting yourself.”

Bill Gates

vii

viii

Contents

1 Introduction 11.1 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Dissertation Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 State of the Art Review 32.1 Persuasive Technology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Serious Games and Application Examples . . . . . . . . . . . . . . . . . . . . . 4

2.2.1 Power Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2.2 Power House . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.3 Persuasive Fish Tank . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.3 Technology Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.1 libGDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.3.2 Turbulenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.3 Playcraft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.4 NodeJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 PowerGame System 133.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.2 PowerGame Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.2.1 Requirements and User Stories . . . . . . . . . . . . . . . . . . . . . . . 143.2.2 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2.3 PowerGame Work Flow . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.3 Global System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.4 Architecture Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4 Measurements 214.1 Data Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.1.1 Circutor Device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.1.2 Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.1.3 MyGenBox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5 Web App 315.1 PowerGame Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1.1 WebApp Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 315.1.2 Organizational Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1.3 Database Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.1.4 WorkFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1.5 Non Implemented Features . . . . . . . . . . . . . . . . . . . . . . . . . 38

ix

CONTENTS

5.1.6 Implemented Features . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6 Tests and Results 416.1 Data Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 416.2 Test Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2.1 T1 - Login Regularity . . . . . . . . . . . . . . . . . . . . . . . . . . . 436.2.2 T2 - Mission Influence . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2.3 T3 - Mission After burn . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2.4 T4 - Reward Influence . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7 Conclusions and Future Work 477.1 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

A Apendix I 49

References 57

x

List of Figures

2.1 Screenshots of the Power Agent Game . . . . . . . . . . . . . . . . . . . . . . . 52.2 Screenshots of the Power House Game . . . . . . . . . . . . . . . . . . . . . . . 72.3 Different feedback stages of persuasive fish tank . . . . . . . . . . . . . . . . . . 8

3.1 Pre Development Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.2 Planning for Website Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3 High Level View of the System Architecture . . . . . . . . . . . . . . . . . . . . 183.4 Architecture of the System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.1 System Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.2 Jamod Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3 Data Array Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.4 Jamod Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Folder Structure for the NodeJS App . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Group Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3 Database Schema for PowerGame . . . . . . . . . . . . . . . . . . . . . . . . . 345.4 Login Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.5 Admin Signup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.6 Game Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.7 The Active Missions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

6.1 Data Graph of the Instant Consumption Variable . . . . . . . . . . . . . . . . . . 426.2 Data Graph of the Accumulated Consumption Variable . . . . . . . . . . . . . . 43

A.1 User Being Promoted to Admin . . . . . . . . . . . . . . . . . . . . . . . . . . 49A.2 Group Criation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51A.3 Admin Creating Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52A.4 Mission Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53A.5 End Mission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54A.6 Acknowledge Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55A.7 Daily Bonus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56A.8 Sending a Log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

xi

LIST OF FIGURES

xii

List of Tables

2.1 Feature comparison of apps reviewed . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1 Single, Two and Triple phase variables . . . . . . . . . . . . . . . . . . . . . . . 234.2 Modbus RTU Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Modbus Serial Connection Parameters . . . . . . . . . . . . . . . . . . . . . . . 254.4 Device Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

A.1 Aditional variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

xiii

LIST OF TABLES

xiv

Abbreviations and Symbols

AP Administration PanelAPI Application Programming InterfaceCPU Central Processing UnitCRUD Create, Read, Update and DeleteePoints Energy PointsHUD Head Up DisplayIDE Integrated Development EnvironmentI/O Input/OutputJDK Java Development KitMGB MyGenBoxMHz Mega HertzmongoDB Mongo Databasems MillisecondsNPM Node Package ModulesOS Operating SystemPC Personal ComputerR&D Research and DevelopmentSCADA Supervisory Control And Data AcquisitionSDK Software Development KitSSH Secure ShellTCP/IP Internet Protocol Suite or TCP over IPUSB Universal Serial BusW Watt

xv

Chapter 1

Introduction

With the increasing scarceness of fossil fuels, one of the most used products in energy generation,

energy costs are expected to continue to rise in the near future. It is then of no surprise that

energy expenditures is starting to become one of companies biggest concern. According to a

recent study by Delloite [Del12], "90% of the companies have set goals regarding electricity and

energy management practices". Although many claim such practices have as a goal reducing costs,

these are not always obvious or easy to implement. For such cases, 3rd party consulting companies

specialized in the energy domain are required to conduct a study.

SmartWatt(SW) is a Portuguese consulting company that studies the energy efficiency of cor-

porations, schools and other associations. By recurring to a set of measurement devices that mon-

itor energy use, SW is able to keep an accurate history of energy use across a long span of time,

creating a baseline of the client company energy waste. This baseline, in conjunction with the

tariff being used by said company to pay his electrical bills, allows them to detect the critical time

intervals where inefficiency is at his highest. After the study is done, the client company receives

an action plan that if followed, should make it possible to lower expenditures and lead to higher

profitability.

The value of such action plan is not always apparent and its effectiveness is always dependent

on the willingness of the participants to follow the guidelines created. Even if the plan is followed

to perfection by all company collaborators, the feedback obtained which most of the times is

limited to a financial result, is not always instant. Depending on the time frame where the biggest

inefficiency lies, positive reinforcement can take months to appear, assuming that the company

can persevere with high efficiency by following a plan without any feedback system during that

span of time.

As stated, one of the few items that can be useful as a feedback system for this case is the

amount of financial resources allocated for energy use. The problem herein is that no one besides

the executive board or financial department has access, or is influenced by, the savings achieved.

An employee working at a desk answering customers calls will have no incentive to turn off the

lights or shut down the computer when he goes to lunch, which is a hindrance when trying to

implement the plan created by the consulting company.

1

Introduction

The problems found when implementing energy saving policies can be put into three different

categories: ignorance, forgetfulness, and sloth. Ignorance is solved with an action plan delineated

by a specialized consulting company like SW, forgetfulness and sloth will need a solution that

keeps the good practices fresh in the users memory, while enticing them to have a proactive stance

on energy saving without a decay in efficiency of said stance over time.

1.1 Objectives

The objective of this master thesis is to design a support application for serious games that can

influence effectively through the use of persuasive technology the players to act regularly on a set

of good energy saving practices.

1.2 Dissertation Structure

In Chapter 1 we give a brief introduction to this dissertation, by describing the problem and giving

a possible solution, the objectives we expect to achieve and the expected results.

In Chapter 2 we do the bibliographic revision, where we study the topics of serious games,

persuasive technologies and give examples of serious games and applications that already to some

extend persuade people to apply best practices of energy management, discussing what they do

right and what they do wrong. We also give a brief overview about possible technologies to be

used with the prototype.

In Chapter 3 we talk about the general architecture of the prototype, including a brief introduc-

tion of the necessary systems and ways for user interaction. We’ll also brush over what we intend

to achieve with the implemented prototype, including possible game concepts, how the framework

will work and we will go over the typical use flow for a regular player and an administrator.

In Chapter 5 we describe in detail the work done while implementing the prototype, which

includes two big sections: data logging and the web framework. On data logging we’ll glance

over the devices and hardware, as well as the industry standard protocols used, and further details

on implementation and the problems faced on that task. On the web framework we’ll justify the

technologies chosen for implementation, explain the architecture of both framework and database

systems used.

In Chapter 6 we explain the test carried out in order to better understand the viability of the

data used, and delineate several test case scenarios that can be used in the future to measure the

effectiveness of the use of the app in each instance.

In Chapter 7 we close this dissertation with the conclusions we arrived at and give some point-

ers on future work.

2

Chapter 2

State of the Art Review

In order to ensure the best results with our proposed solution we first need to take a look at what has

already been made in the area, allowing us to take note of the flaws encountered and improve upon

the features and solutions that are proven to work. In this chapter we will present an overview

of the literary review made, which included subjects on the topic of ’Learning Methodologies’,

’Persuasive Technologies’ and ’Serious Games’.

2.1 Persuasive Technology

According to Fogg [Fog02] persuasive technology can be considered any technology that was

made to mould the attitudes and behaviours of users through persuasion and social influence,

but not through coercion. According to the same author, persuasion can be categorized into five

different categories: physical, psychological, language, social dynamics and social roles. Several

experiments were conducted to prove the influence of these five types of persuasion in influencing

the perception one has about someone or something, thus influencing decision making.

The physical type considers physical characteristics and attractiveness, taking advantage of the

increased trust the human mind places into someone we consider attractive. An example of this

would be the use of pleasantly looking characters, famous people and attractive interfaces. Besides

the experiment made by Fogg on this subject, an extensive study on the marketing of children food

[BHKH11] shows that the use of promotional characters or celebrity endorsers, as well as logos

and slogans deeply sways the decision making of children, while simultaneously increasing the

thrust given by parents to the product or brand.

The psychological type considers hints that portray the existence of emotion or personality in

the technological system, leading the user to behave as if he was interacting with a real human.

We can then design the system in order to take advantage of the human tendency to listen more

attentively to similar people or people affiliated to a common group. On a different article by

Russo [RC10] about the influence of persuasion in decision making, an experiment is done to

see how this tendency can lead someone to choose one of two equal products presented in two

3

State of the Art Review

different ways, according to the way they identify themselves and the similarity they find between

them and the way the product is presented.

The language type considers the different types of language that can be used to better suit

the user, and the different messages text can transmit depending on how it is presented. For

example, an application that constantly addresses its user by name will transmit a more familiar

feeling to the experience. Depending on how it is written, text can seem friendly, inquisitive,

affirmative, demanding, and others. By combining this fact with previous explained types of

persuasion, we can create an application that seems insecure and introverted to better influence

insecure and introvert users. That same way, if the application targets for example, rap singers, the

colloquialisms used by those users should be taken into account when designing the application.

The social dynamics type considers the cultural norms and rules the user is accustomed to. The

most common example of this is the greeting of someone that just arrived or logged in, which is

universal throughout almost every culture. This type of persuasion needs to be implemented very

carefully, because what some cultures might consider the norm, others might consider offensive.

The social roles type considers the perception of importance of each role in society, and the

ability of that role to perform a given task. For example, a piece of software that performs a

diagnostic of sorts will persuade more users to buy it if it possesses ’Dr’ on its name, a profession

that is given great respect by society and is associated with performing diagnostics and ’fixing’

the ill. Likewise, a learning application will influence the user more if it includes ’Teacher’ in the

title.

The language and social dynamics need to be carefully incorporated, since tipping the scale too

much in one way will alienate the user base on the opposite end, creating an unintended undesired

effect on the application.

In sum, persuasive technology tries to emulate favourable traces of human personality in order

to achieve a higher degree of thrust and commitment from the user.

2.2 Serious Games and Application Examples

When reviewing all the different applications related to energy saving and learning a set of com-

mon features were found that we were interested in having in PowerGame. These features can be

found and be missing interchangeably in several applications. A description of all the important

features can be found bellow.

Measurements: These applications use real life measurements as input for their game and as

feedback, either internally on the app or externally to the users, for the players actions.

Multi Platform: These applications run on multiple devices or operating systems. If no details

are provided otherwise, we assume the application failed to comply with this requirement.

Learning Mechanisms: These applications use some form of feedback or learning mechanism

to let the user know the consequences of their actions.

4

State of the Art Review

Feature Measurements Multi Platform Learning RewardsPower House X X V VPower Agent V X X X

Persuasive Fish Tank V X V XTable 2.1: Feature comparison of apps reviewed

Reward Mechanisms: These applications use some form of reward to reinforce positive be-

haviours. Be it points, virtual items, benefits or even levelling up counts as a reward.

A summarized feature comparison for the following applications can be found on Table 2.1

2.2.1 Power Agent

Power Agent [BGK07] is a mobile video-game prototype conceptualized and developed by a re-

search group for the Sweden Energy Agency. The paper describing the process and reason behind

the design of this game states that there is no such thing as knowledge transfer, but that learners

actively construct knowledge built on previous experience of real world tasks. By blurring the

line between what is simulated and what is real, researchers hope to increase success of situated

learning, achieving behavioural changes by contextualizing familiar activities in the social context

the user lives in.

Figure 2.1: Screenshots of the Power Agent Game

Researchers proposed therefore the creation of a pervasive game, a game that somehow ex-

pands the virtual gaming experience to the physical world. Examples of this are location based

games like geo-caching, where the progress of the player and the hints for the locations to visit are

virtually stored, while the actions of the player itself are conducted in the real life world.

5

State of the Art Review

According to the document revision made, in pervasive gaming rules inside the game tend

to alter the notions of rules outside the game, more so if said rules are in some way socially

contextualized. This leads to activities in game that require adaptability from the player to help

him recognize the problems and transfer such skills to outside the game.

To implement this, they suggest following the four tenets of pervasive learning games by

Thomas [Tho06] , where players are directly responsible and in control for their own learning

process (autonomy), connected to places and other players (community), learn in a location and

time relevant for the subject they’re expanding their knowledge into (location) and where they

construct relevant scenarios to which they can relate, easing the learning process (relation).

Social learning theories explains "human behaviour as an interaction process between cogni-

tive, behavioural and social components". By rewarding and punishing certain actions, the game

is showing the outcome of certain choices, which will be reinforced by their peers by course of

regular conversation, or to a greater degree if such rewards or consequences affect the social group

as a whole.

In the Power Agent game, as can be seen in figure 2.1, the user role plays a secret agent that

receives missions through its mobile phone. This can be categorized in training missions (where

the player runs through a classic platform level, grabbing tips and hints about saving energy and

influencing family and friends) or real life tasks missions that range from the obvious and direct

(turn off all stand by appliances) to those who require more thought from the player (minimize

household consumption for a day). Each player household has a series of measurements (electri-

cal consumption, water heating) that are used to measure the performance during the real world

missions. These performances are clustered into groups of players and shown to every group in

order to entice competitiveness and increase awareness.

This two stage play mode is based on Bandura [BM77], who suggests a two stage model for

learning, where first a behaviour can be symbolically rehearsed and later enacted.

2.2.2 Power House

This video game [BTK06] proposes to teach young people how to save energy on every day tasks

performed at home, using for this effect persuasive techniques as delineated by Fogg. By taking

advantage of the use of a simulated environment that is relatable to the task at hand, it allows the

users to experiment with trial and error, get accustomed to the environment and the influence their

actions have over it, foundation of simulation games used for learning purposes like those used in

the air force. Another commonly used technique is called Operant Conditioning, which has as a

goal to manipulate future behaviour by giving positive or negative reinforcement.

As explained earlier, the use of easily identifiable characters or persons can influence the thrust

level felt by the user when completing a task or making a decision. This technique is put to good

effect on the game, that provides a set of avatars within the age range of the users without any

negative features in its complexion, with an emphasis on attractive physical features.

As can be seen in figure 2.2, in this game the player controls the house inhabitants to perform

a series of tasks that provide happiness but consume energy, resulting in extra income as virtual

6

State of the Art Review

Figure 2.2: Screenshots of the Power House Game

money when tasks are successful, income that the player can use to improve efficiency of several

parts of the house, or not. An example given is that of taking a shower, the longer the shower takes,

the more currency is depleted in the form of energy, but the more happiness is generated by the

user taking it. As the main goal of the game is to keep all the characters inside the house as long

as possible, a balancing act needs to be made. The immediate feedback of the draining currency

helps the user realize how taxing each task is, and the influence of the upgrade of different devices

such as a massage shower, or an efficiency A washing machine.

The actions of the players are many times influenced, praised or criticized by the "show host",

as a way to reinforce the conditioning loop.

One of the main flaws of this game is the purely virtual approach to learning. As the game

takes no use of real life measurements, the game relies on the willpower of the player to practice

what he learns in game outside of it.

2.2.3 Persuasive Fish Tank

This research [CLH+11] was conducted due to concerns about global warming. According to

several studies reviewed by this group, a big percentage of energy consumption nationwide can

be attributed to homes and corporations (inside buildings). Since alternative energy generation

methods are very expensive, a good way to save energy is to teach people how to effectively save

energy both at home and on the job.

7

State of the Art Review

Figure 2.3: Different feedback stages of persuasive fish tank

This paper summarizes several other studies that employed feedback systems as an energy

saving teaching technique, most of which use additional incentives "such as reduction in electricity

expenses, competition and peer education". All of these studies use simple text or graphs as

feedback data, while the researchers of this paper will use a more augmented visual system to do

it, as can be seen in figure 2.3.

The first problem with a feedback system is how the users personality relates to the feedback it

receives. According to the studies at hand, biospheric and altruistic people tend to be more easily

persuaded to practice beneficial behaviour when the feedback received is put on a positive light,

while egotistical personalities tend to only cooperate when the consequences of its actions directly

8

State of the Art Review

affect the individual or their loved ones.

To solve the problem this paper proposes the use of Computers as Persuasive Technology. The

system takes the data collected from the energy consumption monitoring devices and transforms

the virtual environment according to what considers good or bad, leading the user to a change in

behaviour, which will in turn change the virtual environment.

To measure the effectiveness of this system a prototype was deployed on two offices with

twenty PhD or master students each. Measurements were taken before and after the model intro-

duction. Additional user perceptions and advice were recorded using questionnaires.

People were more active when directly responsible for paying the bills, and the negative feed-

back proved to be more impactful in animals than on humans. Peer pressure was an important

factor in the use of good practices.

The biggest problem left unanswered was how to prevent user fatigue from reducing the long

term influence of the system on energy saving behaviour.

2.3 Technology Overview

For the proposed solution we chose to use a set of technologies that allowed us to deliver our

prototype in the most amount of different devices possible. These technologies had to allow us to

render some kind of graphical output to the user, and communicate between clients. To achieve

this, we decided to use the latest iteration of the HTML standard, HTML5, which includes the

Canvas specification for immediate mode 2D drawing. This will allow the user to run the pro-

posed solution on any device able to run a browser that supports HTML5. To perform real time

communication between clients we decided to use Node.js, a software system for the creation of

scalable web applications capable of non-blocking event driven I/O.

In order to accelerate the development of the prototype additional research about game engines

was done, a detailed list of JavaScript based engines and features can be found in [Htm]. We

prioritized free engines with sprite management classes and networking support, while open source

was a big plus when making the final verdict.

Conforming to these features we ended up with three different engines in the search phase:

libGDX, Turbulenz and Playcraft. These engines were later scraped in favour of a more bare bones

HTML5 framework, since the requirements for the web app were simplified in terms of graphical

and interaction requirements although more complex in regards to data storage and 3rd party

interaction. To deal with this we required a new scalable database system that could efficiently

handle and process a large data set and a node module that would allows us to quickly develop a

web API. Regardless of the actual use of the game engines in our app, we consider it relevant to

present here the information regarding their features.

2.3.1 libGDX

LibGDX is an open source cross platform framework that abstracts several components of game

development allowing the developer to write the code once and compile to Windows, Linux, Mac,

9

State of the Art Review

HMTL5, Android and iOS. The biggest advantage is the possibility of extending the features of

the framework due to its open source nature. The biggest disadvantage is the bare bone nature of

the framework, requiring the developer to create his own game engine before doing any prototype

work.

2.3.2 Turbulenz

Turbulenz is a free HTML5 javascript game engine that supports shaders, particle systems, in-

cludes a physics package and supports 3D sound sources. This engine also includes networking

capabilities and built-in integration with social networks. This engine provides its own SDK.

2.3.3 Playcraft

Playcraft is an HTML5 game engine currently in beta state. It provides an object oriented devel-

opment environment, includes a mobile framework to run the applications on Android and iOS,

a physics package and multiplayer capabilities with the integration of Node.js. It uses spatial in-

dexing to decrease rendering times and developers have access to a web based world editor that

allows the inspection of object state, game performance and live testing of the game.

2.3.4 NodeJS

NodeJS is an open source platform built on Google’s V8 javascript engine and designed to build

low-latency scalable network applications using an event-driven non blocking I/O model. In node

all I/O operations are asynchronous, and all of them are invoked through a lower-level C++ layer

[Nodb]. NodeJS works by running a single-threaded event loop that reads the event queue sequen-

tially. While these I/O operations are being processed node can handle other events, and once an

operation is concluded a callback is returned and sent to the queue. Due to a strong and growing

community around this project a series of high performance drivers for middleware and other li-

braries is available and easily integrated into NodeJS, the most notable of which were used being

MongoDB, Jade and Express.

2.3.4.1 MongoDB

MongoDB is an open source document oriented NoSQL database system. Each JSON-style doc-

ument is stored into a collection, and several collections can be stored in a single database. This

db system supports indexing of any attribute in the document, provides auto-sharding, map/reduce

and rich queries. MongoDB can have several documents in the same collection with a different

schema between themselves, or missing attributes.

2.3.4.2 JADE

Jade is a nodeJS templating engine built on javascript and influenced by Haml. This library is

available through the NPM and the purpose of the engine is to allow the web designer to write

10

State of the Art Review

jade code which doesn’t suffer from the verbosity required by the html standard, as this code is

later compiled to html on the back end.

One of the main features used besides the beautification of code is the inheritance system that

allows us to extend layout files with each other. In our case we created a template called ’lay-

out.jade’ that served as a base to each page and included scripts, dependencies and dom elements

common to every page. By including the line ’extends layout’ each jade file extended the base one.

In addition, the existence of blocks allowed us to avoid the repetition of code with the inclusion of

code sections into named blocks, that were later included in the needed section of a new page.

Although this engine is designed to take advantage of a different syntax, it also supports pure

HTML mixed in with Jade. The use of JavaScript mixed in is also available, with loops and

conditionals like ’if’ and ’unless’ supported directly as part of the Jade language.

2.3.4.3 Express

Express is a web application framework available for NodeJS through NPM. Express allows us

to run a lightweight dedicated http server, and it simplifies the creation of a web API by taking

advantage of its robust routing system. Express also supports caching of web-pages, simple access

to URL variables and sending http responses.

In conclusion, we decided to choose a set of open source software in order to accelerate devel-

opment and take advantage of the strong open source community and rising popularity of NodeJS,

to facilitate and simplify further needs in regards to modules and extra tools required to be built to

accommodate possible new features.

11

State of the Art Review

12

Chapter 3

PowerGame System

In the following chapter we will talk about what goals we intend to achieve with the PowerGame

system and how we’ve designed and envisioned its functioning.

We will talk about the proposed solution, a visual feedback system and support application

that uses real time measurements to provide the players with information about the outcome of

their real life actions in a virtual world, and how we plan for it to be used after finished.

We finish this chapter with a section where we fit PowerGame into a broader context and talk

about its dependencies in the whole system.

3.1 Goals

When designing the PowerGame our goal was to create an application that granted users the ability

to understand the outcome of their actions in real life in regards to energy consumption habits, and

help them better themselves on that subject through the use of something they enjoyed interacting

with.

To support this we needed to use a system that allowed the PowerGame to accurately monitor

the energetic behaviours of users.

3.2 PowerGame Application

The purpose of PowerGame, the nodeJS web app of the PowerGame system, is to act as a cen-

tral hub between the measurements and 3rd party games, a hub where players can check their

progress and the progress of others, and visually see their main inefficiencies and flaws in energy

management.

It is expected in the future for the PowerGame back-end to provide an API that allows 3rd

party games to access the information of the players registered in the PowerGame. Information

such as the energy points obtained through saving energy or the stars from completing missions

might be used as currency in those games to unlock cosmetic items or features.

13

PowerGame System

The PowerGame web app is split into two modules: the first, that every player has access to, is

the User Panel, where the players have access to the information directly related to them and the

group they belong to. The second, that only the administrators of each group and of SmartWatt

have access to, is the Admin Panel, where the administrators have access to the controls that allows

them to control and manage the group they belong to, and the direct child groups attached to it.

On top of this the influence of a counsellor or teacher outside the game is expected to guide the

players using learning techniques and to mould them into knowledgeable best practice followers.

3.2.1 Requirements and User Stories

After the initial design was outlined, the requirements that would describe it in detail were defined

through a set of user stories that were then split into three modules: server, admin panel and user

interface.

Some specific terms are used throughout these user stories which are not immediately under-

standable, and can be described as follows:

Group In-game team corresponding to an institution/corporation/entity the user is part of.

Mission One or more tasks in a predetermined sequence.

Tier of Competition Hierarchical level containing all children groups of a common super group.

3.2.1.1 Server

The server must be able to store:

- the name, password, email, ePoints, stars and time of last login of each user;

- the relationship between users and groups;

- the name of each group;

- the relationship between groups;

- a flag to distinguish normal users from admins;

- data information about each group consumption levels;

- information about each groups progress on missions;

- information about missions created for each group;

- the name, description, difficulty of each mission;

- a flag to distinguish an active from an inactive mission;

- the relationship between missions and groups;

- the content and date of each log;

- the relationship between a log and corresponding mission and user;

- a flag to distinguish between an acknowledged and unacknowledged mission;

14

PowerGame System

3.2.1.2 Admin Panel

The Admin must be able to:

- alternate between the Admin panel and the User Interface Module;

- create a new group under the one he administrates;

- promote a regular user of a child group to an administrator;

- create a mission;

- define a title and description for each mission;

- define the an associated value of difficulty between 1 and 3 points for each mission;

- activate an inactive mission;

- send notifications warning the user of an active mission;

- select the active missions to be accomplished by the group.

- acknowledge a mission as successful, granting the user with some reward points equivalent

to the difficulty of said mission;

- see the logs sent by users regarding each mission;

- see which user sent which log on which date and time;

3.2.1.3 User Interface

- upon arrival to the page, the user is faced with a login screen;

- the user must be able to register;

- the user must be able to reset his password;

- the reset password must be sent to the stored email account;

- the user must be rewarded for a daily login;

- the app must be able to automatically authenticate the user if he allowed cookies;

- the user must be able to log out off his account;

- the app must warn the user on logout;

- the app must be able to show the real energy consumption line to the corresponding group.

- the app must update the stars of the user every time a mission is completed successfully;

- the app must update the ePoints of the user based on the savings calculated;

- the app must associate a performance value to each group using the variance between the real

energy consumption and the baseline values;

- the app should display in a grid like interface the several peer groups and respective perfor-

mance levels;

- the app must allow the user to see which active missions are available;

- the app must allow the user to see information about each mission;

- the app must allow the user to send a log to the administrator;

- the app must confirm if the log sending was successful or not;

15

PowerGame System

3.2.2 Concept

In figure 3.1 we can see the concept created before the start of the development phase. In this

concept the screen is split into three sections: the visual feedback system takes most of the space

on the top left corner, the data graph is situated on the bottom left corner and the function section

is located on the right.

Figure 3.1: Pre Development Concept

In the data graph section we can see the information received by the devices plotted in conjunc-

tion with the baseline values belonging to the group the logged in user is part of. These baseline

values are the energy consumption values that the users of this particular group are expected to

consume on a minimum, meaning any value above this one will be considered unneeded waste.

These baseline values are dependent on the study of the installations and business process and the

use of calculations over the historic of consumption of all users over a predefined stretch of time.

The background of the graph itself changes color depending on the positive of negative difference

between the expected baseline values and the real consumption measurements.

In the visual feedback section, we can see three rows of tiles representing each a different child

group from the same parent group. In order to be able to compare values between themselves,

these child groups need to have each a different measurement or group of measurement devices.

Each tile represents a set span of time, and its appearance changes depending on the performance

achieved by the group during that time. In the beginning of each row an identifier for each group

is found, and an avatar of the user is placed on the tile corresponding to the current time frame.

On the right side we have the function bar were the user can interact with the system. On the

top area additional info is shown about each tile, such as the consumption and the specific time

where it occurred. Bellow a set of color coded buttons is placed each corresponding to a different

action. It was later decided to let the players compare their overall efficiency levels with others

16

PowerGame System

on the same level, to check active missions and to send a log telling the coordinator how the user

contributed to the completion of the mission.

3.2.3 PowerGame Work Flow

Several kinds of different users will have access to the PowerGame website, and the way they

interact with each other will differ depending on the roles they take. On the top of the permission

chain we have the SmartWatt super administrator, which is the person responsible for coordination

with a joining organisation that by enacting the initial creation of a group, giving admin access to

the coordinator of that organization and helping him understand the workflow of the application

enables this coordinator to become an independent admin capable of managing the PowerGame

on his own accord. The following administrators all follow a top down hierarchy depending on

who promoted who, and they are all responsible for guiding the players that belong to their group

through the use of a set of tools that are restricted to regular users. The regular users are the players

who have access to the game as described in the Concept section above.

Figure 3.2: Planning for Website Workflow

As can be seen in figure 3.2 the first step when an organization joins the PowerGame is done

by a Super Admin that creates the main group with an appropriate name. The coordinator on the

new organization joins this group and is promoted to administrator. From here on out he has total

independence to create new groups, so he creates two different groups called X1 and X2. After a

new user joins X2, Admin A creates mission M1 and makes it available on group X2. From the

user B side he reads the mission goals and tips, carries out its activities in real life and periodically

returns to the website to send text logs with a description of its activities. Admin A can then read

17

PowerGame System

the logs from the user, and seeing a consumption graph decide if the mission was successful or

not. Depending on what Admin A decides, the user gets a reward.

An example of a similar interaction using the finished prototype can be seen in section 5.1.4.

3.3 Global System Architecture

Our PowerGame website will be part of a bigger system comprised of several different compo-

nents. The first one which is located on the client organization site is a physical measuring system

composed by several energy measurement devices. These devices measure the consumption and

energetic performance of the grid on that location, and send the data to the SmartWatt servers.

These servers are also responsible for hosting the PowerGame website and it is by accessing it that

users anywhere and using any type of OS can join and participate in the PowerGame.

Figure 3.3: High Level View of the System Architecture

While a simplified schematic of this can be contemplated in figure 3.3, further details on

technologies and implementation can be found on section 3.4

3.4 Architecture Implementation

In this section we will explain into greater detail the technical side of the Global Architecture

mentioned before, which includes a list of all technologies used, both in client sites as well as in

the SmartWatt servers, and how they interact with each other to provide us with a solution.

18

PowerGame System

As seen in Figure 3.4, each client site will have one or more measurement systems capable of

sending information about the energy consumption and other variables at regular intervals to the

SmartWatt servers.

Figure 3.4: Architecture of the System

In the case of the currently used legacy system, a set of Circutor measurement devices con-

nects using TCP/IP to a single Windows Server. These servers contain a Java app that polls the

measurement devices in sequence in an infinite loop, and sends the values obtained at the end of

each loop to a SCADA system. These values, if valid, override the ones stored in a buffer in the

server, and every 15 minutes the contents of the buffer are stored into a MySQL database.

In the case of the developed system described in the Data Logging section 4.1 that will be

used in the future, one or more Circutor devices are associated to a mini PC running Debian called

MyGenBox (MGB) to which it connects using a Serial-To-USB adapter. These MGBs contain a

Java app that constantly polls the device and stores the valid values in an array in memory. A task

is executed every 15 minutes to write the contents of the array directly into a MongoDB document

on the instance running in the SmartWatt server. Each device has its own collection of documents,

and each building its own database instance.

The SmartWatt Server runs Linux Ubuntu and has a single NodeJS instance running a web

server with an HTML5 interface called PowerGame, a web app that uses the values stored in

the MongoDB database as energy measurements, and uses MySQL to store and read all the info

related to users, groups and other data required for the functioning of its web interface. This web

app is accessible to users in any operating system through a browser compatible with HTML5.

19

PowerGame System

20

Chapter 4

Measurements

In the following chapter we describe in detail the experience obtained and the decision making

behind the implementation of the planned and thought of framework prototype.

In this section, Data Logging, we will talk about the requirements stipulated for data inputs

needed for the correct functioning of our framework, the solutions proposed and the reasoning

behind it, the protocols used to transfer information and the hardware assembled to gather it.

We’ll round up this subsection with the main problems faced and drawbacks while implementing,

and the solutions at which we arrived to solve them.

4.1 Data Logging

Data Logging is an essential task that needs to be performed for the correct and scientific as-

sessment of the influence of a behaviour altering framework that uses real life measurements as

input.

4.1.1 Circutor Device

For the data collection SmartWatt uses two different kinds of Circutor devices.

The first one, used by the legacy system, has an Ethernet port through which a remote server

polls using a Modbus TCP protocol. Depending on the distance between the remote server and the

Circutor device, and depending on conditions such as humidity and heat of the site in which the

Circutor device is stored, the rate at which the CRC check of the response fails increases. Other

failures occur when the polling of the same machine and variable is done at the same time by two

concurrent processes. To solve this problem a timeout is issued, and the poll is repeated.

The second one, which will be the focus of this section, is a Circutor Mini [cir] and takes

advantage of a Serial to USB adapter to connect itself to a mini computer running Debian Linux.

The setup as seen in Figure 4.1 is accomplished by connecting terminals 14 and 15 of the

Circutor device, which correspond to Power supply voltage input, to the power supply circuit we

are interested in monitoring. Terminals 3 and 4 are then connected to Pins RxD and TxD of the

pl2303x [pl2] serial to USB adapter. These pins correspond to the Serial Port Transmitted Data

21

Measurements

Figure 4.1: System Setup

and Received Data respectively. The USB side of the adapter is then connected to a USB 2.0 port

on the Debian machine, with the Ethernet port being used to connect said machine to the web, in

order to send the polled values to a MongoDB databased located in a remote server. Due to the

short distance between the Circutor device and the machine polling for data, the failures in data

reading are minimized.

4.1.2 Data

The Circutor device is capable of reading several variables, that are dependant on the electric setup

available. On table 4.1 we can see the variables available in Single, Two and Triple phase setups,

which can be identified by the 1,2 or 3 post-fix on the symbol column while the temperature

parameter is available on all 3 setups. Variables incompatible with the current setup will return

the value of 0 (zero) upon polling, which is the case on the test case we have available, which

uses a Single-Phase measurement. In the Parameter column we have the variable name, while on

the Code column we have the hexadecimal number corresponding to the MODBUS register of the

instant value stored in the memory of the device. Each variable occupies a single register of space.

For the input of the PowerGame framework we will use only the Active Energy variable, which

holds the value of the accumulated consumption of energy since the start of the setup. In addition

to the mentioned variable, additional variables being polled by the future system can be consulted

on table A.1.

22

Measurements

Paremeter Symbol Code UnitsPhase-neutral voltage V 1 00 V x10Current A 1 02 mAActive power kW 1 04 wReactive power L/C KvarL/C 1 06 wApparent power kV·A 4APower factor PF 1 08 x 100Phase-neutral voltage V 2 0A V x10Current A 2 0C mAActive power kW 2 0E wReactive power L/C KvarL/C 2 10 wApparent power kV·A 4C wPower factor PF 2 12 x100Phase-neutral voltage V 3 14 V x10Current A 3 16 mAActive power kW 3 18 WReactive power L/C KvarL/C 3 1A WApparent power kV·A 4E wPower factor PF 3 1C x 100Temperature - oC 50 oC x 10

Table 4.1: Single, Two and Triple phase variables

4.1.2.1 Modbus Protocol

Modbus is an open and royalty free communications protocol originally designed to be used with

programmable logic controllers. Due to its dominance in the industrial market it has become a

standard, protocol which is to this day still updated by an official organization.

Modbus supports the polling of up to 240 devices in the same network, and each device must

be assigned a unique address, which will be used in the request frame. In such networks the

machine doing the polling must be setup as the master in order for the request to be accepted.

We can find the format of the request frame in table 4.2. In order to receive a valid response

the device being polled must have the equivalent to at least 7 character times worth or silence

between each request. The first byte contains the address of the device being polled, the second

byte the code of the function to be performed, and the following bytes contain data pertaining to

Field Length DescriptionStart 3.5c idle 3.5 character times of silenceAddress 8 bits Device addressFunction 8 bits Function codeData n * 8 bits Data size dependant on the message typeCRC 16 bits Frame integrity checkEnd 3.5c idle 3.5 character times of silence

Table 4.2: Modbus RTU Frame Format

23

Measurements

the function at hand.

In order to communicate with the Circutor device over serial, we decided to keep up with the

choice of SmartWatt, that was using the Jamod library TCP component on the legacy system, and

use the Serial component of Jamod to interact with the device.

Figure 4.2: Jamod Sequence

As can be seen in figure 4.2 the Jamod Serial package contains several elements which are

required for the execution of a simple request. ModbusSerialConnection is responsible for the

setup, opening and maintenance of the connection with the serial port, ModbusSerialTransport

is responsible for the transfer of data in the connected layer, while ModbusSerialTransaction is

responsible for the execution and reception of queries and respective responses.

The application needs to first setup the parameters of the serial connection to be established.

These parameters must be in accord to the parameters of the serial port available through the

operating system being used, or the connection will fail to be opened. If the parameters are not

supported by the kernel, such parameters will be ignored when opening the connection. The

parameters used in this case can be seen in table 4.3. As the port name may vary on different

machines depending on the port and type of port used, it is wise to check on the amount of devices

connected to each block of ports available. In our case, if the device was connected directly to the

serial port, as opposed to using a serial to USB adapter, the port name would be ’/dev/ttyS0’.

After setting up the parameters, the connection can be opened. After the connection is estab-

lished, we need to setup the request paramters, which includes the device address, the register to

start reading from and the amount of subsequent registers to read. Since we were using the same

24

Measurements

Field ValuePort name /dev/ttyUSB0Baudrate 19200Databits 8 bitsParity noneStopbits 1 bitEncoding Modbus.SERIAL_ENCODING_RTU

Table 4.3: Modbus Serial Connection Parameters

library as the legacy code, we will use the same frame as used by the TCP request. The request

frame is then written on the connected port, and a response is obtained. After checking the in-

tegrity of the response the connection is finally closed. To ensure a fail safe operation and extend

the existing legacy code, we opted to send a different request for each variable and machine.

4.1.3 MyGenBox

The MyGenBox is a mini computer that was chosen by SmartWatt to serve as a master node in the

Circutor network to poll the devices, process the responses and periodically send the data over the

web to a mongo database on their servers.

4.1.3.1 Hardware & Software

The MyGenBox uses an alix2d2 [myg] system to act as a master on the network. Hardware side

and of relevance to this project the board boasts a 500MHz AMD Geode LX800 CPU and 256MB

of DDR DRAM. For ports we have access to two USB ports, two ethernet ports and a single serial

port. In addition to this, a 4GB flash card was added for semi-permanent storage, in this case

holding the operating system, data logging application and supporting libraries. For the operating

system a slim version of Debian 6.0.6 is being used, with the kernel version at 2.6.32.

During the implementation phase, the usual setup had the development computer connect-

ing through SSH to MyGenBox using putty and a local area connection between machines. The

Circutor device would be interchangeably connected either on the USB or Serial port of the My-

GenBox, that would be connected with its second ethernet port to the internet in order to more

easily download and install the software packages required for development and debugging.

4.1.3.2 TCP-IP to Serial Adaptation

In order to take advantage of a cheaper and more fail safe system a port of the legacy system was

requested. Besides porting the code from the Windows platform to the Linux environment, it was

also requested an adaptation of the code from using an internet connection to transfer data through

TCP/IP to using a serial connection to do so.

Due to differences in how the general architecture of both legacy and new systems were de-

signed, and the necessity of keeping the legacy code for eventual scenarios, the legacy code was

25

Measurements

Field Descriptionid The decimal value corresponding to the hexadecimal value

representing the register where the variable is stored. Ifreading all variables it changes by 2 starting at 0

nBytes Number of bytes needed by the request frame on the datablock

Modbus Mode Modbus function code. For reading variables the code is al-ways equal to 3, which represents the ’Read Holding Reg-isters’ in the modbus protocol

Multiplier Value to multiply the received variable with. If we receiveW and we want to receive KW, we need to set the multiplierat 0.001

Min Minimum value the variable must have. If bellow thisvalue, this reading instance of this variable is ignored

Max Minimum value the variable must have. If above this value,this reading instance of this variable is ignored

Name Name of the variable on the new Mongo databasePSS Variable Name of the variable on the legacy SCADA system

Table 4.4: Device Parameters

expanded upon with a control flag restricting access to the portions of the codebase exclusive to

the serial component, and a portion of the program flow was altered.

The application starts by opening a configuration file containing several parameters needed

for the connection to the SCADA system. It then proceeds to count the files inside a folder called

’equipamentos’, that contains the variables to read from each device. The filename for each device

is according to the format ’deviceId’ + ’.conf’ for file termination. On the device configuration

file, each line represents a different variable to read, and each line contains a set of parameters that

can be consulted on table 4.4. If the line starts by ’#’ that variable will not be polled.

Inside the loop for each device the variables are sequentially polled using the modbus request

frame, that is compatible with both systems. The response obtained is then passed to a decoding

function that reads the response frame and returns a readable value. The legacy system would pair

these values with the variable names, and instantly send them to the SCADA system. In the new

system a data structure that can be seen in image 4.3 is created upon counting the configuration

files. The application creates a single array of arrays that contains a pair of ’variable name’-’value’

arrays for each Circutor device available. Upon decoding a value, if such value is within the

configuration parameters, the corresponding variable in the array is updated, if not, the old one

is kept. A task is set at the beginning of the application to write the whole array into the mongo

database every 15 minutes, starting after the initial 15 minutes of the application running.

4.1.3.3 Linux Problems and Challenges

While porting the code from Windows to Linux several problems arose, not only due to specific

features of the operating system by itself, but also due to changes in the hardware and software

26

Measurements

Figure 4.3: Data Array Structure

components of the data transportation.

Due to the fact that MyGenBox didn’t have a visual environment on which we could run an

IDE, all the coding was remotely written using Notepad++. The JDK had to be manually installed,

and the compilation was done with the Java compiler through putty. The first obstacle occurred

with a missing dependency on compilation, which was later found out was the discontinued Java-

comm package which the serial component of the Jamod library used, but the TCP/IP component

didn’t. Due to Oracle no longer supporting this library, its download and manual installation

proved lengthy and troublesome.

The following problems are, in a way or another, all related to the configuration of the se-

rial port and the use of the Serial-to-USB adapter model PL-2303X, which on the adapter itself

was labeled as PL-2303. Every time a writing attempt of the request frame was presented, the

application would throw an exception regarding the I/O operation.

Using the command

’dmesg’

It was possible to identify that the OS recognized something connected to the USB port seeing in

the response

’usb 2-2: New USB device found, idVendor=067b, idProduct=2303’

Using the command:

’lsusb’

the OS would return

’Bus 001 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port’

27

Measurements

which informed us that the OS had the drivers and correctly recognized the adapter connected

to the USB port as a Serial Adapter PL2303, as is labeled on the hardware itself. Upon further

investigation it was discovered that this model had two different versions, PL2303 and PL2303X,

both of which used the same driver. To identify which was which, it was possible to query the

system for a verbose description of the adapter using lsusb along with the adapter id, such as

’lsusb -v -d 067b:2303’

which would return dozens of lines of info regarding the adapter. If the param ’bMaxPacketSize0’

was equal to 64 this meant that the connected device was a PL2303X, as it happened in our case.

Due to a bug in the drivers included, every version of the Linux kernel pre dating version 2.6.8

would recognize PL2303X as being PL2303, and fail to correctly communicate. An update to

kernel solved this issue.

As referred previously, the application sets up the serial port parameters as in table 4.3, which

must be the same as working parameters of the port in the operating system. To do this we used

a simple application for serial port setup and initialization called ’minicom’, which allowed us to

define a default profile for the serial ports to be used and started with the system boot. For testing

purposes we built our own request frame instead of relying on the TCP request. As a "failed

to write" error persisted, we turned off hardware flow control using minicom, which was known

for preventing correct communication with Jamod. Upon the change, some request frames are

successfully sent, while others fail with the error "failed to read", with no repeating pattern that

would allows us to identify the cause.

With the hardware flow control turned off, the continual transmission of data caused problems

in the buffer. Additionally, the request frame must respect 3.5 characters of silence at the start and

end of each request. Considering the parameters we were using, we can calculate such interval by

using the following formula:

SilenceInterval :8(bits)∗3.5(ct)

19200(bps)= 1.45ms (4.1)

As calculated, it’s safe to assume we need at least 3 ms of inactivity between requests to respect

the modbus protocol, and some additional time to take into account the lack of acknowledgement

protocol implemented on the master machine. To do this we modified the SerialTransaction class

of the IO package of the Jamod library, by forcing a sleep period of the main thread between

the writing of the request and the reception of its response, as can be seen in image 4.4. For the

purpose of this scenario we defined the variable m_Delay at 50 ms.

The final obstacle we faced when trying to write the data to the MongoDB on one of the

SmartWatt servers. The application would fail to connect to the server, as if the instance of said

database was not running or the server was inaccessible. We started by pinging a website like

google.com to assure connectivity to the internet, which proved successful. A ping to the server

adress, however, was not. To debug this, we installed the arp-scan program, which upon calling

the command

28

Measurements

Figure 4.4: Jamod Modification

’sudo arp-scan –interface=eth0 –localnet’

would return a list of all the computers connected in the internal SmartWatt network, including

the server to which the ping would fail. Several hypothesis were tested client side, but it was

later solved server side as the server was not accepting connections of machines with dynamic

addresses, only static ones.

29

Measurements

30

Chapter 5

Web App

In the following chapter we describe in detail the experience obtained and the decision making

behind the implementation of the planned and thought of framework prototype.

In this section, we will talk about the features of the web app and the reasoning behind their

implementation. We will show a step by step demonstration of the work flow behind the web app,

both from the point of view of a group administrator and overseer as well as from the point of view

of an user. We will round up this subsection with the listing of the state of the art technologies

used, which includes not only programming languages and standards, but also some open source

frameworks and libraries.

5.1 PowerGame Application

The PowerGame website is built entirely on NodeJS and supporting libraries following the typical

file structure and workflow of this platform. The client side of the app works as any other website

that takes advantage of HTML5, javascript, jquery and CSS.

5.1.1 WebApp Architecture

The PowerGame webapp follows the typical architecture of a NodeJS app, with the folder structure

that can be seen in figure 5.1 following the one used on the Node-Login example project by

Stephen Braitsch [Noda], which we used as a base to build our app upon.

A typical NodeJS app contains an ’app.js’ file containing settings such as the required libraries

to run the app, port name, rendering engine and other middleware, favicon graphics to be used and

others. In addition to the settings it includes the necessary initialization code to start the server.

This is done by calling ’node app’ from the command line on the root folder. The root folder also

includes an ’app’ folder where most of the app files like html css and js are stored, and in this folder

the file structure has some more liberty as long as the paths are correctly defined in the config files.

In the root there’s still the ’node_modules’ folder where the source code of the required libraries

is stored, and the file ’package.json’ where the developer can define the version of the libraries he

31

Web App

Figure 5.1: Folder Structure for the NodeJS App

32

Web App

wants to see used. To install or update the libraries defined in this file the command ’npm install’

in the root folder will download or update the code into the ’node_modules’ folder.

Inside the app folder we have the code split between the ’public’ and the ’server’ folder, de-

pending of the level of privacy required for the source files. In the ’server’ folder we will find

another core file of nodeJS called ’router.js’, which is responsible for loading and executing server

side code, and routing the user by handling CRUD requests. The private server sided code is stored

in the folder ’modules’ where we have modules such as the account manager, the email dispatcher,

the energy reader and the mission manager. Alongside this folder we have the ’views’ where all

the jade code, that is later compiled to html is stored. This ’views’ folder includes a ’modal’ folder

containing the jade code for the warning pop up windows that show up to confirm the success or

failure of user actions.

Inside the public folder we have the ’css’, ’img’, and ’js’ folders containing the stylesheets,

the graphic resources and the javascript files respectively. Inside the javascript folder we have

a ’controllers’ folder with the jquery code to manage the functionality of some pages, while the

’form-validators’ folder includes the jquery code to assess the correct submission of forms, such

as the restriction of no empty fields or the limit in password length. The folder ’views’ contains

the jquery code responsible for calling the modal pop-up windows and other smaller functions

relating to interfacing with the user.

5.1.2 Organizational Hierarchy

The users of this website will be joining a group upon registration, group that they must belong to

in real life. Internally all the groups follow a hierarchical tree structure that accurately represents

the hierarchy of said groups outside the virtual world in order to facilitate the assignment of tasks

and selection of counsellors. This structure has as a goal to promote social competitiveness and

peer pressure between groups and users within each group.

Using as an example the structure in Figure 5.2, SmartWatt can define at any time (using the in-

game Administration Panel) the master groups, placing them as child groups of Group ZERO. The

administrators assigned for group A and B must be users belonging to these groups, and should

be the people responsible for the interaction with SmartWatt, or be someone totally aware of the

energy saving plan. Each group can create other sub groups directly below them, like subgroup

A1, A2 for A, B1 and B2 for B, B11 for B1, and assign administrators to these subgroups on their

own from its user base. These user aggregations can represent different types of groups, from

manufacturing companies, to schools, to cities or countries or even individual households.

Each group will have a measuring device associated with it, and the performance values to be

calculated will consider an aggregate of all values in the direct child nodes, allowing for multiple

levels of competition and management to occur at the same time.

This abstracted way of representing and organizing users amongst groups in a hierarchical

way allows the web app to be used in a multitude of different contexts that require a top-down

distribution of tasks and sharing of knowledge, acting as middle ware to support serious games for

energy management.

33

Web App

Figure 5.2: Group Structure

5.1.3 Database Architecture

As can be seen in fig 5.3 the MySQL database schema used for the backend of the PowerGame

webapp is comprised of only five tables.

Figure 5.3: Database Schema for PowerGame

The ’user’ table is the central point of data and data in the system. It includes a flag called

’idAdminOf’ that is null for a regular user and has the id of the group he administers otherwise.

34

Web App

There’s a date and time stamp called ’timeOfLastLogin’ that facilitates the reward of players that

login in consecutive days. We have other variables such as those responsible for tracking progress

like ’CurrentStars’ and ’ePoints’.

The ’groupt’ table hold simple information about the group name and the id of its parent

group. The ’mission’ table holds the name, description and difficulty of the mission. The difficulty

corresponds to the amount of stars the user will be rewarded upon successful completion of the

mission. The ’missionLog’ holds every log sent by the users. This log contains a message called

’content’ sent by the user, the ’date’ when it was sent that’s used to order messages on the admin

panel, and an ’acknowledged’ flag to allow admins to clear the logs from their workflow.

The final table, ’userlogintracking’ registers the login patterns of every user and it is intended

exclusively for use in the test scenarios, to assess the influence of toggling gameplay elements like

the daily login in the regularity of visits by the user.

5.1.4 WorkFlow

As can be seen with figure 5.4 both users and admins access their section of the website through a

common login page.

Figure 5.4: Login Screen

When opening the app, every user is faced with this page, unless they’ve already logged in

before, in which case they will be automatically redirected to the appropriate section.

35

Web App

5.1.4.1 Admin Panel

In this subsection we will go through an example of the website use through the perspective of an

administrator. The first step is to register through the appropriate form as can be seen in figure 5.5,

which is accessible from the login screen. As can be seen the sign up process requests as few info

as simple as possible, and the user is needs to choose the group he belongs to. This admin joined

the group ’FEUP’, which was previously created by a higher up as can be seen in image A.2.

Figure 5.5: Admin Signup

This administrator upon registration is still a regular user. To have access to the administration

panel of the group he belongs to, another admin with a higher level access (belonging to his parent

group or groupZero) will need to approve and promote his credentials as can be seen in figure A.1.

After being promoted the admin can now create a mission or task for the players of its group

to accomplish. As can be seen in figure A.3 the admin needs to insert the name of the mission,

a description, and a assign it a difficulty level. By default the mission will be activated upon

creation, unless the option is actively toggled off. The admin can also select a mission to activate

from a set of pre created inactive missions, as can be seen in figure A.4.

During the mission duration the administrator can see and acknowledge the logs sent by the

users for each mission. As can be seen in figure A.6 a drop down list is available for the admin

to select a log that includes the name of the user who sent it, a description of the mission, and

the text written by the user, with a time and date stamp of when it was sent. The admin can then

acknowledge this log to clear from it from the list of pending logs.

After enough time has passed and conclusive data has been gathered to support the decision,

the admin can mark a mission as a success or a failure, as can be seen in figure A.5 Every user

36

Web App

participating in the mission will receive the corresponding reward if it was a success, or nothing if

it failed to accomplish its goals.

The tasks are grouped into three different tabs, ’Group Management’, ’Admin Management’

and ’Mission Management’, each containing a drop down selection. Upon success or failure on

the submission of the forms, a modal prompt shows up informing the administrator.

5.1.4.2 User Panel

In this subsection we will go through an example of the website use through the perspective of a

regular user. Upon login he gets redirected to the game panel, as can be seen in figure 5.6. If the

user logged in yesterday a thumbs up notification will show as can be seen in figure A.7, and the

user will be rewarded.

Figure 5.6: Game Screen

The final game screen follows the same structure as the one delineated in the concept phase,

with most of the area occupied by the visual feedback space, a graph of the consumption levels on

the botton, and a set of buttons on the right. On the top right we have the ’Sign Out’ button, to its

left the amount of stars the user achieved, and to its left the amount of ePoints he accumulated. On

the right column the user can find a ’See Missions’ button with a small notification warning him

of the amount of active missions. The result of clicking this button can be seen in figure 5.7.

Bellow that the user has access to a ’Send Log’ button that allows him to communicate with

the group admin. Clicking on that button brings up the form as can be seen in figure A.8.

37

Web App

Figure 5.7: The Active Missions

5.1.5 Non Implemented Features

Of all the non implemented features, the most obvious ones are those related to the visual feedback

system and comparison of performance between groups. The detailed list is as follows.

Tiles The tiles representing the performance obtained on each time interval.

Tile Details The tile details panel that showed the energy consumed and respective time when

said consumption occurred.

Graph Background The graph background color representing the performance of the user group.

Performance Comparison The page where users could compare their group performance with

the other groups.

5.1.6 Implemented Features

Besides the features already talked about in the concept fase, to complement the changes in the

initial plan, a set of features were introduced in the web app, most of which are those included in

the Administration Panel.

Daily Login When a user logs into the website in consecutive days he receives a reward in the

form of ePoints, after getting a visual thumbs up on the screen.

38

Web App

Send Log The user can send a Log pertaining to his influence on the success or failure of a specific

mission.

Add Group The admin can add a child group to the group he himself controls. This group must

have an unique name.

Add Admin The admin can promote the user of a specific group to become an admin of said

group. This can only be done for users of the same group as the admin, or to users belonging

to child groups of the one the admin belongs to.

Add Mission The admin creates a mission that the users can participate in. At the time of creation,

the mission doesn’t need to be active (meaning, it doesn’t need to be available for users to

play). An inactive mission can be activated and be played by any group, not only those

directly related to the one the admin belongs to.

Activate Mission Activate an inactive mission so it becomes playable by the group the admin

belongs to.

Finalize Mission Acknowledge the mission as successful or failed depending on the actions of

their players. After finalizing a mission rewards are automatically distributed amongst play-

ers and the mission becomes inactive.

See Logs See the unacknowledged logs sent by users. These logs contain the name of the user,

the mission it relates to, a text description written by the user and an option to acknowledge

it or not. Acknowledged logs will not show up on the ’See Logs’ window.

39

Web App

40

Chapter 6

Tests and Results

This initial prototype for the PowerGame web app was planned to be tailored to and tested with a

set of schools that already had measurement devices installed and baseline values calculated, but

due to changes in availability and other problems the test subjects had to be changed and some

features initially planned had to be dropped, while others were introduced. The plan was changed

to include a small test group, and the prototype has currently access to a single set of Circutor plus

MyGenBox devices measuring the energy values of 3 computers connected to an extension cord

in the SmartWatt Academy room, a place where interns and new IT hirees get accustomed to the

work pace of the company. In this chapter we will talk about the results of this test situation and

possible test scenarios to be carried out in the future.

6.1 Data Testing

In the room where the SmartWatt Academy is located, a single Circutor Device + MGB combo

was setup measuring an extension cord with three work computers connected to it. The MGB was

remotely monitored using a Cisco VPN system from outside the SmartWatt headquarters. This

testing scenario allowed us to understand the possible problems of having a remote measuring

device on a common workplace, and the problems that might occur with web connectivity, power

outage, loss of connectivity between devices and other interferences. As all the energy consuming

devices connected to the measurement device were work computers required for the productivity

of the company (and therefore, cannot be turned off to save energy) this test scenario comprised

of a maximum efficiency closed system, allowing us to focus on the data collection side of the

problem.

In figure 6.1 we have a graph of the instant consumption over time, measured in Volts (V). As

can be seen it oscilates between 229V at the lowest and 235V at the highest, which is a minimal

variance that can be attributed to the variance of energetic need of a computer executing tasks with

different performance needs, and therefore not under the direct control of the user.

The first problem occurred with a power outage on the SmartWatt headquarters during the

beginning of a work week, which led to a several day blank after the power outage was solved

41

Tests and Results

Figure 6.1: Data Graph of the Instant Consumption Variable

with no measurements, as the measuring app had to be manually restarted. To solve this a shell

script was added to be run on boot executing the app.

The stable execution of the app was also dependent of the non interference of external users

on the wiring connecting the devices and the electric plug. In the future, the setups consisting of

this device combos will need to be secured in a static and inaccessible place with reinforcement

on the connections to prevent the need of repeated voyages by SmartWatt collaborators to fix the

installation. In addition, the app itself suffers from a critical bug that makes it crash at random

times and during testing required constant supervision.

A major problem in the coherence of data itself resulted due to the SmartWatt test server being

inaccessible on some days, which considering the energetic variable being used, accumulated

consumption, resulted in a discrepancy in the viewing graph. With 3 computers connected to the

measuring device, the graph should consist of a very slow, but constantly growing line. Due to the

MGB being unable to write to the database between Friday and Wednesday, but the device still

measuring the accumulating energy consumption during this time, the graph suffered a sudden

peak on the first measurement he was able to write to the database. In the future measures need to

be taken in order for the app to store the variables when the database is unavailable, syncing the

values when it can.

In figure 6.2 we have a graph of the accumulated consumption over time, measured in Kil-

loWatts per Hour. This variable is stored on the measuring device, and doesn’t require a poll from

the MGB to exist. Due to this fact, and knowing that we had a constant set of machines being

measured, if the MGB was working at 100% reliability we would expect to get a graph with a

42

Tests and Results

Figure 6.2: Data Graph of the Accumulated Consumption Variable

constant and linear rate of growth. Because the graph represents the accumulated value, even a

perfectly reliable setup will need additional processing to get the real consumption value between

a given interval, and this is done by subtracting the last measurement to the current one.

The values on the graph are the values that we managed to save on the database, and due to the

aforementioned problems do not correspond to measurements at regular intervals. This can be seen

with periodic spikes on certain sections of the graph. The first major spike can be attributed to the

power outage, the wavy line attributed to interferences with the measuring devices and instability

with the app, and the smaller two spikes to the couple of days where the MGB was unable to write

to the database, as previously explained.

6.2 Test Scenarios

The following test scenarios were designed to be carried out in a non efficient closed system with

multiple measurement devices. The purpose of these tests is to assess the influence of several

game elements over the actions of its users, such as the regularity of visits over a long period of

time and their behaviours in regards to energy management.

6.2.1 T1 - Login Regularity

This test scenario has as a goal to assess the influence of the ’Daily Login’ feature on the regularity

of the users return to the website over a long period of time. As previously stated, the users interest

43

Tests and Results

of any product tends to fall off over time, and as such it is in our best interest to find ways to

attenuate this factor.

For a more accurate set of results, this test needs to be performed when the falloff of users

interest has stabilized. To track the users login patterns we have the table ’userlogintracking’ that

stores a date and time stamp every time the user logs into the website. The record has a flag

that distinguishes a manual login, when the user actively inserts its login information, and the

automatic login for when the user refreshes a page or comes back after closing it some time after

its first active login, as long as he had the ’remember me’ option toggled on.

When the conditions are met, we can disable the ’daily login’ feature and see how it affects

users behaviour when it comes to regularly visiting the web page. The compared values must be

on an equivalent time frame and time location, meaning the interval at which we group logins (for

example at x manual logins per day) and the time at which it occurs (for example, x manual logins

on Friday week Z and x manual logins on Friday week Y).

The expected results are a reduced number of manual logins some days after the termination

of the feature.

After enough data is gathered, the feature can be reinstated, and after notifying the users by

email we can assess if the login numbers return to the frequency values attained before the change.

6.2.2 T2 - Mission Influence

This test scenario has as a goal to assess the influence of the missions on the behaviour of users in

regard to energy management.

For a more accurate set of results, this test needs to be performed with two groups simulta-

neously. Both groups must have completed a mission successfully before, and they must both

be aware through the instructions of the counsellor that the goal is always to improve energetic

efficiency.

When the conditions are met, we can assign only one of the groups a mission and see how the

constant notification of a goal to achieve and the hint on how to do it on the game screen influences

the users to take action and save energy.

The expected results are different performance levels from each group, with the group that has

no access to the mission performing poorly when compared to the group who has access.

6.2.3 T3 - Mission After burn

This test scenario has as a goal to assess the efficiency of missions as a learning mechanism, by

testing the long term influence of the missions on their behaviours.

For a more accurate set of results, this test needs to be performed with a group that has com-

pleted a mission successfully before, and its users must be aware through the instructions of the

counsellor that the goal is always to improve energetic efficiency.

When the conditions are met, we can assign this group a mission that will last a fixed time

interval, with different groups having the duration of the mission increase. If the groups succeed

44

Tests and Results

in saving energy, completing the mission, the mission shall be terminated and the behaviour of the

users tracked during the weeks following the termination, for the duration the mission was active

previously.

The expected results are for groups with a longer mission duration to extend their practices

beyond the regular duration of the mission and merge those practices into their daily routine,

thus having increased long term performance in energy saving even when not interacting with the

application.

6.2.4 T4 - Reward Influence

This test scenario has as a goal to assess the influence of the mission rewards on the willingness

of users to complete said missions successfully.

For a more accurate set of results, this test needs to be performed with more than one group

that have completed a mission successfully before, and are aware of the rewards the successful

completion of said tasks entail.

When the conditions are met, we can disable the rewards to half of the groups selected for the

duration of several missions, and see how their performance evolves over time.

The expected results are for groups with no rewards received to start having a negative impact

in performance over time, and to drop the regularity at which they visit the website.

After enough data is gathered, the feature can be reinstated, and after notifying the users by

email we can assess if the performance numbers return to the values attained before the change.

45

Tests and Results

46

Chapter 7

Conclusions and Future Work

In this chapter we will finalize the rationale behind this project, talking about what we proposed

to accomplish and to what degree of success it was achieved, while drawing some conclusions

related to the testing done. We will end this chapter by giving some pointers on the several avenues

possible to be followed in future work.

On the beginning of this thesis we proposed to design a system that would serve as support for

serious games by interfacing the energy measurement done in real life with a related network of

users in a virtual world. This system was split into three components, all of which fulfilled their

purpose, with the visual component missing some features.

To understand how to do such interfacing we studied a series of serious games that aimed to

achieve something similar, and by listing a side by side comparison of the positives and negatives

of such apps we extrapolated under what mould should the interface with the user work.

The data logging tool, that had as a purpose the logging, syncing and storage of all measure-

ment data, proved to have several flaws that easily influenced the expected output and demanded

a series of adaptations that were in some cases still vulnerable to external influences.

The web app, that allows administrators to self manage the groups they belong to, proved to

be generic enough to adapt to different kinds of groups, and the logging tool proved to be effective

in the effort of allowing regular users to report back their actions to an administrator, while being

associated with a mission.

From the testing phase we conclude that the accuracy of consumption values are very sus-

ceptible to failures caused by external factors. The sensitivity of devices coupled with the high

dependency level of the web app in the use of consumption values as input leads to a higher degree

of failure in the app output. All of these external factors can be categorized into three different

types:

Software Errors in measurement caused by a software bug. Such examples include variable inac-

curacy, mismanagement of memory, software crashes or other programming related bugs.

47

Conclusions and Future Work

Hardware Errors in measurement caused by a hardware failure. Such examples include device

failure, higher than normal temperatures, burnt components or other hardware related prob-

lems.

Environmental Errors in measurement caused by environmental factors. Such examples include

power outages, wiring disconnections, amongst other external problems.

Through the work done during the testing phase we conclude that these three types of factors

can be alleviated by the use of several measures that can be split into three different categories,

which are as follows:

Temporary backup A local or remote buffer of data that allows the system to temporarily store

the information during a period of time where one or more components of the system fails,

so it can sync in the future when the system becomes operational.

Automatic Reboot A reboot procedure that allows components of the system to be automatically

re-initiated in case of failure.

Data Post Processing A post processing procedure that uses extra fields of the data to normalize

the corrupted or missing entries in the historical records.

By acknowledging what factors affect our system we can, by using these measures, minimize

the influence of data deviation in our prototype testing.

The visual interface purpose of allowing the users to easily understand their consumption

levels proved ineffective due to lack of implementation of the simplified version and lack of date

labels on the complex graph.

7.1 Future Work

After a new set of measuring devices are installed in the schools, which is expected to occur

in the following months, work can continue on the feedback and competition system, which are

dependant on the existence of multiple independent groups and the participation of environments

with a non maximum energetic efficiency.

After this is done the test scenarios delineated in the previous section can commence in order

to validate the conceived hypothesis on the influence of serious games in learning and long term

behaviour, and to confirm the efficacy of the prototype concept when it comes to achieve this goal.

In the future the platform will continue to be developed, with the next step being the creation

of a web API that will allow third party games to access information about users energetic perfor-

mance. This API will be based on a communications protocol that is going to be developed as a

thesis work under SmartWatt guidance in the following months.

After the communications protocol and API are implemented, a proof of concept game can

start its development to prove the viability of the whole system as a social gaming and learning

platform for energetic efficiency.

48

Appendix A

Apendix I

In the following appendix we list some extra tables that were too big or not relevant enough to be

in the middle of the text.

Figure A.1: User Being Promoted to Admin

49

Apendix I

Paremeter Symbol Code UnitsActive power III kW III 1E wInductive power III KvarL III 20 wCapacitive power III kvarC III 22 wCos Phi III Cos Phi III 24 x 100Power Factor III PF III 26 x 100Frequency Hz 28 Hz x 10Voltage line L1-L2 V12 2A V x10Voltage line L2-L3 V23 2C V x10Voltage line L3-L1 V31 2E V x10% THD V L1 % THD VL1 30 % x 10% THD V L2 % THD VL2 32 % x 10% THD V L3 % THD VL3 34 % x 10% THD A L1 % THD AL1 36 % x 10% THD A L2 % THD AL2 38 % x 10% THD A L3 % THD AL3 3A % x 10Apparent power III KvaIII III 42 wMaximum demand Md (Pd) 44 w/VA/mAThee-phase currrent (average) A.AVG 46 mANeutral currrent In 48 mAMaximum Demand A2 Md (Pd) 52 mAMaximum Demand A3 Md (Pd) 54 mAActive energy kW.h III 3C w.hInductive reactive energy kvarL.h III 3E w.hCapacitive reactive energy kvarC.h III 40 w.h

Table A.1: Aditional variables

50

Apendix I

Figure A.2: Group Criation

51

Apendix I

Figure A.3: Admin Creating Mission

52

Apendix I

Figure A.4: Mission Activation

53

Apendix I

Figure A.5: End Mission

54

Apendix I

Figure A.6: Acknowledge Log

55

Apendix I

Figure A.7: Daily Bonus

Figure A.8: Sending a Log

56

References

[BGK07] M. Bang, A. Gustafsson, and C. Katzeff. Promoting new patterns in household energyconsumption with pervasive learning games. Persuasive Technology, pages 55–63,2007.

[BHKH11] E.J. Boyland, J.A. Harrold, T.C. Kirkham, and J.C.G. Halford. Persuasive techniquesused in television advertisements to market foods to uk children. Appetite, 2011.

[BM77] Albert Bandura and David C McClelland. Social learning theory. 1977.

[BTK06] M. Bang, C. Torstensson, and C. Katzeff. The powerhhouse: A persuasive computergame designed to raise awareness of domestic energy consumption. Persuasive Tech-nology, pages 123–132, 2006.

[cir] Circutor mini manual. http://circutor.com/docs/m98174001-03-05a-mini.pdf. Accessed: 27/05/2013.

[CLH+11] H.M. Chen, C.W. Lin, S.H. Hsieh, H.F. Chao, C.S. Chen, R.S. Shiu, S.R. Ye, andY.C. Deng. Persuasive feedback model for inducing energy conservation behaviors ofbuilding users based on interaction with a virtual object. Energy and Buildings, 2011.

[Del12] Deloite. Insights into corporate energy management trends. Deloitte reSources 2012Study, 2012.

[Fog02] B. J. Fogg. Persuasive technology: using computers to change what we think and do.Ubiquity, 2002(December), December 2002.

[Htm] Game EnGines bebraw/jswiki wiki github. https://github.com/bebraw/jswiki/wiki/Game-Engines. Accessed: 04/02/2013.

[myg] Alixd2d specs. http://www.pcengines.ch/alix2d2.htm. Accessed:27/05/2013.

[Noda] node-login github. https://github.com/braitsch/node-login. Accessed:05/06/2013.

[Nodb] Nodejs for dummies. http://thatextramile.be/blog/2011/12/node-js-for-dummies/. Accessed: 05/06/2013.

[pl2] Pl2303x manual. http://www.prolificusa.com/pdf/PL-2303XA.pdf.Accessed: 27/05/2013.

[RC10] J.E. Russo and A.S. Chaxel. How persuasive messages can influence behavior withoutawareness. Journal of Consumer Psychology, 20(33):8–342, 2010.

57

REFERENCES

[Tho06] Siobhan Thomas. Pervasive learning games: Explorations of hybrid educationalgamescapes. Simulation & Gaming, 37(1):41–55, 2006.

58