Benchmarking smart homes using a humanoid robot approach

PDF ( .pdf )

BENCHMARKING SMART HOMES USING
A HUMANOID ROBOT APPROACH

















By

SATISH KUMAR VEERAPUNENI


A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2004

































Copyright 2004

by

Satish Kumar Veerapuneni


































TO MY WONDERFUL FAMILY















ACKNOWLEDGMENTS

I express my gratitude to Dr. Abdelsalam (Sumi) Helal for his encouragement,

support and valuable feedback from time to time throughout my thesis. I would also like

to thank Dr. Shigang Chen and Dr. Herman Lam for agreeing to serve on my committee.

I have a list of friends to thank for their help and contribution to my thesis. Firstly, I

would like to thank Steve Vander Ploeg and Harsha Munikoti for the great contribution in

the making of Robotilda, a key tool in my benchmarking tests. Secondly, I would like to

thank all the other Pervasive computing/Harris lab-mates for their support. I have a

special thanks to Dr. Choonwa Lee a recent graduate of the Pervasive Computing Lab for

his support in making of my thesis.

Lastly, I would like to thank my parents and relatives for being with me every

moment in life and supporting me in my endeavors.
















TABLE OF CONTENTS
Page

A C K N O W L E D G M E N T S ................................................................................................. iv

LIST OF TABLES ................................................... vii

LIST OF FIGURES ............... ................. .. ......... ............................ viii

ABSTRACT .................................................... ................. ix

CHAPTER

1 IN T R O D U C T IO N ................................................. .............................................. .

2 SMART HOME SURVEY ................................................................ ...............3......

2.1 R obotilda Sm art H om e ................................................................... ...............4...
2 .2 M illennium H om e ... ... ........................................... ....................... .... ......... ... 5
2.3 House_n Project ..... .. ................... .......... .............................7
2 .4 A w are H om e ................................................................................................... 9

3 METRICS TO EVALUATE THE SMART HOME..................................................11

3 .1 In tru siv e n e ss ......................................................................................................... 12
3 .2 S c alab ility ............................................................................................................. 13
3 .3 H etero g en eity ........................................................................................................ 13
3 .4 S e cu rity ................................................................................................................ 1 3
3.5 R em ote M maintenance ................................................................... ............... 14
3 .6 A to m ic ity .............................................................................................................. 14
3 .7 D u rab ility .............................................................................................................. 1 5
3 .8 Iso latio n ............................................................................................................... 1 5
3 .9 P ri v a cy .............. ............................................................................................... . 1 5
3.10 User Friendliness/Experience ....................... ............................................. 16
3 .1 1 C o n tro llab ility ..................................................................................................... 16
3.12 Anomaly Detection .................................................................. ............... 16
3 .1 3 L ate n cy ............................................................................................................... 1 6

4 IM PL E M E N T A T IO N ... ........................................................................................ 18

4 .1 T e st B e d ................................................................................................................1 8



V









4.1.1 Robotilda Smart Home Architecture .............. .................................... 18
4.1.2 C context D discovery ................. ......................................................... 18
4.1.3 Services and A applications ....................... .......................................... 19
4 .1.4 P rototype............................................................................................. 20
4.2 H um anoid R obot A approach ............................................................. ................ 22
4 .2 .1 M making of R obotilda.............................................................. ................ 22
4.2.2 D esign of R obotilda...................................... ...................... ................ 22
4.2.3 C om ponents ... ................................................................... ... ............ 24
4.2.3.1 B um p Sensors ................................................. ..... ... .. ........ .... 25
4.2.3.2 IR Proxim ity D etectors................................................ ................ 25
4 .2 .3.3 C ontroller ................................................................................. 26
4 .2 .4 Softw are in R obotilda .......................................................... .. ................ 28
4.2.4.1 Programming the ATmega 128 .............. ....................................28
4.2.4.2 Softw are for the IPA Q s ............................................... ................ 29
4.2.4.3 C configuration and Setting ........................................... ................ 31
4.2.5 D evelopm ent Environm ent.................................................... ................ 32
4.2.5.1 V isual Studio .N ET 2003 ................................................... 32
4.2.5.2 WIN AVR ... ...... ........................................................ 33
4.3 B enchm parking and Experim ents...................................................... ................ 34
4.3.1 Determining Various Metrics that Evaluate the Benchmark...................38
4.3.2 Sketch the Metric-Trees for Each of the Metric....................................38
4.3.3 Evaluate the Metric-Value for Each of the Metric-Tree..........................41
4.3.4 Sketch the Benchmark-Tree for the Smart Home .................................42
4.3.5 Evaluate the Benchmark for the Smart Home.......................................43
4.4. Benchmarking the Location Positioning System............................................43
4.4.1 Determining Various Metrics that Evaluate the Benchmark...................44
4.4.2 Sketch the Metric-Trees for Each of the Metric....................................45
4.4.3 Evaluate the Metric-Value for Each of the Metric-Tree..........................46
4.4.4 Sketch the Benchmark-Tree for the Location Positioning System ............46
4.4.5 Evaluate the Benchmark for the Location Positioning System...............47

5 CONCLUSION AND FUTURE WORK ..............................................................49

L IST O F R E F E R E N C E S ...................................................................................................50

BIO GR APH ICAL SK ETCH .................................................................... ................ 53
















LIST OF TABLES

Table page

4-1 Binary Analysis of Benchmarking Metrics.........................................................34

4-2 Sm art H om e Latency Chart.................................... ....................... ................ 36

4-3 N-ary Analysis of Benchmarking Metrics ..........................................................38

4-4 L ist of M etric V alues... ................................................................... ............... 41

4-5 L ist of M etrics Precedence........................................ ....................... ................ 42

4-6 C um ulative M etric M atrix ........................................ ........................ ................ 43

4-7 L ist of N eeded M etrics ..................................................................... ................ 44

4-8 Lps Metric Matrix ...................................... ........ ................... 45

4-9 L ist of lps M etric V alues.......................................... ......................... ................ 46

4-10 List of lps Metrics Precedence .............. ............... 47

4-11 L ist of lps C um ulative M etrics............................................................ ................ 48
















LIST OF FIGURES

Figure page

2-1 The R ER C Sm art H house ................... .............................................................4......

2-2 M illennium H om e Floor Plan ...................................... ...................... ...............5...

2 -3 P lacelab ........................................................................ .................................. . 7

2-4 A w are H om e .............. ...................................................................9...........

4-1 Reference Middleware Architecture for Assistive Environments.........................19

4-2 B lock D iagram for the B ase.................................... ....................... ................ 23

4-3 T ecel M otor D river ... ... ........................................... ....................... ............... 24

4 -4 R o b o tild a ................................................................................................................ .. 2 5

4-5 A vr B ootloader ............. .. .................. .................. .......................... ............27

4-6 IPA Q C ontroller Interface..................................... ........................ ................ 30

4 -7 IP A Q S erv er ............................................................................................................. 3 1

4-8 Sm art H om e B enchm ark Tree............................................................. ................ 42

4-9 H/M/L Calculation .................................. ......... ...... ...............43

4-10 Location Positioning System Benchmark Tree...................................................47

4-11 lps H /M /L C alculation ...................................................................... ...............47















Abstract of Dissertation Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

BENCHMARKING SMART HOMES USING THE HUMANOID ROBOT
APPROACH

By

Satish Kumar Veerapuneni

August 2004

Chair: Abdelsalam (Sumi) Helal
Department: Computer and Information Science and Engineering

A smart home in simple terms is an entity comprising of devices that can be

controlled via the Internet. As smart homes have greatly penetrated the market place in

the recent decade, various organizations have developed there own proprietary stack and

therefore interoperability has become a major bottleneck.

This has put forth the need to benchmark, that could help evaluate the "smart

homes." To address the problem of knowing how smart the home is, there was a need to

have human-like robot to emulate the person staying in the smart home as this would

trigger applications based on some specific sensory inputs placed on it.

This thesis was accomplished in various stages; we have built Robotilda a

humanoid robot named Matilda that is controlled by a PDA via a wireless network.

Secondly, we have defined an n-ary tree model (i.e. a tree with up to n metric tree nodes

as its children which in turn are n-ary trees) that is used to evaluate the smart home. To

this end, we have performed benchmark tests using an intuitive/binary model in the mock









smart home at the pervasive computing lab, to evaluate the metric values of various

metric trees. Further, the benchmark value of the benchmark tree is evaluated by a

weighted average of the children nodes, in a post order fashion. Finally, an illustration on

using the general benchmark mechanism to evaluate a component of the smart home, i.e.

the location positioning system, is demonstrated. This is chosen for illustration purposes

as Robotilda's position is determined by the Location Positioning System, which in turn

invokes various applications in accordance to the location context.














CHAPTER 1
INTRODUCTION

The steep decrement in the cost of integrated circuits and advances in their design

over the years, in accordance to "Moors Law [1], has made the creation of a smart

device possible with great ease. The expansive growth and penetration of the internet

with cost effectiveness of the smart devices over the years, has increased adoption of

smart devices.

A smart home in simple terms is an entity comprising of devices that can be

controlled via the internet. For instance, in the pervasive computing lab at UFL [2] the

mock smart home is the entity and the other house hold items like the microwave, TV,

bed light, etc are the devices that can be controlled via the internet. The programmability

and the connectivity of devices entice people to use them in ways that could only be

dreamt of in the past. smart homes in essence help improve the quality of life of people.

As smart homes have greatly penetrated the market place in the recent decade,

various organizations have developed there own proprietary stack for the smart home and

hence interoperability is a major bottleneck for the solutions developed. This thereby has

lead to increased need for transparency and portability of the software used to help

achieve smartness.

At the pervasive computing lab at UFL, we have envisioned a layered architecture

for the software used in the smart homes that address the problem of interoperability.

Openness is achieved as the architecture developed is platform independent.

Transparency with a layered architecture is achieved as the upper layer could perform the









task of reading a location coordinate of the person living just by calling a lower layer's

class method without bothering about the intricacies involved in the process of obtaining

it.

In recent years, many organizations have developed their own interoperable stacks

for the smart homes. This has hence put forth the need to benchmark [3], which could

help evaluate various "smart homes." To address the problem of knowing which is the

smartest, there is a need to have human-like robot to emulate the person staying in the

smart home as this would trigger applications based on some specific sensory inputs

placed on it.

This thesis is organized as follows. Chapter 2 presents various initiatives in

building smart homes. Chapter 3 is an overview of the metrics for benchmarking smart

homes. Our approach for the solution proposed is presented in Chapter 4. Finally, the last

chapter, i.e. chapter 5 presents the future work and the conclusions.














CHAPTER 2
SMART HOME SURVEY

A home or a working environment that includes technology to control the devices

and the environment could be termed as a smart home. The extent in which the home

could be controlled is dependent on various factors like: one's own wish, investment

willing to make in the technology, etc. In a traditional smart home environment, one

could have two types of interactions, user initiated or system initiated. For instance, home

automation can assist a person to control a device in another part of the house, inquire

into the state of something (e.g. Is the electric light on or off? Is the front door open or

closed? Is the television on/off? Is the shower on/off?). This can facilitate

communications and enhance both personal and building security. On the other hand, the

controller can also suggest appropriate actions when necessary, (e.g. It could prompt,

should you not turn down the cooker? The tub takes a few minutes to fill up, please wait?

Your favorite program is aired on television, tune into channel 10? Don't touch the food,

the food is hot?) People who have short-term memory problems such as those with head

injuries or those with Alzheimer's disease [4] may find the later attribute of the smart

home very appropriate.

In this chapter I have discussed a few on going renowned smart home projects like

the RERC Smart Home Project (UFL), Millennium Project(Berlin) [5], House_n

Project(MIT) [6, 7], Aware Home Project(Gatech) [8]. One thing in common to all the

above listed projects is that, all of them have an aim to address, i.e. make living easy for

people, by using technology as an enabler.










2.1 Robotilda Smart Home

The RERC Smart House (Figure 2.1) occupies about 500 sq. ft. in the University of

Florida Pervasive Computing Laboratory. The house consists of a bedroom, a bathroom,

a living room, and a kitchen. This house serves as a development platform and in-

laboratory test bed of a prototype system and applications.



Monitor A sensor





Monitor B




(0,0) Monitor C



Figure 2-1. The RERC Smart House


As indicated in Figure 2.1, four ultrasonic receivers are placed in the ceiling above

each corner of the house perimeter. Also, four flat panel monitors are mounted on each

wall to deliver visual messages to the occupant. The mockup house is instrumented with

other sensors and devices, including J2ME smart phones [9, 10] as user devices, floor

sensors, water leak sensors, RFID tags, X-10 controlled devices (door, mailbox, curtain,

lamp, and radio), and networked devices (microwave, fridge, and cameras).

The heart of the smart house is the ultrasonic location system [11, 12]. Applications

in the smart home like Modia [13] (essentially, smart controller of all the appliances) use

for instance the location context information to switch to the appropriate monitor in the

house. Besides, this context places a key role in determining any sort of anomaly, like









falling down on the floor, at home and let the caregiver know if necessary. This

essentially is done using the logging of the data and analyzing it through an anomaly

detection algorithm.

2.2 Millennium Home

It's a smart home project initiated by the biotechnology department at the Brunel

University, along with a group of industry leaders. The goal of this project was to build a

system that is a fool proof solution to Anomaly detection in homes.













.. I

















Figure 2-2. Millennium Home Floor Plan

One of the unique aspects of the Millennium home project is that the person living

in the smart home is provided with an alarm sensor, which in turn would allow the









resident to interact with it. As was described in the technical document of the project the

following are amongst some of the sensors used in the home:

* Passive infra-red sensors (PIRs) to detect movement

* Custom made pressure sensors which will be placed underneath the legs of chairs
and beds to detect whether the user is sitting or lying down

* Burglar alarm style sensors on windows and doors

* A simple custom-made body count sensor on the main entrance to the property so
that the system will know how many people are in the property at any one time.


Besides, the system initiated events, the project also implemented various user

initiated events for instance, a multimodal interface, based around speech, is one of which

used to relay user initiated events to the underlying system. The system communicates to

the resident through on the following means:

* Loudspeakers placed in all rooms

* The television screen (activated though a computer)

* The telephone, which can ring the resident (activated though a computer)

The resident will also communicate with the system through:

* Voice recognition

* The activation of environmental sensors (e.g. shutting a door)

* A yes/ no button for simple communications

In order to enable voice recognition, a capability to being able to control some

noisy domestic equipment using the X10 protocol is provided too. Shown in Figure 2.2

are some of the key sensors used in the Millennium home.









2.3 House_n Project

The House_n consortium at MIT has designed a unique "living laboratory" (Figure

2.3) shared research facility called the PlaceLab. This is sighted in various references to

be one of the very first initiatives on smart home environments. Hundreds of sensing

components have been installed in nearly every part of the home, which is a one-bedroom

condominium in a residential building. These sensors are being used to develop

innovative user interface applications that help people easily control their environment,

save resources, remain mentally and physically active, and stay healthy. The sensors will

also be used to monitor activity in the environment so that researchers can carefully study

how people react to new devices, systems, and architectural design strategies in the

complex context of the home.

















Figure 2-3. Placelab

The home is occupied by volunteer subjects who agreed to live in the home for

varying lengths of time. While they occupy the facility they will have no contact with

researchers, and the laboratory has been designed so that data can be analyzed off the

site. Researchers will have the capability to monitor nearly every aspect of life in the









home, particularly what people are doing and the interior and exterior environmental

conditions. Tools for the semi-automatic annotation and pruning of data aids researchers

studying the enormous amounts of data acquired daily by the laboratory. Some

occupants are studied living in their own home environments as well using a portable

toolkit of sensors that has been developed by MIT researchers. These devices make

remote monitoring of people in their own homes possible for some period of time before

and after they enter the PlaceLab in order to investigate pre and post-occupancy behavior

changes.

In essence, the project essentially is used to investigate the following questions

about human behavior, among others:

* What influences the behavior of people in their homes?

* How can technology be effective in the home context for long time periods?

* Can technology and architectural design motivate life-extending behavior changes?

* To what degree can measurements of activity in the home be quantified in a way

useful for creating new computer applications for the home?

* How can technology be used to simplify the control of homes of the present and

future, save resources, and improve health?

* What influences how people adjust to new environments?

* How do people learn in the context of the home?

* What new innovations for the home would most fundamentally alter the way we

live our everyday lives?

To be able to delve into various areas of research like proactive health care,

analyzing activities of daily life, monitoring using biometric devices, testing indoor air









quality, privacy protection, etc for the smart home environment, various components like

microcontroller and light sensor, motion sensor, humidity sensor, smoke detector, IR

illuminator, IR motion sensor, C02 sensor, barometric pressure sensor, IR transmitters

microphones, 1-wire network connection, Ethernet connection, and power are

incorporated into the living-home.

2.4 Aware Home

The Aware Home is a project initiated by Georgia Institute of Technology. It is also

referenced along with the House_n project to be one of the very first in the smart home

