Project Domus: Designing Effective Smart Home Systems

Project Domus: Designing Effective

Smart Home Systems

This project manual is submitted as partial fulfilment of the requirements for the BSc in
Information Systems and Information Technology (DT249) to the School of
Computing, Faculty of Science, Dublin Institute of Technology.









Author: Paolo Carner, D08117953
Supervisor: Michael Gleeson, School of Computing
Date: 18 April 2009
Project Domus: Designing Effective Smart Home Systems
2

Acknowledgments
I would like to thank my supervisor Michael Gleeson for his guidance, time and support
throughout the project. My friend and colleague Massimiliano Balsamo for his
suggestions about the applications user interface. A sincere thanks also goes to my
wife Giorgia for all her patience, dedication and encouragement over the past months.
Project Domus: Designing Effective Smart Home Systems
3

Abstract
The subject of this work is the analysis and design of a proof-of-concept Temperature
Control System (TCS) part of a Smart Home. The TCS also implements an early-
warning Fire Alarm sub-system that uses a Bayesian Network to infer the likelihood of
a fire. The application is implemented using Visual Studio 2005, using a hardware and
software kit provided by Echelon Corp. The Bayesian Network implemented is Netica
from Norsys Corp.

Keywords: Smart Home, Home Automation, Bayesian Networks.

Project Domus: Designing Effective Smart Home Systems
4

TableofContents

1. Introduction .............................................................................................................. 8
1.1. Project Aim and Objectives.................................................................................. 8
1.1.1. Aim................................................................................................................... 8
1.1.2. Objectives......................................................................................................... 8
1.2. Intellectual Challenge........................................................................................... 8
2. Literature Review..................................................................................................... 9
2.1. Definition.............................................................................................................. 9
2.2. History.................................................................................................................. 9
2.2.1. The Mechanical Revolution ............................................................................. 9
2.2.2. The Electrical Revolution............................................................................... 10
2.2.3. The Information Revolution........................................................................... 12
2.3. Smart Homes Today........................................................................................... 13
3. Research ................................................................................................................. 16
3.1. Components of a Smart Home System............................................................... 16
3.1.1. Control Systems ............................................................................................. 17
3.1.2. Actuators ........................................................................................................ 17
3.1.3. Home Network ............................................................................................... 18
3.2. Communication Protocols .................................................................................. 19
3.2.1. X10 and its Legacy......................................................................................... 19
3.2.2. Other Protocols............................................................................................... 21
3.3. The Market for Smart Homes............................................................................. 23
3.3.1. Potential Benefits............................................................................................ 24
3.3.2. Reported Needs and Concerns........................................................................ 26
3.4. Design Challenges.............................................................................................. 28
3.4.1. Gathering Valid System Requirements .......................................................... 29
3.4.2. Choosing the Right Technology..................................................................... 32
3.4.3. The Quest for the Effective User Interface..................................................... 33
3.4.4. The Role of Artificial Intelligence ................................................................. 36
3.4.5. Going Beyond Home Automation.................................................................. 39
4. Development .......................................................................................................... 41
Project Domus: Designing Effective Smart Home Systems
5

4.1. Analysis .............................................................................................................. 41
4.1.1. Business Requirements................................................................................... 41
4.1.2. Determining a User Profile............................................................................. 41
4.1.3. Gathering User Requirements ........................................................................ 42
4.1.4. Use Case Diagrams ........................................................................................ 43
4.1.5. Functional Requirements................................................................................ 44
4.1.7. Glossary.......................................................................................................... 59
4.2. Design................................................................................................................. 61
4.3. Implementation................................................................................................... 69
4.3.1. Hardware ........................................................................................................ 70
4.3.2. Software.......................................................................................................... 75
4.4. Testing................................................................................................................ 84
4.4.1. Test Plan......................................................................................................... 84
4.4.2. Test Cases....................................................................................................... 87
4.4.3. Functional Requirements Implemented in POC............................................. 89
4.4.4. Bug Report ..................................................................................................... 91
4.4.5. Test Outcomes................................................................................................ 92
5. Conclusion.............................................................................................................. 93
5.1. Summary of the Work ........................................................................................ 93
5.2. Project Findings.................................................................................................. 94
5.3. Recommendations for Future Work................................................................... 94
5.4. Learning Outcomes ............................................................................................ 95
5.4.1. Research ......................................................................................................... 95
5.4.2. Analysis .......................................................................................................... 95
5.4.3. Technical ........................................................................................................ 95
5.4.4. Project Management ....................................................................................... 96
5.4.5. Lessons Learned............................................................................................. 96
References ...................................................................................................................... 97
Appendices ................................................................................................................... 100


Project Domus: Designing Effective Smart Home Systems
6

FiguresandTables

Figure 1 Advertisement for a Washing Machine, Daily Mail (1955) ..................................... 11
Figure 2 Adoption of new technologies over time .................................................................. 12
Figure 3 Picture of a Xanadu House........................................................................................ 14
Figure 4 Sensor and Actuator Interaction................................................................................ 17
Figure 5 X10 Zero-Crossing Signal Transmission.................................................................. 20
Figure 6 Rogers Technology Adoption Lifecycle.................................................................. 23
Figure 7 Components of Software Requirements ................................................................... 30
Figure 8 Implicit and Explicit Communication Channels....................................................... 35
Figure 9 Causal Graph............................................................................................................. 38
Figure 10 Bayesian Network................................................................................................... 39
Figure 11 System Overview.................................................................................................... 44
Figure 12 Sub-Systems Overview........................................................................................... 54
Figure 13 Operating the System.............................................................................................. 62
Figure 14 User Authentication ................................................................................................ 63
Figure 15 User Administration................................................................................................ 64
Figure 16 Managing Devices................................................................................................... 64
Figure 17 Managing Teams..................................................................................................... 65
Figure 18 Managing Schedules ............................................................................................... 66
Figure 19 Managing Events..................................................................................................... 67
Figure 20 Dispatching Commands .......................................................................................... 67
Figure 21 Flight Control Sub-System ..................................................................................... 68
Figure 22 Inference Engine Sub-system ................................................................................. 69
Figure 23 How LonWorks Devices exchange Messages ........................................................ 70
Figure 24 Anatomy of a LonWorks Device ............................................................................ 71
Figure 25 Network Variables .................................................................................................. 72
Figure 26 A Typical LonWorks Solution................................................................................ 73
Figure 27 The Mini EVK Evaluation Kit ................................................................................ 74
Figure 28 Mini-Gizmo I/O Board............................................................................................ 76
Figure 29 Main Screen of the POC System............................................................................ 77
Figure 30 Add Device Dialog Box.......................................................................................... 78
Project Domus: Designing Effective Smart Home Systems
7

Figure 31 EVK Service Switch ............................................................................................... 78
Figure 32 Fire Alarm Sub-system Settings ............................................................................. 79
Figure 33 Logic Flow for the FA Sub-system......................................................................... 79
Figure 34 HVAC Sub-System Settings ................................................................................... 80
Figure 35 Logic Flow for the HVAC Sub-system................................................................... 80
Figure 36 Causal Graph for the FA Sub-system..................................................................... 82
Figure 37 Fire Alarm Bayesian Network ................................................................................ 84

Table 1 Examples of Smart Home Applications ..................................................................... 25
Table 2 Classifying the Voice of the Customer....................................................................... 30
Table 3 Defining User Input.................................................................................................... 43
Table 4 Functional Requirements............................................................................................ 46
Table 5 Functional Requirements grouped by Sub-system..................................................... 55
Table 6 MGDEMO Attributes and Methods........................................................................... 75
Table 7 Mapping Real-world Devices to the POC.................................................................. 76
Table 8 BN Nodes and Relationships...................................................................................... 82
Table 9 Test Plan Risks and Contingencies ............................................................................ 87
Table 10 Summary of Test Results ......................................................................................... 87
Table 11 List of Functional Requirements Implemented........................................................ 89
Table 12 Bug Report ............................................................................................................... 91



Project Domus: Designing Effective Smart Home Systems
8

1. Introduction
This chapter presents the projects aim, objectives, and its intellectual challenge.
1.1. ProjectAimandObjectives
1.1.1. Aim
The aim of this project is to develop a proof-of-concept prototype for a Smart Home
system that will address some of the challenges emerged during the research.
1.1.2. Objectives
The project has the following objectives:
Providing a brief history of the underlining technology
Presenting an overview and an evaluation of existing standards
Investigating potential benefits and documenting perceived issues
Researching current challenges
Designing and building a proof-of-concept
1.2. IntellectualChallenge
Although the project will consider proper Human-Computer Interaction (HCI)
techniques to provide users with a user-friendly interface, it will also aim at improving
the effectiveness of Smart Home systems. The Oxford Dictionary describes
effective as: producing a desired or intended result (emphasis added). According
to this definition, it is envisaged that an effective Smart Home shall not only carry out
automated actions on the users behalf, but be asked to interpret, understand and, if
possible, anticipate what users might also intend to do. Elements of Artificial
Intelligence, such as decision theories and adaptive systems, may be able to provide
these capabilities.
Project Domus: Designing Effective Smart Home Systems
9

2. LiteratureReview
This chapter presents a definition of Smart Home, provides a brief history of the
technologies contained, and outlines recent developments in the field.
2.1. Definition
A common definition of Smart Home is of an electronic networking technology to
integrate devices and appliances so that the entire home can be monitored and
controlled centrally as a single machine (Pragnell et al., 2000). Another term that
describe the same technology is domotics, which derives from the Latin word domus,
meaning home, and informatics, meaning the study of the processes involved in the
collection, categorization, and distribution of data. However, since this technology is
still very much in flux, other terms are also used in the literature with equivalent
meaning, such as: home automation, smart house, digital home or electronic
home. Furthermore, note that, although the terms house and home have a
different meaning in the English language, they are often used alike in this context.
2.2. History
Although the term smart home was first used in 1980s, the concept is far from new.
The early documented attempt to envisage something very similar dates back to the
1960s, with Walt Disneys Experimental Prototype Community of Tomorrow
(EPCOT), presented in 1966
i
. A Smart Home will not be able to accomplish much
without appliances to control, nor will it be able to communicate to these devices in the
absence of a control network (home network). Since appliances and home network
are so interlinked with a Smart Home, the following sections provide a brief history on
how these come into being.
2.2.1. TheMechanicalRevolution
The first question that might come to mind is why we would need a Smart Home and
why we would want to find different ways of doing ordinary things, such as washing
clothes, cooking, or even turning a light on or off. A similar question could have been
asked at the beginning of the 20
th
Century, at the dawn of what can be called the
mechanical revolution.
Project Domus: Designing Effective Smart Home Systems
10

In late 1800s, the middle class was experiencing a shortage of domestic servants which
created the need to find new ways to provide help in the home (Harper, 2003). Such
necessity was the initial driving force behind the inventions of the first domestic
appliances, which had the purpose of making household chores easier and do more with
less.
In 1911, Frederick Winslow Taylor published The Principles of Scientific
Management, which advocated the use of efficiency to maximize results through
minimal effort. This theory is today known as Taylorism and, though it was originally
intended to be applied in industrial settings, this concept soon spilled over into the
domestic realm due to the need at hand.
Christine Frederick was one of the first to recognize that the challenges tackled by
Taylorism were also directly applicable to domestic issues and captured these in her
book Household engineering: Scientific Management in the Home, published in
1915. In her book, Frederick predicts that mechanical appliances would be the ones
which were to take up the work originally performed by servants where every possible
purely manual task is done by arms of steel and knuckles of copper. She also puts
forward the idea of a Smart Home where she foretells that such machinery will be far
more unified than at present with various pieces related to one another, as reported
by D. Heckman (2008).
2.2.2. TheElectricalRevolution
In spite of the first inventions, most of this new domestic technology would have still
been easily recognized by people who had lived in the pervious Century. However,
electricity, the driving force behind the electrical revolution, would soon to change this
familiar landscape beyond recognition.
Electrical energy first arrived in the homes around 1920s and, although initially used
for lightning purposes only, by 1940s mains electricity was readily available to around
65 per cent of the total of houses in the UK. (Harper, 2003). Soon after it reached a
critical mass, producers of electrical appliances inundated the market with all sorts of
items. Although some of them were nice-to-have-devices, such as electric popcorns
poppers, egg cookers and waffle irons, others were really life changing for the
household: refrigerators, washing machines, electric cookers, vacuum cleaners, just to
mention the most important.
Project Domus: Designing Effective Smart Home Systems
11

Regardless of their importance, all these electrical appliances were still made with the
original need in mind, which was often reminded to people as producers marketed these
products with time-saving slogans such as no longer tied down by housework or
automatically gives you time to do those things you want to do (Heckman, 2008).
Figure 1 shows example of these early campaigns: a 1950s advertisement about a
washing machine with the slogan automatically gives you the time to do the things
you want to do.


Figure 1 Advertisement for a Washing Machine, Daily Mail (1955)
It is interesting to note how some later devices could be hardly classified as time savers
and how, in spite of this, they were still quite readily adopted. By early 1980s, around
65 per cent of UK homes had a colour television set and half of them a video recorder
(Harper, 2003). More interesting still, the adoption curve was different from one to
another, sometimes regardless of the comfort that they could bring. For example,
central heating, took comparatively a while longer to become widespread that the color
television. Figure 2, taken from the research The Market Potential for Smart Homes,
shows the adoption curve of some of the most common electrical devices in the
household (Pragnell et al., 2000).

Project Domus: Designing Effective Smart Home Systems
12


Figure 2 Adoption of new technologies over time
1

2.2.3. TheInformationRevolution
Disneys original vision for EPCOT was to create both a laboratory for new technology
and a home for its inhabitants with the promise of offering an integrated living
environment (Heckman, 2008). Due to his untimely death, just a few months after the
official presentation of the project, EPCOT was never implemented, at least not in its
original idea.
The concept behind the original vision was however to live on. In the 1960s, a number
of hardware and software innovations made possible for home owners to have access to
the first computer-like appliances in their homes. Perhaps the first attempt to create a
home automation system occurred in 1966 when Westinghouse proposed the
experimental and quite bulky Electronic Computing Home Operator (ECHO) IV.
Although the original system was supposed to automate the family finances, it was
soon extended to include recipes, shopping lists, family inventory, and, in its final
versions, added home temperature control and the ability to control appliances.
In 1975, it was the turn of the Altair 8800, followed by the Apple II in 1977 and the
IBM PC in 1981. While these computers were slowly finding their ways into the home,
they also contributed to the creation of the idea of smart machines.


1
Source: General Household Surveys 1972-98, BARB, BT, Oftel, ITC, BskyB, ONS. Note: Data refer to
percentage of households for all goods except mobile phones, which refers to percentage of population.
Project Domus: Designing Effective Smart Home Systems
13

In 1978, after a few years of experimentation and refinement, PICO Electronics
patented the X10 technology. This technology can be considered the first home
network as, differently to other networks available at the time, it enabled the existing
electrical wiring in anyones home to also be used as the media for the communication
network. By doing so, X10 made home automation a reality for the majority of the
household at an affordable price.
Nowadays, an increasing number of houses have home computers, game consoles and
always-on Internet connections that extend the availability of services and resources to
the household beyond the physical boundaries of the home.
2.3. SmartHomesToday
The Oxford Dictionary defines smart as both stylish and fresh in appearance, having
a quick intelligence, and being fashionable and upmarket. Sony was among the first
companies to attach the smart buzzword to a computer when, in 1982, it marketed the
Smart Sony computer: no longer advertised simply as a home computer, but tried
to cash in on the smart concept by selling it as a device which could help you make
smarter business decisions (Heckman, 2008).
The smart concept has become since a marketing catchword, still employed today, to
sell a wide range of products, hence: smart phones, smart cameras, smart design,
smart bombs and smart homes. Usually, the word define devices that are reportedly
based on cutting-edge design that unite innovation with practical simplicity, However,
as this would soon be demonstrated, sometimes marketing buzzwords alone cannot
guarantee the sell.
Xanadu was the first example of a mass-produced Smart Home. Built throughout the
1980s in the US around the original EPCOT idea, these houses were commercially built
dwellings that made extensive use of Smart Home technologies. To look even more
futuristic, the actual house was made entirely of polyurethane foam. The Xanadu home
had a computer that monitored and controlled all its systems: the kitchen, living room,
bathrooms, and bedrooms all had their own electrical and electronic devices to control
the appliances present in the house. For example, the shower could be set to be turned
on at a specific time and a set temperature. The ad campaign eloquently described the
house as Xanadu: the Computerized House of Tomorrow and its peculiar appeal was
set by the advertisement campaign: a house with a brain a house you can talk to, a
Project Domus: Designing Effective Smart Home Systems
14

house were every room adjusts automatically to match your changing moods
(Heckman, 2008).


Figure 3 Picture of a Xanadu House
As the time moved on, and most of the houses were still unsold, the technology
contained soon become obsolete. One by one, these Xanadu houses started to get
demolished to make space for more commercially viable projects and, by October
2005, they were all gone.
In spite of the commercial setback provided by the Xanadu homes, the concept was
sound and a combination of elements such as computers, robotics and Artificial
Intelligence (AI) were to push the Smart Home concept further, even if sometimes only
in research laboratories. Throughout the 1980s, several innovative ideas provided a
clear indication that the technology might have been finally mature enough to deliver
commercially viable solutions. As an example, a device named Waldo, which
interfaced with an Apple computer, could use voice recognition and speech synthesis
technology to control appliances.
Today, several commercial and academic projects, funded by universities and the
industry alike, are still investigating the possibilities that Smart Homes can offer. A
possibly incomplete list of projects working with Smart Home technologies can be
found in the following paragraphs. For more information about some of them, see the
referenced endnotes.
CISCO Internet Home
ii
This project aims at investigating the benefits of a high-
speed, always-on Internet connection that enables an array of consumer devices and
appliances in the home. Developed in conjunction with leading consumer companies, it
Project Domus: Designing Effective Smart Home Systems
15

demonstrates how Internet can enhance daily living for consumers for the homes and
communities of the future.
MIT House_n
iii
This project is led by a multi-disciplinary team composed by
architects, computer experts, engineers and behavioural scientists who investigate key
issues and what services could be offered in the home of the future. Its focus is on the
design of the home and its related technologies, products, and services and to see how
they can evolve to meet the opportunities and challenges in the new home.
Microsoft Research EasyLiving
iv
Started in 1998, EasyLiving is a project funded by
Microsoft Research about creating an intelligent environment which will make
computing more accessible and more pervasive than todays desktop computer. Its goal
is to develop a prototype architecture and technologies for building intelligent
environments that facilitate people interaction with other people, computers, and other
devices.
UMASS intelligent home project This project from University of Massachusetts
uses simulations of agent-based intelligent systems that also use robotics in a domestic
context.
Adaptive House
v
- This project, led by University of Colorado, aims at developing a
Smart Home system that programs itself by observing the lifestyle and desires of the
inhabitants, and by learning to anticipate and accommodate their needs.
Duke Smarthome program
vi
- Duke Universitys dynamic "living laboratory"
environment that contributes to the innovation and demonstration of future residential
building technology. The central concept of this project is the belief that Smart Homes
can improve that quality of life for people of all ages and incomes.
Aware Home Research Initiative (AHRI)
vii
An interdisciplinary research project at
Georgia Tech aimed at addressing the fundamental technical, design, and social
challenges presented by such questions by using off-the-shelf and state-of-the-art
technologies.
CENELEC SmartHouse
viii
- Funded by the European Committee for Electro
Technical Standardization (CENELEC), the aim of this project is to grow and sustain
convergence and interoperability of systems, services and devices that will provide
citizens with access to increased functionality, accessibility, reliability and security that
a SmartHouse, with common and open architectures, can deliver. Recently, CENELEC
has also released a European Code of Practice for SmartHouse operation.
Project Domus: Designing Effective Smart Home Systems
16

