Trondheim, 25th November 2004NTNU-IDISystemutvikling, fordypningTDT4735Adaptive Mobile Work ProcessesFrode HausoØivind RøedFaglærer: Alf Inge WangVeileder: Carl-Fredrik SørenseniiAbstract This report provides a literature study of issues related to context-aware work support systems. We have elaborated mobile work scenarios and requireement for context-aware work support systems, supporting adaptive, mobile work processes. Based on this, we have developed an architecture proposal which facilitates an implementation of these requirements. Importaan aspects of this architecture are related to nding suitable abstractions for context sources, coordination of workow between workow clients, local process enactment of workow clients by using templates and the contextual state of the environment, and the ability of workow clients to plan in situ. iiiPreface This report is the result of work performed as the part of the course TDT4735 by Frode Hauso and ivind Red at the Institute for Computer and Informattio Science (IDI) at the Norwegian University of Science and Technology (NTNU) in autumn 2004. We would like to thank our supervisor, PhD Fellow Carl-Fredrik Srensen, for his support and invaluable insights, ideas, and comments during our work. Trondheim 25th November 2004 ||||||| ||||||| Frode Hauso ivind Red iiiivContents 1 Introduction 1 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.2 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.3 Problem Denition . . . . . . . . . . . . . . . . . . . . . . . . 2 1.4 Outline of the Report . . . . . . . . . . . . . . . . . . . . . . 4 2 Research Methods 7 I Prestudy 9 3 Workow 11 3.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.2 Types of Workow Systems . . . . . . . . . . . . . . . . . . . 14 3.3 WfMC's Workow Reference Model . . . . . . . . . . . . . . 15 3.3.1 Interface 1: Process Denition . . . . . . . . . . . . . 15 3.3.2 Interface 2 and 3: Workow APIs . . . . . . . . . . . . 17 3.3.3 Interface 4: Workow Interoperability . . . . . . . . . 17 3.3.4 Interface 5: Administration and Monitoring . . . . . . 18 3.3.5 Interface c: Context Information Integrator . . . . . . 18 3.4 Adaptive Workow and Exception Handling . . . . . . . . . . 18 3.4.1 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4.2 Handling Exceptions . . . . . . . . . . . . . . . . . . . 20 vCONTENTS 3.4.3 Adaptive Workow . . . . . . . . . . . . . . . . . . . . 21 3.5 Workow Modelling . . . . . . . . . . . . . . . . . . . . . . . 22 3.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4 Context-Aware Computer Systems 23 4.1 Context and Context-Classications . . . . . . . . . . . . . . 24 4.2 Context-Sensing and Infrastructure . . . . . . . . . . . . . . . 26 4.3 Context-Aware Computing . . . . . . . . . . . . . . . . . . . 26 4.4 Challenges in Context-Aware Computing . . . . . . . . . . . 27 4.5 Advantages of Context-Aware Computing . . . . . . . . . . . 28 4.6 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 5 Activity Theory and Situated Actions 31 5.1 Situated Actions . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2 Activity Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2.1 The Basic Principles of Activity Theory . . . . . . . . 32 5.2.2 Principles Derived from Activity Theory . . . . . . . . 33 5.3 Situated Planning . . . . . . . . . . . . . . . . . . . . . . . . 33 5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 6 Enabling Technologies 37 6.1 The Context Toolkit . . . . . . . . . . . . . . . . . . . . . . . 37 6.1.1 Architectural Framework Features . . . . . . . . . . . 37 6.1.2 Architectural Building Blocks . . . . . . . . . . . . . . 38 6.1.3 Implementation . . . . . . . . . . . . . . . . . . . . . . 39 6.1.4 Framework Drawbacks . . . . . . . . . . . . . . . . . . 40 6.2 CORTEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.2.1 The Sentient Object Model . . . . . . . . . . . . . . . 41 6.2.2 CORTEX Middleware . . . . . . . . . . . . . . . . . . 42 6.3 Mobile Wireless Networks . . . . . . . . . . . . . . . . . . . . 43 6.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 viCONTENTS 7 Sensors and Actuators 45 7.1 Sensors Like Dust and Brilliant Rocks . . . . . . . . . . . . . 45 7.2 Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . 45 7.3 Wireless Sensor Nodes . . . . . . . . . . . . . . . . . . . . . . 47 7.3.1 Non Context-Aware Sensors . . . . . . . . . . . . . . . 47 7.3.2 Context-Aware Sensors . . . . . . . . . . . . . . . . . 47 7.4 SensorML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 7.5 Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 7.6 Intelligent Artifacts . . . . . . . . . . . . . . . . . . . . . . . . 51 7.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 8 Social Aspects 55 8.1 Human Aspects of Context . . . . . . . . . . . . . . . . . . . 55 8.2 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 8.3 Social Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 8.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 9 Related Work 59 9.1 CAGIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 9.2 Adaptive Workow System . . . . . . . . . . . . . . . . . . . 59 9.3 Cooperative Open Workow . . . . . . . . . . . . . . . . . . . 59 9.4 Java Border Service Architecture . . . . . . . . . . . . . . . . 60 II Own Contribution 61 10 Scenarios 63 10.1 Maintenance Work on Oil Platforms . . . . . . . . . . . . . . 63 10.1.1 Sensors, Devices and Infrastructure . . . . . . . . . . . 64 10.1.2 Workow . . . . . . . . . . . . . . . . . . . . . . . . . 64 10.2 Electricians Performing Work Indoors . . . . . . . . . . . . . 68 10.2.1 Problem Description . . . . . . . . . . . . . . . . . . . 68 viiCONTENTS 10.2.2 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 68 10.2.3 Smart Work Processes . . . . . . . . . . . . . . . . . . 70 10.3 Shipyard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 10.3.1 Workers and Mobile Robots . . . . . . . . . . . . . . . 70 10.3.2 Collaboration . . . . . . . . . . . . . . . . . . . . . . . 71 10.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 11 Requirement Specication 73 11.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . 73 11.2 Non Functional Requirements . . . . . . . . . . . . . . . . . . 73 11.3 COTS Components and other Technical Constraints . . . . . 75 11.3.1 CORTEX Middleware . . . . . . . . . . . . . . . . . . 75 11.3.2 CLIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 11.3.3 Mobility and Context-Awareness Prototypes . . . . . 76 11.3.4 The Context Toolkit . . . . . . . . . . . . . . . . . . . 76 11.3.5 WfMC Reference Model . . . . . . . . . . . . . . . . . 76 11.3.6 MS Embedded Visual C++ . . . . . . . . . . . . . . . 77 11.3.7 HP iPAQ Handheld Device . . . . . . . . . . . . . . . 77 11.4 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 12 Architecture Proposal 79 12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 12.2 Quality Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . 79 12.3 Architectural Drivers . . . . . . . . . . . . . . . . . . . . . . . 80 12.4 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 12.5 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . 81 12.6 Logical View . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 12.6.1 Context Service . . . . . . . . . . . . . . . . . . . . . . 84 12.6.2 Actuator Service . . . . . . . . . . . . . . . . . . . . . 85 12.6.3 Context Source . . . . . . . . . . . . . . . . . . . . . . 85 viiiCONTENTS 12.6.4 Workow Client . . . . . . . . . . . . . . . . . . . . . 87 12.7 Physical View . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 12.8 Process View . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 12.9 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 12.10Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 III Discussion and Conclusion 97 13 Evaluation 99 13.1 Evaluation of the Architecture . . . . . . . . . . . . . . . . . 99 13.2 Evaluation of Research Method . . . . . . . . . . . . . . . . . 100 14 Further Work 103 15 Conclusion 105 IV Appendix 117 A XPDL Example 119 B SensorML Example 121 ixList of Figures 3.1 A simple example for an order processing workow. . . . . . . 12 3.2 Workow denitions . . . . . . . . . . . . . . . . . . . . . . . 13 3.3 WfMC's Workow reference model . . . . . . . . . . . . . . . 16 3.4 WfMC's Workow reference meta-model . . . . . . . . . . . . 17 3.5 Extended workow reference model . . . . . . . . . . . . . . . 19 4.1 Dimensions of ubiquitous computing [37] . . . . . . . . . . . . 23 5.1 Hierarchical levels of an activity [45] . . . . . . . . . . . . . . 32 6.1 Components of the Context Toolkit [19] . . . . . . . . . . . . 39 6.2 The Sentient Object Model [1] . . . . . . . . . . . . . . . . . 41 7.1 A sensor network divided into a hierarchy . . . . . . . . . . . 46 7.2 The Sonitor system . . . . . . . . . . . . . . . . . . . . . . . . 49 7.3 Location-sensing technologies . . . . . . . . . . . . . . . . . . 50 7.4 Components of an intelligent artifact . . . . . . . . . . . . . . 52 10.1 Use case for a routine inspection of equipment . . . . . . . . . 64 10.2 Template for the work process of inspecting equipment . . . . 65 10.3 Instantiation of template -Inspecting device D2 . . . . . . . . 66 10.4 Instantiation of template -Inspecting device D3 . . . . . . . . 67 11.1 The HP iPAQ PDA . . . . . . . . . . . . . . . . . . . . . . . 77 12.1 Architecture overview . . . . . . . . . . . . . . . . . . . . . . 81 xLIST OF FIGURES 12.2 Architecture actor interaction overview . . . . . . . . . . . . . 84 12.3 Class diagram describing a context service . . . . . . . . . . . 85 12.4 Class diagram describing an actuator service . . . . . . . . . 86 12.5 The context source abstraction hierarchy . . . . . . . . . . . . 87 12.6 Logical view of the workow client. . . . . . . . . . . . . . . . 88 12.7 Deployment of the architecture components . . . . . . . . . . 89 12.8 Workow client enactment of workow process . . . . . . . . 90 12.9 States of the context service . . . . . . . . . . . . . . . . . . . 91 12.10A context client request a context source . . . . . . . . . . . . 92 12.11A workow client sends an actuation order . . . . . . . . . . 93 xiList of Tables 3.1 Relationship between types of workow exceptions and changes to the workow model . . . . . . . . . . . . . . . . . . . . . . 20 7.1 Knowledge stored in an intelligent artifact . . . . . . . . . . . 52 7.2 Rules of an intelligent artifact . . . . . . . . . . . . . . . . . . 53 11.1 Functional requirements for a basic workow system . . . . . 73 11.2 Functional requirements for context information . . . . . . . . 74 11.3 Functional requirements for the workow enactment service . 74 11.4 Functional requirements for client context-awareness . . . . . 75 11.5 Functional requirements for client mobility . . . . . . . . . . . 75 xiiChapter 1 Introduction This chapter presents the background and motivation for our work. It also contains a detailed problem denition and outlines the structure of the repoort 1.1 Background Our project assignment and this report are related to the MOWAHS project [41] at NTNU [46]. MOWAHS is a project carried out jointly by the Software Engineering and Database Technology groups at IDI [29]. It has two main parts; process support for mobile users using mobile devices, and support for transactions/workspaces incorporating work documents. The MOWAHS project states three main goals for their research: Help understanding, and continuously assess and improve workprocessse in virtual organisations. Provide a exible, common work environment to execute and share real workprocesses and their artifacts, applicable on a variety of electronic devices. Distribute the results to the community at large. The approach taken by MOWAHS to achieve these goals is to iteratively dene a exible work environment for virtual organizations. This work enviroonmen should support processes and their transactions. Such a support is in many cases implemented in test beds for process support that realise real scenarios for real applications. 1Introduction This report partly address all three goals by proposing a work environment on mobile devices. This environment can be used to help the understandiin of mobile workprocesses, and thus contribute to the overall goals of MOWAHS. 1.2 Motivation The motivations for developing support for mobile, adaptive work processes in a context-aware workow system are twofold: Increased eciency and safety in workow systems Adaptive, mobile workow systems can provide great benets in industrial applications. By taking the mobile working environment itself into account when performing work, we can better support process enactment in mobile environments, and thus incorporate and integrate more dynamic behaviour into the enactment. This may increase eciency by letting the system automaat the collection of data and execution of services. Safety can be increased by letting workers have an awareness of the environment, and applications which preserve a safe working environment based on sensed data and embeddde knowledge about the environment. Support for mobility in computer systems In recent years, development of new technology has resulted in an increased use of devices such as PDAs and mobile phones. This has led to lower prices and more applications available for the consumer marked. Users of such devices can benet from systems that take contextual information into account, and provide relevant information and services to the user based on the user's guidelines, preferences, activities, etc. 1.3 Problem Denition Our task is to further evolve existing models and prototypes to support process planning and execution by actively using contextual information captured from the physical and electronic environment. Our work is an extension of the work presented in the report by Jon Ole Ndtvedt and Man Hoang Ngyen [47]: Mobility and Context-Awareness in Workow Systems. The activity coordination aspect of a workow enactmeen service is not fully explored in their report. Coordination of activities should be possible for both pre-planned and unplanned situated processes. The elaboration and implementation of this feature as a workow enactment service will be important in our work. This report will provide a prestudy, scenarios, requirements, and an architecctur to support a prototype implementation of a context-aware workow 21.3 Problem Denition system supporting adaptive mobile work processes. We plan to implement this prototype in our master thesis at NTNU. During the initial phase of our project we stated the following research questions for our work: RQ1 How can contextual information from the environment be used in workow enactment services to support dynamic process execution? This is a general question, and we have used an engineering approach (see Chapter 2) to develop a solution to it. We have done a literature survve on relevant topics such as context-aware computer systems (Chapter 4) and workow (Chapter 3). We have also reviewed existing frameworks and elaborated scenarios based on relevant literature and presentations at the MOBIS conference. Based on this, we were able to verify and update the requireement set by Ndtvedt and Ngyen in [47]. Our ndings with regard to this research question are mainly documented in the architecture proposal in Chapter 12. RQ2 What types of context abstractions are needed when we want to reduce possible process paths in workow enactment? To answer this question, we have used the engineering approach by rst revieewin existing frameworks, then developing an architecture using context abstractions we believe are suitable. Our main focus when reviewing existing frameworks was the abstractions proposed by Dey [19]. The documentation of our architecture in Chapter 12 states our ndings related to this research question. RQ3 How is it possible to plan in situ when executing cooperattiv work activities, and how can we deal with competing work processes? Planning includes the building, altering, sharing, executtion and monitoring of plans. Are aspects of situated actions and activity theory relevant in order to coordinate activities for unplanned situated processes? Part of our prestudy involved relating situated actions and activity theory to situated planning in workow systems. Following an engineering approach, our architecture described in Chapter 12 is using these ideas, and in our future implementation of this architecture we will be able to test it. RQ4 What is the state of autonomous wireless sensor technologgy We have performed a literature study on state-of-the-art of sensor technologgy Improvements in sensor technology are necessary to achieve large scale 3Introduction deployment of context-aware systems, and therefore relevant to our work. Our documentation of state-of-the-art in this subject is presented in Chapter 7. 1.4 Outline of the Report This project report is divided into three main parts. A brief description of the content included in each part is given below. Chapter 1 -Introduction: States the background and motivation for our work. Chapter 2 -Research Methods: Describes how we conducted our reseaarch and what sources we used for this research. Part I -Prestudy This report includes a prestudy part to present the state-of-the-art on relevvan theories, enabling technologies, and existing frameworks relevant to our work. Chapter 3 -Workow: Gives an introduction to workow and issues in workow systems. Chapter 4 -Context-Aware Computer Systems: Gives an introduction to context-awareness. Chapter 5 -Activity Theory and Situated Actions: Gives an introductiio to activity theory and situated actions. Chapter 6 -Enabling Technologies: Describes important technologies and components to consider when developing an architecture for a context-aware workow system. Chapter 7 -Sensors and Actuators: Presents state-of-the-art on sensor and actuator technology. Chapter 8 -Social Aspects: Gives an overview of some of the social aspects to consider when dealing with context-aware workow systems. Chapter 9 -Related Work: Presents related work in the eld of mobile work support. Part II -Own Contribution This part comprises our work on relevant scenarios, requirements, and an architecture proposal for a context-aware workow system. 41.4 Outline of the Report Chapter 10 -Scenarios: Presents three relevant scenarios describing applications for context-aware workow systems. Chapter 11 -Requirement Specication: Describes requirements and COTS components relevant to our architecture. Chapter 12 -Architecture Proposal: Presents our architecture propoosa based on previously stated requirements. Part III -Discussion and Conclusion This part summarises our ndings and gives a discussion, an evaluation, and conclusions for our work. Chapter 13 -Evaluation: Gives a discussion and evaluation of ndings during our work. Chapter 14 -Further Work: Describes what aspect of our work that needs to be further addressed. Chapter 15 -Conclusion: Draws conclusions based on the report as a whole. 5Introduction 6Chapter 2 Research Methods According to Zelkowitz [78], there are four general categories of research methods: Scientic method Scientists develop a theory to explain a phenomenon. They propose a hypothesis and test variations of the hypothesis. Data is collected to verify or refute the claim of the hypothesis. Engineering method Engineers develop and test a solution to a hypothessis Based on the results of the test, they improve the solution until it requires no further improvement. Empirical method A statistical method is proposed as a means to validdat a given hypothesis. Unlike the scientic method, there may not be a formal model or theory describing the hypothesis. Data is collected to verify the hypothesis. Analytical method A formal theory is developed, and results derived from this theory are compared with empirical results. Our approach to research is the engineering method. We aim to develop and test a solution to the problem denition stated in Chapter 1.3. Our solution is based on previous work and developed prototypes. With our engineering approach to research, the main activities performed during our project were: Literature survey To answer our proposed research questions we have done a literature survey. This survey gives us an understanding of the relevaan aspects of our problem domain. The Internet provided us with articles, journals and the like from research sites at which NTNU have licence. 7Research Methods Association for Computing Machinery (ACM) [2] Springerlink [62] Cite Seer [60] IEEE Xplore [30] In addition, a large number of publications have been made available through a shared bibliography in the MOWAHS project. We attended the IFIP1 TC8 Working Conference on Mobile Information Systems (MOBIS) [34] in Oslo. The conference spanned three days and provided up-to-date information of topics relevant to our project. Review of existing frameworks During our prestudy, we looked at dierent approaches to the topic of adaptive work processes and contextawarrenes taken in existing frameworks. The existing frameworks are useful as help for identifying partial solutions to some of our research questions. Scenario analyses We created dierent scenarios in order to understand the requirements stated in Chapter 11, based on relevant literature and presentations at the MOBIS conference. Architecture development We developed an architecture in relation to our problem denition, after understanding requirements and which existing frameworks were available. These activities support the engineering approach by letting us improve on existing work and develop an architecture in accordance to our problem description of Chapter 1.3. Implementation and testing of this architecture will be part of our master thesis. 1The International Federation for Information Processing 8Part I Prestudy 910Chapter 3 Workow In this chapter we present a short introduction to workow and workow management systems before we present some proposed additions to workow management systems. \Workow is important. It's a valuable technology. It is also a discipline, practise, and concept. Like knowledge management, all types of vendors claim that their product or service is \work-ow" because it's so important. [4]" Before workow systems became common, work orders were sent to participaant by hand. In the early days of workow systems, work was sent from one participant to another. This made the work more ecient since work was delivered automatically to the participants, and the participants could assume that the work was ready for processing because the system would not forward incomplete work orders. The process of managing those work orders was, however, still manually controlled. Current workow systems are much more advanced, and the work process itself is automated by IT tools wherever possible. Figure 3.1 [22] shows a simple workow for order processing. Each node is an activity performed by a participant and must be performed in sequence as identied by the arrows. Customer Credit Check and Inventory Check must both be nished before Payment Processing is executed. The activities in this workow can be executed manually or automatically by some IT tool. For instance, Inventory Check, can involve a person searching the warehouse by hand, or the inventory can be maintained by an IT tool. We can clearly see that even in this simple workow there is great benets to workow and workow systems. Plesums [51] lists these benets of workow management systems: 11Workow Order placement Validation Customer credit check Inventory check Order fulfillment Payment processing Figure 3.1: A simple example for an order processing workow. Work does not get misplaced or stalled. Participants are rarely requiire to recover from errors or mismanagement of the work. The managers can focus on staand business issues, such as individual performance, optimal procedures, and special cases, rather than the routine assignment of tasks. The army of clerks is no longer required to deliver and track the work. The procedures are formally documented and followed exactly, ensuriin that the work is performed in the way planned by management, meeting all business and regulatory requirements. The person (or machine) is assigned to do each activity, and the most important cases are assigned rst. Users do not waste time choosing which item to work on. Parallel processing, where two or more tasks are performed concurrenntly is far more practical than in a traditional, manual workow. 3.1 Terminology In this section we look at the current workow terminology. Workow is standardised by the Workow Management Coalition (WfMC) [66], a nonpprt, international organisation that promotes the use of workow by estab-123.1 Terminology lishing standards and terminology for connectivity between workow produccts The coalition has over 300 members worldwide, and is the primary standards body for workow. WfMC has the following mission statements: Increase the value of customers' investment with workow technology. Decrease the risk of using workow products. Expand the workow market through increasing awareness for work-ow. Figure 3.2 shows the WfMC denitions [16] and the relationships between them. Figure 3.2: Workow denitions Workow The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. 13Workow Workow management system A system that denes, creates, and manages the execution of workows through the use of software, running on one or more workow engines, which is able to interpret the process denition, interact with workow participants and, where required, invoke the use of IT tools and applications. Business process A set of one or more linked procedures or activities which collectively realise a business objective or policy goal, normally within the context of an organisational structure, dening functional roles and relationnships Process denition The representation of a business process in a form which supports automated manipulation, such as modelling, or enactment by a workow management system. The process denition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc. Activity A description of a piece of work that forms one logical step within a process. An activity may be a manual activity, which does not support computer automation, or a workow (automated) activity. A workow activvit requires human and/or machine resources(s) to support process executiion where human resource is required an activity is allocated to a workow participant. Process instance The representation of a single enactment of a process, or activity within a process, including its associated data. Each instance represents a separate thread of execution of the process or activity, which may be controlled independently and will have its own internal state and externally visible identity, which may be used as a handle, for example, to record or retrieve audit data relating to the individual enactment. 3.2 Types of Workow Systems There exist many types of workow systems that support a wide range of work. Allen [4] classies workow systems into the following four categories. Production This category comprises workow systems that manage a large number of similar and repetitive tasks and try to optimise productivity. This is done by removing the human factor as much as possible by automating the tasks. { Autonomous workow engines An autonomous workow engiin is a system that is self contained. It does not need any external IT tools, although some may rely on critical external 143.3 WfMC's Workow Reference Model software like database management systems. Not relying on exterrna IT tools can make these workow systems very complex and expensive to build and maintain. { Embedded workow An embedded workow management systte is embedded into an environment, and is only functional when it is embedded. ERP (Enterprise Resource Planning) is an example of such a system. Administrative An administrative workow system has a large numbbe of workow processes that involves a large number of employees. In such a system, exibility is more important than productivity, and tasks are often executed manually. Collaborative A collaborative workow focuses on groups working together toward common goals, also called groupware. Ad-Hoc Ad-Hoc workows are created \on the y" by the current participants, and the process denitions are very exible. We will have a more detailed look at ad-hoc workow systems in section 3.4. While support for context-awareness potentially can be useful for production and administrative workows it is not interesting for our work. Our work will focus on single workers or small groups of workers. Collaborative and ad-hoc workows are thus of more interest to us. In the next section we will explore the WfMC's workow reference model. 3.3 WfMC's Workow Reference Model To support interaction between workow products, WfMC has dened the workow reference model shown in Figure 3.3. This model is divided into ve interfaces which we will describe below. Interface 6-8 are still under development and are currently not a part of the ocial workow reference model. These are not relevant to our work. The reference model provides a common vocabulary for describing businees processes, a functional description of the software components needed to support workow, and the denition of interfaces between the software components. It tries to be as technology neutral as possible. 3.3.1 Interface 1: Process Denition This interface integrates the process denitions to the workow enactment service in the form of an interchange Process Denition Language (PDL) and API 1 calls. 1Application Programming Interface 15Workow Administration andMonitoring ToolsProcess DefinitionToolsWorkflow API and interchange formatsOther WorkflowEnactment Service(s)Invoked ApplicationsApplicationDataWork ListHandlingProcess ControlWorkflow Client ApplicationsInterface 1Interface 4Interface 3Interface 2Workflow Enactment Service(s)Workflowengine(s)Workflowengine(s)Interface 5Figure 3.3: WfMC's Workow reference model The process denition provides an environment for a rich description of a process that can be used for the following [65]: Act as a template for the creation and control of instances of that process during process enactment. For simulation and forecasting. As a basis to monitor and analyse enacted processes. For documentation, visualisation, and knowledge management. Meta-model To provide a common method to access and describe workow denitions, a workow process denition meta-model has been established. This metamoode identies common entities within a process denition. A variety of attributes describe the characteristics of this limited set of entities. Based on this model, vendor specic tools can transfer models via a common exchange format we will describe next. Figure 3.4 shows the meta-model promoted by the WfMC. The System and Environmental Data element is of special interees to us. This element contains data which is maintained by the workow management system or the local system environment, that can be accessed in the workow process enactment and used in the evaluation of conditional 163.3 WfMC's Workow Reference Model expressions. In our work we can possibly use this element as an interface to context sources (Chapter 4.1). Workflow ProcessDefinitionActivity SetBlock ActivitySystem andEnvironmentalDataWorkflowRelevant DataWorkflowProcess ActivityWorkflowParticipantSpecifiicationWorkflowApplicationDeclarationTransitionInformationSub-ProcessDefinitionAtomic ActivityResource Repositoryor OrganizationalModelPerformed byfromtoinvoke*111111******11*Figure 3.4: WfMC's Workow reference meta-model Process Denition Language: XPDL To support a variety of dierent tools that analyse, model, describe and docummen business processes, there is a need for a standard interchange format that transfer workow process denitions between the separate products. WfMC has created and promotes a formal specication, the XML [75] Procees Denition Language (XPDL) [65]. XPDL supports all the entities in the workow reference meta-model. See [65] for denitions of all the entities and their corresponding XPDL tags, and Appendix A for an example. 3.3.2 Interface 2 and 3: Workow APIs Interface 2 and interface 3 has been combined, and cover the workow APIs (WAPIs). These APIs allow for external applications to access management engine services. This makes it possible to have a single end-user interface and function set. WAPIs have traditionally been written for the C language, but have in the recent years been written for the Java language. 3.3.3 Interface 4: Workow Interoperability Interface 4 denes the interface that enables workow engines from dierent workow product vendors to make requests to each other to do selection, 17Workow instantiation and enactment of known process denitions. The workow systems are able to send context data and receive status information and the results of the enactment of the process denition in return. WfMC has created a standard for transmitting such requests called Wf-XML. Wf-XML is a XML based protocol for run-time integration of process engines, and is currently in version 2.0. This protocol gives access to the AWSP (Asynchronous Web Services Protocol) [48] running over SOAP [76] that provides access to ASW (Asynchronous Web Services) that can be started, monitored, controlled, and gives notication when it is completed. These AWS can do work that is required by the remote workow system. It is important to note that not all workow systems have the same level of interoperability. We will not elaborate on this, since it is not relevant to our work. The interested reader is referred to Allen's list of eight levels of interoperability [4]. 3.3.4 Interface 5: Administration and Monitoring This interface provides auditing and monitoring to access the workow systte in order to allow analysis of consistent audit data across heterogeneous workow products. The analysed events can be anything of interest to a business. 3.3.5 Interface c: Context Information Integrator Ndtvedt and Nguyen [47], propose a new interface to the workow reference model. They call this interface \Interface 6: Context information integratoor" but this may be confused with Interface 6 currently under development by the WfMC so we have renamed it to \Interface c: Context Information Integrator". Figure 3.5 shows the extended workow reference model. This interface was created to avoid modifying the existing workow interfaces, and thereby be able to use the services already dened in the WAPIs. The goal of this interface is to provide dynamic contextual information to the workow enactment service(s). 3.4 Adaptive Workow and Exception Handling In this section we present exceptions and exception handling in workow systems as well as research on adaptive workow processes. 3.4.1 Exceptions Kammer et al. [33] divide exceptions into two main categories: expected exceptions and unexpected exceptions. Expected exceptions are exceptions 183.4 Adaptive Workow and Exception Handling Administration andMonitoring ToolsProcess DefinitionToolsWorkflow API and interchange formatsOther WorkflowEnactment Service(s)Invoked ApplicationsApplicationDataWork ListHandlingProcess ControlWorkflow Client ApplicationsContext InformationIntegratorInterface cInterface 1Interface 4Interface 3Interface 2Workflow Enactment Service(s)Workflowengine(s)Workflowengine(s)Interface 5Figure 3.5: Extended workow reference model that are modelled into the workow at design time, while unexpected excepttion naturally can be very hard to model at design time. Expected exceptions are not very interesting in our work, since they are already coverre by the WfMC workow reference model. We will therefore only look at unexpected exceptions and possible methods of handling them without manuua intervention. It is also important to note that we only discuss exceptions in the business process execution. Other exceptions like network disconnectioons varying network bandwidth, and hardware or software malfunctions are not covered here. Exceptions occur at dierent levels in the organisation [33]: Employee level Impact is limited to a single individual. Group level Impact stretches across a group working on the same project, process etc. Organisational level Impact is organisation wide, covering more than one group. Unexpected exceptions can be classied into three groups. Minor exceptions that can safely be ignored. Kammer et al. [33] calls this noise. Another type of exceptions are those that are relatively unique to a work process, but still force the work process to change. They call this type of exceptions 19Workow idiosyncratic. The last type of exceptions is evolutionary exceptions that require changes in the organisational workow model. Exception Type Change in Workow Model Noise None Idiosyncratic exceptions Changes to specic instance of work-ow, but the workow type (the generra model) remains the same Evolutionary exceptions Evolution of general workow model, aecting future instances of work procees as well Table 3.1: Relationship between types of workow exceptions and changes to the workow model Since the focus of our report is adaptive mobile work for single workers and small groups of workers we will not discuss exceptions and adaptations on the organisational level, and instead concentrate on idiosyncratic exceptions and noise. See table 3.1 for the relationship between the types of exceptions and what changes they inict on the workow model. 3.4.2 Handling Exceptions If we want to avoid unexpected exceptions stoping our workow execution, we need methods to automatically detect and avoid, ignore, or handle the exceptions. Kammer et al. [33] suggest that the system should tolerate minor deviations, handle changes to the process instance, and support evoluttio and optimisation of the process model. We will only cover the two rst suggestions since the third handles evolutionary exceptions. Tolerating Minor Deviations Minor or insignicant deviations to the workow process, or noise, can safely be ignored and a workow system should be able to safely detect and ignore them. Handling Changes to the Process Instance Exceptions with larger impact on the workow process traditionally involve a stop in the process execution, and manual interaction by one or more work-ow participant before the workow process can be started again. This can be avoided by letting the workow process instance be adaptive or ad-hoc. We will in the next section describe what an adaptive or ad-hoc workow process is. 203.4 Adaptive Workow and Exception Handling 3.4.3 Adaptive Workow Cardoso et al. [12] classify the dierent types of dynamic change into two main categories: primitive change and composite change. Primitive changes are composed of atomic changes that can either be fully executed, or not execuute at all. They further divide primitive changes into immediate changes and incremental changes. Immediate changes can be introduced without changing the correctness and consistency of the workow, while with incremennta changes, the entire change cannot be executed without introducing inconsistency. Composite changes are sequences of primitive changes. Atluri and Chun [5] dene three types of dynamic changes: Prole Change Changes to the goals of the business process. Exceptions Unexpected exceptions that arise during a task execution. Rule Change Changes to business rules and regulations. If we consider exceptions to be a type of change [12], an adaptive workow is a workow able to adapt to exceptions and external changes and input. External changes and input can be prole change, rule change, or other context sources (see chapter 4). An adaptation can result in restructuring the workow, either by inserting, deleting, redoing, or undoing activities. Methods for supporting adaptive workow include: Late binding Defer binding of objects to the workow process instance to the last moment. This results in a separation of an object's data from its behaviour. On-the-y workow composition The denition of the workow is not completed until run-time. This results in a very exible workow. Partial execution Makes it possible for fragments of a workow process to be executed. Reusable process fragments and component libraries Fragments, stubs, or templates for work processes or tasks are stored in a database either on the workow client, distributed, or on a centralised server. Atluri and Chun [5] introduce the notion of self-describing workows and workow management system stubs. \Self-describing workows are partitions of a workow that carry sucient information to be managed by a local task execution 21Workow agent, rather than a central workow management system. A workow management system stub is a light-weight component that can be attached to a task execution agent, which is responsiibl for receiving the self-describing workow, modifying it and re-sending it to the next task execution agent." Workow templates are pre-planned workow processes that are general enough to encompass several similar work processes. They can be instantiatte by adding contextual data, other templates, or workow fragments. A fragment is equal to a workow stub. 3.5 Workow Modelling We will use UML state chart diagrams, and UML activity diagrams to model our workows as suggested by Ndtvedt and Nguyen [47]. These modelling languages are also supported by the WfMC. 3.6 Summary Workow is a mature technology that is well dened with a large install base, and is supported by key industry actors. On the other hand there is a lot of development going on in the eld of adaptive, ad-hoc, and mobile workow systems. For our own work, the WfMC's reference model will be very useful, especially the Interface 1 meta-model and XPDL. Adaptive workow theory will also have an impact on our work. 22Chapter 4 Context-Aware Computer Systems Weiser [73] presents a vision of a world where computers are integrated seamlessly into the world. These computers are aware of their surroundings and can adapt their behaviour accordingly. Such ubiquitous computing is not feasible today, but improvements in technology related to embedded devices give rise to a more pervasive environment, supporting the developmeen of context-aware applications. Lyytinen [37] presents an overview of the dimensions of ubiquitous computing in Figure 4.1. Figure 4.1: Dimensions of ubiquitous computing [37] This gure presents the dimensions on making the computer invisible. Lyytinne proposes the main challenge in relation to ubiquitous computing to be the integration of large scale mobility with the pervasive computing functionaality 23Context-Aware Computer Systems Today, computers make very limited use of input when executing, and applicaation typically rely on explicit input alone. The goal of context-aware computing is to make applications context-aware in the sense that they use both implicit and explicit input when executing. Context-aware applications will then be able to oer a wide range of new services to its users. This chaptte will refer to denitions of important terms related to context-awareness. It will also provide the reader with insights in some of the challenges and benets concerning the development of context-aware applications. 4.1 Context and Context-Classications Before we refer to denitions of the term context-aware, we will briey exammin denitions of context and types of context relevant to the application designer. A good understanding of context will help application designers to bettte utilise the possibilities of oering useful services and context-aware behavviou in applications. By improving the computers ability to access conteext we can improve the human-computer interaction through new contextawwar features in applications. Relevant literature provides us with several denitions of context. Some authors provide examples to dene context, while others use synonyms like the environment or situation of an entity. Dey and Abowd [20] believe these denitions are too specic, and that conteex is about the whole situation relevant to the applications and its set of users. They propose the following denition of context: \Context is any information that can be used to characterise the situation of an entity. An entity is a person, place, or object that is considered relevant to the interaction between a user and an application, including the user and applications themselves." This denition allows context to consist of both implicit and explicit informattion If applications heavily rely on explicit information, they require users to specify the relevant information for a given situation. With the availability of implicitly sensed contextual information, application developeer can automate the collection and interpretation of relevant information. The denition provided by Dey et al. is related to the development of the Context Toolkit [19], a framework consisting of toolkit components that can be combined to determine the contextual state of an application (see chapter 6.1 for an introduction to the Context Toolkit). Greenberg [25] argues that context is a dynamic construct, which means that in most cases it is dicult for designers of context-aware applications to list the set of contextual states that may exist, what information that can accurately determine a contextual 244.1 Context and Context-Classications state, and what appropriate action should be taken from a particular state. He acknowledges the usefulness of Deys denitions and supporting framewoork but emphasise on how this is an elegant solution which only works to design context-aware applications for simple and highly routine contextual situations. Our approach to context-awareness is with the coordination of activities in an adaptive mobile workow system. For our purpose, we need to extend the denition of context as provided by Dey. Instead of focusing on the user and the interaction between a user and an application, our focus is on processes executing in an application environment. These processes involve activities, possibly competing for resources. In this setting, activities in the context-aware application's environment is the context. This approach to context is part of the activity theory presented by Nardi in [43]. Nardi states the following about context in an activity system: \Activity theory proposes a very specic notion of context: the activity itself is the context. What takes place in an activity systte composed of object, actions, and operation, is the context. Context is constituted through the enactment of an activity invollvin people and artifacts." Chapter 5 gives an introduction to activity theory and situated actions. The sentient object model [24] is presented in chapter 6.2. This model presents a method to provide coordination of actions through the environmeen based on clients sensing their physical environment, and reacting to the sensed information according to a set of rules. As part of this model, denitions of context and context-awareness are provided. A denition of context for the purpose of the sentient object model is [24]: \Any information sensed from the environment which may be used to describe the situation of a sentient object. This includes information about the underlying infrastructure available to the sentient object." This denition focuses on coordination of sentient objects, operating without the need for an infrastructure. Dey [20] denes the primary context types for characterising the situation of an entity as: location, identity, activity, and time. These primary context types can be used to acquire other relevant (secondary) information about the entity. A simple example is when the identity of a persons is known, it is easy to acquire the e-mail or phone number of that person. Primary contexxtua information about an entity therefore acts as indices for the retrieval of secondary contextual information about the same entity. 25Context-Aware Computer Systems 4.2 Context-Sensing and Infrastructure The focus of context-sensing research has in the last decade been on locationsenssing and applications are being made possible with the deployment of location-sensing technologies. Hazas [26] states that the widespread deploymeen of sensing technologies will make location-aware applications part of everyday life in the near future. Researchers have developed several locationsennsin systems (Chapter 7.3.2). Development of a context-aware workow system needs sensor and contextsennsin technology beyond technology commonly available today. Such systeem need to be able to sense other context types as well as location. Chapter 7 gives a more technical presentation of the state of actuator and wireless sensor technology. Dix et al. [21] describes how a device in mobile computing operates in a broad context which includes the network and computational infrastructure, the broader computational system, the application domain, and the physicca environment. In reference to this, design of mobile interactive systems introduces several tradeos which must be adressed to achieve acceptable performance. When realising mobile systems using context-sensitive devices, the interaction oered by mobile applications is a product of the device and the supporting infrastructure. This infrastructure may introduce a high degree of variability that may alter interaction dramatically. This variabilitty and the use of wireless communication, force the designers of mobile applications to cope with a high level of uncertainty. 4.3 Context-Aware Computing In relevant literature, context-awareness has become synonymous with the terms: adaptive, reactive, responsive, situated, and context-sensitive. Previiou denitions of context-aware computing can be categorised as focusing on using, or adapting to context [20]. When systems are limited to using context, the relevant services provided are sensing, interpreting, and reacting to contextual changes in the environment. Adaptive context-aware systems dynamically change and adapt their behaviour based on the context of the user and application. Dey and Abowd [20] propose the following denition of context-awareness: \A system is context-aware if it uses context to provide relevant information and/or services to the user, where relevancy depends on the users task." This is a general denition of context-awareness. It includes both systems that are using, and systems that are adapting to context as context-aware. 264.4 Challenges in Context-Aware Computing In the sentient object model, context-aware is dened as [24]: \The use of context to provide information to a sentient object, which may be used in its interactions with other sentient objects, and/or the fullment of its goals." This denition is focusing on achieving coordination through the environmeen rather than provide information and services to the user. When it comes to categorising features for context-aware applications, Dey and Abowd [20] proposes an categorisation that combines ideas from previoou taxonomies. The result is the following three categories of features that context-aware applications may support: Presentation of information and services to a user. Automatic execution of a service. Tagging of context to information for later retrieval. When working with aspects of activity coordination and adaptive workow systems, we need to emphasise on how these application features can proviid benets not only to a user, but also to other (workow) services. We therefore tailor these features for our process centred approach to context, and include other services as well as users, as the target of these features. 4.4 Challenges in Context-Aware Computing Patterson [50] identies several important challenges in the eld of locationawwar computing. First of all, mobile devices have limited resources. Compaare to static devices, mobile devices are small and suer from limited power due to its size and weight. Data is transmitted through open airspace, making communication vulnerable to security violations. There has been an extensive growth in the deployment of wireless technologies. Wireless LAN, Bluetooth, and infrared communication are popular and in widespread use. This wireless connectivity is highly variable in performance and reliability. Satyanarayanan [56] discusses some of the challenges in the emerging eld of pervasive computing. For a computing system to be pervasive, it also has to be context-aware, and Satyanarayanan list the following challenges in the eld of context-aware computing [57]: 1. How is context represented internally? 27Context-Aware Computer Systems 2. How is this information combined with the system and application state? 3. Where is context stored? 4. Does it reside locally, in the network, or both? 5. How frequently does context information need to be consulted? 6. What is the overhead of taking context into account? 7. What techniques can one use to keep this overhead low? 8. What are the minimal services an environment has to provide to make context-awareness feasible? 9. Is historical context useful? 10. What are the relative merits of dierent location-sensing technologies? 11. Under what circumstances should one be used in preference to anothher 12. Should location information be treated just like any other context information, or should it be handled dierently? These challenges are important topics for researchers interested in contextawwar computing. For our work, challenges to be especially aware of are how context is stored (3 and 4), how frequently it has to be consulted (5), and what the overhead for taking context into account (6) is. These challenges relate to aspects of communication. An increase in context sources and workow clients within a system constitute a severe challenge with regards to keeping the generation of messages at an acceptable level. 4.5 Advantages of Context-Aware Computing Context-aware computing is about making our lives easier. There is a great potential for advantages by using context-aware features in real-life applicatioons For this to happen, research in this eld must be able to make systems automate the collection of contextual information, and use this data to take the appropriate actions in the actual situations. Potential for improved usability When applications have available informmatio about a user's context, it is possible to make several improvemeent in usability. The identity of a user can be detected automatically when needed, and available nearby resources can be presented to the user according to user-dened policies. 284.6 Summary Automation of services Context-aware computing can automate the execution of services for users and simplify common everyday activities. Increased safety There are several industry scenarios that can benet from increased safety by using applications that incorporate contextual informaation E.g. by monitoring pressure, temperature, and other contextual parameters, applications can take actions to prevent accidents from happeninng Increased eciency Context-aware applications have a potential of increaasin eciency when implemented as workow systems in dierent settinngs Context-awareness is important to researchers with interests in the visions of Mark Weiser [73]. His article on ubiquitous computing, the computer for the 21st century, gives an insight into a future environment of computers that are invisible to common awareness, with applications that use contextual information to ease the everyday tasks of common people. 4.6 Summary A good understanding of context, context-awareness and the challenges relaate to these terms are important if we want to build systems with support for adaptive workow. The use of implicitly sensed information allows the application's behaviour to be customised to the user's current situation. Denitions of context and context-awareness by Dey and Abowd help us understand what types of context, and what kind of context-aware features to incorporate in applications. Although denitions provided by Dey and Abowd are helpful, they are not satisfactory with regards to the requirements we state for adaptive workow systems in Chapter 11. We focus on processes and activities as important contextual information for use in workow enactment, rather than viewing the user and the interaction between users and applications as the main focuus We therefore emphasise on how application features should be available to other (workow) services as well as to the users of the application. 29Context-Aware Computer Systems 30Chapter 5 Activity Theory and Situated Actions In this chapter, we investigate how activity theory and situated actions can be used to achieve situated planning within workow systems, achieving a more dynamic workow. Our focus is on the technical, rather than social aspects of activity theory and situated actions. 5.1 Situated Actions Research in the area of cognitive science and articial intelligence has creatte a large number of models for human behaviour. These models heavily rely on planning, and how humans use conscious plans to achieve the objectiiv of an activity. Situated action models [44] are developed in contrast to such planning models of human actions. While models in cognitive science represent activities that are carefully planned, situated action models depeen on the surroundings, and recognise the environment as an important shaper of activities. Situated action models are an attempt to develop a theory applicable to real-life human activities. Situated action models emphasises the way activities grow out of the particularritie of a given situation, and therefore recognise that actions are always situated into a context, and impossible to understand without that conteext With situated actions, the unit of analysis is the relation between the individual and the environment. 5.2 Activity Theory Activity theory is a formal theory of human work activities and a philosophicca framework for studying human work practices. 31Activity Theory and Situated Actions 5.2.1 The Basic Principles of Activity Theory The basic concept and unit of analysis in activity theory is the human activvity which has three main characteristics [6]. Activities are directed towards a material or an ideal object An activity is directed towards an object that motivates the activity. This object distinguishes one activity from another. Activities are mediated by dierent artifacts Activity theory emphasiis that human activities are mediated by tools as well as other artifacts. Activities are social within a culture Human activities depend on the culture they are a part of. Activities are composed of subject, object, actions and operations [45]. The structure of activities can be represented as a hierarchy with three levels; activities, actions and operations. Figure 5.1 shows the hierarchical levels of an activity [45]. ActivityActionOperationMotiveGoalConditionsFigure 5.1: Hierarchical levels of an activity [45] Activities are realised through goal-directed actions. Actions that are particippatin in activities have an immediate dened goal, and cannot be undersstoo without reference to the corresponding activity. One activity may be realised through dierent actions depending on the situation. Actions are implemented through automatic operations. Operations do not have goals, but are used to adjust actions to the current situation. They are dependent on the conditions of the corresponding actions using them. In the study of context and activity theory, Nardi [45] explains how activities themselves become context as stated in Chapter 4.1. \Activity theory, then, proposes a very specic notion of conteext the activity itself is the context. What takes place in an activity system composed of object, actions, and operation, is the context." 325.3 Situated Planning 5.2.2 Principles Derived from Activity Theory Adams et al. [3] have derived ten principles from activity theory that help the understanding of work practices. These principles represent the authors' interpretation of the central themes of activity theory. Activities are hierarchical This principle states that activities consist of one or more actions, and actions consist of one or more operations. Activities are communal Activities are almost always communal. This means that activities often involve several participants working towards a common objective. Activities are contextual The context of an activity deeply aects the way an objective is achieved. Activities are dynamic Activities evolve asynchronously, and historical analyses are often needed to understand the current context. Mediation of activity An activity is mediated by tools, rules, and divisiio of labour. Actions are chosen contextually Actions and operations are created, maintained and made available to any activity. Activities are then able to make contextual choices from the available actions and operations. Actions are understood contextually An action's goal may be diereen from the objective of the activity in which the action is a component. An action may have a successful execution in reference to the overall objective of the activity. Plans guide work Plans act as guidance of work-processes and are mod-ed in accordance to contextual information. Exceptions have value Deviations from a plan can give rise to a learning experience which can incorporate additional exceptions into future executioons Granularity based on perspective A piece of work may be an activity or an action depending on the perspective of the viewer. 5.3 Situated Planning Bardram [6] gives the following denition of a plan based on activity theory: 33Activity Theory and Situated Actions \A cognitive or material artifact which supports the anticipatory reection of future goals for actions, based on experience about recurrent structures in life." Traditional workow systems have diculties supporting unexpected changes and deviations from the original process model. These diculties can be understood within the planning paradox; work is by nature ad-hoc and situatted but most organisations need predened plans in order to organise their work. Bardram [6] approaches this paradox by viewing plans in relation to situated actions and activity theory. Both activity theory and situated actiion emphasises the connection between plans and the contextual condition for realising these plans in actual work. An important distinction is the dierence between a plan and the instantiattio of a plan. Plans are resources, and independent of concrete, situated activities. An instantiation of a plan applies the plan to a concrete problle where situated actions are adjusted to their contextual state. Since an instantiation depends on its contextual conditions, some actions will mirror the plan while others will be not. After the completion of an instantiated plan, a comparison of the plan and its actual instantiation may reveal deviatiion that can give rise to learning. Bardram [6] describes how situated actions are not to be viewed as the opposite of planning. Plans are made out of situated actions and realised in situ. Situated planning involves planning while executing and the ability to modify a plan based on occurring events. Situated planning can therefore be characterised as the building, altering, sharing, executing, and monitoring of plans within cooperative work activities [6]. An understanding of this approach to planning as a combination of prede-ned templates using situated actions is useful when developing contextawwar workow systems. 5.4 Summary When working with adaptive mobile work processes, plans are important, but not sucient. Plans need to be instantiated based on information of the current situation. Both situated actions and activity theory may address issues in situated planning. Bardram [6] recognises this, and his conceptualissatio of planning in situ makes it possible to address planning in a way that does not require a rigid match between process models and actual work. Situated planning may provide great benets in relation to supporting contextawwar work. Srensen et al. [13] introduce the notion of smart work processses which automatically adapt themselves based on reasoning on the 345.4 Summary contextual state of the environment. They recognise how situated actions and planning are a natural part of a support environment for smart work processes. By using the contextual state of the environment, activities can be created in situ, ether by the workow client, or by the environment itself with an intelligent artifacts approach [63]. The potential benets of situated planning are often related to increased safety and eciency in the working environment. Using activity theory is a more formal approach to planning than situated actions. The hierarchical levels of an activity may be a good way of represenntin work. Adams et al. [3] states how these activities are contextual, and their actions and operations are chosen contextually. 35Activity Theory and Situated Actions 36Chapter 6 Enabling Technologies In this chapter, we will present some important enabling technologies for realiisin context-aware applications. Section 6.1 covers the Context Toolkit, a framework for developing context-aware applications. Section 6.2 presents the CORTEX research project, which aims to investigate appropriate architeecture and paradigms for the construction of applications composed of collections of sentient objects. Finally Section 6.3 deals with mobile wireless networks. 6.1 The Context Toolkit Dey has in his thesis developed a conceptual framework for building contextawwar applications [19]. The framework is realised in an implementation entitled the Context Toolkit, and several applications have been developed using this toolkit. 6.1.1 Architectural Framework Features Dey identies seven required features when developing a supporting framewoor for context-aware applications. These basic framework features are [19]: Context specication Application builders should be able to specify what context an application requires. This runtime mechanism will ensuur that when applications receive requested context it will be useful and ideally not require further interpretation. Separation of concerns and context handling A separation of how context is acquired from how it is used facilitates the separation of applicatiio semantics from low-level input handling details. 37Enabling Technologies Context interpretation This mechanism allows applications to request the context they want, regardless of whether interpretation is needed or not, and for the application to receive the requested context. Transparent distributed communications Contextual information will come from multiple distributed machines connected via a computer network. The distributed communication should be transparent to both sensors and applications. Constant availability of context acquisition Components that acquuir context must be executed independently from the applications that use them. Since these components run independently of applications, they need to be available at all times. Context storage The Context Toolkit framework must support context history. Context history can help to establish trends and predict future values. Resource discovery When an application is started, the resource discoveer mechanism is responsible for nding relevant components, and provides the application with methods to access them. By addressing these features in a framework, Dey believe application developper are able to do faster and easier development of context-aware applicatiions 6.1.2 Architectural Building Blocks In this section, we describe the architectural building blocks as proposed by Dey [19]. Figure 6.1 gives an overview of the interaction between applicatiion and the architectural components of the Context Toolkit. A Context Widget is a software component that provides applications access to contextual information from their environment. Context Widgets separaat how context is acquired from how it is used. Collection of information from the environment is based on software or hardware based sensors. The Context Widget abstraction provides several benets [19]: Separation of concerns by hiding complexity of the actual sensors used from the application. Abstract context information to suit the expected needs of applicatioons Provide easy access to context-data through querying and notication mechanisms available through a common, uniform interface. 386.1 The Context Toolkit Figure 6.1: Components of the Context Toolkit [19] Provide reusable and customisable building blocks for context-sensing. Context Widgets are designed to comprise a state and a set of callbacks. The state consists of one or more attributes. Applications can register to be notied when a context change occurs. Context Interpreters get contextual information from widgets and interpret this information in a way that makes it useful to applications. Raw low-level contextual information is abstracted into higher level forms of information. The Context Aggregator is a software abstraction that supports the aggregatiio of context for entities in the environment. To prevent such an applicatiio from having to communicate with many Widgets, Context Aggregators support delivery of specied context to an application by collecting relevant context about an entity that the application is interested in. 6.1.3 Implementation The implementation of the context toolkit has a set of base components which includes the BaseObject, context widgets, context aggregators, conteex interpreters, context services, and resource discovery objects. When these components are instantiated, they register themselves with a Discoverrer Applications contact the Discoverer at startup, and the Discoverer may then locate components that are relevant to the applications functionality. A Widget object handles all the features that are common across widgets and maintains a list of subscribers to each callback in the widget. The most common case is for a widget to act as a server and deliver requested information to clients. A subscriber to a widget has to specify a condition to indicate when callbacks are red. For example, a callback may be red 39Enabling Technologies when the value of a context-type change, or when the value is in a particular range. The Discoverer is used by applications and other context-components to locate interesting components, and the Context Toolkit allows multiple Discoveerers A component may register with several Discoverers, and Discoverer can register with higher level Discoverers, forming a hierarchy. An Interpreter is necessary when Widgets cannot provide context at the level required by applications. Interpreter objects allow other components to inspect context types that an interpreter instance can interpret, inspect contest types that an interpreter instance can output, and request interpretattion Similar in functionality to Widgets, Aggregator allow the context they acquuir to be subscribed to and queried, and they store context. A Widget represents context from a particular sensor, while Aggregators represent context from an entity. 6.1.4 Framework Drawbacks When developing context-aware applications using the Context Toolkit, we need to dene how to automate execution of services based on sensed data. Even though we base these decisions on user guidelines, it is still hard to program the system to take correct and relevant actions on behalf of users. Human aspects of context are not easy to represent in a deterministic way, as Bellotti states in [8]. Bellotti believes a component-based approach to building context-aware systeem does not equip the designer with the tools to provide visibility and control of contextual information, which makes these systems prone to misinterprretation 6.2 CORTEX CO-operating Real-time senTient objects: architecture and EXperimental evaluation (CORTEX) [67] is a research project and states its general objecctiv as: \The CORTEX project will investigate appropriate architectures and paradigms for the construction of applications composed of collections of what may be called sentient objects -mobile intelligent software components that accept input from a variety of dierent sensors allowing them to sense the environment in which they operate before deciding how to react." 406.2 CORTEX 6.2.1 The Sentient Object Model The development of pervasive computing environments is driven by the availability of sensor technology that provide accurate and cheap sensing. Environments that provide ubiquitous sensors and wireless communication make it possible to develop a class of applications that are decentralised and \proactive". These applications consist of several mobile software componnent acting with a high degree of autonomy upon the environment via actuators based on input from sensors. The components have \intelligence" and cooperate via dierent network technologies. It is these components Fitzpatrick [24] terms sentient objects. Sentient objects interact using an event-based inter process communication that supports loose coupling betwwee sentient objects. Figure 6.2 illustrates the sentient object model and its three main components. Figure 6.2: The Sentient Object Model [1] The sentient object model provides the application developer with abstractiion for sensors and actuators, and makes it unnecessary to do low level interaction with various hardware devices. In the sentient object model, a sensor is dened to be [24]: \An entity that produce software events in reaction to a stimulus detected by some real-world hardware device." An actuator in the sentient object model is dened as [24]: \An entity which consumes software events, and reacts by attempptin to change the state of the real world in some way via some hardware device." 41Enabling Technologies A sentient object is dened as [24]: \An entity that can both consume and produce software events, an lies in some control path between at least one sensor and one actuator." Several characteristics of sentient objects are important when dealing with ubiquitous computing environments [10]: Sentience Perceive the state of the environment. Autonomy Operate independently in a decentralised manner. Proactiveness Act in anticipation of future goals or problems. Since the sentient object model relies on event-based communication, it is not dependent on centralised control. Fitzpatrick [24] identies three components necessary to achieve contextawarrenes in a sentient object; sensory capture, context representation, and an inference engine. The sensory capture component of the sentient object model receives input from sensors which needs to be integrated in order to determine the context of the sentient object. Major issues to address in this area are data ltering and sensor fusion. Context representation deals with the representation of contextual informatiio in a way that is useful to the sentient object and can easily be exchanged amongst sentient objects. Raw sensor data often needs to be transformed before it may be considered useful information. Sentient objects are context-aware in the sense that they interact with their environment with the help of sensors and actuators. An inference engine performs reasoning, and is the \intelligent" part of an sentient object. It is realised as an expert system with a knowledge base and a set of rules for deriving output. 6.2.2 CORTEX Middleware Middleware can conceal programming complexity from application developerrs CORTEX [77] has designed and implemented a exible middleware for building dependable sentient computing applications. This middleware addreesse several important research challenges related to context-awareness, use of communication models, QoS management, and routing in mobile adhho networks. 426.3 Mobile Wireless Networks To support a high level of conguration and reconguration, they have chosse to base their middleware on OpenCOM [15]. OpenCOM is a lightweight and ecient component model based on COM. Component Frameworks A Component Framework (CF) is targeted at a specic domain, and have rules and interfaces that make sense in that domain. The Publish-Subscribe CF does not rely on any separate infrastructure. It supports a decentralised approach for discovering peers, for routing event notications, and for event ltering. Events are represented as XML-based data, which provides interoperability and extendibility of the event dialect. This is important since all subscribers should be able to interpret events without a priori knowledge. The Context CF is an implementation representing a sentient object and consists of two parts; sensor capture and fusion, and the inference engine. Sensor capture and fusion deals with sensor data and perform data fusion in order to manage uncertainty. The inference engine and its associated knowledge base is the \intelligence" of a sentient object. The inference engine used in the Context CF is based on CLIPS 1 [54]. CLIPS supports rule-based, object oriented, and procedural programming paradigms. The Context CF uses the rule-based paradigm, with rules that have an if and a then part. A proof of concept demonstrator based on the notion of autonomous cooperattin vehicles has been developed [1]. This demonstrator is using instances of the middleware CFs. Since CORTEX middleware is based on the sentient object model, characteriistic of applications which uses this middleware are sentience, autonomy, and proactiveness [10], but also decentralisation and adaptivity [1]. These applications do not rely on any single central server, and have to cope with changing conditions during their lifetime. They will also have to interact with a physical environment while providing real-time services. 6.3 Mobile Wireless Networks Mobile wireless networks consist of many heterogeneous networks or access points. They are typically deployed in situations where the installation of physical media is not feasible [38]. A mobile user may utilise wireless technoloog like Bluetooth [11], Infrared, satellite, WLAN [64], and others. Mobile wireless networks must support nomadic users, anytime and anywhere [71], and setup connections in an ad-hoc manner. This does not limit the user to 1C Language Integrated Production System 43Enabling Technologies use wireless communication all the time. Considering the relative low bandwiddth vulnerability to noise and interferences of all wireless connections, a xed line may provide higher bandwidth at a lower cost. Sensor networks are a special type of mobile wireless networks and are coverre in Chapter 7.2. We will not go into the technical details of mobile wireless networks since it is not relevant to our work, but we provide Bharghavan's [9] list of functionality mobile wireless networks must support. Seamless mobility across dierent wireless networks. Graceful adaptation to dynamic QoS variations. A uniform framework for the execution of applications across diverse underlying environments. Backbone support for mobile applications. Seamless recovery in the presence of failures. 6.4 Summary These enabling technologies can be implemented as partial solutions for our proposed architecture in Chapter 12. We believe that a combination of the the CORTEX middleware and abstractions dened in the Context Toolkit may be used together to develop an architecture that supports adaptive mobile work processes. 44Chapter 7 Sensors and Actuators Sensors are increasingly becoming smaller, more powerful, and smarter. This makes some of Weiser's visions [73] possible, and we will start this chapter with an introduction of smart dust, before we present wireless sensor netwoork and the sensors themselves. Actuators and intelligent artifacts will also be covered. 7.1 Sensors Like Dust and Brilliant Rocks Satyanarayanan [58] introduces the idea of sensors like dust, or smart dust. The idea involves smart sensors that can be produced in such volumes that they essentially do not have an individual cost. These sensors contain the actuua sensing hardware, wireless connectivity, a small memory, a small CPU, and a small battery. When the sensors are deployed in their target environmeen they self-congure and react to the environment. E.g. if sensors are put into concrete when it is mixed they can send data of the moisture level and temperature in the concrete. When the battery is depleted, the sensors are discarded since they have served their purpose. This makes the sensors immersive, since they are embedded into the environment. There is also a need for non-immersive sensors, like security cameras with image recognition. These sensors will be more expensive and hence not as easily deployed in large numbers. Satyanarayanan calls this type of sensoor Brilliant Rocks since they have greater processing power and self-and environmental awareness. 7.2 Wireless Sensor Networks Wireless sensor networks are self-organising, self-regulating, and self-repairing networks of wireless sensors nodes [18]. They combine processing, sensing, 45Sensors and Actuators and peer-to-peer communications into tiny embedded devices [27]. The bassi mode of operation of wireless sensor networks is dierent from traditional computer networks, due to their tight integration with the environment [55]. They are often deployed in large numbers and have to operate unattended for long periods of time. This makes it necessary to sacrice some higher level functionality to make the sensor nodes as small and energy ecient as possible. To achieve higher level functionality, a hierarchy of sensor nodes is needed. The simple nodes connect to higher level nodes functioning as gateways. These gateway nodes provide access to larger networks and can also access even higher level nodes in the hierarchy as shown in Figure 7.1 [27]. Figure 7.1: A sensor network divided into a hierarchy In reference to Satyanarayanan, the lowest level of sensor nodes shown in Figure 7.1 is smart dust, while the three topmost levels are brilliant rocks. There are several challenges when deploying wireless sensor networks. Algoritthm for routing in a hierarchical peer-to-peer network are very complex. Power must be used sparingly when the sensor node is running with battery as a power source. The network must be extremely scalable and have a long-term performance that does not degrade over time. Additionally, sensso nodes may be exposed to harsh weather, theft, and malicious attacks. There exists several approaches to wireless sensor networks security [28], but since they are not important to our work we will not elaborate on them in this report. 467.3 Wireless Sensor Nodes 7.3 Wireless Sensor Nodes The capabilities of wireless sensor nodes vary depending on their application as mentioned above. Some sensors are the low level smart dust type. They typically do not contain much \intelligence" compared to the larger brilliant rocks. There may also be aggregator sensors that only combine sensor data from other sensors. Common for all smart sensors is that they contain a central processing unit, a wireless network interface, an operating system, and the actual sensor. The sensor does not need to be a traditional sensor like a temperature sensor, but can also be an abstraction of all the temperature sensors in a room. Since the sensors usually are embedded into the environment, they can often draw power from the environment itself. If this is not possible it must also contain some sort of power source. In our work we will simulate the nodes by using powerful equipment like PDAs and PCs. We will therefore not go into detail on the capabilities of sensor nodes available today. The interested reader is referred to Hill et al. [27]. 7.3.1 Non Context-Aware Sensors This is traditional dumb sensors that only provide sensor data without any knowledge of what it is and what it is used for. This can for instance be a simple temperature sensor that periodically broadcasts its current temperatuure 7.3.2 Context-Aware Sensors If we follow the denition of context-awareness in Chapter 4.1 given by Dey, the sensor must use context to provide relevant information and /or services to the users of that sensor. Context can in the case of the temperature sensor, be the knowledge that a user only want the temperature reading if it is higher than a predened threshold. To provide this service, the sensor must, in addition to the previously mentioned hardware, also contain some sort of persistent storage that can hold the requirements from the user. This storage is also important when the user is interested in the history of the sensors readings. E.g the user want to know the average temperature over the last hour. Location-Aware Sensors In a mobile environment, location often becomes an important context type for sensors and other context-aware equipment. We will therefore describe 47Sensors and Actuators some common methods for acquiring location. A geographical or locationawwar sensor can be dened as a sensor that knows the position of itself in a local or global geographical or topological system. That system may be a room, building or something larger like a city or the entire earth depending on the scope of the sensor. This means that the sensor must be able to accurately sense its position. There exist many techniques to achieve this depending on if the sensor is used outdoors or indoors. Not all sensors require detailed positioning depending on the activity to be performed. For instance, it may not be interesting to know that the sensor is on a specic wall as long as it is in the room. On the other hand, an activity that is dependent on correct temperature readings may need to know if the sensor is near a window since that may aect the temperature readings on cold days. Outdoor Positioning There are several methods available for achieving outdoor positioning, and all of them use radio waves. GPS GPS use a network of satellites to infer the current position of the receiver. It is fairly accurate with accuracy typically in the range of a few meters. While GPS works everywhere on the globe, the quality of the positiionin degrades in urban areas, inside buildings, and elsewhere the radio waves from the satellites do not reach. Receivers also have a long start-up time. Ultrawideband radio and TV Radio and TV can be used to detect location by triangulating known transmitters. This can for instance be used in large urban areas. Mobile phones Triangulation of mobile base stations can be used to track the location of a mobile phone. Indoor Positioning Indoor positioning today either use light, sound, radio waves, or a combinatiio of those methods to position the sensor. RFID RFID is a small chip that does not require any power source and can be attached to any item. It is by nature passive and has a very low range of just a few centimetres. Positioning can be done by registering the RFID chip as it passes objects. E.g. if a sensor in a doorway to a room registers the chip, it is likely that the chip has moved into the room. Positioning can also be achieved by registering chips with a specied known position, and looking up that position in a data store. E.g. passing a scanner close to a door with a RFID chip will give you the position of that door. 487.3 Wireless Sensor Nodes Ultrasonic Sonitor [61] is a manufacturer of wireless indoor positioning systems that is based on ultrasound. They can deliver two types of position tracking, either in full 3D space or room to room tracking. The system consists of: Tags that contain a motion sensor, an ultrasound sender that sends an unique id and a battery. Microphones connected to the buildings ethernet. A room may have one or more microphones depending on the desired accuracy of the positioning. With eight microphones, the system can track a tag in all three dimensions with an accuracy of about 2cm. A central server that process the tracking information. Figure 7.2 shows the components of the Sonitor position system. Figure 7.2: The Sonitor system The position of the tag is updated when either the tag is moved or by a predened interval. The tag will then send an ultrasound with a unique id that the connected microphones will detect. These microphones send the signal to a central server which process the data and determine the position of the tag. This position information can then be pushed to a receiver. Vision Use image recognition to track objects. Requires heavy processing, is prone to misinterpretation, and requires line of sight. On the other hand, it is appealing since it does not require any tags on the tracked object. Infrared Use infrared senders and receivers to track the receivers position compared to that of the senders. 49Sensors and Actuators Wi-Fi Use standard wireless LAN for positioning by sensing the signal strength and visibility of base stations. Accuracy vary from just a few meters to 100 meters depending on the signal quality and number of installations. The Cordi Radioeye [17] is an example of such a positioning system. It is able to position terminals with an accuracy of one to two meters, by using a receiver box. Bluetooth A Bluetooth device is a small, low power, radio transmitter typically found in mobile phones, and can detect position with an accuracy of a few meters. Figure 7.3 shows the accuracy and the level of deployment of each of the locations sensing technologies described above. Each box's horizontal span shows the range of accuracies the technology covers; the bottom boundary represents current deployment, while the top boundary predicted deploymeen over the next several years as predicted in 2004. [26] Figure 7.3: Location-sensing technologies 7.4 SensorML SensorML is a XML schema for dening the geometric, dynamic, and observatiiona characteristics of a sensor and is developed by the Open Geospatial Consortium [69]. The purpose of SensorML is to: 507.5 Actuators 1. Provide general sensor information in support of data discovery. 2. Support the processing and analysis of the sensor measurements. 3. Support the geolocation of the measured data. 4. Provide performance characteristics (e.g. accuracy, threshold, etc.). 5. Archive fundamental properties and assumptions regarding sensors. While SensorML originally was intended for the Space Time Toolkit [68] it is general enough to be used in other implementations. An example of a SensorML XML le is provided in Appendix B. 7.5 Actuators In the sentient object paradigm an actuator is dened as an entity that consumes software events, and reacts by attempting to change the state of the real world in some way via some hardware device. This may be the truth if one only considers physical devices to be actuators. In activity theory, an operation can be considered to be an actuator for an activity, in a workow system an actuator may be an IT tool or manual work, and in a context-aware application, context may be an actuator. We will not discuss hardware since it is not relevant to our work. 7.6 Intelligent Artifacts Strohbach et al. [63] presents the notion of intelligent artifacts. Figure 7.4 shows the components of an intelligent artifact. Sensors This may be any of the sensor types discussed above. Perception Converts sensor data into observations meaningful to the application. Knowledge base Contains the domain knowledge of the artifact and dynamic knowledge about its situation in the world. Inference Processes the knowledge in the knowledge base and knowleddg provided by other artifacts, and infer actions for the artifact to take. Actuators Actuate the inferred actions. 51Sensors and Actuators sperceptionknowledge baserulesdomainknowledgeobservationalknowledgeinferencesensorsactuatorssharedknowledgeobservationsmeasurementsactionssharedknowledgeFigure 7.4: Components of an intelligent artifact Domain knowledge Domain knowledge built into the artifact, e.g. facts describing the physical nature of the artifact or generra world knowledge. Observational knowledge Knowledge describing the situation of an artifact in the known world. It is based on facts that result from sensor-based observation. Inferred knowledge Knowledge inferred from previously established facts, which may be based on domain knowledge, observatiion previous inference, and knowledge made availabbl by cooperation artifacts. Table 7.1: Knowledge stored in an intelligent artifact The knowledge base consists of facts and rules where facts are the foundattio for decision-making and action-taking, and rules are used to infer further knowledge based on facts and other rule types. Strohbach et al. [63] categorise knowledge and rules in Table 7.1 and Table 7.2. An important aspect of intelligent artifacts is cooperation. Cooperation enabble the artifacts to do cross-artifact reasoning and collaborative inference of knowledge. This is done by sharing knowledge in the artifact's knowledge base with other artifacts in what becomes a distributed knowledge base. 527.7 Summary Inference rules Rules that describe inference of new facts from previoousl established facts. Actuator rules Rules that describe the facts that must be established in order to trigger an action. Table 7.2: Rules of an intelligent artifact 7.7 Summary Sensors which can be used in ubiquitous applications exist, but they are mostly used for research. Hill et al. [27] presents the state of the technology today. We will in our work simulate sensors and actuators, but the technoloogie described above will be very useful in determining what a realistic application is. 53Sensors and Actuators 54Chapter 8 Social Aspects This chapter deals with human considerations in context-aware systems. Bellotti [8] argues that it is the human and social aspects of context in computing systems that raise the most dicult questions related to contextawwar systems. These aspects are at the same time crucial if we want to make people benet from such systems rather than being hefted by annoying features, hindering their work. 8.1 Human Aspects of Context People have intentions, emotions, dislikes, and interpretations which make their behaviour dicult to model. Bellotti [8] states that due to this, desiggner are not likely to successfully represent human and social aspects of context in a deterministic fashion. Machines cannot take actions autonomiicall on our behalf, and a system is not capable of making meaningful inferences about human context. The only contextual aspects that may be handled by devices on their own are basic, non-human aspects with constraaine conditions and well dened responsive behaviour. Context-aware systems are increasingly used in commercial applications. These applications are often restricted to sensing and responding to physicca states and events. Real-life situations often involve a high degree of variability, where dierent outcomes depend on dierent conditions. Since it is hard to model outcomes in advance, allowing the system to take actiion based on context may propose great risks when human participants are involved. Due to this, Bellotti argues that systems cannot execute autonomiicall based only on context-awareness, but must involve users in action outcomes. Bellotti proposes two key features to be supported in any contextawwar infrastructure: intelligibility and accountability [8]: 55Social Aspects Intelligibility Context-aware systems that seek to act upon what they infer about the context must be able to represent to their users what they know, how they know it, and what they are doing about it. Accountability Context-aware systems must enforce user accountability when, based upon their inferences about the social context, they seek to mediate user actions that impact others. These notions are important to acknowledge when we want to make systems that are usable, predictable, and safe. Design Principles Bellotti lists four design principles that must be considered to achieve intelligibbilit and accountability within context-aware systems. 1. Inform the user of current contextual system capabilities and understanddings 2. Provide feedback: Feedforward -What will happen if I do this? Conrmation -What am I doing and what have I done? 3. Enforce identity and action disclosure; Who is that, what are they doing, and what have they done? 4. Provide to the use rcontrol over the system. These principles give rise to requirements for context-aware systems, which is further elaborated by Bellotti [8]. 8.2 Privacy One of the major issues in ubiquitous computing and context-aware systems is privacy. Satyanarayanan [59] describes privacy as the Achilles heel of pervasive computing. Realisation of the visions of Weiser [73] suers from problems with privacy as acknowledged by the author. For a system to infer actions on the user's behalf, as much information as possible must be available to the system to minimise the need for explicit interaction. This need will in many cases conict with privacy issues. Satyanarayanan believes that a step forward with regards to these issues is to increase the user awareness of their current privacy exposure level, and to provide some sort of \sixth sense" feature that informs the user when a serious privacy threat occurs. 568.3 Social Impact Jiang [32] describe a theoretical model for privacy control in context-aware systems. He emphasises how trust is a central concept if we are going to make users adopt context-aware systems. Even a few privacy violations can make people distrust a system, or maybe abandon the use of context-aware systems in general. In a work situation, we often want the environment to be aware of our goals, actions, and activities. In such a situation, it is not personal information that is being made available, but general information about work which may ease the coordination of activities and add safety to the working environment. 8.3 Social Impact The introduction of context-aware systems is meant to enhance the working environment, giving workers an easier way to deal with their work processes. Such work support may be done by introducing sophisticated mobile technoloog with support for workow enactment, providing coordination between workers and their activities. We acknowledge the many benets provided by such systems, but there may also be unforeseen consequences. Case studies [36] show that the introduction of even simple forms of mobile technology to support work may lead to loss of information because human to human interaction is decreased. With the emergence of context-aware systems, such issues become increasingly important to be aware of if we want people to adopt these systems successfully. 8.4 Summary Social aspects often receive little attention when dealing with context in context-aware systems. This may lead to problems with users that are not willing to adopt these systems. Bellotti argues that the human aspects of context means that context-aware systems cannot be made to act on our behalf and users must interact with these systems. Other social aspect of context in context-aware systems involves privacy, which may be an major problem in future applications. In a working environment though, we want to make much information available to ease the coordination of activities and add safety to the working environment. This is not personal information, and issues related to privacy are less of a concern in this setting. 57Social Aspects 58Chapter 9 Related Work This chapter introduces some work related to our approach. We have not found any frameworks or architectures that fully support our problem domaain but some implements parts of it. 9.1 CAGIS CAGIS [52] (Cooperative Agents in a Global Information Space) is a research project which aims to support IT-based cooperation among humans who are located in dierent geographical locations. The CAGIS environment consists of a system handling distributed documents and document understanding, a system for supporting cooperative processes in a distributed environment, and a exible transaction management for shared, distributed resources [53]. 9.2 Adaptive Workow System Cingil et al. [14] presents an architecture for adaptive workow systems for electronic commerce applications on the Internet. The architecture describes how workow templates can be instantiated, how they can be stored, and how they can be executed on dierent clients. While the architecture solves some of the problems with adaptive workow systems, it does not take context-awareness and cooperation into account. 9.3 Cooperative Open Workow Vantroys and Rouillard [70] have created a system for mobile learning processse called Cooperative Open Workow (COW). It supports exible work-ows, work coordination between teachers and students, and user mobility. Mobility is achieved by using a central server for storing workow documennts and transforming the documents to optimise the viewing experience on dierent terminals. 59Related Work 9.4 Java Border Service Architecture Wilken et al. [42] have created the Java Border Service Architecture (JBSA), an infrastructure to integrate various mobile devices into distributed systeems The architecture is based on separating the presentation from the program logic by using abstractions. The JBSA works as a mediator serviice converting server response to something the client can support. By doing this, the client device does not need any modication to run the applicaation This can be useful when the devices are small, and does not allow modications or third-party software. Our work focus on PDAs that can run such software, and hence the JBSA approach is not needed in our architecture. 60Part II Own Contribution 6162Chapter 10 Scenarios This chapter presents scenarios for possible applications of adaptive, contextawwar workow systems. The scenarios are based on themes in available literature, and from presentations held at the MOBIS conference [34] in Oslo. The motivation for presenting these scenarios is that scenario analysis often reveals requirements and challenges which are relevant for us when designing an architecture. These scenarios may also give us \showcases" for demonstrating important features of a future implementation of our propoose architecture. Section 10.1 presents a scenario that deals with maintenance work on an oil platform, Section 10.2 presents a scenario with electricians performing work indoors, and Section 10.3 presents a shipyard scenario. 10.1 Maintenance Work on Oil Platforms Maintenance procedures on oil platforms aim to maximise throughput and minimise downtime. Estimates show that only 65% of total maintenance work is spent on actual repair work [35]. For critical equipment, unplanned corrective maintenance work costs three times more than planned maintennanc work on average. These numbers show that there exists a great potential for improvement related to maintenance work on oil platforms. Vraalsen et al. [35] lists the following areas which need improvements: Access to data Retrieval of background maintenance data is time consummin and involves searching in large paper based archives. This process is time-consuming and often the required data cannot be found. Quality of maintenance data Quality of historical maintenance data is often poor and of little help. 63Scenarios Information ow and work-processes Work orders and work-permits are paper based which introduces long delays. Access to personnel Delays when a situation requires expert support. 10.1.1 Sensors, Devices and Infrastructure To improve eciency, a context-aware maintenance application has to rely on tagging of equipment. Critical equipment must be tagged in such a way that an application can identify its presence and use its information to automate maintenance processes. The maintenance worker is carrying a mobile terminal running a maintenaanc application. The mobile terminal is typically a robust PDA with support for WLAN and Bluetooth for identifying equipment. 10.1.2 Workow We have developed use cases and activity diagrams to increase understandiin of the workow related to this scenario. These models reect a situation with several workers performing work in the same area, possibly having to compete for resources. Figure 10.1 describes a situation with a oil platform worker performing maintenance work. Figure 10.1: Use case for a routine inspection of equipment The maintenance worker approaches a given gearbox in a given area for a routine inspection in accordance to a work order downloaded on the mobile 6410.1 Maintenance Work on Oil Platforms terminal. When moving towards the gearbox, the mobile terminal noties the worker that he or she is at the right device. Since the application is context-aware, it can check relevant properties of related devices. This sensed information is then used to take safety measures in accordance to the work to be done. Safety measures may be to cut power for a certain circuit, stop the execution of a machine near the maintenance worker, or to set certain parameters for related equipment. For a mobile terminal to achieve this, it has to communicate with sensors and actuators embedded in the oil platform devices. A template for the work process of a routine inspection is shown in Figure 10.2. Figure 10.2: Template for the work process of inspecting equipment This template works as a very general plan for performing maintenance work on an oil platform. In a specic situation, such a template will have to be instantiated by using contextual information from the environment. The work process template of Figure 10.2 may be instantiated with subproccesse and activities to achieve its objective. We will now describe these sub-processes and activities in more detail. Download Work Order is an automated activity that is triggered when the worker is on the correct site for the work order. The Locate Gearbox activvit executes when worker is on site with a valid work order. The mobile terminal helps the worker locate the gearbox, and gives a notication to the worker when he/she has approached it. Check Properties is a sub-process capable of checking relevant properties of devices nearby. These properties 65Scenarios typically involve checking temperature, pressure, power, current state etc. of a device. Checking for other workow clients located in the same area is also important for an eective coordination of activities. Take Safety Measuure is a sub-process that takes actions based on the sensed information from the environment and make sure all relevant devices are in a correct and safe state for the work to be performed. The Display Log activity automaticaall displays the log for previous work done on the device. Display Safety Procedure is an activity that automatically shows important safety proceduure for the work at hand. Technical diagrams are automatically displayed with the Display Technical Diagram activity. After completed work, the Log Data activity makes sure logging is done automatically with a detailed work description if the performed work did not follow the documented procedure. An instantiation of the inspection template of Figure 10.2 is shown in Figure 10.3 Figure 10.3: Instantiation of template -Inspecting device D2 The instantiation shows how a worker downloads a specic work-order, and locates the location for the gearbox and maintenance device. The work is done on device D2, which involves having power turned oand a low temperature on device D2. It also means having a high pressure in device 6610.1 Maintenance Work on Oil Platforms D1. Multiple Workers and Competing Resources An oil platform often involves several workers performing maintenance work in the same area at the same time. This situation may lead to conicting need in reference to completing all work orders while keeping a safe working environment. Figure 10.4 shows an activity diagram with activities in a work process which is in conict with the activities of the work process in Figure 10.3 Figure 10.4: Instantiation of template -Inspecting device D3 This instantiation is for work on device D3, which involves having power on device D2, and Ok pressure on device D3. Such conicts needs to be handled by coordinating the activities. Such coordination relies on a set of rules, where safety is the rst criteria, then cost. Each workow client has a high degree of autonomy, and its own set of rules in order to enact workows. 67Scenarios 10.2 Electricians Performing Work Indoors Wang et al. [72] introduce a case study where electricians use PDAs1 to support their work. They use a program called HandyMan developed by ePocket Solutions ASA [23] that manages memos, time usage, and stock of materials for the electrician. In addition, it contains a checklist that function as a workow system. Synchronisation with the oce can occur in the oce by connecting the PDA to its cradle, or on-site by using a mobile phone. 10.2.1 Problem Description In a traditional work environment, an electrician waits in the oce until a work order, or a work order list, is given. The electrician then collects the required tools and material before heading out to do the work. When the work is nished the electrician lls out the required documents, and moves on to another work order. Often, plans cannot be entirely pre-planned according to the work order, and hence the electrician can benet from context-aware workow support. 10.2.2 Scenario A scenario expanded from the HandyMan case study is presented below, where the electrician works in a smart home [49]. The electrician is equipped with a PDA that connects to the oce via a mobile phone. Srensen et al. [13] has provided a list of activities an electrician may perform in a smart home: 1. The electrician company gets a work order to install a heater at a given address. 2. The work order is put into the work plan of an electrician, based on the following properties: Available time, skill, and minimum driving distance. 3. Necessary equipment is made available to pick up by the electrician. 4. A driving route is calculated for the electrician based on the day's activities, and is presented to the electrician in the car together with information about the next activity. 5. The system nds historical information about the house to be visitted and the relevant information is presented in audio form when the electrician is driving to the actual address. 1Personal Data Assistant 6810.2 Electricians Performing Work Indoors 6. The owner of the house indicates the position of the installation to the electrician. 7. The embedded house environment presents a map of the available circuiits switch boxes and other information related to the electricity infrastructure in the house. All cables and other equipment are instrummente with location sensors and an internal knowledge database with technical information about themselves and their connections. 8. The map is interactive and the position and technical information of the heater is given to an in-house system. 9. The in-house system presents an overview of already installed equipmeen together with the already used eect of the nearby, relevant circuits, and proposes to either use an existing circuit, or to install a new one. 10. A conduit route is proposed by the in-house system based on given preferences from the fuse box to the heater position. 11. The system turns othe part of the electricity system aected by the installation. 12. The electrician informs the system that the work is nished. 13. The in-house system updates the circuit map and includes technical information about the installed equipment. 14. The in-house system informs whether the new circuit is working or not. 15. The in-house system ensures that it is safe to turn on the power, and turns it on. 16. The newly installed equipment gives the technical information back to the electrician's computer, and an invoice is created based on the used material, time spent and the driving distance and time. The inventory is updated, and the invoice is either transmitted electronically to the in-house invoice receiver service, or printed out. 17. The invoice is paid by the customer and the electrician leaves the house eventually continuing from work item 4. Srensen et al. [13] state that this is not a complete workow scenario, since it does not include exceptions, resource congestion and the like. Still, this scenario shows how useful context-aware devices can be in supporting work processes for mobile users. The embedded house environment helps 69Scenarios the electrician by providing more safety in his work environment, and a more ecient way of performing this work. Safety aspects may be related to controlling power of devices in accordance to work order, while eciency may be related to supporting the worker with information about his work order and relevant aspects of his working environment. 10.2.3 Smart Work Processes The work processes in this scenario can benet from using situated planning as proposed by Srensen et al. Coarse-grained plans can act as templates that are instantiated by using the contextual properties of the environment. Such smart work processes are sentient, which means they sense the environnmen and adapts according to context changes through context-based reasoning to reach process goals [72]. Actuations take the form of situated activities which may change the current planned activities. 10.3 Shipyard The use of robots in ship construction has increased recent years, but it is still a labour intensive industry. While there have been improvements in safety for shipyard workers, there is still a 5% injury rate of employees [74], and deaths are common. Wondermar [74], a research project for the European maritime industry, describes several scenarios related to shipyards, dealing with hazardous and partly automated work environments for ship construction. 10.3.1 Workers and Mobile Robots Shipyards are hazardous work environments, which makes robots important as an addition to the existing workforce. Robots can operate in hostile environmments performing work that is dangerous to human workers. The most common use of robots in shipyard construction is welding. They may also be used in maintenance work, such as painting, cleaning, and inspections. Mobile robots then work on large structures, often by using tracks, and sometimes alongside common workers. In addition to the safety aspects, there is a potential for increased eciency. Altering complex robotic welding systems to handle single patterns is expensiive By using cooperating, mobile robots, a reduced need for pre-planned activities leads to great savings in welding time. Possible benets of introducing mobile, cooperating robots in shipyards are [74]:Reduced risk of death or injury. 7010.3 Shipyard Savings in welding times. Increased robotic welding accuracy. Reduced rework rate. Reduced construction time. These benets relate to aspects of safety and eciency. 10.3.2 Collaboration Shipyard robots need to be mobile, and have some kind of coordination of their activities. Each mobile robot should be able to schedule work independenntly and thus have some sort of \intelligence" supporting their execution of activities. Such mobile robots have a high degree of autonomy, and rely on advanced sensing technology for this purpose. One proposed solution is to use vision-guided robots to achieve automatic welding. This makes them able to do work without having a pre-programmed path, and thus saving time when setting up new complex welding jobs. The Wondemar project suggests applications of such \intelligent" mobile robots to be: painting, welding, riveting, and in-situ cutting. Intelligent Artifact Approach These robots may use an intelligent artifact approach [63] to their collaborattion Intelligent, cooperative artifacts are able to asses their situation without the need of a separate infrastructure. The intelligent artifact approoac relies on: embedded domain knowledge, perceptual intelligence, and rule-based inference. Strohbach [63] describes a set of components as an architeectur of a cooperative artifact. These components will for this shipyard scenario be the following: Sensing Each mobile robot needs to include sensor devices for observation of phenomena in the physical world, such as other robots or workers. This can e.g. be done by using robots with vision capabilities. Perception This component associates sensor data with meaning in terms of the application. Location and sensor data observed by vision may provide meaningful terms used in the coordination of activities. Knowledge base Contains the domain knowledge, and dynamic knowleddg about its situation. Domain knowledge for these mobile robots may be which robots exist in the environment and information about their welding. Dynamic knowledge may be observed robots and their location, as well as other information about cooperating artifacts. 71Scenarios Inference Knowledge and rules are used together to infer new knowledge about the world. Rules for mobile robots may for example be about how to deal with situations where two robots compete for the same resource. Actuators Actions that have been inferred are eected by actuators. Actuaator for mobile robots may be dierent kinds of equipment for welding, painting etc. 10.4 Summary The scenarios presented in this chapter help us identify important generic functionality which needs to be addressed when developing an architecture supporting mobile adaptive work processes. These considerations coincide with what Ngyen and Ndtvedt identied in their master thesis [47]. Ad-hoc enactment of processes and activities. Coordination of processes and activities. Situated planning. Workow systems with processes integrating contextual information. In addition, Srensen et al. [13] identies some general requirements related to the notion of smart work processes which is very relevant to our scenarios. The working environment must have services These services can be given required properties to be satised during process or activity execution. Coordination service A coordination service is necessary in order to coordiinat workow among dierent actors, possibly competing for resources. Such coordination should be possible, even when the dierent actors are disconnected from a central workow enactment service. A decentralised approach to coordination of workow may be necessary. Rules must be specied or developed To achieve adaptation of work processes to contextual conditions, rules must be specied and developed in order to dene correct adaptation. Specic environments can have pre-dened activities or plans Preddned activities or plans may be put into the enactment when certain contexxtua conditions occur. These generic requirements will be further elaborated in the requirement specication in Chapter 11 and the architecture proposal in Chapter 12. 72Chapter 11 Requirement Specication This chapter presents the requirements for our proposal for an architecture presented in Chapter 12. Section 11.1 presents the functional requirements, while section 11.2 presents non-functional requirements. The use of COTS and encountered problems are covered in Section 11.3 and Section 11.4 respecttively We will use methods for creating an architecture created by Bass et al. [7] where appropriate. 11.1 Functional Requirements The functional requirements are presented in Table 11.1 through 11.5. These requirements are edited and updated from the work of Ndtvedt and Ngyen [47]. Index Description F1 Adhere to the WfMC standards and the Interface 1 specication in particular. F2 Interpret and enact all process denitions dened in the XPDL. F3 Evaluate workow transitions dened in the XPDL. F4 Update workow relevant data based on completed activities from workow participants that have updated such data. F5 Perform enactment of concurrent processes that possibly competes for resources. F6 Communicate with workow clients to send and receive activities. Table 11.1: Functional requirements for a basic workow system 11.2 Non Functional Requirements Our focus is on these quality requirements: 73Requirement Specication Index Description F7 Context source abstraction for context sources to remove low-level input handling from the main application code (separation of concerrns) and provide limited context interpretation. F8 Service for discovering, and look-up of context sources. F9 Support both polling and publish /subscribe mechanisms for context information retrieval from context sources. Table 11.2: Functional requirements for context information Index Description F10 Context information should be used in the evaluation of workow transitions. F11 Lightweight process denition of context source look-up, polling and conversion of the context information between the context representattio and the workow representation. F12 High responsiveness to contextual changes or events: Ad-hoc start of processes and activities. Context as post conditions for processes. Correct handling of invariant conditions. F13 Support re-validation of selected process paths, if the current path does not lead to the process goal. F14 Support exception handling of undened contextual states. F15 Support for both pre-planned and unplanned process enactment by providing rule-based process building with learning. Table 11.3: Functional requirements for the workow enactment service Modiability An adaptive context-aware workow is by denition dynaami and hence must be congurable at run-time. Availability If a workow process is adaptive, it should support handling of exceptions and deviations from the original plan. This means that the workow process should be available at all times. Our architecture makes several assumptions with regards to the electronic environment: Access to high-quality wireless network Our tests will be run on the standard and proven 802.11b [64] WLAN technology. 7411.3 COTS Components and other Technical Constraints Index Description F16 Perform situated planning based on current contextual conditions. F17 Perform situated activity coordination between workow participannts F18 Context as post-condition for activities. (See also F12) Table 11.4: Functional requirements for client context-awareness Index Description F19 Support for physical mobility and network mobility. F20 Handling of unreliable communication. F21 Support for disconnected operations and asynchronous communicatiion F22 Activity locking with support for reassignment of activities. F23 Support for exible task assignment. F24 Support for session mobility. F25 User should be able to select the data elements to be tran