research initiative. This home has essentially two identical and independent living spaces,

consisting of two bedrooms, two bathrooms, one office, kitchen, dining room, living

room and laundry room. In addition, there is a shared basement with a home

entertainment area and control room for two centralized computing services.


Figure 2-4: Aware Home









The reasons for building two independent living spaces are to allow for controlled

experiments with technology and to allow inhabitants to live on one floor while

prototyping or providing demonstrations on the other floor. The initial occupants are

students involved in the research project living in only one floor of the house. A longer-

term goal is to have both floors occupied by a family or elderly occupants, as these are

the targeted groups of there research. These occupants will give more realistic feedback

on the performance of systems within the house. This systems includes sensors like

human position tracking using ultrasonic technology, RF technology [14] and video,

recognition through floor sensors and vision techniques among various other sensors

similar to the other smart home initiatives discussed previously.














CHAPTER 3
METRICS TO EVALUATE THE SMART HOME

This chapter talks about the need to benchmark and the metrics we consider

important for benchmarking a smart home [15, 16]. To motivate in this direction, some of

the questions that come to mind while considering getting oneself a smart home are the

following:

* Would the smart home be intervening in my daily tasks?

* Would the smart home allow me to interact with it to perform a specific task (for

instance, tell the air conditioner to lower the temperature, tell the fireplace to switch

on/off)?

* Would I be able to switch the smart home to non smart mode when desired (This

conserves a lot of energy (power/cost))?

* Would I be able to change the smartness level of the home, say not allow a

particular feature to work for a given period of time?

* Is my privacy lost?

* How easy is it to upgrade the system with new features (I have a new feature like a

smart floor added to the existent system, how easy is it to integrate it to the existent

home?)?

* Is the smart home adaptable to additions made, with ease (I have one more person

in the smart home joining me for a certain period of time, one expects the home to









be able to accommodate him i.e. help him take full advantage of the smartness of

the home?)?

* Does having a smart home lower my self-confidence?

* Is the smart home secure enough from intruders, as it's always on the network? Do

I have authentication mechanisms to ensure my system doesn't get compromised?

* Is the smart home making living easier for me, i.e. is the smart home an enabler?

* Is the smart home cost-effective?

These are just a few of the innumerous questions that one has in his/her mind. To

address the above questions we need a model to analyze the smartness of the home. In the

pervasive Computing Lab here at UFL, we have come up with a few metrics to help

evaluate a smart home. I have assumed that there are two inhabitants in the smart home

named Alice and Bob for illustrative purposes. The following would state and give a brief

description of the metrics.

3.1 Intrusiveness

If Alice or Bob are scheduled to have the medicine and the medicine box is empty,

the assumption is the smart house would get them refilled before the medicine box is

empty and hence the box is never to be seen empty. If this didn't happen and the house

expects the intrusion of the person living in getting the medicine box refilled, there is

great dependency by the smart home for events to be performed. In sum, the smart home

should be proactive towards a given task and not dependable on its residents for periodic

tasks like medicine box refilling.









3.2 Scalability

Alice bought the smart house from a third party, i.e. with a proprietary stack built

(i.e. the software used to achieve smartness in the house, typically called stack in

computer science terms) by say "XYZ". Later Alice got married to Bob and Bob's

presence/addition to the house has to be noted into the smart environment. We need to be

able to add new features to the house with ease. In the Alice/Bob's world it should never

be the case where in a change to the whole system has to be performed to get Bob into

the system. In sum, scalability to a given system is generally considered to be one of the

prerequisites to help achieve market presence.

3.3 Heterogeneity

When Alice gets an additional smart component say a refrigerator and fits it into

the smart home and then Bob gets another i.e. a smart microwave and fits it into the

system, they should not have problems installing them into the system because both the

components were not made by the same manufacturer and also not the same company

that provided the smart home for Alice and Bob. The smart home should be able to

accommodate technologies from various providers i.e. "XYZ" could have its own smart

gas/electricity system installed and fitted into the smart home made and assembled by

"ZYX".

3.4 Security

Alice and Bob do not want intruders to access the system. The maintenance guy of

the smart refrigerator could occasionally peek into the system and see if everything from

the smart refrigerator's perspective is functioning alright. If say Chuck now tries to

intrude into the system and try control/modify a few system components, he should be

forbidden from doing so, besides notifying the residents/service providers of a possible









intrusion (this is achieved by using an authentication module in the system). The security

of the home could be achieved by restraining the access in a very "sand box" like

manner. The home could define protection domains, for instance in the smart

refrigerator's case, the maintenance guy though given ability to get into the system and

watch the smart refrigerator's performance from time to time, is not allowed to get into

the smart microwaves domain. This by en large is achieved by defining boundaries for

the systems in use by the house. In sum, security is becoming increasingly important to

create a complete fool proof system.

3.5 Remote Maintenance

As was just pointed out in the previous metric, the system after bought from the

third party has to undergo maintenance, to achieve good performance from time to time.

It's said that most of the companies achieve good top line benefits if their after sales

service is good. To help this happen the system should have a provision to help

maintenance people have access to the component. Besides, there should be an evening

mechanism in the system to notify the maintenance people of any potential hazard

detected in the system to help be proactive/reactive in there job.

3.6 Atomicity

If the house has sequence of operations performed for a given context. Say if the

person is in the kitchen in front of the stove at location (x, y), the following events like

the stove preparing itself to heat up, the over head light switching on, the exhaust fan

getting switched on, the music system getting switched on, etc should get performed in a

sequence. All these happen in a sequence only when the given person, in our case Alice is

at the location (x,y) and in front of the stove. We can't come across a situation where in

all the above accept the exhaust getting switched on, this would be inappropriate to the









cooking event. Hence the system should have a property of all or none getting performed,

i.e. either all the events dependent on a given context (a set of location /time/ person)

none of them being performed, also in the later case throwing an exception to the

maintenance guy/owner of that particular system to perform the maintenance/checking

operation.

3.7 Durability

As was mentioned for the previous metric, We have a sequence of events

performed in an all or none fashion if and only if one is sure all of them are functioning

properly and not being used by other's at that instant. By this we mean the event should

be done once the commitment of the system to the given context is achieved.

3.8 Isolation

If say both Alice and Bob want to perform a given event on the system, both the

events are serialized to achieve isolation i.e. achieve serial execution of the tasks, hence

there are no conflicting operations though there are two or more events happening at the

same time. Indeed, this is what happens at the architecture level. But at the processor

level, we have the both events performed concurrently as the whole system is built on a

shared memory single processor system. Besides, isolation is also associated with

adaptability i.e. making the smart home smart based on what is needed to the given user.

3.9 Privacy

People living in a smart home are afraid of compromise to there privacy as the

whole system is hooked up to the internet. Hence it's extremely important to help the

residents be aware of the fact that they are monitored if done so. This at least does away

with the fact of being conscious in a smart environment. Besides, the residents should

have full control on whether to allow others to monitor the smart home or not.









3.10 User Friendliness/Experience

The house should not be complicated to use for the residents, say if Alice wants to

use the smart tub and is not able to figure out how to use it, the whole premise of making

it smart to help achieve great end user experience is useless. Hence the smartness

incorporated in the environment should easily sink into the daily deals of the resident.

3.11 Controllability

Alice should be able to control a microwave in the same conventional manner if he

wants to. Hence the conventional way of doing things should not be lost because of the

incorporation of smartness into the device. For instance, if Alice wants to use the smart

microwave by operating on the digital buttons he should be able to do it despite

incorporation of RFID, etc technology to read the food items and set the time for the

cooking automatically.

3.12 Anomaly Detection

The smart home should be able to detect if there is any sort of anomalies in the

environment and determine the appropriate action to be taken. Say, if Alice is observed

falling more than a specified (threshold specified in the system) number of times by the

system, using anomaly detection algorithms on the data that is logged at the home

computer for a given period of time, Alice's personal care taker should be informed of

this by the system.

3.13 Latency

The time taken for a given event to be performed should be within human

acceptable range. Typically the human reaction time for an event is 2/3 rd of a second. If

events take approximately within this time to perform the action, then the system is said

to achieve six sigma level of performance. Although it's impossible to achieve this in real






17


systems where the latencies range typically from one to five seconds, smart home system

developers for good are increasingly concentrating on reducing the latency associated

with the system














CHAPTER 4
IMPLEMENTATION

4.1 Test Bed

4.1.1 Robotilda Smart Home Architecture

Most of the smart environment initiatives have focused on specific technologies to

build the smart spaces, overlooking a long-term, systematic plan for space evolution and

interoperation. A wide variety of devices and services from different manufacturers and

developers will constitute the future pervasive computing environment [17] where

platform and vendor-independence would inevitably be an issue.

Portability and interoperability can be enabled through the concept of services [18,

19, 20] (i.e. application components) and context awareness [21]. Services from different

sources can interact via a standardized service interface, even though they are unknown

to each other. Context information and events will provide an anchor for the service

interaction as well as for the intelligence of the smart environments. As illustrated in

Figure 4-1, our middleware architecture for smart environments centers on context-aware

service discovery issues.

4.1.2 Context Discovery

Our reference architecture has at the lowest layer, the smart house sensor/device

driver modules. The layers above this could use the platform dependent service offered

by the lower layer modules in a very transparent manner. The context layer in our

architecture defines context in the form tuples like . The layer above









the context layer is the generic services layer, which in turn defines a set of services that

could be used by the applications written on top of it.


Applications
Service
Repository
sBpa"B Tak LI.Blan
Se win glf stwduli .' Tr backing


Context Information Context Information Manager


lw i .....Sensoray Bundles....- I I 1


Figure 4-1. Reference Middleware Architecture for Assistive Environments

The context information is continuously stored in the context information manager

that maintains the context database. An entry in the Service Repository represents a

service in the smart space. The service is essentially represented in the form of service

name, attributes, contextual property.

4.1.3 Services and Applications

To support rapid application development and facilitate service composition, our

middleware provides a set of generic services. As indicated in Figure 4-1, they are

discovered and used by other core services or applications. The following is our current

list of generic services.

* Voice recognition service provides voice-to-text translation service to other

services and applications.

* Camera vision service tracks object movements in the camera's view.

* Event broker service delivers an application-specific event to subscribed clients,

when a certain condition specified in terms of context information becomes true.









* Location service provides the location information (e.g. x and y coordinate) of

Robotilda or objects being tracked.

* Automated/scheduled task service performs scheduled or triggered tasks (e.g.

reminders, alerts, etc) if their condition is met.

* Space sensing service monitors the placement and movement of objects in the

house, and is able to present the information with regard to the house floor plan.

This service may be useful for a map application, or it can be used to locate a

certain object in the house.

* Persistent storage service stores streaming sensor data that may be used for trend

analysis, historical context extraction, and statistics later on.

* Web Service service is a proxy to access Web Services [22] in the Internet. For

instance, a grocery shopping application makes use of this service to order some

food from online Web Service shops.

4.1.4 Prototype

We have based our assistive environment infrastructure on the Open Services

Gateway Initiative (OSGi) that provides a managed, extensible framework to connect

various devices and services. By defining a standard execution environment and service

interface, and by promoting dynamic discovery and collaboration of devices and services

from possibly different sources, the goals of openness and extensibility of the smart

house are attainable. In this sense, the OSGi framework is an ideal match for our need for

an extensible software infrastructure that can adapt to changes (such as declining health

conditions over time and the introduction of new devices, sensors, and services.)

Moreover, we have found the framework's connectivity support to the outside world to









be another noteworthy feature, which supports remote control and diagnosis applications

by family members and caregivers.

An OSGi environment (to be exact, an OSGi Service Platform) is made up of a

Java virtual machine [23], an OSGi Framework, and a set of bundles. The Framework

provides general-purpose, secure support for deploying extensible and downloadable

Java-based service applications known as bundles [9]. Running on top of a Java virtual

machine, it provides a shared execution environment where bundles are installed,

updated, and uninstalled without requiring the system to be restarted. The Framework

also manages dependencies among bundles and services to facilitate their interaction. A

bundle may register zero or more services with the Framework's service registry, which

are discovered through the registry by others. The service registry provides a simple

service discovery functionality based on a service interface name and a collection of

key/value pair properties. The basic functionality is being extended to support the

contextual property and context-aware service discovery feature of our reference

architecture. The registry's need of context information handling and update is backed by

the underlying CIM. The smart house device/sensor drivers in Figure 4-1 are

implemented as OSGi device bundles, and all other components, including the

Applications, the Generic Services, and the CIM, are mapped to a separate service

bundle.

The assistive space built on the OSGi framework provided a solid infrastructure so

that our application development team could focus more on integrating the smart phone

(and by extension, the resident) with the smart environments and various pervasive

computing applications.









4.2 Humanoid Robot Approach

4.2.1 Making of Robotilda

The idea to have a robot in the demo house has occurred to us, when we have

realized that we needed to do extensive testing and benchmarking of the software

hardware involved in the smart home. This eventually addressed the following concerns

that we had.

* How to entice someone to live in the house, while testing the smart home?

* How to have people see what the person living in the house can see, while
demonstrating remotely?

The secondary goal was addressed by having a camera incorporated on Robotilda.

The camera comes with an application program which helps people see what Robotilda

sees remotely. This is accomplished as the cam has an IP-address hard-coded through the

serial port.

4.2.2 Design of Robotilda

These are the following goals that I have met with the help of Steve and Harsha:-

* It is able to move

* It is able to see

* It is able to avoid collision

* It has a universal Power supply

* It is controlled via a IPAQ/Computer

* It is able to have a IPAQ on it for processing outsourcing

We started the making of Robotilda by designing the base on which it rests. The

base has two wheels and motors along with some smart IC's for the robust

communication with the other parts. The wheels are connected to the wind shield motors









that are pulse wave modulated. This enables us to have variable speeds on the wheels. To

be precise, I was able to have the speed vary from 0-255, i.e. we could have 256

variations of the speed. The motors are connected to drivers that are in turn connected to

the ATMEGA 128 [24] processor. The ATMega 128 processor is the brain of Robotilda,

i.e. here is where the c program that controls the robot is residing, i.e. once we have a

sensory data input the c program could instruct the motors to take appropriate actions.

Besides I have also incorporated a few bump and IR sensors [25], these help avoid the

collision. The IR sensors work as they have a lower limit on the distance that an object

could be placed with the robot, it works by emitting an infrared signal and receiving it

back to calculate the distance of the obstacle. The bump sensors work by just a binary

value, they are set when hit to an obstacle and otherwise not set. A block diagram of the

system is shown in Figure 4-2.


Figure 4-2. Block diagram for the Base









4.2.3 Components

In order to actuate Robotilda, we used two 12V DC gear head windshield wiper

motors. We control the steering of Robotilda by sending separate PWM values to each

motor. In order to control these motors, we used two TECEL D 100-B Motor Driver

Boards [26]. These boards are capable of powering each motor with 25 Amps of current.

These boards use three control lines which make these motor driver boards easy to use.

The IN1 and IN2 pins control the direction of the motor, and the EN pin accepts PWM.

Figure 4-3 and Figure 4-4 show how we connected the motor drivers to the motors.


Figure 4-3. Tecel Motor Driver


Enable IN1 IN2 Action
H L L Fast Motor
Stop
H L H Forward

H H L Reverse

H H H Fast Motor
Stop
L X X Free
Running
Motor Stop









This truth table (Figure 4.3) demonstrates the functions provided by the TECEL D-

100b board.

4.2.3.1 Bump Sensors

Because there are many available I/0 pins on the Progressive ATMega 128 board,

we connected each of the 6 bump switches directly to Port B. We connected one end of

the switch to ground and the other end of the switch went directly to our Progressive

board. We have also activated an internal pull-up resistor on the ATMega 128, so that the












Figure 4-4. Robotilda

pin would only go low when the switch is pressed. Based on the location of the switch,

we decided which direction we would have Robotilda move when the switch is pressed.

These switches are mainly used for obstacle avoidance.

4.2.3.2 IR Proximity Detectors

The IR detectors that we used for the Robotilda are the Sharp GP2D120. These

sensors have the capability of locating obstacles between the distances of 4 to 30

centimeters. The output of this device is analog, and is updated approximately every

32ns. On Robotilda, we used three of these IR proximity detectors. We mounted all three

in the front of the platform, since Robotilda would primarily be traveling forward.









4.2.3.3 Controller

We have used the Atmega 128 processor for the purpose of controlling the robot.

Atmega 128 [27] is a low power CMOS 8-bit microcontroller based on RISC

architecture. By executing greater number of instructions for a given block, the

throughput is considerable higher than its counterparts.

The ATmegal28 provided the following features: 128K bytes of In-System

Programmable Flash with Read-While-Write capabilities, 4K bytes EEPROM, 4K bytes

SRAM, 53 general purpose I/O lines, 32 general purpose working registers, Real Time

Counter (RTC), four flexible Timer/Counters with compare modes and PWM, 2

USARTs, a byte oriented Two-wire Serial Interface, an 8-channel, 10-bit ADC with