3. Research
This chapter provides details about the main elements that compose a Smart Home
system and gives an overview of the most important home network protocols. It also
attempts to define a possible market for the technology, outlining the potential benefits
and concerns emerged from recent researches. Finally, it provides some design
challenges that needs to be considered when designing a Smart Home.
3.1. ComponentsofaSmartHomeSystem
To be considered a Smart Home, the technology used must employ all the following
elements: intelligent control, home automation and internal network (Jiang et al., 2004).
The intelligent control is provided by a control system, comprised of two types of
elements: sensors, which will monitor, control and report the status of the home
environment, and a control agent (human or software based) which acts on the
information provided by the sensors.
The home automation function is fulfilled by electrical or electronic devices, called
actuators, that will interact and modify the environment by accomplishing specialized
tasks. These tasks often work towards a more complex goal defined by the user of the
system.
The purpose of the home network is simply to ensure that all the components can
receive and send instructions to each other.
Figure 4 provide a simple example on how all three elements interact. A thermometer,
an example of a sensor, reports the current temperature. In response to this input, the
control agent, which can be a piece of software or an actual person, acts on the heater,
via the actuator, and instructs the device to switch on. This action accomplishes the
users initial goal: to increase the temperature to a comfortable level (Helai et al.,
2005). The result of a task might modify the environment monitored by the sensors,
whose input might cause the control agent to perform other tasks, such as turning the
heater off when the temperature has reached the desired level, and the cycle starts
again. Although not explicitly represented, all the actions depicted in the example
above can only be made possible by the existence of a home network that can carry the
information provided by the sensors and send commands to the actuators.

Project Domus: Designing Effective Smart Home Systems
17


Figure 4 Sensor and Actuator Interaction
3.1.1. ControlSystems
The control system is a critical part of a Smart Home as it determines usability,
reliability and overall effectiveness of the solution provided. These systems are written
as a piece of software that is run on a home computer or embedded in an electronic
device. These software systems offer the ability to control a subset of the home
appliances from a centralized location. Most of them also provide users with the option
to store macro commands; that is, to combine a list of tasks together. These macros can
be then invoked by the user when required or be automatically executed by the system
at a pre-set scheduled date and time.
3.1.2. Actuators
Actuators are electrical or electronic devices that can control a household appliance.
When they come as a separate device, they need to be electrically coupled with the
appliance and can control it by executing some simple commands, such as switching it
on or off. When they are embedded within the appliance itself, they can be more
sophisticated and provide more value added to the user.
Smart Home-enabled appliances can be subdivided into two categories. The first
category is composed by familiar items, such as refrigerators or washing machines,
which would also provide an intelligent interface to control them. The second category
is comprised of entirely new devices. To a greater extent, most of these devices are still
at a prototype stage, with their viability and effectiveness being studied in some of the
home lab projects outlined in the previous section. Some interesting examples are:
Project Domus: Designing Effective Smart Home Systems
18

smart picture frames, which display users images in rotation updated in real-time;
smart mirrors
2
that can display the news and remind the user of todays appointments
while brushing the teeth; smart tables, which incorporate a touch screen that allow users
to display and edit documents stored in file servers accessed via the home network;
smart pillow, which can read a book, or play the users favourite music when they
detect that their user is drifting into sleep.
3.1.3. HomeNetwork
Smart Home network technology can be subdivided into three main areas, depending
on the communication media used: Powerline, Busline, and Wireless.
Powerline systems plug in directly to the house electrical network (electrical mains)
and do not require additional cabling. This technology is the oldest of the three and,
though simple to configure and cheaper than other solutions, it may lack scalability and
considered the least reliable due to its susceptibility to electrical interferences. Some of
the earlier protocols support one-way communication, which allows devices to receive
information but not to communicate.
Busline systems use a separate media to send/receive signals, usually twisted-pair
cabling, which is similar to the cables adopted for phone or network services. Albeit
being more expensive to install, especially when retro-fitting existing houses, the use of
a separate cable provides a positive note as it makes this technology the most reliable of
the three and can provide higher bandwidth. Components based on this technology are
usually more complex to configure and require some knowledge of networking.
Finally, thanks to the dedicated media, this technology usually provides a completed
two-way communication protocol so that connected devices can communicate with
each other.
Wireless systems do not require any wires to operate. This technology can be further
subdivided into Radio Frequency (RF), and Infrared (IR). It is the most recent of the
three and is increasingly becoming more popular as costs per unit decrease. Solutions
based on this technology are usually very easy to install and configure and can combine
most of the benefits offered by Busline technology, such as two-way communication
and scalability, though with a relatively lower bandwidth. However, similarly to


2
See: http://gizmodo.com/gadgets/gadgets/touchscreen-smart-mirror-widgets-in-the-mirror-246384.php
Project Domus: Designing Effective Smart Home Systems
19

Powerline, this technology can be prone to interferences, though the existence of two-
way communication can address it by implementing acknowledgment of commands
received and error checking/recovery mechanisms. Finally, due to its wireless nature,
this technology introduces some privacy concerns as unauthorized access can be gained
without even the need to be in the house. Some of the most recent protocols have tried
to address this issue by introduced data encryption and authentication mechanisms.
However, this also adds to the communication overhead, thus decreasing the bandwidth
available, and make systems based on this technology more complex to configure and
manage.
3.2. CommunicationProtocols
This section provides an overview of some the most important communication
protocols for home networks available today. Some of the protocols listed are
proprietary, that is, details are not disclosed to the public. Others are owned and
maintained by a company or consortium but openly made available. Finally, some of
these are also recognized standards, that is, acknowledged by nationally or
internationally accredited bodies.
3.2.1. X10anditsLegacy
X10 was the first general-purpose home network solution. PICO Electronic, a UK-
based engineering firm, patented it in 1978. After a first unsuccessful attempt to
market it in Europe, the company established itself in the US, where it was more
successful. The RadioShack, the US-based chain of electronics retail store, was the first
to offer consumer solutions based on this technology.
X10 is a Powerline system, so uses the existing electrical network in the house and can
allow users to remotely control, at least in principle, any appliance connected to the
house mains. A controlling device would just be plugged in between the mains and the
electrical appliance to be controlled. Properly instructed, this controlling device will
then turn the appliance on or off at specific times or as a response to specific events
coming from the home network.
The original implementation allows one-way communication and can address up to 256
devices subdivided into eight different homes (channels) to lessen the chances of
interferences with other systems nearby. Figure 5 provides a graphical representation
Project Domus: Designing Effective Smart Home Systems
20

on how X10 communicates. The X10 signal is sent when the voltage value crosses
zero, which happens twice at every current cycle. Virtually all other Powerline home
communication protocols use a variation of this method.

Figure 5 X10 Zero-Crossing Signal Transmission
In spite of its limitations, and thanks to the low installation costs and its ease of use,
X10 is still widely used today by DYI enthusiasts, especially in the US, where a
multitude of off-the-shelf components are readily available. However, due to the
differences between the US (120V/60HZ) and European (220V/50HZ) power lines,
devices built for the US market will not work in Europe.
In more recent years, this technology made a comeback due to the fact that the patent
for the protocol expired in late 1990s, and several forums on the Internet now can
provide resources for anyone interested in investigating this technology. A wireless
version of this protocol which offers limited two-way communication seem to exist but,
besides being called X10, it might have little to do with the original Powerline
technology.
After the original idea first implemented by X10, several other protocols have emerged
using the same concepts, sometimes enhancing the original specifications, such as
implementing two-way communication, providing support for more devices and
different types of media. The communication protocols listed below are an example of
the most known.
INSTEON derives directly from X10, for which is backward compatible. It is a
proprietary protocol developed by SmartLabs, Inc.
ix
and can use electrical power lines
or wireless. It offers two-way communication where the controlled devices also
function as repeaters for the messages to increase reliability.
Powerline Control Bus (PLCBUS) is a proprietary, two-way communications
technology developed by ShangHai Super Smart Electronics Co. Ltd.
x
. Differently from
X10, it can support up to 64,000 devices.
Project Domus: Designing Effective Smart Home Systems
21

CEBus, the Consumer Electronic bus (CEBus) protocol, also known as EIA-600, is by
some considered the US standard for home networking. It was first released in 1992
with the intent of expanding the capability of X10. It is an open architecture and is
outlined by a set of specification documents which define details for communicating
through power lines, twisted-pair cables, wireless, and others media.
Universal Powerline Bus (UPB) was released in 1999 by PCS Powerline Systems
xi
of
Northridge, California (USA). Reportedly, it features an improved transmission rate
and higher reliability than X10, due to the different method used in transmitting the
electrical pulses.
3.2.2. OtherProtocols
Konnex (KNX) is a standard (EN 50090, ISO/IEC 14543), OSI-based network
communications protocol for home automation. It is the result of a convergence of three
existing European standards: the European Home Systems Protocol (EHS), BatiBUS,
and the European Installation Bus (EIB). In contrast with other similar technologies,
KNX defines several possible physical communication media and it is designed to be
independent of any particular hardware platform. The KNX standard is administered by
the Konnex Association
xii
.
LonWorks, similarly to KNX, is a networking platform which specifies both the
communication protocol and the hardware required by it. Developed by Echelon
Corporation
xiii
in conjunction with Motorola in the early 1990s it supports a variety of
communication media, such as twisted pair, power lines, fiber optics, and RF. It has
established itself as a de-facto standard for building control and automation. In 1999,
the communications protocol was submitted to ANSI and accepted as a standard for
control networking (ANSI/CEA-709.1-B).
C-Bus is a proprietary protocol created by Clipsal
xiv
for use with its brand of home
automation and building lighting control system. C-Bus requires Ethernet-network like
Cat 5 Unshielded Twisted Pair (UTP) cables, though a two-way wireless version also
exists. This system is primarily used in Australia (e.g. Sydney Opera House) and in
Asia, but it is becoming more known in Europe as well.
Universal Plug and Play (UpnP) protocol is actually a set of protocols promulgated by
the UPnP Forum
xv
. The goals of UPnP are to allow devices to connect seamlessly in
order to simplify the implementation of networks in the home. Its control protocol is
Project Domus: Designing Effective Smart Home Systems
22

based upon an open architecture based on established standards such as TCP/IP, UDP,
HTTP and XML. However, this protocol is not an officially recognized IETF or IEEE
standard and may not be supported by many networking devices.
Zigbee is the name of a specification for a suite of communication protocols that use
RF as their transmission media. Based on the IEEE 802.15.4-2006 standard for wireless
personal area networks (WPANs), the standard is maintained by the ZigBee Alliance
Group
xvi
. For non-commercial purposes, protocol specifications are available free to
the general public.
Z-Wave, smilarly to ZigBee, Z-Wave is a communications standard based on wireless
communication. The technology is developed and maintained by Zensys
xvii
, a Denmark-
based company. The Z-Wave Alliance is an international consortium of manufacturers
that oversees interoperability between Z-Wave products and enabled devices. This
protocol is a mesh networking technology where each node or device on the network
capable of sending and receiving control commands. Devices can work as stand alone
or in groups, and can be programmed into sequences (called scenes or events) that
trigger multiple devices, either automatically or via remote control.
BACNet
xviii
is an acronym for Building Automation and Control Network. This
communication protocol was developed by the American Society of Heating,
Refrigerating and Air-Conditioning Engineers (ASHRAE) in conjunction with building
management organizations, system users, and building system manufacturers. BACNet
standard was officially ratified in 1995 as ANSI/ASHRAE 135-1995 and it is
advertised as an open protocol which could be applied to any type of systems, such as
Heating, Ventilating and Air Conditioning (HVAC) systems, lighting, life safety,
access control, transportation, and maintenance systems. It can use a wide range of
network technologies for communication.
Modbus is a communication protocol that was developed in the 1970s by Modicon,
Inc. for use in industrial automation systems with programmable logic controller (PLC)
devices. Reportedly, it is one of the most widely used communication protocol for
connecting electronic equipment in industrial settings. In 2004, the standard was
transferred to Modbus-IDA
xix
, a non-profit organization made up of users and suppliers
of automation devices primarily in manufacturing.
Project Domus: Designing Effective Smart Home Systems
23

3.3. TheMarketforSmartHomes
As outlined in Chapter 2, the 20
th
Century introduced a dramatic revolution in domestic
technology which culminated with the emergency of the Smart Home concept.
However, in many cases, the research carried out for Smart Home systems has been
focusing more on the technical possibilities without little or no consideration of the
social aspects or the actual needs of the potential user (Harper, 2003). As a
consequence, Smart Home solutions are mostly appealing only to DIY enthusiast and
hobbyists and seem to be stuck in the Early Adopter phase of Rogers Technology
Adoption Lifecycle.


Figure 6 Rogers Technology Adoption Lifecycle
3

A survey carried out for the UK-based Joseph Rowntree Foundation in 2000 reported
that we may be very close to a change of attitude whereby Smart Home technologies
may soon become more popular and widespread. According to the research, 59 per
cent of the people interviewed stated their interest for a technology that would save
time and effort in their home, though it also outlined concerns about how complicate
this technology might still be to operate (46%). As perhaps expected, the demographics
outlined that young people would be more in favour of such technology than elderly
people, due their degree of familiarity with game console and computers (Pragnell et
al., 2000). However, this generation will soon become the decision-maker for these
systems in the near future.
A similar study identifies other types of users who could benefit from this technology.
The relatively recent concept of teleworking opens new opportunities for executives


3
Courtesy of Wikipedia: http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png
Project Domus: Designing Effective Smart Home Systems
24

and professionals to work from home. These individuals will spend more time at home
and may be more interested in taking advantage of the potential benefits that this
technology can offer. Moreover, as population in the western world becomes older,
households with members over 65 will substantially rise in the next years. Another
research reported how the installation of digital control and communication systems, as
part of a fully integrated Smart Home system, can enhance important health and
support services, improve independence, and overcome isolation for this category of
people (Gann et al., 1999).
Finally, another research points out that busy households, that is a family with children
and both parents working, could themselves become adopter of Smart Home services.
Dual-income families represent already almost half of the total in the US and these
families often live a very structured life with almost no un-scheduled time. The
potential time-saving features that a Smart Home can provide will help to maintain a
sense of control and relieve some of the stress associated with running the household
(Kyung Lee et al., 2008).
3.3.1. PotentialBenefits
Although features offered by a Smart Home may vary, an effective implementation can
bring several potential benefits. Childrens needs and busy days prevent families from
having enough spare time and a Smart Home may make everyday life at home easier
for its inhabitants (Harper, 2003). The ability to monitor and control all the devices in
the house from a central location can introduce time-saving benefits. Furthermore, over
half (59%) of the participant of a recent survey reported that they would welcome a
new technology that would save time and effort in their homes (Pragnell et al., 2000).
Furthermore, such gain can be sensibly expanded with applications that offer
opportunities to group stand-alone operations into logical macro tasks. For example,
the turning on of a DVD player could automatically operate the TV and either dim the
lights in the room or lower the window blinds to obtain the optimal light level.
Going further, an effective Smart Home system may be able to make complex decisions
that are likely beyond the technical expertise of the inhabitants of the house: for
example, an expert system built into a Smart Home system could contain a detailed
knowledge of thermal systems, of human physiology, and of the HVAC system
installed in the house and being able determine the optimal choice of temperature and
Project Domus: Designing Effective Smart Home Systems
25

humidity based on the information received by thermometers and humidity sensors
located inside and outside the house (Greyson, 1991).
Modern technology is already changing the home as an increasingly larger number of
appliances come with embedded computing capabilities. Smart Homes of the future
will be able to integrate all heating, air conditioning, lighting, home entertainment, and
security systems together. Although safety, security, and centralized control are
currently what potential users expressed as the most interesting (Pragnell et al., 2000),
the result of this integration, combined with modern networking technology, will open
new possibilities and the creation of additional services that might not exist today.
Table 1 represents possible areas where Smart Home technology can already help today
(Green et al., 2004).

Table 1 Examples of Smart Home Applications
AREA EXAMPLES
Welfare Health and monitoring; remote diagnosis; remote personal trainer.
Entertainment Music television and video downloading.
Environment Remote control of lighting, heating/air-conditioning; energy usage and
costs.
Safety Alerting of problems e.g. gas leaks, CO.
Communication Video phone; calendar reminders; communication inside and outside
home.
Appliances Self-diagnosis or problems and assistance in their operations; automated
food ordering.

Linking the home network to the outside world via the Internet connection opens up the
possibility for the a Smart Home to also be managed remotely, e.g. when at work or
away on holiday. This option could also be extended to authorized third parties, such
as electricity or gas utilities, who can run routine maintenance or troubleshooting tasks
remotely or on behalf of the house owner.
Studies demonstrated how mobile phones and Short Message Service (SMS) messages
have become a popular way to keep in touch and how this can increase the sense of
safety and connectedness among family members (Harper, 2003). These benefits may
be further expanded by integrating this mobile communication network, now composed
also by other devices such as Personal Digital Assistance (PDA) and hand-held
Project Domus: Designing Effective Smart Home Systems
26

computers, with components of Smart Home systems and with the Internet itself. For
example, family members may be able to leave notes to each other and making or
changing appointments with ease. According to the same study, this network society
will enable always-on, real-time communication, bring people closer, and could
concretely add to family communication as a means of organizing daily living as Smart
Home might become: the gate to a new kind of collectivity (Harper, 2003).
Finally, Smart Home technology can increase the quality and facilitate the life of
elderly people or people with disabilities. Todays digital controls and communication
systems can already allow enable health and support services personnel (telecarer) to
carry out routine diagnostics, monitoring and basic services whilst allowing the person
to remain comfortably at home.
3.3.2. ReportedNeedsandConcerns
The same researches carried out on Smart Home technologies also raised some
concerns. Regardless of the technical edge provided by one particular technology over
another, addressing such concerns will play a pivotal role to ensure the buy-in to the
Smart Home concept by the majority of consumer market.
The survey carried out in 2000 for the Joseph Rowntree Foundation (UK) unveiled
some interesting findings, where the most significant concerns were the fear of
technical issues that would cause the system to stop functioning or perform unintended
(unwanted?) operations, and users who may be intimidated by a system too complex to
be used effectively or who would be unable to take back control of the system (Pragnell
et al., 2000).
Similar findings were outlined by a 2002s survey carried out by the Digital Media
Institute of Tampere University of Technology (Finland). In addition, the research
showed that people are traditional when it comes to their daily routines and working on
household chores and might at times decide to carry out these tasks themselves.
Furthermore, people will have different opinions on what is enjoyable and what is not:
for example, a person might like to cook but hates dusting, another might hate ironing
but likes hovering so the system should be able to cope with these preferences too.
Finally, although basic daily routines may be the same across households, the way to
perform them may vary from household to household and from individual to individual
(Koshela et al., 2004).
Project Domus: Designing Effective Smart Home Systems
27

