Adaptive Mobile Work Processes

Adaptive Mobile Work Processes Frode Hauso Øivind Røed Systemutvikling, fordypning TDT4735 Faglærer: Alf Inge Wang Veileder: Carl-Fredrik Sørensen Trondheim, 25th November 2004 NTNU-IDI ii Abstract This report provides a literature study of issues related to context-aware work support systems. We have elaborated mobile work scenarios and requirements 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. Important aspects of this architecture are related to finding suitable abstractions for context sources, coordination of workflow between workflow clients, local process enactment of workflow clients by using templates and the contextual state of the environment, and the ability of workflow clients to plan in situ. i ii Preface This report is the result of work performed as the part of the course TDT4735 by Frode Hauso and Øivind Røed at the Institute for Computer and Information 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 Sørensen, for his support and invaluable insights, ideas, and comments during our work. Trondheim 25th November 2004 ——————— Frode Hauso ——————— Øivind Røed iii iv Contents 1 Introduction 1.1 1.2 1.3 1.4 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 2 4 7 Problem Definition . . . . . . . . . . . . . . . . . . . . . . . . Outline of the Report . . . . . . . . . . . . . . . . . . . . . . 2 Research Methods I Prestudy 9 11 12 14 15 15 17 17 18 18 18 18 20 3 Workflow 3.1 3.2 3.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . Types of Workflow Systems . . . . . . . . . . . . . . . . . . . WfMC’s Workflow Reference Model . . . . . . . . . . . . . . 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5 3.4 Interface 1: Process Definition . . . . . . . . . . . . . Interface 2 and 3: Workflow APIs . . . . . . . . . . . . Interface 4: Workflow Interoperability . . . . . . . . . Interface 5: Administration and Monitoring . . . . . . Interface c: Context Information Integrator . . . . . . Adaptive Workflow and Exception Handling . . . . . . . . . . 3.4.1 3.4.2 Exceptions . . . . . . . . . . . . . . . . . . . . . . . . Handling Exceptions . . . . . . . . . . . . . . . . . . . v CONTENTS 3.4.3 3.5 3.6 Adaptive Workflow . . . . . . . . . . . . . . . . . . . . 21 22 22 23 24 26 26 27 28 29 31 31 31 32 33 33 34 37 37 37 38 39 40 40 41 42 43 44 Workflow Modelling . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Context-Aware Computer Systems 4.1 4.2 4.3 4.4 4.5 4.6 Context and Context-Classifications . . . . . . . . . . . . . . Context-Sensing and Infrastructure . . . . . . . . . . . . . . . Context-Aware Computing . . . . . . . . . . . . . . . . . . . Challenges in Context-Aware Computing . . . . . . . . . . . Advantages of Context-Aware Computing . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Activity Theory and Situated Actions 5.1 5.2 Situated Actions . . . . . . . . . . . . . . . . . . . . . . . . . Activity Theory . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 5.2.2 5.3 5.4 The Basic Principles of Activity Theory . . . . . . . . Principles Derived from Activity Theory . . . . . . . . Situated Planning . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Enabling Technologies 6.1 The Context Toolkit . . . . . . . . . . . . . . . . . . . . . . . 6.1.1 6.1.2 6.1.3 6.1.4 6.2 Architectural Framework Features . . . . . . . . . . . Architectural Building Blocks . . . . . . . . . . . . . . Implementation . . . . . . . . . . . . . . . . . . . . . . Framework Drawbacks . . . . . . . . . . . . . . . . . . CORTEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 6.2.2 The Sentient Object Model . . . . . . . . . . . . . . . CORTEX Middleware . . . . . . . . . . . . . . . . . . 6.3 6.4 Mobile Wireless Networks . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vi CONTENTS 7 Sensors and Actuators 7.1 7.2 7.3 Sensors Like Dust and Brilliant Rocks . . . . . . . . . . . . . Wireless Sensor Networks . . . . . . . . . . . . . . . . . . . . Wireless Sensor Nodes . . . . . . . . . . . . . . . . . . . . . . 7.3.1 7.3.2 7.4 7.5 7.6 7.7 Non Context-Aware Sensors . . . . . . . . . . . . . . . Context-Aware Sensors . . . . . . . . . . . . . . . . . 45 45 45 47 47 47 50 51 51 53 55 55 56 57 57 59 59 59 59 60 SensorML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intelligent Artifacts . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Social Aspects 8.1 8.2 8.3 8.4 Human Aspects of Context . . . . . . . . . . . . . . . . . . . Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Social Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Related Work 9.1 9.2 9.3 9.4 CAGIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adaptive Workflow System . . . . . . . . . . . . . . . . . . . Cooperative Open Workflow . . . . . . . . . . . . . . . . . . . Java Border Service Architecture . . . . . . . . . . . . . . . . II Own Contribution 61 63 63 64 64 68 68 10 Scenarios 10.1 Maintenance Work on Oil Platforms . . . . . . . . . . . . . . 10.1.1 Sensors, Devices and Infrastructure . . . . . . . . . . . 10.1.2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Electricians Performing Work Indoors . . . . . . . . . . . . . 10.2.1 Problem Description . . . . . . . . . . . . . . . . . . . vii CONTENTS 10.2.2 Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2.3 Smart Work Processes . . . . . . . . . . . . . . . . . . 10.3 Shipyard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3.1 Workers and Mobile Robots . . . . . . . . . . . . . . . 10.3.2 Collaboration . . . . . . . . . . . . . . . . . . . . . . . 10.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Requirement Specification 11.1 Functional Requirements . . . . . . . . . . . . . . . . . . . . . 11.2 Non Functional Requirements . . . . . . . . . . . . . . . . . . 11.3 COTS Components and other Technical Constraints . . . . . 11.3.1 CORTEX Middleware . . . . . . . . . . . . . . . . . . 11.3.2 CLIPS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3.3 Mobility and Context-Awareness Prototypes . . . . . 68 70 70 70 71 72 73 73 73 75 75 76 76 76 76 77 77 77 79 79 79 80 80 81 84 84 85 85 11.3.4 The Context Toolkit . . . . . . . . . . . . . . . . . . . 11.3.5 WfMC Reference Model . . . . . . . . . . . . . . . . . 11.3.6 MS Embedded Visual C++ . . . . . . . . . . . . . . . 11.3.7 HP iPAQ Handheld Device . . . . . . . . . . . . . . . 11.4 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Architecture Proposal 12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.2 Quality Tactics . . . . . . . . . . . . . . . . . . . . . . . . . . 12.3 Architectural Drivers . . . . . . . . . . . . . . . . . . . . . . . 12.4 Stakeholders . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.5 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . 12.6 Logical View . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.6.1 Context Service . . . . . . . . . . . . . . . . . . . . . . 12.6.2 Actuator Service . . . . . . . . . . . . . . . . . . . . . 12.6.3 Context Source . . . . . . . . . . . . . . . . . . . . . . viii CONTENTS 12.6.4 Workflow Client . . . . . . . . . . . . . . . . . . . . . 12.7 Physical View . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.8 Process View . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.9 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12.10Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 88 88 90 95 III Discussion and Conclusion 97 99 . . . . . . . . . . . . . . . . . 99 13 Evaluation 13.1 Evaluation of the Architecture 13.2 Evaluation of Research Method . . . . . . . . . . . . . . . . . 100 14 Further Work 15 Conclusion 103 105 IV Appendix 117 119 121 A XPDL Example B SensorML Example ix List of Figures 3.1 3.2 3.3 3.4 3.5 4.1 5.1 6.1 6.2 7.1 7.2 7.3 7.4 A simple example for an order processing workflow. . . . . . . Workflow definitions . . . . . . . . . . . . . . . . . . . . . . . WfMC’s Workflow reference model . . . . . . . . . . . . . . . WfMC’s Workflow reference meta-model . . . . . . . . . . . . Extended workflow reference model . . . . . . . . . . . . . . . Dimensions of ubiquitous computing [37] . . . . . . . . . . . . Hierarchical levels of an activity [45] . . . . . . . . . . . . . . Components of the Context Toolkit [19] . . . . . . . . . . . . The Sentient Object Model [1] . . . . . . . . . . . . . . . . . A sensor network divided into a hierarchy . . . . . . . . . . . The Sonitor system . . . . . . . . . . . . . . . . . . . . . . . . Location-sensing technologies . . . . . . . . . . . . . . . . . . Components of an intelligent artifact . . . . . . . . . . . . . . 12 13 16 17 19 23 32 39 41 46 49 50 52 64 65 66 67 77 81 10.1 Use case for a routine inspection of equipment . . . . . . . . . 10.2 Template for the work process of inspecting equipment . . . . 10.3 Instantiation of template - Inspecting device D2 . . . . . . . . 10.4 Instantiation of template - Inspecting device D3 . . . . . . . . 11.1 The HP iPAQ PDA . . . . . . . . . . . . . . . . . . . . . . . 12.1 Architecture overview . . . . . . . . . . . . . . . . . . . . . . x LIST OF FIGURES 12.2 Architecture actor interaction overview . . . . . . . . . . . . . 12.3 Class diagram describing a context service . . . . . . . . . . . 12.4 Class diagram describing an actuator service . . . . . . . . . 84 85 86 87 88 89 90 91 92 93 12.5 The context source abstraction hierarchy . . . . . . . . . . . . 12.6 Logical view of the workflow client. . . . . . . . . . . . . . . . 12.7 Deployment of the architecture components . . . . . . . . . . 12.8 Workflow client enactment of workflow process . . . . . . . . 12.9 States of the context service . . . . . . . . . . . . . . . . . . . 12.10A context client request a context source . . . . . . . . . . . . 12.11A workflow client sends an actuation order . . . . . . . . . . xi List of Tables 3.1 Relationship between types of workflow exceptions and changes to the workflow model . . . . . . . . . . . . . . . . . . . . . . Knowledge stored in an intelligent artifact . . . . . . . . . . . Rules of an intelligent artifact . . . . . . . . . . . . . . . . . . 20 52 53 73 74 74 75 75 7.1 7.2 11.1 Functional requirements for a basic workflow system . . . . . 11.2 Functional requirements for context information . . . . . . . . 11.3 Functional requirements for the workflow enactment service . 11.4 Functional requirements for client context-awareness . . . . . 11.5 Functional requirements for client mobility . . . . . . . . . . . xii Chapter 1 Introduction This chapter presents the background and motivation for our work. It also contains a detailed problem definition and outlines the structure of the report. 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 workprocesses in virtual organisations. • Provide a flexible, 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 define a flexible work environment for virtual organizations. This work environment 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. 1 Introduction This report partly address all three goals by proposing a work environment on mobile devices. This environment can be used to help the understanding 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 workflow system are twofold: Increased efficiency and safety in workflow systems Adaptive, mobile workflow systems can provide great benefits 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 efficiency by letting the system automate 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 embedded 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 benefit 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 Definition 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 Nødtvedt and Man Hoang Ngyen [47]: Mobility and Context-Awareness in Workflow Systems. The activity coordination aspect of a workflow enactment 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 workflow enactment service will be important in our work. This report will provide a prestudy, scenarios, requirements, and an architecture to support a prototype implementation of a context-aware workflow 2 1.3 Problem Definition 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 workflow 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 survey on relevant topics such as context-aware computer systems (Chapter 4) and workflow (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 requirements set by Nødtvedt and Ngyen in [47]. Our findings 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 workflow enactment? To answer this question, we have used the engineering approach by first reviewing 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 findings related to this research question. RQ3 How is it possible to plan in situ when executing cooperative work activities, and how can we deal with competing work processes? Planning includes the building, altering, sharing, execution, 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 workflow 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 technology? We have performed a literature study on state-of-the-art of sensor technology. Improvements in sensor technology are necessary to achieve large scale 3 Introduction 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 research, 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 relevant theories, enabling technologies, and existing frameworks relevant to our work. • Chapter 3 - Workflow: Gives an introduction to workflow and issues in workflow systems. • Chapter 4 - Context-Aware Computer Systems: Gives an introduction to context-awareness. • Chapter 5 - Activity Theory and Situated Actions: Gives an introduction 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 workflow 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 workflow systems. • Chapter 9 - Related Work: Presents related work in the field 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 workflow system. 4 1.4 Outline of the Report • Chapter 10 - Scenarios: Presents three relevant scenarios describing applications for context-aware workflow systems. • Chapter 11 - Requirement Specification: Describes requirements and COTS components relevant to our architecture. • Chapter 12 - Architecture Proposal: Presents our architecture proposal based on previously stated requirements. Part III - Discussion and Conclusion This part summarises our findings and gives a discussion, an evaluation, and conclusions for our work. • Chapter 13 - Evaluation: Gives a discussion and evaluation of findings 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. 5 Introduction 6 Chapter 2 Research Methods According to Zelkowitz [78], there are four general categories of research methods: Scientific 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 hypothesis. 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 validate a given hypothesis. Unlike the scientific 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 definition 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 relevant aspects of our problem domain. The Internet provided us with articles, journals and the like from research sites at which NTNU have licence. 7 Research 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 different approaches to the topic of adaptive work processes and contextawareness 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 different 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 definition, 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. 1 The International Federation for Information Processing 8 Part I Prestudy 9 10 Chapter 3 Workflow In this chapter we present a short introduction to workflow and workflow management systems before we present some proposed additions to workflow management systems. “Workflow 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 “workflow” because it’s so important. [4]” Before workflow systems became common, work orders were sent to participants by hand. In the early days of workflow systems, work was sent from one participant to another. This made the work more efficient 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 workflow systems are much more advanced, and the work process itself is automated by IT tools wherever possible. Figure 3.1 [22] shows a simple workflow for order processing. Each node is an activity performed by a participant and must be performed in sequence as identified by the arrows. Customer Credit Check and Inventory Check must both be finished before Payment Processing is executed. The activities in this workflow 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 workflow there is great benefits to workflow and workflow systems. Plesums [51] lists these benefits of workflow management systems: 11 Workflow Order placement Validation Customer credit check Inventory check Payment processing Order fulfillment Figure 3.1: A simple example for an order processing workflow. • Work does not get misplaced or stalled. Participants are rarely required to recover from errors or mismanagement of the work. • The managers can focus on staff and 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, ensuring 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 first. Users do not waste time choosing which item to work on. • Parallel processing, where two or more tasks are performed concurrently, is far more practical than in a traditional, manual workflow. 3.1 Terminology In this section we look at the current workflow terminology. Workflow is standardised by the Workflow Management Coalition (WfMC) [66], a nonprofit, international organisation that promotes the use of workflow by estab12 3.1 Terminology lishing standards and terminology for connectivity between workflow products. The coalition has over 300 members worldwide, and is the primary standards body for workflow. WfMC has the following mission statements: • Increase the value of customers’ investment with workflow technology. • Decrease the risk of using workflow products. • Expand the workflow market through increasing awareness for workflow. Figure 3.2 shows the WfMC definitions [16] and the relationships between them. Figure 3.2: Workflow definitions Workflow 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. 13 Workflow Workflow management system A system that defines, creates, and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow 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, defining functional roles and relationships. Process definition The representation of a business process in a form which supports automated manipulation, such as modelling, or enactment by a workflow management system. The process definition 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 workflow (automated) activity. A workflow activity requires human and/or machine resources(s) to support process execution; where human resource is required an activity is allocated to a workflow 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 Workflow Systems There exist many types of workflow systems that support a wide range of work. Allen [4] classifies workflow systems into the following four categories. • Production This category comprises workflow 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 workflow engines An autonomous workflow engine is a system that is self contained. It does not need any external IT tools, although some may rely on critical external 14 3.3 WfMC’s Workflow Reference Model software like database management systems. Not relying on external IT tools can make these workflow systems very complex and expensive to build and maintain. – Embedded workflow An embedded workflow management system 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 workflow system has a large number of workflow processes that involves a large number of employees. In such a system, flexibility is more important than productivity, and tasks are often executed manually. • Collaborative A collaborative workflow focuses on groups working together toward common goals, also called groupware. • Ad-Hoc Ad-Hoc workflows are created “on the fly” by the current participants, and the process definitions are very flexible. We will have a more detailed look at ad-hoc workflow systems in section 3.4. While support for context-awareness potentially can be useful for production and administrative workflows it is not interesting for our work. Our work will focus on single workers or small groups of workers. Collaborative and ad-hoc workflows are thus of more interest to us. In the next section we will explore the WfMC’s workflow reference model. 3.3 WfMC’s Workflow Reference Model To support interaction between workflow products, WfMC has defined the workflow reference model shown in Figure 3.3. This model is divided into five interfaces which we will describe below. Interface 6-8 are still under development and are currently not a part of the official workflow reference model. These are not relevant to our work. The reference model provides a common vocabulary for describing business processes, a functional description of the software components needed to support workflow, and the definition of interfaces between the software components. It tries to be as technology neutral as possible. 3.3.1 Interface 1: Process Definition This interface integrates the process definitions to the workflow enactment service in the form of an interchange Process Definition Language (PDL) and API 1 calls. 1 Application Programming Interface 15 Workflow Process Definition Tools Interface 1 Workflow API and interchange formats Interface 5 Administration and Monitoring Tools Workflow Enactment Service(s) Interface 4 Other Workflow Enactment Service(s) Workflow engine(s) Workflow engine(s) Interface 2 Interface 3 Work List Handling Process Control Invoked Applications Application Data Workflow Client Applications Figure 3.3: WfMC’s Workflow reference model The process definition 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 workflow definitions, a workflow process definition meta-model has been established. This metamodel identifies common entities within a process definition. A variety of attributes describe the characteristics of this limited set of entities. Based on this model, vendor specific 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 interest to us. This element contains data which is maintained by the workflow management system or the local system environment, that can be accessed in the workflow process enactment and used in the evaluation of conditional 16 3.3 WfMC’s Workflow Reference Model expressions. In our work we can possibly use this element as an interface to context sources (Chapter 4.1). 1 Workflow Process Definition 1 1 1 1 1 * Activity Set 1 * System and Environmental Data Workflow Relevant Data * Performed by * Workflow Process Activity Sub-Process Definition Block Activity 1 invoke * Workflow Participant Specifiication * Workflow Application Declaration from to Atomic Activity Transition Information * * Resource Repository or Organizational Model Figure 3.4: WfMC’s Workflow reference meta-model Process Definition Language: XPDL To support a variety of different tools that analyse, model, describe and document business processes, there is a need for a standard interchange format that transfer workflow process definitions between the separate products. WfMC has created and promotes a formal specification, the XML [75] Process Definition Language (XPDL) [65]. XPDL supports all the entities in the workflow reference meta-model. See [65] for definitions of all the entities and their corresponding XPDL tags, and Appendix A for an example. 3.3.2 Interface 2 and 3: Workflow APIs Interface 2 and interface 3 has been combined, and cover the workflow 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: Workflow Interoperability Interface 4 defines the interface that enables workflow engines from different workflow product vendors to make requests to each other to do selection, 17 Workflow instantiation and enactment of known process definitions. The workflow systems are able to send context data and receive status information and the results of the enactment of the process definition in return. WfMC has created a standard for transmitting such requests called WfXML. 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 notification when it is completed. These AWS can do work that is required by the remote workflow system. It is important to note that not all workflow 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 workflow system in order to allow analysis of consistent audit data across heterogeneous workflow products. The analysed events can be anything of interest to a business. 3.3.5 Interface c: Context Information Integrator Nødtvedt and Nguyen [47], propose a new interface to the workflow reference model. They call this interface “Interface 6: Context information integrator”, 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 workflow reference model. This interface was created to avoid modifying the existing workflow interfaces, and thereby be able to use the services already defined in the WAPIs. The goal of this interface is to provide dynamic contextual information to the workflow enactment service(s). 3.4 Adaptive Workflow and Exception Handling In this section we present exceptions and exception handling in workflow systems as well as research on adaptive workflow processes. 3.4.1 Exceptions Kammer et al. [33] divide exceptions into two main categories: expected exceptions and unexpected exceptions. Expected exceptions are exceptions 18 3.4 Adaptive Workflow and Exception Handling Process Definition Tools Interface c Context Information Integrator Interface 1 Workflow API and interchange formats Interface 4 Other Workflow Enactment Service(s) Workflow Enactment Service(s) Administration and Monitoring Tools Workflow engine(s) Workflow engine(s) Interface 5 Interface 2 Interface 3 Work List Handling Process Control Invoked Applications Application Data Workflow Client Applications Figure 3.5: Extended workflow reference model that are modelled into the workflow at design time, while unexpected exceptions naturally can be very hard to model at design time. Expected exceptions are not very interesting in our work, since they are already covered by the WfMC workflow reference model. We will therefore only look at unexpected exceptions and possible methods of handling them without manual intervention. It is also important to note that we only discuss exceptions in the business process execution. Other exceptions like network disconnections, varying network bandwidth, and hardware or software malfunctions are not covered here. Exceptions occur at different 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 classified 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 19 Workflow idiosyncratic. The last type of exceptions is evolutionary exceptions that require changes in the organisational workflow model. Exception Type Noise Idiosyncratic exceptions Change in Workflow Model None Changes to specific instance of workflow, but the workflow type (the general model) remains the same Evolution of general workflow model, affecting future instances of work process as well Evolutionary exceptions Table 3.1: Relationship between types of workflow exceptions and changes to the workflow 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 inflict on the workflow model. 3.4.2 Handling Exceptions If we want to avoid unexpected exceptions stoping our workflow 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 evolution and optimisation of the process model. We will only cover the two first suggestions since the third handles evolutionary exceptions. Tolerating Minor Deviations Minor or insignificant deviations to the workflow process, or noise, can safely be ignored and a workflow system should be able to safely detect and ignore them. Handling Changes to the Process Instance Exceptions with larger impact on the workflow process traditionally involve a stop in the process execution, and manual interaction by one or more workflow participant before the workflow process can be started again. This can be avoided by letting the workflow process instance be adaptive or ad-hoc. We will in the next section describe what an adaptive or ad-hoc workflow process is. 20 3.4 Adaptive Workflow and Exception Handling 3.4.3 Adaptive Workflow Cardoso et al. [12] classify the different 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 executed 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 workflow, while with incremental changes, the entire change cannot be executed without introducing inconsistency. Composite changes are sequences of primitive changes. Atluri and Chun [5] define three types of dynamic changes: • Profile 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 workflow is a workflow able to adapt to exceptions and external changes and input. External changes and input can be profile change, rule change, or other context sources (see chapter 4). An adaptation can result in restructuring the workflow, either by inserting, deleting, redoing, or undoing activities. Methods for supporting adaptive workflow include: Late binding Defer binding of objects to the workflow process instance to the last moment. This results in a separation of an object’s data from its behaviour. On-the-fly workflow composition The definition of the workflow is not completed until run-time. This results in a very flexible workflow. Partial execution to be executed. Makes it possible for fragments of a workflow process Reusable process fragments and component libraries Fragments, stubs, or templates for work processes or tasks are stored in a database either on the workflow client, distributed, or on a centralised server. Atluri and Chun [5] introduce the notion of self-describing workflows and workflow management system stubs. “Self-describing workflows are partitions of a workflow that carry sufficient information to be managed by a local task execution 21 Workflow agent, rather than a central workflow management system. A workflow management system stub is a light-weight component that can be attached to a task execution agent, which is responsible for receiving the self-describing workflow, modifying it and re-sending it to the next task execution agent.” Workflow templates are pre-planned workflow processes that are general enough to encompass several similar work processes. They can be instantiated by adding contextual data, other templates, or workflow fragments. A fragment is equal to a workflow stub. 3.5 Workflow Modelling We will use UML state chart diagrams, and UML activity diagrams to model our workflows as suggested by Nødtvedt and Nguyen [47]. These modelling languages are also supported by the WfMC. 3.6 Summary Workflow is a mature technology that is well defined 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 field of adaptive, ad-hoc, and mobile workflow systems. For our own work, the WfMC’s reference model will be very useful, especially the Interface 1 meta-model and XPDL. Adaptive workflow theory will also have an impact on our work. 22 Chapter 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 development 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 figure presents the dimensions on making the computer invisible. Lyytinen proposes the main challenge in relation to ubiquitous computing to be the integration of large scale mobility with the pervasive computing functionality. 23 Context-Aware Computer Systems Today, computers make very limited use of input when executing, and applications 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 offer a wide range of new services to its users. This chapter will refer to definitions of important terms related to context-awareness. It will also provide the reader with insights in some of the challenges and benefits concerning the development of context-aware applications. 4.1 Context and Context-Classifications Before we refer to definitions of the term context-aware, we will briefly examine definitions of context and types of context relevant to the application designer. A good understanding of context will help application designers to better utilise the possibilities of offering useful services and context-aware behaviour in applications. By improving the computers ability to access context, we can improve the human-computer interaction through new contextaware features in applications. Relevant literature provides us with several definitions of context. Some authors provide examples to define context, while others use synonyms like the environment or situation of an entity. Dey and Abowd [20] believe these definitions are too specific, and that context is about the whole situation relevant to the applications and its set of users. They propose the following definition 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 definition allows context to consist of both implicit and explicit information. 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 developers can automate the collection and interpretation of relevant information. The definition 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 difficult for designers of context-aware applications to list the set of contextual states that may exist, what information that can accurately determine a contextual 24 4.1 Context and Context-Classifications state, and what appropriate action should be taken from a particular state. He acknowledges the usefulness of Deys definitions and supporting framework, 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 workflow system. For our purpose, we need to extend the definition 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 specific notion of context: the activity itself is the context. What takes place in an activity system composed of object, actions, and operation, is the context. Context is constituted through the enactment of an activity involving 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 environment based on clients sensing their physical environment, and reacting to the sensed information according to a set of rules. As part of this model, definitions of context and context-awareness are provided. A definition 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 definition focuses on coordination of sentient objects, operating without the need for an infrastructure. Dey [20] defines 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 contextual information about an entity therefore acts as indices for the retrieval of secondary contextual information about the same entity. 25 Context-Aware Computer Systems 4.2 Context-Sensing and Infrastructure The focus of context-sensing research has in the last decade been on locationsensing, and applications are being made possible with the deployment of location-sensing technologies. Hazas [26] states that the widespread deployment of sensing technologies will make location-aware applications part of everyday life in the near future. Researchers have developed several locationsensing systems (Chapter 7.3.2). Development of a context-aware workflow system needs sensor and contextsensing technology beyond technology commonly available today. Such systems 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 physical environment. In reference to this, design of mobile interactive systems introduces several tradeoffs which must be adressed to achieve acceptable performance. When realising mobile systems using context-sensitive devices, the interaction offered 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 variability, 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. Previous definitions 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 definition 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 definition of context-awareness. It includes both systems that are using, and systems that are adapting to context as context-aware. 26 4.4 Challenges in Context-Aware Computing In the sentient object model, context-aware is defined 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 fulfilment of its goals.” This definition is focusing on achieving coordination through the environment 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 previous 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 workflow systems, we need to emphasise on how these application features can provide benefits not only to a user, but also to other (workflow) 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] identifies several important challenges in the field of locationaware computing. First of all, mobile devices have limited resources. Compared to static devices, mobile devices are small and suffer 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 field 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 field of context-aware computing [57]: 1. How is context represented internally? 27 Context-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 different location-sensing technologies? 11. Under what circumstances should one be used in preference to another? 12. Should location information be treated just like any other context information, or should it be handled differently? These challenges are important topics for researchers interested in contextaware 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 workflow 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 applications. For this to happen, research in this field 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 information about a user’s context, it is possible to make several improvements 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-defined policies. 28 4.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 benefit from increased safety by using applications that incorporate contextual information. E.g. by monitoring pressure, temperature, and other contextual parameters, applications can take actions to prevent accidents from happening. Increased efficiency Context-aware applications have a potential of increasing efficiency when implemented as workflow systems in different settings. 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 related to these terms are important if we want to build systems with support for adaptive workflow. The use of implicitly sensed information allows the application’s behaviour to be customised to the user’s current situation. Definitions 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 definitions provided by Dey and Abowd are helpful, they are not satisfactory with regards to the requirements we state for adaptive workflow systems in Chapter 11. We focus on processes and activities as important contextual information for use in workflow enactment, rather than viewing the user and the interaction between users and applications as the main focus. We therefore emphasise on how application features should be available to other (workflow) services as well as to the users of the application. 29 Context-Aware Computer Systems 30 Chapter 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 workflow systems, achieving a more dynamic workflow. 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 artificial intelligence has created a large number of models for human behaviour. These models heavily rely on planning, and how humans use conscious plans to achieve the objective 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 depend 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 particularities of a given situation, and therefore recognise that actions are always situated into a context, and impossible to understand without that context. 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 philosophical framework for studying human work practices. 31 Activity 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 activity, 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 different artifacts Activity theory emphasise that human activities are mediated by tools as well as other artifacts. Activities are social within a culture culture they are a part of. Human activities depend on the 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]. Activity Action Operation Motive Goal Conditions Figure 5.1: Hierarchical levels of an activity [45] Activities are realised through goal-directed actions. Actions that are participating in activities have an immediate defined goal, and cannot be understood without reference to the corresponding activity. One activity may be realised through different 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 specific notion of context: the activity itself is the context. What takes place in an activity system composed of object, actions, and operation, is the context.” 32 5.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 affects 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 sion of labour. An activity is mediated by tools, rules, and divi- 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 different 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 modified 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 executions. 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 definition of a plan based on activity theory: 33 Activity Theory and Situated Actions “A cognitive or material artifact which supports the anticipatory reflection of future goals for actions, based on experience about recurrent structures in life.” Traditional workflow systems have difficulties supporting unexpected changes and deviations from the original process model. These difficulties can be understood within the planning paradox ; work is by nature ad-hoc and situated, but most organisations need predefined 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 actions emphasises the connection between plans and the contextual condition for realising these plans in actual work. An important distinction is the difference between a plan and the instantiation of a plan. Plans are resources, and independent of concrete, situated activities. An instantiation of a plan applies the plan to a concrete problem 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 deviations 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 predefined templates using situated actions is useful when developing contextaware workflow systems. 5.4 Summary When working with adaptive mobile work processes, plans are important, but not sufficient. 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 conceptualisation 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 benefits in relation to supporting contextaware work. Sørensen et al. [13] introduce the notion of smart work processes, which automatically adapt themselves based on reasoning on the 34 5.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 workflow client, or by the environment itself with an intelligent artifacts approach [63]. The potential benefits of situated planning are often related to increased safety and efficiency 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 representing work. Adams et al. [3] states how these activities are contextual, and their actions and operations are chosen contextually. 35 Activity Theory and Situated Actions 36 Chapter 6 Enabling Technologies In this chapter, we will present some important enabling technologies for realising 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 architectures 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 contextaware 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 identifies seven required features when developing a supporting framework for context-aware applications. These basic framework features are [19]: Context specification Application builders should be able to specify what context an application requires. This runtime mechanism will ensure 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 application semantics from low-level input handling details. 37 Enabling 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 acquire 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 discovery mechanism is responsible for finding relevant components, and provides the application with methods to access them. By addressing these features in a framework, Dey believe application developers are able to do faster and easier development of context-aware applications. 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 applications 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 separate 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 benefits [19]: • Separation of concerns by hiding complexity of the actual sensors used from the application. • Abstract context information to suit the expected needs of applications. • Provide easy access to context-data through querying and notification mechanisms available through a common, uniform interface. 38 6.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 notified 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 aggregation of context for entities in the environment. To prevent such an application from having to communicate with many Widgets, Context Aggregators support delivery of specified 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, context interpreters, context services, and resource discovery objects. When these components are instantiated, they register themselves with a Discoverer. 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 fired. For example, a callback may be fired 39 Enabling 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 Discoverers. 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 interpretation. Similar in functionality to Widgets, Aggregator allow the context they acquire 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 define 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 systems does not equip the designer with the tools to provide visibility and control of contextual information, which makes these systems prone to misinterpretation. 6.2 CORTEX CO-operating Real-time senTient objects: architecture and EXperimental evaluation (CORTEX) [67] is a research project and states its general objective 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 different sensors allowing them to sense the environment in which they operate before deciding how to react.” 40 6.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 components acting with a high degree of autonomy upon the environment via actuators based on input from sensors. The components have “intelligence” and cooperate via different 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 between 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 abstractions 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 defined 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 defined as [24]: “An entity which consumes software events, and reacts by attempting to change the state of the real world in some way via some hardware device.” 41 Enabling Technologies A sentient object is defined 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 Autonomy Perceive the state of the environment. Operate independently in a decentralised manner. Act in anticipation of future goals or problems. Proactiveness Since the sentient object model relies on event-based communication, it is not dependent on centralised control. Fitzpatrick [24] identifies three components necessary to achieve contextawareness 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 filtering and sensor fusion. Context representation deals with the representation of contextual information 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 developers. CORTEX [77] has designed and implemented a flexible middleware for building dependable sentient computing applications. This middleware addresses several important research challenges related to context-awareness, use of communication models, QoS management, and routing in mobile adhoc networks. 42 6.3 Mobile Wireless Networks To support a high level of configuration and reconfiguration, they have chosen to base their middleware on OpenCOM [15]. OpenCOM is a lightweight and efficient component model based on COM. Component Frameworks A Component Framework (CF) is targeted at a specific 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 notifications, and for event filtering. 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 cooperating vehicles has been developed [1]. This demonstrator is using instances of the middleware CFs. Since CORTEX middleware is based on the sentient object model, characteristics 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 technology 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 1 C Language Integrated Production System 43 Enabling Technologies use wireless communication all the time. Considering the relative low bandwidth, vulnerability to noise and interferences of all wireless connections, a fixed line may provide higher bandwidth at a lower cost. Sensor networks are a special type of mobile wireless networks and are covered 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 different 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 defined in the Context Toolkit may be used together to develop an architecture that supports adaptive mobile work processes. 44 Chapter 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 networks 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 actual sensing hardware, wireless connectivity, a small memory, a small CPU, and a small battery. When the sensors are deployed in their target environment they self-configure 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 sensors 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, 45 Sensors and Actuators and peer-to-peer communications into tiny embedded devices [27]. The basic mode of operation of wireless sensor networks is different 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 sacrifice some higher level functionality to make the sensor nodes as small and energy efficient 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. Algorithms 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, sensor 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. 46 7.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 temperature. 7.3.2 Context-Aware Sensors If we follow the definition 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 predefined 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 47 Sensors and Actuators some common methods for acquiring location. A geographical or locationaware sensor can be defined 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 specific 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 affect 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 positioning 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 combination 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 specified 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. 48 7.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 predefined 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. 49 Sensors 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 deployment 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 defining the geometric, dynamic, and observational characteristics of a sensor and is developed by the Open Geospatial Consortium [69]. The purpose of SensorML is to: 50 7.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 file is provided in Appendix B. 7.5 Actuators In the sentient object paradigm an actuator is defined 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 workflow 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 knowledge provided by other artifacts, and infer actions for the artifact to take. • Actuators Actuate the inferred actions. 51 Sensors and Actuators actuators actions shared knowledge inference rules domain s knowledge knowledge base observational knowledge shared knowledge observations perception measurements sensors Figure 7.4: Components of an intelligent artifact Domain knowledge Observational knowledge Inferred knowledge Domain knowledge built into the artifact, e.g. facts describing the physical nature of the artifact or general world knowledge. Knowledge describing the situation of an artifact in the known world. It is based on facts that result from sensor-based observation. Knowledge inferred from previously established facts, which may be based on domain knowledge, observation, previous inference, and knowledge made available by cooperation artifacts. Table 7.1: Knowledge stored in an intelligent artifact The knowledge base consists of facts and rules where facts are the foundation 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 enables 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. 52 7.7 Summary Inference rules Actuator rules Rules that describe inference of new facts from previously established facts. 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 technologies described above will be very useful in determining what a realistic application is. 53 Sensors and Actuators 54 Chapter 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 difficult questions related to contextaware systems. These aspects are at the same time crucial if we want to make people benefit 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 difficult to model. Bellotti [8] states that due to this, designers are not likely to successfully represent human and social aspects of context in a deterministic fashion. Machines cannot take actions autonomically 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 constrained conditions and well defined responsive behaviour. Context-aware systems are increasingly used in commercial applications. These applications are often restricted to sensing and responding to physical states and events. Real-life situations often involve a high degree of variability, where different outcomes depend on different conditions. Since it is hard to model outcomes in advance, allowing the system to take actions based on context may propose great risks when human participants are involved. Due to this, Bellotti argues that systems cannot execute autonomically based only on context-awareness, but must involve users in action outcomes. Bellotti proposes two key features to be supported in any contextaware infrastructure: intelligibility and accountability [8]: 55 Social 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 intelligibility and accountability within context-aware systems. 1. Inform the user of current contextual system capabilities and understandings. 2. Provide feedback: • Feedforward - What will happen if I do this? • Confirmation - 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] suffers 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 conflict 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. 56 8.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 technology with support for workflow enactment, providing coordination between workers and their activities. We acknowledge the many benefits 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. 57 Social Aspects 58 Chapter 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 domain, 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 different 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 flexible transaction management for shared, distributed resources [53]. 9.2 Adaptive Workflow System Cingil et al. [14] presents an architecture for adaptive workflow systems for electronic commerce applications on the Internet. The architecture describes how workflow templates can be instantiated, how they can be stored, and how they can be executed on different clients. While the architecture solves some of the problems with adaptive workflow systems, it does not take context-awareness and cooperation into account. 9.3 Cooperative Open Workflow Vantroys and Rouillard [70] have created a system for mobile learning processes called Cooperative Open Workflow (COW). It supports flexible workflows, work coordination between teachers and students, and user mobility. Mobility is achieved by using a central server for storing workflow documents, and transforming the documents to optimise the viewing experience on different terminals. 59 Related 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 systems. The architecture is based on separating the presentation from the program logic by using abstractions. The JBSA works as a mediator service, converting server response to something the client can support. By doing this, the client device does not need any modification to run the application. This can be useful when the devices are small, and does not allow modifications 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. 60 Part II Own Contribution 61 62 Chapter 10 Scenarios This chapter presents scenarios for possible applications of adaptive, contextaware workflow 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 proposed 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 maintenance 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 consuming 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. 63 Scenarios Information flow 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 efficiency, 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 maintenance application. The mobile terminal is typically a robust PDA with support for WLAN and Bluetooth for identifying equipment. 10.1.2 Workflow We have developed use cases and activity diagrams to increase understanding of the workflow related to this scenario. These models reflect 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 64 10.1 Maintenance Work on Oil Platforms terminal. When moving towards the gearbox, the mobile terminal notifies 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 specific 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 subprocesses 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 activity executes when worker is on site with a valid work order. The mobile terminal helps the worker locate the gearbox, and gives a notification 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 65 Scenarios typically involve checking temperature, pressure, power, current state etc. of a device. Checking for other workflow clients located in the same area is also important for an effective coordination of activities. Take Safety Measures 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 automatically displays the log for previous work done on the device. Display Safety Procedure is an activity that automatically shows important safety procedures 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 specific work-order, and locates the location for the gearbox and maintenance device. The work is done on device D2, which involves having power turned off and a low temperature on device D2. It also means having a high pressure in device 66 10.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 conflicting 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 conflict 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 conflicts needs to be handled by coordinating the activities. Such coordination relies on a set of rules, where safety is the first criteria, then cost. Each workflow client has a high degree of autonomy, and its own set of rules in order to enact workflows. 67 Scenarios 10.2 Electricians Performing Work Indoors Wang et al. [72] introduce a case study where electricians use PDAs 1 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 workflow system. Synchronisation with the office can occur in the office 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 office 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 finished the electrician fills 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 benefit from context-aware workflow 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 office via a mobile phone. Sørensen 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 finds historical information about the house to be visited, and the relevant information is presented in audio form when the electrician is driving to the actual address. 1 Personal Data Assistant 68 10.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 circuits, switch boxes and other information related to the electricity infrastructure in the house. All cables and other equipment are instrumented 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 equipment together with the already used effect 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 off the part of the electricity system affected by the installation. 12. The electrician informs the system that the work is finished. 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. Sørensen et al. [13] state that this is not a complete workflow 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 69 Scenarios the electrician by providing more safety in his work environment, and a more efficient way of performing this work. Safety aspects may be related to controlling power of devices in accordance to work order, while efficiency 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 benefit from using situated planning as proposed by Sørensen 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 environment 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 environments, 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 efficiency. Altering complex robotic welding systems to handle single patterns is expensive. By using cooperating, mobile robots, a reduced need for pre-planned activities leads to great savings in welding time. Possible benefits of introducing mobile, cooperating robots in shipyards are [74]: • Reduced risk of death or injury. 70 10.3 Shipyard • Savings in welding times. • Increased robotic welding accuracy. • Reduced rework rate. • Reduced construction time. These benefits relate to aspects of safety and efficiency. 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 independently, 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 collaboration. Intelligent, cooperative artifacts are able to asses their situation without the need of a separate infrastructure. The intelligent artifact approach relies on: embedded domain knowledge, perceptual intelligence, and rule-based inference. Strohbach [63] describes a set of components as an architecture 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 knowledge 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. 71 Scenarios 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 effected by actuators. Actuators for mobile robots may be different 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 Nødtvedt identified in their master thesis [47]. • Ad-hoc enactment of processes and activities. • Coordination of processes and activities. • Situated planning. • Workflow systems with processes integrating contextual information. In addition, Sørensen et al. [13] identifies 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 satisfied during process or activity execution. Coordination service A coordination service is necessary in order to coordinate workflow among different actors, possibly competing for resources. Such coordination should be possible, even when the different actors are disconnected from a central workflow enactment service. A decentralised approach to coordination of workflow may be necessary. Rules must be specified or developed To achieve adaptation of work processes to contextual conditions, rules must be specified and developed in order to define correct adaptation. Specific environments can have pre-defined activities or plans Predefined activities or plans may be put into the enactment when certain contextual conditions occur. These generic requirements will be further elaborated in the requirement specification in Chapter 11 and the architecture proposal in Chapter 12. 72 Chapter 11 Requirement Specification 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 respectively. 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 Nødtvedt and Ngyen [47]. Index F1 F2 F3 F4 F5 F6 Description Adhere to the WfMC standards and the Interface 1 specification in particular. Interpret and enact all process definitions defined in the XPDL. Evaluate workflow transitions defined in the XPDL. Update workflow relevant data based on completed activities from workflow participants that have updated such data. Perform enactment of concurrent processes that possibly competes for resources. Communicate with workflow clients to send and receive activities. Table 11.1: Functional requirements for a basic workflow system 11.2 Non Functional Requirements Our focus is on these quality requirements: 73 Requirement Specification Index F7 F8 F9 Description Context source abstraction for context sources to remove low-level input handling from the main application code (separation of concerns), and provide limited context interpretation. Service for discovering, and look-up of context sources. Support both polling and publish / subscribe mechanisms for context information retrieval from context sources. Table 11.2: Functional requirements for context information Index F10 F11 Description Context information should be used in the evaluation of workflow transitions. Lightweight process definition of context source look-up, polling and conversion of the context information between the context representation and the workflow representation. 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 F14 F15 Support re-validation of selected process paths, if the current path does not lead to the process goal. Support exception handling of undefined contextual states. Support for both pre-planned and unplanned process enactment by providing rule-based process building with learning. F12 Table 11.3: Functional requirements for the workflow enactment service Modifiability An adaptive context-aware workflow is by definition dynamic and hence must be configurable at run-time. Availability If a workflow process is adaptive, it should support handling of exceptions and deviations from the original plan. This means that the workflow 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. 74 11.3 COTS Components and other Technical Constraints Index F16 F17 F18 Description Perform situated planning based on current contextual conditions. Perform situated activity coordination between workflow participants. Context as post-condition for activities. (See also F12) Table 11.4: Functional requirements for client context-awareness Index F19 F20 F21 F22 F23 F24 F25 Description Support for physical mobility and network mobility. Handling of unreliable communication. Support for disconnected operations and asynchronous communication. Activity locking with support for reassignment of activities. Support for flexible task assignment. Support for session mobility. User should be able to select the data elements to be transferred to the mobile device. Table 11.5: Functional requirements for client mobility Stable connectivity Since our tests will be run inside a building without much interference, the connectivity should be stable. We will also make sure we do not “reinvent the wheel”. There is no point in trying to create components from scratch when there are available components, either commercial, free, or open source. 11.3 COTS Components and other Technical Constraints This section describes which COTS1 components we plan to use in our architecture. We only describe these COTS briefly since they are presented as part of our prestudy. 11.3.1 CORTEX Middleware As mentioned in chapter 6.2, CORTEX proposes a middleware implementing the sentient object paradigm. It consists of three modules that are all created using embedded visual C++ for PocketPC 2002: 1 Commercial Off the Shelf Software 75 Requirement Specification OpenCOM A Component Object Model (COM) that is built atop a subset of Microsoft’s COM. OpenCOM keeps its core aspects including the binary level interoperability standard, Microsoft’s Interface Definition Language (IDL), COM’s globally unique identifiers and the IUnknown interface. [1] Publish-subscribe CF This is a prototype of the STEAM P-S system [39]. STEAM is created for publish-subscribe communication over ad-hoc mobile networks. Context CF The Context CF consists of two parts: sensor capture and fusion, and an inference engine. The inference engine used is CLIPS and will be covered in section 11.3.2. 11.3.2 CLIPS The C Language Integration Production System (CLIPS) [54] is a tool for building expert systems and is widely used both in industry and academia. It provides a complete environment for building rule and/or object based expert systems. Some of its features are: knowledge representation, portability and extensibility. An important feature for us is that CLIPS can easily be integrated with C++. The CORTEX middleware should cover requirements F7 through F9, the lookup, polling, and conversion in F11, and F19 through 21. 11.3.3 Mobility and Context-Awareness Prototypes Nødtvedt and Nguyen have in their diploma [47] developed several workflow prototypes that incorporates contextual information caused by mobility. These prototypes are developed in Java, and our use of this work will be as partial design solutions with regards to our architecture proposal. While we cannot implement these prototypes directly, they will help us create solutions for most of the requirements. 11.3.4 The Context Toolkit The main characteristics of the Context Toolkit [19] are presented in chapter 4. We use some of the conceptual abstractions from this framework in our proposed architecture. These abstractions help us to better organise diverse contextual information. This is especially true for requirements F7, F8, and F9. 11.3.5 WfMC Reference Model The WfMC reference model Interface 1 defines a standard for interconnection between workflow systems. We should follow that standard as closely 76 11.4 Issues as possible. See Section 3.3.1 for more information. Requirements R1, R2, and R3. 11.3.6 MS Embedded Visual C++ The CORTEX middleware is implemented using C++. Our future implementation will therefore be based on MS Embedded Visual C++ (eVC++) [40]. HPs iPAQ support applications developed with eVC++, which provides us with a practical programming environment. 11.3.7 HP iPAQ Handheld Device Our workflow clients will be running on HP iPAQ devices. These devices support Wi-Fi and Bluetooth for wireless communication. A HP iPAQ device is shown in figure 11.1. Figure 11.1: The HP iPAQ PDA 11.4 Issues P1 - Adherence to the WfMC reference model We try to fully adhere to the WfMC reference model. This makes it difficult to integrate context-awareness and the activity theory paradigm without modifying the model. P2 - Prototype written in Java Prototypes developed by Nødtvedt an Nguyen [47] are written in Java which makes it difficult for us to reuse code since CORTEX is implemented in C++. 77 Requirement Specification 78 Chapter 12 Architecture Proposal This architecture proposal loosely follows the IEEE 1471-2000 standard [31]. 12.1 Introduction Our architecture proposal combines the CORTEX middleware with some of the Context Toolkit framework abstractions. The architecture supports the development of a workflow system with support for adaptive mobile workflows that incorporate contextual information. The architecture uses aspects of situated actions and activity theory to achieve situated planning. 12.2 Quality Tactics We will here present the tactics for achieving the quality goals of Chapter 11.2. Many of the traditional tactics to achieve a high rate of availability will of course apply to our architecture. Tactics like fault detection, recovery, and prevention are sound when considering how to prevent an application from coming into a non-runnable state (crash), but our problem is to find out how to handle exceptions and deviation on a higher level. We will therefore not elaborate on the standard tactics on availability, but instead introduce tactics that solve the problems associated with adaptive workflow. Availability and modifiability tactics will also converge somewhat since an available adaptive workflow system requires extensive run-time modification. The tactics we focus on are described below: • Workflow fragments Allow the workflow process to be run in fragments, and not require complete workflow process descriptions at startup. 79 Architecture Proposal • Workflow templates Templates include common tasks, required context sources, and actors. They must be instantiated before they can by run in a workflow process enactment service. • Decentralised workflow process enactment Every workflow client can do its own workflow process enactment, while being monitored by a distributed or central workflow enactment service. 12.3 Architectural Drivers We have chosen the following architecture drivers to be the main focus of our architecture: • AD1 - Decentralised workflow management Workflow clients provide local workflow enactment based on contextual information from the environment. This includes support for workflow templates and fragments (Chapter 3.4.3). Coordination of work can then also be performed decentralised, and should optimally include all actors capable of reporting their progress. • AD2 - Autonomous workflow clients All workflow clients can consume and react to events from the environment without relying on centralised control. • AD3 - Context source abstraction levels By using context source abstraction levels inspired by the Context Toolkit, the architecture can reduce the number of generated events from context sources and the number of possible process paths in the client workflow enactment service. • AD4 - Event based asynchronous communication The CORTEX Publish-Subscribe middleware supports event based asynchronous communication between workflow clients and the environment. This means it does not rely on the presence of any separate infrastructure, and can be used in an ad-hoc mobile network. 12.4 Stakeholders Since this is an academic research project, the number of stakeholders is rather limited. • Our self We will be implementing the architecture in our master thesis. (Developers and Acquirers) 80 12.5 Architecture Overview • MOWAHS May acquire the architecture and improve on it in the future. It is also conceivable that MOWAHS may use it as a proof-ofconcept, and as a test bench for new research. (Users and Maintainers) 12.5 Architecture Overview An overview of our architecture is presented in Figure 12.1. A high level description of each of the components in this figure is provided below. Actuator(s) Context Source(s) Sensor(s) Actuator Service(s) Context Service(s) User Client Mobile Worker Workflow Client Client Workflow Enactment Service Central Workflow Enactment Service Cooperating Workflow Enactment Service Figure 12.1: Architecture overview Mobile Worker The mobile worker using the system in his/hers work. Actuator An actuator is responsible for executing actuation commands received from an actuator service. Actuators may be physical devices, applications, or other workflow enactment services. Sensor A sensor is an electronic sensor, capable of sending sensor data digitally. It has a simple mechanism for marshalling SensorML data, in addition to support for broadcasting data periodically, or receiving poll requests from a context source. Sensors may vary from very simple, to smart and autonomous 81 Architecture Proposal entities. A sensor is always connected to one and only one context source. Other context sources wanting to use the sensor must connect through that context source. Context Source A context source can have one or more sensors, and provides an abstraction of the connected sensors. In addition, it can be connected to one or more context sources to provide an aggregation. It can provide low-level event filtering, i.e. simple rules and preferences, and a subscription facility. While it is possible to poll context sources, this should be avoided whenever possible. Context Service A context service manages context sources and provides contextual events to context clients according to their rules and preferences. Managing context sources includes the discovering of, filtering of, subscription to, and unsubscription from context sources. When a context service receives a contextual event from a context source it will filter it based on the context clients rules and preferences, provide reasoning on the context data, and convert it into something the context client can use. This may include the collection or aggregation of sensor data, sensor history, and/or abstraction of the data. The data can then be sent as raw data, or as process fragments, either created from templates or received directly from a context source, which the client can use in its process enactment. A context service can use one or more context services other than itself to discover and manage context sources by either subscribing to the context services as a context client, or by downloading the other context services’ lists of context sources. Context services can be realised as software run on a user client, or as physical devices in the work environment. Actuator Service An actuator service is responsible for lookup of actuators, validation of actuation orders, and initiating actuation orders in an environment. E.g. starting/stopping an engine, executing IT tools, sending messages, etc. Workflow Client The workflow client is a context-aware client enactment service, responsible for the monitoring and execution of activities based on the state of the currently running process or activity. This state is inferred by receiving contextual events from either context services, context sources, or the client workflow enactment service. The workflow client can also receive process fragments from a context service, the client workflow enactment service, or the central workflow service. Contextual events can be sent as process/activity states to the client workflow enactment service and the central workflow 82 12.5 Architecture Overview service. This may lead to the initiations of an actuation by sending an actuation order to an actuator service. A user interface should be provided for filling in and receiving information related to the activities. This information may also be collected automatically using a context service. Client Workflow Enactment Service The client workflow enactment service is a client-based cooperative workflow coordination service, responsible for the managing and coordination of activities in a multi-actor environment. Coordination is based on policies, which enables the workflow enactment service to send messages about coordination needs, competitive resources etc. to all involved parties. Relevant coordination can for the workflow enactment service be to send the state of the currently executing activity, and then possibly prepare other users for new activities to be started within a time limit. Other coordination messages may be communication with other users, including the need for artifacts, services, actuators, or a preferred environmental state. The client workflow enactment service can also send contextual events to workflow clients based on coordination reasoning. These events may include information about the need for artifacts, services, actuators, or an environmental state with priorities concerning demands of different kinds. The coordination of the client workflow enactment service may derive new process fragments which can be distributed to other clients based on their needs. These new process fragments are sent both to the relevant workflow clients and to the central workflow enactment service. When two or more client workflow enactment services execute in the same environment a Cooperating Workflow Enactment Service is created. This cooperating workflow service is a virtual and distributed workflow management system that manages conflicts, based on safety and business rules, and coordinates cooperative work. Central Workflow Enactment Service A central workflow enactment service is responsible for managing the complete, high-level workflow process for all the involved participants. This involves sending activities to users based on plans. Overview of Important Architectural Components Figure 12.2 shows an overview of the interaction between important architectural components. This is a simplified use case diagram and gives the reader an overview of the system’s actors and their responsibilities. The workflow client uses information from context sources in its local enactment of processes, and uses actuators to actuate results from this enactment. Retrieval of contextual information is done by using the context service, which manages context sources. Actuators are contacted by using the actuator ser83 Architecture Proposal vice, which is responsible for performing actuations inferred by the workflow client. The client workflow enactment service is responsible for enacting workflow by coordinating (receiving and sending) activities and processes with the central workflow enactment service and the cooperating workflow enactment service. The central workflow enactment service is responsible for sending and receiving activities based on plans, while the cooperating workflow enactment service is responsible for managing conflicts between workflow clients based on rules. Figure 12.2: Architecture actor interaction overview 12.6 Logical View In this section we present UML diagrams describing the main parts of our architecture. 12.6.1 Context Service Figure 12.3 shows the ContextService implementation and its dependencies. Context services are inspired by the sentient object model. ContextServi84 12.6 Logical View Figure 12.3: Class diagram describing a context service ceImpl implements, in addition to the ContextService interface, the ContextSource interface to make it possible for other context services to use ContextServiceImpl as a context source, and the ContextClient interfaces to make ContextServiceImpl a consumer of contextual events. The Discoverer interface and its DiscovererImpl implementation handles all discovery services for ContextService and is an interface to the CORTEX Context CF. Interpreter and its implementation InterpreterImpl is an interface to the CLIPS expert system, and Interpreter and its InterpreterImpl implementation manage the rules and preferences received from a client. 12.6.2 Actuator Service Figure 12.4 shows an actuator service. The actuator service implementation is similar to the context service. 12.6.3 Context Source The context source abstraction hierarchy is shown in Figure 12.5. A description of the interfaces follows: 85 Architecture Proposal Figure 12.4: Class diagram describing an actuator service • Source Source ensures a common polling protocol, and will be useful when we start implementing the architecture. • Sensor This is the interface for a simple sensor that can only be polled, and hence must be connected to a context source. • Actuator The Actuator interface provides access to an actuator. An actuator may have other actuators connected to it. • ContextSource A ContextSource is more “intelligent” than a Sensor and an Actuator. It has a CORTEX Publish-subscribe CF that provides a subscription facility and event filtering. A ContextSource can have one or more Sensor objects connected to it, and provides an abstraction of those sensors. • Aggregator An Aggregator is a special type of ContextSource that combines several context sources into one abstract context source. The context client will view this Aggregator as a single ContextSource. • ContextClient Classes implementing this interface will be able to 86 12.6 Logical View Figure 12.5: The context source abstraction hierarchy receive ContextEvent objects after a successful subscription to a ContextSource. • SensorEvent Provides a wrapper for sensor events sent from a Sensor object. The data contains SensorML markup. • ContextEvent Provides a wrapper for context events sent from a ContextSource object. • ActuationOrder Provides a wrapper for actuation orders sent to Actuator objects. 12.6.4 Workflow Client Figure 12.6 shows the WorkflowClient interface, its WorkflowClientImpl implementation, and its dependencies. The important interfaces are described 87 Architecture Proposal Figure 12.6: Logical view of the workflow client. in Chapter 12.5. 12.7 Physical View Figure 12.7 shows a deployment of the architecture where the Context Service node is a physical device separate from the UserClient node, and not running on the UserClient node as it could have been. A Workflow Client node can also connect to one or more Context Source nodes, but this is not shown in the figure to avoid crossing lines. 12.8 Process View The process view presents some of the dynamic aspects of our architecture. A state chart for the workflow client is presented in Figure 12.8. The workflow client first initiates its process description, which includes using contextual information to instantiate a process template. When the process description is initiated, the process keeps executing, and is only paused by receiving events. A received event may lead to modification of the process description, which means it has to be initiated again. A state chart showing states of a context service is presented in Figure 12.9. When the context service receives a look-up request, it spawns a discovery process which identifies context sources relevant to the request. When the 88 12.8 Process View Figure 12.7: Deployment of the architecture components context service receives a contextual event, an event handling process is spawned, which means the event is abstracted to be useful for the workflow client. An actuator service will use the same state chart, but the Handle event state will include checking if the actuation order is allowed to run, and executing it on an actuator if it is. A sequence diagram describing a context client requesting a context source is presented in Figure 12.10. The context client registers rules and preferences with the context service which makes the context service able to act on behalf of the context client. If the context client wants to look up an interesting context source, it contacts the context service which discovers and subscribes to the relevant context sources, and interprets and filters their events. A workflow client ordering an actuation is presented in Figure 12.11. The workflow client contacts an actuation service with an actuation order. The 89 Architecture Proposal Figure 12.8: Workflow client enactment of workflow process actuation service processes this order and sends it to the correct actuator which performs the actuation. In return, the workflow client receives an answer to whether the actuation order was performed successfully. 12.9 Scenarios A selection of relevant system scenarios are documented as use cases to help the understanding of important aspects of the architecture. Cooperation between Client Workflow Enactment Services The coordination of distributed workflow is handled by letting each workflow client have its own workflow enactment service, cooperating with other clients and their workflow enactment service in a decentralised manner. There may also be a centralised workflow server, but clients are often disconnected from this server, which make workflow enactment a matter of coordination through a cooperative workflow service. 1. The client workflow enactment service receives a process fragment. 2. The client workflow enactment service derives the need for coordination. 90 12.9 Scenarios Figure 12.9: States of the context service (a) If coordination is needed, update local process model and send coordination messages to other users by using the cooperating workflow service. (b) If coordination is not needed, update local process model. 3. The client workflow enactment service resumes enactment. Local Process Enactment performed by the Workflow Client The workflow client is context-aware, and performs workflow enactment based on the contextual state of the environment. When receiving events from context sources or other workflow clients via the context service, the workflow client decides if new activities need to be initiated in relation to these events. Changes have to be communicated to relevant actors. 1. The workflow client receives an event via the context service. 2. The workflow client derives the need for initiation of new activities. (a) If yes, the workflow client creates a new activity based on the contextual state of the environment and informs the client workflow enactment service by using the cooperating workflow service 91 Architecture Proposal Figure 12.10: A context client request a context source and/or central workflow service to communicate these changes to relevant actors. (b) If no, save event and update local process model. 3. The workflow client derives the need for actuations. (a) If yes, the workflow client uses the actuation service to actuate change, and informs the client workflow enactment service, which communicates this via the cooperating workflow service and/or the central workflow service. (b) If no, resume enactment. 4. The workflow client resumes enactment. The Workflow Client Monitors Events from Context Sources The workflow client subscribes to the context service, which look up context sources that the workflow client have interest in. The context service then 92 12.9 Scenarios Figure 12.11: A workflow client sends an actuation order subscribe to context sources on behalf of the workflow client. When a context source sends an event, the context service interprets it, and finds out if the event is relevant for the workflow client. If this is true, the context service converts the contextual event into something that is useful for the workflow client, and sends it as a new contextual event. The workflow client can now handle the contextual data in an appropriate manner. 1. The workflow client subscribes to a context service, and sends information about what it is interested in. 2. The context service look up context sources that the workflow client is interested in. 3. The context service subscribes to context sources on behalf of the workflow client. 4. The workflow client and the context service wait for contextual events. 5. A context source sends a contextual event to the context service. 6. The context service interprets the data from the contextual event and decides if it is interesting for the workflow client. 93 Architecture Proposal (a) The context event was not interesting, and is discarded. (b) Contextual event was interesting i. The context service interpret the contextual event data, and converts it into data useful for the workflow client. ii. The context service sends a new contextual event with the interpreted data to workflow client. iii. The Workflow client handles the contextual event. The Managing of Context Sources by a Context Service The context service receives requests for context source lookups. It then sends out a broadcast signal to find other context services that may have a list of context sources. If no such context service is found, or if they do not contain any interesting context sources, the context service sends out a broadcast signal that tells all reachable context sources that they should send information about themselves. The context service then filters out all context sources not interesting to the requester, and subscribes to the remaining context sources. If one or more context services were found, the context service will publish its presence on it / them. 1. The context service receives a request for a context source look up. 2. The context service sends out a broadcast signal to find other context services that may have a list of context sources. (a) If one or more context services were found, the context service downloads their list of context sources (b) If no context services were found, or the context services found did not have any interesting context sources, or their lists are old, the context service sends out a broadcast signal that tells all reachable context sources that they should send information about themselves to the context service. 3. The context service filters out context sources that are not interesting to the requester. 4. The context service subscribes to the context sources that remain after the filtering. 5. The context service publish itself on the other context services found. 6. The context service poll / listen to the context sources it has subscribed to. 94 12.10 Conclusion 12.10 Conclusion We have in our architecture created the basis for further development of an architecture for adaptive and mobile workflow systems. An abstraction of actuators, sensors, and context sources and their connection to context services have been defined. These abstractions are inspired by Dey [19]. The actuation service, context service, and workflow client are all using the sentient object model, and heavily rely on the CORTEX middleware [67]. Aspects of activity theory and situated planning have been implemented by using workflow process fragments and templates respectively. We have not elaborated the client workflow enactment service because of time constraints, and the fact that Nødtvedt and Ngyen [47] already have created an architecture we can implement with only minor modifications. Neither have we looked into the interaction between the client workflow enactment service and the central and cooperating workflow services. This was considered outside the scope of this work. 95 Architecture Proposal 96 Part III Discussion and Conclusion 97 98 Chapter 13 Evaluation This chapter will evaluate to what degree our architecture in Chapter 12 supports the requirements stated in Chapter 11. It will also provide a discussion on important aspects of our architecture and evaluate the research methods used during our work. 13.1 Evaluation of the Architecture Most of the requirements stated in Chapter 11 has been covered in the architecture. A short summary is provided below: F1 - F6 These requirements relate to basic workflow systems and are covered by the Client Workflow Enactment Service and its communication with the Cooperation Workflow Service and the Central Workflow Service. See Chapter 12.5 and Figure 12.1 for an overview of these services. F7 - F11 The context service and the context source abstraction hierarchy satisfy these requirements. F12 - F15, F18 The workflow client, as shown in Figure 12.1, supports the requirements in F12 and F15. It also supports F13, F14 and F18 but we have not provided any details on how this is achieved. F16 The workflow client can use workflow templates that can translate to situated planning. F17 By using the context service to detect changes in the environment, and sending activities and processes by using the cooperation workflow enactment service this requirement is supported. F19 - F21 These requirements relate to issues concerning communication and connectivity, and are supported by the CORTEX middleware. 99 Evaluation F22 This requirement is not properly addressed in the architecture. F23 This requirement deals with support for flexible task assignment which is the core of our architecture and is covered. F24 This requirement deals with support for session mobility. By using the central workflow enactment service to send workflow processes it should be possible to move a session from one device to another. F25 This requirement is supported by providing a user interface for the workflow client. The architecture is not complete, as we state in Chapter 14, but it is a good starting point for a more complete architecture that is ready for implementation. We believe the architecture is general enough to encompass a large number of implementation scenarios, while being specific enough that it will be possible to implement it. We believe the architecture and the literature study provides answers and solutions to our research questions stated in Chapter 2: RQ1 and RQ2 These research questions are addressed in our literature study of use of contextual information in computer systems (Chapter 4), and the context service and the context source abstraction levels in the architecture (Chapter 12). RQ3 Our literature study of activity theory and situated actions (Chapter 5) and adaptive workflow systems (Chapter 3.4.3) have provided us with an understanding on how building, altering, sharing, executing, and monitoring of plans can be implemented. RQ4 In chapter 7, we provide a survey of the state of autonomous wireless sensor technology. We have not delved deep into technical aspects, but have focused on how far this technology has come related to provide a pervasive environment, enabling the development of context-aware applications. 13.2 Evaluation of Research Method We used an engineering approach to research which involved several activities (Chapter 2). In this section we evaluate their usefulness in relation to our problem definition. Literature Survey 100 13.2 Evaluation of Research Method Our literature survey has provided us an understanding of context-awareness, sensor technology, situated planning, ubiquitous computing, and workflow. It has proven invaluable when discussing and creating the architecture. We attended the IFIP TC 8MOBIS conference in Oslo which provided us with the current state-of-the-art and research in the field of mobile information systems. Several of the proceedings have been used in our literature survey. Review of Existing Frameworks Our review of existing frameworks helped us identify possible partial solutions to our problem definition. In addition, we have used existing frameworks in the architecture. Scenario Analysis The elaboration of scenarios helped us define requirements for the architecture, and has provided us with at tool to identify problems and inconsistency within the requirements. Architecture Development The architecture development has helped us understand how we can combine different technologies and paradigms to create an adaptive mobile workflow system. A future implementation of this architecture will enable us to conduct testing of the functional requirements. 101 Evaluation 102 Chapter 14 Further Work Our work on this report is documented as proposal for an architecture for a workflow system that is adaptive to changes in the contextual environment. We will continue our work on this architecture by implementing it in our master thesis at NTNU. It is natural that our architecture will evolve during work on our master thesis, but we believe our work on this report is a good foundation for further design and development. We plan on deploying an implementation of our architecture in a lab setting by using laptops and PDAs as resources, simulating a pervasive computing environment. If we can test functional requirements by using relevant process descriptions, this may help our understanding of the usefulness of such an architecture. The architecture should also be evaluated against similar systems. The development of a decentralised, cooperating workflow enactment service by using the concept of virtual workflow servers needs to be further addressed. When workflow clients are disconnected from a centralised workflow service, they must rely on decentralised control by coordinating its workflow with other workflow clients. Issues concerning security are not elaborated in this report. Security will be an important aspect in an industry implementation of a workflow system with support for adaptive work processes, since there is a great danger for malicious attacks and misuse. 103 Further Work 104 Chapter 15 Conclusion This chapter provides conclusions and a summary of the findings in this report. Workflow (Chapter 3) is a mature technology, and standards for workflow process enactment and workflow system intercommunication are widespread. It is possible to use standard workflow technology in adaptive and contextaware work processes, although some changes to the standard must be made. No standard for using context in computer systems exists, but with the definitions given by Dey et al. [20] and others, a common understanding of what context and context-awareness in computer systems is, is possible (Chapter 4). The Context Toolkit (Chapter 6.1) created by Dey [19] also provides a good starting point for creating context-aware applications. And by combining context with activity theory as Nardi [43] suggests, an activity can be context. This provides us with a possibility for creating collaborative applications. Finally, by using aspects of activity theory and situated actions (Chapter 5), we have a framework for creating plans that can change over time, i.e. workflow templates that can be instantiated by using the contextual state of the environment. To be able to use the theories summarised above we need supporting technology. Wireless sensor technology (Chapter 7) has come to a state where it is possible to deploy a large number of autonomous sensor nodes in an environment that can benefit from such a deployment. The technology is on the other hand not mature and cheap enough to support the sensors like dust vision of Satyanarayanan [58] or the Weiser’s [73] vision of ubiquitous computing. Summary of the Architecture We used a “bottom up” approach in order to develop an architecture for a context-aware workflow system with support for adaptive, mobile work 105 Conclusion processes. An important part of this work was to identify COTS and existing frameworks, and how we could tailor them to suit parts of our problem description. Our chapter on enabling technologies (Chapter 6) describes these components. A workflow client acts in accordance to the sentient object model, and has to be able to operate independently in a decentralised manner. The CORTEX middleware supports a sentient object model by providing event-based asynchronous communication. In addition, abstractions in the Context Toolkit helped us provide a context source abstraction hierarchy. This reduces the generation of contextual events to workflow clients. The enactment of workflows is done at several levels in an architecture with support for adaptive mobile work processes, as presented in Figure 12.1. Each mobile worker uses a workflow client which can use the contextual state of the environment to instantiate workflow templates that support the mobile worker’s work processes. This is done by using one or more context services to reach relevant context sources and sensor data. A workflow client has, in addition, a client workflow enactment service which is responsible for managing and coordinating the workflow client’s activities and the activities’ relations to other actors in the environment. This includes sending and receiving coordination messages which may be process fragments, the contextual state of an activity, or other information relevant to coordination. When two or more workflow clients execute in the same environment, a cooperating workflow enactment service is created to manage conflicts based on safety and efficiency parameters. This coordination is done in a decentralised manner, which is important when workflow clients are disconnected from a central server. Finally, a central workflow enactment service manages the complete, high level process for all the involved participants. The central workflow enactment service coordinates work processes based on high level plans. 106 Glossary 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 workflow (automated) activity. A workflow activity requires human and/or machine resources(s) to support process execution; where human resource is required an activity is allocated to a workflow participant. [16] Activity instance The representation of an activity within a (single) enactment of a process, i.e. within a process instance. [16] Automated activity An activity which is capable of computer automation using a workflow management system to manage the activity during execution of the business process of which it forms a part. [16] 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 defining functional roles and relationships. [16] Invoked application An invoked application is a workflow application that is invoked by the workflow management system to automate an activity, fully or in part, or to support a workflow participant in processing a work item. [16] Manual activity An activity within a business process which is not capable of automation and hence lies outside the scope of a workflow management system. Such activities may be included within a process definition, for example to support modelling of the process, but do not form part of a resulting workflow. [16] Process definition The representation of a business process in a form which supports automated manipulation, such as modelling, or enactment by a workflow management system. The process definition consists of a network of activities and their relationships, criteria to 107 Conclusion indicate the start and termination of the process, and information about the individual activities, such as participants, associated IT applications and data, etc. [16] 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. [16] Sentient object Mobile, intelligent software component which is able to sense its environment via sensors and react to sensed information via actuators. Wapi WAPI is an abbreviation for Workflow APIs and Interchange Formats, published by the Workflow Management Coalition, and incorporating specifications to enable interoperability between different components of workflow management systems and applications WfMC Workflow Management Coalition Workflow 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. [16] Workflow management system A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. [16] Workflow participant A resource which performs the work represented by a workflow activity instance. This work is normally manifested as one or more work items assigned to the workflow participant via the work list. Work item The representation of the work to be processed (by a workflow participant) in the context of an activity within a process instance. [16] Work list A list of work items associated with a given workflow participant (or in some cases with a group of workflow participants who may share a common work list). The work list forms part of the interface between a workflow engine and the work list handler 108 Work list handler A software component that manages the interaction between the user (or group of users) and the work list maintained by a workflow engine. It enables work items to be passed from the workflow management system to users and notifications of completion or other work status conditions to be passed between the user and the workflow management system. XPDL XML Process definition language 109 Bibliography [1] Novel Component Middleware for Building Dependable Sentient Computing Applications, June 2004. European Conference on ObjectOriented Programming (ECOOP 2004). [2] ACM. Association for Computing Machinery http://www.portal.acm.org/, Accessed October 6th 2004. portal. [3] Michael Adams, David Edmond, and Arthur H.M. ter Hofstede. The application of activity theory to dynamic workflow adaptation issues. http://sky.fit.qut.edu.au/ adamsmj/The Application of Activity Theory to Dynamic Workflow Adaptation Issues.pdf. [4] Rob Allen, editor. Workflow: An Introduction, page 24 pages. WfMC, 2001. [5] Vijayalakshmi Atluri and Soon Ae Chun. Handling Dynamic Changes in Decentralized Workflow Execution Environments. pages 813–825, 2003. LNCS 2736. [6] Jakob E. Bardram. Plans as Situated Action: An Activity Theory Approach to Workflow Systems. In 5th European Conference on Computer Supported Cooperative Work, Lancaster University, UK, 7-11 September 1997. Kluwer Academic Publishers. [7] Len Bass, Paul Clements, and Rick Kazman. Software Architecture in Practice Second Edition. SEI Series in Sofware Engineering. Addison Wesley, 2003. [8] Victoria Bellotti and Keith Edwards. Intelligibility and Accountability: Human Considerations in Context-Aware Systems. Human-Computer Interaction (HCI) Journal. Special Issue: Context-Aware Computing, 16(2–4):193–212, 2001. [9] V. Bharghavan. Challenges and Solutions to Adaptive Computing and Seamless Mobility over Heterogeneous Wireless Networks. International Journal on Wireless Personal Communications, 1996. 110 BIBLIOGRAPHY [10] Gregory Biegel and Vinny Cahill. A Framework for Developing Mobile, Context-aware Applications. In Second IEEE International Conference on Pervasive Computing and Communications (PerCom’04), pages 361–365, Orlando, Florida, March 14-17 2004. IEEE Computer Society Press. [11] BlueTooth sig, Inc. BlueTooth – The Official BlueTooth Membership Site. https://www.bluetooth.org/, Accessed February 20th 2003. [12] Jorge Cardoso, Zongwei Luo, John Miller, Amit Sheth, and Krys Kochut. Survivability architecture for workflow management systems. In Proceedings of the 39th Annual ACM Southeast Conference (ACMSE’01), pages 207–216, 2001. [13] Carl-Fredrik Sørensen and Alf Inge Wang and Reidar Conradi. Support of Smart Work Processes in Context Rich Environments. To be published. [14] Ibrahim Cingil, Asuman Dogac, Nesime Tatbul, and Sena Arpinar. An Adaptable Workflow System Architecture on the Internet for Electronic Commerce Applications. In International Symposium on Distributed Objects and Applications, pages 242–251. IEEE CS Press, September 1999. [15] Michael Clarke, Gordon S. Blair, Geoff Coulson, and Nikolaos Parlavantzas. An Efficient Component Model for the Construction of Adaptive Middleware. In Proc. of IFIP/ACM Middleware 2001, Heidelberg, Germany, November 2001. IEEE CS Press. [16] The Workflow Management Coalition. Workflow Management Coalition - Terminology & Glossary. Technical report, The Workflow Management Coalition (WfMC), February 1999. Document Number WFMC-TC-1011. [17] Radionor Communications. Cordis http://www.radionor.no/Innhold/Cordis.htm, Accessed 18th 2004. RadioEye. November [18] David E. Culler and Wei Hong. Wireless sensor networks: Introduction. Communications of the ACM, 47(6):30–33, 2004. [19] Anind K. Dey. Providing Architectural Support for Building ContextAware Applications. PhD thesis, College of Computing, Georgia Institute of Technology, Atlanta, GA, USA, December 2000. [20] Anind K. Dey and Gregory D. Abowd. Towards a Better Understanding of Context and Context-Awareness. In Workshop on The What, Who, 111 BIBLIOGRAPHY Where, When, and How of Context-Awareness, as part of the 2000 Conference on Human Factors in Computing Systems (CHI 2000), The Hague, The Netherlands, April 2000. ACM Press. Also GVU Technical Report GIT-GVU-99-22. [21] Alan Dix, Tom Rodden, Nigel Davies, Jonathan Trevor, Adrian Friday, and Kevin Palfreyman. Exploiting Space and Location as a Design Framework for Interactive Mobile Systems. ACM Transactions on Computer-Human Interaction (TOCHI), 7(3):285–321, 2000. [22] Dralasoft. Workflow example. http://www.dralasoft.com/products /workflow/engine/details.html, Accessed October 6th 2004. [23] ePocket Solutions ASA. ePocket Solutions ASA. http://www.epocketsolutions.com/, Accessed November 12th 2004. [24] Adrian Fitzpatrick, Gregory Biegel, Siobh´n Clarke, and Vinny a Cahill. Towards a Sentient Object Model. In Workshop on Engineering Context-Aware Object Oriented Systems and Environments (ECOOSE), Seattle, WA, USA, November 2002. [25] Saul Greenberg. Context as a Dynamic Construct. Human-Computer Interaction (HCI) Journal. Special Issue: Context-Aware Computing, 16(2–4):257–268, 2001. [26] Mike Hazas, James Scott, and John Krumm. Location-Aware Computing Comes of Age. IEEE Computer, 37(2):95–97, February 2004. [27] Jason Hill, Mike Horton, Ralph Kling, and Lakshman Krishnamurthy. The Platforms Enabling Wireless Sensor Networks. Communications of the ACM, 47(6):41–46, 2004. [28] Ning Hu, Randy K. Smith, and Phillip G. Bradford. Security for fixed sensor networks. In Proceedings of the 42nd annual Southeast regional conference, pages 212–213. ACM Press, 2004. [29] IDI. IDI website. http://www.idi.ntnu.no, Accessed October 18th 2004. [30] IEEE. IEEE Xplore portal. http://ieeexplore.ieee.org/Xplore/DynWel.jsp, Accessed October 20th 2004. [31] IEEE Architecture Working Group. IEEE Recommended Practice for Architecural Description of Software-Intensive Systems. [32] Xiaodong Jiang and James A. Landay. Modeling Privacy Control in Context-Aware Systems. IEEE Pervasive Computing, 1(3):59–63, July– September 2002. 112 BIBLIOGRAPHY [33] Peter J. Kammer, Gregory Alan Bolcer, Richard N. Taylor, Arthur S. Hitomi, and Mark Bergman. Techniques for Supporting Dynamic and Adaptive Workflow. Computer Supported Cooperative Work, 9(3/4):269–292, 2000. [34] John Krogstie. MOBIS Home Page. http://www.idi.ntnu.no/ krogstie/MOBIS.htm, Accessed September 18th 2004. [35] Elaine Lawrence, Barbara Pernici, and John Krogstie, editors. A Multimodal context Aware Mobile Maintenance Terminal for Noisy Environments – Proc. IFIP TC8 Working Conference 2004 (MOBIS), Sintef, trondheim, Norway, September 2004. Springer-Verlag Berlin Heidelberg. IFIP TC8. [36] Paul Luff and Christian Heath. Mobility in Collaboration. In ACM 1998 Conference on Computer Supported Cooperative Work, pages 305–314, Seattle, Washington, United States, 1998. ACM Press. [37] Kalle Lyytinen and Youngjin Yoo. Issues and Challenges in Ubiquitous Computing. Communications of the ACM, 45(12):62–65, December 2002. [38] Rajeswari Malladi and Dharma P. Agrawal. Current and Future Applications of Mobile and Wireless Networks. Communications of the ACM, 45(10):144–146, October 2002. [39] Ren´ Meier and Vinny Cahill. Exploiting Proximity in Event-Based e Middleware for Collaborative Mobile Applications. In 4th IFIP International Conference on Distributed Applications and Interoperable Systems (DAIS’03), pages 285–296, Paris, France, 2003. Springer Verlag, Heidelberg, Germany. LNCS 2893. [40] Microsoft. MS Embedded Visual C++. http://msdn.microsoft.com/mobility /othertech/eVisualc/default.aspx, Accessed October 18th 2004. [41] MOWAHS. MObile Work Across Heterogeneous Systems. http://www.mowahs.com, 2004. Web: [42] Stefan M¨ ller-Wilken, Frank Wienberg, and Winfried Lamersdorf. On u Integrating Mobile Devices into a Workflow Management Scenario. In 11th International Workshop on Database and Expert Systems Applications (DEXA’00). IEEE CS Press, 2000. [43] Bonnie A. Nardi, editor. Activity Theory, pages 73–76. MIT Press, 1995. 113 BIBLIOGRAPHY [44] Bonnie A. Nardi, editor. Situated Action Models, pages 71–73. MIT Press, 1995. [45] Bonnie A. Nardi, editor. Studying Context: A Comparinson of Activity Theory, Situated Action Model, and Distributed Cognition, pages 69– 102. MIT Press, 1995. [46] NTNU. NTNU website. http://www.ntnu.no, Accessed October 18th 2004. [47] Jon Ole Nødtvedt and Man Hoang Nguyen. Mobility and contextawareness in workflow systems. Technical report, 2004. [48] Cover Pages. Coverpages: Asynchronous Transactions and Web Services. http://xml.coverpages.org/async.html, Accessed November 1st 2004. [49] Sang Hyun Park, So Hee Won, Jong Bong Lee, and Sung Woo Kim. Smart home - digitally engineered domestic life. Personal Ubiquitous Comput., 7(3-4):189–196, 2003. [50] Cynthia A. Patterson, Richard R. Muntz, and Cherri M. Pancake. Challenges in Location-Aware Computing. IEEE Pervasive Computing, 2(2):80–89, April–June 2003. [51] Charles Plesums, editor. WfMC, 2002. Introduction to Workflow, pages 19–38. [52] CAGIS project. Cooperative agents in global information space webpage. http://www.idi.ntnu.no/∼cagis, 2000. [53] Heri Ramampiaro, Terje Brasethvik, and Alf Inge Wang. Supporting Distributed Cooperative Work in CAGIS. In 4th IASTED International Conference on Software Engineering and Applications (SEA’2000), 6-9 November 2000. [54] Gary Riley. CLIPS – A Tool for Building Expert Systems. http://www.ghg.net/clips/CLIPS.html, 2003. [55] Kay R¨mer, Oliver Kasten, and Friedemann Mattern. Middleware o Challenges for Wireless Sensor Networks. ACM SIGMOBILE Mobile Computing and Communications Review, 6(4):59–61, 2002. [56] M. Satyanarayanan. Pervasive Computing: Vision and Challenges. IEEE Personal Communications, 8(4):10–17, August 2001. [57] M. Satyanarayanan. Challenges in Implementing a Context-Aware System. IEEE Pervasive Computing, 1(3):2–2, July-September 2002. 114 BIBLIOGRAPHY [58] M. Satyanarayanan. Of Smart Dust and Brilliant Rocks. IEEE Pervasive Computing, 2(4):2–4, October-December 2003. [59] M. Satyanarayanan. Privacy: The Achilles Heel of Pervasive Computing? IEEE Pervasive Computing, 2(1):2–3, January-March 2003. [60] Cite Seer. Cite Seer portal. http://citeseer.ist.psu.edu/, Accessed October 20th 2004. [61] Sonitor. Sonitor Home Page. September 20th 2004. http://www.sonitor.com/, Accessed [62] Springer. Springer portal. http://springerlink.metapress.com/, Accessed October 6th 2004. [63] Martin Strohbach, Hans Gellersen, Gerd Kortuem, and Christian Kray. Intelligent Artefacts: An Embedded Systems Approach for Cooperative Assessment of Situations in the World. In The Sixth International Conference on Ubiquitous Computing (Ubicomp 2004), Nottingham, England, September 7-10 2004. [64] The IEEE Working Group for WLAN Standards. IEEE 802.11 Wireless Local Area Networks. http://grouper.ieee.org/groups/802/11/, 2002. [65] The Workflow Management Coalition. Workflow Process Definition Interface – XML Process Definition Language, 2002. [66] The Workflow Management Coalition. http://www.wfmc.org, 2003. Welcome to WFMC. [67] Universidade de Lisboa, Lancaster University, Trinity College Dublin and Universit¨t Ulm. a CORTEX project homepage. http://cortex.di.fc.ul.pt, 2001. [68] Earth System Science Center University of Alabama in Huntsville. Sensor Modeling Language (SensorML). http://vast.uah.edu/SpaceTimeToolkit, Accessed November 3rd 2004. [69] Earth System Science Center University of Alabama in Huntsville. University of Alabama in Huntsville, Earth System Science Center Home Page. http://vast.nsstc.uah.edu/SensorML/, Accessed September 23th 2004. [70] Thomas Vantroys and Jos´ Rouillard. Workflow and Mobile Devices e in Open Distance Learning. In IEEE International Conference on Advanced Learning Technology (ICALT 2002), pages 123–127, Kazan, Tatarstan, Russia, 9-12 September 2002. IEEE. 115 BIBLIOGRAPHY [71] Upkar Varshney and Ron Vetter. Emerging Mobile and Wireless Networks. Communications of the ACM, 43(6):73–81, June 2000. [72] Alf Inge Wang, Carl-Fredrik Sørensen, Thale Christina Fritzner, and Eldrid Schei. Case Study: Use of the Mobile Tool HandyMan for Mobile Work. In M.H. Hamza, editor, IASTED International Conference on Software Engineering and Applications (SEA’2003), pages 757–762, Marina Del Rey, CA, USA, November 3-5 2003. [73] Mark Weiser. The Computer for the 21st Century. IEEE Pervasive Computing, 1(1):18–25, January-March 2002. Reprinted from Scientific American, 1991. [74] Wondermar. Shipyard scenario. http://www.wondermar.net/wondermard6 /viewscenario.phtml?scenarioid=42, Accessed October 18th 2004. [75] World Wide Web Consortium – W3C. Extensible Markup Language (XML). http://www.w3.org/XML/, 2002. [76] World Wide Web Consortium – W3C. The Simple Object Access Protocol (SOAP) Working Group. http://www.w3c.org/2000/xp/Group/, Accessed May 21th 2003. [77] Maomao Wu, Adrian Friday, Gordon Blair, Thirunavukkarasu Sivaharan, Paul Okanda, Hector Duran Limon, Carl-Fredrik Sørensen, Gregory Biegel, and Ren´ Meier. Novel Component Middleware for Builde ing Dependable Sentient Computing Applications. In Proceedings of the ECOOP’04 Workshop: Component-Oriented Approaches to ContextAware Systems, Oslo, Norway, June 14th 2004. [78] Marvin V. Zelkowitz and Dolores R. Wallace. Experimental Models for Validating Technology. Computer, 31(5):23–31, May 1998. 116 Part IV Appendix 117 118 Appendix A XPDL Example This example shows a modified example of a XPDL document [66]. Listing A.1: XPDL Example XML document 1 2 3 4 0.09 5 XYZ, Inc 6 6/18/2002 5:27:17 PM 7 8 9