A Document centric approach for supporting
Contents
1. Figure 5 Artefact Description File for the Mirror with Prox imity Profile of our example scenario 2 Profile Each profile represents a specific functionality and implements the underlying logic of the functions e g pro viding context by analyzing the attached sensors data or ac tuating an action by changing the artefacts state e g in creasing the lamp brightness etc Each profile is a sensor or an actuator type and has a profile handler a template to plug device code and context calculation or service actuation logic Due to a variety of sensors and actuators different artefacts are augmented with different sensors or actuators having different access and data semantics like Smart its 9 Mote etc Since the same functionality can be achieved by different sensors and actuators the profile handler has an ab straction layer that hides the heterogeneity of the underlying device platforms 3 1 2 Documents to represent Artefacts The artefact framework s core is packaged as a ready to run bi nary with a description document Artefact Description File ADF as shown in Figure 5 This file contains the basic information about the artefacts e g name vendor profile specifications etc When ever a new profile is attached to that artefact the corresponding ADF is updated to reflect the added capabilities of the artefact Pro file is packaged as plug ins that run atop the core and its services are expressed in2. istered in the FedNet system see section 3 3 an access point is assigned to the application An application needs to access this access point to send requests and receive responses from the under lying artefacts In our current implementation the application uses a SOAP request for polling or sending an actuation request to the artefacts For continuous polling i e subscription auto discover able RSS feed is used During the application s instantiation time the required physical artefacts data semantics lt detector gt and lt ac tuator gt nodes of the Profile Description File are send to the appli cation by the FedNet so that applications can understand the data format of the artefacts and can request or receive data accordingly In the current implementation we have provided a simple library in Java comprised of a SOAP Client and Auto Discoverable RSS Parser which the application developer can use to access the ac cess point 3 3 FedNet System In our approach both the applications and artefacts are infras tructure independent and expressed in high level descriptive docu ments Thus to create a runtime association between an application and the underlying artefacts an intermediator is needed that can connect the applications and the artefacts This intermediation is done by FedNet in our approach FedNet does this intermediation by utilizing only the documents of these applications and artefacts FedNet can contact the c
3. lt Jstates gt actuator b Figure 6 a Profile Description File for Proximity Profile Sen sorML is used in the lt detector gt node b Artefact Control Language is used for actuator profile only the lt detector gt node is replaced with lt actuator gt node can still exploit the environment resources we utilize task specifica tion of the applications An application is expressed as a collection of functional tasks independent of the implementation and infras tructure This specification allows the FedNet runtime to map the task to respective service provider artefacts An application devel oper can follow any library and implementation language to code the execution logic of the application The only two things neces sary for an application to run in a FedNet environment are 1 ex pressing application s functional task list in a description file and 11 utilizing an access point to manipulate the artefact services using generic web techniques Any application is composed of several functional tasks e g atomic actions In pervasive applications these atomic actions may be get current light sensitivity turn the air conditioner on sense the proximity of an object etc We assume that each functional task explicitly manipulates one artefact So one artefact might be shared by multiple tasks but a single task can not use multiple arte facts An application is expressed as a collection of such functional genet tt
4. where many things happen autonomously without providing visual feedback has little appeal to the end users 3 Since we solicit end users effective re sponses from deployment point of view it was very important that the end users are completely acquainted with the scenario at hand The apparatus used in the experiment are explained below 4 1 1 Mirror Display The mirror is constructed using an acrylic magic mirror board and an ordinary computer monitor Figure 11 a This mirror can be extended to improve its functionalities and is equipped with an extension board Figure 11 b The mirror is hosted in a net worked tablet PC following our At the Infrastructure approach as explained in section 3 4 We assume this augmented mirror with embedded computer can be bought from the store in the near fu ture 4 1 2 Display Application The application shows some up to date information weather stock currency exchange rate etc in a mirror display This ap plication is distributed as a executable binary along with a TDF Figure 11 f The application can work in different combinations of the following modes depending on the level of functionalities available in the mirror A p FedNet Kepository Fanel en Artelact Management Applikation Managenvent a 1 Basic Mode The application shows information as pictorial widgets in this mode 2 Sensor Mode In this mode the display is triggered only when someone is in fr
5. Deployment Process Our end users experiment revealed that the deployment process has to be as seamless as possible We found that the end users had difficulty using current web based deployment tool As we men tioned in section 4 3 ideally end users would only do the hardware installation which itself has to be self explanatory and the software installation has to be autonomous to ensure the balance with end users current practices with home appliances Considering these facts we are now working on a tangible interaction mechanism for software installation which will allow end users to touch a spe cific RFID tag embedding a URL that comes with the artefact and profile into a reader attached to the FedNet system that will au tomatically collect the artefact binary and profile implementation with corresponding Description File from a remote location and will install it into the specific artefact space Similar approach will be applied for installing the applications We reckon this will make the software deployment process for physical artefacts and perva sive applications more lucid from end users perspective Also we are working on providing a instantaneous visual feedback to end users for their deployment actions 6 RELATED WORK The end users support to entail a smart spaces incrementally re lies on instrumented artefacts and device integration technologies We will look at the related work in these areas 6 1 Augmented Artefac
6. Human Computer Interaction 16 2 4 2001 4 A K Dey G Abowd and D Salber A conceptual framework and a toolkit for supporting the rapid prototyping of context aware applications Human Computer Interaction 16 2 4 97 166 2001 5 W K Edwards V Bellotti A K Dey and M W Newman Stuck in the middle The challenges of user centered design and evaluation of infrastructure In The ACM Conference on Human Factors in Computing Systems CHI 03 2003 6 W K Edwards and R Grinter At home with ubiquitous computing Seven challenges In The Third International Conference on Ubiquitous Computing 2001 7 W K Edwards M Newman J Sedivy T Smith and S Izadi Challenge recombinant computing and the speakeasy approach In The Eighth Annual International Conference on Mobile Computing and Networking MobiCom 2002 8 K Fujinami F Kawsar and T Nakajima Awaremirror A personalized display using a mirror In Third International Conference on Pervasive Computing 2005 9 H Gellersen G Kortuem A Schmidt and M Beigl Physical prototyping with smart its IEEE Pervasive Computing 03 3 74 82 2004 10 B Johanson A Fox and T Winograd The interactive workspaces project experiences with ubiquitous computing rooms IEEE Pervasive Computing 1 2 2002 11 N Kohtake R Ohsawa M Iwai K Takashio and H Tokuda u texture Self organizable universal panels for creating smart surroundings In
7. adopted a profile based artefact frame work in our system Basic artefact functionalities are combined in a core component as a generic binary and additional augmented features can be added as plug ins atop the core Each augmented feature is called a profile in our approach These profiles are arte fact independent and represent a generic service This design al lows an artefact to act as a stand alone artefact and to participate in an application scenario thus supporting all four cases in Figure 3 Furthermore the generic binary makes the artefact infrastructure independent enabling end users to deploy them spontaneously Case 2 One application uses only one artefact with one or multiple functionalities Case l Stand alone artefacts with 2 one or multiple functionalities Case 4 Multiple applications use multiple artefacts with one or multiple functionalities Case 3 One application uses multiple artefacts with one or multiple functionalities Figure 3 Different association cases between the artefacts and the applications Actuator mhn N Communication Module Figure 4 Architecture of Artefact Framework 3 1 1 Internal Architecture of Artefact Framework The internal architecture of the artefact framework consists of the following Figure 4 1 Core Component Typically instrumented artefacts have some common characteristics e g communication capable 2 19 provides perceptual feedback
8. ical artefacts in a Do it Yourself DIY fashion without any com plex configurations Second developing applications and physical artefacts in an independent manner so that applications can cre ate a spontaneous federation at runtime and can leverage the richer services of the artefacts that are incrementally added These two challenges lead us to the following design decisions 1 DIY Instrumented Artefacts Artefacts should be reusable and augmented features should not be tightly coupled with the scenario or the artefact itself We need to abstract the augmented features in a way that can be applied to multiple artefacts and package the artefact in a generic binary so that the end users can deploy them In addition a common repre sentation is needed to ensure that an artefact can participate in any environment To meet these requirements we adopted a profile based artefact framework that represents an artefact End User Tool for End User Tool for Infrastructure Infrastructure Independent fs Independent Applications P k Artefacts BF AA Au am ented Artefact F Function DF Description File App Application Figure 1 Basic workflow of our approach in a unified way using a generic binary with structured docu ments and allows plugging multiple profiles into an artefact The profile is a single augmented functionality of an artefact The separation of artefacts and profiles enables DIY support i e an artefact can be instrum
9. users actions In our current ap proach the only way to realize a profile s functionality is by running the application However the participants were curi ous in knowing whether their action was successful instantly after the installation This missing feature caused frustra tion among the participants and was reported during the in terview This suggests that our artefact framework needs to have an instant feedback facility for the users actions 6 Intuitive hardware interface is needed Considering our participants performances and subjective feedback we con curred that the intuitiveness of the profile hardwares are es sential for the success of the DIY approach For example in our experiment except for the floor sensor all the sensors had one cable that could be attached to the mirror However there were two ports in the mirror for the cables and each port was specific to a profile 4 of the participants made mis takes in picking the right port These cases are reflected in the max values of Figure 13 a for task 3 and 4 Although it was clearly written in the manual they did not consult it and tried to do it intuitively Of course If the artefact is designed without further augmentation such port or other hardware interfaces need not be intuitive however for a DIY approach it is necessary that the hardware installation process is self explanatory Furthermore we noticed that the participants were quite serious about
10. 3 possesses memory etc The core component of our artefact framework encapsulates all these functionalities in a generic binary The communication module facilitates communication support and encapsulates the transport layer whereas the discovery module allows ser vice advertisement The notification module enables the rest of the modules to indicate their status The artefact memory is a shared space that contains artefacts property data profile descriptions and other temporal data The client handler is the request broker for artefact services and delegates the ex ternal requests to specific profiles Finally the profile repos itory hosts the array of profiles In the current prototype the profile repository is implemented following a plug in ar chitecture It has class loaders to load the artefact profiles dynamically when requested The entire core is packaged in a generic binary thus runs independently and can respond to applications requests The profiles can be gradually added to this core lt xml version 0 gt lt artefact gt SS toa lt name gt Mirror lt name gt Dynamically lt vendor gt lt vendor gt injected lt profiles gt Sos esace ccset a e a lt name gt Proximity lt name gt lt codebase gt ArtefactSpace Mirror ProximityProfile ProximityIRProfile jar lt codebase gt Perry Sererrrrerrrr rr ir i rrr irri irri iii rrr irri i i irr rrr rrr rrr lt profiles gt lt artefact gt
11. A Document centric approach for supporting Incremental Deployment of Pervasive Applications Fahim Kawsar Tatsuo Nakajima Department of Computer Science Waseda University Tokyo Japan fahim tatsuo dcl info waseda ac jp ABSTRACT This paper explores system issues for enabling incremental deploy ment of pervasive application the problem of how to deploy and gradually enhance the functionalities of applications in a pervasive environment We present a system architecture FedNet that pro vides the foundation for incremental deployment and uses a docu ment centric approach utilizing a profile based artefact framework and a task based application framework Our artefact framework represents an instrumented physical artefact as a collection of ser vice profiles and expresses these services in generic documents Pervasive applications are expressed as a collection of functional tasks independent of the implementation in a corresponding doc ument A runtime component provides the foundation for mapping these tasks to the corresponding service provider artefacts This mapping is spontaneous and thus enables gradual addition of ser vices Primary advantages of our approach are twofold firstly it allows end users to deploy pervasive applications and instrumented artefacts easily and gradually Secondly it allows developers to write applications in a generic way regardless of the constraints of the target environment We describe an implement
12. FedNet that maps the task specifi cations of the applications to the underlying artefacts functions by utilizing respective documents of the applications and the artefacts This spontaneity allows applications to leverage richer artefact ser vices that are added gradually In the subsequent section we present the design decisions fol lowed by the technical detail of our approach Then we proceed to the feasibility of the proposed solution by illustrating a real life deployment experiment session A smart mirror and a pervasive ap plication for the mirror were deployed and incrementally enhanced by the end users using our system Although the end user experi ment positively evaluated our system s support for the deployment activity it revealed several usability problems We report these findings along with the experiment descriptions After which we discuss some generic issues Finally we position our research with respect to the related work and conclude the paper 2 DESIGN ISSUES In this section first we draw a scenario to illustrate the concepts of this paper Then we elicit the design challenges and explain the design decisions to meet those challenges Alice recently moved into a new home and bought a new mirror augmented with a display for her wash room She found and down loaded an interesting application on the internet that can show some information e g weather stock quote movie listing etc in the mirror display a
13. Finally in phase four we had a questionnaire and interview ses sion 4 3 Experiment Result Figure 12 shows some snapshots from the experiment sessions There were 40 tasks in total four for each participant All partic ipants successfully finished the assigned tasks though two partic ipants needed active support in the early stages primarily because of the unfamiliarity with the FedNet deployment tool From a sys tem s perspective our approach provided a stable performance in Time In Minutes Adding Proximity Adding Bi State Interaction Profile Adding Artefact Installing Application Profile a Required time for the tasks Adding Artefact Installing Application Adding Proximity Profile Adding Bi State Interaction Profile Complexity Scale 1 Very Easy 5 Very Hard b Average complexity level for each task as perceived by the end users Figure 13 Average time taken and average complexities for completing experiment tasks all the sessions and end users activities were properly converted into the system events accordingly e g to add an artefact to the artefact repository to add profiles to form a spontaneous federation between the application and the artefact etc Regardless of the sen sor type and implementation profiles were seamlessly added into the artefact framework which highlights the capacity of our art
14. The Seventh International Conference on Ubiquitous Computing 2005 12 R Masuoka B Parsia and Y Labrou Task computing the semantic web meets pervasive computing In The Second International Semantic Web Conference 2003 13 A Messer A Kunjithapatham M Sheshagiri H Song P Kumar P Nguyen and K H Yi Interplay A middleware for seamless device integration and task orchestration in a networked home In Fourth Annual IEEE International Conference on Pervasive Computing and Communications 2006 14 Microsoft Corp Universal plug and play device architecture reference specification 15 O G C Inc Sensor Model Language SensorML implementation specification 16 T Rodden and S Benford The evolution of buildings and implications for the design of ubiquitous domestic environments In The ACM Conference on Human Factors in Computing Systems CHI 03 2003 17 M Roman C K Hess R Cerqueira A Ranganathan R H Campbell and K Nahrstedt Gaia A middleware infrastructure to enable active spaces IEEE Pervasive Computing pages 74 83 2002 18 J P Sousa and D Garlan Aura an architectural framework for user mobility in ubiquitous computing environments In 3rd Working IEEE IFIP Conference on Software Architecture 2002 19 M Strohbach H W Gellersen G Kortuem and C Kray Cooperative artefacts Assessing real world situations with embedded technology In The Sixth International Conferenc
15. a Profile Description File as shown in Figure 6 This file specifies the data semantics of the corresponding profile Each profile is a sensor or an actuator type Therefore the descrip tion file either contains a detector or an actuator node The sensor type profile s description follows the specification of the Sensor Modeling Language SensorML 15 Figure 6 a and expresses profile s output e g data format parameters etc The primary strengths of SensorML are its soft typed attribute reference frame and parameters with which the semantics of different sensor data platforms can easily be understood and interchanged For an actua tor profile our custom designed Artefact Control Language is used Figure 6 b where the state attribute is used to abstract the opera tional states of the artefacts This file specifies the required the in put parameters and their data types to change artefact states Each profile description also contains a quality of service QoS block which specifies the quality of the profile s service Adding a profile to an existing artefact requires hardware attachment and installa tion of the plug in implementing the profile atop the artefact core 3 2 Task Centric Application Framework Usually pervasive middlewares 4 17 18 provide their own ap plication model that the developers follow to utilize the environ ment resources This dependency limits the deployability of the ap plication To create
16. an engineering background and participated for the first time in this kind of experiment The experiment had four phases In phase one we introduced the concept showed the appa ratus and presented a tutorial on the web based deployment tool In this phase we also introduced the experiment tasks In phase two they were given 10 minutes to get familiar with the tools Next in phase three they were asked to attain the given tasks In this phase no direct assistance was provided except reference to the manual page containing the help This phase included the following four tasks e Task 1 Deploying and and running the mirror e Task 2 Installing and running the application The applica tion runs in Basic mode e Task 3 Adding either the Proximity or the Bi State Interac tion Profile into the mirror by selecting one of the two im plementations The hardware installation requires attaching the sensor to the mirror using magic tape and connecting the sensor cable to the interface board located in the backside of the mirror For the floor sensor hardware installation was not needed except for placing the floor mat The software instal lation required installing the plugin into the artefact binary After this task the application either runs in Sensor Mode or in Standard Mode depending on the selected profile e Task 4 Adding the other profile into the mirror and running the application combining the Sensor Mode and the Standard Mode
17. an infrastructure independent application that http xbow com products wirelesssensornetworks htm lt xml version 1 0 7 gt lt protile gt lt name gt Proximity lt name gt lt purpose gt Sensing the proximity lt purpose gt lt lype gt Sensoratype gt lt detector gt lt identification gt IR Sensor lt identification gt lt referenceFrame gt lt inputs gt OUTPUTS lt output lt name gt positionaname gt lt datatype gt string lt datatype gt lt value gt lt ouTpUt lt output gt lt name gt proximity lt name gt lt datatype gt int lt datatype gt lt Value gt lt output gt OUTDUTES gt lt parameters gt lt parameter gt lt name gt timestamp lt name gt lt datatype gt long lt datatype gt lt Value gt lt parameter gt lt parameters gt detector lt Qo05 attribute gt lt gos gt lt name gt latency lt name gt lt datatype gt int lt datatype gt lt measurement unit gt milisecond lt measurement unit lt high threshold 100 lt high threshold gt lt low threshold 50 lt low threshold gt goss lt Qo5 attibute gt g profiles a lt actuator lt identification cidentification lt states gt lt state gt lt Name gt ainame lt input lt name gt a name gt lt parameter gt lt MIMEdatatype gt lt MIMEdatatype gt Values lt value lt parameter gt lore Parameter lt input lt output gt lt name gt cname gt output lt state gt
18. e fact framework design for hosting multiple profiles implementing different device interfaces Furthermore the application running in the mirror could successfully switch to respective advanced modes when the profiles were added signifying the spontaneous federa tion facilities of FedNet Because of the runtime mapping of the applications tasks to artefact profiles whenever a new profile was added the application could leverage that profile s service This signifies the generality of our approach From usability perspective each trial session was held for 120 minutes on an average 44 minutes were required for the third phase accomplishing the four tasks Figure 13 shows the time Fig ure 13 a required for each task and the corresponding complexity Figure 13 b associated with the task We measure the complexity in a5 point scale with 1 as very easy and 5 as very hard These com plexity values are collected from the questionnaire sessions All participants have shown progress in repeating tasks and on an aver age they required 43 less time in redundant activities e g when adding the second profile plugin attaching hardware or restarting an application etc This indicates the fast learnability of our system from the end users perspective In the following we are reporting the implications of the subjective feedback that we received from the participants through formal interviews 1 Concept was difficult to comprehend The
19. e associated with the environment at runtime by the FedNet system Second We have reported a real life end user deployment session and findings from the experiment From a system s perspective our approach was successful in enabling the incremental deployment by the end users However the experiment also exposed several usability aspects of end user deployment process e g confusion arising from the notion of profiles and manual installation process need for different packaging intuitive hardware interface instanta neous feedback etc We consider these findings from our exper iment are very useful for further research exploration in the per vasive computing domain specially one that involves augmented artefacts 8 ACKNOWLEDGEMENT This research was supported by Ambient SoC Global COE Pro gram of Waseda University of the Ministry of Education Culture Sports Science and Technology Japan 9 REFERENCES 1 R Ballagas A Szybalski and A Fox Patch panel Enabling control flow interoperability in ubicomp environments In Second Annual IEEE International Conference on Pervasive Computing and Communications 2004 2 M Beigl H W Gellersen and A Schmidt Media cups Experience with design and use of computer augmented everyday objects Computer Networks special Issue on Pervasive Computing 35 4 2001 3 V Bellotti and K Edwards Intelligibility and accountability Human considerations in context aware systems
20. e on Ubiquitous Computing 2004 20 Sun Microsystems Inc Jini Specification Nov 1998
21. e specific wrappers and a range of APIs is provided to the applica tions to manipulate them However the problem of this approach is that the applications and the instrumented artefacts become vir tually incompatible in other environments In our approach we have adopted a document centric approach allowing development of infrastructure independent applications and artefacts and Fed Net provides the runtime association among them using respective documents 7 CONCLUSION We believe that in the near future end users will be involved in associating smartness in the home and this involvement must support the evolving nature of the home i e incremental deploy ment From a practical point of view this should be achieved by the end users To enable this we have presented FedNet a sys tem infrastructure that enables incremental deployment support for end users utilizing an artefact framework and a task centric appli cation framework The contribution of this paper can be seen as twofold First the plug and play artefact framework allows end users to deploy and to incrementally enhance a smart space with out going through complex authoring or configuration steps Our approach also allows an application developer to write applications considering the functionalities only regardless of the constraints of the target environment Since the profile abstraction essentially represents an artefact s functional capabilities applications can b
22. e ereans hd t lt xml version 1 0 encoding UTF 8 gt P lt application gt i Dynamically lt name gt Smart Display lt name gt a r age eee feteeeesneeet lt task list gt lt task gt lt id gt T1 lt id gt lt purpose gt Measuring Proximity lt purpose gt lt required profile type gt Sensor lt required profile type gt lt profile name gt Proximity lt profile name gt lt communication mode gt asynchronous lt communication mode gt lt profile QoS attribute gt lt qos gt lt name gt latency lt name gt lt datatype gt int lt datatype gt lt measurement unit gt milisecond lt measurement unit gt lt high threshold gt 70 lt high threshold gt lt low threshold gt 60 lt low threshold gt lt qos gt lt profile QoS attribute gt lt task gt lt task list lt application gt Figure 7 Task Description File partly for the display applica tion used in the presented scenario tasks in a Task Description File TDF Each task specifies the re spective profiles their quality of service and communication mode e g synchronous and asynchronous it needs to accomplish its goal Figure 7 shows part of the task description file for the appli cation presented in section 2 Each task may also contain Quality of Service QoS requirements for the target profiles The second requirement for an application is to use generic web protocols to manipulate the artefacts When an application is reg
23. e interface directly but the process to accomplish a task e g adding a profile etc Figure 13 a b also reflects these facts on an average 12 8 and 8 3 minutes were required to add profiles with associated complexities of 3 6 and 3 4 The end users mainly struggled in installing the profile plugin and we have found that the hardware in stallation was completed with less trouble The end users suggested that the process of profile deployment has to be plug and play when attaching the profile hardware the cor responding software should be installed with minimal inter vention This finding is crucial and has direct implications in our future work Package with different options was preferred over the DIY approach Several participants pointed out that they can buy a product with different functional granularity according to their preferences They concurred that the augmented arte fact should be similar for example one mirror could be packaged with a proximity profile and another with both pro files etc In this case they have the flexibility to buy dif ferent packages or to upgrade their existing package Al though they agreed that the DIY approach is fun interesting and inexpensive but it limits the acceptability of the product to amass population A participant pointed out J don t think my 58 year old mom could use your whole system Maybe it was ok for me But not for her I don t think she will be able to attach sensors o
24. ed prototype of FedNet and show examples of its use in a real life deployment by the end users to illustrate its feasibility Categories and Subject Descriptors D 2 11 Software Engineering Software Architectures Keywords Augmented Artefact Pervasive Application Deployment 1 INTRODUCTION We envision that with the proliferation of low cost sensors smart artefacts and spontaneous communication technologies pervasive applications will find a universal place in our everyday life A pervasive application usually involves physical artefacts i e sen sors augmented artefacts mobile devices displays etc Ideally these applications should be similar to home appliances i e easy Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page To copy otherwise to republish to post on servers or to redistribute to lists requires prior specific permission and or a fee MobiQuitous 2008 July 21 25 2008 Dublin Ireland Copyright 2008 ICST ISBN 978 963 9799 27 1 Kaori Fujinami Department of Computer Information and Communication Sciences Tokyo University of Agriculture and Technology Tokyo Japan fujinami cc tuat ac jp to setup adaptive to users needs styles and interchangeable with new models An e
25. ented by a suitable profile in an ad hoc manner Because of this loose coupling and stand alone characteristics our framework enables the incremental deployment support for end users just like in the scenario Alice can gradually enable the features of the application by adding multiple instruments to the mirror Infrastructure Independent Application Applications sh ould be developed considering the functionalities only To make an application independent of the Infrastructure it is imperative to know an application s runtime requirement ah ead of the execution Furthermore the application needs a generic access mechanism to interact with the environment We have addressed these challenges by representing an ap plication as a collection of functional tasks written in a task description file and allowing an application to access the arte fact services using popular web techniques SOAP for push and RSS Feed for pull In our example scenario the dis play application s runtime requirements were expressed in a document which was utilized to enable its features when ad ditional instruments were added to the mirror Spontaneous Federation An intermediator is needed to cre ate the runtime association among the applications and the artefacts both of which are infrastructure independent To form such a federation it is essential to understand the se mantics of the movable data ahead of the execution In our approach the inf
26. g the application and the artefacts When an application is deployed the corresponding application s task descriptions are extracted from the application repository by the FedNet Core Then it consults the artefact repository to identify the probable list of artefacts that can be federated considering the application tasks profile and QoS require ments Once the artefacts are identified FedNet Core gener ates a template of the federation collection of artefacts and their identities and maps this federation into a generic access point component for that application Then FedNet Core as signs this specific access point to the corresponding applica tion and injects the access point s identity in the TDF When an application is launched this access point is instantiated and the corresponding template is filled by the actual arte fact available in the environment right at that moment thus forming a spontaneous federation 4 Access Point is the generic component of FedNet that repre sents the physical environment federated artefacts needed by an application Since each application s artefact require ment is different and each application might not be running all the time FedNet assigns a unique access point for each application meaning multiple federations of artefacts can co exist in the environment Simultaneously each artefact can participate in multiple federations When an application is lunched it contacts it s Access Po
27. ing multiple artefact nodes and Fed Net can run in its own node to manage all other nodes The arte fact framework essentially is the digital identity of an artefact So an obvious issue is the location of this digital part We have two choices as shown in Figure 9 a At the Edge On Board b At the Infrastructure Off Board At the Edge means the artefact it self has a processing unit that hosts its digital representation where as the At the Infrastructure means a proxy running in a separate location represents the artefacts and communicates with the arte fact to retrieve sensor data or to actuate artefact s function using some communication protocol e g Bluetooth IEEE 802 11x etc Both choices have pros and cons While at the edge approach pro vides pre configurable and self sustainable artefacts it has mini mal support for DIY Do It Yourself approach and prone to lim ited capability On the other hand although at the infrastructure approach requires manual configuration and maintenance the pri mary advantage is the DIY support Also it enables rapid proto typing In our current implementation we have adopted At the Infrastructure approach and each artefacts digital representation i e artefact framework s binary core and profile plug ins are de ployed in a node that communicates with the physical artefact thr ough some communication channel to retrieve the actual profile ser vice via the hardware attached into the ar
28. int to know the avail ability of the artefacts required by its task lists The Access Point responds by specifying the tasks that can be supported 5 m Profile Profile z NS eA 4 Profile Profile f T Artefact f I o Profile Profile A lt Artefact Artefact En Pi 7 Profil Aeus w a At the Edge On Board b At the Infrastructure Off Board Figure 9 Location Modalities of Artefact Framework in the current environment by filling its template with actual artefacts It sends the mapped artefacts data semantics 1 e SensorML and Artefact Control Language to the application which allow the application to know the semantics of mov able data in advance From then on the application delegates all its requests to the access point which in turn forwards them to the specific artefact The artefacts responds to these requests by providing their profile outputs either by pushing the environment state actuation or pulling the environment states Sensing back to the access point that are fed to the application 3 4 Distributed Management In the earlier part of this section we have provided the explana tion of the functional roles of the primary components of our in frastructure From physical implementation point of view all these components could be distributed i e instrumented artefacts can run in their own nodes applications can run on the artefact nodes or in a separate node integrat
29. le implementations of the same profile as shown in section 4 1 3 essentially highlights the abstraction layer of profile handler Similarly end users can install any application that adheres to the FedNet requirement 1 e comes with a Task Description File and implements generic web techniques to access the access point Applications functionali ties can be enhanced by gradual addition of profiles into artefacts The combination of these approaches enables lucid support for end users to build and enhance a smart space incrementally 5 2 Profile Ontology Our artefact framework is organized as a collection of profiles and these profiles are derived from the designers of the system This profile notion has serious drawbacks from the standardization point Since we do not have a common vocabulary or ontologies that can be used to define profiles a pitfall of our approach can be seen in the profile based unification However by profile abstrac tion we are not trying to define the ontology for profiles In stead we are providing a structure that designers can use to disseminate their implemented ontology Defining the conceptual ontology in a standard way is the hardest part of pervasive computing not the encoding We are fully aware of that and do not claim that our platform is providing a solution to that Our contribution is provid ing an architecture that can glue the encoding structures with rest of the systems seamlessly 5 3 End User
30. nd installed it on the mirror While reading the application manual she realized that the application has some advanced features that can be enabled by adding some add ons in the mirror For example if the mirror is augmented with a sensor that can recognize someone s presence in front of it the applica tion can show the information only at that time for the remainder of the time it will switch to the power save mode Similarly if the mirror is augmented with an input device the application allows the user to interact with the application e g to know more detail about weather information Furthermore the application s infor mation sources can be personalized if the user can be identified For that the mirror needs to be augmented with an identification device e g a finger print reader etc Alice decided to enable all these features one by one A week later she bought an infra red sensor and placed it in front of the mirror now the application au tomatically goes to the power save mode when no one is in front of it After a few weeks she bought a touch button and a finger print reader and attached them to the mirror so that she can interact with the application more closely and personally Now her mirror application is running in full fledged mode just as she liked 2 1 Design Challenges and Decisions The above scenario poses us with two fundamental design chal lenges First allowing end users to incrementally deploy the phys
31. ng two ideal situations a a single everyday arte fact capable of playing multiple functional roles and b multiple artefacts sharing a similar functional role In Figure 2 a we have a smart table providing two supplementary functions an ambient display and a proximity detector In Figure 2 b we have a mir ror display 8 in a washroom which is triggered by any of the three augmented artefacts e g a toothbrush a comb or a razor The suitable augmentation of these artefacts depends on the under pinned scenario regardless of the multiple functionalities that can be afforded Simultaneously the characteristics of the application association with the artefacts require a new model for artefact pre sentation Consider Figure 3 where four different cases are shown In case 1 artefacts are stand alone providing a single or multiple built in functions without any applications Whereas in cases 2 4 three different modalities of application associations are shown Although these latter cases are supported by existing middlewares 4 9 17 through the notion of device wrapper these wrappers are tightly glued with the rest of the middleware these middlewares have no clean support in case 1 Artefacts are inherently dependent on the middleware and can not run in a stand alone mode Also to use augmented artefacts in these middleware environments appli cations are bound to follow the infrastructure semantics Following these observations we have
32. notion of arte fact profile and application were difficult for the end users to comprehend and differentiate For them the artefact and the application were the same they could not separate the application from the mirror This causes confusion while in stalling the application task 2 in thinking it was already in stalled when the mirror was added in task 1 This is reflected in the median time of 9 minutes taken for installing the ap plication as well as in the corresponding average complex ity as shown in Figure 13 a b They also had difficulties in understanding what a profile is as they associated the term profile with someone s background or record So they could not correlate how a physical object could have multiple pro files which also affected the performance in task 3 and 4 of adding profiles as shown in Figure 13 a b Since they could not understand the notions clearly it took time to install the profile into the appropriate artefact However the hardware installation was simple for them These facts suggest that our current notions are not self explanatory to end users and we need to provide a more comprehensive way of expressing these concepts Installation process was difficult Although all the partic ipants were familiar with the internet they found it difficult to use the web interface tool to install the artefact the ap plication and the profiles Later interviews revealed that it was not because of th
33. ntegration mechanism One approach is interface standardization as attempted by Jini 20 and UPnP 14 They describe devices using interface description and language APIs allowing applica tions to utilize the interfaces However they do not provide any artefact framework that enable incremental deployment in a mean ingful way Furthermore as new services or features are added into artefacts they can not be utilized by the applications because of the limited interfaces Patch Panel 1 is a programming tool that provides a generic set of mechanisms for interoperating and translating incoming events to outgoing events enabling interop eration among any set of devices that communicates using their EventHeap 10 communication platform Although this approach is seemingly lucid it does not specify how to support the develop ment of artefacts incrementally and how to express their semantics in a generic way so that any application can use those artefacts In SpeakEasy 7 mobile codes were exchanged among heteroge neous devices to create an interoperable environment Their ap proach requires a special runtime environment to be available at each device to exchange and execute mobile codes It is hard to expect that such a specialized mobile code at the device end can be added incrementally and it is impractical for augmented artefacts deployable by end users Although he has not considered the rep resentation of artefacts and applications his s
34. ommunicator module of the artefact core using the semantics described in the artefact documents for map ping application tasks similarly application can contact FedNet using generic web access mechanisms Since both the applications are artefacts are independent of FedNet and come as ready to run binary end users can install them in the respective environment seamlessly For supporting these installation an end user tool is Task Specification Query Artefacts Generate Repository Subset Application Specific Access Point Figure 8 Architecture of FedNet provided FedNet itself is packaged in a generic binary and com posed of four components as shown in Figure 8 1 Artefact Repository hosts all the artefact running in the en vironment During artefact deployment the executable bi nary implementing the artefact framework and the ADF is submitted to this repository When a profile is added to an artefact corresponding profile information is injected into the ADF Figure 5 and the profile is attached to the correspond ing artefact 2 Application Repository hosts all the applications that are running atop the FedNet system During application deploy ment the binary executable and the TDF of the application are submitted to this repository and the identity of the corre sponding application s access point is injected into the TDF Figure 7 3 FedNet Core provides the foundation for a spontaneous fed eration amon
35. ons that we addressed in this paper 1 building artefacts and applica tions in a way that are independent of the underlying infrastruc ture and deployable by the end users and 11 enabling application to adapt its functional behavior as richer artefacts services are in troduced We have explained our approach of specifying both the application and the artefacts through high level descriptions A run time component FedNet matches these descriptions to create a spontaneous federation This is useful for both the end users and the developers For end users it allows incremental editing of the smart space in a DIY fashion and for the developers it enables the devel opment of the infrastructure independent applications which can incrementally leverage richer artefact facilities To validate these claims we have evaluated our approach following the guidelines of Edwards et al 5 A proof of concept ubicomp system 8 that include multiple artefacts profiles and application are re developed following FedNet s approach and are provided to end users for real time deployment in a DIY fashion This deployment task is sup ported by the end user deployment tool In this section we present the end user trial and result of the study 4 1 Target Scenario and Apparatus We used the scenario introduced in section 2 excluding the per sonalization feature The scenario was picked because of its sim plicity and strong visual appeal A smart space
36. ont of the mirror and the rest of the time it switches to the power save mode blank display To enable this mode the application needs the mirror to be aug mented with a Proximity Profile that provides this positional context 3 Standard Mode The application provides two styles of pre sentation in this mode Initially the application shows the information in pictorial widgets which can be switched to textual presentation by interacting with the mirror To enable this mode the mirror needs to be augmented with a Bi state Interaction Profile which provides a two state switch func tionality to the mirror 4 1 3 Mirror Profiles To work in a full fledged mode the application needs two profiles in the mirror A profile functionality can be achieved by multiple instrumentations So both profiles have multiple implementation choices For each profile we have used two different implementa tions in this trial Each profile comes with a hardware a plugin binary and the Profile Description File A user manual is also pro vided containing the installation instructions 1 Proximity Profile This profile s sole purpose is to recognize the presence of an entity in front of the mirror This func tionality can be achieved in multiple ways i e using an infra red sensor a motion sensor a camera etc In our test we have provided two implementations with two different sen sors for this profile Figure 11 d The first one is with an Inf
37. r even install anything But she can use the microwave because it just works Similar views were received from other participants which indicate that the DIY approach is suitable for a specific class of users familiar with technology These facts signify that to make augmented artefacts available to a larger user base packaging with vari ant options is needed The incremental DIY approach can further extrapolate the packaging scheme Balance with current practice is required Participants noted that when they buy furniture or home appliances they do not need any software installation Usually they just plug it in and it works However in our approach software in stallation is required Although our process is identical to regular desktop computing it has no similarity with home appliances Thus the participants found it conceptually hard to think of the mirror as a piece furniture instead of a com puter This was further extrapolated by the fact that a tablet PC was attached to the mirror which made them perceive the mirror as aregular computer display They suggested that the software installation process should be absent and that the hardware installation should be the only task since it needs manual intervention 5 Instantaneous feedback is necessary It is essential that when a profile is added the new functionalities are reflected in the artefact instantly and erroneous installation is reported immediately to confirm the
38. ra Red Sensor and the second one is with a Floor Sensor Figure 11 c 2 Bi State Interaction Profile This profile enables a user to in teract with the mirror It provides a simple two state input facility which is suitable for the display application since a i Pedhet Repository Panel A Add New Application to App Repository a The Mirror b Mirror s Extensible Interface c Floor Sensor IR Sensor and Floor Sensor Figure 11 Mirror Artefact Profiles and Applications with their manuals user can navigate between the pictorial and the detailed pre sentation styles There are multiple instrument choices for the profile implementation In this test we have provided two implementations Figure 11 e one with a touch sensor and the other with a slider 4 1 4 FedNet The FedNet infrastructure and the web based deployment tool for the end users are running in a laptop computer 4 2 Experiment Detail The goal of our experiment is to involve end users in a DIY fash ion in deploying the mirror installing the application and then incrementally adding profiles into the mirror to enhance the ap plication s functionality We have invited 10 ordinary individuals Figure 12 Participants deploying artefacts installing applica tion adding profiles etc 8 Male 2 Female Age Range 21 35 with moderate computing skills through an open invitation in a social networking site 9 of them did not have
39. rastructure FedNet provides this intermedia tion It analyzes the task description file to extract the service requirements and then maps these tasks to underlying service provider artefacts by matching artefact description files Fed Net then assigns a generic intermediation component to the application that allows the application to access the services of the artefacts The spontaneous federation enables incre mental integration of applications In our example scenario due to this the application could use the added instruments whenever they are available Figure 1 shows the basic work flow of our approach An end user deployment tool works Ambient Display Proximity Detector a _ Person ye kientif hy Identifier n 4 Candedate m Artefacts 4 Figure 2 A single artefact with multiple roles and multiple artefacts with similar roles atop FedNet that allows ordinary individuals to deploy and interact with instrumented artefacts and pervasive applica tions Next we present the technical detail of our approach 3 SYSTEM DETAIL In this section first we present the artefact framework and the task centric application framework Then we will show how Fed Net utilizes these frameworks to create a spontaneous federation 3 1 Artefact Framework Augmentations of physical artefacts depend on the designer s in tuition and it is hard to confine the augmentation scope Consider Figure 2 depicti
40. ssential property of our living space is its evolu tionary nature and receptibility to continual change We incremen tally organize our homes with furniture and appliances according to our preferences and styles Previous studies have shown how end users continuously reconfigure their homes and technologies within it to meet their demands 16 Edward and Grinter echoed that the networked home of the future will not be custom designed from the beginning rather it will emerge in a piecemeal fashion 6 To support the evolutionary nature of our homes it is essen tial that pervasive applications and instrumented artefacts support the incremental deployment A user can buy physical artefacts and pervasive applications and should be able to install these just like other home appliances In addition he she can incrementally en hance an application s functionalities by purchasing new artefacts or upgrading the artefacts functionalities e g an application can provide a few basic services initially with the available artefacts and can incrementally provide more richer services as new func tionalities are added to the artefact These observations raise two questions 1 How does one develop smart artefacts and pervasive applications which can be deployed by the end users and 11 How does an application adapt its functional behavior with incremental integration of physical artefacts providing richer services To address these concerns we present a
41. system FedNet that pro vides the foundation for the incremental deployment of pervasive applications and physical artefacts It uses a document centric ap proach utilizing a profile based artefact framework and a functional task centric application framework The artefact framework repre sents an instrumented artefact in a unified way by encapsulating its augmented functionalities in one or multiple service profiles atop a core generic binary and allows additional profiles to be plugged into the core incrementally Such generality makes an artefact plug and play and allows end users to deploy it easily in a Do it Yourself DIY fashion The artefact framework expresses these augmented functionalities of an artefact in descriptive documents that allows applications to interact with that artefact Pervasive applications are represented as a collection of functional tasks atomic actions independent of their implementation and are exposed in a generic document The task in our framework is an atomic action that re quires an artefact s service like sense current humidity turn on the lamp etc Expressing application in this way allows devel opers to write applications without considering the target environ ments constraints Both the artefact framework and task centric application framework are independent of any infrastructure thus to create a spontaneous association among the artefacts and the ap plications at runtime we utilize
42. tefact The same is true for the applications 1 e the applications running on a single arte fact can reside in the same node that represents the artefact and the application that integrates multiple artefact can reside on the any of those artefacts node It is the FedNet components that organize these nodes in a distributed manner and manages the spontaneous federation The FedNet components i e Application Repository Artefact Repository and FedNet Core can reside in one or multiple nodes and manage the underlying artefacts and applications 3 5 Deployment Tool for End Users The components described so far provide the system foundation for the end user deployment However to involve end users in the deployment process a tool is needed that they can use to install the artefacts and applications into the corresponding repositories and to add profile plug ins into the artefacts Furthermore this tool should enable the end users to control run and stop these artefacts and applications In our current implementation a web based tool is provided for the end users to deploy artefacts and applications in the environment Using this tool end users can add and remove an artefact add and remove profiles to an artefact and run an artefact Furthermore endusers can install remove and run an application using this tool Figure 10 shows some screen shots of this tool 4 EVALUATION In the introduction section we have pointed out two questi
43. the aesthetics of the mirror while attaching the sensors Later interviews revealed that it is im portant for them to make sure that the overall appearance of the artefacts matched their style These facts suggest that the manual had a minimum role in the DIY approach and that the instrumentation has to be intuitive to the end users Although the feedback from the participants did not positively val idate the current state of our approach from the usability perspec tive we consider these results promising for future research on per vasive applications and augmented artefact deployment However from a system point of view our approach provided stable perfor mance and met the primary goals that we attempted to reach in this work 5 DISCUSSION For the purpose of discussion we would like put forth a few issues in this section 5 1 Modality of End Users Support One important discussion point is the type of support that is of fered to the end users in our approach The artefact framework is a generic binary with the support for plugging in multiple profiles So a new artefact either with profiles or without profiles come with a ready to run component that users can deploy using FedNet end user tool Also end users can gradually add new profiles to an arte fact without complex configurations As we have shown end users have the flexibility to select the appropriate profile implementation that matches their preferences The multip
44. ts One of the very first prototypes of smart object was Mediacup 2 where a regular coffee cup was instrumented to provide the state of the cup as context information Although the Mediacup project and its succeeding SmartIts 9 provide solid insight into the aug mentation of physical artefacts with sensing and processing they did not provide any generic representation model that can make them usable with any general purpose applications Tokuda and his group introduced Smart Furniture and u Textures to build custom furniture 11 however their approach is also closed and tightly coupled with their underlying scenarios The same is true for other projects in this area where various objects are augmented for pro viding value added functionalities 8 19 These objects work fine in a specific scenario however this assumption of scenario specific objects leads to a less reusable and closed development model The artefact framework presented in this paper takes a generic approach to solve this problem We present a service profile based framework to represent the instrumented features of the artefacts in an appli cation independent way We express this augmented features in generic languages which any application can use without prior un derstanding By doing so we make the instrumented artefacts plug and play this allows end users to deploy them freely 6 2 Device Integration To date several methods have been proposed to address device i
45. ystem is quite useful and can be integrated into our approach InterPlay 13 is a mid dleware for home A V networking and is similar to our approach InterPlay uses pseudo sentences to capture user intent which is converted into a higher level description of user tasks These tasks are mapped to underlying devices that are expressed using device description which contains property and grounding protocol infor mation However InterPlay predominantly focuses on A V devices thus does not provide any support for building artefacts incremen tally Our artefact framework is a major leap from InterPlay which signifies our contribution Also we do not consider user oriented tasks rather we express applications as a collection of functional tasks which enables developers to write applications without con sidering the constraints of the target environment Task Computing 12 initiative allows users to select a basic service or compose a complex service by combining multiple basic services but it does not provide a good user centric approach as the user spends a lot of time in understanding the services Also it has no support for incremental deployment of artefacts for end users A range of mid dlewares have been proposed in the pervasive literature 17 18 4 specifying their application development processes These middle wares usually provide end to end support for the application de veloper i e instrumented artefacts are wrapped into middlewar
Download Pdf Manuals
Related Search