Often, peoples vision of technology is tainted by reservations and fears, not only in
science fiction movies terms, such as that the house might start living a life of its
own, but also a concern connected to very real situations, such as not being able to
turn a device off. Smart Home systems encompass complex socio-cultural aspects that
strongly relate with the concept of home and, as such, can evoke strong feelings and
emotions. It is also interesting to note how some participants feared that technology
would actually reduce the amount of communication, though it was acknowledged at
the same time that communication between family members has improved with the
usage of mobile phones.
Other concerns identified were the worry of being constantly on line and general
security issues, with one of the participants being worried about the possibility of their
microwave being operated by an outsider without them knowing about it (Harper,
2003).
The use of this technology also raises many ethical questions, such as how to protect
the privacy for such items as remote access and allowed level of surveillance for
telecarer. (Gann et al., 1999).
Another research conducted in 2003 in US and Korea outlined the importance for a new
technology to be compatible with existing devices, to be customizable, and provide
improvements on communication methods (e.g. support for wireless technology).
Accessibility features and centralized entertainment resources were also being of high
interest, though dedicated devices for stand-alone appliances were preferred to multi-
function devices controlling several of them (Chung et al., 2003).
A research conducted in 2004 outlined the following themes as being the major
concerns for the participants: costs, system reliability, security and privacy concerns,
ease of use, flexibility, convenience, maintaining independence, expandability with
future technologies, and ability for the users to take control when required (Green et al.,
2004).
Finally, the research conducted by Tampere University of Technology in 2004, which
also prototyped different user interfaces, reported the appreciation of having a mobile
device when interacting with the system rather than a fixed one, such as the TV set.
From this study, further requirements emerged, such as having a way to record pre-
defined actions at a certain time and day in advance (pattern control), whilst at the
same time provide users with the ability to act on a device immediately (instant
Project Domus: Designing Effective Smart Home Systems
28

control). The study also highlighted the confusion that might occur when multiple
users operate the same device, e.g. a light, or that a user might not be aware of a pattern
control set by another user (Koskela et al., 2004)
Finally, the nature of the home is quite dynamic and the type, level of information and
interaction required by its inhabitants change throughout the day (Chung et al., 2003).
Smart Home systems will need to maintain a profile of its users in order to keep track
of their needs, preferences, and how these can change throughout time.
3.4. DesignChallenges
In addition to the needs and concerns expressed above, Smart Home systems provide
several design challenges.
30 years in the making, Smart Home technologies do not yet seem to have reached
most of potential users. D. Gann (1999) in his research, reported five reasons for this
slow growth and, though few years have gone by since these findings, todays situation
does not seem to have improved significantly in any of these areas:

Poor understanding of user needs
Users lack of understanding about potential benefits
Difficulties in installing and integrating solutions into existing households
Immature technology, causing defects, rapid obsolescence and upgradeability
issues
Costs.

Whilst some of these design challenges are beyond the scope of this project, others can
be investigated and expanded further in this paper. For example, it is certainly possible
to gain a better understanding of the users needs and, by doing so, have a better chance
to develop solutions that are useful, usable, and used (Dix et al., 2004). Furthermore,
it may be possible to choose technologies that are more reliable, less disruptive, more
supported and upgradeable than others and that should provide a better chance to be a
sound investment from the users point of view.
Project Domus: Designing Effective Smart Home Systems
29

3.4.1. GatheringValidSystemRequirements
The true potential of Smart Homes can only be unleashed with a user-centric approach.
One of the challenges often reported by the current literature on the subject is that
designers of Smart Home solutions seem to be more focused on the technical part of the
solution and often ignore what customers might actually want the product to do. In
some cases, this resulted in making available technically valid products for which very
few customers were interested in. The techniques described in this section can help
bridge this gap and will be used later on when documenting the system requirements
for this project as gathering unambiguous and detailed software requirements is a vital
part of any software development endeavour. K. Wiegers (2003) states that not
dedicating enough time to properly document requirements for a system usually leads
to at least one of the following:

Unusable product
Poor product quality
Dissatisfied customers
Wasted time and rework
Project overruns (time, costs)
Gold-plating (adding of unnecessary features)

Wiegers suggests that software requirements can be subdivided into three main
sections: user requirements, business requirements, and functional requirements. Figure
7 provides a visual representation of the major components of all system requirements
and their relations (Wiegers, 2003).

Project Domus: Designing Effective Smart Home Systems
30


Figure 7 Components of Software Requirements
Business requirements are documented in the vision and scope document of the project,
whilst functional requirements are usually formally recorded in software requirements
specification (SRS) documents. These formal documents describe, in as much detail as
possible, the expected behavior of the system and often also outline non-functional
requirements such expected quality standards, regulations and other constraints.
User requirements, sometimes also called Voice of the Customer, describe the system
as a set of tasks that the user must be able to accomplish with the product.
Unfortunately, gathering these requirements is seldom an activity that will result in a
well-ordered list of detailed needs and it will often require refining steps and
subdividing the input provided into different categories as a better understanding is
gained. Table 2 outlines how the Voice of the Customer can be further subdivided into
nine requirement categories and provides a brief description of each one (Wiegers,
2003). These requirements are documented, expanded, and confirmed using Use Case
diagrams, which describe a single instance of usage of the system and outline the
relationship between users (actors) and tasks (use cases) to be performed.

Table 2 Classifying the Voice of the Customer
Business Requirements Any business benefit that either customers or the developing
organization wish to gain from the product.
Use Cases General statements of user goals or business tasks that users
Project Domus: Designing Effective Smart Home Systems
31

need to perform.
Business Rules Rules that states which users can perform a specific activity and
under which specific conditions. These rules will need to be
captured in the software functional requirements and enforced by
the system.
Access control is a typical business rule in most of computer
systems.
Functional
Requirements
Description of observable behaviors that the system will exhibit
under certain conditions and descriptions of actions the system
will let users take.
They are derived from system requirements, user requirements,
business rules, and other sources.
Quality Attributes Qualitative statements are modifiers that will indicate how a task
needs to be performed.
Some examples of these statements are: fast, easy, intuitive,
user-friendly, robust, reliable, secure, and efficient.
External Interface
Requirements
How the system needs to connect to other systems or, generally,
to the outside world.
Constraints Constraints restrict the options available to the developer. For
example, constraints such as size, weight, and interface
connections.
Data Definitions The format, data type, allowed values, or default value for a data
These requirements are usually collected in a data dictionary that
will serve as reference for the project team.
Solution Ideas A description of a desired way to interact with the system to
perform a particular task.
Most of user requirements usually fit in this category.

The list below, again adapted from K. Wiegers (2003), defines the major steps that
should be carried when documenting requirements for a software project:

1. Identify Business Requirements
2. Identify users of the software
3. Gather User Requirements
4. Define Use Case scenarios
5. Gather Functional Requirements
6. Subdivide system-level requirements into major subsystems and match
requirements to software components
7. Define implementation priorities
8. Review use cases against original requirements to ensure correctness.

Project Domus: Designing Effective Smart Home Systems
32

In addition to this, contrarily to the typical software design where the user base can be
quite homogenous, users of a Smart Home are far less so, ranging from children, to
adults, to elderly people. This poses the challenge to define a user interface that can be
versatile enough to be effective with every user of the system. (Ringbauer et al., 2003).
In order to better address this, one of the techniques that can be used is the creation of
different personas, i.e. virtual users, to try and represent these differences. Most of the
times, personas take the form of fictional characters, who are though provided with
enough real-life details so that developers will be able to relate to them when discussing
a particular requirement or feature of the product e.g. John would never use that
feature this way. Using personas will also increase the developers connection with a
real user, instead of abstractions, while designing the system (Courage & Baxter, 2005).
3.4.2. ChoosingtheRightTechnology
Advancements in networking in 1980s and 1990s allowed home computer networks to
become a reality. However, though several alternatives emerged, none of these have yet
managed to establish themselves as de-facto standards in the industry. This has affected
the consumer industry, which had been delaying the adoption of Smart Home-enabling
technology in their products, worrying that they may invest in the wrong technology.
Already, some of these network protocols have since been abandoned due to lack of
profitability. From the end-users point of view too, as the home network is a vital part
of any Smart Home solutions, the risk is that by siding with the wrong technology you
would soon end up with a system that might no longer be expandable or even supported
tomorrow.
The good news is that these concerns are starting to be addressed as consolidation
seems to be occurring, at least in Europe and some major players are emerging. Konnex
(KNX), for example, represents the convergence of three previous European standards:
the European Home Systems Protocol (EHS), BatiBUS, and the European Installation
Bus (EIB). These consolidation efforts will create viable platforms that can then be
picked by producers of electronic and electrical home appliances to introduce smart
features in their devices (Wacks, 2002). With a proper economy of scale, development
and implementation costs should also be driven down, making these solutions more
appealing to consumers.
Project Domus: Designing Effective Smart Home Systems
33

The building industry is part of this challenge too. As very few new residential
dwellings are built to natively support the Smart Home, e.g. by installing twister-pair
cabling, most of todays Smart Home systems will be installed in existing houses. In
order to ensure ease of installation and minimize costs, it will not be feasible for the
average user to run new cabling that would support a twisted-pair home network. By
excluding Busline technology, Smart Homes will need to be implemented with either
Wireless or Powerline communication. As Wireless is still expensive, Powerline, that
is technology that use of the existing electrical network to operate, seems the only truly
viable alternative. The issue here is that most of the protocols that use this type of
communication are quite old, can be unreliable, and are quite limited in terms of
bandwidth. Some of the drawbacks of X10, the most common Powerline
communication protocol, have been outlined by a recent research: sluggish response
times especially over longer distances, bandwidth limitations, the increase in costs
due to need of amplifiers and filters required to boost reliability, lack of connection to
external network resources, and performance impact in electrically noisy environments
(Chunduru & Subramanian, 2006).
Concluding, although it seems that when choosing the communication protocol for a
Smart Home solution, there are several alternatives, when these are evaluated against
parameters such as ease of integration, reliability, support, compatibility, long-term
investment, and, ultimately, costs, these options may become fewer.
3.4.3. TheQuestfortheEffectiveUserInterface
Human-Computer Interaction (HCI) is a technical field that studies the interactions and
the relationships between humans and computers (Fischer, 2001). Most of the HCI
research can employ several years before it materializes into an available off-the-shelf
product. The idea behind todays point-and-click graphical interfaces was first
demonstrated in 1963, while, at around the same time, Douglas C. Engelbart was
developing the first mouse at Stanford Research Laboratory, carved in wood and
initially intended to be a cheaper replacement for light pens. Commercial systems that
used direct manipulation of objects using the concept of a desktop were not available
since the 1980s, with the Xerox Star (1981) and the Apple Lisa the following year
(Myers et al. 1998, Dix et al., 2004).
Project Domus: Designing Effective Smart Home Systems
34

Recently, the HCI focus has shifted from studying computer interfaces into the way
people use computers in a more general sense; that is, how people and computers can
collaborate together to achieve the users goal. One of main areas of HCI research is
about the concept of usability of systems, which can be approached from two
perspectives. The early area of focus was the emulation approach, where the computer
is programmed to exhibit human-like abilities, e.g. computers greeting their user with
How can I help you today?. More recently, the research shifted towards exploring a
complementing approach, which can better leverage on the difference between humans
and computers and can open up to new interaction and collaboration possibilities
(Fischer, 2001).
Usability requirements are influenced by the complexity of the system being designed.
An Automated Teller Machine (ATM) is an example of a simple system with a few
basic functions and which needs to be understood by users with little or no prior
knowledge of the system. At the other end of the spectrum, a high-functionality
application (HFA) is a complex system that requires users to learn the intricacies of its
interface and functionalities before they can become proficient with it. However, HFAs
can perform a richer variety of functions than simple applications, hence they can assist
users with resolving more complex problems. An example of a HFA is Adobe
PhotoShop, the leading application for editing digital images, which literally contains
hundreds of functions, each one with several settings and subtle nuances.
In todays applications, there seem to be an inversed proportion between the usefulness
of a system (i.e. its complexity), and its usability (i.e. how user-friendly the user
interface is). However, as costs of hardware keep falling, cognitive costs, that is the
costs involved in learning a system, will represent an increasingly higher part of the
total cost of ownership (TCO). This calls for proper HCI techniques that will help
maintaining an appropriate level of usability whilst providing the ability of adding more
features. When dealing with usability of a system, developers of user interfaces will
need to make generic assumptions about the users knowledge in order to find the right
balance between beginner and expert users and reach a compromise that can work with
both these extremes. The challenge is that, when making this choice, there is always a
risk to either leave novice users without the required help or to create a system that gets
in the way more than the necessary with more experienced user.
Project Domus: Designing Effective Smart Home Systems
35

Todays Windows, Icons, Menus and Pointers (WIMP) interfaces have exacerbated this
challenge even further (Dix et al., 2004). Older, text-based interfaces provided a clear,
explicit communication channel between user and the machine. Where the user was
presented with a prompt they could enter only one command at any time and this
command was to be picked from a well-defined list constrained by the current context.
Modern multi-modal graphical interfaces allow users to impart instructions via multiple
input devices (e.g. a keyboard and a mouse) in a less constrained sequence and within a
wider context. This new level of interaction has created the possibility for multiple
implicit communication channels. This extra level of complexity often requires the
system (and developers) to gain a wider understanding of multiple areas:

Users knowledge of the system
Users goals and how they can be mapped against the systems primitive
operations
Understanding of the communication processes and which communication
channel is more appropriate to use in relation to the above
Instructional strategies, based on pedagogical theories that can exploit the
knowledge contained in the system to the benefit of the user.

Figure 8 provides a graphical representation of implicit and explicit channels (Fischer,
2001).


Figure 8 Implicit and Explicit Communication Channels
Project Domus: Designing Effective Smart Home Systems
36

In truth, recent progresses in this area have made systems easier to learn and to interact
with: context-sensitive help systems, today present in almost the totality of systems, is a
direct product of this research. The challenge here is to be able to infer correctly what
tasks will actualize the users goal without being intrusive. For example, potential users
of a Smart Home system tend to assume that such system should have voice recognition
capabilities but natural speech interfaces are still far from perfect and still cause
unintended operations (Koskela et al., 2004).
Future success of new computer systems will be less judged on factors such as
processing speed or the amount of memory available and more on the ability to interact
effectively with users, regardless of their current knowledge of the system.
3.4.4. TheRoleofArtificialIntelligence
As per other computer systems, the factors that will influence the success of a Smart
Home product are not purely technical. The challenge lies in how to make an intuitive
system powerful yet still intuitive to use in order to provide real value for its users.
Artificial Intelligence (AI) techniques can provide a positive contribution towards
resolving such challenges. To successfully resolve the speech recognition problem
presented in the previous section, for example, will require systems with the ability to
provide syntactic analysis, semantic recognition, along with some pragmatic analysis
(Greyson, 1991).
Moreover, Smart Home system will need to be able to adapt to a changing environment
and to multiple users. In this context, the best user interface is the one that requires the
least amount of user interaction; that is, the system should be able to correctly
understand the users need using a probabilistic approach coupled with other factors
such as knowledge of past events and users preferences. With this knowledge, a Smart
Home system will then be able to perform some of the required tasks autonomously. An
AI field of research that can work towards this goal is the studies done on Bayesian
Networks. Bayesian Networks (BN), also known as belief networks, knowledge maps
or probabilistic causal networks, provide a method of reasoning using probabilities and
have already been applied successfully to problems in medical diagnosis, whose results
are often more accurate than an expert diagnosis (Charniak, 1991). A BN tree is a
graphical representations of probabilistic relationships among variables of a system that
may influence the probability for a given event to occur. It represents a graph which
Project Domus: Designing Effective Smart Home Systems
37

includes a set of nodes, representing the variables, connecting lines (edges or arcs),
which display their inter-relations between hypothesis and variables, and associated
probability values for all the edges. By using this method, one can reason and calculate
the likelihood for an event to occur. E. Charniak (1991) illustrates a BN with a simple
example: we want to know whether our family is home when deciding what door to use
when enter the house. For arguments sake, let us say that the most convenient door
would be doubly locked if nobody is home. Since this door will require more fumbling
with its keys in order to be opened, we may decide to go for the other one instead, once
we have sufficient reason to believe that this would indeed be the case. The BN tree
will use the expert knowledge embedded in the relationships among the nodes to
calculate the likelihood of the family being out. So, if nobody is home, the dog is
usually put out in the backyard and the porch light is usually turned on. If the dog is
out, we would know it because we could hear its barking. However, when the dog has
bowel problems, it will also be put out. The BN provides a way to weigh these
variables and determine the likelihood of the family being out. Figure 9 provides a
graphical representation of the sentences given above in the form of a causal graph
(Charniak, 1991). From this graph, we can draw the following general hypothesis: if
dog-out and light-on then family-out is likely to be true. However, if dog-
out the bowel-problem hypothesis could also be true. The arcs in the BN tree will
tell what nodes (also called variables) influence others. In this case, the dog-out node
is said to have a direct causal connection on hear-bark so that, if hear-bark is
true, then dog-out is more likely to be true. However, if light-on is true, it will
tell us nothing more about dog-out as these variables do not have a direct causal
connection between each other. Furthermore, light-on will not influence the
likelihood of the bowel-problem event in any way.

Project Domus: Designing Effective Smart Home Systems
38


Figure 9 Causal Graph
It is important to understand that BN cannot provide absolutes but always return a
degree of confidence (probability) for the given hypothesis. To refer back to the
example, the family might sometimes forget to turn on the porch light or to leave the
dog out when leaving the house. Figure 10 expands the causal graph by adding the
probability values given for all the BN nodes. These values are usually gathered by
direct observation, from historical data (also known as cases) or from information
gathered via expert knowledge. So, let us say that when the family leaves the house,
someone remembers to turn the porch light most of the times (60%), but that there is a
smaller (5%) chance that the light is on even when people are in the house, say when a
guest is expected. The first is represented as P(lo|fo)=0.6, which reads: the
likelihood (P) that light-on (lo) and family-out (fo) equals to 60% (0.6). Conversely,
the second case is represented by P(lo|fo)=0.05; that is, the likelihood (P) that
light-on (lo) but not family-out (fo) equals to 5% (0.05). Once all the probabilities
are provided, the BN tree is used to validate the hypothesis for which is was created
(e.g. to resolve the family-out scenario).

Project Domus: Designing Effective Smart Home Systems
39


Figure 10 Bayesian Network
A practical example of how BN can be used to infer the users goal is Project Lumire.
Started in 1993 by Microsoft Research Labs, the project investigated how BN trees
could be used to help users of a computer system. The model built tried to infer a
users goals based on their past and current actions and on their supposed knowledge of
the system. The system would then propose tasks that should have helped the user to
reach his/her goal. A short video
xx
, available from Microsoft, shows a live
demonstration of the prototype. The findings of this project were eventually used to
develop the Office Assistant in the Microsoft Office 97 suite (Horvitz et al., 1998).
Smart Home systems can benefit from BN models. For example, a reasoning
framework will greatly facilitate any event-condition-action scenario that contains
uncertain or incomplete knowledge (Dimitrov et al., 2007). A problem domain where
BN models can be employed is the detection of a dangerous situations. Such a
probabilistic model would be able to identify anomalous or dangerous situations, e.g. a
person falling, by continuously gathering evidence considering whether the information
increases the likelihood of the event beyond a threshold that would trigger the alarm
(Cucchiara et al., 2003).
3.4.5. GoingBeyondHomeAutomation
Very few of todays off-the-shelf products go much farther than providing basic home
automation functionalities. Despite the abundance of electrical and electronic devices,
little effort has been placed to try and connect these devices in a meaningful way that
will add value to the users. The number of remote controls that are still required today
in an average home media center would serve a good example for such lack of
integration. However, an effective Smart Home should also be able to infer the goal
Project Domus: Designing Effective Smart Home Systems
40

