Project Domus: Designing Effective Smart Home Systems
Project Domus: Designing Effective Smart Home Systems This project manual is submitted as partial fulfilment of the requirements for the BSc in Information Systems and Information Technology (DT249) to the School of Computing, Faculty of Science, Dublin Institute of Technology.
Author:
Paolo Carner, D08117953
Supervisor: Michael Gleeson, School of Computing Date:
18 April 2009
Project Domus: Designing Effective Smart Home Systems
Acknowledgments I would like to thank my supervisor Michael Gleeson for his guidance, time and support throughout the project. My friend and colleague Massimiliano Balsamo for his suggestions about the application’s user interface. A sincere thanks also goes to my wife Giorgia for all her patience, dedication and encouragement over the past months.
2
Project Domus: Designing Effective Smart Home Systems
Abstract The subject of this work is the analysis and design of a proof-of-concept Temperature Control System (TCS) part of a Smart Home. The TCS also implements an 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.
3
Project Domus: Designing Effective Smart Home Systems
Table of Contents 1.
Introduction ..............................................................................................................8
1.1.
Project Aim and Objectives..................................................................................8
1.1.1.
Aim ...................................................................................................................8
1.1.2.
Objectives .........................................................................................................8
1.2. 2.
Intellectual Challenge...........................................................................................8 Literature Review .....................................................................................................9
2.1.
Definition..............................................................................................................9
2.2.
History ..................................................................................................................9
2.2.1.
The Mechanical Revolution .............................................................................9
2.2.2.
The Electrical Revolution...............................................................................10
2.2.3.
The Information Revolution ...........................................................................12
2.3. 3.
Smart Homes Today ...........................................................................................13 Research .................................................................................................................16
3.1.
Components of a Smart Home System...............................................................16
3.1.1.
Control Systems .............................................................................................17
3.1.2.
Actuators ........................................................................................................17
3.1.3.
Home Network ...............................................................................................18
3.2.
Communication Protocols ..................................................................................19
3.2.1.
X10 and its Legacy.........................................................................................19
3.2.2.
Other Protocols...............................................................................................21
3.3.
The Market for Smart Homes.............................................................................23
3.3.1.
Potential Benefits............................................................................................24
3.3.2.
Reported Needs and Concerns........................................................................26
3.4.
Design Challenges ..............................................................................................28
3.4.1.
Gathering Valid System Requirements ..........................................................29
3.4.2.
Choosing the Right Technology.....................................................................32
3.4.3.
The Quest for the Effective User Interface.....................................................33
3.4.4.
The Role of Artificial Intelligence .................................................................36
3.4.5.
Going Beyond Home Automation..................................................................39
4.
Development ..........................................................................................................41 4
Project Domus: Designing Effective Smart Home Systems 4.1.
Analysis ..............................................................................................................41
4.1.1.
Business Requirements...................................................................................41
4.1.2.
Determining a User Profile.............................................................................41
4.1.3.
Gathering User Requirements ........................................................................42
4.1.4.
Use Case Diagrams ........................................................................................43
4.1.5.
Functional Requirements................................................................................44
4.1.7.
Glossary..........................................................................................................59
4.2.
Design.................................................................................................................61
4.3.
Implementation...................................................................................................69
4.3.1.
Hardware ........................................................................................................70
4.3.2.
Software..........................................................................................................75
4.4.
Testing ................................................................................................................84
4.4.1.
Test Plan .........................................................................................................84
4.4.2.
Test Cases.......................................................................................................87
4.4.3.
Functional Requirements Implemented in POC.............................................89
4.4.4.
Bug Report .....................................................................................................91
4.4.5.
Test Outcomes ................................................................................................92
5.
Conclusion..............................................................................................................93
5.1.
Summary of the Work ........................................................................................93
5.2.
Project Findings..................................................................................................94
5.3.
Recommendations for Future Work ...................................................................94
5.4.
Learning Outcomes ............................................................................................95
5.4.1.
Research .........................................................................................................95
5.4.2.
Analysis ..........................................................................................................95
5.4.3.
Technical ........................................................................................................95
5.4.4.
Project Management.......................................................................................96
5.4.5.
Lessons Learned .............................................................................................96
References ......................................................................................................................97 Appendices ...................................................................................................................100
5
Project Domus: Designing Effective Smart Home Systems
Figures and Tables 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 Roger’s 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
Project Domus: Designing Effective Smart Home Systems Figure 31 EVK Service Switch ............................................................................................... 78 Figure 32 Fire Alarm Sub-system Settings ............................................................................. 79 Figure 33 Logic Flow for the FA Sub-system......................................................................... 79 Figure 34 HVAC Sub-System Settings ................................................................................... 80 Figure 35 Logic Flow for the HVAC Sub-system................................................................... 80 Figure 36 Causal Graph for the FA Sub-system ..................................................................... 82 Figure 37 Fire Alarm Bayesian Network ................................................................................ 84 Table 1 Examples of Smart Home Applications ..................................................................... 25 Table 2 Classifying the Voice of the Customer....................................................................... 30 Table 3 Defining User Input.................................................................................................... 43 Table 4 Functional Requirements............................................................................................ 46 Table 5 Functional Requirements grouped by Sub-system..................................................... 55 Table 6 MGDEMO Attributes and Methods ........................................................................... 75 Table 7 Mapping Real-world Devices to the POC.................................................................. 76 Table 8 BN Nodes and Relationships...................................................................................... 82 Table 9 Test Plan Risks and Contingencies ............................................................................ 87 Table 10 Summary of Test Results ......................................................................................... 87 Table 11 List of Functional Requirements Implemented ........................................................ 89 Table 12 Bug Report ............................................................................................................... 91
7
Project Domus: Designing Effective Smart Home Systems
1. Introduction This chapter presents the project’s aim, objectives, and its intellectual challenge.
1.1. Project Aim and Objectives 1.1.1. Aim The aim of this project is to develop a proof-of-concept prototype for a Smart Home system that will address some of the challenges emerged during the research. 1.1.2. Objectives The project has the following objectives: •
Providing a brief history of the underlining technology
•
Presenting an overview and an evaluation of existing standards
•
Investigating potential benefits and documenting perceived issues
•
Researching current challenges
•
Designing and building a proof-of-concept
1.2. Intellectual Challenge Although the project will consider proper Human-Computer Interaction (HCI) techniques to provide users with a user-friendly interface, it will also aim at improving the “effectiveness” of Smart Home systems.
The Oxford Dictionary describes
“effective” as: “producing a desired or intended result” (emphasis added). According to this definition, it is envisaged that an effective Smart Home shall not only carry out automated actions on the users’ behalf, but be asked to interpret, understand and, if possible, anticipate what users might also intend to do. Elements of Artificial Intelligence, such as decision theories and adaptive systems, may be able to provide these capabilities.
8
Project Domus: Designing Effective Smart Home Systems
2. Literature Review This chapter presents a definition of Smart Home, provides a brief history of the technologies contained, and outlines recent developments in the field.
2.1. Definition A common definition of Smart Home is of an “electronic networking technology to integrate devices and appliances so that the entire home can be monitored and controlled centrally as a single machine” (Pragnell et al., 2000). Another term that describe the same technology is “domotics”, which derives from the Latin word domus, meaning home, and informatics, meaning the study of the processes involved in the collection, categorization, and distribution of data. However, since this technology is still very much in flux, other terms are also used in the literature with equivalent meaning, such as: “home automation”, “smart house”, “digital home” or “electronic home”.
Furthermore, note that, although the terms “house” and “home” have a
different meaning in the English language, they are often used alike in this context.
2.2. History Although the term “smart home” was first used in 1980s, the concept is far from new. The early documented attempt to envisage something very similar dates back to the 1960s, with Walt Disney’s Experimental Prototype Community of Tomorrow (EPCOT), presented in 1966i. A Smart Home will not be able to accomplish much without appliances to control, nor will it be able to communicate to these devices in the absence of a control network (“home network”). Since appliances and home network are so interlinked with a Smart Home, the following sections provide a brief history on how these come into being. 2.2.1. The Mechanical Revolution 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
Project Domus: Designing Effective Smart Home Systems In late 1800’s, the middle class was experiencing a shortage of domestic servants which created the need to find new ways to provide help in the home (Harper, 2003). Such necessity was the initial driving force behind the inventions of the first domestic appliances, which had the purpose of making household chores easier and do more with less. In 1911, Frederick Winslow Taylor published “The Principles of Scientific Management”, which advocated the use of efficiency to maximize results through minimal effort. This theory is today known as Taylorism and, though it was originally intended to be applied in industrial settings, this concept soon spilled over into the domestic realm due to the need at hand. Christine Frederick was one of the first to recognize that the challenges tackled by Taylorism were also directly applicable to domestic issues and captured these in her book “Household engineering: Scientific Management in the Home”, published in 1915. In her book, Frederick predicts that mechanical appliances would be the ones which were to take up the work originally performed by servants “where every possible purely manual task is done by arms of steel and knuckles of copper”. She also puts forward the idea of a Smart Home where she foretells that “such machinery will be far more unified than at present … with various pieces related to one another”, as reported by D. Heckman (2008). 2.2.2. The Electrical Revolution In spite of the first inventions, most of this new domestic technology would have still been easily recognized by people who had lived in the pervious Century. However, electricity, the driving force behind the electrical revolution, would soon to change this familiar landscape beyond recognition. Electrical energy first arrived in the homes around 1920s and, although initially used for lightning purposes only, by 1940s mains electricity was readily available to around 65 per cent of the total of houses in the UK. (Harper, 2003). Soon after it reached a critical mass, producers of electrical appliances inundated the market with all sorts of items. Although some of them were nice-to-have-devices, such as electric popcorns poppers, egg cookers and waffle irons, others were really life changing for the household: refrigerators, washing machines, electric cookers, vacuum cleaners, just to mention the most important. 10
Project Domus: Designing Effective Smart Home Systems Regardless of their importance, all these electrical appliances were still made with the original need in mind, which was often reminded to people as producers marketed these products with time-saving slogans such as “no longer tied down by housework” or “automatically gives you time to do those things you want to do” (Heckman, 2008). Figure 1 shows example of these early campaigns: a 1950s advertisement about a washing machine with the slogan “automatically gives you the time to do the things you want to do”.
Figure 1 Advertisement for a Washing Machine, Daily Mail (1955)
It is interesting to note how some later devices could be hardly classified as time savers and how, in spite of this, they were still quite readily adopted. By early 1980s, around 65 per cent of UK homes had a colour television set and half of them a video recorder (Harper, 2003). More interesting still, the adoption curve was different from one to another, sometimes regardless of the comfort that they could bring. For example, central heating, took comparatively a while longer to become widespread that the color television. Figure 2, taken from the research “The Market Potential for Smart Homes”, shows the adoption curve of some of the most common electrical devices in the household (Pragnell et al., 2000).
11
Project Domus: Designing Effective Smart Home Systems
Figure 2 Adoption of new technologies over time1
2.2.3. The Information Revolution Disney’s original vision for EPCOT was to create both a laboratory for new technology and a home for its inhabitants with the promise of offering an “integrated living environment” (Heckman, 2008). Due to his untimely death, just a few months after the official presentation of the project, EPCOT was never implemented, at least not in its original idea. The concept behind the original vision was however to live on. In the 1960s, a number of hardware and software innovations made possible for home owners to have access to the first computer-like appliances in their homes. Perhaps the first attempt to create a “home automation” system occurred in 1966 when Westinghouse proposed the experimental – and quite bulky – Electronic Computing Home Operator (ECHO) IV. Although the original system was supposed to automate the family finances, it was soon extended to include recipes, shopping lists, family inventory, and, in its final versions, added home temperature control and the ability to control appliances. In 1975, it was the turn of the Altair 8800, followed by the Apple II in 1977 and the IBM PC in 1981. While these computers were slowly finding their ways into the home, they also contributed to the creation of the idea of “smart machines”.
1
Source: General Household Surveys 1972-98, BARB, BT, Oftel, ITC, BskyB, ONS. Note: Data refer to percentage of households for all goods except mobile phones, which refers to percentage of population.
12
Project Domus: Designing Effective Smart Home Systems In 1978, after a few years of experimentation and refinement, PICO Electronics patented the X10 technology. This technology can be considered the first “home network” as, differently to other networks available at the time, it enabled the existing electrical wiring in anyone’s home to also be used as the media for the communication network. By doing so, X10 made home automation a reality for the majority of the household at an affordable price. Nowadays, an increasing number of houses have home computers, game consoles and always-on Internet connections that extend the availability of services and resources to the household beyond the physical boundaries of the home.
2.3. Smart Homes Today The Oxford Dictionary defines “smart” as both “stylish and fresh in appearance, having a quick intelligence”, and “being fashionable and upmarket”. Sony was among the first companies to attach the “smart” buzzword to a computer when, in 1982, it marketed the “Smart Sony” computer: no longer advertised simply as a “home” computer, but tried to cash in on the smart concept by selling it as a device which could “help you make smarter business decisions” (Heckman, 2008). The “smart” concept has become since a marketing catchword, still employed today, to sell a wide range of products, hence: “smart phones”, “smart cameras”, “smart design”, “smart bombs” and “smart homes”. Usually, the word define devices that are reportedly based on cutting-edge design that unite innovation with practical simplicity, However, as this would soon be demonstrated, sometimes marketing buzzwords alone cannot guarantee the sell. Xanadu was the first example of a mass-produced Smart Home. Built throughout the 1980s in the US around the original EPCOT idea, these houses were commercially built dwellings that made extensive use of Smart Home technologies.
To look even more
futuristic, the actual house was made entirely of polyurethane foam. The Xanadu home had a computer that monitored and controlled all its systems: the kitchen, living room, bathrooms, and bedrooms all had their own electrical and electronic devices to control the appliances present in the house. For example, the shower could be set to be turned on at a specific time and a set temperature. The ad campaign eloquently described the house as “Xanadu: the Computerized House of Tomorrow” and its peculiar appeal was set by the advertisement campaign: a “house with a brain – a house you can talk to, a 13
Project Domus: Designing Effective Smart Home Systems house were every room adjusts automatically to match your changing moods” (Heckman, 2008).
Figure 3 Picture of a Xanadu House
As the time moved on, and most of the houses were still unsold, the technology contained soon become obsolete. One by one, these Xanadu houses started to get demolished to make space for more “commercially viable” projects and, by October 2005, they were all gone. In spite of the commercial setback provided by the Xanadu homes, the concept was sound and a combination of elements such as computers, robotics and Artificial Intelligence (AI) were to push the Smart Home concept further, even if sometimes only in research laboratories. Throughout the 1980s, several innovative ideas provided a clear indication that the technology might have been finally mature enough to deliver commercially viable solutions.
As an example, a device named Waldo, which
interfaced with an Apple computer, could use voice recognition and speech synthesis technology to control appliances. Today, several commercial and academic projects, funded by universities and the industry alike, are still investigating the possibilities that Smart Homes can offer. A possibly incomplete list of projects working with Smart Home technologies can be found in the following paragraphs. For more information about some of them, see the referenced endnotes. CISCO Internet 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
Project Domus: Designing Effective Smart Home Systems demonstrates how Internet can enhance daily living for consumers for the homes and communities of the future. MIT House_niii – This project is led by a multi-disciplinary team composed by architects, computer experts, engineers and behavioural scientists who investigate key issues and what services could be offered in the home of the future. Its focus is on the design of the home and its related technologies, products, and services and to see how they can evolve to meet the opportunities and challenges in the new home. Microsoft Research EasyLivingiv – Started in 1998, EasyLiving is a project funded by Microsoft Research about creating an intelligent environment which will make computing more accessible and more pervasive than today’s desktop computer. Its goal is to develop a prototype architecture and technologies for building intelligent environments that facilitate people interaction with other people, computers, and other devices. UMASS intelligent home project – This project from University of Massachusetts uses simulations of agent-based intelligent systems that also use robotics in a domestic context. Adaptive Housev - This project, led by University of Colorado, aims at developing a Smart Home system that programs itself by observing the lifestyle and desires of the inhabitants, and by learning to anticipate and accommodate their needs. Duke Smarthome programvi - Duke University’s dynamic "living laboratory" environment that contributes to the innovation and demonstration of future residential building technology. The central concept of this project is the belief that Smart Homes can improve that quality of life for people of all ages and incomes. Aware Home Research Initiative (AHRI)vii – An interdisciplinary research project at Georgia Tech aimed at addressing the fundamental technical, design, and social challenges presented by such questions by using off-the-shelf and state-of-the-art technologies. CENELEC SmartHouseviii - Funded by the European Committee for Electro Technical Standardization (CENELEC), the aim of this project is to grow and sustain convergence and interoperability of systems, services and devices that will provide citizens with access to increased functionality, accessibility, reliability and security that a SmartHouse, with common and open architectures, can deliver. Recently, CENELEC has also released a European Code of Practice for SmartHouse operation. 15
Project Domus: Designing Effective Smart Home Systems
3. Research This chapter provides details about the main elements that compose a Smart Home system and gives an overview of the most important home network protocols. It also attempts to define a possible market for the technology, outlining the potential benefits and concerns emerged from recent researches.
Finally, it provides some design
challenges that needs to be considered when designing a Smart Home.
3.1. Components of a Smart Home System 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 user’s 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
Project Domus: Designing Effective Smart Home Systems
Figure 4 Sensor and Actuator Interaction
3.1.1. Control Systems 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
Project Domus: Designing Effective Smart Home Systems smart picture frames, which display user’s images in rotation updated in real-time; smart mirrors2 that can display the news and remind the user of today’s appointments while brushing the teeth; smart tables, which incorporate a touch screen that allow users to display and edit documents stored in file servers accessed via the home network; smart pillow, which can read a book, or play the user’s favourite music when they detect that their user is drifting into sleep. 3.1.3. Home Network Smart Home network technology can be subdivided into three main areas, depending on the communication media used: Powerline, Busline, and Wireless. Powerline systems plug in directly to the house electrical network (electrical mains) and do not require additional cabling. This technology is the oldest of the three and, though simple to configure and cheaper than other solutions, it may lack scalability and considered the least reliable due to its susceptibility to electrical interferences. Some of the earlier protocols support one-way communication, which allows devices to receive information but not to communicate. Busline systems use a separate media to send/receive signals, usually twisted-pair cabling, which is similar to the cables adopted for phone or network services. Albeit being more expensive to install, especially when retro-fitting existing houses, the use of a separate cable provides a positive note as it makes this technology the most reliable of the three and can provide higher bandwidth. Components based on this technology are usually more complex to configure and require some knowledge of networking. Finally, thanks to the dedicated media, this technology usually provides a completed two-way communication protocol so that connected devices can communicate with each other. Wireless systems do not require any wires to operate. This technology can be further subdivided into Radio Frequency (RF), and Infrared (IR). It is the most recent of the three and is increasingly becoming more popular as costs per unit decrease. Solutions based on this technology are usually very easy to install and configure and can combine most of the benefits offered by Busline technology, such as two-way communication and scalability, though with a relatively lower bandwidth. However, similarly to
2
See: http://gizmodo.com/gadgets/gadgets/touchscreen-smart-mirror-widgets-in-the-mirror-246384.php
18
Project Domus: Designing Effective Smart Home Systems Powerline, this technology can be prone to interferences, though the existence of twoway communication can address it by implementing acknowledgment of commands received and error checking/recovery mechanisms. Finally, due to its wireless nature, this technology introduces some privacy concerns as unauthorized access can be gained without even the need to be in the house. Some of the most recent protocols have tried to address this issue by introduced data encryption and authentication mechanisms. However, this also adds to the communication overhead, thus decreasing the bandwidth available, and make systems based on this technology more complex to configure and manage.
3.2. Communication Protocols This section provides an overview of some the most important communication protocols for home networks available today.
Some of the protocols listed are
proprietary, that is, details are not disclosed to the public. Others are owned and maintained by a company or consortium but openly made available. Finally, some of these are also recognized standards, that is, acknowledged by nationally or internationally accredited bodies. 3.2.1. X10 and its Legacy 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
Project Domus: Designing Effective Smart Home Systems on how X10 communicates. The X10 signal is sent when the voltage value crosses zero, which happens twice at every current cycle. Virtually all other Powerline home communication protocols use a variation of this method.
Figure 5 X10 Zero-Crossing Signal Transmission
In spite of its limitations, and thanks to the low installation costs and its ease of use, X10 is still widely used today by DYI enthusiasts, especially in the US, where a multitude of off-the-shelf components are readily available.
However, due to the
differences between the US (120V/60HZ) and European (220V/50HZ) power lines, devices built for the US market will not work in Europe. In more recent years, this technology made a comeback due to the fact that the patent for the protocol expired in late 1990s, and several forums on the Internet now can provide resources for anyone interested in investigating this technology. A wireless version of this protocol which offers limited two-way communication seem to exist but, besides being called X10, it might have little to do with the original Powerline technology. After the original idea first implemented by X10, several other protocols have emerged using the same concepts, sometimes enhancing the original specifications, such as implementing two-way communication, providing support for more devices and different types of media. The communication protocols listed below are an example of the most known. INSTEON derives directly from X10, for which is backward compatible. It is a proprietary protocol developed by SmartLabs, Inc.ix and can use electrical power lines or wireless.
It offers two-way communication where the controlled devices also
function as repeaters for the messages to increase reliability. Powerline Control Bus (PLCBUS) is a proprietary, two-way communications technology developed by ShangHai Super Smart Electronics Co. Ltd.x. Differently from X10, it can support up to 64,000 devices. 20
Project Domus: Designing Effective Smart Home Systems CEBus, the Consumer Electronic bus (CEBus) protocol, also known as EIA-600, is by some considered the US standard for home networking. It was first released in 1992 with the intent of expanding the capability of X10.
It is an open architecture and is
outlined by a set of specification documents which define details for communicating through power lines, twisted-pair cables, wireless, and others media. Universal Powerline Bus (UPB) was released in 1999 by PCS Powerline Systemsxi of Northridge, California (USA). Reportedly, it features an improved transmission rate and higher reliability than X10, due to the different method used in transmitting the electrical pulses. 3.2.2. Other Protocols Konnex (KNX) is a standard (EN 50090, ISO/IEC 14543), OSI-based network communications protocol for home automation. It is the result of a convergence of three existing European standards: the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus (EIB). In contrast with other similar technologies, KNX defines several possible physical communication media and it is designed to be independent of any particular hardware platform. The KNX standard is administered by the Konnex Associationxii. LonWorks, similarly to KNX, is a networking platform which specifies both the communication protocol and the hardware required by it. Developed by Echelon Corporationxiii in conjunction with Motorola in the early 1990s it supports a variety of communication media, such as twisted pair, power lines, fiber optics, and RF. It has established itself as a de-facto standard for building control and automation. In 1999, the communications protocol was submitted to ANSI and accepted as a standard for control networking (ANSI/CEA-709.1-B). C-Bus is a proprietary protocol created by Clipsalxiv for use with its brand of home automation and building lighting control system. C-Bus requires Ethernet-network like Cat 5 Unshielded Twisted Pair (UTP) cables, though a two-way wireless version also exists. This system is primarily used in Australia (e.g. Sydney Opera House) and in Asia, but it is becoming more known in Europe as well. Universal Plug and Play (UpnP) protocol is actually a set of protocols promulgated by the UPnP Forumxv. The goals of UPnP are to allow devices to connect seamlessly in order to simplify the implementation of networks in the home. Its control protocol is 21
Project Domus: Designing Effective Smart Home Systems based upon an open architecture based on established standards such as TCP/IP, UDP, HTTP and XML. However, this protocol is not an officially recognized IETF or IEEE standard and may not be supported by many networking devices. Zigbee is the name of a specification for a suite of communication protocols that use RF as their transmission media. Based on the IEEE 802.15.4-2006 standard for wireless personal area networks (WPANs), the standard is maintained by the ZigBee Alliance Groupxvi. For non-commercial purposes, protocol specifications are available free to the general public. Z-Wave, smilarly to ZigBee, Z-Wave is a communications standard based on wireless communication. The technology is developed and maintained by Zensysxvii, a Denmarkbased company. The Z-Wave Alliance is an international consortium of manufacturers that oversees interoperability between Z-Wave products and enabled devices. This protocol is a mesh networking technology where each node or device on the network capable of sending and receiving control commands. Devices can work as stand alone or in groups, and can be programmed into sequences (called “scenes” or “events”) that trigger multiple devices, either automatically or via remote control. BACNetxviii is an acronym for Building Automation and Control Network.
This
communication protocol was developed by the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) in conjunction with building management organizations, system users, and building system manufacturers. BACNet standard was officially ratified in 1995 as ANSI/ASHRAE 135-1995 and it is advertised as an open protocol which could be applied to any type of systems, such as Heating, Ventilating and Air Conditioning (HVAC) systems, lighting, life safety, access control, transportation, and maintenance systems. It can use a wide range of network technologies for communication. Modbus is a communication protocol that was developed in the 1970s by Modicon, Inc. for use in industrial automation systems with programmable logic controller (PLC) devices. Reportedly, it is one of the most widely used communication protocol for connecting electronic equipment in industrial settings. In 2004, the standard was transferred to Modbus-IDAxix, a non-profit organization made up of users and suppliers of automation devices primarily in manufacturing.
22
Project Domus: Designing Effective Smart Home Systems
3.3. The Market for Smart Homes 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 Roger’s Technology Adoption Lifecycle.
Figure 6 Roger’s Technology Adoption Lifecycle3
A survey carried out for the UK-based Joseph Rowntree Foundation in 2000 reported that we may be very close to a change of attitude whereby Smart Home technologies may soon become more popular and widespread. According to the research, 59 per cent of the people interviewed stated their interest for a technology that would save time and effort in their home, though it also outlined concerns about how complicate this technology might still be to operate (46%). As perhaps expected, the demographics outlined that young people would be more in favour of such technology than elderly people, due their degree of familiarity with game console and computers (Pragnell et al., 2000). However, this generation will soon become the decision-maker for these systems in the near future. A similar study identifies other types of users who could benefit from this technology. The relatively recent concept of teleworking opens new opportunities for executives
3
Courtesy of Wikipedia: http://en.wikipedia.org/wiki/File:DiffusionOfInnovation.png
23
Project Domus: Designing Effective Smart Home Systems and professionals to work from home. These individuals will spend more time at home and may be more interested in taking advantage of the potential benefits that this technology can offer. Moreover, as population in the western world becomes older, households with members over 65 will substantially rise in the next years. Another research reported how the installation of digital control and communication systems, as part of a fully integrated Smart Home system, can enhance important health and support services, improve independence, and overcome isolation for this category of people (Gann et al., 1999). Finally, another research points out that busy households, that is a family with children and both parents working, could themselves become adopter of Smart Home services. Dual-income families represent already almost half of the total in the US and these families often live a very structured life with almost no un-scheduled time.
The
potential time-saving features that a Smart Home can provide will help to maintain a sense of control and relieve some of the stress associated with running the household (Kyung Lee et al., 2008). 3.3.1. Potential Benefits Although features offered by a Smart Home may vary, an effective implementation can bring several potential benefits. Children’s 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
Project Domus: Designing Effective Smart Home Systems humidity based on the information received by thermometers and humidity sensors located inside and outside the house (Greyson, 1991). Modern technology is already changing the home as an increasingly larger number of appliances come with embedded computing capabilities. Smart Homes of the future will be able to integrate all heating, air conditioning, lighting, home entertainment, and security systems together.
Although safety, security, and centralized control are
currently what potential users expressed as the most interesting (Pragnell et al., 2000), the result of this integration, combined with modern networking technology, will open new possibilities and the creation of additional services that might not exist today. Table 1 represents possible areas where Smart Home technology can already help today (Green et al., 2004).
Table 1 Examples of Smart Home Applications AREA
EXAMPLES
Welfare
Health and monitoring; remote diagnosis; remote personal trainer.
Entertainment
Music television and video downloading.
Environment
Remote control of lighting, heating/air-conditioning; energy usage and costs.
Safety
Alerting of problems e.g. gas leaks, CO.
Communication
Video phone; calendar reminders; communication inside and outside home.
Appliances
Self-diagnosis or problems and assistance in their operations; automated food ordering.
Linking the home network to the outside world via the Internet connection opens up the possibility for the a Smart Home to also be managed remotely, e.g. when at work or away on holiday. This option could also be extended to authorized third parties, such as electricity or gas utilities, who can run routine maintenance or troubleshooting tasks remotely or on behalf of the house owner. Studies demonstrated how mobile phones and Short Message Service (SMS) messages have become a popular way to keep in touch and how this can increase the sense of safety and connectedness among family members (Harper, 2003). These benefits may be further expanded by integrating this mobile communication network, now composed also by other devices such as Personal Digital Assistance (PDA) and hand-held 25
Project Domus: Designing Effective Smart Home Systems computers, with components of Smart Home systems and with the Internet itself. For example, family members may be able to leave notes to each other and making or changing appointments with ease. According to the same study, this network society will enable always-on, real-time communication, bring people closer, and could concretely add to family communication as a means of organizing daily living as Smart Home might become: “the gate to a new kind of collectivity” (Harper, 2003). Finally, Smart Home technology can increase the quality and facilitate the life of elderly people or people with disabilities. Today’s digital controls and communication systems can already allow enable health and support services personnel (telecarer) to carry out routine diagnostics, monitoring and basic services whilst allowing the person to remain comfortably at home. 3.3.2. Reported Needs and Concerns The same researches carried out on Smart Home technologies also raised some concerns. Regardless of the technical edge provided by one particular technology over another, addressing such concerns will play a pivotal role to ensure the buy-in to the Smart Home concept by the majority of consumer market. The survey carried out in 2000 for the Joseph Rowntree Foundation (UK) unveiled some interesting findings, where the most significant concerns were the fear of technical issues that would cause the system to stop functioning or perform unintended (unwanted?) operations, and users who may be intimidated by a system too complex to be used effectively or who would be unable to take back control of the system (Pragnell et al., 2000). Similar findings were outlined by a 2002’s survey carried out by the Digital Media Institute of Tampere University of Technology (Finland). In addition, the research showed that people are traditional when it comes to their daily routines and working on household chores and might at times decide to carry out these tasks themselves. Furthermore, people will have different opinions on what is enjoyable and what is not: for example, a person might like to cook but hates dusting, another might hate ironing but likes hovering so the system should be able to cope with these preferences too. Finally, although basic daily routines may be the same across households, the way to perform them may vary from household to household and from individual to individual (Koshela et al., 2004). 26
Project Domus: Designing Effective Smart Home Systems Often, people’s vision of technology is tainted by reservations and fears, not only in science fiction movies’ terms, such as that the house might start “living a life of its own”, but also a concern connected to very real situations, such as not being able to turn a device off. Smart Home systems encompass complex socio-cultural aspects that strongly relate with the concept of home and, as such, can evoke strong feelings and emotions. It is also interesting to note how some participants feared that technology would actually reduce the amount of communication, though it was acknowledged at the same time that communication between family members has improved with the usage of mobile phones. Other concerns identified were the worry of being constantly “on line” and general security issues, with one of the participants being worried about the possibility of their microwave being operated by an outsider without them knowing about it (Harper, 2003). The use of this technology also raises many ethical questions, such as how to protect the privacy for such items as remote access and allowed level of surveillance for telecarer. (Gann et al., 1999). Another research conducted in 2003 in US and Korea outlined the importance for a new technology to be compatible with existing devices, to be customizable, and provide improvements on communication methods (e.g. support for wireless technology). Accessibility features and centralized entertainment resources were also being of high interest, though dedicated devices for stand-alone appliances were preferred to multifunction devices controlling several of them (Chung et al., 2003). A research conducted in 2004 outlined the following themes as being the major concerns for the participants: costs, system reliability, security and privacy concerns, ease of use, flexibility, convenience, maintaining independence, expandability with future technologies, and ability for the users to take control when required (Green et al., 2004). Finally, the research conducted by Tampere University of Technology in 2004, which also prototyped different user interfaces, reported the appreciation of having a mobile device when interacting with the system rather than a fixed one, such as the TV set. From this study, further requirements emerged, such as having a way to record predefined actions at a certain time and day in advance (pattern control), whilst at the same time provide users with the ability to act on a device immediately (instant 27
Project Domus: Designing Effective Smart Home Systems control). The study also highlighted the confusion that might occur when multiple users operate the same device, e.g. a light, or that a user might not be aware of a pattern control set by another user (Koskela et al., 2004) Finally, the nature of the home is quite dynamic and the type, level of information and interaction required by its inhabitants change throughout the day (Chung et al., 2003). Smart Home systems will need to maintain a profile of its users in order to keep track of their needs, preferences, and how these can change throughout time.
3.4. Design Challenges 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, today’s situation does not seem to have improved significantly in any of these areas: •
Poor understanding of user needs
•
Users’ lack of understanding about potential benefits
•
Difficulties in installing and integrating solutions into existing households
•
Immature technology, causing defects, rapid obsolescence and upgradeability issues
•
Costs.
Whilst some of these design challenges are beyond the scope of this project, others can be investigated and expanded further in this paper. For example, it is certainly possible to gain a better understanding of the users’ needs and, by doing so, have a better chance to develop solutions that are “useful, usable, and used” (Dix et al., 2004). Furthermore, it may be possible to choose technologies that are more reliable, less disruptive, more supported and upgradeable than others and that should provide a better chance to be a sound investment from the users’ point of view.
28
Project Domus: Designing Effective Smart Home Systems 3.4.1. Gathering Valid System Requirements The true potential of Smart Homes can only be unleashed with a user-centric approach. One of the challenges often reported by the current literature on the subject is that designers of Smart Home solutions seem to be more focused on the technical part of the solution and often ignore what customers might actually want the product to do.
In
some cases, this resulted in making available technically valid products for which very few customers were interested in. The techniques described in this section can help bridge this gap and will be used later on when documenting the system requirements for this project as gathering unambiguous and detailed software requirements is a vital part of any software development endeavour. K. Wiegers (2003) states that not dedicating enough time to properly document requirements for a system usually leads to at least one of the following: •
Unusable product
•
Poor product quality
•
Dissatisfied customers
•
Wasted time and rework
•
Project overruns (time, costs)
•
Gold-plating (adding of unnecessary features)
Wiegers suggests that software requirements
can be subdivided into three main
sections: user requirements, business requirements, and functional requirements. Figure 7 provides a visual representation of the major components of all system requirements and their relations (Wiegers, 2003).
29
Project Domus: Designing Effective Smart Home Systems
Figure 7 Components of Software Requirements
Business requirements are documented in the vision and scope document of the project, whilst functional requirements are usually formally recorded in software requirements specification (SRS) documents. These formal documents describe, in as much detail as possible, the expected behavior of the system and often also outline non-functional requirements such expected quality standards, regulations and other constraints. User requirements, sometimes also called Voice of the Customer, describe the system as a set of tasks that the user must be able to accomplish with the product. Unfortunately, gathering these requirements is seldom an activity that will result in a well-ordered list of detailed needs and it will often require refining steps and subdividing the input provided into different categories as a better understanding is gained. Table 2 outlines how the Voice of the Customer can be further subdivided into nine requirement categories and provides a brief description of each one (Wiegers, 2003). These requirements are documented, expanded, and confirmed using Use Case diagrams, which describe a single instance of usage of the system and outline the relationship between users (actors) and tasks (use cases) to be performed. Table 2 Classifying the Voice of the Customer Business Requirements
Any business benefit that either customers or the developing organization wish to gain from the product.
Use Cases
General statements of user goals or business tasks that users
30
Project Domus: Designing Effective Smart Home Systems need to perform. Business Rules
Rules that states which users can perform a specific activity and under which specific conditions. These rules will need to be captured in the software functional requirements and enforced by the system. Access control is a typical business rule in most of computer systems.
Functional Requirements
Description of observable behaviors that the system will exhibit under certain conditions and descriptions of actions the system will let users take. They are derived from system requirements, user requirements, business rules, and other sources.
Quality Attributes
Qualitative statements are modifiers that will indicate how a task needs to be performed. Some examples of these statements are: fast, easy, intuitive, user-friendly, robust, reliable, secure, and efficient.
External Interface Requirements
How the system needs to connect to other systems or, generally, to the outside world.
Constraints
Constraints restrict the options available to the developer. For example, constraints such as size, weight, and interface connections.
Data Definitions
The format, data type, allowed values, or default value for a data These requirements are usually collected in a data dictionary that will serve as reference for the project team.
Solution Ideas
A description of a desired way to interact with the system to perform a particular task. Most of user requirements usually fit in this category.
The list below, again adapted from K. Wiegers (2003), defines the major steps that should be carried when documenting requirements for a software project: 1. Identify Business Requirements 2. Identify users of the software 3. Gather User Requirements 4. Define Use Case scenarios 5. Gather Functional Requirements 6. Subdivide system-level requirements into major subsystems and match requirements to software components 7. Define implementation priorities 8. Review use cases against original requirements to ensure correctness.
31
Project Domus: Designing Effective Smart Home Systems In addition to this, contrarily to the typical software design where the user base can be quite homogenous, users of a Smart Home are far less so, ranging from children, to adults, to elderly people. This poses the challenge to define a user interface that can be versatile enough to be effective with every user of the system. (Ringbauer et al., 2003). In order to better address this, one of the techniques that can be used is the creation of different personas, i.e. virtual users, to try and represent these differences. Most of the times, personas take the form of fictional characters, who are though provided with enough real-life details so that developers will be able to relate to them when discussing a particular requirement or feature of the product – e.g. “John would never use that feature this way”. Using personas will also increase the developers’ connection with a real user, instead of abstractions, while designing the system (Courage & Baxter, 2005). 3.4.2. Choosing the Right Technology Advancements in networking in 1980s and 1990s allowed home computer networks to become a reality. However, though several alternatives emerged, none of these have yet managed to establish themselves as de-facto standards in the industry. This has affected the consumer industry, which had been delaying the adoption of Smart Home-enabling technology in their products, worrying that they may invest in the wrong technology. Already, some of these network protocols have since been abandoned due to lack of profitability. From the end-user’s point of view too, as the home network is a vital part of any Smart Home solutions, the risk is that by siding with the wrong technology you would soon end up with a system that might no longer be expandable or even supported tomorrow. The good news is that these concerns are starting to be addressed as consolidation seems to be occurring, at least in Europe and some major players are emerging. Konnex (KNX), for example, represents the convergence of three previous European standards: the European Home Systems Protocol (EHS), BatiBUS, and the European Installation Bus (EIB). These consolidation efforts will create viable platforms that can then be picked by producers of electronic and electrical home appliances to introduce smart features in their devices (Wacks, 2002). With a proper economy of scale, development and implementation costs should also be driven down, making these solutions more appealing to consumers.
32
Project Domus: Designing Effective Smart Home Systems The building industry is part of this challenge too.
As very few new residential
dwellings are built to natively support the Smart Home, e.g. by installing twister-pair cabling, most of today’s Smart Home systems will be installed in existing houses. In order to ensure ease of installation and minimize costs, it will not be feasible for the average user to run new cabling that would support a twisted-pair home network. By excluding Busline technology, Smart Homes will need to be implemented with either Wireless or Powerline communication. As Wireless is still expensive, Powerline, that is technology that use of the existing electrical network to operate, seems the only truly viable alternative. The issue here is that most of the protocols that use this type of communication are quite old, can be unreliable, and are quite limited in terms of bandwidth.
Some of the drawbacks of X10, the most common Powerline
communication protocol, have been outlined by a recent research: sluggish response times – especially over longer distances, bandwidth limitations, the increase in costs due to need of amplifiers and filters required to boost reliability, lack of connection to external network resources, and performance impact in electrically noisy environments (Chunduru & Subramanian, 2006). Concluding, although it seems that when choosing the communication protocol for a Smart Home solution, there are several alternatives, when these are evaluated against parameters such as ease of integration, reliability, support, compatibility, long-term investment, and, ultimately, costs, these options may become fewer. 3.4.3. The Quest for the Effective User Interface Human-Computer Interaction (HCI) is a technical field that studies the interactions and the relationships between humans and computers (Fischer, 2001). Most of the HCI research can employ several years before it materializes into an available off-the-shelf product. The idea behind today’s point-and-click graphical interfaces was first demonstrated in 1963, while, at around the same time, Douglas C. Engelbart was developing the first mouse at Stanford Research Laboratory, carved in wood and initially intended to be a cheaper replacement for light pens. Commercial systems that used direct manipulation of objects using the concept of a “desktop” were not available since the 1980s, with the Xerox Star (1981) and the Apple Lisa the following year (Myers et al. 1998, Dix et al., 2004).
33
Project Domus: Designing Effective Smart Home Systems Recently, the HCI focus has shifted from studying computer interfaces into the way people use computers in a more general sense; that is, how people and computers can collaborate together to achieve the user’s goal. One of main areas of HCI research is about the concept of usability of systems, which can be approached from two perspectives. The early area of focus was the emulation approach, where the computer is programmed to exhibit “human-like” abilities, e.g. computers greeting their user with “How can I help you today?”. More recently, the research shifted towards exploring a complementing approach, which can better leverage on the difference between humans and computers and can open up to new interaction and collaboration possibilities (Fischer, 2001). Usability requirements are influenced by the complexity of the system being designed. An Automated Teller Machine (ATM) is an example of a simple system with a few basic functions and which needs to be understood by users with little or no prior knowledge of the system. At the other end of the spectrum, a high-functionality application (HFA) is a complex system that requires users to learn the intricacies of its interface and functionalities before they can become proficient with it. However, HFAs can perform a richer variety of functions than simple applications, hence they can assist users with resolving more complex problems. An example of a HFA is Adobe PhotoShop™, the leading application for editing digital images, which literally contains hundreds of functions, each one with several settings and subtle nuances. In today’s applications, there seem to be an inversed proportion between the usefulness of a system (i.e. its complexity), and its usability (i.e. how user-friendly the user interface is). However, as costs of hardware keep falling, cognitive costs, that is the costs involved in learning a system, will represent an increasingly higher part of the total cost of ownership (TCO). This calls for proper HCI techniques that will help maintaining an appropriate level of usability whilst providing the ability of adding more features. When dealing with usability of a system, developers of user interfaces will need to make generic assumptions about the user’s knowledge in order to find the right balance between beginner and expert users and reach a compromise that can work with both these extremes. The challenge is that, when making this choice, there is always a risk to either leave novice users without the required help or to create a system that gets in the way more than the necessary with more experienced user.
34
Project Domus: Designing Effective Smart Home Systems Today’s Windows, Icons, Menus and Pointers (WIMP) interfaces have exacerbated this challenge even further (Dix et al., 2004). Older, text-based interfaces provided a clear, explicit communication channel between user and the machine. Where the user was presented with a prompt they could enter only one command at any time and this command was to be picked from a well-defined list constrained by the current context. Modern multi-modal graphical interfaces allow users to impart instructions via multiple input devices (e.g. a keyboard and a mouse) in a less constrained sequence and within a wider context. This new level of interaction has created the possibility for multiple implicit communication channels. This extra level of complexity often requires the system (and developers) to gain a wider understanding of multiple areas: •
User’s knowledge of the system
•
User’s goals and how they can be mapped against the system’s primitive operations
•
Understanding of the communication processes and which communication channel is more appropriate to use in relation to the above
•
Instructional strategies, based on pedagogical theories that can exploit the knowledge contained in the system to the benefit of the user.
Figure 8 provides a graphical representation of implicit and explicit channels (Fischer, 2001).
Figure 8 Implicit and Explicit Communication Channels
35
Project Domus: Designing Effective Smart Home Systems In truth, recent progresses in this area have made systems easier to learn and to interact with: context-sensitive help systems, today present in almost the totality of systems, is a direct product of this research. The challenge here is to be able to infer correctly what tasks will actualize the user’s goal without being intrusive. For example, potential users of a Smart Home system tend to assume that such system should have voice recognition capabilities but natural speech interfaces are still far from perfect and still cause unintended operations (Koskela et al., 2004). Future success of new computer systems will be less judged on factors such as processing speed or the amount of memory available and more on the ability to interact effectively with users, regardless of their current knowledge of the system. 3.4.4. The Role of Artificial Intelligence As per other computer systems, the factors that will influence the success of a Smart Home product are not purely technical. The challenge lies in how to make an intuitive system powerful yet still intuitive to use in order to provide real value for its users. Artificial Intelligence (AI) techniques can provide a positive contribution towards resolving such challenges. To successfully resolve the speech recognition problem presented in the previous section, for example, will require systems with the ability to provide syntactic analysis, semantic recognition, along with some pragmatic analysis (Greyson, 1991). Moreover, Smart Home system will need to be able to adapt to a changing environment and to multiple users. In this context, the best user interface is the one that requires the least amount of user interaction; that is, the system should be able to correctly understand the user’s need using a probabilistic approach coupled with other factors such as knowledge of past events and user’s preferences. With this knowledge, a Smart Home system will then be able to perform some of the required tasks autonomously. An AI field of research that can work towards this goal is the studies done on Bayesian Networks. Bayesian Networks (BN), also known as belief networks, knowledge maps or probabilistic causal networks, provide a method of reasoning using probabilities and have already been applied successfully to problems in medical diagnosis, whose results are often more accurate than an expert diagnosis (Charniak, 1991). A BN tree is a graphical representations of probabilistic relationships among variables of a system that may influence the probability for a given event to occur. It represents a graph which 36
Project Domus: Designing Effective Smart Home Systems includes a set of nodes, representing the variables, connecting lines (edges or arcs), which display their inter-relations between hypothesis and variables, and associated probability values for all the edges. By using this method, one can reason and calculate the likelihood for an event to occur. E. Charniak (1991) illustrates a BN with a simple example: we want to know whether our family is home when deciding what door to use when enter the house. For argument’s sake, let us say that the most convenient door would be doubly locked if nobody is home. Since this door will require more fumbling with its keys in order to be opened, we may decide to go for the other one instead, once we have sufficient reason to believe that this would indeed be the case. The BN tree will use the expert knowledge embedded in the relationships among the nodes to calculate the likelihood of the family being out. So, if nobody is home, the dog is usually put out in the backyard and the porch light is usually turned on. If the dog is out, we would know it because we could hear its barking. However, when the dog has bowel problems, it will also be put out. The BN provides a way to weigh these variables and determine the likelihood of the family being out. Figure 9 provides a graphical representation of the sentences given above in the form of a causal graph (Charniak, 1991). From this graph, we can draw the following general hypothesis: if dog-out and light-on then family-out is likely to be true. However, if dogout the bowel-problem hypothesis could also be true. The arcs in the BN tree will tell what nodes (also called variables) influence others. In this case, the dog-out node is said to have a direct causal connection on hear-bark so that, if hear-bark is true, then dog-out is more likely to be true. However, if light-on is true, it will tell us nothing more about dog-out as these variables do not have a direct causal connection between each other. Furthermore, light-on will not influence the likelihood of the bowel-problem event in any way.
37
Project Domus: Designing Effective Smart Home Systems
Figure 9 Causal Graph
It is important to understand that BN cannot provide absolutes but always return a degree of confidence (probability) for the given hypothesis.
To refer back to the
example, the family might sometimes forget to turn on the porch light or to leave the dog out when leaving the house. Figure 10 expands the causal graph by adding the probability values given for all the BN nodes. These values are usually gathered by direct observation, from historical data (also known as cases) or from information gathered via expert knowledge. So, let us say that when the family leaves the house, someone remembers to turn the porch light most of the times (60%), but that there is a smaller (5%) chance that the light is on even when people are in the house, say when a guest is expected. The first is represented as P(lo|fo)=0.6, which reads: the likelihood (P) that light-on (lo) and family-out (fo) equals to 60% (0.6). Conversely, the second case is represented by P(lo|¬fo)=0.05; that is, the likelihood (P) that light-on (lo) but not family-out (fo) equals to 5% (0.05). Once all the probabilities are provided, the BN tree is used to validate the hypothesis for which is was created (e.g. to resolve the family-out scenario).
38
Project Domus: Designing Effective Smart Home Systems
Figure 10 Bayesian Network
A practical example of how BN can be used to infer the user’s goal is Project Lumiére. Started in 1993 by Microsoft Research Labs, the project investigated how BN trees could be used to help users of a computer system. The model built tried to infer a user’s goals based on their past and current actions and on their supposed knowledge of the system. The system would then propose tasks that should have helped the user to reach his/her goal.
A short videoxx, available from Microsoft, shows a live
demonstration of the prototype. The findings of this project were eventually used to develop the Office Assistant in the Microsoft Office 97 suite (Horvitz et al., 1998). Smart Home systems can benefit from BN models. For example, a reasoning framework will greatly facilitate any event-condition-action scenario that contains uncertain or incomplete knowledge (Dimitrov et al., 2007). A problem domain where BN models can be employed is the detection of a dangerous situations.
Such a
probabilistic model would be able to identify anomalous or dangerous situations, e.g. a person falling, by continuously gathering evidence considering whether the information increases the likelihood of the event beyond a threshold that would trigger the alarm (Cucchiara et al., 2003). 3.4.5. Going Beyond Home Automation Very few of today’s off-the-shelf products go much farther than providing basic home automation functionalities. Despite the abundance of electrical and electronic devices, little effort has been placed to try and connect these devices in a meaningful way that will add value to the users. The number of remote controls that are still required today in an average home media center would serve a good example for such lack of integration. However, an effective Smart Home should also be able to infer the goal 39
Project Domus: Designing Effective Smart Home Systems intended by the user and to carry out (or propose to the user) tasks that will help reaching the goal, thus adding value from a user’s point of view. Smart Homes can successfully implement the idea of ubiquitous computing. Earlier definitions of ubiquitous computing simply focused on making devices so small to be hidden from the user’s view, what is called perceptual visibility. Rather than merely focusing on size alone, a more recent definition of ubiquitous computing outlines the computer’s ability to become integrated with the user’s goal as to being used without the user being aware of it (Dunlop & Brewster, 2002). An effective area where Smart Home systems can help is in supporting the household’s daily routines. The MerriamWebster English dictionary defines routines as “habitual or mechanical performance of an established procedure”. So daily chores are deeply unremarkable and accomplished almost automatically by the individual. The challenge is to ensure that the introduction of computing abilities will not disrupt this routine and will not force users to bring this automatism to the foreground. Finally, Smart Homes may need to move beyond the simple detection of an action towards a truer understanding of the action’s significance from the user’s point of view – what is called user semantics. A research outlined by Peter Tolmie, of Xerox Research Center in Grenoble provides results of a research where, for example, the knocking on a front door (action), called for two distinct courses of action (significance), which depended on the meaning given to the action by the actors involved. Focusing upon the action alone only enables a surface interpretation of what is going on and might not allow for the most appropriate response. Effective Smart Home systems will need to go beyond detecting the actual action performed and try to contextualize it into the possible significance attributed to it by the user. As a final point, experts caution developers to be careful when adding features to familiar objects as this might change the user semantics, regardless of how useful or easy to learn the new function is thought to be (Harper, 2003).
40
Project Domus: Designing Effective Smart Home Systems
4. Development This chapter outlines the development of a Smart Home system. The Analysis section will document the system requirements for a complete Smart Home system based on the information gathered by the Research, whilst the Implementation section will focus on the development of a Proof-of-Concept (POC) system. The system that will be developed is a Temperature Control System, envisaged as a subset of a full Smart Home system. In addition to the usual features present in such systems, the POC will also implement a Bayesian Network that can help the Fire Alarm sub-system to determine the likelihood of a fire. Note that, while the analysis will be carried out for the complete system, only a sub-set of this will be developed further into the POC.
4.1. Analysis This section will outline the system requirements for the Smart Home system. As no real end user was available to gather the necessary input on the user requirements, an attempt was made to identify the user profile and such requirements by considering the findings outlined by a survey reported by M. Pragnell in “The market potential for Smart Homes” (2000). 4.1.1. Business Requirements This section outlines the high-level objectives of the project.
As documented in
Chapter 1, the aim of this project is to develop a POC system that addresses some of the challenges emerged during the research. This statement will therefore define the vision and scope. The reason why this project is being carried out is two-fold: •
To contribute to the existing literature for Smart Home technologies
•
A as partial fulfilment of the requirements for the BSc in Information Systems and Information Technology (DT249) to the School of Computing. 4.1.2. Determining a User Profile
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
Project Domus: Designing Effective Smart Home Systems what type of consumers are the most interested in living in a Smart Home (Pragnell, 2000). According to the research, participants could be divided into three categories: the interested in Smart Home technologies (54%), the ambivalent (19%), and the uninterested (37%). In accordance with these findings, the following user profile can be defined: •
Family households
•
Aged 15 to 34
•
Technology savvy
•
Subscribed to external services
•
Own a home entertainment system
•
Have a Home Personal Computer
•
Have an always-on Internet connection at home.
The differences present in the user profile defined above might still require further clarification before the design phase can start. Should a full Smart Home system need to be built, developing different personas might help with this process. A persona could, for example, be created to identify an adult user of the system, whilst another one might define a typical teenager who might have very different goals and requirements than the former. As this project will design a Proof-of-Concept system, this step was not deemed necessary. 4.1.3. Gathering User Requirements 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
Project Domus: Designing Effective Smart Home Systems
Table 3 Defining User Input User Requirements
Categories
The system should save time and effort.
Business Requirements
The system should be easy and intuitive to use.
Quality Attributes
Users should be able to control devices in the home when away
Solution Ideas
from home. The system should integrate safety and security features.
Business Rules
Users should be able to control remotely everything in the home.
Use Cases
The system should be reliable.
Quality Attributes
Users should be able to override the system when required.
Functional Requirements
The system should be cost effective.
Business Requirements
The system should be capable of being installed in an existing
External Interface
home.
Requirements
Users should be able to decide what task to be done automatically
Use Cases
and what to carry out themselves and to change the decision at any time. Users should be able to manually control any devices.
Use Cases
The system should prevent unauthorized access.
Quality Attributes
The system should include means to protect the household’s
Functional Requirements
privacy. The system should be customizable.
Quality Attributes
The system should be compatible with existing technologies.
Quality Attributes
The system should be expandable and support newer
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
The system should be able to resolve conflicting commands set for
Quality Attributes
the same device.
4.1.4. Use Case Diagrams This section outlines the Use Case diagrams that detail the most common actions performed in the system. 43
Project Domus: Designing Effective Smart Home Systems System Overview Figure 11 displays provide an overview of the main functions present in the system from a user’s point of view. It shows how a user issues a command or create a schedule for a command to be executed sometime in the future. The Use Case diagram also depicts how a control agent in the system evaluates the command before passing it to the actuator, which in turn will execute it. Furthermore, the diagram shows how a sensor communicates with the system and how an inference engine that can assist with the decision process by suggesting actions based on the data provided by one or more sensors and past events saved in the database.
Figure 11 System Overview
4.1.5. Functional Requirements 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
Project Domus: Designing Effective Smart Home Systems •
Stimulus/Response Sequence: sequences of input stimuli (user actions, signals from external devices, or other triggers) and system responses that define the behaviours for this feature. When appropriate, this will correspond to the initial dialog steps of use cases or to external system events.
•
Functional Requirements: detailed functional requirements associated with the system feature. This corresponds to capabilities that must be present in the system for the user to access the feature and perform a Use Case. It describes how the product should respond to anticipated error conditions and to invalid inputs and actions. Each functional requirement is uniquely numbered.
45
Project Domus: Designing Effective Smart Home Systems
Table 4 Functional Requirements ID
System Feature
Priority
Functional Requirement Details
FR-01
Support for Manual
Description: The system shall be able to release control of devices.
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
1
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
Description: The system shall provide appropriate feedback to the user.
User
Stimulus/Response Sequence: User to enter command to perform an immediate task; System to automatically 2
execute a deferred (scheduled) command. Functional Requirements: •
FR-02.1. The system shall provide feedback for a user request for an instant command within 3 seconds from the command being issued by the user.
Project Domus: Designing Effective Smart Home Systems
ID
System Feature
Priority
Functional Requirement Details •
FR-02.2. The system shall implement a means to record all instant command requests and their outcomes for later user retrieval and examination.
•
FR-02.3. If an instant command takes more than 3 seconds to complete, the system shall provide continuous feedback to the user who requested it until the command either returns with a OK/Failed result OR is aborted (cancelled) by the user.
•
FR-02.4. The system shall evaluate immediately information received by real-time sensors (e.g. intruder alert).
FR-03
Access Control
Description: The system shall employ means to protect the information present in the system.
and Data
Stimulus/Response Sequence: An un-authenticated user accesses the system.
Protection
Functional Requirements: •
FR-03.1. The system shall present a login screen comprised of username and passcode before allowing access to the system.
• 1
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
Project Domus: Designing Effective Smart Home Systems
ID
System Feature
Priority
Functional Requirement Details •
FR-03.9. The system shall allow only power users to delete existing users.
•
FR-03.10. For a user already logged in, the system shall request the user’s passcode again after the account has been idle for x number of minutes (configurable within user preferences).
FR-04
Ease of Use (1)
•
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.
Description: The system shall be ease to use. Stimulus/Response Sequence: User operates the system. Functional Requirements: •
FR-04.1. The system shall implement appropriate HCI methodologies for its User Interface.
•
FR-04.2. The system shall implement relevant industry-standard guidelines, depending on the actual user interface used (e.g. Microsoft Windows, Internet Browser, etc.)
•
1
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 user’s 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 User’s View of the
2
•
Description: The system shall provide a means to group devices together to create user-defined subsystems and enhance usability.
48
Project Domus: Designing Effective Smart Home Systems
ID
System Feature
Priority
System (1)
Functional Requirement Details •
Stimulus/Response Sequence: User wants to control devices together.
•
Functional Requirements:
•
FR-05.1. The system shall allow power users to create and name teams (groups of devices).
•
FR-05.2. The system shall allow users to control teams as a single device (e.g. turned on or off with a single command).
•
FR-05.3. The system shall make available all the methods (i.e. operations) in common with all the devices in present in a team.
•
FR-05.4. The system shall provide users with the option to disable or enable all the devices in a team with a single command.
•
FR-05.5. The system shall allow devices to be part of multiple teams.
•
FR-05.6. The system shall provide users with the option to disable all the devices in a team with a single command.
FR-06
Remote Access
Description: The system shall also be operated remotely.
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.
Description: The system shall implement features to improve its reliability. 2
Stimulus/Response Sequence: Internal or external events causes the system to stop operating. Functional Requirements:
49
Project Domus: Designing Effective Smart Home Systems
ID
System Feature
Priority
Functional Requirement Details •
FR-07.1. The system shall implement an internal mechanism to verify that a instant or deferred command has been successfully executed.
•
FR-07.2. The system shall be able to restart automatically after a mains power outage.
•
FR-07.3. The system shall monitor itself and be able to recover after a crash.
•
FR-07.4. The system shall provide a means to store operation issues for later examination.
•
FR-07.5. The system shall provide a means to store information about notification options to report issues.
•
FR-07.6. The system shall automatically notify designated users when normal functioning is resumed.
•
FR-07.7. When recovering from a power outage, the system shall ensure that all controlled devices be in sync with the last know configuration.
• FR-08
FR-07.8. The system shall ensure the integrity of the information stored.
Support User’s
Description: The system shall offer customizable features.
View of the
Stimulus/Response Sequence: User perform changes in the system.
System (2)
4
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
Description: The system shall be able to work within existing environment. Stimulus/Response Sequence: User installs the system in an existing environment. 3
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
Project Domus: Designing Effective Smart Home Systems
ID
System Feature
Priority
Functional Requirement Details •
FR-09.4. The system shall provide support for at least other two network protocols (e.g. RF/IF, Twisted Pair, etc.).
FR-10
Expandability
Description: The system shall allow users to add new devices. Stimulus/Response Sequence: User wants to add a new device to the system. Functional Requirements: 2
•
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
Description: The system shall be accessed from a 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.
3 •
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
Project Domus: Designing Effective Smart Home Systems
ID
System Feature
Priority
Functional Requirement Details •
FR-12.1. The system shall provide users with a means to schedule a task in the future for a device via the User Interface
•
FR-12.2. The system shall provide users with the option to repeat a scheduled task at a given interval (e.g. daily, weekly, monthly).
•
FR-12.3. The system shall provide the option to schedule tasks for a device or a team.
•
FR-12.4. The system shall allow only power users to add/edit/delete a schedule for a team.
•
FR-12.5. The system shall routinely scan the active schedule to see whether any actions need to be performed.
FR-13
Support for
Description: The system shall support multiple users.
Multiple Users
Stimulus/Response Sequence: User logs into the system. Functional Requirements: •
User Interface.
3
FR-14
Ease of Use (2)
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.
Description: The system shall be able to resolve command conflicts. 3
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
Project Domus: Designing Effective Smart Home Systems
ID
System Feature
Priority
Functional Requirement Details •
FR-14.1. The system shall provide users with a warning message when another user is already operating the same device (or team) and abort the last transaction.
•
FR-14.2. The system shall consider the team ownership (if available) when determining who has priority over a conflicting schedule and keep/accept the one issues by the team owner.
•
FR-14.3. The system shall allow team∆ managers to created closed teams to impede control of the devices present in the team by other users.
•
FR-14.4. The system shall still allow power users to control a closed team.
•
FR-14.5. The system shall allow team owners to re-open a closed teams to allow control to all users.
53
Project Domus: Designing Effective Smart Home Systems 4.1.6. Sub-system Identification This section provides a break-down of the system into the main components. Figure 12 provides a graphical representation of these sub-systems and Table 5 matches the Functional Requirements identified in the previous section.
Figure 12 Sub-Systems Overview
Command Dispatcher will be responsible for issuing commands to system actuators and to record the success/failure of a command. Device Manager will be responsible for adding editing and deleting devices in the system. Event Collector will be responsible for collecting information coming from sensors and either forwarding to the Flight Control or passing it to the Event Logger to be saved in the system database. Event Logger will be responsible for storing events occurring in the system. Flight Control will be the main module responsible for coordinating system actions and events. Inference Engine will be responsible to analyze the events stored in the Event Database and suggest course of actions to the Flight Control. System Scheduler will be responsible for checking active schedules and sending action requests to Flight Control. Team Manager will be responsible for maintaining the device teams existing in the system.
Project Domus: Designing Effective Smart Home Systems User Admin will be responsible for adding, editing and deleting users from the system. User Authenticator will be responsible for the authentication of local and remote users. User Interface will be responsible for interacting with the user (to collect input requests and provide the status of the system). Table 5 Functional Requirements grouped by Sub-system Sub-System
Functional Requirements
Command
FR-02.3. If an instant command takes more than 3 seconds to complete, the
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
FR-02.4. The system shall evaluate immediately information received by real-
Collector
time sensors (e.g. intruder alert).
Event Logger
FR-07. 4. The system shall provide a means to store operation issues for
55
Project Domus: Designing Effective Smart Home Systems
Sub-System
Functional Requirements later examination. FR-03.12. The system shall store command issued and confirmed system changes in an Event Log. FR-02.2. The system shall implement a means to record all instant command requests and their outcomes for later user retrieval and examination.
Flight Control
FR-07.1. The system shall implement an internal mechanism to verify that a instant or deferred command has been successfully executed. FR-07. 2. The system shall be able to restart automatically after a mains power outage. FR-07. 3. The system shall monitor itself and be able to recover after a crash. FR-07. 6. The system shall automatically notify designated users when normal functioning is resumed. FR-07. 7. When recovering from a power outage, the system shall ensure that all controlled devices be in sync with the last know configuration. FR-11.4. Mobile users shall not be able to perform admin (power user) tasks. FR-14.1. The system shall provide users with a warning message when another user is already operating the same device (or team) and abort the last transaction. FR-14.2. The system shall consider the team ownership (if available) when determining who has priority over a conflicting schedule and keep/accept the one issues by the team owner. FR-14.4. The system shall still allow power users to control a closed team. FR-07. 8. The system shall ensure the integrity of the information stored.
Inference
FR-04.4. The system shall implement an inference engine that periodically
Engine
analyzes actions taken by user and events stored and suggest/carry out tasks that can improve the user’s 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
Project Domus: Designing Effective Smart Home Systems
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
Project Domus: Designing Effective Smart Home Systems
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 user’s 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
Project Domus: Designing Effective Smart Home Systems
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
A self-contained instruction executed in the system. Actions can be triggered by a user (e.g. instant action) but can also be carried out automatically (e.g. scheduled action).
Actuator
An electric or electronic device connected to the system that controls an appliance (e.g. a light).
Audit Log
A table in the system database that stores security information such as login attempts and system changes.
Automated
An action carried out by the system without direct user input.
Action Closed Team
A team that has been given restricted access by a team owner. A closed team can no longer be controlled by a normal user but only by its owner or by a power user (see also: Team).
Deferred
A command that is issued as part of a schedule set by the user.
Command Device
An actuator or a sensor existing in the system.
Disabled Device
A device that has been made inactive. The device still exist in the system but will not be considered. If this device is a sensor, its input will not be considered; if an actuator, no commands will be 59
Project Domus: Designing Effective Smart Home Systems issued to it. A disabled device retains all its information in the system (e.g. details and schedule) and can be re-enabled at any time. Event
An input provided by a Sensor and that may trigger an automated action.
Instant Action
A command given by the user that is intended to immediately act upon a specific device or team.
Local User
An authenticated user who connects to the system locally (e.g. while being in the home).
Mobile Device
A device used by mobile users to connect to the system (e.g. a PDA or mobile phone).
Mobile Users
A subset of local users who will use a mobile interface to connect to the system (e.g. a PDA).
Passcode
A secret alphanumerical string that grant access to the system. It is used combined with a username.
Power User
An authenticated user in the system with administrator rights. Only a power user will be able to perform certain tasks in the system (e.g. creating teams).
Real-time Sensor
An input device that will provide real-time input to the system.
Remote User
An authenticated user who connects o the system remotely via the Internet.
Removed Device
A device that is no longer part of the system. When a device is removed, all its data (e.g. historical information, schedules, etc.) will also be permanently removed from the system. If the device is then re-added, it will be treated as a new device.
Schedule
A command set in the future that will trigger one or more actuators when executed. A schedule can also contain multiple or recurring events.
Scheduled
An Automated Action carried out as a result of a Deferred
Action
Command set by the user.
Sensor
An electric or electronic device connected to the system that provide a digital or analog input (e.g. a thermometer). 60
Project Domus: Designing Effective Smart Home Systems System
The Smart Home system developed with this project.
Team
A collection of devices that can be operated as one device.
Team owner
An authenticated user designated by a power user who has control over a team. (see also: Team).
User
Any authenticated users of the system.
User Interface
It provides input and output capabilities to allow users to interact with the system. The system may need to provide different interfaces to cater for the differences among local, remote and mobile users.
Username
A unique alphanumerical string that identify a user on the system.
4.2. Design This section will take the information outlined by the analysis and implement the actual design of the Smart Home system using the Unified Modelling Language (UML) design methodology to represent the information required. System Operation The Use Case diagram depicted in Figure 13 outlines the main tasks performed by users of the system. Authenticated users can display the status of any device controlled by the system, issue a command to change a status of a device through an Actuator, setup a schedule for future events, and disconnect a device that can then be controlled manually. In order to enhance security, some of the system functionalities can be made not available to Remote Users (not shown in the diagram).
61
Project Domus: Designing Effective Smart Home Systems
Figure 13 Operating the System
User Authentication Before users can carry out any operation within the system, they will need to be authenticated. Three categories of authenticated users are defined as follows: Authenticated Users, Remote Users, who connect to the system remotely, and Power Users, who will perform certain administration functions in the system. A time-stamped entry will be saved into an Event Log for reference. Figure 14 illustrates this scenario as a Use Case diagram.
62
Project Domus: Designing Effective Smart Home Systems
Figure 14 User Authentication
User Administration To enforce the user authentication feature, users will need to receive a username and password in order to log in. Only Power Users will have access to creating a new user or resetting a user password . Figure 15 represents the Use Case diagram for this scenario.
63
Project Domus: Designing Effective Smart Home Systems
Figure 15 User Administration
Device Administration Figure 16 represent the Use Case diagram that outlines how devices can be added, edited or removed from the system. Only Power Users will be able to execute these commands and the operation will also be logged in the Event Log for reference.
Figure 16 Managing Devices
64
Project Domus: Designing Effective Smart Home Systems Team Administration Teams provide users with the option of grouping devices that can work together as part of virtual, user-defined sub-systems, e.g. a HVAC or Home Security system. The main purpose of this feature is to offer users the ability of creating images of the system according to their understanding, thus increasing the overall usability.
All the
functionalities common to all the devices grouped in a team can be controlled together as if it were a single device. Devices can belong to more than one Team and devices that belong to a Team can still be managed individually. Only Power Users can create, modify and delete Teams. However, once a Team has been set up, its operation can be delegated to a member of the Authenticated User group. Figure 17 provides the Use Case diagram for the management of this feature.
Figure 17 Managing Teams
Schedule Administration The system provides the option to schedule recurring actions for one device or a team. This is considered a useful feature of a Smart Home system.
The system will
continuously pull the Schedule database to see whether there are actions to be carried out. A Team schedule can only be edited by a Power User of by an Authenticated user
65
Project Domus: Designing Effective Smart Home Systems who was made owner of the Team. Figure 18 represents the Use Case diagram for this feature.
Figure 18 Managing Schedules
Event Management Events are input provided by sensors communicating with the system, e.g. a thermometer or an occupancy sensor. In order not to overburden the system with a constant stream of data, sensors will be sub-divided into two categories. The first category is for real-time (RT) sensors, which, due to the sensitivity of the input provided, communicate directly to the Flight Control, e.g. a motion detector part of a the Home Security System. The second category contains all the other sensors, such as a thermometer, which might not require immediate action. In this case, the input provided is simply stored in the system database and will be analyzed, perhaps in combination with other events, at the next scheduled cycle. Figure 19 displays the Use Case diagram for this scenario. 66
Project Domus: Designing Effective Smart Home Systems
Figure 19 Managing Events
Command Dispatcher Figure 20 illustrates the Use Case diagram for how the system dispatches commands to an Actuator. In order to enhance reliability, the Actuator will implement a closed-loop feedback which will provide the system with a means to detect whether the command has been executed properly.
Figure 20 Dispatching Commands
67
Project Domus: Designing Effective Smart Home Systems Flight Control Figure 21 shows the Use Case diagram for the Flight Control sub-system. The Flight Control is the central element of the system as it coordinates all the actions and events occurring in the system.
Figure 21 Flight Control Sub-System
Inference Engine The Inference Engine comprises of a Rule-set database that contains a Bayesian Network engine that interacts with the events occurring in the system and provide suggestions to the Flight Control about possible actions that need to be carried out in the system. Ideally, the Rule-set database should also be able to learn from historical information in order to become more effective. Figure 22 shows the Use Case diagram for the Inference Engine.
68
Project Domus: Designing Effective Smart Home Systems
Figure 22 Inference Engine Sub-system
4.3. Implementation This section will outline the actual implementation of the Proof-of-concept (POC) system. Firstly, it will introduce the technology that will be used and then outline the inner workings of the actual system. Of the various sub-systems identified in the previous section, only the following will be further developed: •
Command Dispatcher
•
Device Manager
•
Event Collector
•
Event Logger
•
Flight Control
•
User Interface
•
Inference Engine 69
Project Domus: Designing Effective Smart Home Systems 4.3.1. Hardware The POC system uses hardware that is compatible with the LonWorks technology, developed by Echelon Corp.4 LonWorks™ is an industry standard (ISO/IEC 14908-1) home network technology which has been successfully used to control and automate commercial buildings and factory settings. LonMark™ International is the independent body that manages the evolution of the technology by issuing interoperability guidelines and certifications for new devices. LonTalk™ (EN14908/1), the LonWorks communication protocol, implements a structure comparable to the OSI network model, with six of its seven layers integrated in the device hardware. The protocol includes features such as media access control, transaction acknowledgement, priority transmission, authentication, multicast and broadcast addressing, error detection and recovery. A LonWorks network consists of intelligent devices that communicate with each other using LonTalk protocol over a communications channels, which may be implemented using several medium, such as Powerline, twisted-pair, RF or any mix of these. The protocol defines the format of the messages being transmitted between devices and the actions expected when a device sends a message to another. Figure 23 shows how two LonWorks devices exchange these messages and how the various network layers encapsulate these messages with the layer’s frame.
Figure 23 How LonWorks Devices exchange Messages
4
See: http://www.echelon.org
70
Project Domus: Designing Effective Smart Home Systems All LonWorks devices comprise of a microchip, called Neuron Chip, which functions as a network communications processor and an application processor. Each Neuron Chip comes with a unique 48-bit software-accessible serial number (called Neuron ID, or NID) that ensure uniqueness of the device and facilitates its installation and configuration. Devices are programmed using a variant of ANSI C, named Neuron C, which adds event-driven capabilities to the standard C language. Once developed and debugged, the code is then loaded into the devices using the EPROM space provided in the logic board. The Neuron C language creates the software interface that a device will use to issue or receive commands and to communicate information about its status to other devices in the network. Each LonWorks device comprise of one or more functional blocks (FBs) which group the input/output interface into coherent groups. Each Functional Block implements a portion of a device’s application and performs the tasks of receiving configuration and operational data inputs, processing the data, and sending operational data outputs. FBs declare configuration properties (CPs) and network variables (NVs). Using the Object-Oriented paradigm, a Configuration Property corresponds to an object attribute, whereas a Network Variable provides the object methods that can be used to access or modify a CP. Figure 24 provide a graphical representation of a typical LonWorks device.
Figure 24 Anatomy of a LonWorks Device
71
Project Domus: Designing Effective Smart Home Systems
To ensure inter-operability between devices in a multi-vendor environment, LonMark International provides guidelines for the definition of these devices. Such implementation details are then usually provided to the system integrator when buying the physical device. The most up-to-date guideline documents can be found on line at: http://www.lonmark.org/. In order for two NVs to connect one another, they must be of a compatible type. For example, Figure 25 shows how a LonWorks switch can operate a light device by connecting its output NV, with a compatible input NV of the controlled device, in what is also called a point-to-point connection.
Figure 25 Network Variables
A single output NV may connect to more than one input NVs, creating what is called a fan-out connection. This is a useful feature that would allow, for example, a single switch to control multiple lights or a light to be controlled by multiple switches. Through a process called binding, usually performed during the design and installation phase, the device’s firmware is configured to know the logical address of the other device, or group of devices, in the LonTalk network from which to expect input via one of its NVs. This process creates logical connections among devices that might be thought as “virtual wires”. Finally, controlled devices can also provide NVs that can be used to determine whether a command completed successfully, thus increasing reliability. Figure 26 depicts an example of a typical LonWorks solution that is made of two switches, one light sensor, and two lamps. The system also makes use of the feedback mechanism via one of the lights’ nvoSwitchFb output NVs. In such configuration, the light can return its current status to the controlling switches via the nviSwitchFb Network Variable.
72
Project Domus: Designing Effective Smart Home Systems
Figure 26 A Typical LonWorks Solution
The POC system uses a Mini EVK Evaluation Kit, acquired from Echelon Corp., which includes the following: •
A FT 3120 and FT 3150 Evaluation Boards (EVBs)
•
Two I/O Boards (Mini Gizmos) that can be attached to each EVB
•
A USB Network Interface (U10) used to connect the computer to the LonWorks network and communicate with the devices
•
Twisted-pair (TP) cables for wiring the two EVB and the USB Network Interface
•
Installation CD-ROM containing application examples, utilities and drivers for Windows 2000/XP.
73
Project Domus: Designing Effective Smart Home Systems
Figure 27 The Mini EVK Evaluation Kit
Figure 27 provides an overview of the Mini Kit and its components.
The two
Evaluation Boards could be programmed using the Neuron C language and the Installation CD also provided a few examples that would emulate different types of LonWorks devices. The two Mini Gizmos I/O boards provided the input/output devices that could be piloted by the EVBs. The following I/O devices were available: •
Eight mini-switches, of which seven are available to the application (input)
•
Eight LEDs, connected to their corresponding switch to provide visual feedback about the status of a simulated device (output)
•
One temperature sensor (input)
•
One buzzer (output)
74
Project Domus: Designing Effective Smart Home Systems For the POC system, the FT3150 Board, configured with the “MGDEMO” Neuron C image will be used. Table 6 details MGDEMO the Functional Blocks, Configuration Properties and Network Variables developed for the device. Table 6 MGDEMO Attributes and Methods Functional Blocks (device)
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): •
A Temperature Sensor (TS)
•
A Motion Sensor (MS)
•
A Light Sensor (LS)
Actuators (output devices):
5
•
HVAC System
•
A Fire Alarm Siren
The “nvo” and “nvi” suffix define an output or input variable respectively.
75
Project Domus: Designing Effective Smart Home Systems Table 7 reports how the real-world devices listed above will be represented by the system, while Figure 28 provides a detailed view of the Mini Gizmo I/O board that contains the devices used by the POC system. Table 7 Mapping Real-world Devices to the POC Real-world Device
POC (Mini Gizmo I/O Board)
Main Switch
Switch #1 (ON = activated)
HVAC System
Switch #2 (ON = activated)
Motion Sensor (MS)
Switch #3 (ON = activated)
Light Sensor (LS)
Switch #4 (ON = daytime)
Temperature Sensor (TS)
Temperature sensor
Fire Alarm Siren
Buzzer
Figure 28 Mini-Gizmo I/O Board
The Temperature Control System (TCS) will continuously interpret the data provided by the sensors installed and take actions depending on the input received. The application’s main screen is divided into two main sections, left to right: the section on the left can be defined as the “control panel”, providing all the settings available and the system outputs; the section on the right provides the real-world representation of the system.
This will also provide the location of the actual sensors and actuators
throughout the house: the Light Sensor, Motion Sensor, Fire Alarm, and HVAC). 76
Project Domus: Designing Effective Smart Home Systems Although in the final system some of these elements would exist in its own sub-menu, for ease of representation, the POC provides everything in one screen. Figure 29 shows a screenshot of the system’s main window.
Figure 29 Main Screen of the POC System
After the introductory screen is acknowledged, the system will start in idle mode; that is, waiting for the user to select the device to be monitored and managed. In order to bind the LonWorks kit to the application, the following steps will need to be carried out: 1. Click on the Monitor button. The Add Device dialog box will display, shown by Figure 30. 2. Either enter the Neuron ID in the text box provided (if known) or press the Service switch on the EVB to fill the text box automatically. Figure 31 illustrates the location of the switch in the board. 3. Press the OK button.
77
Project Domus: Designing Effective Smart Home Systems The software is now bound the EVB and will show the status of the actuators and sensors present in the system.
Figure 30 Add Device Dialog Box
Figure 31 EVK Service Switch
The POC system can be conceptually sub-divided into three main sub-systems: the Fire Alarm sub-system, the Heating and Air Conditioning sub-system, and the Inference Engine. The following sections will go into more details for each of these sub-systems. Both the FA and HVAC sub-systems can be turned on or off using their main switches. Fire Alarm Sub-System The Fire Alarm sub-system (FA) will monitor the environment for the likelihood of a fire in order to alert security personnel in time to address potentially dangerous situations. Figure 32 displays the settings for the FA sub-system.
78
Project Domus: Designing Effective Smart Home Systems
Figure 32 Fire Alarm Sub-system Settings
The FA will activate an alarm when some thresholds specified by the user have been met. The system also provides a way to mute the alarm once the alarm has been acknowledged and the situation being investigated. The FA uses two interlinked ways to determine the likelihood of a fire: the first is by comparing the current temperature with what is considered a high and the other is by monitoring the probability of a fire against a pre-set value, controlled by the Sensitivity slider. The probability value is calculated in real time by the BN and it is displayed by the application in the Current Fire Likelihood bar, outlined in Figure 32. Figure 33 shows the logic flow for the FA sub-system. The code implementation of this logic flow is provided in the Appendices.
Figure 33 Logic Flow for the FA Sub-system
79
Project Domus: Designing Effective Smart Home Systems Heating and Air Conditioning Sub-System The Heating, Ventilating and Air-Conditioning (HVAC) sub-system monitors and controls the temperature in the house. Should this fall outside the comfort zone set by the user, the system might bring the temperature within the parameters specified. Figure 34 displays the settings for the HVAC sub-system.
Figure 34 HVAC Sub-System Settings
Before deciding to turn the system on, the HVAC will consider some conditions. Firstly, the system will not take any action if the user set this to manual mode (by ticking the Manual Mode check box) and will let instead the user take control of the system. Should the system be configured to operate in automatic mode, it will consider the input from the sensors to determine the best course of action. Specifically, it will try to determine whether there is anyone in the house and whether to employ a more conservative, energy-saving scheme if it is night-time. Figure 35 provides the logic flow for the HVAC sub-system. The code implementation of this logic flow is provided in the Appendices.
Figure 35 Logic Flow for the HVAC Sub-system
80
Project Domus: Designing Effective Smart Home Systems Inference Engine Sub-System The Inference Engine sub-system (IE) implements a Bayesian Network through the Netica API provided by Norsys Software Corp.6, Vancouver (CA). The BN should enhance the system’s ability to detect a fire that would be otherwise limited to measuring the temperature in the house. The BN correlates all events reported by the various sensors and combines this with other factors such as the status of other systems, such as the HVAC.
It then calculates and returns the real-time likelihood of a fire
scenario by calculating its statistical probability according to the state and relationships of the other nodes. Manually calculating the probability of such a model can be a tedious and 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 28–1=255 calculations. In reality Bayesian Networks do not actually need to perform all these calculations; however a more in-depth discussions is beyond the scope of this paper. Further discussions on Bayesian Networks can be found in the material referenced.
6
See: http://www.norsys.com/
81
Project Domus: Designing Effective Smart Home Systems
Figure 36 Causal Graph for the FA Sub-system
Table 8 provides the rationale behind these relationships. Note that each node will have only two possible status. The probability tables for a practical implementation of these relationships can be found in the appendices. Table 8 BN Nodes and Relationships Node (values)
Relationship with
Reasons
Fire Danger
none
Fire Danger is the outcome scenario sought by this BN.
(true/false) Cooking Time
High Temperature
High Temperature: the temperature might raise
(true/false)
Fire Danger
above normal values while cooking. Fire Danger: The risk of a fire is somewhat greater when cooking. NOTE: Not implemented by the application. It could be gathered out of evidence such as the oven/cooker being switched on etc.
Daytime
HVAC
HVAC: A longer day or shorter night will
(true/false)
High Temperature
influence how the HVAC system will operate.
Lived In
High Temperature: Longer summer days are likely warmer; longer winter nights are likely colder.
82
Project Domus: Designing Effective Smart Home Systems
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
Causal connection between high temperature in the room and the likelihood of a fire.
High Temperature
(true/false)
It is less likely to have a high temperature when the air conditioning is on (so a high temperature developing in this circumstance might be more suspicious).
Lived In (true/false)
HVAC On
HVAC On: This is a direct consequence of the
Fire Danger
HVAC logic, which is to turn on when the motion sensor is activated. Fire Danger: Here an assumption was made that when there are people in the house there is a minor probability for fire to be developed.
Summer
High temperature
High Temperature: It is likely to be hotter in
(true/false)
Daytime
summer than winter.
HVAC
Daytime: Days are shorter in winter time than summertime. HVAC: Air conditioning might be turned on more often in summertime (and the heating system in winter time). NOTE: Not implemented in the application. The information might be gathered from a calendar or by other type of evidence.
Figure 37 shows a point-in-time representation of the BN for the FA sub-system. Note how the probabilities contained in the nodes will change depending on the status of other nodes. In the example provided, the BN was provided with evidence known at that point in time (see nodes with probability set to 100%). Generally, the more evidence can be provided to the BN, the more accurate the likelihood for the outcome monitored will become.
83
Project Domus: Designing Effective Smart Home Systems
Figure 37 Fire Alarm Bayesian Network
Although not implemented in this POC, it is worth mentioning that, in a real-world scenario, the initial probabilities set up in the BN could be adjusted using this evidence, thus potentially increasing its prediction accuracy over time. The code implemented in the application to connect to the Netica API is provided in the Appendices.
4.4. Testing This section illustrates the testing carried out with the POC system. It provides an outline of the test plan, its deliverables, a summary of the results and the outcomes of the test. Details of the individual tests are provided in the appendices. 4.4.1. Test Plan 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
Project Domus: Designing Effective Smart Home Systems subset of the initial functional requirements outlined in the Design section displays the sub-set of Function Requirements implemented in the POC. This table shall form the basis for the testing strategy along with the logic flows outlined by Figure 33 and Figure 35. Interfaces with Other Systems In order to run correctly, the application tested will need the following software installed on the machine used for testing: •
Netsys Netica Software, Version 4.08
•
Microsoft Visual Studio 2005
Testing Approach As this POC was conceived as a throw-away prototype, the code is as such not intended to be re-used and no other testing techniques other than System Testing will therefore be used. Suspension Criteria and Resumption Requirements Test Cases are given a Severity (1= high, 3= low) and Priority (1= must have, 3= nice to have). All failed test cases will be reported in the Bug Report along with details of the failure and any workaround (if available). However, only Severity 1 or Priority 1 features are considered “high impact”.
Testing will be discontinued if one of the
following conditions is encountered: •
2 Severity 1 bugs found, or
•
2 Priority 1 bugs found
Testing will not be halted if non-high impact bugs are found. Testing will resume as soon as a new build which corrects the high-impact bugs is available. The test execution order will take the following order: 1. Smoke and confidence tests 2. The tests which found the bugs which have just been fixed 3. The regression tests 85
Project Domus: Designing Effective Smart Home Systems 4. The rest of the tests Test Deliverables The following deliverables are part of this plan: •
Test plan (this document)
•
Test cases
•
Bug reports
•
Test summary reports
Testing Tasks Identify: The set of tasks necessary to prepare for and perform unit, integration, and system testing All inter-task dependencies and any special skills required Environmental needs In addition to the software specified in the “Interface with Other Systems” section of this Plan, the following HW and SW will also be required to perform the tests: Minimum Requirements: •
Operating System Windows XP SP2
•
CPU Intel Pentium 4, 2 GHz
•
1GB RAM
•
Screen resolution 800x600
•
100 MB available hard-disk space
•
One USB (1.1) Port available
•
Echelon Mini EVK Kit, Rev. A W.W. 08/08 37323
•
FTDI Echelon USB Network Interface Driver v. 2.0.2.0
•
OpenLDV Driver v. 3.20.29
•
Microsoft Visual Studio 2005
86
Project Domus: Designing Effective Smart Home Systems Identified Risks Details, impacts, and contingency plans for the high-level risks that may occur during the testing procedure are outlined in Table 9. Table 9 Test Plan Risks and Contingencies ID
Risk
Impact
Contingency Plan
1
One high-impact
The user is severely affected
Document the issue in the bug
bug found
by the lack of an important
report and provide a workaround (if
feature.
possible)
Two high-impact
Delays caused by test
Lift code freeze and debug the
bugs are found
procedure being halted and
application in order to resolve the
re-work to occur in the
bugs found within 48 hours. If this
application
cannot be resolved within the
2
timeframe provided, exclude the feature from the POC.
4.4.2. Test Cases 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)
2
1
2
PASS (1)
1
1
3
PASS (1)
2
2
4
FAIL (1)
2
2
Error message: “Invalid Neuron ID. The Neuron ID must be specified in 12-digit hexadecimal number.” The number provided in the test seems to be one digit short?!? WORKAROUND: YES
5
PASS (1)
2
1
6
PASS (1)
2
1
7
PASS (1)
2
1
8
PASS (1)
2
2
The setting seems to be repeated at each cycle in the log.
87
Project Domus: Designing Effective Smart Home Systems
ID
PASS/FAIL
SEV
PRI
NOTES
(ROUND) 9
PASS (1)
2
1
10
PASS (1)
2
2
The calculated values seems to be rounded up/down (e.g. 5% of 15 is 0.75; 5% of 28 is 1.4 but the min/max values are always +1/-2 degrees.
11
PASS (1)
2
3
12
PASS (1)
2
1
13
PASS (1)
2
3
14
PASS (1)
1
1
15
PASS (1)
1
1
Neuron ID of Device 2: 04284CAF0200 Cannot set High Temp value below 29 degrees. Buzzer does not turn OFF once the alarm is triggered but you will need to mute the alarm to make it stop (feature or bug?)
16
PASS (1)
2
1
17
FAIL (1)
1
1
Mute Alarm doesn’t get un-ticked.
18
PASS (1)
2
2
Calculated values seem rounded up/down to the nearest unity (e.g. 1.24 = 1; 2.4 = 2).
19
PASS (1)
2
2
20
PASS (1)
2
2
21
PASS (1)
2
2
22
PASS (1)
2
1
23
PASS (1)
2
1
88
Project Domus: Designing Effective Smart Home Systems
4.4.3. Functional Requirements Implemented in POC Table 11 outlines the subset of the original Functional Requirements implemented in the POC. Table 11 List of Functional Requirements Implemented Sub-System
Functional Requirement Details
Implementation Details
Device
FR-01.1. The system shall provide users with a feature to temporarily disable or permanently
HVAC system can be set to manual
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.
HVAC and FA sub-systems have main switch to inhibit control of the devices from the application.
User Interface Event Logger
FR-02.1. The system shall provide feedback for a user request for an instant command within 3
Immediate (< 3 sec) visual feedback
seconds from the command being issued by the user.
provided by objects in UI.
FR-02.2. The system shall implement a means to record all instant command requests and their
Event Logger to display a time-
outcomes for later user retrieval and examination.
stamped record of command requests and other actions occurred in the system.
Event
FR-02.4. The system shall evaluate immediately information received by real-time sensors (e.g.
System to continuously poll status of
Collector
intruder alert).
sensors and actuators (< 1 sec).
Event Logger
FR-03.12. The system shall store command issued and confirmed system changes in an Event Log.
Implemented by Event Logger.
User Interface
FR-04.1. The system shall implement appropriate HCI methodologies for its User Interface.
Visual representation of devices using the house blueprint.
Project Domus: Designing Effective Smart Home Systems
Sub-System
Functional Requirement Details
Implementation Details Use of real-world analogies (e.g. sliders) to control device settings. Objects and settings logically grouped together. Enabled use of mouse with keyboard accelerators (shortcuts) as secondary ways to access all main features.
User Interface
FR-04.2. The system shall implement relevant industry-standard guidelines, depending on the actual
Standard Windows objects
user interface used (e.g. Microsoft Windows, Internet Browser, etc.)
implemented in GUI.
FR-04.6. None of the commonly used features shall be more than three steps away (e.g. three
All main features represented in
mouse clicks) from the main system window.
main window.
Event Logger
FR-07.4. The system shall provide a means to store operation issues for later examination.
Implemented in Event Logger.
Device
FR-09.2. The system shall provide a way to identify its own devices from others.
Implemented via LonWorks Device
User Interface
Manager
ID and Network ID.
Device
FR-10.1. The system shall provide users with the option to add a new compatible device into the
Implemented via the Add Device
Manager
system via the User Interface.
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
Implemented via the Add Device
Manager
teams, setting a schedule, etc.).
dialog box.
90
Project Domus: Designing Effective Smart Home Systems
4.4.4. Bug Report Table 12 provides the list of tracked bugs for the application. Table 12 Bug Report Bug #
Title
Description
Status
Feature Area
Severity
Environment
Resolution
1
Manual Neuron
Cannot type Neuron ID
Fixed
Device Manager
3 (low)
Tried with Neuron ID
Neuron ID provided in the test
ID
manually (doesn’t work?)
04D5CA75020
case was missing a zero (04D5CA750200).
However
Text Box might need to be expanded to show full string at once. 2
Buzzer does not
Muted buzzer does not get
get un-muted
un-muted when the FA is
starts with “Mute
triggered
Alarm” ticked
Open
Fire Alarm Logic
91
1 (high)
FA Alarm system
Project Domus: Designing Effective Smart Home Systems
4.4.5. Test Outcomes Out of the total number of test cases devises, 21 passed, giving a first-pass rate of 91%. Moreover, one of the failed tests (Test # 4) was not a high-impact feature and had a workaround and a sub-sequent investigation found that the reason of the failure was caused by the incorrect number being provided in the test case. The other failed test (Test # 17) is high-impact as it affects an important feature of the FA sub-system but it will not be a show-stopper according to the Suspension Criteria listed previously. However, if time allows, a decision will be made to see whether it will be feasible to correct this bug before the deadline.
Project Domus: Designing Effective Smart Home Systems
5. Conclusion This chapter presents the conclusion drawn from the work carried out for the project. It provides a summary of the work performed, the main findings, and recommendations for future work.
Finally, it includes comments on the learning outcomes from a
personal point of view.
5.1. Summary of the Work Chapter 1 has defined the initial aim and objectives for this project. The aim was to develop a proof-of-concept that would address at least some of the challenges found during the research. The intellectual challenge was to investigate how a Smart Home system could be made more effective by using AI techniques. Chapter 2 has provided the formal definition of a Smart Home system and outlined a history of appliances and home networking technologies which are fundamental to the existence of a Smart Home. It has also provided an overview of recent development and current research projects. Chapter 3 has investigated in more detail the basic blocks of a Smart Home system and has provided an overview of home network communication protocols in existence today.
It has then expanded on the potential market for Smart Homes, outlining
benefits, needs, and concerns reported by recent researches. Finally, it has outlined current design challenges and provided suggestions on how they could be addressed. Chapter 4 has dealt with the actual development of a Smart Home system. In the Analysis section, the system requirements and the main sub-system for the system were outlined in details. The Design section has expanded the analysis by documenting use case scenarios and integrating these into the sub-systems identified.
The
Implementation section has outlined the details of a proof-of-concept system by first introducing the hardware and software used, and then providing its implementation details. Finally, the Testing section has outlined how the system testing was planned, executed, and how its results were analyzed.
93
Project Domus: Designing Effective Smart Home Systems
5.2. Project Findings The main finding of this project is that it is indeed possible to make a Smart Home system more effective by integrating AI technologies into it. The proof-of-concept has provided an example on how such a system can analyze the information gathered from the environment using a Bayesian Network that can be used by an inference engine that could calculate the likelihood of a fire. Although the POC offers a simplified view of a Fire Alarm system, it already offers a solution that can be implemented in a real-world application. It also illustrates a concept that can be further developed to support different and more complex decision-making scenarios.
Moreover, the inference
engine could be enhanced further so that it can learn from the input provided by user’s 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. Recommendations for Future Work Regarding the proof-of-concept system developed by this work, it is understood that it provides a subset of a fully functional Smart Home system.
Therefore, the first
recommendation would be to develop and implement the other areas identified in the Analysis and Design sections. Furthermore, future work should provide implementation of the core as a Web Service and develop a web-based User Interface as this will provide support to heterogeneous web-based clients which will allow mobile and remote users to connect. Finally, the system demonstrated how Bayesian Networks can effectively support decision making in many automated areas of the system and an effort should be made to explore this concept further. General recommendations can also be provided about the design of Smart Home systems. First, it is suggested that producers of Smart Home technology should take more time to try and understand users’ needs before developing new products and should put more effort in making potential users understand what their solutions can do for them. Second, as the existence of too many standards has been slowing down a wider adoption of this technology by the consumer and building industries, it is 94
Project Domus: Designing Effective Smart Home Systems therefore arguable that the current consolidation trend ought to continue in order to push this technology farther along the Technology Adoption Lifecycle. Third, lack of available expertise in the industry has contributed to the creation of ineffective solutions, in spite of sometimes high implementation costs. As choosing the right technology mix plays an important role in the success of a Smart Home system, it is arguable that, as more expertise become available, better, cheaper, and more effective solutions will be made available. On a positive note, this technology can fulfill many of the expressed needs and address most of the concerns. All the design challenges examined in this paper can be overcome by using the right approach and implementing the correct methodology. Reliable, costeffective, and supported technology is available and other research fields, such as AI, can contribute to make Smart Home systems more effective.
5.4. Learning Outcomes 5.4.1. Research Google Scholar proved to be an invaluable starting point to locate white papers, publications and books on the topic. Reviewing this literature provided a deeper insight on Smart Home systems, their challenges and recent researches made in the field, all of which helped and challenged to dig deeper in certain areas to gain a more complete understanding of the subject. The student memberships of ACM and IEEE also helped in providing full access to most of the research papers and publications found, whilst the local DIT library and Book24x7.com provided access to the books. 5.4.2. Analysis This project has allowed me to apply methodologies and concepts learned in this course to a real-world problem and to effectively document the requirements of an Information System. 5.4.3. Technical As identified at the beginning of this project, coding has been the singe biggest challenge of this project, mostly due to lack of recent hands-on experiences with the 95
Project Domus: Designing Effective Smart Home Systems subject. Fortunately, the code samples provided with the LonWorks kit, coupled with the guidance provided by Echelon technical support personnel and on-line forums, always allowed the project to progress further. 5.4.4. Project Management The application of proper Project Management techniques helped to keep this project on track. For example, the initial Risk Identification carried out was important to spot potential problems and brainstorm contingency plans should any of these risks have occurred. As a result, it was possible to avoid most of this potential problems and with the confidence that there was a contingency plan in place should a monitored risk have materialized. The decision about what technology to use was made at the right time into the project and the hardware was timely made available and worked flawlessly. Although the tight timeframe did not allow for the implementation of all the features that were initially envisaged, and some compromises were at times required, the project remained on track throughout all its phases and ended right on schedule. 5.4.5. Lessons Learned From a personal point of view, I consider this project a success. However, a lesson learned was to include in the project schedule training activities to become accustomed with the programming language, as this would have allowed the Implementation phase to progress more efficiently. Furthermore, the starting date for the project and its initial phases, such as initial investigation, could have pushed back a few months and been carried out during summertime. This would have allowed more time for other phases to be expanded as required, for example leaving enough time for a refresher training in Visual Studio C# to be included.
96
Project Domus: Designing Effective Smart Home Systems
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. (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
Project Domus: Designing Effective Smart Home Systems Helal S., Mann W., El-Zabadani H., King J., Kaddoura Y., Jansen E., "The Gator Tech Smart House: A Programmable Pervasive Space," Computer, vol. 38, no. 3, pp. 50-60, March, 2005. Horvitz, E., et al., “The Lumiére project, Bayesian user modeling for inferring the goals and needs of software users”, Proceedings of the 14th Conference on Uncertainty in AI, pp. 256-265, Morgan Kaufmann, San Francisco, 1998. Kango R., Moore P.R., Pu, J., “Networked smart home appliances - enabling real ubiquitous culture, Proceedings. 2002 IEEE 5th International Workshop on Networked Appliances, 2002, pp. 76-80, October 2002. Kook Hyun Chung, Kyoung Soon Oh, Cheong Hyun Lee, Jae Hyun Park, Sunae Kim, Soon Hee Kim, Loring, Beth, Hass, C., “A User-Centric Approach to Designing Home Network Devices”, CHI '03 extended abstracts on Human factors in computing systems, pp. 648-649, 2003. Koskela T., Väänänen-Vainio-Mattila K., “Evolutions towards smart home environments: empirical evaluation of three user interfaces”, Personal and Ubiquitous Computing, vol. 8, no. 3-4, pp. 234-240, June, 2004. Kyung Lee M., Davidoff S., Zimmerman J. (Year?), Dey A., “Smart Home, Families and Control”, Carnegie Mellon University, Pittsburgh, PA (US) Li Jiang; Da-You Liu; Bo Yang (2004), "Smart home research, Machine Learning and Cybernetics”, Proceedings of 2004 International Conference, vol.2, pp. 659-663, 26-29 Aug. 2004. Lorente, S. (2004) "Key issues regarding Domotic applications", Proceedings of 2004 International Conference on Information and Communication Technologies: From Theory to Applications, pp. 121-122, 19-23 April 2004. Morgan Kaufmann, San Francisco.Chunduru, V. Subramanian, N., “Effects of Power Lines on Performance of Home Control System” , International Conference on Power Electronics, Drives and Energy Systems, PEDES '06, pp. 1-6. December, 2006. Myers B., Hollan J., Cruz Isabel, et al., “Strategic Directions in Human-Computer Interaction”, ACM Computing Surveys, vol. 28, no. 4, pp. 794-809 December 1996. Myers, G. J.. The Art of Software Testing. John Wiley & Sons. © 1979. Books24x7. (accessed March 24, 2009). Page, A., Johnson, K., Rollison, B. How We Test Software at Microsoft. Microsoft Press. © 2009. Books24x7. (accessed March 24, 2009). Pragnell, M., Spence L., Moore R. (2000) The market potential for Smart Homes, Joseph Rowntree Foundation, York, UK. Ricquebourg, V.; Menga, D.; Durand, D.; Marhic, B.; Delahoche, L.; Loge, C. (2006), “The Smart Home Concept : our immediate future", E-Learning in Industrial Electronics, 2006 1ST IEEE International Conference, pp. 23-28, 18-20 Dec. 2006. Ringbauer, B., Heidmann, F., Beisterfeldt, J., “When a house controls its master – Universal design for smart living environments”, Proceedings of the Universal Access 98
Project Domus: Designing Effective Smart Home Systems in HCI: Inclusive Design, Crete, Greece, 2003. Taylor, F.W.(1911) The Principles of Scientific Management. Reprint. New York: Dover, 1998. Wacks, K. (2002), "Home systems standards: achievements and challenges," IEEE Communications Magazine, vol.40, no.4, pp.152-159, Apr 2002. Wang (ed), J., "Bayesian Networks". Encyclopedia of Data Warehousing and Mining, Volume I, A-H. IGI Publishing. © 2006. Books24x7. (accessed February 16, 2009). Wiegers, K. E., Software Requirements, Second Edition. Microsoft Press. © 2003. Books24x7. (accessed February 18, 2009).
99
Project Domus: Designing Effective Smart Home Systems
Appendices Appendix A – Details from Survey This appendix outline the main findings of the survey reported by M. Pragnell (200) in “The market potential for Smart Homes”. Some of the findings were used to determine the user profile for the Smart Home system detailed in this paper. 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
Project Domus: Designing Effective Smart Home Systems
Views about the Smart Home:
Concerns about Smart Home technology:
101
Project Domus: Designing Effective Smart Home Systems
Level of interest in the Smart Home concept:
Agreement with statement ‘I am really interested in having the sort of functions a Smart Home could offer’ among those who agree with attitude statements:
102
Project Domus: Designing Effective Smart Home Systems
Appendix B – Code Implementation HVAC Logic Flow: /// /// Checking HVAC /// // set to manual mode? if (checkBoxOverRide.Checked) return; // then exits // determines the comfort zone if (bLSOn) // it's daytime { //defines comfort zone (+/- 5%) comfortZoneMin = cZoneTemp – System.Convert.ToInt32(cZoneTemp * 5 / 100); comfortZoneMax = cZoneTemp + System.Convert.ToInt32(cZoneTemp * 5 / 100) else { // it's night-time so use some energy-saving approach comfortZoneMin = cZoneTemp – System.Convert.ToInt32(cZoneTemp * 15 / 100); comfortZoneMax = cZoneTemp + System.Convert.ToInt32(cZoneTemp * 15 / 100); } // check whether we are outside the comfort zone if ((args.Temperature.ScaledValue > comfortZoneMax) || (args.Temperature.ScaledValue < comfortZoneMin)) bOutsideCZone = true; // if we need to adjust if (bOutsideCZone) { // if it is night time and there isn't anyone in the room, no need if ((!bLSOn) && (!bMSOn)) bHVACOn = false; else bHVACOn = true;
103
Project Domus: Designing Effective Smart Home Systems
}
} else bHVACOn = false; // displays current comfort zone (for debugging purposes) oResultPane.AddText("Comfort Zone (min) is " + System.Convert.ToString(comfortZoneMin)); oResultPane.AddText("Comfort Zone (max) is " + System.Convert.ToString(comfortZoneMax)); // take the action depending on the result of the boolean if (bHVACOn) { // turn it on oMonitorCtrlEngine.UpdateLightInputNV(1, FlightControl.OnState); oResultPane.AddText("HVAC is ON."); } else { // turn it OFF oMonitorCtrlEngine.UpdateLightInputNV(1, FlightControl.OffState); oResultPane.AddText("HVAC is OFF."); }
Fire Alarm Logic Flow: /// /// Checking Fire Alarm /// // if the Fire Alarm is switched on if (bFAOn) { // checks whether we need to report the probability of a fire if (belief >= maxBelief) { // add text in the Event Logger oResultPane.AddText("Fire Alarm."); // check whether the alarm is not muted first if (!checkBoxMute.Checked) // enable siren (buzzer) oMonitorCtrlEngine.UpdateBuzzerEnable(FlightControl.OnState); else // mute alarm oMonitorCtrlEngine.UpdateBuzzerEnable(FlightControl.OffState); return; } }
Implementation of Netica API: … // implements Netica BN in the declaration section of the code using Netica; … /// /// NETICA INFERENCE ENGINE VARIABLES /// private double belief; // belief returned by the BN static private Streamer RuleDBFile; // Netica file static private BNet net; // the actual object used ///BN Nodes (only the ones managed by the POC)
104
Project Domus: Designing Effective Smart Home Systems static static static static static …
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
/// display current belief value belief = System.Convert.ToSingle((fireNode.GetBelief("true")) * 100); pBarLikelihood.Value = System.Convert.ToInt32(belief);
105
Project Domus: Designing Effective Smart Home Systems
Appendix C – Test Scripts Test ID:
1
Sub-System:
Application Logic (alternate path)
Severity:
2
Priority:
1
Dependencies: Description:
Testing Exit button in splash screen. 1. Double-click on “Temperature Control System.exe” to launch the
Steps:
application 2.
Click on Exit button.
Expected Result:
The application quits without any error message.
Pass/Fail?
PASS
Details: Workaround: Test ID:
2
Sub-System:
Application Logic (default path)
Severity:
1
Priority:
1
Dependencies: Description:
Testing Continue button in splash screen. 1. Double-click on “Temperature Control System.exe” to launch the
Steps:
application 2.
Click on Continue button.
Expected Result:
The main screen appears.
Pass/Fail?
PASS
Details: Workaround: Test ID:
3
Sub-System:
Device Manager
Severity:
2
Priority:
2
Dependencies:
1
Description:
Adding a new device via the Service Switch button.
Steps:
1. Click on the Monitor button. The Add Device dialog box
106
Project Domus: Designing Effective Smart Home Systems
appears. 2. Expected Result:
From the FT 3150 board, click on the Service Switch button.
The Neuron ID will automatically populate the Text Box.
Pass/Fail? Details:
PASS
Workaround: Test ID:
4
Sub-System:
Device Manager
Severity:
2
Priority:
2
Dependencies:
3
Description:
Adding a new device by entering the Neuron ID manually. 1. Click on the Monitor button. The Add Device dialog box
Steps:
appears. 2.
In the Text Box, enter: 04D5CA75020 and click on the OK button.
Expected Result:
The Drop-down Box in the Main Screen will be populated with the details of the device (“Device … - …), confirming the successful binding.
Pass/Fail?
FAIL
Details:
Error message: “Invalid Neuron ID. The Neuron ID must be specified in 12-digit hexadecimal number.” The number provided in the test seems to be one digit short?!?
Workaround:
Use the Service Switch to populate the number automatically.
Test ID:
5
Sub-System:
Device Manager (FR-01.1)
Severity:
2
Priority:
1
Dependencies: Description: Steps:
Setting HVAC in Manual Mode 1. Tick the Manual Mode Check Box 2. Set the HVAC to ON 3. Move the Comfort Zone slide all the way to the left (min settings) 4. Wait 3 seconds. The HVAC should not change its status 5. Move the Comfort Zone slide all the way to the right (max
107
Project Domus: Designing Effective Smart Home Systems
settings) 6. Wait 3 seconds. The HVAC should not change its status 7. Set the HVAC to OFF 8. Repeat Steps 3 through 6 9.
Un-tick the Manual Mode Check Box
Expected Result:
HVAC system can be operated manually with any temperature range.
Pass/Fail?
PASS
Details: Workaround: Test ID:
6
Sub-System:
Device Manager (FR-01.1)
Severity:
2
Priority:
1
Dependencies: Description:
FA can be turned OFF and ON 1. Set the FA switch to ON
Steps:
2. Wait 3 seconds 3. Set the FA switch to OFF 4.
Wait 3 seconds
Expected Result:
The FA can be turned ON or OFF by the user.
Pass/Fail?
PASS
Details: Workaround: Test ID:
7
Sub-System:
User Interface (FR-02.1)
Severity:
2
Priority:
1
Dependencies: Description:
The system will provide feedback for a user request for an instant command within 3 seconds from the command being issued.
Steps:
1. In the I/O Board ensure that the LS is turned ON (Switch # 4) 2. Ensure that the HVAC is set to automatic (i.e. the Manual Mode Check Box is un-ticked) 3. Move the Comfort Zone slider all the way to the right or left 4. Wait 3 seconds
108
Project Domus: Designing Effective Smart Home Systems
5. Confirms that the HVAC has been turned on (Switch # 2 in I/O Board) and that the UI has been updated accordingly (i.e. HVAC switch is ON) 6. Move the Comfort Zone slider to match the current temperature 7.
Wait 3 seconds Confirms that the HVAC has been turned off (Switch # 2 in I/O Board) and that the UI has been updated accordingly (i.e. HVAC switch is OFF)
Expected Result:
The status of the HVAC switch is refreshed within 3 seconds from the user’s command.
Pass/Fail?
PASS
Details: Workaround: Test ID:
8
Sub-System:
Event Logger (FR 02.2), Event Logger (FR-07.4)
Severity:
2
Priority:
2
Dependencies: Description:
System to record instant command requests and their outcomes for later user retrieval and examination. 1. Take note of the current time and date
Steps:
2. Change the status of the FA switch (e.g. if ON, turn it OFF) 3. Click on te Pause Logging Check Box to Pause the Event Logger 4. Scroll the Log upward to locate the event that correspond to the action (e.g. “Fire Alarm turned ON”) 5. Confirm that the date/time of the event correspond 6. Expected Result:
Un-check the Pause Logging Check Box
The Event Logger recorded the event corresponding to the user’s action with the correct timestamp.
Pass/Fail?
PASS
Details:
The setting seems to be repeated at each cycle in the log.
Workaround: Test ID:
9
Sub-System:
Event Collector (FR-02.4)
Severity:
2
109
Project Domus: Designing Effective Smart Home Systems
Priority:
1
Dependencies: Description:
System to continously evaluate information received by sensors. 1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode
Steps:
Check Box is un-ticked) 2. On the I/O board, ensure that the LS and MS are deactivated (Switch # 3 and 4 OFF) 3. Move the Comfort Zone slider all the way to the left (min settings). The HVAC should remain turned off 4. On the I/O board, activate the LS (Switch # 4 ON) 5. Expected Result:
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:
Event Logger (FR-03.12)
Severity:
2
Priority:
2
Dependencies: Description:
System storing command issued and confirmed system changes in an Event Log.
Steps:
1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode Check Box is un-ticked) 2. On the I/O board, ensure that the LS is active (Switch # 4 ON) 3. Move the Comfort Zone Slider anywhere in the scale 4. Click on te Pause Logging Check Box to Pause the Event Logger 5. Scroll the Log upward to locate the latest entry for the events “Comfort Zone (min)” and “Comfort Zone (max)” 6. Check that the two values (min and max) are within 5% of the value displayed at the right of the Comfort Zone slider (e.g. 23) 7. Un-tick the Pause Logging Check Box 8.
Expected Result:
Repeat Steps 3 through 7 for a other two Comfort Zone values
Changed in the Comfort Zone (min) and (max) are recorded in the Event
110
Project Domus: Designing Effective Smart Home Systems
Log. Pass/Fail?
PASS
Details:
The calculated values seems to be rounded up/down (e.g. 5% of 15 is 0.75; 5% of 28 is 1.4 but the min/max values are always +1/-2 degrees.
Workaround: Test ID:
11
Sub-System:
User Interface (FR-04.1)
Severity:
2
Priority:
3
Dependencies: Description:
System supporting keyboard accelerators (i.e. ALT+Key) as secondary ways to access all main features 1. Press the ALT key once
Steps:
2. Confirm that the keyboard accelerators are enabled by noticing that the Exit button has the “x” underlined (i.e. “Exit”) 3. Locate an underlined command (e.g. Mute Alarm) in the UI and make sure that it can be operated by using the ALT key plus the underlined letter (e.g. ALT + A) 4. Confirm that the command has bee executed (UI and Event Log) 5.
Repeat Steps 3 through 4 until all keyboard accelerators have been tested.
Expected Result:
Keyboard accelerators will allow commands to be issued without the use of the mouse.
Pass/Fail?
PASS
Details: Workaround: Test ID:
12
Sub-System:
User Interface (FR-04.6)
Severity:
2
Priority:
1
Dependencies: Description:
All main features can be operated with less than three actions (e.g mouse clicks)
Steps:
1. Note how many clicks or keyboard commands are required to perform the following operations:
111
Project Domus: Designing Effective Smart Home Systems
Expected Result:
•
Turn the FA ON
•
Turn the FA OFF
•
Turn the HVAC ON
•
Turn the HVA OFF
•
Set the HVAC to Manual Mode
•
Set the HVAC to Automatic Mode
•
Bind a LonWorks Device (see: Monitor button)
•
Mute FA Alarm
•
Change FA Hight Temperature
•
Change HVAC Comfort Zone
•
Change the FA Sensitivity
•
Pause/Resume Event Logging
•
Exit the Application
None of the operation listed will require more than three actions to be completed.
Pass/Fail?
PASS
Details: Workaround: Test ID:
13
Sub-System:
Device Manager (FR-09.2), Device Manager (FR-10.1), Device Manager (FR-10.2)
Severity:
2
Priority:
3
Dependencies: Description:
System will identify the devices connected using a unique identifier withing the same Network ID.
Steps:
1. Ensure that the FT3120 board is connected to the LonTalk network and turned ON 2. Click on the Monitor Button 3. On the FT3120 board, press the Service Switch 4. Confirm the Neuron ID provided in the Text Box by clicking the OK Button 5. Confirm that the Drop-Down box now contains two both devices (Device 1… and Device 2…) and that they are uniquely identified by their Neuron ID 6.
Confirm that the two devices are part of the same Network ID
112
Project Domus: Designing Effective Smart Home Systems
(9F:FF:FF:20:00:05:04:01) Expected Result:
Each LonWorks device will be uniquely identified in the same Network ID.
Pass/Fail?
PASS
Details:
Neuron ID of Device 2: 04284CAF0200
Workaround: Test ID:
14
Sub-System:
Fire Alarm Logic (default path)
Severity:
1
Priority:
1
Dependencies: Description:
FA should not be triggered if the Sensitivity threshold is not reached 1. Ensure that the FA is not active (UI and Switch # 1 in I/O Board
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:
Fire Alarm Logic (alternate path)
Severity:
1
Priority:
1
113
Project Domus: Designing Effective Smart Home Systems
Dependencies: Description:
FA should be triggered when the Sensitivity threshold is reached 1. Ensure that the FA is not active (UI and Switch # 1 in I/O Board
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:
FA wil be triggered if the Fire Probability reported matches or is beyond the Sensitivity Value.
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:
Fire Alarm Logic (default path)
Severity:
2
Priority:
1
Dependencies: Description: Steps:
Checking whether it is possible to mute an alarm 1. Ensure that the FA is not active (UI and Switch # 1 in I/O Board is set to OFF) 2. Ensure that the Mute Alarm is un-ticked
114
Project Domus: Designing Effective Smart Home Systems
3. Ensure that the Pause Logging is un-ticked 4. Move the Sensitivity Slider all the way to the left (minimum value, 5%) 5. Set the Hight Temp Text Box to a value that is just above the current temperature reported 6. Activate the FA by using the UI Switch 7. Confirm that the FA is active (Switch # 1 in I/O Board is ON 8. Find a way to increase the temperature reported by the sensor on the I/O Board 9. Wait until the current temperature matches or goes beyond the one set in the High Temp Box 10. Confirm in the Event Logger that the Fire Probability has reached or gone beyond the Sensitivity value 11. When the Alarm is triggered (buzzer sounds), tick the Mute Alarm Check Box 12. Confirm that the FA is active (Switch # 1 in I/O Board is still ON Expected Result:
Buzzer stops.
Pass/Fail?
PASS
Details: Workaround: Test ID:
17
Sub-System:
Fire Alarm Logic (alternate path)
Severity:
1
Priority:
1
Dependencies: Description: Steps:
Triggered FA alarm will always cause the alarm to sound initially 1. Ensure that the FA is not active (UI and Switch # 1 in I/O Board is set to OFF) 2. Ensure that the Mute Alarm is ticked 3. Ensure that the Pause Logging is un-ticked 4. Move the Sensitivity Slider all the way to the left (minimum value, 5%) 5. Set the Hight Temp Text Box to a value that is just above the current temperature reported 6. Activate the FA by using the UI Switch 7. Confirm that the FA is active (Switch # 1 in I/O Board is ON 8. Find a way to increase the temperature reported by the sensor
115
Project Domus: Designing Effective Smart Home Systems
on the I/O Board 9. Wait until the current temperature matches or goes beyond the one set in the High Temp Box 10. Confirm in the Event Logger that the Fire Probability has reached or gone beyond the Sensitivity value 11. When the buzzer sounds, turn the FA OFF Expected Result:
Mute Alarm check box is automatically un-ticked and the buzzer sounds.
Pass/Fail?
FAIL
Details:
Mute Alarm doesn’t get un-ticked.
Workaround: Test ID:
18
Sub-System:
HVAC Logic (alternate path)
Severity:
2
Priority:
2
Dependencies: Description: Steps:
Energy saving scheme will be enabled at night-time 1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode Check Box is un-ticked) 2. On the I/O board, ensure that the LS is not active (Switch # 4 OFF) 3. Move the Comfort Zone Slider anywhere in the scale 4. Click on te Pause Logging Check Box to Pause the Event Logger 5. Scroll the Log upward to locate the latest entry for the events “Comfort Zone (min)” and “Comfort Zone (max)” 6. Check that the two values (min and max) are within 15% of the value displayed at the right of the Comfort Zone slider (e.g. 23) 7. Un-tick the Pause Logging Check Box 8.
Repeat Steps 3 through 7 for other two different Comfort Zone values
Expected Result:
Changed in the Comfort Zone (min) and (max) are recorded in the Event Log.
Pass/Fail?
PASS
Details:
Calculated values seem rounded up/down to the nearest unity (e.g. 1.24 = 1; 2.4 = 2).
Workaround:
116
Project Domus: Designing Effective Smart Home Systems
Test ID:
19
Sub-System:
HVAC Logic (alternate path)
Severity:
2
Priority:
2
Dependencies: Description:
MS may cause the HVAC to be turned on at night if the temperature is outside the comfort zone 1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode
Steps:
Check Box is un-ticked) 2. On the I/O board, ensure that the LS and MS are not active (Switch # 3 and 4 OFF) 3. Move the Comfort Zone Slider to a value that is at least +/- 20% away from the current temperature 4. Wait 3 seconds 5. Confirm that the HVAC remains OFF 6. On the I/O Board, set MS to active (turn Switch # 3 ON) 7. Expected Result:
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:
HVAC Logic (alternate path)
Severity:
2
Priority:
2
Dependencies: Description:
MS may not cause the HVAC to be turned on at night if the temperature is still within the comfort zone
Steps:
1. Ensure that the HVAC is set to automatic (i.e. the Manual Mode Check Box is un-ticked) 2. On the I/O board, ensure that the LS and MS are not active (Switch # 3 and 4 OFF) 3. Move the Comfort Zone Slider to a value that is within +/- 15% the current temperature 4. Wait 3 seconds
117
Project Domus: Designing Effective Smart Home Systems
5. Confirm that the HVAC remains OFF 6. On the I/O Board, set MS to active (turn Switch # 3 ON) 7. Expected Result:
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:
HVAC Logic (default path)
Severity:
2
Priority:
2
Dependencies: Description:
HVAC set in automatic mode will be turned OFF if not required 1. Ensure that the HVAC is set to manual (i.e. the Manual Mode
Steps:
Check Box is ticked) 2. Turn the HVAC ON 3. On the I/O board, ensure that the LS is active (Switch # 4 ON) 4. Move the Comfort Zone Slider to a value that matches the current temperature 5. Un-tick the Manual Mode Check Box 6. Expected Result:
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:
HVAC Logic (alternate path)
Severity:
2
Priority:
1
Dependencies: Description: Steps:
HVAC in manual mode will not be turned ON in any circumstance 1. Ensure that the HVAC is set to manual (i.e. the Manual Mode Check Box is ticked)
118
Project Domus: Designing Effective Smart Home Systems
2. Move the Comfort Zone Slider all the way to the left (min value) 3. Wait 3 seconds 4. Move the Comfort Zone Slider all the way to the right (max value) 5.
Wait 3 seconds
Expected Result:
The HVAC will not be operated automatically when in Manual Mode.
Pass/Fail?
PASS
Details: Workaround: Test ID:
23
Sub-System:
Application Logic (default path)
Severity:
2
Priority:
1
Dependencies: Description:
Application can be successfully terminated. 1. Click on the Exit Button
Steps: Expected Result:
The application quits without error messages.
Pass/Fail?
PASS
Details: Workaround:
Appendix D – Bayesian Network Probability Tables Node:
Summer (su)
Probabilities:
Node:
True
False
.40
.60
True
False
.20
.80
Cooking Time (ct)
Probabilities:
119
Project Domus: Designing Effective Smart Home Systems
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:
High Temperature (ht)
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
Project Domus: Designing Effective Smart Home Systems
P(ht | su ¬hvo dt ct) P(ht | su ¬hvo dt ¬ct) P(ht | su ¬hvo ¬dt ct) P(ht | su ¬hvo ¬dt ¬ct) P(ht | ¬su hvo dt ct) P(ht | ¬su hvo dt ¬ct) P(ht | ¬su hvo ¬dt ct) P(ht | ¬su hvo ¬dt ¬ct) P(ht | ¬su ¬hvo dt ct) P(ht | ¬su ¬hvo dt ¬ct) P(ht | ¬su ¬hvo ¬dt ct) P(ht | ¬su ¬hvo ¬dt ¬ct)
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
Fire Danger (fd)
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
Project Domus: Designing Effective Smart Home Systems Appendix E – Project Plan
Appendix F – Risks and Contingency Plans Risk Name Cannot get the hardware required Do not know what technology to use
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
Although I have been doing system design and programming in the past, I have since move out that field over ten years ago and it might take some time to brush up this skill again. I will need to take this into account in the project schedule.
Tight timeframe
The project is to be presented in early April 2009, which will realistically leave around 12 weeks for researching, designing, coding and testing the system.
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.
Project Domus: Designing Effective Smart Home Systems
i
http://www.the-original-epcot.com/2008/05/epcot-film-video.html (accessed on 18 February 2009)
ii
http://newsroom.cisco.com/dlls/fspnisapi3934.html
iii
http://architecture.mit.edu/house_n/
iv
http:// research.microsoft.com/en-us/um/people/marycz/el.doc
v
http://www.cs.colorado.edu/~mozer/nnh/
vi
http://www.smarthome.duke.edu/home/
vii
http://awarehome.imtc.gatech.edu/
viii
http://www.cenelec.eu/Cenelec/CENELEC+in+action/Horizontal+areas/ICT/SMARTHOUSE+-
+PHASE+II.htm ix
http://www.insteon.net
x
http://www.plcbus.com.cn/
xi
http://www.pulseworx.com/
xii
http://www.knx.org/
xiii
http://www.echelon.com
xiv
http://www.clipsal.com/
xv
http://www.upnp.org/
xvi
http://www.zigbee.org/
xvii
http://www.zen-sys.com/
xviii
http://www.bacnet.org/
xix
http://www.modbus.org/
xx
http://research.microsoft.com/en-us/um/people/horvitz/Lumiere_big.wmv (accessed on 18 Feb 2009).
123