optional differential input stage with programmable gain, programmable Watchdog

Timer with Internal Oscillator, an SPI serial port, IEEE std. 1149.1 compliant JTAG test

interface, also used for accessing the On-chip Debug system and programming and six

software selectable power saving modes. The Idle mode stops the CPU while allowing

the SRAM, Timer/Counters, SPI port, and interrupt system to continue functioning. The

Power down mode saves the register contents but freezes the Oscillator, disabling all

other chip functions until the next interrupt or Hardware Reset. In Power-save mode, the

asynchronous timer continues to run, allowing the user to maintain a timer base while the

rest of the device is sleeping. The ADC Noise Reduction mode stops the CPU and all I/O

modules except Asynchronous Timer and ADC, to minimize switching noise during

ADC conversions. In Standby mode, the Crystal/Resonator Oscillator is running while

the rest of the device is sleeping. This allows very fast start-up combined with low power

consumption. In Extended Standby mode, both the main Oscillator and the Asynchronous

Timer continue to run.









The ATmegal28 AVR is supported with a full suite of program and system

development tools including C compilers, macro assemblers, program

debugger/simulators, in-circuit emulators, and evaluation kits.

We have used the Win AVR development environment to write/debug and compile

the code. The details of Win AVR are discussed in the "environments used" section.

IV BotlaeU .9- n;X


File Default All Settings Info
Connection
Corn Port Selection:
I Com 2
Baud Rate Selection:
19200


-Start Bootloader Characters.--
Jump to Bootloader Command:


Bootloader Active Character:
F-
Start Download Sequence:


B ootloader Ready:
F- _


- Download File Characters
Line Complete Character:
F-_
Page Error Character:

Checksum Error Character:
File Complete with Errors Character:
File Complete with Errors Character:

File Complete. No Errors Character:
F@_


Filename: IC:\WinAVR\matildaremake\matilda.hex Browse

Wait for Bootloader then Download Jump to Bootloader then Download


Info I

Exit


Status: Idle


Figure 4-5. Avr Bootloader

After the compilation, the object code was to be uploaded to the ATmega 128

processors memory. This, was achieved using the Bootloader, i.e. an AVR Bootloader

1.9.0(Figure 4-5), there was a setting in the GUI of enabled us to set the baud

rate/communication port of transfer of the object code. A baud rate of 19200


I


I I









bytes/second and com2 port of the computer on which the transfer is made from, were

selected.

Besides, the port connections for the IR's and the Bump Sensors, which take in the

various inputs from the sensors, there are USART's (Universal Synchronous

Asynchronous Receiver Transmitter) that take a serial input from an external device. We

had connected the Compaq IPAQ to USART_0, the other USART i.e. USART_1 was left

idle. As was shown in the Block diagram of the Processor, all the components on

Robotilda essentially connect to Atmega Processor if some sort of processing of the

components input is to be done.

4.2.4 Software in Robotilda

4.2.4.1 Programming the ATmega 128

I had programmed the Atmegal28 in C. The various header files of the C class

used are avr/io.h, avr/interrupt.h, avr/signal.h, string.h, avr/pgmspace.h. The io.h was

used to enable the printfo, etc. functions, besides the general i/o functions. The

interrupt.h and the signal.h are the two files needed to accept the sensory interrupts

caused. The string.h included to use the string functions. The pqmspace.h is included to

help allocate memory on the ATmega128 processor.

The key functions written to enable the moving of Robotilda possible in a very

transparent way are the following:-

configuremotors(: This function is used to configure the motors take input from a

particular pin. Also, the LED's on the Atmegal28 are used to help know various stages

of the program traversal as by blinking them at appropriate times in the traversal.









init_UARTO: This function is used to initialize the UART's for accepting input's from a

serial port. Amongst the essential quantities initialized like setting the transmit/receive

the baud rate is set to 19200 as was specified, for the baud rate in the bootloader.

checkbump():It's is used to check if there was a collision from the backside of Robitilda,

as the bump sensors are placed on the back side. Once, there is some sort of collision on

one of the bump sensors, moving routines like right, straight, left(), etc are called to

move away from the object that it collided from.

checkir(): Similar to checkbumpo, this is used to see if there is any object in the front in a

range of 4-5 inches and would avoid the collision with that object by backing off. The

functions used to achieve this are similar to what are used in the checkbumpo case.

Wait(int):It was used to make the processor wait for a given time before calling the

following command in the instruction sequence. This enabled discretization of various

actions performed by the processor on Robotilda.

Movement Functions:This has left(), hardlefto, right, hardrighto, straight, back(),

stop. As the name suggests, these functions are essentially used to move Robotilda to

the left, right, straight, backwards and stop it from moving respectively.

Besides these, there are couple of system functions used like sei(),cli(), output, inp();

which are essentially used to set global interrupts, clear bits on the pins, output certain

hexadecimal value, read a particular input respectively.

4.2.4.2 Software for the IPAQs

The interface for the IPaq essentially has buttons to control the robot. As can be

shown in figure below, the controller connects to the server on the robot on the IP address

specified on the server IP address button and the port number specified by the Server Port

button. I also incorporated the buttons to connect and to disconnect with the server IPAQ,






30


as I could have multiple users connect to the server at a given time on a time sharing

basis. TCP doesn't allow multiple connections on a given IP and port number. The

functions of the other buttons are as mentioned below:



Server IP Address .. 192.168.1.165

Server Port: 721 Connect

: disconnect

Speed .... [ Front .... Slow |

: Lett Stop ... LRight :


: Back :. .



Figure 4-6. IPAQ Controller Interface

Slow: It's used to slow down the robot using the button, this helps in varying the speed of

the robot from 0-255, i.e. since I used PWM the speed could range from 0-255.

Speed: This is used to speed up the robot using the button, this also as specified above

helps in varying the speed of the robot from 0-255, i.e. since I used PWM the speed could

range from 0-255.

Front: It's used to move the robot in the forward direction. This along with speed/slow

buttons could help me achieve the requisite movement for the robot.

Back: It's used in moving the robot in the backwards direction. Again this is mentioned

above is used in conjunction with the speed/slow buttons to achieve the movement that I

needed.

Stop: This is used to freeze the robot to a stand still position.







































Figure 4-7. IPAQ Server

As shown in the figure above after the program is downloaded into the Compaq

IPAQ using the serial port of the IPAQ, from the computer. The program is run from the

files folder, by clicking on the executable just loaded onto the Compaq Ipaq. This then

gives the interface of the controller as shown in the previous figure, to help control the

robot.

4.2.4.3 Configuration and Setting

The Cisco wireless LAN card was configured using the client utility that was

provided by Cisco. The utility after installed was placed in the start/programs/cisco

folder.









Besides, I have used a utility to know the IP address set to the IPAQ. vxUtil is

available for free on the web. This after installation has been placed in the start/programs/

communication folder. The "I" button has been activated to know the various wireless-

LAN settings that the IPAQ has. For the Ad Hoc network I first chose the network type to

be infrastructure-less network and named the network by ICTA i.e. the SSID, the

respective names of the IPAQ's as Robotilda and Mat. Besides, the other settings were,

no gateway, no encryption, no LEAP, subnet mask as "255.255.255.0". The only

difference to have this work for an infrastructure mode is to change the mode of

operation to infrastructure mode, besides setting up the gateway information.

4.2.5 Development Environment

4.2.5.1 Visual Studio .NET 2003

With time handheld devices are becoming more capable. Processors are getting

faster, and devices at the low end of the market now come with 32kb of RAM, compared

to 16kb a short while ago. Also, diverse networking technologies like Wireless Lan

802.11, Bluetooth, Infrared, etc are built into the device.

With so much of sophistication in the attributes incorporated into the new

generation handheld devices, there was an increasing need for a framework that could

give in a managed execution environment for the device. Microsoft Inc, during the

beginning of year 2000 had released .NET Compact Framework [28] to address the need

to manage execution environment for handheld devices.

The .NET Compact Framework is for devices with the following characteristics:-

* A capable CPU

* RAM for program and data storage

* Persistant Storage such as RAM disk









In essence the .NET Compact Framework is a "lite" version of the full, desktop

.NET framework. It includes a compatible subset of base class libraries of the full .NET

framework, and it also adds in a few new ones that are specifically designed for mobile

devices. The .NET Compact framework also has a new implementation of the common

language runtime, built from ground up to run efficiently on small devices that are

constraint in both memory and CPU power and which must conserve battery power.

Visual Studio 2003 includes the software and tools needed to create applications that run

on devices where the .NET compact framework is installed. The components necessary to

install the .NET Compact Framework on the handheld device install onto the desktop

computer when visual studio 2003 is installed.

Visual Studio .NET 2003, is a comprehensive development tool for creating the

next generation of applications. Developers can use Visual Studio .NET to:

* Build the next-generation Internet.

* Create powerful applications quickly and effectively.

* Span any platform or device.

Visual Studio .NET is the only development environment built from the ground up

to enable integration through XML Web services. By allowing applications to share data

over the Internet, XML Web services enable developers to assemble applications from

new and existing code, regardless of platform, programming language, or object model.

4.2.5.2 WIN AVR

For Robotilda to have intelligence incorporated in it, we have used ATMEL

processors to talk to various motors and sensors like the infrared/bump sensors. The key

advantage of using the processors from ATMEL is the ability of it to be programmed in a

very well defined high level language like c/c++.










WinAVR [29] includes a set of tools like avr-gcc (the command line compiler),

avr-libc (the compiler library that is essential for avrgcc), avr-as (the assembler), avrdude

(the programming interface), avarice (JTAG ICE interface), avr-gdb (the de-bugger),

programmers notepad (editor) and a few others. These tools are all compiled for

Microsoft Windows and put together with a nice installer program. The version of

WinAVR is essentially the version of the compiler AVRGCC, For example currently

WinAVR includes version 3.3 of avr-gcc.

4.3 Benchmarking and Experiments

The concept of benchmarking a smart home has evolved from the fact that the

customer/manufacturer of the smart home needs to know if the technology used is good

enough, given the requirements of the smart home.

Table 4-1. Binary Analysis of Benchmarking Metrics
Metrics Favorable(Yes) Description
UnFavorable(No)
Security [18, 19] Yes(l) We have not incorporated any security
mechanisms into the system for the mock home
at this moment but are using the security
modules provided by the OSGI platform for the
actual home integration of technology.
Atomicity [20] Yes(l) This is ensured by the OSGI platform i.e. in
similar lines as the operating system ensures
atomicity for the applications running above it
(the scheduler of the OS ensures every
application gets there time slice to perform the
operation on the occurrence of the event).
Durability [20] Yes(l) The OSGI platform ensures that the operation
is performed when an operation is triggered by
a user or a sensor.
Intrusiveness Yes( 1) Most of the components in the mock smart
home are triggered by events i.e. we have
followed an event-driven model. This ensures
there is minimal intrusiveness from the user's
side to perform a given operation.
Scalability [20] Yes(1) We have given at most importance to this while
developing the software for the smart home.
The idea of our integration of new components
into the smart home is performed with great
ease because of the software/hardware
scalability incorporated into the design.










Table 4-1--Continued.
Metrics Favorable(Yes) Description
UnFavorable(No)
Heterogeneity [20] Yes(1) We have with great ease used technologies
from various manufacturers [5, 9, 15] and have
no platform dependent issues coming across
while in the process of integrating these into
the system.
Remote Maintenance No(0) As of now we have not incorporated remote
maintenance into the system. We plan to
incorporate the remote maintenance into the
system for the actual home that is to be built.
Isolation No(0) As of now we have not incorporated remote
maintenance into the system. We plan to
incorporate the remote maintenance into the
system for the actual home that is to be built.
Privacy Yes(1) We have not compromised on the privacy of
the home user by giving unauthorized access of
the home to others.
User Experience Yes( 1) We have performed usability tests by having
people perform tests of various components in
the house and have achieved 85% acceptance
level.
Controllability Yes( 1) Though we have incorporated smart
components that are triggered by the operating
context (Microwave operated after the RFID
reader [15] reads the food package), we have
not disabled manually operating the smart
components.
Anomaly Detection No(0) We have not enabled this feature in the mock
home that we presently work on but plan to
incorporate this in the actual home being built.
Latency Yes(l) Avoiding unaccepted time latency is the major
concern for most of the developers in the field
of smart environments. We have tried our level
best in decreasing the time latency associated in
the given event in the smart home.



To understand and motivate this concept in smart environments, we have

performed benchmarking analysis using an N-ary tree model in similar lines to threat

modeling [30] performed in security aware systems. To this end, we proposed and

performed a detailed study in the mock home built at the pervasive computing lab in the

Computer Science Department, University of Florida (UFL). First of all in our model,

we have tabulated the metrics (Table 4-1) and the binary value associated in accordance

to their being addressed in the mock smart home. Later, we have illustrated in Table 4-2

one essential metric of the smart home: "The Latency". Our benchmarking mechanism









for the smart home enables sub-component benchmarking as well. For instance, our

model helps benchmark the "Location Positioning System" in the smart home using the

generic benchmark mechanism. This is achieved by having Robotilda's position trigger

application's like appliances control in the mock smart home and tabulating the latency

associated with various applications, we then following the general benchmarking

mechanism to evaluate it.

Table 4-2. Smart Home Latency Chart
Application Min-Latency Max- Average No of Simulations
(Sec) Latency(Sec) (Sec)
TV 5.5 6.3 6.0 6
Curtain 5.7 6.5 5.9 6
Microwave 2.7 3.1 2.8 6
Radio 4.0 4.9 4.5 6
Bed Light 2.1 3.7 3.1 6
Door Lock 0.9 1.3 1.0 6
Home Camera 2.4 3.0 2.7 6
LPS-TV 5.2 5.5 5.3 6


Table 4-2 has as columns the various applications, the minimum latency, the

maximum latency observed in the tests carried out for an hour (i.e. six tests). It also has

the Average and the number of simulations performed in the tests during that period.

In the following description I give a general idea on how the various application

latencies are evaluated.

* TV: We have associated time latency for TV to be the time it takes for the TV to
switch on/hop channels, after a command is issued from the J2ME phone.

* Curtain: We have associated time latency for curtain to be the time it takes for the
curtain to open/close, after a command is issued from the J2ME phone.

* Microwave: We have associated time latency for the Microwave to be the time it
takes for the Microwave to start the cooking operation after it reads the RFID from
the food item.









* Radio: We have associated time latency for radio to be the time it takes for the
radio to start/stop, after a command is issued from the J2ME phone.

* Bed-light: We have associated time latency for the light to be the time it takes for
the light to turn-on/turn-off, after a command is issued from the J2ME phone.


* Door Bell: We have associated time latency for the Door Bell to be the time it
takes for the Home System to prompt the user of the open/close of the door.

* Home Camera: We have associated time latency for the camera to be the time it
takes for the camera to show the picture of the person on the TV display when the
door bell rings.

* LPS' -TV: We have associated time latency for the LPS-TV to be the time it takes
for the LPS to switch on an appropriate TV in accordance to the position of the
person in the smart home. It performed by controlling Robotilda's movements in
the smart home using the IPAQ; this in turn switches the appropriate monitor in
accordance to Robotilda's position.

From the table we also get the values associated with the Location positioning

system for benchmarking the location positioning system module. We have restricted

ourselves to switching on the appropriate TV in accordance to the location provided by

the Location Positioning System. Though in reality we presume there could be many

applications dependent on the Location Positioning System for the input state.

Finally, we have performed the benchmark value evaluation using a thirteen-ary

tree model. We have followed a bottom-up approach in determining the benchmark

value associated with the smart home. This was achieved by categorizing benchmarking

of a smart home into various phases as described below:

* Phase I: Determining various metrics that evaluate the Benchmark

* Phase II: Sketch the Metric-Trees for each of the Metric

* Phase III: Evaluate the Metric-Value for each of the Metric-Tree


1 LPS stands for Location Positioning System










* Phase IV: Sketch the Benchmark-Tree for the Smart home

* Phase V: Evaluate the Benchmark for the Smart Home

I would discuss in detail each of the above mentioned phases in the following

sections.2

4.3.1 Determining Various Metrics that Evaluate the Benchmark

This is the phase that was discussed in the section for "Metrics to evaluate the

smartness of the home". In sum, we have proposed a set of thirteen metrics, each of

which is essentially a node in the benchmark tree for the smart home (Table 4-1).3

4.3.2 Sketch the Metric-Trees for Each of the Metric

We have in this phase drawn thirteen metric trees for each of the metrics to

evaluate the Metric-Value associated with the metric tree. A Metric-Tree in simple terms

is a tree rooted with the metric and whose children are in general, the attributes of the

metric. To illustrate the idea, I have tabulated the metric trees corresponding to each of

the metrics in Table 4-3.

Table 4-3. N-ary Analysis of Benchmarking Metrics
Metrics Metric Tree Description

Security Security Metric tree has as it's
Security Metric Tree attributes the three pillars of
A security. Going by the Intuitive
4Q. "Y r,.orT Model, in a smart environment
431.0/9 we have assigned 4:3:2 weights
to the three essential attributes.

Autenticatilon Integrity Encryption of
AuthorizaUton Protection Data




2 Please note that having a bottom-up strategy in evaluating a benchmark is just an issue of choice, one
could as well perform the analysis in a top-down fashion.

3 Please also note that this generates a thirteen-ary tree and in general terms could lead to N-ary tree,
depending on the metrics one proposes (we have proposed thirteen metrics in our model).











Table 4-3.


ntinued.
Metric Tree Description


Security Metric tree has as it's
Security Metric Tree attributes the three pillars of
A k security. Going by the Intuitive
3 rti .1rg Model, in a smart environment
31.09 2 9 we have assigned 4:3:2 weights
to the three essential attributes.

Autenticalion/ Integrity Encryption of
Authorization Protection Data

We have considered all the
metrics other than Security and
Latency to be a one node tree
Atoricily Tree i.e. a leaf node. Hence the value
(Single node n-nary tree) associated to it goes by Binary
Model i.e. 1(if addressed)/0(if
not-addressed).
We have considered all the
metrics other than Security and
Latency to be a one node tree
Durability Tree i.e. a leaf node. Hence the value
Single node n-nary tree) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).
We have considered all the
metrics other than Security and
Latency to be a one node tree
ntrusveness Tree i.e. a leaf node. Hence the value
{Single node n-nary tree) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).
We have considered all the
metrics other than Security and
Latency to be a one node tree
letemgensity Tree i.e. a leaf node. Hence the value
associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).
We have considered all the
metrics other than Security and
Latency to be a one node tree
Scaiabirlty Tree i.e. a leaf node. Hence the value
associated to it goes by Binary
Model i.e. 1/0.
We have considered all the
metrics other than Security and
Latency to be a one node tree
RemnoteMaintrenance Tree i.e. a leaf node. Hence the value
(Single ode n-nary tree) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).