intended by the user and to carry out (or propose to the user) tasks that will help
reaching the goal, thus adding value from a users point of view.
Smart Homes can successfully implement the idea of ubiquitous computing. Earlier
definitions of ubiquitous computing simply focused on making devices so small to be
hidden from the users view, what is called perceptual visibility. Rather than merely
focusing on size alone, a more recent definition of ubiquitous computing outlines the
computers ability to become integrated with the users goal as to being used without
the user being aware of it (Dunlop & Brewster, 2002). An effective area where Smart
Home systems can help is in supporting the households daily routines. The Merriam-
Webster English dictionary defines routines as habitual or mechanical performance of
an established procedure. So daily chores are deeply unremarkable and accomplished
almost automatically by the individual. The challenge is to ensure that the introduction
of computing abilities will not disrupt this routine and will not force users to bring this
automatism to the foreground.
Finally, Smart Homes may need to move beyond the simple detection of an action
towards a truer understanding of the actions significance from the users point of view
what is called user semantics. A research outlined by Peter Tolmie, of Xerox
Research Center in Grenoble provides results of a research where, for example, the
knocking on a front door (action), called for two distinct courses of action
(significance), which depended on the meaning given to the action by the actors
involved. Focusing upon the action alone only enables a surface interpretation of what
is going on and might not allow for the most appropriate response. Effective Smart
Home systems will need to go beyond detecting the actual action performed and try to
contextualize it into the possible significance attributed to it by the user. As a final
point, experts caution developers to be careful when adding features to familiar objects
as this might change the user semantics, regardless of how useful or easy to learn the
new function is thought to be (Harper, 2003).
Project Domus: Designing Effective Smart Home Systems
41

4. Development
This chapter outlines the development of a Smart Home system. The Analysis section
will document the system requirements for a complete Smart Home system based on
the information gathered by the Research, whilst the Implementation section will focus
on the development of a Proof-of-Concept (POC) system. The system that will be
developed is a Temperature Control System, envisaged as a subset of a full Smart
Home system. In addition to the usual features present in such systems, the POC will
also implement a Bayesian Network that can help the Fire Alarm sub-system to
determine the likelihood of a fire. Note that, while the analysis will be carried out for
the complete system, only a sub-set of this will be developed further into the POC.
4.1. Analysis
This section will outline the system requirements for the Smart Home system. As no
real end user was available to gather the necessary input on the user requirements, an
attempt was made to identify the user profile and such requirements by considering the
findings outlined by a survey reported by M. Pragnell in The market potential for
Smart Homes (2000).
4.1.1. BusinessRequirements
This section outlines the high-level objectives of the project. As documented in
Chapter 1, the aim of this project is to develop a POC system that addresses some of the
challenges emerged during the research. This statement will therefore define the vision
and scope. The reason why this project is being carried out is two-fold:

To contribute to the existing literature for Smart Home technologies
A as partial fulfilment of the requirements for the BSc in Information Systems
and Information Technology (DT249) to the School of Computing.
4.1.2. DeterminingaUserProfile
The findings reported by M. Pragnell (2000) will be used to determine the likely user
profile for the software being designed. The aims of the survey were to assess views
about key features, to identify concerns, to assess the level of interest, and to identify
Project Domus: Designing Effective Smart Home Systems
42

what type of consumers are the most interested in living in a Smart Home (Pragnell,
2000).
According to the research, participants could be divided into three categories: the
interested in Smart Home technologies (54%), the ambivalent (19%), and the
uninterested (37%). In accordance with these findings, the following user profile can be
defined:

Family households
Aged 15 to 34
Technology savvy
Subscribed to external services
Own a home entertainment system
Have a Home Personal Computer
Have an always-on Internet connection at home.

The differences present in the user profile defined above might still require further
clarification before the design phase can start. Should a full Smart Home system need
to be built, developing different personas might help with this process. A persona
could, for example, be created to identify an adult user of the system, whilst another
one might define a typical teenager who might have very different goals and
requirements than the former. As this project will design a Proof-of-Concept system,
this step was not deemed necessary.
4.1.3. GatheringUserRequirements
The findings reported in The market potential for Smart Homes (Pragnell, 2000) will
be used again, this time with the purpose of gathering the user requirements for the
project. These findings will be then checked against the needs and concerns reported in
3.3.2. and integrated when required. For the sake of clarity, each of these requirements
will be expressed in form of simple statements that can be later used to devise
corresponding Use Case scenarios that will help with the system design.
Table 3 groups the statements identified according to the user requirement categories
defined by K. Wiegers (2003). Note that not all types might be present and that some
of the entries may fit more than one category.
Project Domus: Designing Effective Smart Home Systems
43


Table 3 Defining User Input
User Requirements Categories
The system should save time and effort. Business Requirements
The system should be easy and intuitive to use. Quality Attributes
Users should be able to control devices in the home when away
from home.
Solution Ideas
The system should integrate safety and security features. Business Rules
Users should be able to control remotely everything in the home. Use Cases
The system should be reliable. Quality Attributes
Users should be able to override the system when required. Functional Requirements
The system should be cost effective. Business Requirements
The system should be capable of being installed in an existing
home.
External Interface
Requirements
Users should be able to decide what task to be done automatically
and what to carry out themselves and to change the decision at
any time.
Use Cases
Users should be able to manually control any devices. Use Cases
The system should prevent unauthorized access. Quality Attributes
The system should include means to protect the households
privacy.
Functional Requirements
The system should be customizable. Quality Attributes
The system should be compatible with existing technologies. Quality Attributes
The system should be expandable and support newer
technologies.
Quality Attributes
The system should also provide access from a mobile device. Solution Ideas
The system should offer the ability to program events into the
future.
Use Cases
The system should allow to issue immediate commands to
controlled devices.
Use Cases
The system should support multiple users. Solution Ideas
The system should be able to resolve conflicting commands set for
the same device.
Quality Attributes
4.1.4. UseCaseDiagrams
This section outlines the Use Case diagrams that detail the most common actions
performed in the system.
Project Domus: Designing Effective Smart Home Systems
44

System Overview
Figure 11 displays provide an overview of the main functions present in the system
from a users point of view. It shows how a user issues a command or create a
schedule for a command to be executed sometime in the future. The Use Case diagram
also depicts how a control agent in the system evaluates the command before passing it
to the actuator, which in turn will execute it. Furthermore, the diagram shows how a
sensor communicates with the system and how an inference engine that can assist with
the decision process by suggesting actions based on the data provided by one or more
sensors and past events saved in the database.


Figure 11 System Overview
4.1.5. FunctionalRequirements
Table 4 outlines the Functional Requirements for the system. The column ID provides
each requirement with a unique identifier. The System Feature column provides a title
for the requirement. The Priority column provides a value 0 through 4 that indicates
the priority for the feature to be implemented in the system (0 = must be in, 4 = low
priority). The Requirement Details column provides the following:

Description: a short description of the feature, useful to identify this later on.
Project Domus: Designing Effective Smart Home Systems
45

Stimulus/Response Sequence: sequences of input stimuli (user actions, signals
from external devices, or other triggers) and system responses that define the
behaviours for this feature. When appropriate, this will correspond to the initial
dialog steps of use cases or to external system events.
Functional Requirements: detailed functional requirements associated with the
system feature. This corresponds to capabilities that must be present in the
system for the user to access the feature and perform a Use Case. It describes
how the product should respond to anticipated error conditions and to invalid
inputs and actions. Each functional requirement is uniquely numbered.
Project Domus: Designing Effective Smart Home Systems

Table 4 Functional Requirements
ID System Feature Priority Functional Requirement Details
FR-01 Support for Manual
Override
1
Description: The system shall be able to release control of devices.
Stimulus/Response Sequence: User requests that the system release control of a device to be opera.
Functional Requirements:
FR-01.1. The system shall provide users with a feature to temporarily disable or permanently remove a
device present the system via the User Interface. A device removed or disabled shall henceforth be
operated manually i.e. no automatic control or schedule shall affect its operation.
FR-01.2. The system shall allow users to re-enable a temporarily disabled device. If the device had
associated scheduled events, this shall ask the authenticated user whether they are to be considered or
discarded.
FR-01.3. When a device is being re-enabled, the system shall warn a user of the presence of future
scheduled event and shall be given the option to either retain or remove (delete) these schedule.
FR-01.4. If user permanently remove a device from the system, all the associated information (e.g.
history, logs, and schedule) shall also be deleted from the system.
FR-01.5. The system shall alert a user that permanently deleting an object from the system also removes
all its associated information.
FR-02 Feedback to the
User
2
Description: The system shall provide appropriate feedback to the user.
Stimulus/Response Sequence: User to enter command to perform an immediate task; System to automatically
execute a deferred (scheduled) command.
Functional Requirements:
FR-02.1. The system shall provide feedback for a user request for an instant command within 3 seconds
from the command being issued by the user.
Project Domus: Designing Effective Smart Home Systems

47


ID System Feature Priority Functional Requirement Details
FR-02.2. The system shall implement a means to record all instant command requests and their
outcomes for later user retrieval and examination.
FR-02.3. If an instant command takes more than 3 seconds to complete, the system shall provide
continuous feedback to the user who requested it until the command either returns with a OK/Failed result
OR is aborted (cancelled) by the user.
FR-02.4. The system shall evaluate immediately information received by real-time sensors (e.g. intruder
alert).
FR-03 Access Control
and Data
Protection

1
Description: The system shall employ means to protect the information present in the system.
Stimulus/Response Sequence: An un-authenticated user accesses the system.
Functional Requirements:
FR-03.1. The system shall present a login screen comprised of username and passcode before allowing
access to the system.
FR-03.2. The system shall validate information provided in the login screen against the credential stored
in the system and grant access if there is a match or deny access otherwise.
FR-03.3. The system shall store username and passcode information in an internal database.
FR-03.4. The system shall request an initial username and passcode when being first installed. The
system shall use this information to create the first power user (administrator) account in the system.
FR-03.5. The system shall define two types of users: normal and power users (administrators).
FR-03-6. The system shall grant access to certain functions to power users only.
FR-03-7. The system shall allow only power users to create other users.
FR-03.8. The system shall allow only power users to reset passwords for other users.
Project Domus: Designing Effective Smart Home Systems

48


ID System Feature Priority Functional Requirement Details
FR-03.9. The system shall allow only power users to delete existing users.
FR-03.10. For a user already logged in, the system shall request the users passcode again after the
account has been idle for x number of minutes (configurable within user preferences).
FR-03.11. The system shall allow only power users to create or modify teams.
FR-03.12. The system shall store command issued and confirmed system changes in an Event Log.
FR-04 Ease of Use (1)

1
Description: The system shall be ease to use.
Stimulus/Response Sequence: User operates the system.
Functional Requirements:
FR-04.1. The system shall implement appropriate HCI methodologies for its User Interface.
FR-04.2. The system shall implement relevant industry-standard guidelines, depending on the actual user
interface used (e.g. Microsoft Windows, Internet Browser, etc.)
FR-04.3. The system shall warn users and ask for confirmation for operations that can potentially cause a
loss of data.
FR-04.4. The system shall implement an inference engine that periodically analyzes actions taken by user
and events stored and suggest/carry out tasks that can improve the users experience.
FR-04.5. For all operations documented in a Use Case diagram that are longer than three steps (e.g.
three mouse clicks) before then can be completed, the system shall provide a step-by-step,
FR-04.6. None of the commonly used features shall be more than three steps away (e.g. three mouse
clicks) from the main system window.
FR-05 Support Users
View of the
2
Description: The system shall provide a means to group devices together to create user-defined sub-
systems and enhance usability.
Project Domus: Designing Effective Smart Home Systems

49


ID System Feature Priority Functional Requirement Details
System (1)

Stimulus/Response Sequence: User wants to control devices together.
Functional Requirements:
FR-05.1. The system shall allow power users to create and name teams (groups of devices).
FR-05.2. The system shall allow users to control teams as a single device (e.g. turned on or off with a
single command).
FR-05.3. The system shall make available all the methods (i.e. operations) in common with all the
devices in present in a team.
FR-05.4. The system shall provide users with the option to disable or enable all the devices in a team with
a single command.
FR-05.5. The system shall allow devices to be part of multiple teams.
FR-05.6. The system shall provide users with the option to disable all the devices in a team with a single
command.
FR-06 Remote Access
Support
3
Description: The system shall also be operated remotely.
Stimulus/Response Sequence: User connects to the system from a remote location (e.g. office).
Functional Requirements:
FR-06.1. The system shall allow remote users to connect to the system from a remote location via the
home internet connection.
FR-06.2. The system shall provide a secure means to authenticate remote users.
FR-07 Reliability
2
Description: The system shall implement features to improve its reliability.
Stimulus/Response Sequence: Internal or external events causes the system to stop operating.
Functional Requirements:
Project Domus: Designing Effective Smart Home Systems

50


ID System Feature Priority Functional Requirement Details
FR-07.1. The system shall implement an internal mechanism to verify that a instant or deferred command
has been successfully executed.
FR-07.2. The system shall be able to restart automatically after a mains power outage.
FR-07.3. The system shall monitor itself and be able to recover after a crash.
FR-07.4. The system shall provide a means to store operation issues for later examination.
FR-07.5. The system shall provide a means to store information about notification options to report issues.
FR-07.6. The system shall automatically notify designated users when normal functioning is resumed.
FR-07.7. When recovering from a power outage, the system shall ensure that all controlled devices be in
sync with the last know configuration.
FR-07.8. The system shall ensure the integrity of the information stored.
FR-08 Support Users
View of the
System (2)

4
Description: The system shall offer customizable features.
Stimulus/Response Sequence: User perform changes in the system.
Functional Requirements:
FR-08.1. The system shall save user preferences and remember these the next time the same user
access the system.
FR-09 Compatibility
3
Description: The system shall be able to work within existing environment.
Stimulus/Response Sequence: User installs the system in an existing environment.
Functional Requirements:
FR-09.1. The system shall be able to operate successfully along with other home automation solutions.
FR-09.2. The system shall provide a way to identify its own devices from others.
FR-09.3. The system shall use Powerline (i.e. electrical mains) as its home network.
Project Domus: Designing Effective Smart Home Systems

51


ID System Feature Priority Functional Requirement Details
FR-09.4. The system shall provide support for at least other two network protocols (e.g. RF/IF, Twisted
Pair, etc.).
FR-10 Expandability
2
Description: The system shall allow users to add new devices.
Stimulus/Response Sequence: User wants to add a new device to the system.
Functional Requirements:
FR-10.1. The system shall provide users with the option to add a new compatible device into the system
via the User Interface.
FR-10.2. Users shall be able to integrate the new device into the existing system (e.g. adding it to a
teams, setting a schedule, etc.).
FR-11 Mobile Device
Support
3
Description: The system shall be accessed from a mobile device
Stimulus/Response Sequence: User wants to access the system from a mobile device.
Functional Requirements:
FR-11.1. The system shall provide a means for mobile users to access the system via a suitable user
interface.
FR-11.2. The system shall offer a suitable interface compatible with the visualization constraints of the
mobile device used.
FR-11.3. The system shall authenticate a user trying to connect via the mobile device.
FR-11.4. Mobile users shall not be able to perform admin (power user) tasks.
FR-12 Support for
Scheduled
Commands
1
Description: The system shall provide the ability to handle deferred (scheduled) commands.
Stimulus/Response Sequence: User wants to schedule a task for a team/device in the future.
Functional Requirements:
Project Domus: Designing Effective Smart Home Systems

52


ID System Feature Priority Functional Requirement Details
FR-12.1. The system shall provide users with a means to schedule a task in the future for a device via the
User Interface
FR-12.2. The system shall provide users with the option to repeat a scheduled task at a given interval
(e.g. daily, weekly, monthly).
FR-12.3. The system shall provide the option to schedule tasks for a device or a team.
FR-12.4. The system shall allow only power users to add/edit/delete a schedule for a team.
FR-12.5. The system shall routinely scan the active schedule to see whether any actions need to be
performed.
FR-13 Support for
Multiple Users
3
Description: The system shall support multiple users.
Stimulus/Response Sequence: User logs into the system.
Functional Requirements:
FR-13.1. The system shall provide power users with the ability to add new users in the system via the
User Interface.
FR-13.2. The system shall provide users with the ability to save their preferences.
FR-13.3. The system shall provide power users to designate an owner for a team.
FR-13.4. The system shall allow designated team owners to fully control the team.
FR-13-5. The system shall not allow team owners to delete a team or add/remove devices.
FR-14 Ease of Use (2)
3
Description: The system shall be able to resolve command conflicts.
Stimulus/Response Sequence: Users try to operate the same team or device at the same time; Users try to save
two conflicting schedules for the same team or device.
Functional Requirements:
Project Domus: Designing Effective Smart Home Systems

53


ID System Feature Priority Functional Requirement Details
FR-14.1. The system shall provide users with a warning message when another user is already operating
the same device (or team) and abort the last transaction.
FR-14.2. The system shall consider the team ownership (if available) when determining who has priority
over a conflicting schedule and keep/accept the one issues by the team owner.
FR-14.3. The system shall allow team managers to created closed teams to impede control of the
devices present in the team by other users.
FR-14.4. The system shall still allow power users to control a closed team.
FR-14.5. The system shall allow team owners to re-open a closed teams to allow control to all users.
Project Domus: Designing Effective Smart Home Systems

4.1.6. Sub-system Identification
This section provides a break-down of the system into the main components. Figure 12
provides a graphical representation of these sub-systems and Table 5 matches the
Functional Requirements identified in the previous section.


Figure 12 Sub-Systems Overview
Command Dispatcher will be responsible for issuing commands to system actuators
and to record the success/failure of a command.
Device Manager will be responsible for adding editing and deleting devices in the
system.
Event Collector will be responsible for collecting information coming from sensors
and either forwarding to the Flight Control or passing it to the Event Logger to be saved
in the system database.
Event Logger will be responsible for storing events occurring in the system.
Flight Control will be the main module responsible for coordinating system actions
and events.
Inference Engine will be responsible to analyze the events stored in the Event
Database and suggest course of actions to the Flight Control.
System Scheduler will be responsible for checking active schedules and sending action
requests to Flight Control.
Team Manager will be responsible for maintaining the device teams existing in the
system.
Project Domus: Designing Effective Smart Home Systems

55


User Admin will be responsible for adding, editing and deleting users from the system.
User Authenticator will be responsible for the authentication of local and remote
users.
User Interface will be responsible for interacting with the user (to collect input
requests and provide the status of the system).
Table 5 Functional Requirements grouped by Sub-system
Sub-System Functional Requirements
Command
Dispatcher
FR-02.3. If an instant command takes more than 3 seconds to complete, the
system shall provide continuous feedback to the user who requested it until
the command either returns with a OK/Failed result OR is aborted (cancelled)
by the user.
Device
Manager
FR-01.1. The system shall provide users with a feature to temporarily disable
or permanently remove a device present the system via the User Interface. A
device removed or disabled shall henceforth be operated manually i.e. no
automatic control or schedule shall affect its operation.
FR-01.2. The system shall allow users to re-enable a temporarily disabled
device. If the device had associated scheduled events, this shall ask the
authenticated user whether they are to be considered or discarded.
FR-01.3. When a device is being re-enabled, the system shall warn a user of
the presence of future scheduled event and shall be given the option to either
retain or remove (delete) these schedule.
FR-01.4. If user permanently remove a device from the system, all the
associated information (e.g. history, logs, and schedule) shall also be deleted
from the system.
FR-05.4. The system shall still provide users with the ability to operate a
device part of a team as it were stand alone. (e.g. can issue immediate
commands and scheduled events shall still apply).
FR-09.2. The system shall provide a way to identify its own devices from
others.
FR-10.1. The system shall provide users with the option to add a new
compatible device into the system via the User Interface.
FR-10.2. Users shall be able to integrate the new device into the existing
system (e.g. adding it to a teams, setting a schedule, etc.).
Event
Collector
FR-02.4. The system shall evaluate immediately information received by real-
time sensors (e.g. intruder alert).
Event Logger FR-07. 4. The system shall provide a means to store operation issues for
Project Domus: Designing Effective Smart Home Systems

