Professional Documents
Culture Documents
Project Domus Designing Effective Smart
Project Domus Designing Effective Smart
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.
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 application’s user interface. A sincere thanks also goes to my
wife Giorgia for all her patience, dedication and encouragement over the past months.
2
Project Domus: Designing Effective Smart Home Systems
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.
3
Project Domus: Designing Effective Smart Home Systems
Table of Contents
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
4
Project Domus: Designing Effective Smart Home Systems
5
Project Domus: Designing Effective Smart Home Systems
7
Project Domus: Designing Effective Smart Home Systems
1. Introduction
This chapter presents the project’s aim, objectives, and its intellectual challenge.
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
8
Project Domus: Designing Effective Smart Home Systems
2. Literature Review
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 Disney’s Experimental Prototype Community of Tomorrow
(EPCOT), presented in 1966i. 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.
In late 1800’s, 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).
10
Project Domus: Designing Effective Smart Home Systems
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”.
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).
11
Project Domus: Designing Effective Smart Home Systems
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.
12
Project Domus: Designing Effective Smart Home Systems
13
Project Domus: Designing Effective Smart Home Systems
house were every room adjusts automatically to match your changing moods”
(Heckman, 2008).
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 Homeii – 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
14
Project Domus: Designing Effective Smart Home Systems
demonstrates how Internet can enhance daily living for consumers for the homes and
communities of the future.
MIT House_niii – 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 EasyLivingiv – 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 today’s 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 Housev - 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 programvi - Duke University’s 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 SmartHouseviii - 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.
15
Project Domus: Designing Effective Smart Home Systems
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.
16
Project Domus: Designing Effective Smart Home Systems
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:
17
Project Domus: Designing Effective Smart Home Systems
smart picture frames, which display user’s images in rotation updated in real-time;
smart mirrors2 that can display the news and remind the user of today’s 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 user’s favourite music when they
detect that their user is drifting into sleep.
2
See: http://gizmodo.com/gadgets/gadgets/touchscreen-smart-mirror-widgets-in-the-mirror-246384.php
18
Project Domus: Designing Effective Smart Home Systems
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.
19
Project Domus: Designing Effective Smart Home Systems
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.
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.
20
Project Domus: Designing Effective Smart Home Systems
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 Systemsxi 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.
21
Project Domus: Designing Effective Smart Home Systems
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
Groupxvi. 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 Zensysxvii, 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.
BACNetxviii 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-IDAxix, a non-profit organization made up of users and suppliers
of automation devices primarily in manufacturing.
22
Project Domus: Designing Effective Smart Home Systems
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
23
Project Domus: Designing Effective Smart Home Systems
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).
24
Project Domus: Designing Effective Smart Home Systems
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
25
Project Domus: Designing Effective Smart Home Systems
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. Today’s 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.
26
Project Domus: Designing Effective Smart Home Systems
Often, people’s 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
27
Project Domus: Designing Effective Smart Home Systems
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.
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.
28
Project Domus: Designing Effective Smart Home Systems
• 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).
29
Project Domus: Designing Effective Smart Home Systems
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.
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
30
Project Domus: Designing Effective Smart Home Systems
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 Description of observable behaviors that the system will exhibit
Requirements 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 How the system needs to connect to other systems or, generally,
Requirements 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:
31
Project Domus: Designing Effective Smart Home Systems
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).
32
Project Domus: Designing Effective Smart Home Systems
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 today’s 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.
33
Project Domus: Designing Effective Smart Home Systems
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 user’s 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 today’s 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 user’s 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.
34
Project Domus: Designing Effective Smart Home Systems
Today’s 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:
35
Project Domus: Designing Effective Smart Home Systems
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 user’s 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.
36
Project Domus: Designing Effective Smart Home Systems
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 argument’s 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.
37
Project Domus: Designing Effective Smart Home Systems
38
Project Domus: Designing Effective Smart Home Systems
A practical example of how BN can be used to infer the user’s goal is Project Lumiére.
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
user’s 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 videoxx, 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).
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 user’s 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 user’s view, what is called perceptual visibility. Rather than merely
focusing on size alone, a more recent definition of ubiquitous computing outlines the
computer’s ability to become integrated with the user’s 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 household’s 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 action’s significance from the user’s 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).
40
Project Domus: Designing Effective Smart Home Systems
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).
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.
43
Project Domus: Designing Effective Smart Home Systems
System Overview
Figure 11 displays provide an overview of the main functions present in the system
from a user’s 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.
• Description: a short description of the feature, useful to identify this later on.
44
Project Domus: Designing Effective Smart Home Systems
45
Project Domus: Designing Effective Smart Home Systems
47
Project Domus: Designing Effective Smart Home Systems
48
Project Domus: Designing Effective Smart Home Systems
49
Project Domus: Designing Effective Smart Home Systems
50
Project Domus: Designing Effective Smart Home Systems
51
Project Domus: Designing Effective Smart Home Systems
52
Project Domus: Designing Effective Smart Home Systems
53
Project Domus: Designing Effective Smart Home Systems
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
55
Project Domus: Designing Effective Smart Home Systems
56
Project Domus: Designing Effective Smart Home Systems
57
Project Domus: Designing Effective Smart Home Systems
58
Project Domus: Designing Effective Smart Home Systems
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 An action carried out by the system without direct user input.
Action
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 A command that is issued as part of a schedule set by the user.
Command
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
59
Project Domus: Designing Effective Smart Home Systems
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).
61
Project Domus: Designing Effective Smart Home Systems
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.
62
Project Domus: Designing Effective Smart Home Systems
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.
63
Project Domus: Designing Effective Smart Home Systems
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.
64
Project Domus: Designing Effective Smart Home Systems
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.
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
65
Project Domus: Designing Effective Smart Home Systems
who was made owner of the Team. Figure 18 represents the Use Case diagram for this
feature.
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.
66
Project Domus: Designing Effective Smart Home Systems
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.
67
Project Domus: Designing Effective Smart Home Systems
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.
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.
68
Project Domus: Designing Effective Smart Home Systems
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
69
Project Domus: Designing Effective Smart Home Systems
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 layer’s frame.
4
See: http://www.echelon.org
70
Project Domus: Designing Effective Smart Home Systems
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 device’s 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.
71
Project Domus: Designing Effective Smart Home Systems
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 device’s 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.
72
Project Domus: Designing Effective Smart Home Systems
The POC system uses a Mini EVK Evaluation Kit, acquired from Echelon Corp., which
includes the following:
73
Project Domus: Designing Effective Smart Home Systems
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:
74
Project Domus: Designing Effective Smart Home Systems
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.
4.3.2. Software
The POC system will outline a possible solution for a Temperature Control system,
which will include the following devices:
5
The “nvo” and “nvi” suffix define an output or input variable respectively.
75
Project Domus: Designing Effective Smart Home Systems
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.
The Temperature Control System (TCS) will continuously interpret the data provided
by the sensors installed and take actions depending on the input received. The
application’s 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).
76
Project Domus: Designing Effective Smart Home Systems
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 system’s main window.
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.
77
Project Domus: Designing Effective Smart Home Systems
The software is now bound the EVB and will show the status of the actuators and
sensors present in the system.
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.
78
Project Domus: Designing Effective Smart Home Systems
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.
79
Project Domus: Designing Effective Smart Home Systems
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.
6
See: http://www.norsys.com/
81
Project Domus: Designing Effective Smart Home Systems
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.
82
Project Domus: Designing Effective Smart Home Systems
83
Project Domus: Designing Effective Smart Home Systems
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.
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
84
Project Domus: Designing Effective Smart Home Systems
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.
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.
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:
Test Deliverables
The following deliverables are part of this plan:
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
86
Project Domus: Designing Effective Smart Home Systems
Identified Risks
Details, impacts, and contingency plans for the high-level risks that may occur during
the testing procedure are outlined in Table 9.
87
Project Domus: Designing Effective Smart Home Systems
88
Project Domus: Designing Effective Smart Home Systems
90
Project Domus: Designing Effective Smart Home Systems
91
Project Domus: Designing Effective Smart Home Systems
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.
93
Project Domus: Designing Effective Smart Home Systems
94
Project Domus: Designing Effective Smart Home Systems
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.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
95
Project Domus: Designing Effective Smart Home Systems
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.
96
Project Domus: Designing Effective Smart Home Systems
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.
97
Project Domus: Designing Effective Smart Home Systems
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 Lumiére project, Bayesian user modeling for inferring the goals
and needs of software users”, Proceedings of the 14th 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., Väänänen-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
98
Project Domus: Designing Effective Smart Home Systems
99
Project Domus: Designing Effective Smart Home Systems
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.
Agreement by age group with the statement ‘I welcome new technology in my home because it
saves me time and effort’:
100
Project Domus: Designing Effective Smart Home Systems
101
Project Domus: Designing Effective Smart Home Systems
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:
102
Project Domus: Designing Effective Smart Home Systems
103
Project Domus: Designing Effective Smart Home Systems
}
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
104
Project Domus: Designing Effective Smart Home Systems
///
/// 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);
// 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
105
Project Domus: Designing Effective Smart Home Systems
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
106
Project Domus: Designing Effective Smart Home Systems
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
107
Project Domus: Designing Effective Smart Home Systems
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
108
Project Domus: Designing Effective Smart Home Systems
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 user’s 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
109
Project Domus: Designing Effective Smart Home Systems
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
110
Project Domus: Designing Effective Smart Home Systems
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:
111
Project Domus: Designing Effective Smart Home Systems
• 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
112
Project Domus: Designing Effective Smart Home Systems
(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
113
Project Domus: Designing Effective Smart Home Systems
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
114
Project Domus: Designing Effective Smart Home Systems
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
115
Project Domus: Designing Effective Smart Home Systems
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:
116
Project Domus: Designing Effective Smart Home Systems
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
117
Project Domus: Designing Effective Smart Home Systems
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)
118
Project Domus: Designing Effective Smart Home Systems
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
.40 .60
.20 .80
119
Project Domus: Designing Effective Smart Home Systems
120
Project Domus: Designing Effective Smart Home Systems
121
Project Domus: Designing Effective Smart Home Systems
122
Project Domus: Designing Effective Smart Home Systems
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).
123