Table 4-3. Continued.
Metrics Metric Tree Description


Isolation We have considered all the
metrics other than Security and
Latency to be a one node tree
isolation T e i.e. a leaf node. Hence the value
{Single node n-nary tre) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).
Privacy We have considered all the
metrics other than Security and
Latency to be a one node tree
Privacy Tree i.e. a leaf node. Hence the value
Single node n-nary tree) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).
User We have considered all the
Experience metrics other than Security and
Latency to be a one node tree
User Expsrinece Tre i.e. a leaf node. Hence the value
Single node n-nary tre) associated to it goes by Binary
Model i.e. 1/0.
Controllability We have considered all the
metrics other than Security and
Latency to be a one node tree
Controllability Tree i.e. a leaf node. Hence the value
{Single node n-nary tree) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).
Anomaly We have considered all the
Detection metrics other than Security and
Latency to be a one node tree
Anomay detection Tree i.e. a leaf node. Hence the value
Single node n-nary tree) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).
Latency We have associated Latency
SLatenc. Mec Tree Metric Tree to have two com-
0.5 0ponent N-ary-trees (Applianc-
0.5 05
Ses / Others). Each of these
components is given a weight
SAppliances 01s to the link in accordance to the
0.05 0. intuitive model. Also, each leaf
0.3 0.4 0.6 nodes of the Appliance and
Others trees are evaluated using
curtain Radio uavei TV Ughi C Dor a binary model. Further, the
links between the Appliance
\Others trees and their children
are weighted using an intuitive
model.










4.3.3 Evaluate the Metric-Value for Each of the Metric-Tree

In this phase we have evaluated (as shown in Table 4-4) the value corresponding to

each of the metric from the Metric-Tree. We have followed a Binary Model4 and an

Intuitive Model5 to calculate the value associated with each node. The general idea behind

evaluating a value to a node is bottom up, i.e. in a post-order fashion (evaluate the

children before evaluating the root).

Table 4-4. List of Metric Values
Metrics Metric value

Security 0
Atomicity 1
Durability 1
Intrusiveness 1
Scalability 1
Heterogeneity 1
Remote Maintenance 0
Isolation 0
Privacy 1
User Experience 1
Controllability 1
Anomaly Detection 0
Latency 1-0.38



The metric values for the metric trees are evaluated using Tables 4-1 and Table 4-2

for the mock smart home. The Latency Metric tree is evaluated using a weighted

accumulation technique, i.e. each of its children is evaluated to determine their

normalized value, after which we found the weighted cumulative of all the children.






4 In a Binary Model, we associate 0/1 value with each leaf node in the Metric-Tree

' In an Intuitive Model, we associate an intuition driven value to each of the links between the tree node
and its children










4.3.4 Sketch the Benchmark-Tree for the Smart Home

In this phase we have sketched (Figure 4-8) the benchmark-tree for the smart home

i.e. a thirteen-ary tree in our model. We have further illustrated the Associate Matrix

(Table 4-5) for the Benchmark Tree.


Figure 4-8. Smart Home Benchmark Tree

The calculation for the High, Medium, Low values is performed via an intuitive

approach. I have illustrated it in Figure 4-9.

Table 4-5. List of Metrics Precedence
Metrics Associated Identifier Precedence
(Value)
Security a(0.1) High
Atomicity b(0.063) Medium
Durability c(0.063) Medium
Intrusiveness d(0.1) High
Scalability e(0.1) High
Heterogeneity f(0.05) Low
Remote Maintenance g(0.05) Low
Isolation h(0.05) Low
Privacy i(0.1) High
User Experience j(0. 1) High
Controllability k(0.063) Medium
Anomaly Detection 1(0.05) Low
Latency m(0.1) High











Calculating the High, Medium, Low values

Eq 1: 6* High + 4* Medium + 3* Low = 1.0 (law of equilibrium)
Eq 2: High > Medium > Low (law of semantics)

By Intuitive Model:
3* Low = 0.2, 4*Medium = 0.2, 6*High = 0.6

Hence,
Low = 0.063
Medium = 0.05
High = 0.6/6 = 0.1

Figure 4-9. H/M/L Calculation

4.3.5 Evaluate the Benchmark for the Smart Home

We have followed a cumulative approach in finding the benchmark value (Table 4-

6) associated with the given smart home.

Table 4-6. Cumulative Metric Matrix
Metrics Metric Value Weighted Metric Cumulative Value
Security 0 0 0
Atomicity 1 .063 .063
Durability 1 .063 .126
Intrusiveness 1 .1 .226
Scalability 1 .1 .226
Heterogeneity 1 .05 .276
Remote Maintenance 0 0 .276
Isolation 0 0 .276
Privacy 1 .1 .376
User Experience 1 .1 .476
Controllability 1 .063 .539
Anomaly Detection 0 0 .539
Latency 0.62 0.062 0.601
__0_____.601


4.4. Benchmarking the Location Positioning System

In this section we have demonstrated how one could benchmark a given component

(Location positioning system) of the smart home using the general benchmarking model

discussed in the section 4.3. We have very much followed the general phases (I V) of

the smart home benchmarking mechanism to determine the benchmark value










corresponding to the Location positioning system. The phases that we have followed in

benchmarking the Location Positioning System are the following:-

* Phase I: Determining various metrics that evaluate the Benchmark

* Phase II: Sketch the Metric-Trees for each of the Metric

* Phase III: Evaluate the Metric-Value for each of the Metric-Tree

* Phase IV: Sketch the Benchmark-Tree for the Location Positioning System

* Phase V: Evaluate the Benchmark for the Location Positioning System

4.4.1 Determining Various Metrics that Evaluate the Benchmark

In this phase we have determined which of the thirteen metrics (in general n

metrics) proposed for the smart home benchmarking would be relevant for benchmarking

the Location Positioning System. This is illustrated in Table 4-7.

Table 4-7. List of Needed Metrics
Metrics Needed(Yes)
Not-Needed(No)
Security No
Atomicity Yes
Durability Yes
Intrusiveness No
Scalability Yes
Heterogeneity Yes
Remote Maintenance No
Isolation No
Privacy No
User Experience No
Controllability No
Anomaly Detection No
Latency Yes


As tabulated in the figure, the metrics that do not have any significance in

benchmarking the location positioning system are marked with a "NO" and the ones with

have significance are marked with an "YES".











4.4.2 Sketch the Metric-Trees for Each of the Metric

We have in this phase drawn metric trees for each of the metrics significant to


benchmarking the location positioning system. I have tabulated the metric trees


corresponding to each of the metrics in Table 4-8.



Table 4-8. Lps Metric Matrix
Metrics Metric Tree Description


Atomicity We have considered all the
metrics other than Latency to
be a one node tree i.e. a leaf
Atomiily Tree node. Hence the value
(Single node n-nary tree) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).

Durability We have considered all the
metrics other than Latency to
be a one node tree i.e. a leaf
Durability Tree node. Hence the value
{Single node n-nary tree) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).
Heterogeneity We have considered all the
metrics other than Latency to
be a one node tree i.e. a leaf
otemgensity Tree node. Hence the value
(Single node n-nary tree) associated to it goes by Binary
Model i.e. 1 (if addressed)/0(if
not-addressed).
Scalability We have considered all the
metrics other than Latency to
be a one node tree i.e. a leaf
ScalabilityTree node. Hence the value
(Singe node n-nary tree) associated to it goes by Binary
Model i.e. 1/0.

Latency We have associated Latency
Latency M&%ic Tree Metric Tree to have two com-
ponent N-ary-trees (Applianc-
0.5 05
es/Others). Each of these
components is given a weight
OeAppliances O3 to the link in accord-ance to the
1 or 0 03 oA intuitive model. Also, each leaf
o4 06 nodes of the Appliance and
Others trees are evaluated using
Ctain Radio T V ought camera Door a binary model. Further, the
links between the
Appliance\Others trees and
their children are weighted
using an intuitive model.










4.4.3 Evaluate the Metric-Value for Each of the Metric-Tree

In this phase we have evaluated (as shown in Table 4-9) the value corresponding to

each of the metrics from the Metric-Tree. We have followed a Binary Model and an

Intuitive Model to calculate the value associated with each node as was described in the

general smart home benchmarking mechanism. Also the idea behind evaluating a value to

a node remains bottom up, i.e. post-order (evaluate the children before evaluating the

root).

Table 4-9. List of lps Metric Values
Metrics Metric value

Atomicity 1
Durability 1
Heterogeneity 1
Scalability 1
Latency 0.5



The metric values for the metric trees are evaluated using Table 4-7 and Table 4-8,

for the mock smart home.

4.4.4 Sketch the Benchmark-Tree for the Location Positioning System

In this phase we have sketched the Location Positioning Benchmark Tree (Figure

4-10) for the smart home i.e. a five-nary tree in our model. We have further illustrated the

Associate Matrix (Table 4-10) for the Location Positioning Benchmark Tree.








6 In a Binary Model, we associate 0/1 value with each leaf node in the Metric-Tree

' In an Intuitive Model, we associate an intuition driven value to each of the links between the tree node
and its children





















Figure 4-10. Location Positioning System Benchmark Tree

The calculation for the High, Medium, Low values is performed via an intuitive

approach. I have illustrated it in figure 4-11.

Table 4-10. List of lps Metrics Precedence
Metrics Associated Identifier Precedence
(Value)
Atomicity a(0.15) Medium
Durability b(0.15) Medium
Scalability d(0.3) High
Heterogeneity c(O.1) Low
Latency e(0.3) High


Calculating the High, Medium, Low values
Eq 1: 2* High + 2* Medium + 1* Low = 1.0 (Law ofEquilibrium8)
Eq 2: High > Medium > Low (Law of Semanticsl9)

By Intuitive Model:
1* Low = 0.1, 2*Medium = 0.3, 2*High = 0.6
Hence,
Low = 0.1, Medium = 0.15, High = 0.6/2 = 0.3
Figure 4-11. lps H/M/L Calculation

4.4.5 Evaluate the Benchmark for the Location Positioning System

We have followed a cumulative approach in finding the benchmark value

associated with the given smart home. This is illustrated in Table 4-11.




8 Law of Equilibrium, it is a law that associates equality between the LHS and the RHS.

9 Law of Semantics, it is a law that mathematically describes the semantic context.











Table 4-11. List of Ips Cumulative Metrics
Metrics Metric Value Weighted Metric Cumulative Value

Atomicity 1 .15 .15
Durability 1 .15 .3
Scalability 1 .3 .6
Heterogeneity 1 .1 .7
Latency 0.5 .15 .85
0.85














CHAPTER 5
CONCLUSION AND FUTURE WORK

Having a benchmarking mechanism to evaluate a technology/product is not new;

we have used it in this thesis, to move a step forward in the direction of evaluating the

smart homes. To perform this evaluation, we have used a Robot to simulate a living

person in the mock smart home (smart home to benchmark).

One of the key aspects of our work is the idea of evaluating the benchmark using

an N-ary tree model, which in turn is evaluated using a binary/intuitive model. The binary

model is used to evaluate the leaf nodes in the N-ary tree, which evaluates to either

1(implemented)/0(not-implemented). The Intuitive model is used to evaluate the non-leaf

tree-nodes in a post-order fashion by weighted accumulation of the evaluated children.

The value of root node i.e. the benchmark tree node is the evaluated benchmark value of

the smart home. We have not made any conclusions about what are the best values to

have in terms of the benchmark value. This model essentially helps determine the best

smart home, in a given list of smart home specifications.

In our approach for benchmarking a smart home using a humanoid robot we have

used an intuitive model to evaluate a non-leaf node in the N-ary tree. We plan to use an

alternative approach which is more robust and calculation transparent, i.e. we plan to

develop a tool that gives the values for the various metric nodes in the N-ary tree by

performing live tests on the home computer.















LIST OF REFERENCES


1. Silicon Moore's Law. http://architecture.mit.edu/house_n/. Site last visited on
April, 2004.

2. Rehabilitation Engineering Research Center. http://www.rerc.ufl.edu/. Site last
visited on April, 2004.

3. Berlo, AV. "Design Guidelines on Smart homes."
http://www.stakes.fi/cost219/smarthousing.htm. Site last visited on April, 2004.

4. Dewsbury G, Taylor B, Edge M. "Designing Safe Smart Home Systems for
Vulnerable People," In Proceedings of the First Dependability and Healthcare
Informatics Workshop, Edinburgh, Scotland, 2002, UK, pp. 65-70.

5. Millennium Home. http://disc.brunel.ac.uk/. Site last visited on April, 2004.

6. MIT Media Laboratory. "Counter Intelligence." http://www.media.mit.edu/ci. Site
last visited on April, 2004.

7. The MIT Home of Future Consortium. http://architecture.mit.edu/house_n/. Site
last visited on April, 2004.

8. Aware Home Research Initiative.
http://www.cc.gatech.edu/fce/ahri/publications/index.html#overviews. Site last
visited on April, 2004.

9. Giraldo C, Helal A, Mann WC. "mPCA A Mobile Patient Care-Giving Assistant
for Alzheimer Patients," In First International Workshop on Ubiquitous Computing
for Cognitive Aid, 2002.

10. Helal A, Giraldo C, Kaddoura Y, Lee C, Zabadani HE and Mann WC. "Smart
Phone Based Cognitive Assistant," In Fifth International Conference on
Ubiquitous Computing, 2003.

11. Hexamite, "Local Positioning System." http://www.hexamite.com/. Site last visited
on April, 2004.

12. Hightower J, Borriello G. "Location Systems for Ubiquitous Computing," IEEE
Computer Magazine, August 2001, vol. 34, no. 8, pp. 57-66.









13. Helal, A, Winkler B, Lee C, Kaddoura Y, Ran L, Giraldo C, Kuchibhotla S, and
Mann WC "Enabling Location-Aware Pervasive Computing Applications for the
Elderly," In Proceedings of theFirst IEEE International Conference Pervasive
Computing and Communications, 2003.

14. Texas Instrument RFID. "Tag It Inlays."
http://www.ti.com/tiris/docs/products/transponders/RI-I01-11 OA.shtml. Site last
visited on April, 2004.

15. Satyanarayanan M. "Pervasive Computing: Vision and Challenges," IEEE
Personal Communications Magazine, August 2001, vol. 8, no. 4, pp. 10-17.

16. Weiser M. "The Computer for the 21st Century," Scientific American, September
2001, vol. 256, no. 3, pp. 94-104.

17. Lehmannn 0, Bauer M, Becker C, Nicklas D. "From Home to World Supporting
Context-Aware Applications through World Models," In Proceedings of the
Second IEEE International Conference on Pervasive Computing and
Communications, January, 2004.

18. Marples D, Kriens P. "The Open Services Gateway Initiative: An Introductory
Review," IEEE Communications Magazine, December 2001, vol. 39, no. 12, pp.
110-114.

19. OSGi Alliance. "OSGi Service Platform."
http://www.osgi.org/resources/spec_download.asp. Site last visited on April, 2004.

20. Henricksen A, Indulska J. "A Software Framework for Context-Aware Pervasive
Computing," In Proceedings of the Second IEEE International Conference on
Pervasive Computing and Communications, January, 2004.