56


Sub-System Functional Requirements
later examination.
FR-03.12. The system shall store command issued and confirmed system
changes in an Event Log.
FR-02.2. The system shall implement a means to record all instant command
requests and their outcomes for later user retrieval and examination.
Flight Control FR-07.1. The system shall implement an internal mechanism to verify that a
instant or deferred command has been successfully executed.
FR-07. 2. The system shall be able to restart automatically after a mains
power outage.
FR-07. 3. The system shall monitor itself and be able to recover after a crash.
FR-07. 6. The system shall automatically notify designated users when
normal functioning is resumed.
FR-07. 7. When recovering from a power outage, the system shall ensure
that all controlled devices be in sync with the last know configuration.
FR-11.4. Mobile users shall not be able to perform admin (power user) tasks.
FR-14.1. The system shall provide users with a warning message when
another user is already operating the same device (or team) and abort the
last transaction.
FR-14.2. The system shall consider the team ownership (if available) when
determining who has priority over a conflicting schedule and keep/accept the
one issues by the team owner.
FR-14.4. The system shall still allow power users to control a closed team.
FR-07. 8. The system shall ensure the integrity of the information stored.
Inference
Engine
FR-04.4. The system shall implement an inference engine that periodically
analyzes actions taken by user and events stored and suggest/carry out
tasks that can improve the users experience.
System
Scheduler
FR-01.3. When a device is being re-enabled, the system shall warn a user of
the presence of future scheduled event and shall be given the option to either
retain or remove (delete) these schedule.
FR-12.1. The system shall provide users with a means to schedule a task in
the future for a device via the User Interface
FR-12.2. The system shall provide users with the option to repeat a
scheduled task at a given interval (e.g. daily, weekly, monthly).
FR-12.3. The system shall provide the option to schedule tasks for a device
or a team.
FR-12.4. The system shall allow only power users to add/edit/delete a
schedule for a team.
Project Domus: Designing Effective Smart Home Systems

57


Sub-System Functional Requirements
FR-12.5. The system shall routinely scan the active schedule to see whether
any actions need to be performed.
Team
Manager
FR-05.1. The system shall allow power users to create and name teams
(groups of devices).
FR-05.2. The system shall allow users to control a team as a single device
(e.g. turned on or off with a single command).
FR-05.3. The system shall make available all the methods (i.e. operations) in
common with all the devices in present in a team.
FR-05.5. The system shall allow devices to be part of multiple teams.
FR-05.6. The system shall provide users with the option to disable or enable
all the devices in a team with a single command.
FR-13.3. The system shall provide power users to designate an owner for a
team.
FR-13.4. The system shall allow designated team owners to fully control the
team.
FR-13-5. The system shall not allow team owners to delete a team or
add/remove devices.
FR-14.3. The system shall allow team owners to created closed teams to
impede control of the devices present in the team by other users.
FR-14.5. The system shall allow team owners to re-open a closed teams to
allow control to all users.
User Admin FR-03.5. The system shall define two types of users: normal and power users
(administrators).
FR-03-6. The system shall grant access to certain functions to power users
only.
FR-03-7. The system shall allow only power users to create other users.
FR-03.8. The system shall allow only power users to reset passwords for
other users.
FR-03.9. The system shall allow only power users to delete existing users.
FR-03.11. The system shall allow only power users to create or modify
teams.
FR-13.1. The system shall provide power users with the ability to add new
users in the system via the User Interface.
FR-07. 5. The system shall provide a means to store information about
notification options to report issues.
FR-03.3. The system shall store username and passcode information in an
internal database.
Project Domus: Designing Effective Smart Home Systems

58


Sub-System Functional Requirements
User
Authenticator
FR-03.2. The system shall validate information provided in the login screen
against the credential stored in the system and grant access if there is a
match or deny access otherwise.
FR-03.10. For a user already logged in, the system shall request the users
passcode again after the account has been idle for x number of minutes
(configurable within user preferences).
FR-06.2. The system shall provide a secure means to authenticate remote
users.
FR-11.3. The system shall authenticate a user trying to connect via the
mobile device.
User Interface FR-01.5. The system shall alert a user that permanently deleting an object
from the system also removes all its associated information.
FR-02.1. The system shall provide feedback for a user request for an instant
command within 3 seconds from the command being issued by the user.
FR-03.1. The system shall present a login screen comprised of username
and passcode before allowing access to the system.
FR-03.4. The system shall request an initial username and passcode when
being first installed. The system shall use this information to create the first
power user (administrator) account in the system.
FR-04.1. The system shall implement appropriate HCI methodologies for its
User Interface.
FR-04.2. The system shall implement relevant industry-standard guidelines,
depending on the actual user interface used (e.g. Microsoft Windows,
Internet Browser, etc.)
FR-04.3. The system shall warn users and ask for confirmation for operations
that can potentially cause a loss of data.
FR-04.5. For all operations documented in a Use Case diagram that are
longer than three steps (e.g. three mouse clicks) before then can be
completed, the system shall provide a step-by-step,
FR-04.6. None of the commonly used features shall be more than three steps
away (e.g. three mouse clicks) from the main system window.
FR-06.1. The system shall allow remote users to connect to the system from
a remote location via the home internet connection.
FR-08.1. The system shall save user preferences and remember these the
next time the same user access the system.
FR-11.1. The system shall provide a means for mobile users to access the
system via a suitable user interface.
Project Domus: Designing Effective Smart Home Systems

59


Sub-System Functional Requirements
FR-11.2. The system shall offer a suitable interface compatible with the
visualization constraints of the mobile device used.
FR-13.2. The system shall provide users with the ability to save their
preferences.
General to the
System
FR-09.3. The system shall use Powerline (i.e. electrical mains) as its home
network.
FR-09.4. The system shall provide support for at least other two network
protocols (e.g. RF/IF, Twisted Pair, etc.).
FR-09.1. The system shall be able to operate successfully along with other
home automation solutions.
4.1.7. Glossary
A Glossary of the terms used when defining Functional Requirements is provided
below.
Action A self-contained instruction executed in the system. Actions can
be triggered by a user (e.g. instant action) but can also be carried
out automatically (e.g. scheduled action).
Actuator An electric or electronic device connected to the system that
controls an appliance (e.g. a light).
Audit Log A table in the system database that stores security information such
as login attempts and system changes.
Automated
Action
An action carried out by the system without direct user input.
Closed Team A team that has been given restricted access by a team owner. A
closed team can no longer be controlled by a normal user but only
by its owner or by a power user (see also: Team).
Deferred
Command
A command that is issued as part of a schedule set by the user.
Device An actuator or a sensor existing in the system.
Disabled Device A device that has been made inactive. The device still exist in the
system but will not be considered. If this device is a sensor, its
input will not be considered; if an actuator, no commands will be
Project Domus: Designing Effective Smart Home Systems

60


issued to it. A disabled device retains all its information in the
system (e.g. details and schedule) and can be re-enabled at any
time.
Event An input provided by a Sensor and that may trigger an automated
action.
Instant Action A command given by the user that is intended to immediately act
upon a specific device or team.
Local User An authenticated user who connects to the system locally (e.g.
while being in the home).
Mobile Device A device used by mobile users to connect to the system (e.g. a
PDA or mobile phone).
Mobile Users A subset of local users who will use a mobile interface to connect
to the system (e.g. a PDA).
Passcode A secret alphanumerical string that grant access to the system. It is
used combined with a username.
Power User An authenticated user in the system with administrator rights.
Only a power user will be able to perform certain tasks in the
system (e.g. creating teams).
Real-time Sensor An input device that will provide real-time input to the system.
Remote User An authenticated user who connects o the system remotely via the
Internet.
Removed Device A device that is no longer part of the system. When a device is
removed, all its data (e.g. historical information, schedules, etc.)
will also be permanently removed from the system. If the device
is then re-added, it will be treated as a new device.
Schedule A command set in the future that will trigger one or more actuators
when executed. A schedule can also contain multiple or recurring
events.
Scheduled
Action
An Automated Action carried out as a result of a Deferred
Command set by the user.
Sensor An electric or electronic device connected to the system that
provide a digital or analog input (e.g. a thermometer).
Project Domus: Designing Effective Smart Home Systems

61


System The Smart Home system developed with this project.
Team A collection of devices that can be operated as one device.
Team owner An authenticated user designated by a power user who has control
over a team. (see also: Team).
User Any authenticated users of the system.
User Interface It provides input and output capabilities to allow users to interact
with the system.
The system may need to provide different interfaces to cater for
the differences among local, remote and mobile users.

Username A unique alphanumerical string that identify a user on the system.
4.2. Design
This section will take the information outlined by the analysis and implement the actual
design of the Smart Home system using the Unified Modelling Language (UML)
design methodology to represent the information required.
System Operation
The Use Case diagram depicted in Figure 13 outlines the main tasks performed by users
of the system. Authenticated users can display the status of any device controlled by the
system, issue a command to change a status of a device through an Actuator, setup a
schedule for future events, and disconnect a device that can then be controlled
manually. In order to enhance security, some of the system functionalities can be made
not available to Remote Users (not shown in the diagram).
Project Domus: Designing Effective Smart Home Systems

62




Figure 13 Operating the System

User Authentication
Before users can carry out any operation within the system, they will need to be
authenticated. Three categories of authenticated users are defined as follows:
Authenticated Users, Remote Users, who connect to the system remotely, and Power
Users, who will perform certain administration functions in the system. A time-stamped
entry will be saved into an Event Log for reference. Figure 14 illustrates this scenario
as a Use Case diagram.
Project Domus: Designing Effective Smart Home Systems

63



Figure 14 User Authentication
User Administration
To enforce the user authentication feature, users will need to receive a username and
password in order to log in. Only Power Users will have access to creating a new user
or resetting a user password . Figure 15 represents the Use Case diagram for this
scenario.

Project Domus: Designing Effective Smart Home Systems

64



Figure 15 User Administration
Device Administration
Figure 16 represent the Use Case diagram that outlines how devices can be added,
edited or removed from the system. Only Power Users will be able to execute these
commands and the operation will also be logged in the Event Log for reference.

Figure 16 Managing Devices
Project Domus: Designing Effective Smart Home Systems

65


Team Administration
Teams provide users with the option of grouping devices that can work together as part
of virtual, user-defined sub-systems, e.g. a HVAC or Home Security system. The main
purpose of this feature is to offer users the ability of creating images of the system
according to their understanding, thus increasing the overall usability. All the
functionalities common to all the devices grouped in a team can be controlled together
as if it were a single device. Devices can belong to more than one Team and devices
that belong to a Team can still be managed individually. Only Power Users can create,
modify and delete Teams. However, once a Team has been set up, its operation can be
delegated to a member of the Authenticated User group. Figure 17 provides the Use
Case diagram for the management of this feature.




Figure 17 Managing Teams
Schedule Administration
The system provides the option to schedule recurring actions for one device or a team.
This is considered a useful feature of a Smart Home system. The system will
continuously pull the Schedule database to see whether there are actions to be carried
out. A Team schedule can only be edited by a Power User of by an Authenticated user
Project Domus: Designing Effective Smart Home Systems

66


who was made owner of the Team. Figure 18 represents the Use Case diagram for this
feature.

Figure 18 Managing Schedules
Event Management
Events are input provided by sensors communicating with the system, e.g. a
thermometer or an occupancy sensor. In order not to overburden the system with a
constant stream of data, sensors will be sub-divided into two categories. The first
category is for real-time (RT) sensors, which, due to the sensitivity of the input
provided, communicate directly to the Flight Control, e.g. a motion detector part of a
the Home Security System. The second category contains all the other sensors, such as
a thermometer, which might not require immediate action. In this case, the input
provided is simply stored in the system database and will be analyzed, perhaps in
combination with other events, at the next scheduled cycle. Figure 19 displays the Use
Case diagram for this scenario.
Project Domus: Designing Effective Smart Home Systems

67



Figure 19 Managing Events
Command Dispatcher
Figure 20 illustrates the Use Case diagram for how the system dispatches commands to
an Actuator. In order to enhance reliability, the Actuator will implement a closed-loop
feedback which will provide the system with a means to detect whether the command
has been executed properly.


Figure 20 Dispatching Commands

Project Domus: Designing Effective Smart Home Systems

68


Flight Control
Figure 21 shows the Use Case diagram for the Flight Control sub-system. The Flight
Control is the central element of the system as it coordinates all the actions and events
occurring in the system.

Figure 21 Flight Control Sub-System
Inference Engine
The Inference Engine comprises of a Rule-set database that contains a Bayesian
Network engine that interacts with the events occurring in the system and provide
suggestions to the Flight Control about possible actions that need to be carried out in
the system. Ideally, the Rule-set database should also be able to learn from historical
information in order to become more effective. Figure 22 shows the Use Case diagram
for the Inference Engine.
Project Domus: Designing Effective Smart Home Systems

69



Figure 22 Inference Engine Sub-system
4.3. Implementation
This section will outline the actual implementation of the Proof-of-concept (POC)
system. Firstly, it will introduce the technology that will be used and then outline the
inner workings of the actual system. Of the various sub-systems identified in the
previous section, only the following will be further developed:

Command Dispatcher
Device Manager
Event Collector
Event Logger
Flight Control
User Interface
Inference Engine
Project Domus: Designing Effective Smart Home Systems

70


4.3.1. Hardware
The POC system uses hardware that is compatible with the LonWorks technology,
developed by Echelon Corp.
4

LonWorks is an industry standard (ISO/IEC 14908-1) home network technology
which has been successfully used to control and automate commercial buildings and
factory settings. LonMark International is the independent body that manages the
evolution of the technology by issuing interoperability guidelines and certifications for
new devices.
LonTalk (EN14908/1), the LonWorks communication protocol, implements a
structure comparable to the OSI network model, with six of its seven layers integrated
in the device hardware. The protocol includes features such as media access control,
transaction acknowledgement, priority transmission, authentication, multicast and
broadcast addressing, error detection and recovery. A LonWorks network consists of
intelligent devices that communicate with each other using LonTalk protocol over a
communications channels, which may be implemented using several medium, such as
Powerline, twisted-pair, RF or any mix of these. The protocol defines the format of the
messages being transmitted between devices and the actions expected when a device
sends a message to another. Figure 23 shows how two LonWorks devices exchange
these messages and how the various network layers encapsulate these messages with
the layers frame.


Figure 23 How LonWorks Devices exchange Messages


4
See: http://www.echelon.org
Project Domus: Designing Effective Smart Home Systems

71


All LonWorks devices comprise of a microchip, called Neuron Chip, which functions
as a network communications processor and an application processor. Each Neuron
Chip comes with a unique 48-bit software-accessible serial number (called Neuron ID,
or NID) that ensure uniqueness of the device and facilitates its installation and
configuration. Devices are programmed using a variant of ANSI C, named Neuron C,
which adds event-driven capabilities to the standard C language. Once developed and
debugged, the code is then loaded into the devices using the EPROM space provided in
the logic board.
The Neuron C language creates the software interface that a device will use to issue or
receive commands and to communicate information about its status to other devices in
the network. Each LonWorks device comprise of one or more functional blocks (FBs)
which group the input/output interface into coherent groups. Each Functional Block
implements a portion of a devices application and performs the tasks of receiving
configuration and operational data inputs, processing the data, and sending operational
data outputs. FBs declare configuration properties (CPs) and network variables (NVs).
Using the Object-Oriented paradigm, a Configuration Property corresponds to an object
attribute, whereas a Network Variable provides the object methods that can be used to
access or modify a CP. Figure 24 provide a graphical representation of a typical
LonWorks device.



Figure 24 Anatomy of a LonWorks Device
Project Domus: Designing Effective Smart Home Systems

72



To ensure inter-operability between devices in a multi-vendor environment, LonMark
International provides guidelines for the definition of these devices. Such
implementation details are then usually provided to the system integrator when buying
the physical device. The most up-to-date guideline documents can be found on line at:
http://www.lonmark.org/.
In order for two NVs to connect one another, they must be of a compatible type. For
example, Figure 25 shows how a LonWorks switch can operate a light device by
connecting its output NV, with a compatible input NV of the controlled device, in what
is also called a point-to-point connection.

Figure 25 Network Variables
A single output NV may connect to more than one input NVs, creating what is called a
fan-out connection. This is a useful feature that would allow, for example, a single
switch to control multiple lights or a light to be controlled by multiple switches.
Through a process called binding, usually performed during the design and installation
phase, the devices firmware is configured to know the logical address of the other
device, or group of devices, in the LonTalk network from which to expect input via one
of its NVs. This process creates logical connections among devices that might be
thought as virtual wires.
Finally, controlled devices can also provide NVs that can be used to determine whether
a command completed successfully, thus increasing reliability. Figure 26 depicts an
example of a typical LonWorks solution that is made of two switches, one light sensor,
and two lamps. The system also makes use of the feedback mechanism via one of the
lights nvoSwitchFb output NVs. In such configuration, the light can return its
current status to the controlling switches via the nviSwitchFb Network Variable.

Project Domus: Designing Effective Smart Home Systems

73



Figure 26 A Typical LonWorks Solution
The POC system uses a Mini EVK Evaluation Kit, acquired from Echelon Corp., which
includes the following:

A FT 3120 and FT 3150 Evaluation Boards (EVBs)
Two I/O Boards (Mini Gizmos) that can be attached to each EVB
A USB Network Interface (U10) used to connect the computer to the LonWorks
network and communicate with the devices
Twisted-pair (TP) cables for wiring the two EVB and the USB Network
Interface
Installation CD-ROM containing application examples, utilities and drivers for
Windows 2000/XP.

Project Domus: Designing Effective Smart Home Systems

74



Figure 27 The Mini EVK Evaluation Kit
Figure 27 provides an overview of the Mini Kit and its components. The two
Evaluation Boards could be programmed using the Neuron C language and the
Installation CD also provided a few examples that would emulate different types of
LonWorks devices.
The two Mini Gizmos I/O boards provided the input/output devices that could be
piloted by the EVBs. The following I/O devices were available:

Eight mini-switches, of which seven are available to the application (input)
Eight LEDs, connected to their corresponding switch to provide visual feedback
about the status of a simulated device (output)
One temperature sensor (input)
One buzzer (output)

Project Domus: Designing Effective Smart Home Systems

75


For the POC system, the FT3150 Board, configured with the MGDEMO Neuron C
image will be used. Table 6 details MGDEMO the Functional Blocks, Configuration
Properties and Network Variables developed for the device.

Table 6 MGDEMO Attributes and Methods
Functional Blocks (device) Configuration Properties Network Variables
5

SFPTnodeObject nciNetConfig
cpLocation
nvoStatus
nviRequest
nvoDirectory
SFTPclosedLoopActuator (lights) cpHeartbeatInterval nviLight
nvoLightFb
SFTPclosedLoopSensor (switches) cpHeartbeatInterval nvoSwitch
nviValueFb
SFTPhvacTempSensor
(thermometer)
cpThrottle
cpDelta
nvoTemperature
nvoTemperatureF
SFTPOpenLoopActuator (buzzer) nviFrequency
nviEnable
4.3.2. Software
The POC system will outline a possible solution for a Temperature Control system,
which will include the following devices:

