Académique Documents
Professionnel Documents
Culture Documents
Author:
18 April 2009
Acknowledgments
I would like to thank my supervisor Michael Gleeson for his guidance, time and support
throughout the project. My friend and colleague Massimiliano Balsamo for his
suggestions about the applications user interface. A sincere thanks also goes to my
wife Giorgia for all her patience, dedication and encouragement over the past months.
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 earlywarning Fire Alarm sub-system that uses a Bayesian Network to infer the likelihood of
a fire. The application is implemented using Visual Studio 2005, using a hardware and
software kit provided by Echelon Corp. The Bayesian Network implemented is Netica
from Norsys Corp.
Keywords: Smart Home, Home Automation, Bayesian Networks.
TableofContents
1.
Introduction ..............................................................................................................8
1.1.
1.1.1.
Aim ...................................................................................................................8
1.1.2.
Objectives .........................................................................................................8
1.2.
2.
Intellectual Challenge...........................................................................................8
Literature Review .....................................................................................................9
2.1.
Definition..............................................................................................................9
2.2.
History ..................................................................................................................9
2.2.1.
2.2.2.
2.2.3.
2.3.
3.
3.1.
3.1.1.
3.1.2.
Actuators ........................................................................................................17
3.1.3.
3.2.
3.2.1.
3.2.2.
Other Protocols...............................................................................................21
3.3.
3.3.1.
Potential Benefits............................................................................................24
3.3.2.
3.4.
3.4.1.
3.4.2.
3.4.3.
3.4.4.
3.4.5.
4.
Development ..........................................................................................................41
4
Analysis ..............................................................................................................41
4.1.1.
Business Requirements...................................................................................41
4.1.2.
4.1.3.
4.1.4.
4.1.5.
Functional Requirements................................................................................44
4.1.7.
Glossary..........................................................................................................59
4.2.
Design.................................................................................................................61
4.3.
Implementation...................................................................................................69
4.3.1.
Hardware ........................................................................................................70
4.3.2.
Software..........................................................................................................75
4.4.
Testing ................................................................................................................84
4.4.1.
4.4.2.
Test Cases.......................................................................................................87
4.4.3.
4.4.4.
4.4.5.
5.
Conclusion..............................................................................................................93
5.1.
5.2.
Project Findings..................................................................................................94
5.3.
5.4.
5.4.1.
Research .........................................................................................................95
5.4.2.
Analysis ..........................................................................................................95
5.4.3.
Technical ........................................................................................................95
5.4.4.
Project Management.......................................................................................96
5.4.5.
References ......................................................................................................................97
Appendices ...................................................................................................................100
FiguresandTables
Figure 1 Advertisement for a Washing Machine, Daily Mail (1955) ..................................... 11
Figure 2 Adoption of new technologies over time .................................................................. 12
Figure 3 Picture of a Xanadu House........................................................................................ 14
Figure 4 Sensor and Actuator Interaction................................................................................ 17
Figure 5 X10 Zero-Crossing Signal Transmission.................................................................. 20
Figure 6 Rogers Technology Adoption Lifecycle.................................................................. 23
Figure 7 Components of Software Requirements ................................................................... 30
Figure 8 Implicit and Explicit Communication Channels....................................................... 35
Figure 9 Causal Graph............................................................................................................. 38
Figure 10 Bayesian Network ................................................................................................... 39
Figure 11 System Overview .................................................................................................... 44
Figure 12 Sub-Systems Overview ........................................................................................... 54
Figure 13 Operating the System .............................................................................................. 62
Figure 14 User Authentication ................................................................................................ 63
Figure 15 User Administration................................................................................................ 64
Figure 16 Managing Devices................................................................................................... 64
Figure 17 Managing Teams..................................................................................................... 65
Figure 18 Managing Schedules ............................................................................................... 66
Figure 19 Managing Events..................................................................................................... 67
Figure 20 Dispatching Commands .......................................................................................... 67
Figure 21 Flight Control Sub-System ..................................................................................... 68
Figure 22 Inference Engine Sub-system ................................................................................. 69
Figure 23 How LonWorks Devices exchange Messages ........................................................ 70
Figure 24 Anatomy of a LonWorks Device ............................................................................ 71
Figure 25 Network Variables .................................................................................................. 72
Figure 26 A Typical LonWorks Solution................................................................................ 73
Figure 27 The Mini EVK Evaluation Kit ................................................................................ 74
Figure 28 Mini-Gizmo I/O Board............................................................................................ 76
Figure 29 Main Screen of the POC System............................................................................ 77
Figure 30 Add Device Dialog Box.......................................................................................... 78
6
1. Introduction
This chapter presents the projects aim, objectives, and its intellectual challenge.
1.1. ProjectAimandObjectives
1.1.1. Aim
The aim of this project is to develop a proof-of-concept prototype for a Smart Home
system that will address some of the challenges emerged during the research.
1.1.2. Objectives
The project has the following objectives:
1.2. IntellectualChallenge
Although the project will consider proper Human-Computer Interaction (HCI)
techniques to provide users with a user-friendly interface, it will also aim at improving
the effectiveness of Smart Home systems.
2. LiteratureReview
This chapter presents a definition of Smart Home, provides a brief history of the
technologies contained, and outlines recent developments in the field.
2.1. Definition
A common definition of Smart Home is of an electronic networking technology to
integrate devices and appliances so that the entire home can be monitored and
controlled centrally as a single machine (Pragnell et al., 2000). Another term that
describe the same technology is domotics, which derives from the Latin word domus,
meaning home, and informatics, meaning the study of the processes involved in the
collection, categorization, and distribution of data. However, since this technology is
still very much in flux, other terms are also used in the literature with equivalent
meaning, such as: home automation, smart house, digital home or electronic
home.
Furthermore, note that, although the terms house and home have a
different meaning in the English language, they are often used alike in this context.
2.2. History
Although the term smart home was first used in 1980s, the concept is far from new.
The early documented attempt to envisage something very similar dates back to the
1960s, with Walt Disneys Experimental Prototype Community of Tomorrow
(EPCOT), presented in 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.
2.2.1. TheMechanicalRevolution
The first question that might come to mind is why we would need a Smart Home and
why we would want to find different ways of doing ordinary things, such as washing
clothes, cooking, or even turning a light on or off. A similar question could have been
asked at the beginning of the 20th Century, at the dawn of what can be called the
mechanical revolution.
9
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
2.2.3. TheInformationRevolution
Disneys original vision for EPCOT was to create both a laboratory for new technology
and a home for its inhabitants with the promise of offering an integrated living
environment (Heckman, 2008). Due to his untimely death, just a few months after the
official presentation of the project, EPCOT was never implemented, at least not in its
original idea.
The concept behind the original vision was however to live on. In the 1960s, a number
of hardware and software innovations made possible for home owners to have access to
the first computer-like appliances in their homes. Perhaps the first attempt to create a
home automation system occurred in 1966 when Westinghouse proposed the
experimental and quite bulky Electronic Computing Home Operator (ECHO) IV.
Although the original system was supposed to automate the family finances, it was
soon extended to include recipes, shopping lists, family inventory, and, in its final
versions, added home temperature control and the ability to control appliances.
In 1975, it was the turn of the Altair 8800, followed by the Apple II in 1977 and the
IBM PC in 1981. While these computers were slowly finding their ways into the home,
they also contributed to the creation of the idea of smart machines.
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
2.3. SmartHomesToday
The Oxford Dictionary defines smart as both stylish and fresh in appearance, having
a quick intelligence, and being fashionable and upmarket. Sony was among the first
companies to attach the smart buzzword to a computer when, in 1982, it marketed the
Smart Sony computer: no longer advertised simply as a home computer, but tried
to cash in on the smart concept by selling it as a device which could help you make
smarter business decisions (Heckman, 2008).
The smart concept has become since a marketing catchword, still employed today, to
sell a wide range of products, hence: smart phones, smart cameras, smart design,
smart bombs and smart homes. Usually, the word define devices that are reportedly
based on cutting-edge design that unite innovation with practical simplicity, However,
as this would soon be demonstrated, sometimes marketing buzzwords alone cannot
guarantee the sell.
Xanadu was the first example of a mass-produced Smart Home. Built throughout the
1980s in the US around the original EPCOT idea, these houses were commercially built
dwellings that made extensive use of Smart Home technologies.
futuristic, the actual house was made entirely of polyurethane foam. The Xanadu home
had a computer that monitored and controlled all its systems: the kitchen, living room,
bathrooms, and bedrooms all had their own electrical and electronic devices to control
the appliances present in the house. For example, the shower could be set to be turned
on at a specific time and a set temperature. The ad campaign eloquently described the
house as Xanadu: the Computerized House of Tomorrow and its peculiar appeal was
set by the advertisement campaign: a house with a brain a house you can talk to, a
13
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.
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 highspeed, 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
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.
3.1. ComponentsofaSmartHomeSystem
To be considered a Smart Home, the technology used must employ all the following
elements: intelligent control, home automation and internal network (Jiang et al., 2004).
The intelligent control is provided by a control system, comprised of two types of
elements: sensors, which will monitor, control and report the status of the home
environment, and a control agent (human or software based) which acts on the
information provided by the sensors.
The home automation function is fulfilled by electrical or electronic devices, called
actuators, that will interact and modify the environment by accomplishing specialized
tasks. These tasks often work towards a more complex goal defined by the user of the
system.
The purpose of the home network is simply to ensure that all the components can
receive and send instructions to each other.
Figure 4 provide a simple example on how all three elements interact. A thermometer,
an example of a sensor, reports the current temperature. In response to this input, the
control agent, which can be a piece of software or an actual person, acts on the heater,
via the actuator, and instructs the device to switch on. This action accomplishes the
users initial goal: to increase the temperature to a comfortable level (Helai et al.,
2005). The result of a task might modify the environment monitored by the sensors,
whose input might cause the control agent to perform other tasks, such as turning the
heater off when the temperature has reached the desired level, and the cycle starts
again. Although not explicitly represented, all the actions depicted in the example
above can only be made possible by the existence of a home network that can carry the
information provided by the sensors and send commands to the actuators.
16
3.1.1. ControlSystems
The control system is a critical part of a Smart Home as it determines usability,
reliability and overall effectiveness of the solution provided. These systems are written
as a piece of software that is run on a home computer or embedded in an electronic
device. These software systems offer the ability to control a subset of the home
appliances from a centralized location. Most of them also provide users with the option
to store macro commands; that is, to combine a list of tasks together. These macros can
be then invoked by the user when required or be automatically executed by the system
at a pre-set scheduled date and time.
3.1.2. Actuators
Actuators are electrical or electronic devices that can control a household appliance.
When they come as a separate device, they need to be electrically coupled with the
appliance and can control it by executing some simple commands, such as switching it
on or off. When they are embedded within the appliance itself, they can be more
sophisticated and provide more value added to the user.
Smart Home-enabled appliances can be subdivided into two categories. The first
category is composed by familiar items, such as refrigerators or washing machines,
which would also provide an intelligent interface to control them. The second category
is comprised of entirely new devices. To a greater extent, most of these devices are still
at a prototype stage, with their viability and effectiveness being studied in some of the
home lab projects outlined in the previous section. Some interesting examples are:
17
See: http://gizmodo.com/gadgets/gadgets/touchscreen-smart-mirror-widgets-in-the-mirror-246384.php
18
3.2. CommunicationProtocols
This section provides an overview of some the most important communication
protocols for home networks available today.
proprietary, that is, details are not disclosed to the public. Others are owned and
maintained by a company or consortium but openly made available. Finally, some of
these are also recognized standards, that is, acknowledged by nationally or
internationally accredited bodies.
3.2.1. X10anditsLegacy
X10 was the first general-purpose home network solution. PICO Electronic, a UKbased engineering firm, patented it in 1978. After a first unsuccessful attempt to
market it in Europe, the company established itself in the US, where it was more
successful. The RadioShack, the US-based chain of electronics retail store, was the first
to offer consumer solutions based on this technology.
X10 is a Powerline system, so uses the existing electrical network in the house and can
allow users to remotely control, at least in principle, any appliance connected to the
house mains. A controlling device would just be plugged in between the mains and the
electrical appliance to be controlled. Properly instructed, this controlling device will
then turn the appliance on or off at specific times or as a response to specific events
coming from the home network.
The original implementation allows one-way communication and can address up to 256
devices subdivided into eight different homes (channels) to lessen the chances of
interferences with other systems nearby. Figure 5 provides a graphical representation
19
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.
This
22
3.3. TheMarketforSmartHomes
As outlined in Chapter 2, the 20th Century introduced a dramatic revolution in domestic
technology which culminated with the emergency of the Smart Home concept.
However, in many cases, the research carried out for Smart Home systems has been
focusing more on the technical possibilities without little or no consideration of the
social aspects or the actual needs of the potential user (Harper, 2003).
As a
consequence, Smart Home solutions are mostly appealing only to DIY enthusiast and
hobbyists and seem to be stuck in the Early Adopter phase of Rogers Technology
Adoption Lifecycle.
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
23
The
potential time-saving features that a Smart Home can provide will help to maintain a
sense of control and relieve some of the stress associated with running the household
(Kyung Lee et al., 2008).
3.3.1. PotentialBenefits
Although features offered by a Smart Home may vary, an effective implementation can
bring several potential benefits. Childrens needs and busy days prevent families from
having enough spare time and a Smart Home may make everyday life at home easier
for its inhabitants (Harper, 2003). The ability to monitor and control all the devices in
the house from a central location can introduce time-saving benefits. Furthermore, over
half (59%) of the participant of a recent survey reported that they would welcome a
new technology that would save time and effort in their homes (Pragnell et al., 2000).
Furthermore, such gain can be sensibly expanded with applications that offer
opportunities to group stand-alone operations into logical macro tasks. For example,
the turning on of a DVD player could automatically operate the TV and either dim the
lights in the room or lower the window blinds to obtain the optimal light level.
Going further, an effective Smart Home system may be able to make complex decisions
that are likely beyond the technical expertise of the inhabitants of the house: for
example, an expert system built into a Smart Home system could contain a detailed
knowledge of thermal systems, of human physiology, and of the HVAC system
installed in the house and being able determine the optimal choice of temperature and
24
currently what potential users expressed as the most interesting (Pragnell et al., 2000),
the result of this integration, combined with modern networking technology, will open
new possibilities and the creation of additional services that might not exist today.
Table 1 represents possible areas where Smart Home technology can already help today
(Green et al., 2004).
EXAMPLES
Welfare
Entertainment
Environment
Safety
Communication
Appliances
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
3.4. DesignChallenges
In addition to the needs and concerns expressed above, Smart Home systems provide
several design challenges.
30 years in the making, Smart Home technologies do not yet seem to have reached
most of potential users. D. Gann (1999) in his research, reported five reasons for this
slow growth and, though few years have gone by since these findings, todays situation
does not seem to have improved significantly in any of these areas:
Costs.
Whilst some of these design challenges are beyond the scope of this project, others can
be investigated and expanded further in this paper. For example, it is certainly possible
to gain a better understanding of the users needs and, by doing so, have a better chance
to develop solutions that are useful, usable, and used (Dix et al., 2004). Furthermore,
it may be possible to choose technologies that are more reliable, less disruptive, more
supported and upgradeable than others and that should provide a better chance to be a
sound investment from the users point of view.
28
In
some cases, this resulted in making available technically valid products for which very
few customers were interested in. The techniques described in this section can help
bridge this gap and will be used later on when documenting the system requirements
for this project as gathering unambiguous and detailed software requirements is a vital
part of any software development endeavour. K. Wiegers (2003) states that not
dedicating enough time to properly document requirements for a system usually leads
to at least one of the following:
Unusable product
Dissatisfied customers
29
Business requirements are documented in the vision and scope document of the project,
whilst functional requirements are usually formally recorded in software requirements
specification (SRS) documents. These formal documents describe, in as much detail as
possible, the expected behavior of the system and often also outline non-functional
requirements such expected quality standards, regulations and other constraints.
User requirements, sometimes also called Voice of the Customer, describe the system
as a set of tasks that the user must be able to accomplish with the product.
Unfortunately, gathering these requirements is seldom an activity that will result in a
well-ordered list of detailed needs and it will often require refining steps and
subdividing the input provided into different categories as a better understanding is
gained. Table 2 outlines how the Voice of the Customer can be further subdivided into
nine requirement categories and provides a brief description of each one (Wiegers,
2003). These requirements are documented, expanded, and confirmed using Use Case
diagrams, which describe a single instance of usage of the system and outline the
relationship between users (actors) and tasks (use cases) to be performed.
Table 2 Classifying the Voice of the Customer
Business Requirements
Use Cases
30
Rules that states which users can perform a specific activity and
under which specific conditions. These rules will need to be
captured in the software functional requirements and enforced by
the system.
Access control is a typical business rule in most of computer
systems.
Functional
Requirements
Quality Attributes
External Interface
Requirements
Constraints
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
The list below, again adapted from K. Wiegers (2003), defines the major steps that
should be carried when documenting requirements for a software project:
1. Identify Business Requirements
2. Identify users of the software
3. Gather User Requirements
4. Define Use Case scenarios
5. Gather Functional Requirements
6. Subdivide system-level requirements into major subsystems and match
requirements to software components
7. Define implementation priorities
8. Review use cases against original requirements to ensure correctness.
31
32
dwellings are built to natively support the Smart Home, e.g. by installing twister-pair
cabling, most of todays Smart Home systems will be installed in existing houses. In
order to ensure ease of installation and minimize costs, it will not be feasible for the
average user to run new cabling that would support a twisted-pair home network. By
excluding Busline technology, Smart Homes will need to be implemented with either
Wireless or Powerline communication. As Wireless is still expensive, Powerline, that
is technology that use of the existing electrical network to operate, seems the only truly
viable alternative. The issue here is that most of the protocols that use this type of
communication are quite old, can be unreliable, and are quite limited in terms of
bandwidth.
33
34
Users goals and how they can be mapped against the systems primitive
operations
35
37
example, the family might sometimes forget to turn on the porch light or to leave the
dog out when leaving the house. Figure 10 expands the causal graph by adding the
probability values given for all the BN nodes. These values are usually gathered by
direct observation, from historical data (also known as cases) or from information
gathered via expert knowledge. So, let us say that when the family leaves the house,
someone remembers to turn the porch light most of the times (60%), but that there is a
smaller (5%) chance that the light is on even when people are in the house, say when a
guest is expected. The first is represented as P(lo|fo)=0.6, which reads: the
likelihood (P) that light-on (lo) and family-out (fo) equals to 60% (0.6). Conversely,
the second case is represented by P(lo|fo)=0.05; that is, the likelihood (P) that
light-on (lo) but not family-out (fo) equals to 5% (0.05). Once all the probabilities
are provided, the BN tree is used to validate the hypothesis for which is was created
(e.g. to resolve the family-out scenario).
38
A practical example of how BN can be used to infer the users goal is Project Lumire.
Started in 1993 by Microsoft Research Labs, the project investigated how BN trees
could be used to help users of a computer system. The model built tried to infer a
users goals based on their past and current actions and on their supposed knowledge of
the system. The system would then propose tasks that should have helped the user to
reach his/her goal.
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
40
4. Development
This chapter outlines the development of a Smart Home system. The Analysis section
will document the system requirements for a complete Smart Home system based on
the information gathered by the Research, whilst the Implementation section will focus
on the development of a Proof-of-Concept (POC) system. The system that will be
developed is a Temperature Control System, envisaged as a subset of a full Smart
Home system. In addition to the usual features present in such systems, the POC will
also implement a Bayesian Network that can help the Fire Alarm sub-system to
determine the likelihood of a fire. Note that, while the analysis will be carried out for
the complete system, only a sub-set of this will be developed further into the POC.
4.1. Analysis
This section will outline the system requirements for the Smart Home system. As no
real end user was available to gather the necessary input on the user requirements, an
attempt was made to identify the user profile and such requirements by considering the
findings outlined by a survey reported by M. Pragnell in The market potential for
Smart Homes (2000).
4.1.1. BusinessRequirements
This section outlines the high-level objectives of the project.
As documented in
Chapter 1, the aim of this project is to develop a POC system that addresses some of the
challenges emerged during the research. This statement will therefore define the vision
and scope. The reason why this project is being carried out is two-fold:
The findings reported by M. Pragnell (2000) will be used to determine the likely user
profile for the software being designed. The aims of the survey were to assess views
about key features, to identify concerns, to assess the level of interest, and to identify
41
Family households
Aged 15 to 34
Technology savvy
The differences present in the user profile defined above might still require further
clarification before the design phase can start. Should a full Smart Home system need
to be built, developing different personas might help with this process. A persona
could, for example, be created to identify an adult user of the system, whilst another
one might define a typical teenager who might have very different goals and
requirements than the former. As this project will design a Proof-of-Concept system,
this step was not deemed necessary.
4.1.3. GatheringUserRequirements
The findings reported in The market potential for Smart Homes (Pragnell, 2000) will
be used again, this time with the purpose of gathering the user requirements for the
project. These findings will be then checked against the needs and concerns reported in
3.3.2. and integrated when required. For the sake of clarity, each of these requirements
will be expressed in form of simple statements that can be later used to devise
corresponding Use Case scenarios that will help with the system design.
Table 3 groups the statements identified according to the user requirement categories
defined by K. Wiegers (2003). Note that not all types might be present and that some
of the entries may fit more than one category.
42
Categories
Business Requirements
Quality Attributes
Solution Ideas
from home.
The system should integrate safety and security features.
Business Rules
Use Cases
Quality Attributes
Functional Requirements
Business Requirements
External Interface
home.
Requirements
Use Cases
Use Cases
Quality Attributes
Functional Requirements
privacy.
The system should be customizable.
Quality Attributes
Quality Attributes
Quality Attributes
technologies.
The system should also provide access from a mobile device.
Solution Ideas
The system should offer the ability to program events into the
Use Cases
future.
The system should allow to issue immediate commands to
Use Cases
controlled devices.
The system should support multiple users.
Solution Ideas
Quality Attributes
4.1.4. UseCaseDiagrams
This section outlines the Use Case diagrams that detail the most common actions
performed in the system.
43
4.1.5. FunctionalRequirements
Table 4 outlines the Functional Requirements for the system. The column ID provides
each requirement with a unique identifier. The System Feature column provides a title
for the requirement. The Priority column provides a value 0 through 4 that indicates
the priority for the feature to be implemented in the system (0 = must be in, 4 = low
priority). The Requirement Details column provides the following:
Description: a short description of the feature, useful to identify this later on.
44
45
System Feature
Priority
FR-01
Override
Stimulus/Response Sequence: User requests that the system release control of a device to be opera.
Functional Requirements:
FR-01.1. The system shall provide users with a feature to temporarily disable or permanently remove a
device present the system via the User Interface. A device removed or disabled shall henceforth be
operated manually i.e. no automatic control or schedule shall affect its operation.
FR-01.2. The system shall allow users to re-enable a temporarily disabled device. If the device had
associated scheduled events, this shall ask the authenticated user whether they are to be considered or
discarded.
FR-01.3. When a device is being re-enabled, the system shall warn a user of the presence of future
scheduled event and shall be given the option to either retain or remove (delete) these schedule.
FR-01.4. If user permanently remove a device from the system, all the associated information (e.g.
history, logs, and schedule) shall also be deleted from the system.
FR-01.5. The system shall alert a user that permanently deleting an object from the system also removes
all its associated information.
FR-02
Feedback to the
User
Stimulus/Response Sequence: User to enter command to perform an immediate task; System to automatically
2
FR-02.1. The system shall provide feedback for a user request for an instant command within 3 seconds
from the command being issued by the user.
ID
System Feature
Priority
FR-02.2. The system shall implement a means to record all instant command requests and their
outcomes for later user retrieval and examination.
FR-02.3. If an instant command takes more than 3 seconds to complete, the system shall provide
continuous feedback to the user who requested it until the command either returns with a OK/Failed result
OR is aborted (cancelled) by the user.
FR-02.4. The system shall evaluate immediately information received by real-time sensors (e.g. intruder
alert).
FR-03
Access Control
Description: The system shall employ means to protect the information present in the system.
and Data
Protection
Functional Requirements:
FR-03.1. The system shall present a login screen comprised of username and passcode before allowing
access to the system.
FR-03.2. The system shall validate information provided in the login screen against the credential stored
in the system and grant access if there is a match or deny access otherwise.
FR-03.3. The system shall store username and passcode information in an internal database.
FR-03.4. The system shall request an initial username and passcode when being first installed. The
system shall use this information to create the first power user (administrator) account in the system.
FR-03.5. The system shall define two types of users: normal and power users (administrators).
FR-03-6. The system shall grant access to certain functions to power users only.
FR-03-7. The system shall allow only power users to create other users.
FR-03.8. The system shall allow only power users to reset passwords for other users.
47
ID
System Feature
Priority
FR-03.9. The system shall allow only power users to delete existing users.
FR-03.10. For a user already logged in, the system shall request the users passcode again after the
account has been idle for x number of minutes (configurable within user preferences).
FR-04
FR-03.11. The system shall allow only power users to create or modify teams.
FR-03.12. The system shall store command issued and confirmed system changes in an Event Log.
FR-04.1. The system shall implement appropriate HCI methodologies for its User Interface.
FR-04.2. The system shall implement relevant industry-standard guidelines, depending on the actual user
interface used (e.g. Microsoft Windows, Internet Browser, etc.)
FR-04.3. The system shall warn users and ask for confirmation for operations that can potentially cause a
loss of data.
FR-04.4. The system shall implement an inference engine that periodically analyzes actions taken by user
and events stored and suggest/carry out tasks that can improve the users experience.
FR-04.5. For all operations documented in a Use Case diagram that are longer than three steps (e.g.
three mouse clicks) before then can be completed, the system shall provide a step-by-step,
FR-04.6. None of the commonly used features shall be more than three steps away (e.g. three mouse
clicks) from the main system window.
FR-05
Support Users
View of the
Description: The system shall provide a means to group devices together to create user-defined subsystems and enhance usability.
48
ID
System Feature
Priority
System (1)
Functional Requirements:
FR-05.1. The system shall allow power users to create and name teams (groups of devices).
FR-05.2. The system shall allow users to control teams as a single device (e.g. turned on or off with a
single command).
FR-05.3. The system shall make available all the methods (i.e. operations) in common with all the
devices in present in a team.
FR-05.4. The system shall provide users with the option to disable or enable all the devices in a team with
a single command.
FR-05.6. The system shall provide users with the option to disable all the devices in a team with a single
command.
FR-06
Remote Access
Support
Stimulus/Response Sequence: User connects to the system from a remote location (e.g. office).
3
Functional Requirements:
FR-06.1. The system shall allow remote users to connect to the system from a remote location via the
home internet connection.
FR-07
Reliability
FR-06.2. The system shall provide a secure means to authenticate remote users.
Stimulus/Response Sequence: Internal or external events causes the system to stop operating.
Functional Requirements:
49
ID
System Feature
Priority
FR-07.1. The system shall implement an internal mechanism to verify that a instant or deferred command
has been successfully executed.
FR-07.2. The system shall be able to restart automatically after a mains power outage.
FR-07.3. The system shall monitor itself and be able to recover after a crash.
FR-07.4. The system shall provide a means to store operation issues for later examination.
FR-07.5. The system shall provide a means to store information about notification options to report issues.
FR-07.6. The system shall automatically notify designated users when normal functioning is resumed.
FR-07.7. When recovering from a power outage, the system shall ensure that all controlled devices be in
sync with the last know configuration.
FR-08
FR-07.8. The system shall ensure the integrity of the information stored.
Support Users
View of the
System (2)
Functional Requirements:
FR-08.1. The system shall save user preferences and remember these the next time the same user
access the system.
FR-09
Compatibility
Functional Requirements:
FR-09.1. The system shall be able to operate successfully along with other home automation solutions.
FR-09.2. The system shall provide a way to identify its own devices from others.
FR-09.3. The system shall use Powerline (i.e. electrical mains) as its home network.
50
ID
System Feature
Priority
FR-09.4. The system shall provide support for at least other two network protocols (e.g. RF/IF, Twisted
Pair, etc.).
FR-10
Expandability
FR-10.1. The system shall provide users with the option to add a new compatible device into the system
via the User Interface.
FR-10.2. Users shall be able to integrate the new device into the existing system (e.g. adding it to a
teams, setting a schedule, etc.).
FR-11
Mobile Device
Support
Stimulus/Response Sequence: User wants to access the system from a mobile device.
Functional Requirements:
FR-11.1. The system shall provide a means for mobile users to access the system via a suitable user
interface.
FR-11.2. The system shall offer a suitable interface compatible with the visualization constraints of the
mobile device used.
FR-12
Support for
Scheduled
Commands
FR-11.3. The system shall authenticate a user trying to connect via the mobile device.
FR-11.4. Mobile users shall not be able to perform admin (power user) tasks.
Description: The system shall provide the ability to handle deferred (scheduled) commands.
1
Stimulus/Response Sequence: User wants to schedule a task for a team/device in the future.
Functional Requirements:
51
ID
System Feature
Priority
FR-12.1. The system shall provide users with a means to schedule a task in the future for a device via the
User Interface
FR-12.2. The system shall provide users with the option to repeat a scheduled task at a given interval
(e.g. daily, weekly, monthly).
FR-12.3. The system shall provide the option to schedule tasks for a device or a team.
FR-12.4. The system shall allow only power users to add/edit/delete a schedule for a team.
FR-12.5. The system shall routinely scan the active schedule to see whether any actions need to be
performed.
FR-13
Support for
Multiple Users
User Interface.
FR-14
FR-13.1. The system shall provide power users with the ability to add new users in the system via the
FR-13.2. The system shall provide users with the ability to save their preferences.
FR-13.3. The system shall provide power users to designate an owner for a team.
FR-13.4. The system shall allow designated team owners to fully control the team.
FR-13-5. The system shall not allow team owners to delete a team or add/remove devices.
Stimulus/Response Sequence: Users try to operate the same team or device at the same time; Users try to save
two conflicting schedules for the same team or device.
Functional Requirements:
52
ID
System Feature
Priority
FR-14.1. The system shall provide users with a warning message when another user is already operating
the same device (or team) and abort the last transaction.
FR-14.2. The system shall consider the team ownership (if available) when determining who has priority
over a conflicting schedule and keep/accept the one issues by the team owner.
FR-14.3. The system shall allow team managers to created closed teams to impede control of the
devices present in the team by other users.
FR-14.4. The system shall still allow power users to control a closed team.
FR-14.5. The system shall allow team owners to re-open a closed teams to allow control to all users.
53
Functional Requirements
Command
Dispatcher
system shall provide continuous feedback to the user who requested it until
the command either returns with a OK/Failed result OR is aborted (cancelled)
by the user.
Device
FR-01.1. The system shall provide users with a feature to temporarily disable
Manager
or permanently remove a device present the system via the User Interface. A
device removed or disabled shall henceforth be operated manually i.e. no
automatic control or schedule shall affect its operation.
FR-01.2. The system shall allow users to re-enable a temporarily disabled
device. If the device had associated scheduled events, this shall ask the
authenticated user whether they are to be considered or discarded.
FR-01.3. When a device is being re-enabled, the system shall warn a user of
the presence of future scheduled event and shall be given the option to either
retain or remove (delete) these schedule.
FR-01.4. If user permanently remove a device from the system, all the
associated information (e.g. history, logs, and schedule) shall also be deleted
from the system.
FR-05.4. The system shall still provide users with the ability to operate a
device part of a team as it were stand alone. (e.g. can issue immediate
commands and scheduled events shall still apply).
FR-09.2. The system shall provide a way to identify its own devices from
others.
FR-10.1. The system shall provide users with the option to add a new
compatible device into the system via the User Interface.
FR-10.2. Users shall be able to integrate the new device into the existing
system (e.g. adding it to a teams, setting a schedule, etc.).
Event
Collector
Event Logger
FR-07. 4. The system shall provide a means to store operation issues for
55
Sub-System
Functional Requirements
later examination.
FR-03.12. The system shall store command issued and confirmed system
changes in an Event Log.
FR-02.2. The system shall implement a means to record all instant command
requests and their outcomes for later user retrieval and examination.
Flight Control
Inference
Engine
analyzes actions taken by user and events stored and suggest/carry out
tasks that can improve the users experience.
System
FR-01.3. When a device is being re-enabled, the system shall warn a user of
Scheduler
the presence of future scheduled event and shall be given the option to either
retain or remove (delete) these schedule.
FR-12.1. The system shall provide users with a means to schedule a task in
the future for a device via the User Interface
FR-12.2. The system shall provide users with the option to repeat a
scheduled task at a given interval (e.g. daily, weekly, monthly).
FR-12.3. The system shall provide the option to schedule tasks for a device
or a team.
FR-12.4. The system shall allow only power users to add/edit/delete a
schedule for a team.
56
Sub-System
Functional Requirements
FR-12.5. The system shall routinely scan the active schedule to see whether
any actions need to be performed.
Team
FR-05.1. The system shall allow power users to create and name teams
Manager
(groups of devices).
FR-05.2. The system shall allow users to control a team as a single device
(e.g. turned on or off with a single command).
FR-05.3. The system shall make available all the methods (i.e. operations) in
common with all the devices in present in a team.
FR-05.5. The system shall allow devices to be part of multiple teams.
FR-05.6. The system shall provide users with the option to disable or enable
all the devices in a team with a single command.
FR-13.3. The system shall provide power users to designate an owner for a
team.
FR-13.4. The system shall allow designated team owners to fully control the
team.
FR-13-5. The system shall not allow team owners to delete a team or
add/remove devices.
FR-14.3. The system shall allow team owners to created closed teams to
impede control of the devices present in the team by other users.
FR-14.5. The system shall allow team owners to re-open a closed teams to
allow control to all users.
User Admin
FR-03.5. The system shall define two types of users: normal and power users
(administrators).
FR-03-6. The system shall grant access to certain functions to power users
only.
FR-03-7. The system shall allow only power users to create other users.
FR-03.8. The system shall allow only power users to reset passwords for
other users.
FR-03.9. The system shall allow only power users to delete existing users.
FR-03.11. The system shall allow only power users to create or modify
teams.
FR-13.1. The system shall provide power users with the ability to add new
users in the system via the User Interface.
FR-07. 5. The system shall provide a means to store information about
notification options to report issues.
FR-03.3. The system shall store username and passcode information in an
internal database.
57
Sub-System
Functional Requirements
User
FR-03.2. The system shall validate information provided in the login screen
Authenticator
against the credential stored in the system and grant access if there is a
match or deny access otherwise.
FR-03.10. For a user already logged in, the system shall request the users
passcode again after the account has been idle for x number of minutes
(configurable within user preferences).
FR-06.2. The system shall provide a secure means to authenticate remote
users.
FR-11.3. The system shall authenticate a user trying to connect via the
mobile device.
User Interface
FR-01.5. The system shall alert a user that permanently deleting an object
from the system also removes all its associated information.
FR-02.1. The system shall provide feedback for a user request for an instant
command within 3 seconds from the command being issued by the user.
FR-03.1. The system shall present a login screen comprised of username
and passcode before allowing access to the system.
FR-03.4. The system shall request an initial username and passcode when
being first installed. The system shall use this information to create the first
power user (administrator) account in the system.
FR-04.1. The system shall implement appropriate HCI methodologies for its
User Interface.
FR-04.2. The system shall implement relevant industry-standard guidelines,
depending on the actual user interface used (e.g. Microsoft Windows,
Internet Browser, etc.)
FR-04.3. The system shall warn users and ask for confirmation for operations
that can potentially cause a loss of data.
FR-04.5. For all operations documented in a Use Case diagram that are
longer than three steps (e.g. three mouse clicks) before then can be
completed, the system shall provide a step-by-step,
FR-04.6. None of the commonly used features shall be more than three steps
away (e.g. three mouse clicks) from the main system window.
FR-06.1. The system shall allow remote users to connect to the system from
a remote location via the home internet connection.
FR-08.1. The system shall save user preferences and remember these the
next time the same user access the system.
FR-11.1. The system shall provide a means for mobile users to access the
system via a suitable user interface.
58
Sub-System
Functional Requirements
FR-11.2. The system shall offer a suitable interface compatible with the
visualization constraints of the mobile device used.
FR-13.2. The system shall provide users with the ability to save their
preferences.
General to the
FR-09.3. The system shall use Powerline (i.e. electrical mains) as its home
System
network.
FR-09.4. The system shall provide support for at least other two network
protocols (e.g. RF/IF, Twisted Pair, etc.).
FR-09.1. The system shall be able to operate successfully along with other
home automation solutions.
4.1.7. Glossary
A Glossary of the terms used when defining Functional Requirements is provided
below.
Action
Actuator
Audit Log
Automated
Action
Closed Team
Deferred
Command
Device
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
Instant Action
Local User
Mobile Device
Mobile Users
Passcode
Power User
Real-time Sensor
Remote User
Removed Device
Schedule
A command set in the future that will trigger one or more actuators
when executed. A schedule can also contain multiple or recurring
events.
Scheduled
Action
Sensor
Team
Team owner
User
User Interface
Username
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
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
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
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
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.
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
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
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
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
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
See: http://www.echelon.org
70
71
A single output NV may connect to more than one input NVs, creating what is called a
fan-out connection. This is a useful feature that would allow, for example, a single
switch to control multiple lights or a light to be controlled by multiple switches.
Through a process called binding, usually performed during the design and installation
phase, the devices firmware is configured to know the logical address of the other
device, or group of devices, in the LonTalk network from which to expect input via one
of its NVs. This process creates logical connections among devices that might be
thought as virtual wires.
Finally, controlled devices can also provide NVs that can be used to determine whether
a command completed successfully, thus increasing reliability. Figure 26 depicts an
example of a typical LonWorks solution that is made of two switches, one light sensor,
and two lamps. The system also makes use of the feedback mechanism via one of the
lights nvoSwitchFb output NVs. In such configuration, the light can return its
current status to the controlling switches via the nviSwitchFb Network Variable.
72
The POC system uses a Mini EVK Evaluation Kit, acquired from Echelon Corp., which
includes the following:
Two I/O Boards (Mini Gizmos) that can be attached to each EVB
A USB Network Interface (U10) used to connect the computer to the LonWorks
network and communicate with the devices
Twisted-pair (TP) cables for wiring the two EVB and the USB Network
Interface
73
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
Configuration Properties
Network Variables5
SFPTnodeObject
nciNetConfig
nvoStatus
cpLocation
nviRequest
nvoDirectory
SFTPclosedLoopActuator (lights)
cpHeartbeatInterval
nviLight
nvoLightFb
SFTPclosedLoopSensor (switches)
cpHeartbeatInterval
nvoSwitch
nviValueFb
SFTPhvacTempSensor
cpThrottle
nvoTemperature
(thermometer)
cpDelta
nvoTemperatureF
SFTPOpenLoopActuator (buzzer)
nviFrequency
nviEnable
4.3.2. Software
The POC system will outline a possible solution for a Temperature Control system,
which will include the following devices:
Sensors (input devices):
HVAC System
The nvo and nvi suffix define an output or input variable respectively.
75
Main Switch
HVAC System
Temperature sensor
Buzzer
The Temperature Control System (TCS) will continuously interpret the data provided
by the sensors installed and take actions depending on the input received. The
applications main screen is divided into two main sections, left to right: the section on
the left can be defined as the control panel, providing all the settings available and
the system outputs; the section on the right provides the real-world representation of the
system.
This will also provide the location of the actual sensors and actuators
throughout the house: the Light Sensor, Motion Sensor, Fire Alarm, and HVAC).
76
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
The POC system can be conceptually sub-divided into three main sub-systems: the Fire
Alarm sub-system, the Heating and Air Conditioning sub-system, and the Inference
Engine. The following sections will go into more details for each of these sub-systems.
Both the FA and HVAC sub-systems can be turned on or off using their main switches.
Fire Alarm Sub-System
The Fire Alarm sub-system (FA) will monitor the environment for the likelihood of a
fire in order to alert security personnel in time to address potentially dangerous
situations. Figure 32 displays the settings for the FA sub-system.
78
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
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.
80
scenario by calculating its statistical probability according to the state and relationships
of the other nodes.
Manually calculating the probability of such a model can be a tedious and timeconsuming task as the calculations involved can increase exponentially and the amount
is given by the formula: Sn-1, where S is the number of states that a variable can
assume and n is the number of nodes. For the BN illustrated in Figure 36, which
contains only binary variable, it would still require 281=255 calculations. In reality
Bayesian Networks do not actually need to perform all these calculations; however a
more in-depth discussions is beyond the scope of this paper. Further discussions on
Bayesian Networks can be found in the material referenced.
See: http://www.norsys.com/
81
Table 8 provides the rationale behind these relationships. Note that each node will have
only two possible status. The probability tables for a practical implementation of these
relationships can be found in the appendices.
Table 8 BN Nodes and Relationships
Node (values)
Relationship with
Reasons
Fire Danger
none
(true/false)
Cooking Time
High Temperature
(true/false)
Fire Danger
Daytime
HVAC
(true/false)
High Temperature
Lived In
82
Node (values)
Relationship with
Reasons
Lived In: The Motion Sensor is likely to be more
often ON during the day (people moving around)
than at night.
High Temperature
Fire Danger
(true/false)
HVAC On
High Temperature
(true/false)
Lived In (true/false)
HVAC On
Fire Danger
Summer
High temperature
(true/false)
Daytime
HVAC
83
4.4. Testing
This section illustrates the testing carried out with the POC system. It provides an
outline of the test plan, its deliverables, a summary of the results and the outcomes of
the test. Details of the individual tests are provided in the appendices.
4.4.1. TestPlan
This section will outline the Test Plan for the POC system.
Introduction
This plan is drafted for the application Temperature Control System (TCS), Version
0.0.1.1, which has been designed as a Proof-of-Concept for a Smart Home system
outlined in the Analysis section of this paper. The purpose of this Test Plan is to test a
84
Testing Approach
As this POC was conceived as a throw-away prototype, the code is as such not intended
to be re-used and no other testing techniques other than System Testing will therefore
be used.
Suspension Criteria and Resumption Requirements
Test Cases are given a Severity (1= high, 3= low) and Priority (1= must have, 3= nice
to have). All failed test cases will be reported in the Bug Report along with details of
the failure and any workaround (if available). However, only Severity 1 or Priority 1
features are considered high impact.
Testing will not be halted if non-high impact bugs are found. Testing will resume as
soon as a new build which corrects the high-impact bugs is available. The test
execution order will take the following order:
1. Smoke and confidence tests
2. The tests which found the bugs which have just been fixed
3. The regression tests
85
Test cases
Bug reports
Testing Tasks
Identify:
The set of tasks necessary to prepare for and perform unit, integration, and system
testing
All inter-task dependencies and any special skills required
Environmental needs
In addition to the software specified in the Interface with Other Systems section of
this Plan, the following HW and SW will also be required to perform the tests:
Minimum Requirements:
1GB RAM
86
Risk
Impact
Contingency Plan
One high-impact
bug found
feature.
possible)
Two high-impact
application
4.4.2. TestCases
Table 10 reports the summary of all the test cases and their results. The details of each
test case can be found in the Appendices.
Table 10 Summary of Test Results
ID
PASS/FAIL
SEV
PRI
NOTES
(ROUND)
1
PASS (1)
PASS (1)
PASS (1)
FAIL (1)
PASS (1)
PASS (1)
PASS (1)
PASS (1)
87
ID
PASS/FAIL
SEV
PRI
NOTES
(ROUND)
9
PASS (1)
10
PASS (1)
11
PASS (1)
12
PASS (1)
13
PASS (1)
14
PASS (1)
15
PASS (1)
16
PASS (1)
17
FAIL (1)
18
PASS (1)
19
PASS (1)
20
PASS (1)
21
PASS (1)
22
PASS (1)
23
PASS (1)
88
4.4.3. FunctionalRequirementsImplementedinPOC
Table 11 outlines the subset of the original Functional Requirements implemented in the POC.
Table 11 List of Functional Requirements Implemented
Sub-System
Implementation Details
Device
FR-01.1. The system shall provide users with a feature to temporarily disable or permanently
Manager
remove a device present the system via the User Interface. A device removed or disabled shall
mode.
henceforth be operated manually i.e. no automatic control or schedule shall affect its operation.
User Interface
Event Logger
FR-02.1. The system shall provide feedback for a user request for an instant command within 3
FR-02.2. The system shall implement a means to record all instant command requests and their
Event
FR-02.4. The system shall evaluate immediately information received by real-time sensors (e.g.
Collector
intruder alert).
Event Logger
FR-03.12. The system shall store command issued and confirmed system changes in an Event Log.
User Interface
FR-04.1. The system shall implement appropriate HCI methodologies for its User Interface.
Sub-System
Implementation Details
Use of real-world analogies (e.g.
sliders) to control device settings.
Objects and settings logically
grouped together.
Enabled use of mouse with
keyboard accelerators (shortcuts) as
secondary ways to access all main
features.
User Interface
FR-04.2. The system shall implement relevant industry-standard guidelines, depending on the actual
implemented in GUI.
FR-04.6. None of the commonly used features shall be more than three steps away (e.g. three
main window.
Event Logger
FR-07.4. The system shall provide a means to store operation issues for later examination.
Device
FR-09.2. The system shall provide a way to identify its own devices from others.
User Interface
Manager
Device
FR-10.1. The system shall provide users with the option to add a new compatible device into the
Manager
dialog box.
Device
FR-10.2. Users shall be able to integrate the new device into the existing system (e.g. adding it to a
Manager
dialog box.
90
4.4.4. BugReport
Table 12 provides the list of tracked bugs for the application.
Table 12 Bug Report
Bug #
Title
Description
Status
Feature Area
Severity
Environment
Resolution
Manual Neuron
Fixed
Device Manager
3 (low)
ID
04D5CA75020
However
get un-muted
triggered
Alarm ticked
Open
91
1 (high)
FA Alarm system
4.4.5. TestOutcomes
Out of the total number of test cases devises, 21 passed, giving a first-pass rate of 91%.
Moreover, one of the failed tests (Test # 4) was not a high-impact feature and had a
workaround and a sub-sequent investigation found that the reason of the failure was
caused by the incorrect number being provided in the test case.
The other failed test (Test # 17) is high-impact as it affects an important feature of the
FA sub-system but it will not be a show-stopper according to the Suspension Criteria
listed previously. However, if time allows, a decision will be made to see whether it
will be feasible to correct this bug before the deadline.
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.
5.1. SummaryoftheWork
Chapter 1 has defined the initial aim and objectives for this project. The aim was to
develop a proof-of-concept that would address at least some of the challenges found
during the research. The intellectual challenge was to investigate how a Smart Home
system could be made more effective by using AI techniques.
Chapter 2 has provided the formal definition of a Smart Home system and outlined a
history of appliances and home networking technologies which are fundamental to the
existence of a Smart Home. It has also provided an overview of recent development and
current research projects.
Chapter 3 has investigated in more detail the basic blocks of a Smart Home system and
has provided an overview of home network communication protocols in existence
today.
It has then expanded on the potential market for Smart Homes, outlining
benefits, needs, and concerns reported by recent researches. Finally, it has outlined
current design challenges and provided suggestions on how they could be addressed.
Chapter 4 has dealt with the actual development of a Smart Home system. In the
Analysis section, the system requirements and the main sub-system for the system were
outlined in details. The Design section has expanded the analysis by documenting use
case scenarios and integrating these into the sub-systems identified.
The
93
5.2. ProjectFindings
The main finding of this project is that it is indeed possible to make a Smart Home
system more effective by integrating AI technologies into it. The proof-of-concept has
provided an example on how such a system can analyze the information gathered from
the environment using a Bayesian Network that can be used by an inference engine that
could calculate the likelihood of a fire. Although the POC offers a simplified view of a
Fire Alarm system, it already offers a solution that can be implemented in a real-world
application. It also illustrates a concept that can be further developed to support
different and more complex decision-making scenarios.
engine could be enhanced further so that it can learn from the input provided by users
actions, e.g. whenever a user cancels or overrules a command, and from the actual data
gathered by sensors, e.g. determining actual cooking times. This will enable the system
to adapt to the specific environment where it operates and become more accurate, thus
increasing its effectiveness overtime.
5.3. RecommendationsforFutureWork
Regarding the proof-of-concept system developed by this work, it is understood that it
provides a subset of a fully functional Smart Home system.
recommendation would be to develop and implement the other areas identified in the
Analysis and Design sections. Furthermore, future work should provide implementation
of the core as a Web Service and develop a web-based User Interface as this will
provide support to heterogeneous web-based clients which will allow mobile and
remote users to connect. Finally, the system demonstrated how Bayesian Networks can
effectively support decision making in many automated areas of the system and an
effort should be made to explore this concept further.
General recommendations can also be provided about the design of Smart Home
systems. First, it is suggested that producers of Smart Home technology should take
more time to try and understand users needs before developing new products and
should put more effort in making potential users understand what their solutions can do
for them. Second, as the existence of too many standards has been slowing down a
wider adoption of this technology by the consumer and building industries, it is
94
5.4. LearningOutcomes
5.4.1. Research
Google Scholar proved to be an invaluable starting point to locate white papers,
publications and books on the topic. Reviewing this literature provided a deeper insight
on Smart Home systems, their challenges and recent researches made in the field, all of
which helped and challenged to dig deeper in certain areas to gain a more complete
understanding of the subject. The student memberships of ACM and IEEE also helped
in providing full access to most of the research papers and publications found, whilst
the local DIT library and Book24x7.com provided access to the books.
5.4.2. Analysis
This project has allowed me to apply methodologies and concepts learned in this course
to a real-world problem and to effectively document the requirements of an Information
System.
5.4.3. Technical
As identified at the beginning of this project, coding has been the singe biggest
challenge of this project, mostly due to lack of recent hands-on experiences with the
95
96
References
Charniak, E., Bayesian Networks without Tears, AI Magazine, vol. 12, no. 4, pp. 5063, 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. 395400, 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 Humancomputer 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
99
Appendices
Appendix A Details from Survey
This appendix outline the main findings of the survey reported by M. Pragnell (200) in
The market potential for Smart Homes. Some of the findings were used to determine
the user profile for the Smart Home system detailed in this paper.
Attitudes to new technology in the home:
Agreement by age group with the statement I welcome new technology in my home because it
saves me time and effort:
100
101
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
103
}
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.");
}
///
/// NETICA INFERENCE ENGINE VARIABLES
///
private double belief; // belief returned by the BN
static private Streamer RuleDBFile; // Netica file
static private BNet net; // the actual object used
///BN Nodes (only the ones managed by the POC)
104
private
private
private
private
private
BNode
BNode
BNode
BNode
BNode
fireNode;
highTempNode;
motionSensorNode;
lightSensorNode;
HVACNode;
///
/// Rule DB Initialization
///
string net_file_name = AppDomain.CurrentDomain.BaseDirectory +
"RulesDB.dne"; // filename
// creates new object
Netica.Application oRuleDB = new Netica.Application();RuleDBFile =
oRuleDB.NewStream(net_file_name, null);
net = oRuleDB.ReadBNet(RuleDBFile, "");
net.Compile();
// assigning nodes
fireNode = net.Node("fire_danger");
highTempNode = net.Node("hi_temp");
motionSensorNode = net.Node("ms");
lightSensorNode = net.Node("ls");
HVACNode = net.Node("hvac");
///
/// Recalculating the BN belief based on the current status of nodes
///
// record status of High Temperature reached
highTempNode.RetractFindings(); // required to clear any previous
findings (evidence) entered
if (bHighTemp)
highTempNode.EnterFinding("true"); // evidence of high temperature
provided by the sensor
// record status of HVAC
HVACNode.RetractFindings(); //reset any previous value
if (bHVACOn)
HVACNode.EnterFinding("true"); // the HVAC is ON
// record status of Motion Sensor
motionSensorNode.RetractFindings();
if (bMSOn)
motionSensorNode.EnterFinding("true");
// record status of Light Sensor
lightSensorNode.RetractFindings();
if (bLSOn)
lightSensorNode.EnterFinding("true");
// the MS is ON
105
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
application
2.
Expected Result:
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
application
2.
Expected Result:
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
Sub-System:
Device Manager
Severity:
Priority:
Dependencies:
Description:
Steps:
106
appears.
2.
Expected Result:
Pass/Fail?
Details:
PASS
Workaround:
Test ID:
Sub-System:
Device Manager
Severity:
Priority:
Dependencies:
Description:
Steps:
appears.
2.
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:
Workaround:
Test ID:
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
107
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.
Expected Result:
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
2. Wait 3 seconds
3. Set the FA switch to OFF
4.
Wait 3 seconds
Expected Result:
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
Sub-System:
Severity:
Priority:
Dependencies:
Description:
The system will provide feedback for a user request for an instant
command within 3 seconds from the command being issued.
Steps:
108
Wait 3 seconds Confirms that the HVAC has been turned off
(Switch # 2 in I/O Board) and that the UI has been updated
accordingly (i.e. HVAC switch is OFF)
Expected Result:
The status of the HVAC switch is refreshed within 3 seconds from the
users command.
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
Sub-System:
Severity:
Priority:
Dependencies:
Description:
System to record instant command requests and their outcomes for later
user retrieval and examination.
1. Take note of the current time and date
Steps:
The Event Logger recorded the event corresponding to the users action
with the correct timestamp.
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
Sub-System:
Severity:
109
Priority:
Dependencies:
Description:
Steps:
Wait 3 seconds
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:
Severity:
Priority:
Dependencies:
Description:
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.
Expected Result:
Changed in the Comfort Zone (min) and (max) are recorded in the Event
110
Log.
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
11
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
Expected Result:
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
12
Sub-System:
Severity:
Priority:
Dependencies:
Description:
All main features can be operated with less than three actions (e.g
mouse clicks)
Steps:
111
Expected Result:
Turn the FA ON
Mute FA Alarm
None of the operation listed will require more than three actions to be
completed.
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
13
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
Confirm that the two devices are part of the same Network ID
112
(9F:FF:FF:20:00:05:04:01)
Expected Result:
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
14
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
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:
Severity:
Priority:
113
Dependencies:
Description:
Steps:
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:
Pass/Fail?
PASS
1) Cannot set High Temp value below 29 degrees.
Details:
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:
Severity:
Priority:
Dependencies:
Description:
Steps:
114
Buzzer stops.
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
17
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
115
Mute Alarm check box is automatically un-ticked and the buzzer sounds.
Pass/Fail?
FAIL
Details:
Workaround:
Test ID:
18
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
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
Test ID:
19
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
Wait 3 seconds
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:
Severity:
Priority:
Dependencies:
Description:
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
Wait 3 seconds
The HVAC will remain OFF at night-time if the MS switch is ON and the
delta temp is still within 15%
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
21
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
Wait 3 seconds
The HVAC will be turned OFF when not required when in Automatic
Mode.
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
22
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
118
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:
Pass/Fail?
PASS
Details:
Workaround:
Test ID:
23
Sub-System:
Severity:
Priority:
Dependencies:
Description:
Steps:
Expected Result:
Pass/Fail?
PASS
Details:
Workaround:
Summer (su)
Probabilities:
Node:
True
False
.40
.60
True
False
.20
.80
Probabilities:
119
Node:
Daytime (dt)
Probabilities:
P(dt | su)
P(dt | su)
True
False
.70
.30
.30
.70
True
False
.60
.40
.80
.20
True
False
.70
.30
.40
.60
80.
.20
.45
.55
.30
.70
.20
.80
.20
.80
.15
.85
True
False
.15
.85
.10
.90
.80
.20
.50
.50
Node:
Lived In (li)
Probabilities:
P(li | dt)
P(li | dt)
Node:
HVAC On (hvo)
Probabilities:
P(hvo | li su dt)
P(hvo | li su dt)
P(hvo | li su dt)
P(hvo | li su dt)
P(hvo | li su dt)
P(hvo | li su dt)
P(hvo | li su dt)
P(hvo | li su dt)
Node:
Probabilities:
P(ht | su hvo dt ct)
P(ht | su hvo dt ct)
P(ht | su hvo dt ct)
P(ht | su hvo dt ct)
120
Node:
.25
.75
.20
.80
.15
.85
.08
.92
.10
.90
.05
.95
.05
.95
.01
.99
.08
.92
.05
.95
.08
.92
.04
.96
True
False
.20
.80
.25
.75
.30
.70
.35
.65
.003
.997
.005
.995
.001
.999
.001
.999
Probabilities:
P(fd | ht ct li)
P(fd |ht ct li)
P(fd |ht ct li)
P(fd |ht ct li)
P(fd | ht ct li)
P(fd | ht ct li)
P(fd |ht ct li)
P(fd |ht ct li)
121
Risk Details
Most of the technology is still
developed for the US market
and might not be readily
available in Europe.
All the technology research so
far has pros and cons. As of
today, it is not yet clear what
would be the best choice.
System programming
challenge
Tight timeframe
122
Contingency Plan
Contacting the manufacturers directly
to find out timing and availability of
the products needed before
considering using this in the project.
Narrow down the choice to two/three
candidates and pursue only these as
candidates for the project. Final
decision to be made by mid January
09.
Subscribe to on-line newsgroups that
will help with possible challenges.
Use a software design tool such as
Rational Rose to help with the
development.
When choosing the development
tool, see whether I can leverage the
past knowledge to cut developing
times.
Investigate availability of on-line
courses on system development that
are relevant to the system chosen for
the prototype.
Tight control of time and tasks via
Microsoft Project.
Implement relevant milestones to
detect deviations from the plan as
early as possible.
Consider the late delivery date (Sep
09) option to be reviewed in late
Feb 09.
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
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
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
123