21. Nagel K, Kidd C, O'Connell T, Dey A, and Abowd G. "The Family Intercom:
Developing a Context-Aware Audio Communication System," In Proceedings of
the Third International Conference on Ubiquitous Computing 2001, March, 2001.

22. Tanenbaum SA. "Chapter 5: Synchronization, Distributed Systems Principles and
Paradigms," Prentice-Hall of India, New-Delhi, 2002.

23. Engel J. "Programming for the JVM," Addison-Wesley, Reading, MA, 1999.

24. ATMega 128 Processor Specifications. http://www.atmel.com/dyn/products. Site
last visited on April, 2004.

25. IR Sensors Specification. http://www.acroname.com. Site last visited on April,
2004.

26. TECEL Board Specifications. http://www.tecel.com/d200/. Site last visited on
April, 2004.






52


27. Hennessy LJ, Patterson H. "Computer Architecture- 3rd Edition," Morgan
Kaufmann Publishers, San Francisco, CA, 2003.

28. Wigley A, Wheelwright S, Burbidge R, MacLeod R, Sutton M. ".NET Compact
Framework (Core Reference)," Microsoft Press, Redmond, WA, 2003.

29. WinAVR Specification and Downloads. http://www.avrfreaks.net/. Site last visited
on April, 2004.

30. Howard M, LeBlanc D. "Chapter 4: Threat Modeling, Writing Secure Code,
Second Edition," Microsoft Press, Redmond, WA, 2002.















BIOGRAPHICAL SKETCH

Satish Kumar Veerapuneni has received his bachelor's degree in mechanical

engineering from the Indian Institute of Technology- Bombay, India (IITB), in May

2002. After his graduation, he joined the Computer and Information Science and

Engineering (CISE) department at the University of Florida for his graduate studies in

August 2002.

Satish, has been a part of Pervasive Computing lab since December of 2002. He

has a passion for technology and his interests lie in mobile computing, pervasive

computing, networking and network security in general.

After graduation, Satish will be joining Intel-WPD San Diego, California, as a

network software engineer.

PAGE 1

BENCHMARKING SMART HOMES USING A HUMANOID ROBOT APPROACH By SATISH KUMAR VEERAPUNENI A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLOR IDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2004

PAGE 2

Copyright 2004 by Satish Kumar Veerapuneni

PAGE 3

TO MY WONDERFUL FAMILY

PAGE 4

iv ACKNOWLEDGMENTS I express my gratitude to Dr. Abdelsalam (Sumi) Helal for his encouragement, support and valuable feedback from time to time throughout my thesis. I would also like to thank Dr. Shigang Chen and Dr. Herman Lam for agreeing to serve on my committee. I have a list of friends to th ank for their help and contribution to my thesis. Firstly, I would like to thank Steve Vander Ploeg and Ha rsha Munikoti for the great contribution in the making of Robotilda, a key tool in my benchmarking tests. Secondly, I would like to thank all the other Pervasive computing/Harr is lab-mates for their support. I have a special thanks to Dr. Choonwa Lee a recent graduate of the Pervasive Computing Lab for his support in making of my thesis. Lastly, I would like to thank my parents and relatives for being with me every moment in life and supporting me in my endeavors.

PAGE 5

v TABLE OF CONTENTS Page ACKNOWLEDGMENTS.................................................................................................iv LIST OF TABLES............................................................................................................vii LIST OF FIGURES.........................................................................................................viii ABSTRACT....................................................................................................................... ix CHAPTER 1 INTRODUCTION........................................................................................................1 2 SMART HOME SURVEY...........................................................................................3 2.1 Robotilda Smart Home...........................................................................................4 2.2 Millennium Home...................................................................................................5 2.3 House_n Project......................................................................................................7 2.4 Aware Home...........................................................................................................9 3 METRICS TO EVALUATE THE SMART HOME..................................................11 3.1 Intrusiveness.........................................................................................................12 3.2 Scalability.............................................................................................................13 3.3 Heterogeneity........................................................................................................13 3.4 Security.................................................................................................................13 3.5 Remote Maintenance............................................................................................14 3.6 Atomicity..............................................................................................................14 3.7 Durability..............................................................................................................15 3.8 Isolation................................................................................................................15 3.9 Privacy..................................................................................................................15 3.10 User Friendliness/Experience.............................................................................16 3.11 Controllability.....................................................................................................16 3.12 Anomaly Detection.............................................................................................16 3.13 Latency...............................................................................................................16 4 IMPLEMENTATION.................................................................................................18 4.1 Test Bed................................................................................................................18

PAGE 6

vi 4.1.1 Robotilda Smart Home Architecture..........................................................18 4.1.2 Context Discovery......................................................................................18 4.1.3 Services and Applications..........................................................................19 4.1.4 Prototype.....................................................................................................20 4.2 Humanoid Robot Approach..................................................................................22 4.2.1 Making of Robotilda...................................................................................22 4.2.2 Design of Robotilda....................................................................................22 4.2.3 Components................................................................................................24 4.2.3.1 Bump Sensors...................................................................................25 4.2.3.2 IR Proximity Detectors.....................................................................25 4.2.3.3 Controller.........................................................................................26 4.2.4 Software in Robotilda.................................................................................28 4.2.4.1 Programming the ATmega 128........................................................28 4.2.4.2 Software for the IPAQs....................................................................29 4.2.4.3 Configuration and Setting................................................................31 4.2.5 Development Environment.........................................................................32 4.2.5.1 Visual Studio .NET 2003.................................................................32 4.2.5.2 WIN AVR........................................................................................33 4.3 Benchmarking and Experiments...........................................................................34 4.3.1 Determining Various Metrics th at Evaluate the Benchmark......................38 4.3.2 Sketch the Metric-Trees for Each of the Metric.........................................38 4.3.3 Evaluate the Metric-Value fo r Each of the Metric-Tree.............................41 4.3.4 Sketch the Benchmark-Tree for the Smart Home......................................42 4.3.5 Evaluate the Benchmark for the Smart Home............................................43 4.4. Benchmarking the Location Positioning System.................................................43 4.4.1 Determining Various Metrics th at Evaluate the Benchmark......................44 4.4.2 Sketch the Metric-Trees for Each of the Metric.........................................45 4.4.3 Evaluate the Metric-Value fo r Each of the Metric-Tree.............................46 4.4.4 Sketch the Benchmark-Tree for the Location Positioning System............46 4.4.5 Evaluate the Benchmark for the Location Positioning System..................47 5 CONCLUSION AND FUTURE WORK...................................................................49 LIST OF REFERENCES...................................................................................................50 BIOGRAPHICAL SKETCH.............................................................................................53

PAGE 7

vii LIST OF TABLES Table page 4-1 Binary Analysis of Benchmarking Metrics..............................................................34 4-2 Smart Home Latency Chart......................................................................................36 4-3 N-ary Analysis of Benchmarking Metrics...............................................................38 4-4 List of Metric Values................................................................................................41 4-5 List of Metrics Precedence.......................................................................................42 4-6 Cumulative Metric Matrix........................................................................................43 4-7 List of Needed Metrics.............................................................................................44 4-8 Lps Metric Matrix....................................................................................................45 4-9 List of lps Metric Values...........................................................................................46 4-10 List of lps Metrics Precedence.................................................................................47 4-11 List of lps Cumulative Metrics.................................................................................48

PAGE 8

viii LIST OF FIGURES Figure page 2-1 The RERC Smart House............................................................................................4 2-2 Millennium Home Floor Plan....................................................................................5 2-3 Placelab................................................................................................................... ...7 2-4 Aware Home..............................................................................................................9 4-1 Reference Middleware Architect ure for Assistive Environments............................19 4-2 Block Diagram for the Base......................................................................................23 4-3 Tecel Motor Driver...................................................................................................24 4-4 Robotilda.................................................................................................................. 25 4-5 Avr Bootloader.........................................................................................................27 4-6 IPAQ Controller Interface........................................................................................30 4-7 IPAQ Server.............................................................................................................31 4-8 Smart Home Benchmark Tree..................................................................................42 4-9 H/M/L Calculation...................................................................................................43 4-10 Location Positioning System Benchmark Tree........................................................47 4-11 lps H/M/L Calculation..............................................................................................47

PAGE 9

ix Abstract of Dissertation Pres ented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science BENCHMARKING SMART HOMES USING THE HUMANOID ROBOT APPROACH By Satish Kumar Veerapuneni August 2004 Chair: Abdelsalam (Sumi) Helal Department: Computer and Information Science and Engineering A smart home in simple terms is an entity comprising of devices that can be controlled via the Internet. As smart homes ha ve greatly penetrated the market place in the recent decade, various organizations have developed there own proprietary stack and therefore interoperability has become a major bottleneck. This has put forth the need to benchmark, that could help evaluate the “smart homes.” To address the problem of knowing how smart the home is, there was a need to have human-like robot to emulate the person staying in the smart home as this would trigger applications based on some specific sensory inputs placed on it. This thesis was accomplished in various stages; we have built Robotilda a humanoid robot named Matilda that is c ontrolled by a PDA via a wireless network. Secondly, we have defined an n-ary tree model (i.e. a tree with up to n metric tree nodes as its children which in turn are n-ary trees) that is used to evaluate the smart home. To this end, we have performed benchmark tests us ing an intuitive/binary model in the mock

PAGE 10

x smart home at the pervasive computing lab, to evaluate the metric values of various metric trees. Further, the benchmark valu e of the benchmark tree is evaluated by a weighted average of the children nodes, in a post order fashion. Finally, an illustration on using the general benchmark mechanism to eval uate a component of the smart home, i.e. the location positioning system, is demonstrated This is chosen for illustration purposes as RobotildaÂ’s position is determined by the Location Positioning System, which in turn invokes various applications in acco rdance to the location context.

PAGE 11

1 CHAPTER 1 INTRODUCTION The steep decrement in the cost of integrat ed circuits and advances in their design over the years, in accordance to “ Moors Law” [1] has made the creation of a smart device possible with great ease. The expansiv e growth and penetra tion of the internet with cost effectiveness of the smart devices over the years, has increased adoption of smart devices. A smart home in simple terms is an entity comprising of devices that can be controlled via the internet. For instance, in the pervasive computing lab at UFL [2] the mock smart home is the entity and the ot her house hold items like the microwave, TV, bed light, etc are the devices that can be c ontrolled via the internet. The programmability and the connectivity of devices entice people to use them in ways that could only be dreamt of in the past. smart homes in essence help improve the quality of life of people. As smart homes have greatly penetrated the market place in the recent decade, various organizations have developed there ow n proprietary stack fo r the smart home and hence interoperability is a ma jor bottleneck for the solutions developed. This thereby has lead to increased need for transparency and portability of the software used to help achieve smartness. At the pervasive computing lab at UFL, we have envisioned a layered architecture for the software used in the smart homes th at address the problem of interoperability. Openness is achieved as the architectur e developed is platform independent. Transparency with a layered architecture is achieved as the upper la yer could perform the

PAGE 12

2 task of reading a location coor dinate of the person living just by calling a lower layer’s class method without bothering a bout the intricacies involved in the process of obtaining it. In recent years, many organizations have developed their own interoperable stacks for the smart homes. This has hence put fort h the need to benchmark [3], which could help evaluate various “smart homes.” To address the prob lem of knowing which is the smartest, there is a need to have human-lik e robot to emulate the person staying in the smart home as this would trigger applica tions based on some specific sensory inputs placed on it. This thesis is organized as follows. Chapter 2 presents various initiatives in building smart homes. Chapter 3 is an overview of the metrics for benchmarking smart homes. Our approach for the solution proposed is presented in Chapter 4. Finally, the last chapter, i.e. chapter 5 presents the future wo rk and the conclusions.

PAGE 13

3 CHAPTER 2 SMART HOME SURVEY A home or a working environment that includes technology to control the devices and the environment could be termed as a smart home. The extent in which the home could be controlled is dependent on various factors like: oneÂ’s own wish, investment willing to make in the technology, etc. In a traditional smart home environment, one could have two types of interact ions, user initiated or system initiated. For instance, home automation can assist a person to control a device in another part of the house, inquire into the state of something (e.g. Is the electric light on or o ff? Is the front door open or closed? Is the television on/ off? Is the shower on/off?). This can facilitate communications and enhance both personal and building security. On the other hand, the controller can also suggest appropriate acti ons when necessary, (e.g. It could prompt, should you not turn down the cooker? The tub ta kes a few minutes to fill up, please wait? Your favorite program is aired on television, tune into channel 10 ? DonÂ’t touch the food, the food is hot?) People who have short-term memory problems such as those with head injuries or those with AlzheimerÂ’s disease [4] may find the later attribute of the smart home very appropriate. In this chapter I have discussed a fe w on going renowned smart home projects like the RERC Smart Home Project (UFL), Mi llennium Project(Berlin) [5], House_n Project(MIT) [6, 7], Aware Home Project(Gat ech) [8]. One thing in common to all the above listed projects is that, all of them have an aim to address, i.e. make living easy for people, by using technology as an enabler.

PAGE 14

4 2.1 Robotilda Smart Home The RERC Smart House (Figure 2.1) occupies about 500 sq. ft. in the University of Florida Pervasive Computing Laboratory. The h ouse consists of a bedroom, a bathroom, a living room, and a kitchen. This house se rves as a development platform and inlaboratory test bed of a protot ype system and applications. 72.0 x 72.0 Elder Monitor A Monitor B Monitor C Monitor D (0,0) Ultrasonic location sensor Living area Kitchen Bathroom Bedroom Figure 2-1. The RERC Smart House As indicated in Figure 2.1, four ultrasonic receivers are placed in the ceiling above each corner of the house perimeter. Also, four flat panel monitors are mounted on each wall to deliver visual messages to the occ upant. The mockup house is instrumented with other sensors and devices, including J2ME smart phones [9, 10] as user devices, floor sensors, water leak sensors, RFID tags, X-10 controlled devices (door, mailbox, curtain, lamp, and radio), and networked devices (microwave, fridge, and cameras). The heart of the smart house is the ultras onic location system [11, 12]. Applications in the smart home like Modia [13] (essentially, smart controller of all the appliances) use for instance the location context information to switch to the appropriate monitor in the house. Besides, this context places a key ro le in determining any sort of anomaly, like

PAGE 15

5 falling down on the floor, at home and let the caregiver know if necessary. This essentially is done using the logging of th e data and analyzing it through an anomaly detection algorithm. 2.2 Millennium Home ItÂ’s a smart home project initiated by the biotechnology department at the Brunel University, along with a group of industry leader s. The goal of this project was to build a system that is a fool proof soluti on to Anomaly detection in homes. Figure 2-2. Millennium Home Floor Plan One of the unique aspects of the Millennium home project is that the person living in the smart home is provided with an al arm sensor, which in turn would allow the

PAGE 16

6 resident to interact with it. As was describe d in the technical document of the project the following are amongst some of the sensors used in the home: Passive infra-red sensors (PIRs) to detect movement Custom made pressure sensors which will be placed underneath the legs of chairs and beds to detect whether the user is sitti ng or lying down Burglar alarm style sensors on windows and doors A simple custom-made body count sensor on th e main entrance to the property so that the system will know how many peopl e are in the property at any one time. Besides, the system initiated events, the project also implemented various user initiated events for instance, a multimodal in terface, based around speech, is one of which used to relay user initiated events to the underlying system. The system communicates to the resident through on the following means: Loudspeakers placed in all rooms The television screen (activated though a computer) The telephone, which can ring the resi dent (activated though a computer) The resident will also communicate with the system through: Voice recognition The activation of environmenta l sensors (e.g. shutting a door) A yes/ no button for simple communications In order to enable voice recognition, a capab ility to being able to control some noisy domestic equipment using the X10 protoc ol is provided too. Shown in Figure 2.2 are some of the key sensors used in the Millennium home.

PAGE 17

7 2.3 House_n Project The House_n consortium at MIT has desi gned a unique “living laboratory” (Figure 2.3) shared research facility called the PlaceLab. This is sight ed in various references to be one of the very first in itiatives on smart home envi ronments. Hundreds of sensing components have been installed in nearly ever y part of the home, wh ich is a one-bedroom condominium in a residential building. Thes e sensors are being used to develop innovative user interface applic ations that help people easily control their environment, save resources, remain mentally and physically active, and stay healthy. The sensors will also be used to monitor activ ity in the environment so that researchers can carefully study how people react to new devices, systems, a nd architectural design strategies in the complex context of the home. Figure 2-3. Placelab The home is occupied by volunteer subject s who agreed to live in the home for varying lengths of time. While they occupy th e facility they will ha ve no contact with researchers, and the laboratory has been desi gned so that data can be analyzed off the site. Researchers will have the capability to monitor nearly every as pect of life in the

PAGE 18