Sensors (input devices):
A Temperature Sensor (TS)
A Motion Sensor (MS)
A Light Sensor (LS)

Actuators (output devices):
HVAC System
A Fire Alarm Siren



5
The nvo and nvi suffix define an output or input variable respectively.
Project Domus: Designing Effective Smart Home Systems

76


Table 7 reports how the real-world devices listed above will be represented by the
system, while Figure 28 provides a detailed view of the Mini Gizmo I/O board that
contains the devices used by the POC system.

Table 7 Mapping Real-world Devices to the POC
Real-world Device POC (Mini Gizmo I/O Board)
Main Switch Switch #1 (ON = activated)
HVAC System Switch #2 (ON = activated)
Motion Sensor (MS) Switch #3 (ON = activated)
Light Sensor (LS) Switch #4 (ON = daytime)
Temperature Sensor (TS) Temperature sensor
Fire Alarm Siren Buzzer


Figure 28 Mini-Gizmo I/O Board
The Temperature Control System (TCS) will continuously interpret the data provided
by the sensors installed and take actions depending on the input received. The
applications main screen is divided into two main sections, left to right: the section on
the left can be defined as the control panel, providing all the settings available and
the system outputs; the section on the right provides the real-world representation of the
system. This will also provide the location of the actual sensors and actuators
throughout the house: the Light Sensor, Motion Sensor, Fire Alarm, and HVAC).
Project Domus: Designing Effective Smart Home Systems

77


Although in the final system some of these elements would exist in its own sub-menu,
for ease of representation, the POC provides everything in one screen. Figure 29 shows
a screenshot of the systems main window.


Figure 29 Main Screen of the POC System
After the introductory screen is acknowledged, the system will start in idle mode; that
is, waiting for the user to select the device to be monitored and managed. In order to
bind the LonWorks kit to the application, the following steps will need to be carried
out:

1. Click on the Monitor button. The Add Device dialog box will display, shown
by Figure 30.
2. Either enter the Neuron ID in the text box provided (if known) or press the
Service switch on the EVB to fill the text box automatically. Figure 31
illustrates the location of the switch in the board.
3. Press the OK button.

Project Domus: Designing Effective Smart Home Systems

78


The software is now bound the EVB and will show the status of the actuators and
sensors present in the system.


Figure 30 Add Device Dialog Box


Figure 31 EVK Service Switch

The POC system can be conceptually sub-divided into three main sub-systems: the Fire
Alarm sub-system, the Heating and Air Conditioning sub-system, and the Inference
Engine. The following sections will go into more details for each of these sub-systems.
Both the FA and HVAC sub-systems can be turned on or off using their main switches.
Fire Alarm Sub-System
The Fire Alarm sub-system (FA) will monitor the environment for the likelihood of a
fire in order to alert security personnel in time to address potentially dangerous
situations. Figure 32 displays the settings for the FA sub-system.

Project Domus: Designing Effective Smart Home Systems

79



Figure 32 Fire Alarm Sub-system Settings

The FA will activate an alarm when some thresholds specified by the user have been
met. The system also provides a way to mute the alarm once the alarm has been
acknowledged and the situation being investigated. The FA uses two interlinked ways
to determine the likelihood of a fire: the first is by comparing the current temperature
with what is considered a high and the other is by monitoring the probability of a fire
against a pre-set value, controlled by the Sensitivity slider. The probability value is
calculated in real time by the BN and it is displayed by the application in the Current
Fire Likelihood bar, outlined in Figure 32. Figure 33 shows the logic flow for the FA
sub-system. The code implementation of this logic flow is provided in the Appendices.



Figure 33 Logic Flow for the FA Sub-system
Project Domus: Designing Effective Smart Home Systems

80


Heating and Air Conditioning Sub-System
The Heating, Ventilating and Air-Conditioning (HVAC) sub-system monitors and
controls the temperature in the house. Should this fall outside the comfort zone set by
the user, the system might bring the temperature within the parameters specified.
Figure 34 displays the settings for the HVAC sub-system.

Figure 34 HVAC Sub-System Settings
Before deciding to turn the system on, the HVAC will consider some conditions.
Firstly, the system will not take any action if the user set this to manual mode (by
ticking the Manual Mode check box) and will let instead the user take control of the
system. Should the system be configured to operate in automatic mode, it will consider
the input from the sensors to determine the best course of action. Specifically, it will
try to determine whether there is anyone in the house and whether to employ a more
conservative, energy-saving scheme if it is night-time. Figure 35 provides the logic
flow for the HVAC sub-system. The code implementation of this logic flow is provided
in the Appendices.


Figure 35 Logic Flow for the HVAC Sub-system
Project Domus: Designing Effective Smart Home Systems

81


Inference Engine Sub-System
The Inference Engine sub-system (IE) implements a Bayesian Network through the
Netica API provided by Norsys Software Corp.
6
, Vancouver (CA). The BN should
enhance the systems ability to detect a fire that would be otherwise limited to
measuring the temperature in the house. The BN correlates all events reported by the
various sensors and combines this with other factors such as the status of other systems,
such as the HVAC. It then calculates and returns the real-time likelihood of a fire
scenario by calculating its statistical probability according to the state and relationships
of the other nodes.
Manually calculating the probability of such a model can be a tedious and time-
consuming task as the calculations involved can increase exponentially and the amount
is given by the formula: S
n
-1, where S is the number of states that a variable can
assume and n is the number of nodes. For the BN illustrated in Figure 36, which
contains only binary variable, it would still require 2
8
1=255 calculations. In reality
Bayesian Networks do not actually need to perform all these calculations; however a
more in-depth discussions is beyond the scope of this paper. Further discussions on
Bayesian Networks can be found in the material referenced.



6
See: http://www.norsys.com/
Project Domus: Designing Effective Smart Home Systems

82



Figure 36 Causal Graph for the FA Sub-system
Table 8 provides the rationale behind these relationships. Note that each node will have
only two possible status. The probability tables for a practical implementation of these
relationships can be found in the appendices.

Table 8 BN Nodes and Relationships
Node (values) Relationship with Reasons
Fire Danger
(true/false)
none Fire Danger is the outcome scenario sought by
this BN.
Cooking Time
(true/false)
High Temperature
Fire Danger
High Temperature: the temperature might raise
above normal values while cooking.
Fire Danger: The risk of a fire is somewhat
greater when cooking.
NOTE: Not implemented by the application. It
could be gathered out of evidence such as the
oven/cooker being switched on etc.
Daytime
(true/false)
HVAC
High Temperature
Lived In
HVAC: A longer day or shorter night will
influence how the HVAC system will operate.
High Temperature: Longer summer days are
likely warmer; longer winter nights are likely
colder.
Project Domus: Designing Effective Smart Home Systems

83


Node (values) Relationship with Reasons
Lived In: The Motion Sensor is likely to be more
often ON during the day (people moving around)
than at night.
High Temperature
(true/false)
Fire Danger Causal connection between high temperature in
the room and the likelihood of a fire.
HVAC On
(true/false)
High Temperature

It is less likely to have a high temperature when
the air conditioning is on (so a high temperature
developing in this circumstance might be more
suspicious).
Lived In (true/false) HVAC On
Fire Danger
HVAC On: This is a direct consequence of the
HVAC logic, which is to turn on when the motion
sensor is activated.
Fire Danger: Here an assumption was made that
when there are people in the house there is a
minor probability for fire to be developed.
Summer
(true/false)
High temperature
Daytime
HVAC
High Temperature: It is likely to be hotter in
summer than winter.
Daytime: Days are shorter in winter time than
summertime.
HVAC: Air conditioning might be turned on more
often in summertime (and the heating system in
winter time).
NOTE: Not implemented in the application. The
information might be gathered from a calendar or
by other type of evidence.

Figure 37 shows a point-in-time representation of the BN for the FA sub-system. Note
how the probabilities contained in the nodes will change depending on the status of
other nodes. In the example provided, the BN was provided with evidence known at
that point in time (see nodes with probability set to 100%). Generally, the more
evidence can be provided to the BN, the more accurate the likelihood for the outcome
monitored will become.

Project Domus: Designing Effective Smart Home Systems

84



Figure 37 Fire Alarm Bayesian Network
Although not implemented in this POC, it is worth mentioning that, in a real-world
scenario, the initial probabilities set up in the BN could be adjusted using this evidence,
thus potentially increasing its prediction accuracy over time. The code implemented in
the application to connect to the Netica API is provided in the Appendices.
4.4. Testing
This section illustrates the testing carried out with the POC system. It provides an
outline of the test plan, its deliverables, a summary of the results and the outcomes of
the test. Details of the individual tests are provided in the appendices.
4.4.1. TestPlan
This section will outline the Test Plan for the POC system.
Introduction
This plan is drafted for the application Temperature Control System (TCS), Version
0.0.1.1, which has been designed as a Proof-of-Concept for a Smart Home system
outlined in the Analysis section of this paper. The purpose of this Test Plan is to test a
Project Domus: Designing Effective Smart Home Systems

85


subset of the initial functional requirements outlined in the Design section displays the
sub-set of Function Requirements implemented in the POC. This table shall form the
basis for the testing strategy along with the logic flows outlined by Figure 33 and
Figure 35.
Interfaces with Other Systems
In order to run correctly, the application tested will need the following software
installed on the machine used for testing:

Netsys Netica Software, Version 4.08
Microsoft Visual Studio 2005
Testing Approach
As this POC was conceived as a throw-away prototype, the code is as such not intended
to be re-used and no other testing techniques other than System Testing will therefore
be used.
Suspension Criteria and Resumption Requirements
Test Cases are given a Severity (1= high, 3= low) and Priority (1= must have, 3= nice
to have). All failed test cases will be reported in the Bug Report along with details of
the failure and any workaround (if available). However, only Severity 1 or Priority 1
features are considered high impact. Testing will be discontinued if one of the
following conditions is encountered:

2 Severity 1 bugs found, or
2 Priority 1 bugs found

Testing will not be halted if non-high impact bugs are found. Testing will resume as
soon as a new build which corrects the high-impact bugs is available. The test
execution order will take the following order:

1. Smoke and confidence tests
2. The tests which found the bugs which have just been fixed
3. The regression tests
Project Domus: Designing Effective Smart Home Systems

86


4. The rest of the tests
Test Deliverables
The following deliverables are part of this plan:

Test plan (this document)
Test cases
Bug reports
Test summary reports
Testing Tasks
Identify:
The set of tasks necessary to prepare for and perform unit, integration, and system
testing
All inter-task dependencies and any special skills required
Environmental needs
In addition to the software specified in the Interface with Other Systems section of
this Plan, the following HW and SW will also be required to perform the tests:

Minimum Requirements:
Operating System Windows XP SP2
CPU Intel Pentium 4, 2 GHz
1GB RAM
Screen resolution 800x600
100 MB available hard-disk space
One USB (1.1) Port available
Echelon Mini EVK Kit, Rev. A W.W. 08/08 37323
FTDI Echelon USB Network Interface Driver v. 2.0.2.0
OpenLDV Driver v. 3.20.29
Microsoft Visual Studio 2005
Project Domus: Designing Effective Smart Home Systems

87


Identified Risks
Details, impacts, and contingency plans for the high-level risks that may occur during
the testing procedure are outlined in Table 9.

Table 9 Test Plan Risks and Contingencies
ID Risk Impact Contingency Plan
1 One high-impact
bug found
The user is severely affected
by the lack of an important
feature.
Document the issue in the bug
report and provide a workaround (if
possible)
2 Two high-impact
bugs are found
Delays caused by test
procedure being halted and
re-work to occur in the
application
Lift code freeze and debug the
application in order to resolve the
bugs found within 48 hours. If this
cannot be resolved within the
timeframe provided, exclude the
feature from the POC.
4.4.2. TestCases
Table 10 reports the summary of all the test cases and their results. The details of each
test case can be found in the Appendices.
Table 10 Summary of Test Results
ID PASS/FAIL
(ROUND)
SEV PRI NOTES
1 PASS (1) 2 1
2 PASS (1) 1 1
3 PASS (1) 2 2
4 FAIL (1)

2 2 Error message: Invalid Neuron ID. The Neuron ID must be
specified in 12-digit hexadecimal number.
The number provided in the test seems to be one digit
short?!?
WORKAROUND: YES
5 PASS (1) 2 1
6 PASS (1) 2 1
7 PASS (1) 2 1
8 PASS (1) 2 2 The setting seems to be repeated at each cycle in the log.
Project Domus: Designing Effective Smart Home Systems

88


ID PASS/FAIL
(ROUND)
SEV PRI NOTES
9 PASS (1) 2 1
10 PASS (1) 2 2 The calculated values seems to be rounded up/down (e.g.
5% of 15 is 0.75; 5% of 28 is 1.4 but the min/max values are
always +1/-2 degrees.
11 PASS (1) 2 3
12 PASS (1) 2 1
13 PASS (1) 2 3 Neuron ID of Device 2: 04284CAF0200
14 PASS (1) 1 1
15 PASS (1) 1 1 Cannot set High Temp value below 29 degrees.
Buzzer does not turn OFF once the alarm is triggered but
you will need to mute the alarm to make it stop (feature or
bug?)
16 PASS (1) 2 1
17 FAIL (1) 1 1 Mute Alarm doesnt get un-ticked.
18 PASS (1) 2 2 Calculated values seem rounded up/down to the nearest
unity (e.g. 1.24 = 1; 2.4 = 2).
19 PASS (1) 2 2
20 PASS (1) 2 2
21 PASS (1) 2 2
22 PASS (1) 2 1
23 PASS (1) 2 1
Project Domus: Designing Effective Smart Home Systems

4.4.3. FunctionalRequirementsImplementedinPOC
Table 11 outlines the subset of the original Functional Requirements implemented in the POC.

Table 11 List of Functional Requirements Implemented
Sub-System Functional Requirement Details Implementation Details
Device
Manager
FR-01.1. The system shall provide users with a feature to temporarily disable or permanently
remove a device present the system via the User Interface. A device removed or disabled shall
henceforth be operated manually i.e. no automatic control or schedule shall affect its operation.
HVAC system can be set to manual
mode.
HVAC and FA sub-systems have
main switch to inhibit control of the
devices from the application.
User Interface FR-02.1. The system shall provide feedback for a user request for an instant command within 3
seconds from the command being issued by the user.
Immediate (< 3 sec) visual feedback
provided by objects in UI.
Event Logger FR-02.2. The system shall implement a means to record all instant command requests and their
outcomes for later user retrieval and examination.
Event Logger to display a time-
stamped record of command
requests and other actions occurred
in the system.
Event
Collector
FR-02.4. The system shall evaluate immediately information received by real-time sensors (e.g.
intruder alert).
System to continuously poll status of
sensors and actuators (< 1 sec).
Event Logger FR-03.12. The system shall store command issued and confirmed system changes in an Event Log. Implemented by Event Logger.
User Interface FR-04.1. The system shall implement appropriate HCI methodologies for its User Interface.

Visual representation of devices
using the house blueprint.
Project Domus: Designing Effective Smart Home Systems

90


Sub-System Functional Requirement Details Implementation Details
Use of real-world analogies (e.g.
sliders) to control device settings.
Objects and settings logically
grouped together.
Enabled use of mouse with
keyboard accelerators (shortcuts) as
secondary ways to access all main
features.
User Interface FR-04.2. The system shall implement relevant industry-standard guidelines, depending on the actual
user interface used (e.g. Microsoft Windows, Internet Browser, etc.)
Standard Windows objects
implemented in GUI.
User Interface FR-04.6. None of the commonly used features shall be more than three steps away (e.g. three
mouse clicks) from the main system window.
All main features represented in
main window.
Event Logger FR-07.4. The system shall provide a means to store operation issues for later examination. Implemented in Event Logger.
Device
Manager
FR-09.2. The system shall provide a way to identify its own devices from others. Implemented via LonWorks Device
ID and Network ID.
Device
Manager
FR-10.1. The system shall provide users with the option to add a new compatible device into the
system via the User Interface.
Implemented via the Add Device
dialog box.
Device
Manager
FR-10.2. Users shall be able to integrate the new device into the existing system (e.g. adding it to a
teams, setting a schedule, etc.).
Implemented via the Add Device
dialog box.


Project Domus: Designing Effective Smart Home Systems

91


4.4.4. BugReport
Table 12 provides the list of tracked bugs for the application.
Table 12 Bug Report
Bug # Title Description Status Feature Area Severity Environment Resolution
1 Manual Neuron
ID
Cannot type Neuron ID
manually (doesnt work?)
Fixed Device Manager 3 (low) Tried with Neuron ID
04D5CA75020
Neuron ID provided in the test
case was missing a zero
(04D5CA750200). However
Text Box might need to be
expanded to show full string
at once.
2 Buzzer does not
get un-muted
Muted buzzer does not get
un-muted when the FA is
triggered
Open Fire Alarm Logic 1 (high) FA Alarm system
starts with Mute
Alarm ticked




Project Domus: Designing Effective Smart Home Systems

4.4.5. TestOutcomes
Out of the total number of test cases devises, 21 passed, giving a first-pass rate of 91%.
Moreover, one of the failed tests (Test # 4) was not a high-impact feature and had a
workaround and a sub-sequent investigation found that the reason of the failure was
caused by the incorrect number being provided in the test case.
The other failed test (Test # 17) is high-impact as it affects an important feature of the
FA sub-system but it will not be a show-stopper according to the Suspension Criteria
listed previously. However, if time allows, a decision will be made to see whether it
will be feasible to correct this bug before the deadline.
Project Domus: Designing Effective Smart Home Systems

93


5. Conclusion
This chapter presents the conclusion drawn from the work carried out for the project. It
provides a summary of the work performed, the main findings, and recommendations
for future work. Finally, it includes comments on the learning outcomes from a
personal point of view.
5.1. SummaryoftheWork
Chapter 1 has defined the initial aim and objectives for this project. The aim was to
develop a proof-of-concept that would address at least some of the challenges found
during the research. The intellectual challenge was to investigate how a Smart Home
system could be made more effective by using AI techniques.
Chapter 2 has provided the formal definition of a Smart Home system and outlined a
history of appliances and home networking technologies which are fundamental to the
existence of a Smart Home. It has also provided an overview of recent development and
current research projects.
Chapter 3 has investigated in more detail the basic blocks of a Smart Home system and
has provided an overview of home network communication protocols in existence
today. It has then expanded on the potential market for Smart Homes, outlining
benefits, needs, and concerns reported by recent researches. Finally, it has outlined
current design challenges and provided suggestions on how they could be addressed.
Chapter 4 has dealt with the actual development of a Smart Home system. In the
Analysis section, the system requirements and the main sub-system for the system were
outlined in details. The Design section has expanded the analysis by documenting use
case scenarios and integrating these into the sub-systems identified. The
Implementation section has outlined the details of a proof-of-concept system by first
introducing the hardware and software used, and then providing its implementation
details. Finally, the Testing section has outlined how the system testing was planned,
executed, and how its results were analyzed.
Project Domus: Designing Effective Smart Home Systems

94


5.2. ProjectFindings
The main finding of this project is that it is indeed possible to make a Smart Home
system more effective by integrating AI technologies into it. The proof-of-concept has
provided an example on how such a system can analyze the information gathered from
the environment using a Bayesian Network that can be used by an inference engine that
could calculate the likelihood of a fire. Although the POC offers a simplified view of a
Fire Alarm system, it already offers a solution that can be implemented in a real-world
application. It also illustrates a concept that can be further developed to support
different and more complex decision-making scenarios. Moreover, the inference
engine could be enhanced further so that it can learn from the input provided by users
actions, e.g. whenever a user cancels or overrules a command, and from the actual data
gathered by sensors, e.g. determining actual cooking times. This will enable the system
to adapt to the specific environment where it operates and become more accurate, thus
increasing its effectiveness overtime.
5.3. RecommendationsforFutureWork
Regarding the proof-of-concept system developed by this work, it is understood that it
provides a subset of a fully functional Smart Home system. Therefore, the first
recommendation would be to develop and implement the other areas identified in the
Analysis and Design sections. Furthermore, future work should provide implementation
of the core as a Web Service and develop a web-based User Interface as this will
provide support to heterogeneous web-based clients which will allow mobile and
remote users to connect. Finally, the system demonstrated how Bayesian Networks can
effectively support decision making in many automated areas of the system and an
effort should be made to explore this concept further.
General recommendations can also be provided about the design of Smart Home
systems. First, it is suggested that producers of Smart Home technology should take
more time to try and understand users needs before developing new products and
should put more effort in making potential users understand what their solutions can do
for them. Second, as the existence of too many standards has been slowing down a
wider adoption of this technology by the consumer and building industries, it is
Project Domus: Designing Effective Smart Home Systems

95


therefore arguable that the current consolidation trend ought to continue in order to
push this technology farther along the Technology Adoption Lifecycle. Third, lack of
available expertise in the industry has contributed to the creation of ineffective
solutions, in spite of sometimes high implementation costs. As choosing the right
technology mix plays an important role in the success of a Smart Home system, it is
arguable that, as more expertise become available, better, cheaper, and more effective
solutions will be made available.
On a positive note, this technology can fulfill many of the expressed needs and address
most of the concerns. All the design challenges examined in this paper can be overcome
by using the right approach and implementing the correct methodology. Reliable, cost-
effective, and supported technology is available and other research fields, such as AI,
can contribute to make Smart Home systems more effective.
5.4. LearningOutcomes
5.4.1. Research
Google Scholar proved to be an invaluable starting point to locate white papers,
publications and books on the topic. Reviewing this literature provided a deeper insight
on Smart Home systems, their challenges and recent researches made in the field, all of
which helped and challenged to dig deeper in certain areas to gain a more complete
understanding of the subject. The student memberships of ACM and IEEE also helped
in providing full access to most of the research papers and publications found, whilst
the local DIT library and Book24x7.com provided access to the books.
5.4.2. Analysis
This project has allowed me to apply methodologies and concepts learned in this course
to a real-world problem and to effectively document the requirements of an Information
System.
5.4.3. Technical
As identified at the beginning of this project, coding has been the singe biggest
challenge of this project, mostly due to lack of recent hands-on experiences with the
Project Domus: Designing Effective Smart Home Systems

96


subject. Fortunately, the code samples provided with the LonWorks kit, coupled with
the guidance provided by Echelon technical support personnel and on-line forums,
always allowed the project to progress further.
5.4.4. ProjectManagement
The application of proper Project Management techniques helped to keep this project
on track. For example, the initial Risk Identification carried out was important to spot
potential problems and brainstorm contingency plans should any of these risks have
occurred. As a result, it was possible to avoid most of this potential problems and with
the confidence that there was a contingency plan in place should a monitored risk have
materialized. The decision about what technology to use was made at the right time into
the project and the hardware was timely made available and worked flawlessly.
Although the tight timeframe did not allow for the implementation of all the features
that were initially envisaged, and some compromises were at times required, the project
remained on track throughout all its phases and ended right on schedule.
5.4.5. LessonsLearned
From a personal point of view, I consider this project a success. However, a lesson
learned was to include in the project schedule training activities to become accustomed
with the programming language, as this would have allowed the Implementation phase
to progress more efficiently. Furthermore, the starting date for the project and its initial
phases, such as initial investigation, could have pushed back a few months and been
carried out during summertime. This would have allowed more time for other phases to
be expanded as required, for example leaving enough time for a refresher training in
Visual Studio C# to be included.
Project Domus: Designing Effective Smart Home Systems

97


References
Charniak, E., Bayesian Networks without Tears, AI Magazine, vol. 12, no. 4, pp. 50-
63, 1991.
Chunduru, V., Subramanian, N., Effects of Power Lines on Performance of Home
Control Systems, International Conference on Power Electronics, Drives and Energy
Systems, 2006. PEDES '06, pp. 1-6, 12-15 Dec. 2006.
Courage, C., Baxter, K. (2005) Understanding Your Users. A Practical Guide to User
Requirements Methods, Tools and Techniques, Morgan Kaufmann, San Francisco, US.
Cucchiara, R., Prati, A., and Vezzani, R. (2003), Domotics for disability: smart
surveillance and smart video server, Proceedings of 8th Conference of the Italian
Association of Artificial Intelligence Workshop on "Ambient Intelligence", pages 46
57, 2003.
Davidoff S., Kyung Lee M., Zimmerman J., Anind D., Socially-Aware Requirements
for a Smart Home, Human-Computer Interaction Institute + School of Design,
Carnegie Mellon University, Pittsburgh, PA (US).
Dimitrov, T., Pauli J., Naroska, E., A Probabilistic Reasoning Framework for Smart
Homes, Proceedings of the 5th international workshop on Middleware for pervasive
and ad-hoc computing, pp. 1-6, November 2007.
Dix, A., Finlay, J., D. Abowd, G., Beale, R., (2004), Human Computer Interaction,
Third Edition, Personal Education Limited, Harlow, England.
Dunlop M., Brewster S., The Challenge of Mobile Devices for Human Computer
Interaction, Personal and Ubiquitous Computing, vol. 6, pp. 235-236, 2002.
Farrell-Vinay, P., Manage Software Testing. Auerbach Publications. 2008.
Books24x7. <http://common.books24x7.com/book/id_26451/book.asp> (accessed
March 24, 2009).
Fischer G., User Modeling in Human-Computer Interaction, User Modeling and User
adapted Interaction, vol. 11, pp. 65-86, January, 2000.
Gann D., Barlow J., Venerables T. (1999) Digital Futures: Making Homes Smarter,
Joseph Rowntree Foundation, York, UK.
Grayson, E., Solving Home Automation Problems Using Artificial Intelligence
Techniques, IEEE Transactions on Consumer Electronics, vol. 37, issue 3, pp. 395-
400, August, 1991.
Green, W., Gyi Diane, Kalawasky R., Atkins D., Capturing user requirements for an
integrated home environment, Proceedings of the third Nordic conference on Human-
computer interaction, pp. 255-258, October, 2004.
Harper, R. (2003), Inside the Smart Home, Springer-Verlag, London, UK.
Heckman, D. (2008), A Small World. Smart Houses and the Dream of the Perfect day,
Duke University Press, London, UK.
Project Domus: Designing Effective Smart Home Systems

98


Helal S., Mann W., El-Zabadani H., King J., Kaddoura Y., Jansen E., "The Gator Tech
Smart House: A Programmable Pervasive Space," Computer, vol. 38, no. 3, pp. 50-60,
March, 2005.
Horvitz, E., et al., The Lumire project, Bayesian user modeling for inferring the goals
and needs of software users, Proceedings of the 14
th
Conference on Uncertainty in AI,
pp. 256-265, Morgan Kaufmann, San Francisco, 1998.
Kango R., Moore P.R., Pu, J., Networked smart home appliances - enabling real
ubiquitous culture, Proceedings. 2002 IEEE 5th International Workshop on Networked
Appliances, 2002, pp. 76-80, October 2002.
Kook Hyun Chung, Kyoung Soon Oh, Cheong Hyun Lee, Jae Hyun Park, Sunae Kim,
Soon Hee Kim, Loring, Beth, Hass, C., A User-Centric Approach to Designing Home
Network Devices, CHI '03 extended abstracts on Human factors in computing
systems, pp. 648-649, 2003.
Koskela T., Vnnen-Vainio-Mattila K., Evolutions towards smart home
environments: empirical evaluation of three user interfaces, Personal and Ubiquitous
Computing, vol. 8, no. 3-4, pp. 234-240, June, 2004.
Kyung Lee M., Davidoff S., Zimmerman J. (Year?), Dey A., Smart Home, Families
and Control, Carnegie Mellon University, Pittsburgh, PA (US)
Li Jiang; Da-You Liu; Bo Yang (2004), "Smart home research, Machine Learning and
Cybernetics, Proceedings of 2004 International Conference, vol.2, pp. 659-663, 26-29
Aug. 2004.
Lorente, S. (2004) "Key issues regarding Domotic applications", Proceedings of 2004
International Conference on Information and Communication Technologies: From
Theory to Applications, pp. 121-122, 19-23 April 2004.
Morgan Kaufmann, San Francisco.Chunduru, V. Subramanian, N., Effects of Power
Lines on Performance of Home Control System , International Conference on Power
Electronics, Drives and Energy Systems, PEDES '06, pp. 1-6. December, 2006.
Myers B., Hollan J., Cruz Isabel, et al., Strategic Directions in Human-Computer
Interaction, ACM Computing Surveys, vol. 28, no. 4, pp. 794-809 December 1996.
Myers, G. J.. The Art of Software Testing. John Wiley & Sons. 1979. Books24x7.
<http://common.books24x7.com/book/id_6690/book.asp> (accessed March 24, 2009).
Page, A., Johnson, K., Rollison, B. How We Test Software at Microsoft. Microsoft
Press. 2009. Books24x7. <http://common.books24x7.com/book/id_27542/book.asp>
(accessed March 24, 2009).
Pragnell, M., Spence L., Moore R. (2000) The market potential for Smart Homes,
Joseph Rowntree Foundation, York, UK.
Ricquebourg, V.; Menga, D.; Durand, D.; Marhic, B.; Delahoche, L.; Loge, C. (2006),
The Smart Home Concept : our immediate future", E-Learning in Industrial
Electronics, 2006 1ST IEEE International Conference, pp. 23-28, 18-20 Dec. 2006.
Ringbauer, B., Heidmann, F., Beisterfeldt, J., When a house controls its master
Universal design for smart living environments, Proceedings of the Universal Access
Project Domus: Designing Effective Smart Home Systems

99


in HCI: Inclusive Design, Crete, Greece, 2003.
Taylor, F.W.(1911) The Principles of Scientific Management. Reprint. New York:
Dover, 1998.
Wacks, K. (2002), "Home systems standards: achievements and challenges," IEEE
Communications Magazine, vol.40, no.4, pp.152-159, Apr 2002.
Wang (ed), J., "Bayesian Networks". Encyclopedia of Data Warehousing and Mining,
Volume I, A-H. IGI Publishing. 2006. Books24x7.
<http://common.books24x7.com/book/id_14698/book.asp> (accessed February 16,
2009).
Wiegers, K. E., Software Requirements, Second Edition. Microsoft Press. 2003.
Books24x7. <http://common.books24x7.com/book/id_6818/book.asp> (accessed
February 18, 2009).
Project Domus: Designing Effective Smart Home Systems

100


Appendices
Appendix A Details from Survey
This appendix outline the main findings of the survey reported by M. Pragnell (200) in
The market potential for Smart Homes. Some of the findings were used to determine
the user profile for the Smart Home system detailed in this paper.

Attitudes to new technology in the home:


Agreement by age group with the statement I welcome new technology in my home because it
saves me time and effort:
Project Domus: Designing Effective Smart Home Systems

101




Views about the Smart Home:

Concerns about Smart Home technology:
Project Domus: Designing Effective Smart Home Systems

102



Level of interest in the Smart Home concept:


Agreement with statement I am really interested in having the sort of functions a Smart Home
could
offer among those who agree with attitude statements:
Project Domus: Designing Effective Smart Home Systems

103



Appendix B Code Implementation
HVAC Logic Flow:
///
/// Checking HVAC
///
// set to manual mode?
if (checkBoxOverRide.Checked)
return; // then exits
// determines the comfort zone
if (bLSOn) // it's daytime
{ //defines comfort zone (+/- 5%)
comfortZoneMin = cZoneTemp
System.Convert.ToInt32(cZoneTemp * 5 / 100);
comfortZoneMax = cZoneTemp +
System.Convert.ToInt32(cZoneTemp * 5 / 100)
else
{ // it's night-time so use some energy-saving approach
comfortZoneMin = cZoneTemp
System.Convert.ToInt32(cZoneTemp * 15 / 100);
comfortZoneMax = cZoneTemp +
System.Convert.ToInt32(cZoneTemp * 15 / 100);
}
// check whether we are outside the comfort zone
if ((args.Temperature.ScaledValue > comfortZoneMax) ||
(args.Temperature.ScaledValue < comfortZoneMin))
bOutsideCZone = true;
// if we need to adjust
if (bOutsideCZone)
{ // if it is night time and there isn't anyone in the room, no need
if ((!bLSOn) && (!bMSOn))
bHVACOn = false;
else
bHVACOn = true;
Project Domus: Designing Effective Smart Home Systems

104


}
else
bHVACOn = false;
// displays current comfort zone (for debugging purposes)
oResultPane.AddText("Comfort Zone (min) is " +
System.Convert.ToString(comfortZoneMin));
oResultPane.AddText("Comfort Zone (max) is " +
System.Convert.ToString(comfortZoneMax));
// take the action depending on the result of the boolean
if (bHVACOn)
{ // turn it on
oMonitorCtrlEngine.UpdateLightInputNV(1, FlightControl.OnState);
oResultPane.AddText("HVAC is ON.");
}
else
{ // turn it OFF
oMonitorCtrlEngine.UpdateLightInputNV(1, FlightControl.OffState);
oResultPane.AddText("HVAC is OFF.");
}
}
Fire Alarm Logic Flow:

///
/// Checking Fire Alarm
///
// if the Fire Alarm is switched on
if (bFAOn)
{ // checks whether we need to report the probability of a fire
if (belief >= maxBelief)
{ // add text in the Event Logger
oResultPane.AddText("Fire Alarm.");
// check whether the alarm is not muted first
if (!checkBoxMute.Checked)
// enable siren (buzzer)
oMonitorCtrlEngine.UpdateBuzzerEnable(FlightControl.OnState);
else
// mute alarm
oMonitorCtrlEngine.UpdateBuzzerEnable(FlightControl.OffState);
return;
}
}
Implementation of Netica API:

// implements Netica BN in the declaration section of the code
using Netica;


///
/// NETICA INFERENCE ENGINE VARIABLES
///
private double belief; // belief returned by the BN
static private Streamer RuleDBFile; // Netica file
static private BNet net; // the actual object used

///BN Nodes (only the ones managed by the POC)
Project Domus: Designing Effective Smart Home Systems

105


static private BNode fireNode;
static private BNode highTempNode;
static private BNode motionSensorNode;
static private BNode lightSensorNode;
static private BNode HVACNode;


///
/// Rule DB Initialization
///
string net_file_name = AppDomain.CurrentDomain.BaseDirectory +
"RulesDB.dne"; // filename
// creates new object
Netica.Application oRuleDB = new Netica.Application();RuleDBFile =
oRuleDB.NewStream(net_file_name, null);

net = oRuleDB.ReadBNet(RuleDBFile, "");
net.Compile();

// assigning nodes
fireNode = net.Node("fire_danger");
highTempNode = net.Node("hi_temp");
motionSensorNode = net.Node("ms");
lightSensorNode = net.Node("ls");
HVACNode = net.Node("hvac");

///
/// Recalculating the BN belief based on the current status of nodes
///
// record status of High Temperature reached
highTempNode.RetractFindings(); // required to clear any previous
findings (evidence) entered
if (bHighTemp)
highTempNode.EnterFinding("true"); // evidence of high temperature
provided by the sensor

// record status of HVAC
HVACNode.RetractFindings(); //reset any previous value
if (bHVACOn)
HVACNode.EnterFinding("true"); // the HVAC is ON

// record status of Motion Sensor
motionSensorNode.RetractFindings();
if (bMSOn)
motionSensorNode.EnterFinding("true"); // the MS is ON
// record status of Light Sensor
lightSensorNode.RetractFindings();
if (bLSOn)
lightSensorNode.EnterFinding("true");

/// display current belief value
belief = System.Convert.ToSingle((fireNode.GetBelief("true")) * 100);
pBarLikelihood.Value = System.Convert.ToInt32(belief);


Project Domus: Designing Effective Smart Home Systems

106


Appendix C Test Scripts
Test ID: 1
Sub-System: Application Logic (alternate path)
Severity: 2
Priority: 1
Dependencies:
Description: Testing Exit button in splash screen.
Steps: 1. Double-click on Temperature Control System.exe to launch the
application
2. Click on Exit button.
Expected Result: The application quits without any error message.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 2
Sub-System: Application Logic (default path)
Severity: 1
Priority: 1
Dependencies:
Description: Testing Continue button in splash screen.
Steps: 1. Double-click on Temperature Control System.exe to launch the
application
2. Click on Continue button.
Expected Result: The main screen appears.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 3
Sub-System: Device Manager
Severity: 2
Priority: 2
Dependencies: 1
Description: Adding a new device via the Service Switch button.
Steps: 1. Click on the Monitor button. The Add Device dialog box
Project Domus: Designing Effective Smart Home Systems

107


appears.
2. From the FT 3150 board, click on the Service Switch button.
Expected Result: The Neuron ID will automatically populate the Text Box.
Pass/Fail?
Details: PASS
Workaround:

Test ID: 4
Sub-System: Device Manager
Severity: 2
Priority: 2
Dependencies: 3
Description: Adding a new device by entering the Neuron ID manually.
Steps: 1. Click on the Monitor button. The Add Device dialog box
appears.
2. In the Text Box, enter: 04D5CA75020 and click on the OK
button.
Expected Result: The Drop-down Box in the Main Screen will be populated with the details
of the device (Device - <Neuron ID> ), confirming the successful
binding.
Pass/Fail? FAIL
Details: Error message: Invalid Neuron ID. The Neuron ID must be specified in
12-digit hexadecimal number.
The number provided in the test seems to be one digit short?!?
Workaround: Use the Service Switch to populate the number automatically.