8 home, particularly what peopl e are doing and the interior and exterior environmental conditions. Tools for the semi-automatic annot ation and pruning of data aids researchers studying the enormous amounts of data acq uired daily by the laboratory. Some occupants are studied living in their own home environmen ts as well using a portable toolkit of sensors that has been develope d by MIT researchers. These devices make remote monitoring of people in their own homes possible for some period of time before and after they enter the PlaceLab in order to investigate pre and post-occupancy behavior changes. In essence, the project essentially is us ed to investigate the following questions about human behavior, among others: What influences the behavior of people in their homes? How can technology be effective in the home context for long time periods? Can technology and architectural design motiv ate life-extending behavior changes? To what degree can measurements of activ ity in the home be quantified in a way useful for creating new computer applications for the home? How can technology be used to simplify th e control of homes of the present and future, save resources, and improve health? What influences how people adjust to new environments? How do people learn in the context of the home? What new innovations for the home would most fundamentally alter the way we live our everyday lives? To be able to delve into various areas of research like proactive health care, analyzing activities of daily life, monitori ng using biometric devi ces, testing indoor air

PAGE 19

9 quality, privacy protection, etc for the smart home environmen t, various components like microcontroller and light sensor, motion sens or, humidity sensor, smoke detector, IR illuminator, IR motion sensor, CO2 sensor, barometric pressure sensor, IR transmitters microphones, 1-wire network connection, Ethernet connection, and power are incorporated into the living-home. 2.4 Aware Home The Aware Home is a project initiated by Ge orgia Institute of T echnology. It is also referenced along with the House_n project to be one of the very first in the smart home research initiative. This home has essentially two identical and inde pendent living spaces, consisting of two bedrooms, two bathrooms, one office, kitchen, dining room, living room and laundry room. In addition, there is a shared basement with a home entertainment area and control room fo r two centralized computing services. Figure 2-4: Aware Home

PAGE 20

10 The reasons for building two independent li ving spaces are to allow for controlled experiments with technology and to allow inhabitants to live on one floor while prototyping or providi ng demonstrations on the other floor. The initial occupants are students involved in the research project liv ing in only one floor of the house. A longerterm goal is to have both floors occupied by a family or elderly occupants, as these are the targeted groups of there research. These o ccupants will give more realistic feedback on the performance of systems within the hous e. This systems includes sensors like human position tracking using ultrasonic technology, RF technology [14] and video, recognition through floor sensors and visi on techniques among various other sensors similar to the other smart home initiatives discussed previously.

PAGE 21

11 CHAPTER 3 METRICS TO EVALUATE THE SMART HOME This chapter talks about the need to benchmark and the metrics we consider important for benchmarking a smart home [15, 16 ]. To motivate in this direction, some of the questions that come to mind while consid ering getting oneself a smart home are the following: Would the smart home be intervening in my daily tasks? Would the smart home allow me to interact with it to perform a specific task (for instance, tell the air conditioner to lower the temperature, tell the fireplace to switch on/off)? Would I be able to switch the smart home to non smart mode when desired (This conserves a lot of en ergy (power/cost))? Would I be able to change the smartn ess level of the home, say not allow a particular feature to work for a given period of time? Is my privacy lost? How easy is it to upgrade the system with new features (I have a new feature like a smart floor added to the existent system, ho w easy is it to integrate it to the existent home?)? Is the smart home adaptable to additions made, with ease (I have one more person in the smart home joining me for a certain period of time, one expects the home to

PAGE 22

12 be able to accommodate him i.e. help hi m take full advantage of the smartness of the home?)? Does having a smart home lo wer my self-confidence? Is the smart home secure enough from intrude rs, as itÂ’s always on the network? Do I have authentication mechanisms to ensure my system doesnÂ’t get compromised? Is the smart home making living easier for me, i.e. is the smart home an enabler? Is the smart home cost-effective? These are just a few of the innumerous que stions that one has in his/her mind. To address the above questions we need a model to analyze the smartness of the home. In the pervasive Computing Lab here at UFL, we have come up with a few metrics to help evaluate a smart home. I have assumed that there are two inhabitants in the smart home named Alice and Bob for illustrative purposes. Th e following would state and give a brief description of the metrics. 3.1 Intrusiveness If Alice or Bob are scheduled to have th e medicine and the medicine box is empty, the assumption is the smart house would get th em refilled before the medicine box is empty and hence the box is never to be s een empty. If this didnÂ’t happen and the house expects the intrusion of the person living in getting the medicine box refilled, there is great dependency by the smart home for events to be performed. In sum, the smart home should be proactive towards a given task and not dependable on its re sidents for periodic tasks like medicine box refilling.

PAGE 23

13 3.2 Scalability Alice bought the smart house from a third pa rty, i.e. with a proprietary stack built (i.e. the software used to achieve smartn ess in the house, typi cally called stack in computer science terms) by say “XYZ”. La ter Alice got married to Bob and Bob’s presence/addition to the house has to be noted in to the smart environment. We need to be able to add new features to the house with ease. In the A lice/Bob’s world it should never be the case where in a change to the whole system has to be performed to get Bob into the system. In sum, scalability to a given syst em is generally consider ed to be one of the prerequisites to help achieve market presence. 3.3 Heterogeneity When Alice gets an additional smart compone nt say a refrigerator and fits it into the smart home and then Bob gets another i.e. a smart microwave and fits it into the system, they should not have problems installin g them into the system because both the components were not made by the same manuf acturer and also not the same company that provided the smart home for Alice and Bob. The smart home should be able to accommodate technologies from various provide rs i.e. “XYZ” could have its own smart gas/electricity system installed and fitted into the smart home made and assembled by “ZYX”. 3.4 Security Alice and Bob do not want intruders to access the system. The maintenance guy of the smart refrigerator could occasionally peek into the system and see if everything from the smart refrigerator’s perspective is f unctioning alright. If sa y Chuck now tries to intrude into the system and try control/modi fy a few system components, he should be forbidden from doing so, besides notifying th e residents/service pr oviders of a possible

PAGE 24

14 intrusion (this is achieved by using an authen tication module in the system). The security of the home could be achieved by restrain ing the access in a very “sand box” like manner. The home could define protec tion domains, for instance in the smart refrigerator’s case, the maintenance guy though given ability to get into the system and watch the smart refrigerator’s performance from time to time, is not allowed to get into the smart microwaves domain. This by en large is achieved by defining boundaries for the systems in use by the house. In sum, secu rity is becoming increasingly important to create a complete fool proof system. 3.5 Remote Maintenance As was just pointed out in the previous metric, the system after bought from the third party has to undergo maintenance, to achieve good performance from time to time. It’s said that most of the companies achie ve good top line benefits if their after sales service is good. To help this happen the system should have a provision to help maintenance people have access to the compone nt. Besides, there should be an eventing mechanism in the system to notify the ma intenance people of any potential hazard detected in the system to help be proactive/reactive in there job. 3.6 Atomicity If the house has sequence of operations performed for a given context. Say if the person is in the kitchen in front of the stove at location (x, y), the following events like the stove preparing itself to heat up, the ove r head light switching on, the exhaust fan getting switched on, the music system getting switched on, etc should get performed in a sequence. All these happen in a sequence only when the given person, in our case Alice is at the location (x,y) and in fr ont of the stove. We can’t come across a situation where in all the above accept the exhaus t getting switched on, this woul d be inappropriate to the

PAGE 25

15 cooking event. Hence the system should have a property of all or none getting performed, i.e. either all the events dependent on a give n context (a set of lo cation /time/ person) none of them being performed, also in the later case throwing an exception to the maintenance guy/owner of that particular system to perform the maintenance/checking operation. 3.7 Durability As was mentioned for the previous me tric, We have a sequence of events performed in an all or none fashion if and onl y if one is sure all of them are functioning properly and not being used by ot herÂ’s at that instant. By this we mean the event should be done once the commitment of the system to the given context is achieved. 3.8 Isolation If say both Alice and Bob want to perf orm a given event on the system, both the events are serialized to achiev e isolation i.e. achieve serial execution of the tasks, hence there are no conflicting operations though there are two or more events happening at the same time. Indeed, this is what happens at the architecture level. But at the processor level, we have the both events performed concurrently as the whole system is built on a shared memory single processor system. Besi des, isolation is al so associated with adaptability i.e. making the smart home smart based on what is needed to the given user. 3.9 Privacy People living in a smart home are afraid of compromise to there privacy as the whole system is hooked up to the internet. He nce itÂ’s extremely important to help the residents be aware of the fact that they are monitored if done so. This at least does away with the fact of being consci ous in a smart environment. Besides, the residents should have full control on whether to allow othe rs to monitor the smart home or not.

PAGE 26

16 3.10 User Friendliness/Experience The house should not be complicated to use for the residents, say if Alice wants to use the smart tub and is not able to figure out how to use it, the whole premise of making it smart to help achieve great end user e xperience is useless. Hence the smartness incorporated in the environment should easily sink into the daily deals of the resident. 3.11 Controllability Alice should be able to c ontrol a microwave in the same conventional manner if he wants to. Hence the conventional way of doing things should not be lost because of the incorporation of smartness into the device. Fo r instance, if Alice wa nts to use the smart microwave by operating on the digital butt ons he should be able to do it despite incorporation of RFID, etc te chnology to read the food ite ms and set the time for the cooking automatically. 3.12 Anomaly Detection The smart home should be able to detect if there is any sort of anomalies in the environment and determine the appropriate actio n to be taken. Say, if Alice is observed falling more than a specified (threshold spec ified in the system) number of times by the system, using anomaly detection algorithms on the data that is logged at the home computer for a given period of time, AliceÂ’s personal care taker should be informed of this by the system. 3.13 Latency The time taken for a given event to be performed should be within human acceptable range. Typically the human reaction time for an event is 2/3 rd of a second. If events take approximately within this time to perform the action, then the system is said to achieve six sigma level of performance. A lthough itÂ’s impossible to achieve this in real

PAGE 27

17 systems where the latencies range typically fr om one to five seconds, smart home system developers for good are increasingly concentr ating on reducing the latency associated with the system

PAGE 28

18 CHAPTER 4 IMPLEMENTATION 4.1 Test Bed 4.1.1 Robotilda Smart Home Architecture Most of the smart environmen t initiatives have focused on specific technologies to build the smart spaces, overlooking a long-term systematic plan for space evolution and interoperation. A wide variety of devices and services from different manufacturers and developers will constitute the future pe rvasive computing environment [17] where platform and vendor-independence w ould inevitably be an issue. Portability and interoperability can be en abled through the concep t of services [18, 19, 20] (i.e. application components) and contex t awareness [21]. Services from different sources can interact via a standardized service interf ace, even though they are unknown to each other. Context information and even ts will provide an anchor for the service interaction as well as for the intelligence of the smart environments. As illustrated in Figure 4-1, our middleware architecture for sm art environments centers on context-aware service discovery issues. 4.1.2 Context Discovery Our reference architecture has at the lowe st layer, the smart house sensor/device driver modules. The layers above this could use the platform dependent service offered by the lower layer modules in a very tran sparent manner. The context layer in our architecture defines context in the form tupl es like . The layer above

PAGE 29

19 the context layer is the generic services layer, which in turn defines a set of services that could be used by the applica tions written on top of it. Figure 4-1. Reference Middleware Archite cture for Assistive Environments The context information is continuously st ored in the context information manager that maintains the context database. An entry in the Service Repository represents a service in the smart space. Th e service is essentially represented in the form of service name, attributes, contextual property. 4.1.3 Services and Applications To support rapid application development and facilitate service composition, our middleware provides a set of generic servic es. As indicated in Figure 4-1, they are discovered and used by other core services or applications. The following is our current list of generic services. Voice recognition service provides voice-to-text tran slation service to other services and applications. Camera vision service tracks object movements in the cameraÂ’s view. Event broker service delivers an applicat ion-specific event to subscribed clients, when a certain condition specified in term s of context information becomes true.

PAGE 30

20 Location service provides the location informati on (e.g. x and y coordinate) of Robotilda or objects being tracked. Automated/scheduled task service performs scheduled or triggered tasks (e.g. reminders, alerts, etc) if their condition is met. Space sensing service monitors the placement and movement of objects in the house, and is able to present the informa tion with regard to the house floor plan. This service may be useful for a map app lication, or it can be used to locate a certain object in the house. Persistent storage service stores streaming sensor data that may be used for trend analysis, historical context extr action, and statistics later on. Web Service service is a proxy to access Web Servi ces [22] in the Internet. For instance, a grocery shopping application ma kes use of this service to order some food from online Web Service shops. 4.1.4 Prototype We have based our assistive environmen t infrastructure on the Open Services Gateway Initiative (OSG i) that provides a managed, extensible framework to connect various devices and services. By defining a standard execution environment and service interface, and by promoting dynamic discovery and collaboration of devices and services from possibly different sources, the goals of openness and extensibility of the smart house are attainable. In this sense, the OSGi framework is an ideal match for our need for an extensible software infrastructure that ca n adapt to changes (such as declining health conditions over time and the introduction of new devices, sensors, and services.) Moreover, we have found the frameworkÂ’s conn ectivity support to the outside world to

PAGE 31

21 be another noteworthy feature, which supports remote control and di agnosis applications by family members and caregivers. An OSGi environment (to be exact, an OS Gi Service Platform) is made up of a Java virtual machine [23], an OSGi Fram ework, and a set of bundles. The Framework provides general-purpose, secure support fo r deploying extensible and downloadable Java-based service applications known as bundles [9]. Running on top of a Java virtual machine, it provides a shared execution environment where bundles are installed, updated, and uninstalled without requiring the system to be restarted. The Framework also manages dependencies among bundles and serv ices to facilitate their interaction. A bundle may register zero or more services with the Framewor kÂ’s service registry, which are discovered through the registry by others The service registry provides a simple service discovery functionality based on a service interface name and a collection of key/value pair propert ies. The basic functionality is being extended to support the contextual property and cont ext-aware service discovery feature of our reference architecture. The registryÂ’s need of contex t information handling and update is backed by the underlying CIM. The smart house devi ce/sensor drivers in Figure 4-1 are implemented as OSGi device bundles, and all other components, including the Applications, the Generic Se rvices, and the CIM, are ma pped to a separate service bundle. The assistive space built on the OSGi fram ework provided a solid infrastructure so that our application development team coul d focus more on integrating the smart phone (and by extension, the resident ) with the smart environmen ts and various pervasive computing applications.

PAGE 32

22 4.2 Humanoid Robot Approach 4.2.1 Making of Robotilda The idea to have a robot in the demo house has occurred to us, when we have realized that we needed to do extensive testing and benchmarking of the software hardware involved in the smart home. This eventually addressed the following concerns that we had. How to entice someone to live in the house, while testing the smart home? How to have people see what the pers on living in the house can see, while demonstrating remotely? The secondary goal was addressed by havi ng a camera incorporated on Robotilda. The camera comes with an application progr am which helps people see what Robotilda sees remotely. This is accomplished as the cam has an IP-address hard-coded through the serial port. 4.2.2 Design of Robotilda These are the following goals th at I have met with the help of Steve and Harsha:It is able to move It is able to see It is able to avoid collision It has a universal Power supply It is controlled via a IPAQ/Computer It is able to have a IPAQ on it for processing outsourcing We started the making of Robotilda by desi gning the base on which it rests. The base has two wheels and motors along w ith some smart ICÂ’s for the robust communication with the other pa rts. The wheels are connected to the wind shield motors

PAGE 33

23 that are pulse wave modulated. This enables us to have variable speeds on the wheels. To be precise, I was able to have the spee d vary from 0-255, i.e. we could have 256 variations of the speed. The motors are connected to drivers that are in turn connected to the ATMEGA 128 [24] processor. The ATMega 128 processor is the brain of Robotilda, i.e. here is where the c program that contro ls the robot is residing, i.e. once we have a sensory data input the c program could instruct the motors to take appropriate actions. Besides I have also incorporat ed a few bump and IR sensor s [25], these help avoid the collision. The IR sensors work as they have a lower limit on the distance that an object could be placed with the robot, it works by emitting an infrared signal and receiving it back to calculate the distance of the obstacle. The bump sensors work by just a binary value, they are set when hit to an obstacle a nd otherwise not set. A block diagram of the system is shown in Figure 4-2. Figure 4-2. Block diagram for the Base

PAGE 34

24 4.2.3 Components In order to actuate Robotilda, we used two 12V DC gear head windshield wiper motors. We control the steering of Robotilda by sending separate PWM values to each motor. In order to control these motors we used two TECEL D100-B Motor Driver Boards [26]. These boards are capable of pow ering each motor with 25 Amps of current. These boards use three control lines which make these motor driver boards easy to use. The IN1 and IN2 pins control the direction of the motor, and the EN pin accepts PWM. Figure 4-3 and Figure 4-4 show how we conn ected the motor drivers to the motors. Figure 4-3. Tecel Motor Driver Enable IN1 IN2 Action H L L Fast Motor Stop H L H Forward H H L Reverse H H H Fast Motor Stop L X X Free Running Motor Stop

PAGE 35