Test ID: 5
Sub-System: Device Manager (FR-01.1)
Severity: 2
Priority: 1
Dependencies:
Description: Setting HVAC in Manual Mode
Steps: 1. Tick the Manual Mode Check Box
2. Set the HVAC to ON
3. Move the Comfort Zone slide all the way to the left (min settings)
4. Wait 3 seconds. The HVAC should not change its status
5. Move the Comfort Zone slide all the way to the right (max
Project Domus: Designing Effective Smart Home Systems

108


settings)
6. Wait 3 seconds. The HVAC should not change its status
7. Set the HVAC to OFF
8. Repeat Steps 3 through 6
9. Un-tick the Manual Mode Check Box
Expected Result: HVAC system can be operated manually with any temperature range.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 6
Sub-System: Device Manager (FR-01.1)
Severity: 2
Priority: 1
Dependencies:
Description: FA can be turned OFF and ON
Steps: 1. Set the FA switch to ON
2. Wait 3 seconds
3. Set the FA switch to OFF
4. Wait 3 seconds
Expected Result: The FA can be turned ON or OFF by the user.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 7
Sub-System: User Interface (FR-02.1)
Severity: 2
Priority: 1
Dependencies:
Description: The system will provide feedback for a user request for an instant
command within 3 seconds from the command being issued.
Steps: 1. In the I/O Board ensure that the LS is turned ON (Switch # 4)
2. Ensure that the HVAC is set to automatic (i.e. the Manual Mode
Check Box is un-ticked)
3. Move the Comfort Zone slider all the way to the right or left
4. Wait 3 seconds
Project Domus: Designing Effective Smart Home Systems

109


5. Confirms that the HVAC has been turned on (Switch # 2 in I/O
Board) and that the UI has been updated accordingly (i.e. HVAC
switch is ON)
6. Move the Comfort Zone slider to match the current temperature
7. Wait 3 seconds Confirms that the HVAC has been turned off
(Switch # 2 in I/O Board) and that the UI has been updated
accordingly (i.e. HVAC switch is OFF)
Expected Result: The status of the HVAC switch is refreshed within 3 seconds from the
users command.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 8
Sub-System: Event Logger (FR 02.2), Event Logger (FR-07.4)
Severity: 2
Priority: 2
Dependencies:
Description: System to record instant command requests and their outcomes for later
user retrieval and examination.
Steps: 1. Take note of the current time and date
2. Change the status of the FA switch (e.g. if ON, turn it OFF)
3. Click on te Pause Logging Check Box to Pause the Event
Logger
4. Scroll the Log upward to locate the event that correspond to the
action (e.g. Fire Alarm turned ON)
5. Confirm that the date/time of the event correspond
6. Un-check the Pause Logging Check Box
Expected Result: The Event Logger recorded the event corresponding to the users action
with the correct timestamp.
Pass/Fail? PASS
Details: The setting seems to be repeated at each cycle in the log.
Workaround:

Test ID: 9
Sub-System: Event Collector (FR-02.4)
Severity: 2
Project Domus: Designing Effective Smart Home Systems

110


Priority: 1
Dependencies:
Description: System to continously evaluate information received by sensors.
Steps: 1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode
Check Box is un-ticked)
2. On the I/O board, ensure that the LS and MS are deactivated
(Switch # 3 and 4 OFF)
3. Move the Comfort Zone slider all the way to the left (min
settings). The HVAC should remain turned off
4. On the I/O board, activate the LS (Switch # 4 ON)
5. Wait 3 seconds
Expected Result: The HVAC Switch in the UI and Switch # 2 in the I/O board will turn ON,
confirming that the LS sensor is polled continuously.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 10
Sub-System: Event Logger (FR-03.12)
Severity: 2
Priority: 2
Dependencies:
Description: System storing command issued and confirmed system changes in an
Event Log.
Steps: 1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode
Check Box is un-ticked)
2. On the I/O board, ensure that the LS is active (Switch # 4 ON)
3. Move the Comfort Zone Slider anywhere in the scale
4. Click on te Pause Logging Check Box to Pause the Event
Logger
5. Scroll the Log upward to locate the latest entry for the events
Comfort Zone (min) and Comfort Zone (max)
6. Check that the two values (min and max) are within 5% of the
value displayed at the right of the Comfort Zone slider (e.g. 23)
7. Un-tick the Pause Logging Check Box
8. Repeat Steps 3 through 7 for a other two Comfort Zone values
Expected Result: Changed in the Comfort Zone (min) and (max) are recorded in the Event
Project Domus: Designing Effective Smart Home Systems

111


Log.
Pass/Fail? PASS
Details: The calculated values seems to be rounded up/down (e.g. 5% of 15 is
0.75; 5% of 28 is 1.4 but the min/max values are always +1/-2 degrees.
Workaround:

Test ID: 11
Sub-System: User Interface (FR-04.1)
Severity: 2
Priority: 3
Dependencies:
Description: System supporting keyboard accelerators (i.e. ALT+Key) as secondary
ways to access all main features
Steps: 1. Press the ALT key once
2. Confirm that the keyboard accelerators are enabled by noticing
that the Exit button has the x underlined (i.e. Exit)
3. Locate an underlined command (e.g. Mute Alarm) in the UI and
make sure that it can be operated by using the ALT key plus the
underlined letter (e.g. ALT + A)
4. Confirm that the command has bee executed (UI and Event Log)
5. Repeat Steps 3 through 4 until all keyboard accelerators have
been tested.
Expected Result: Keyboard accelerators will allow commands to be issued without the use
of the mouse.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 12
Sub-System: User Interface (FR-04.6)
Severity: 2
Priority: 1
Dependencies:
Description: All main features can be operated with less than three actions (e.g
mouse clicks)
Steps: 1. Note how many clicks or keyboard commands are required to
perform the following operations:
Project Domus: Designing Effective Smart Home Systems

112


Turn the FA ON
Turn the FA OFF
Turn the HVAC ON
Turn the HVA OFF
Set the HVAC to Manual Mode
Set the HVAC to Automatic Mode
Bind a LonWorks Device (see: Monitor button)
Mute FA Alarm
Change FA Hight Temperature
Change HVAC Comfort Zone
Change the FA Sensitivity
Pause/Resume Event Logging
Exit the Application
Expected Result: None of the operation listed will require more than three actions to be
completed.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 13
Sub-System: Device Manager (FR-09.2), Device Manager (FR-10.1), Device Manager
(FR-10.2)
Severity: 2
Priority: 3
Dependencies:
Description: System will identify the devices connected using a unique identifier
withing the same Network ID.
Steps: 1. Ensure that the FT3120 board is connected to the LonTalk
network and turned ON
2. Click on the Monitor Button
3. On the FT3120 board, press the Service Switch
4. Confirm the Neuron ID provided in the Text Box by clicking the
OK Button
5. Confirm that the Drop-Down box now contains two both devices
(Device 1 and Device 2) and that they are uniquely identified
by their Neuron ID
6. Confirm that the two devices are part of the same Network ID
Project Domus: Designing Effective Smart Home Systems

113


(9F:FF:FF:20:00:05:04:01)
Expected Result: Each LonWorks device will be uniquely identified in the same Network
ID.
Pass/Fail? PASS
Details: Neuron ID of Device 2: 04284CAF0200
Workaround:

Test ID: 14
Sub-System: Fire Alarm Logic (default path)
Severity: 1
Priority: 1
Dependencies:
Description: FA should not be triggered if the Sensitivity threshold is not reached
Steps: 1. Ensure that the FA is not active (UI and Switch # 1 in I/O Board
is set to OFF)
2. Ensure that the Mute Alarm is un-ticked
3. Tick on Pause Logging Check Box
4. Make note of the last entry in the log that reports the Fire
Probability (e.g. 2%)
5. Move the Sensitivity Slider to any value above the Fire
Probability (e.g 5%)
6. Activate the FA by using the UI Switch
7. Confirm that the FA is active (Switch # 1 in I/O Board is ON)
8. Wait 3 seconds
9. Un-tick on Pause Logging Check Box
10. Confrrm that the Fire Probability is still below the Sensitivity
value
Expected Result: FA will not be triggered if the Sensitivity Value is higher than the Fire
Probability.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 15
Sub-System: Fire Alarm Logic (alternate path)
Severity: 1
Priority: 1
Project Domus: Designing Effective Smart Home Systems

114


Dependencies:
Description: FA should be triggered when the Sensitivity threshold is reached
Steps: 1. Ensure that the FA is not active (UI and Switch # 1 in I/O Board
is set to OFF)
2. Ensure that the Mute Alarm is un-ticked
3. Ensure that the Pause Logging is un-ticked
4. Move the Sensitivity Slider all the way to the left (minimum value,
5%)
5. Set the Hight Temp Text Box to a value that is just above the
current temperature reported
6. Activate the FA by using the UI Switch
7. Confirm that the FA is active (Switch # 1 in I/O Board is ON
8. Find a way to increase the temperature reported by the sensor
on the I/O Board
9. Wait until the current temperature matches or goes beyond the
one set in the High Temp Box
10. Confirm in the Event Logger that the Fire Probability has
reached or gone beyond the Sensitivity value
11. When the Alarm is triggered (buzzer sounds), turn the FA Switch
OFF
Expected Result: FA wil be triggered if the Fire Probability reported matches or is beyond
the Sensitivity Value.
Pass/Fail? PASS
Details: 1) Cannot set High Temp value below 29 degrees.
2) Buzzer does not turn OFF once the alarm is triggered but you
will need to mute the alarm to make it stop (feature or bug?)
Workaround:

Test ID: 16
Sub-System: Fire Alarm Logic (default path)
Severity: 2
Priority: 1
Dependencies:
Description: Checking whether it is possible to mute an alarm
Steps: 1. Ensure that the FA is not active (UI and Switch # 1 in I/O Board
is set to OFF)
2. Ensure that the Mute Alarm is un-ticked
Project Domus: Designing Effective Smart Home Systems

115


3. Ensure that the Pause Logging is un-ticked
4. Move the Sensitivity Slider all the way to the left (minimum value,
5%)
5. Set the Hight Temp Text Box to a value that is just above the
current temperature reported
6. Activate the FA by using the UI Switch
7. Confirm that the FA is active (Switch # 1 in I/O Board is ON
8. Find a way to increase the temperature reported by the sensor
on the I/O Board
9. Wait until the current temperature matches or goes beyond the
one set in the High Temp Box
10. Confirm in the Event Logger that the Fire Probability has
reached or gone beyond the Sensitivity value
11. When the Alarm is triggered (buzzer sounds), tick the Mute
Alarm Check Box
12. Confirm that the FA is active (Switch # 1 in I/O Board is still ON
Expected Result: Buzzer stops.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 17
Sub-System: Fire Alarm Logic (alternate path)
Severity: 1
Priority: 1
Dependencies:
Description: Triggered FA alarm will always cause the alarm to sound initially
Steps: 1. Ensure that the FA is not active (UI and Switch # 1 in I/O Board
is set to OFF)
2. Ensure that the Mute Alarm is ticked
3. Ensure that the Pause Logging is un-ticked
4. Move the Sensitivity Slider all the way to the left (minimum value,
5%)
5. Set the Hight Temp Text Box to a value that is just above the
current temperature reported
6. Activate the FA by using the UI Switch
7. Confirm that the FA is active (Switch # 1 in I/O Board is ON
8. Find a way to increase the temperature reported by the sensor
Project Domus: Designing Effective Smart Home Systems

116


on the I/O Board
9. Wait until the current temperature matches or goes beyond the
one set in the High Temp Box
10. Confirm in the Event Logger that the Fire Probability has
reached or gone beyond the Sensitivity value
11. When the buzzer sounds, turn the FA OFF
Expected Result: Mute Alarm check box is automatically un-ticked and the buzzer sounds.
Pass/Fail? FAIL
Details: Mute Alarm doesnt get un-ticked.
Workaround:

Test ID: 18
Sub-System: HVAC Logic (alternate path)
Severity: 2
Priority: 2
Dependencies:
Description: Energy saving scheme will be enabled at night-time
Steps: 1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode
Check Box is un-ticked)
2. On the I/O board, ensure that the LS is not active (Switch # 4
OFF)
3. Move the Comfort Zone Slider anywhere in the scale
4. Click on te Pause Logging Check Box to Pause the Event
Logger
5. Scroll the Log upward to locate the latest entry for the events
Comfort Zone (min) and Comfort Zone (max)
6. Check that the two values (min and max) are within 15% of the
value displayed at the right of the Comfort Zone slider (e.g. 23)
7. Un-tick the Pause Logging Check Box
8. Repeat Steps 3 through 7 for other two different Comfort Zone
values
Expected Result: Changed in the Comfort Zone (min) and (max) are recorded in the Event
Log.
Pass/Fail? PASS
Details: Calculated values seem rounded up/down to the nearest unity (e.g. 1.24
= 1; 2.4 = 2).
Workaround:

Project Domus: Designing Effective Smart Home Systems

117


Test ID: 19
Sub-System: HVAC Logic (alternate path)
Severity: 2
Priority: 2
Dependencies:
Description: MS may cause the HVAC to be turned on at night if the temperature is
outside the comfort zone
Steps: 1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode
Check Box is un-ticked)
2. On the I/O board, ensure that the LS and MS are not active
(Switch # 3 and 4 OFF)
3. Move the Comfort Zone Slider to a value that is at least +/- 20%
away from the current temperature
4. Wait 3 seconds
5. Confirm that the HVAC remains OFF
6. On the I/O Board, set MS to active (turn Switch # 3 ON)
7. Wait 3 seconds
Expected Result: The HVAC will turn ON at night-time if the MS switch is ON and the delta
temp is more than 20%
Pass/Fail? PASS
Details:
Workaround:

Test ID: 20
Sub-System: HVAC Logic (alternate path)
Severity: 2
Priority: 2
Dependencies:
Description: MS may not cause the HVAC to be turned on at night if the temperature
is still within the comfort zone
Steps: 1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode
Check Box is un-ticked)
2. On the I/O board, ensure that the LS and MS are not active
(Switch # 3 and 4 OFF)
3. Move the Comfort Zone Slider to a value that is within +/- 15%
the current temperature
4. Wait 3 seconds
Project Domus: Designing Effective Smart Home Systems

118


5. Confirm that the HVAC remains OFF
6. On the I/O Board, set MS to active (turn Switch # 3 ON)
7. Wait 3 seconds
Expected Result: The HVAC will remain OFF at night-time if the MS switch is ON and the
delta temp is still within 15%
Pass/Fail? PASS
Details:
Workaround:

Test ID: 21
Sub-System: HVAC Logic (default path)
Severity: 2
Priority: 2
Dependencies:
Description: HVAC set in automatic mode will be turned OFF if not required
Steps: 1. Ensure that the HVAC is set to manual (i.e. the Manual Mode
Check Box is ticked)
2. Turn the HVAC ON
3. On the I/O board, ensure that the LS is active (Switch # 4 ON)
4. Move the Comfort Zone Slider to a value that matches the
current temperature
5. Un-tick the Manual Mode Check Box
6. Wait 3 seconds
Expected Result: The HVAC will be turned OFF when not required when in Automatic
Mode.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 22
Sub-System: HVAC Logic (alternate path)
Severity: 2
Priority: 1
Dependencies:
Description: HVAC in manual mode will not be turned ON in any circumstance
Steps: 1. Ensure that the HVAC is set to manual (i.e. the Manual Mode
Check Box is ticked)
Project Domus: Designing Effective Smart Home Systems

119


2. Move the Comfort Zone Slider all the way to the left (min value)
3. Wait 3 seconds
4. Move the Comfort Zone Slider all the way to the right (max
value)
5. Wait 3 seconds
Expected Result: The HVAC will not be operated automatically when in Manual Mode.
Pass/Fail? PASS
Details:
Workaround:

Test ID: 23
Sub-System: Application Logic (default path)
Severity: 2
Priority: 1
Dependencies:
Description: Application can be successfully terminated.
Steps: 1. Click on the Exit Button

Expected Result: The application quits without error messages.
Pass/Fail? PASS
Details:
Workaround:

Appendix D Bayesian Network Probability Tables
Node: Summer (su)
Probabilities: True False

.40 .60

Node: Cooking Time (ct)
Probabilities: True False

.20 .80
Project Domus: Designing Effective Smart Home Systems

120



Node: Daytime (dt)
Probabilities: True False
P(dt | su)
.70 .30
P(dt | su)
.30 .70

Node: Lived In (li)

Probabilities: True False
P(li | dt)
.60 .40
P(li | dt)
.80 .20

Node: HVAC On (hvo)
Probabilities: True False
P(hvo | li su dt)
.70 .30
P(hvo | li su dt)
.40 .60
P(hvo | li su dt)
80. .20
P(hvo | li su dt)
.45 .55
P(hvo | li su dt)
.30 .70
P(hvo | li su dt)
.20 .80
P(hvo | li su dt)
.20 .80
P(hvo | li su dt)
.15 .85

Node: High Temperature (ht)
Probabilities: True False
P(ht | su hvo dt ct)
.15 .85
P(ht | su hvo dt ct)
.10 .90
P(ht | su hvo dt ct)
.80 .20
P(ht | su hvo dt ct)
.50 .50
Project Domus: Designing Effective Smart Home Systems

121


P(ht | su hvo dt ct)
.25 .75
P(ht | su hvo dt ct)
.20 .80
P(ht | su hvo dt ct)
.15 .85
P(ht | su hvo dt ct)
.08 .92
P(ht | su hvo dt ct)
.10 .90
P(ht | su hvo dt ct)
.05 .95
P(ht | su hvo dt ct)
.05 .95
P(ht | su hvo dt ct)
.01 .99
P(ht | su hvo dt ct)
.08 .92
P(ht | su hvo dt ct)
.05 .95
P(ht | su hvo dt ct)
.08 .92
P(ht | su hvo dt ct)
.04 .96

Node: Fire Danger (fd)
Probabilities: True False
P(fd | ht ct li)
.20 .80
P(fd |ht ct li)
.25 .75
P(fd |ht ct li)
.30 .70
P(fd |ht ct li)
.35 .65
P(fd | ht ct li)
.003 .997
P(fd | ht ct li)
.005 .995
P(fd |ht ct li)
.001 .999
P(fd |ht ct li)
.001 .999

Project Domus: Designing Effective Smart Home Systems

122


Appendix E Project Plan


Appendix F Risks and Contingency Plans
Risk Name Risk Details Contingency Plan
Cannot get the
hardware required
Most of the technology is still
developed for the US market
and might not be readily
available in Europe.
Contacting the manufacturers directly
to find out timing and availability of
the products needed before
considering using this in the project.
Do not know what
technology to use
All the technology research so
far has pros and cons. As of
today, it is not yet clear what
would be the best choice.
Narrow down the choice to two/three
candidates and pursue only these as
candidates for the project. Final
decision to be made by mid January
09.
System programming
challenge
Although I have been doing
system design and
programming in the past, I
have since move out that field
over ten years ago and it
might take some time to brush
up this skill again. I will need
to take this into account in the
project schedule.
Subscribe to on-line newsgroups that
will help with possible challenges.
Use a software design tool such as
Rational Rose to help with the
development.
When choosing the development
tool, see whether I can leverage the
past knowledge to cut developing
times.
Investigate availability of on-line
courses on system development that
are relevant to the system chosen for
the prototype.
Tight timeframe The project is to be presented
in early April 2009, which will
realistically leave around 12
weeks for researching,
designing, coding and testing
the system.
Tight control of time and tasks via
Microsoft Project.
Implement relevant milestones to
detect deviations from the plan as
early as possible.
Consider the late delivery date (Sep
09) option to be reviewed in late
Feb 09.

Project Domus: Designing Effective Smart Home Systems

123




i
http://www.the-original-epcot.com/2008/05/epcot-film-video.html (accessed on 18 February 2009)
ii
http://newsroom.cisco.com/dlls/fspnisapi3934.html
iii
http://architecture.mit.edu/house_n/
iv
http:// research.microsoft.com/en-us/um/people/marycz/el.doc
v
http://www.cs.colorado.edu/~mozer/nnh/
vi
http://www.smarthome.duke.edu/home/
vii
http://awarehome.imtc.gatech.edu/
viii
http://www.cenelec.eu/Cenelec/CENELEC+in+action/Horizontal+areas/ICT/SMARTHOUSE+-
+PHASE+II.htm
ix
http://www.insteon.net
x
http://www.plcbus.com.cn/
xi
http://www.pulseworx.com/
xii
http://www.knx.org/
xiii
http://www.echelon.com
xiv
http://www.clipsal.com/
xv
http://www.upnp.org/
xvi
http://www.zigbee.org/
xvii
http://www.zen-sys.com/
xviii
http://www.bacnet.org/
xix
http://www.modbus.org/
xx
http://research.microsoft.com/en-us/um/people/horvitz/Lumiere_big.wmv (accessed on 18 Feb 2009).