25 This truth table (Figure 4.3) demonstrat es the functions provided by the TECEL D100b board. 4.2.3.1 Bump Sensors Because there are many available I/0 pi ns on the Progressive ATMega 128 board, we connected each of the 6 bump switches direct ly to Port B. We connected one end of the switch to ground and the ot her end of the switch went directly to our Progressive board. We have also activated an internal pu ll-up resistor on the ATMe ga 128, so that the Figure 4-4. Robotilda pin would only go low when the switch is pr essed. Based on the location of the switch, we decided which direction we would have Robotilda move when the switch is pressed. These switches are mainly used for obstacle avoidance. 4.2.3.2 IR Proximity Detectors The IR detectors that we used for the Robotilda are the Sharp GP2D120. These sensors have the capability of locating obs tacles between the distances of 4 to 30 centimeters. The output of this device is analog, and is updated approximately every 32ns. On Robotilda, we used three of these IR proximity detectors. We mounted all three in the front of the platform, since Robo tilda would primarily be traveling forward.

PAGE 36

26 4.2.3.3 Controller We have used the Atmega 128 processor fo r the purpose of controlling the robot. Atmega 128 [27] is a low power CMOS 8-bit microcontrolle r based on RISC architecture. By executing greater number of instructions for a given block, the throughput is considerable higher than its counterparts. The ATmega128 provided the following f eatures: 128K bytes of In-System Programmable Flash with Read-While-Write capabilities, 4K bytes EEPROM, 4K bytes SRAM, 53 general purpose I/O lines, 32 genera l purpose working registers, Real Time Counter (RTC), four flexible Timer/C ounters with compare modes and PWM, 2 USARTs, a byte oriented Two-wire Serial Interface, an 8-channel, 10-bit ADC with optional differential input stage with programmable ga in, programmable Watchdog Timer with Internal Oscillator, an SPI se rial port, IEEE std. 1149.1 compliant JTAG test interface, also used for accessing the On-c hip Debug system and programming and six software selectable power saving modes. Th e Idle mode stops the CPU while allowing the SRAM, Timer/Counters, SPI port, and inte rrupt system to continue functioning. The Power down mode saves the register contents but freezes the Oscillator, disabling all other chip functions until the next interrupt or Hardware Re set. In Power-save mode, the asynchronous timer continues to run, allowing the user to maintain a timer base while the rest of the device is sleeping. The ADC Nois e Reduction mode stops the CPU and all I/O modules except Asynchronous Timer and ADC, to minimize switching noise during ADC conversions. In Standby mode, the Crysta l/Resonator Oscillator is running while the rest of the device is sleeping. This allows very fast start-up combined with low power consumption. In Extended Standby mode, both the main Oscillator and the Asynchronous Timer continue to run.

PAGE 37

27 The ATmega128 AVR is supported with a full suite of program and system development tools including C comp ilers, macro assemblers, program debugger/simulators, in-circuit em ulators, and evaluation kits. We have used the Win AVR development environment to write/debug and compile the code. The details of Win AVR are discus sed in the “environments used” section. Figure 4-5. Avr Bootloader After the compilation, the obj ect code was to be uploaded to the ATmega 128 processors memory. This, was achieved using the Bootloader, i.e. an AVR Bootloader 1.9.0(Figure 4-5), there was a setting in th e GUI of enabled us to set the baud rate/communication port of transfer of the object c ode. A baud rate of 19200

PAGE 38

28 bytes/second and com2 port of the computer on which the transfer is made from, were selected. Besides, the port connections for the IRÂ’s and the Bump Sensors, which take in the various inputs from the sensors, ther e are USARTÂ’s (Universal Synchronous Asynchronous Receiver Transmitter) that take a se rial input from an external device. We had connected the Compaq IPAQ to USART_0, the other USART i.e. USART_1 was left idle. As was shown in the Block diagram of the Processor, all the components on Robotilda essentially connect to Atmega Processor if some sort of processing of the components input is to be done. 4.2.4 Software in Robotilda 4.2.4.1 Programming the ATmega 128 I had programmed the Atmega128 in C. The various header files of the C class used are avr/io.h, avr/in terrupt.h, avr/signal.h, string.h, avr/pgmspace.h. The io.h was used to enable the printf(), etc. functi ons, besides the general i/o functions. The interrupt.h and the signal.h ar e the two files needed to accept the sensory interrupts caused. The string.h included to use the string functions. The pqmspace.h is included to help allocate memory on the ATmega128 processor. The key functions written to enable th e moving of Robotilda possible in a very transparent way are the following:configuremotors(): This function is used to configure the motors take input from a particular pin. Also, the LEDÂ’s on the Atmega 128 are used to help know various stages of the program traversal as by blinking them at appropriate times in the traversal.

PAGE 39

29 init_UART(): This function is used to initialize the UARTÂ’s for accepting inputÂ’s from a serial port. Amongst the essent ial quantities initialized like setting the transmit/receive the baud rate is set to 19200 as was specified, for the baud rate in the bootloader. checkbump(): ItÂ’s is used to check if there was a co llision from the backside of Robitilda, as the bump sensors are placed on the back side Once, there is some sort of collision on one of the bump sensors, moving routines like right(), straight(), left (), etc are called to move away from the object that it collided from. checkir(): Similar to checkbump(), this is used to see if there is any object in the front in a range of 4-5 inches and would avoid the col lision with that object by backing off. The functions used to achieve this are similar to what are used in the checkbump() case. Wait(int): It was used to make the processor wait for a given time before calling the following command in the instruction sequence. This enabled discre tization of various actions performed by the processor on Robotilda. Movement Functions: This has left(), hardleft(), right(), hardright(), straight(), back(), stop(). As the name suggests, these functions are essentially used to move Robotilda to the left, right, straight, backward s and stop it from moving respectively. Besides these, there ar e couple of system functions used like sei(),cli(), output(), inp(); which are essentially used to set global interr upts, clear bits on th e pins, output certain hexadecimal value, read a particular input respectively. 4.2.4.2 Software for the IPAQs The interface for the IPaq essentially has buttons to control the robot. As can be shown in figure below, the controller connects to the server on the robot on the IP address specified on the server IP addr ess button and the port number specified by the Server Port button. I also incorporated the buttons to connect and to disc onnect with the server IPAQ,

PAGE 40

30 as I could have multiple users connect to the server at a given time on a time sharing basis. TCP doesnÂ’t allow multiple connections on a given IP and port number. The functions of the other buttons are as mentioned below: Figure 4-6. IPAQ Controller Interface Slow: ItÂ’s used to slow down the ro bot using the button, this he lps in varying the speed of the robot from 0-255, i.e. since I used PWM the speed could range from 0-255. Speed: This is used to speed up the robot using the button, this also as specified above helps in varying the speed of the robot from 0-255, i.e. since I used PWM the speed could range from 0-255. Front: ItÂ’s used to move the robot in the forwar d direction. This al ong with speed/slow buttons could help me achieve the requisite movement for the robot. Back: ItÂ’s used in moving the robot in the back wards direction. Again this is mentioned above is used in conjunction with the speed/s low buttons to achieve the movement that I needed. Stop: This is used to freeze the robot to a stand still position.

PAGE 41

31 Figure 4-7. IPAQ Server As shown in the figure above after the program is downloaded into the Compaq IPAQ using the serial port of the IPAQ, from the computer. The program is run from the files folder, by clicking on the executable just loaded onto the Compaq Ipaq. This then gives the interface of the controller as shown in the previous figure, to help control the robot. 4.2.4.3 Configuration and Setting The Cisco wireless LAN card was configured using the client utility that was provided by Cisco. The utility after installed was placed in the start/programs/cisco folder.

PAGE 42

32 Besides, I have used a utility to know the IP address set to the IPAQ. vxUtil is available for free on the web. This after insta llation has been placed in the start/programs/ communication folder. The “I” button has been activated to know the various wirelessLAN settings that the IPAQ has. For the Ad Ho c network I first chose the network type to be infrastructure-less network and named the network by ICTA i.e. the SSID, the respective names of the IPAQ’s as Robotilda and Mat. Besides, the other settings were, no gateway, no encryption, no LEAP, s ubnet mask as “255.255.255.0”. The only difference to have this work for an infras tructure mode is to change the mode of operation to infrastructure mode, beside s setting up the gateway information. 4.2.5 Development Environment 4.2.5.1 Visual Studio .NET 2003 With time handheld devices are becoming more capable. Processors are getting faster, and devices at the low end of the ma rket now come with 32kb of RAM, compared to 16kb a short while ago. Also, diverse ne tworking technologies like Wireless Lan 802.11, Bluetooth, Infrared, etc are built into the device. With so much of sophistication in the attributes incorporated into the new generation handheld devices, there was an in creasing need for a framework that could give in a managed execution environment for the device. Microsoft Inc, during the beginning of year 2000 had released .NET Comp act Framework [28] to address the need to manage execution environment for handheld devices. The .NET Compact Framework is for device s with the following characteristics:A capable CPU RAM for program and data storage Persistant Storage such as RAM disk

PAGE 43

33 In essence the .NET Compact Framework is a “lite” version of the full, desktop .NET framework. It includes a compatible subset of base class libraries of the full .NET framework, and it also adds in a few new ones that are specifically designed for mobile devices. The .NET Compact framework also has a new implementation of the common language runtime, built from ground up to r un efficiently on small devices that are constraint in both memory and CPU power and which must conserve battery power. Visual Studio 2003 includes the software and tool s needed to create applications that run on devices where the .NET compact framework is installed. The components necessary to install the .NET Compact Framework on the handheld device install onto the desktop computer when visual studio 2003 is installed. Visual Studio .NET 2003, is a comprehens ive development tool for creating the next generation of applications. Deve lopers can use Visual Studio .NET to: Build the next-generation Internet. Create powerful applications quickly and effectively. Span any platform or device. Visual Studio .NET is the only development environment built from the ground up to enable integration through XML Web services By allowing applications to share data over the Internet, XML Web services enable de velopers to assemble applications from new and existing code, regardless of platfo rm, programming language, or object model. 4.2.5.2 WIN AVR For Robotilda to have intelligence inco rporated in it, we have used ATMEL processors to talk to various motors and se nsors like the infrared/bump sensors. The key advantage of using the processors from ATMEL is the ability of it to be programmed in a very well defined high level language like c/c++.

PAGE 44

34 WinAVR [29] includes a set of tools lik e avr-gcc (the command line compiler), avr-libc (the compiler library that is essentia l for avrgcc), avr-as (the assembler), avrdude (the programming interface), avarice (JTAG ICE interface), avr-gdb (the de-bugger), programmers notepad (editor) and a few others. These tools are all compiled for Microsoft Windows and put together with a nice installer program. The version of WinAVR is essentially the version of the compiler AVRGCC, For example currently WinAVR includes version 3.3 of avr-gcc. 4.3 Benchmarking and Experiments The concept of benchmarking a smart home has evolved from the fact that the customer/manufacturer of the smart home n eeds to know if the t echnology used is good enough, given the requirements of the smart home. Table 4-1. Binary Analysis of Benchmarking Metrics Metrics Favorable(Yes) UnFavorable(No) Description Security [18, 19] Yes(1) We have not incorporated any security mechanisms into the system for the mock home at this moment but are using the security modules provided by the OSGI platform for the actual home integration of technology. Atomicity [20] Yes(1) This is ensured by the OSGI platform i.e. in similar lines as the operating system ensures atomicity for the applic ations running above it (the scheduler of the OS ensures every application gets there time slice to perform the operation on the occurrence of the event). Durability [20] Yes(1) The OSGI platform ensures that the operation is performed when an operation is triggered by a user or a sensor. Intrusiveness Yes(1) Most of the components in the mock smart home are triggered by events i.e. we have followed an event-driven model. This ensures there is minimal intrusiveness from the userÂ’s side to perform a given operation. Scalability [20] Yes(1) We have given at most importance to this while developing the software for the smart home. The idea of our integration of new components into the smart home is performed with great ease because of the software/hardware scalability incorporated into the design.

PAGE 45

35 Table 4-1--Continued. Metrics Favorable(Yes) UnFavorable(No) Description Heterogeneity [20] Yes(1) We have with great ease used technologies from various manufacturers [5, 9, 15] and have no platform dependent issues coming across while in the process of integrating these into the system. Remote Maintenance No(0) As of now we have not incorporated remote maintenance into the system. We plan to incorporate the remote maintenance into the system for the actual home that is to be built. Isolation No(0) As of now we have not incorporated remote maintenance into the system. We plan to incorporate the remote maintenance into the system for the actual home that is to be built. Privacy Yes(1) We have not compromised on the privacy of the home user by giving unauthorized access of the home to others. User Experience Yes(1) We have pe rformed usability tests by having people perform tests of various components in the house and have achi eved 85% acceptance level. Controllability Yes(1) Though we have incorporated smart components that are triggered by the operating context (Microwave operated after the RFID reader [15] reads the food package), we have not disabled manually operating the smart components. Anomaly Detection No(0) We have not enabled this feature in the mock home that we presently work on but plan to incorporate this in the actual home being built. Latency Yes(1) Avoiding unaccep ted time latency is the major concern for most of the developers in the field of smart environments. We have tried our level best in decreasing the time latency associated in the given event in the smart home. To understand and motivate this concep t in smart environments, we have performed benchmarking analysis using an Nary tree model in similar lines to threat modeling [30] performed in s ecurity aware systems. To this end, we proposed and performed a detailed study in the mock home built at the pervasive computing lab in the Computer Science Department, University of Fl orida (UFL). First of all in our model, we have tabulated the metrics (Table 4-1) a nd the binary value associated in accordance to their being addressed in the mock smart ho me. Later, we have illustrated in Table 4-2 one essential metric of the smart home: “T he Latency”. Our benchmarking mechanism

PAGE 46

36 for the smart home enables sub-component benchmarking as well. For instance, our model helps benchmark the “Location Positioni ng System” in the smart home using the generic benchmark mechanism. This is achieved by having Robotilda’s position trigger application’s like appliances control in the mock smart home and tabulating the latency associated with various applications, we then following the general benchmarking mechanism to evaluate it. Table 4-2. Smart Home Latency Chart Application Min-Latency (Sec) MaxLatency(Sec) Average (Sec) No of Simulations TV 5.5 6.3 6.0 6 Curtain 5.7 6.5 5.9 6 Microwave 2.7 3.1 2.8 6 Radio 4.0 4.9 4.5 6 Bed Light 2.1 3.7 3.1 6 Door Lock 0.9 1.3 1.0 6 Home Camera 2.4 3.0 2.7 6 LPS-TV 5.2 5.5 5.3 6 Table 4-2 has as columns the various applications, the minimum latency, the maximum latency observed in the tests carried ou t for an hour (i.e. six tests). It also has the Average and the number of simulations pe rformed in the tests during that period. In the following description I give a gene ral idea on how the various application latencies are evaluated. TV : We have associated time latency for TV to be the time it takes for the TV to switch on/hop channels, after a command is issued from the J2ME phone. Curtain: We have associated time latency for curtain to be the time it takes for the curtain to open/close, after a comma nd is issued from the J2ME phone. Microwave: We have associated time latency for the Microwave to be the time it takes for the Microwave to start the cooking operation afte r it reads the RFID from the food item.

PAGE 47

37 Radio: We have associated time latency for radio to be the time it takes for the radio to start/stop, after a command is issued from the J2ME phone. Bed-light: We have associated time latency for the light to be the time it takes for the light to turn-on/turn-off, after a co mmand is issued from the J2ME phone. Door Bell : We have associated time latency for the Door Bell to be the time it takes for the Home System to prompt the user of the open/close of the door. Home Camera: We have associated time latency for the camera to be the time it takes for the camera to show the picture of the person on the TV display when the door bell rings. LPS1 -TV : We have associated time latency for the LPS-TV to be the time it takes for the LPS to switch on an appropriate TV in accordance to the position of the person in the smart home. It performed by controlling RobotildaÂ’s movements in the smart home using the IPAQ; this in turn switches the appropriate monitor in accordance to RobotildaÂ’s position. From the table we also get the values associated with the Location positioning system for benchmarking the location positioning system module. We have restricted ourselves to switching on the appropriate TV in accordance to the location provided by the Location Positioning System. Though in reality we presume there could be many applications dependent on the Location Po sitioning System for the input state. Finally, we have performed the benchmar k value evaluation us ing a thirteen-ary tree model. We have followed a bottom-up approach in determining the benchmark value associated with the smart home. Th is was achieved by categorizing benchmarking of a smart home into various phases as described below: Phase I : Determining various metrics that evaluate the Benchmark Phase II : Sketch the Metric-Trees for each of the Metric Phase III : Evaluate the Metric-Value for each of the Metric-Tree 1 LPS stands for Location Positioning System

PAGE 48

38 Phase IV : Sketch the Benchmark-Tree for the Smart home Phase V : Evaluate the Benchmark for the Smart Home I would discuss in detail each of the above mentioned phases in the following sections.2 4.3.1 Determining Various Metrics that Evaluate the Benchmark This is the phase that was discussed in the section for “Metrics to evaluate the smartness of the home”. In sum, we have pr oposed a set of thirteen metrics, each of which is essentially a node in the benc hmark tree for the smart home (Table 4-1).3 4.3.2 Sketch the Metric-Trees for Each of the Metric We have in this phase drawn thirteen metric trees for each of the metrics to evaluate the Metric-Value associ ated with the metric tree. A Metric-Tree in simple terms is a tree rooted with the metric and whose ch ildren are in general, the attributes of the metric. To illustrate the idea, I have tabulat ed the metric trees corresponding to each of the metrics in Table 4-3. Table 4-3. N-ary Analysis of Benchmarking Metrics Metrics Metric Tree Description Security Security Metric tree has as it’s attributes the three pillars of security. Going by the Intuitive Model, in a smart environment we have assigned 4:3:2 weights to the three essential attributes. 2 Please note that having a bottom-up strategy in evalua ting a benchmark is just an issue of choice, one could as well perform the analysis in a top-down fashion. 3 Please also note that this generates a thirteen-ary tree and in general terms could lead to N-ary tree, depending on the metrics one proposes (we have proposed thirteen metrics in our model).

PAGE 49

39 Table 4-3. Continued. Metrics Metric Tree Description Security Security Metric tree has as itÂ’s attributes the three pillars of security. Going by the Intuitive Model, in a smart environment we have assigned 4:3:2 weights to the three essential attributes. Atomicity We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Durability We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Intrusiveness We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Heterogeneity We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Scalability We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1/0. RemoteMaintenance We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed).

PAGE 50

40 Table 4-3. Continued. Metrics Metric Tree Description Isolation We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Privacy We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). User Experience We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1/0. Controllability We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Anomaly Detection We have considered all the metrics other than Security and Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Latency We have associated Latency Metric Tree to have two component N-ary–trees (Appliances / Others). Each of these components is given a weight to the link in accordance to the intuitive model. Also, each leaf nodes of the Appliance and Others trees are evaluated using a binary model. Further, the links between the Appliance \Others trees and their children are weighted using an intuitive model.

PAGE 51

41 4.3.3 Evaluate the Metric-Value for Each of the Metric-Tree In this phase we have evaluated (as show n in Table 4-4) the value corresponding to each of the metric from the Metric-Tree. We have followed a Binary Model4 and an Intuitive Model5 to calculate the value associated with each node. The general idea behind evaluating a value to a node is bottom up, i.e. in a postorder fashion (evaluate the children before evaluating the root). Table 4-4. List of Metric Values Metrics Metric value Security 0 Atomicity 1 Durability 1 Intrusiveness 1 Scalability 1 Heterogeneity 1 Remote Maintenance 0 Isolation 0 Privacy 1 User Experience 1 Controllability 1 Anomaly Detection 0 Latency 1-0.38 The metric values for the metric trees ar e evaluated using Tables 4-1 and Table 4-2 for the mock smart home. The Latency Metr ic tree is evaluated using a weighted accumulation technique, i.e. each of its children is evaluated to determine their normalized value, after which we found the weighted cumulative of all the children. 4 In a Binary Model, we as sociate 0/1 value with each leaf node in the Metric-Tree 5 In an Intuitive Model, we associate an intuition driven value to each of the links between the tree node and its children

PAGE 52

42 4.3.4 Sketch the Benchmark-Tree for the Smart Home In this phase we have sketched (Figure 4-8) the benchmark-tree for the smart home i.e. a thirteen-ary tree in our model. We have further illustrated the Associate Matrix (Table 4-5) for the Benchmark Tree. Figure 4-8. Smart Home Benchmark Tree The calculation for the High, Medium, Low va lues is performed via an intuitive approach. I have illustrated it in Figure 4-9. Table 4-5. List of Metrics Precedence Metrics Associated Identifier (Value) Precedence Security a(0.1) High Atomicity b(0.063) Medium Durability c(0.063) Medium Intrusiveness d(0.1) High Scalability e(0.1) High Heterogeneity f(0.05) Low Remote Maintenance g(0.05) Low Isolation h(0.05) Low Privacy i(0.1) High User Experience j(0.1) High Controllability k(0.063) Medium Anomaly Detecti on l(0.05) Low Latency m(0.1) High

PAGE 53

43 Calculating the High, Medium, Low values Eq 1 : 6* High + 4* Medium + 3* Low = 1.0 ( law of equilibrium ) Eq 2 : High > Medium > Low ( law of semantics ) By Intuitive Model: 3* Low = 0.2, 4*Medium = 0.2, 6*High = 0.6 Hence, Low = 0.063 Medium = 0.05 High = 0.6/6 = 0.1 Figure 4-9. H/M/L Calculation 4.3.5 Evaluate the Benchmark for the Smart Home We have followed a cumulative approach in finding the benchmark value (Table 46) associated with the given smart home. Table 4-6. Cumulative Metric Matrix Metrics Metric Value Weighted Metric Cumulative Value Security 0 0 0 Atomicity 1 .063 .063 Durability 1 .063 .126 Intrusiveness 1 .1 .226 Scalability 1 .1 .226 Heterogeneity 1 .05 .276 Remote Maintenance 0 0 .276 Isolation 0 0 .276 Privacy 1 .1 .376 User Experience 1 .1 .476 Controllability 1 .063 .539 Anomaly Detect ion 0 0 .539 Latency 0.62 0.062 0.601 0.601 4.4. Benchmarking the Locati on Positioning System In this section we have demonstrated how one could benchmark a given component (Location positioning system) of the smart home using the general benchmarking model discussed in the section 4.3. We have very much followed the general phases (I V) of the smart home benchmarking mechanism to determine the benchmark value

PAGE 54

44 corresponding to the Location positioning system. The phases that we have followed in benchmarking the Location Positioning System are the following:Phase I : Determining various metrics that evaluate the Benchmark Phase II : Sketch the Metric-Trees for each of the Metric Phase III : Evaluate the Metric-Value for each of the Metric-Tree Phase IV : Sketch the Benchmark-Tree for the Location Positioning System Phase V : Evaluate the Benchmark for the Location Positioning System 4.4.1 Determining Various Metrics that Evaluate the Benchmark In this phase we have determined whic h of the thirteen metrics (in general n metrics) proposed for the smart home benc hmarking would be relevant for benchmarking the Location Positioning System. This is illustrated in Table 4-7. Table 4-7. List of Needed Metrics Metrics Needed(Yes) Not-Needed(No) Security No Atomicity Yes Durability Yes Intrusiveness No Scalability Yes Heterogeneity Yes Remote Maintenance No Isolation No Privacy No User Experience No Controllability No Anomaly Detection No Latency Yes As tabulated in the figure, the metric s that do not have any significance in benchmarking the location positioning system ar e marked with a “NO” and the ones with have significance are marked with an “YES”.

PAGE 55

45 4.4.2 Sketch the Metric-Trees for Each of the Metric We have in this phase drawn metric trees for each of the metrics significant to benchmarking the location positioning system. I have tabulated the metric trees corresponding to each of the metrics in Table 4-8. Table 4-8. Lps Metric Matrix Metrics Metric Tree Description Atomicity We have considered all the metrics other than Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Durability We have considered all the metrics other than Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Heterogeneity We have considered all the metrics other than Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1(if addressed)/0(if not-addressed). Scalability We have considered all the metrics other than Latency to be a one node tree i.e. a leaf node. Hence the value associated to it goes by Binary Model i.e. 1/0. Latency We have associated Latency Metric Tree to have two component N-ary–trees (Appliances/Others). Each of these components is given a weight to the link in accord-ance to the intuitive model. Also, each leaf nodes of the Appliance and Others trees are evaluated using a binary model. Further, the links between the Appliance\Others trees and their children are weighted using an intuitive model.

PAGE 56

46 4.4.3 Evaluate the Metric-Value for Each of the Metric-Tree In this phase we have evaluated (as show n in Table 4-9) the value corresponding to each of the metrics from the Metric-Tree. We have followed a Binary Model6 and an Intuitive Model7 to calculate the value associated with each node as was described in the general smart home benchmarking mechanism. Al so the idea behind evaluating a value to a node remains bottom up, i.e. post-order (eva luate the children before evaluating the root). Table 4-9. List of lps Metric Values Metrics Metric value Atomicity 1 Durability 1 Heterogeneity 1 Scalability 1 Latency 0.5 The metric values for the metric trees ar e evaluated using Table 4-7 and Table 4-8, for the mock smart home. 4.4.4 Sketch the Benchmark-Tree for th e Location Positioning System In this phase we have sketched the Location Positioning Benchmark Tree (Figure 4-10) for the smart home i.e. a five-nary tree in our model. We have further illustrated the Associate Matrix (Table 4-10) for th e Location Positioning Benchmark Tree. 6 In a Binary Model, we as sociate 0/1 value with each leaf node in the Metric-Tree 7 In an Intuitive Model, we associate an intuition driven value to each of the links between the tree node and its children

PAGE 57

47 Figure 4-10. Location Positioning System Benchmark Tree The calculation for the High, Medium, Low va lues is performed via an intuitive approach. I have illustra ted it in figure 4-11. Table 4-10. List of lps Metrics Precedence Metrics Associated Identifier (Value) Precedence Atomicity a(0.15) Medium Durability b(0.15) Medium Scalability d(0.3) High Heterogeneity c(0.1) Low Latency e(0.3) High Calculating the High, Medium, Low values Eq 1 : 2* High + 2* Medium + 1* Low = 1.0 ( Law of Equilibrium8) Eq 2 : High > Medium > Low ( Law of Semanticsl9) By Intuitive Model: 1* Low = 0.1, 2*Medium = 0.3, 2*High = 0.6 Hence, Low = 0.1, Medium = 0.15, High = 0.6/2 = 0.3 Figure 4-11. lps H/M/L Calculation 4.4.5 Evaluate the Benchmark for th e Location Positioning System We have followed a cumulative approach in finding the benchmark value associated with the given smart home This is illustrated in Table 4-11. 8 Law of Equilibrium it is a law that associates equality between the LHS and the RHS. 9 Law of Semantics it is a law that mathematically describes the semantic context.

PAGE 58

48 Table 4-11. List of lps Cumulative Metrics Metrics Metric Value Weighted Metric Cumulative Value Atomicity 1 .15 .15 Durability 1 .15 .3 Scalability 1 .3 .6 Heterogeneity 1 .1 .7 Latency 0.5 .15 .85 0.85

PAGE 59

49 CHAPTER 5 CONCLUSION AND FUTURE WORK Having a benchmarking mechanism to eval uate a technology/product is not new; we have used it in this thesis, to move a st ep forward in the dire ction of evaluating the smart homes. To perform this evaluation, we have used a Robot to simulate a living person in the mock smart home (smart home to benchmark). One of the key aspects of our work is the idea of evaluating the benchmark using an N-ary tree model, which in turn is evalua ted using a binary/intuitive model. The binary model is used to evaluate the leaf nodes in the N-ary tree, which evaluates to either 1(implemented)/0(not-implemented). The Intui tive model is used to evaluate the non-leaf tree-nodes in a post-order fash ion by weighted accumulation of the evaluated children. The value of root node i.e. the benchmark tr ee node is the evaluated benchmark value of the smart home. We have not made any conclu sions about what are the best values to have in terms of the benchmark value. This model essentially helps determine the best smart home, in a given list of smart home specifications. In our approach for benchmarking a smar t home using a humanoid robot we have used an intuitive model to ev aluate a non-leaf node in the Nary tree. We plan to use an alternative approach which is more robust and calculation transparent, i.e. we plan to develop a tool that gives the values for th e various metric nodes in the N-ary tree by performing live tests on the home computer.

PAGE 60

50 LIST OF REFERENCES 1. Silicon Moore’s Law. http://architecture. mit.edu/house_n/. Site last visited on April, 2004. 2. Rehabilitation Engineering Research Cent er. http://www.rerc.ufl.edu/. Site last visited on April, 2004. 3. Berlo, AV. “Design Guidelines on Smart homes.” http://www.stakes.fi/cost219/smarthousing.ht m. Site last visited on April, 2004. 4. Dewsbury G, Taylor B, Edge M. “Des igning Safe Smart Home Systems for Vulnerable People,” In Proceedings of the First Dependability and Healthcare Informatics Workshop Edinburgh, Scotland, 2002, UK, pp. 65-70. 5. Millennium Home. http://disc.brunel.ac.uk/ Site last visited on April, 2004. 6. MIT Media Laboratory. “Counter Intelligen ce.” http://www.media.mit.edu/ci. Site last visited on April, 2004. 7. The MIT Home of Future Consortium. h ttp://architecture.mit.edu/house_n/. Site last visited on April, 2004. 8. Aware Home Research Initiative. http://www.cc.gatech.edu/fce/ahri/public ations/index.html#overviews. Site last visited on April, 2004. 9. Giraldo C, Helal A, Mann WC. “mPCA – A Mobile Patient Care-Giving Assistant for Alzheimer Patients,” In First International Work shop on Ubiquitous Computing for Cognitive Aid, 2002. 10. Helal A, Giraldo C, Kaddoura Y, Lee C, Zabadani HE and Mann WC. “Smart Phone Based Cognitive Assistant,” In Fifth International Conference on Ubiquitous Computing 2003. 11. Hexamite, “Local Positioning System.” http ://www.hexamite.com/. Site last visited on April, 2004. 12. Hightower J, Borriello G. “Location Systems for Ubiquitous Computing,” IEEE Computer Magazine August 2001, vol. 34, no. 8, pp. 57–66.

PAGE 61

51 13. Helal, A, Winkler B, Lee C, Kaddoura Y, Ran L, Giraldo C, Kuchibhotla S, and Mann WC “Enabling Location-Aware Pervas ive Computing App lications for the Elderly,” In Proceedings of theFirst IEEE International Conference Pervasive Computing and Communications, 2003. 14. Texas Instrument RFID “Tag It Inlays.” http://www.ti.com/tiris/doc s/products/transponders/RI-I01110A.shtml. Site last visited on April, 2004. 15. Satyanarayanan M. “Pervasive Computing: Vision and Challenges,” IEEE Personal Communications Magazine August 2001, vol. 8, no. 4, pp. 10-17. 16. Weiser M. “The Computer for the 21st Century,” Scientific American September 2001, vol. 256, no. 3, pp. 94-104. 17. Lehmannn O, Bauer M, Becker C, Nickla s D. “From Home to World – Supporting Context-Aware Applications through World Models,” In Proceedings of the Second IEEE International Conf erence on Pervasive Computing and Communications January, 2004. 18. Marples D, Kriens P. “The Open Servi ces Gateway Initiative: An Introductory Review,” IEEE Communications Magazine December 2001, vol. 39, no. 12, pp. 110–114. 19. OSGi Alliance. “OSGi Service Platform.” http://www.osgi.org/resources/spec_download.a sp. Site last visited on April, 2004. 20. Henricksen A, Indulska J. “A Software Framework for Context-Aware Pervasive Computing,” In Proceedings of the Second IEEE International Conference on Pervasive Computing and Communications January, 2004. 21. Nagel K, Kidd C, O'Connell T, Dey A, and Abowd G. “The Family Intercom: Developing a Context-Aware A udio Communication System,” In Proceedings of the Third International Conference on Ubiquitous Computing 2001 March, 2001. 22. Tanenbaum SA. “Chapter 5: Synchronizati on, Distributed Systems – Principles and Paradigms,” Prentice-Hall of India, New-Delhi, 2002. 23. Engel J. “Programming for the JVM, ” Addison-Wesley, Reading, MA, 1999. 24. ATMega 128 Processor Specifications. h ttp://www.atmel.com/dyn/products. Site last visited on April, 2004. 25. IR Sensors Specification. http://www.acrona me.com. Site last visited on April, 2004. 26. TECEL Board Specifications. http://www.t ecel.com/d200/. Site last visited on April, 2004.

PAGE 62

52 27. Hennessy LJ, Patterson H. “Computer Architecture3rd Edition,” Morgan Kaufmann Publishers, San Francisco, CA, 2003. 28. Wigley A, Wheelwright S, Burbidge R, MacLeod R, Sutton M. “.NET Compact Framework (Core Reference),” Microsoft Press, Redmond, WA, 2003. 29. WinAVR Specification and Downloads. http:/ /www.avrfreaks.net/. Site last visited on April, 2004. 30. Howard M, LeBlanc D. “Chapter 4: Threat Modeling, Writing Secure Code, Second Edition,” Microsof t Press, Redmond, WA, 2002.

PAGE 63

53 BIOGRAPHICAL SKETCH Satish Kumar Veerapuneni has received his bachelorÂ’s degree in mechanical engineering from the Indian Institute of TechnologyBombay, India (IITB), in May 2002. After his graduation, he joined the Computer and Information Science and Engineering (CISE) department at the Universi ty of Florida for his graduate studies in August 2002. Satish, has been a part of Pervasive Co mputing lab since December of 2002. He has a passion for technology a nd his interests lie in m obile computing, pervasive computing, networking and network security in general. After graduation, Satish w ill be joining Intel-WPD San Diego, California, as a network software engineer.