This paper defines a new, context-driven programming model for pervasive spaces. Existing models are prone to conflict, as it is hard to predict the outcome of interleaved actions from different services, or even to detect that a particular device is receiving conflicting instructions. Nor is there an easy way to identify unsafe contexts and the emergency remedy actions, or for programmers and users to grasp the complete status of the space. The programming model proposed here resolves these problems by improving coordination by explicitly defining the behaviors via context, and providing enhanced safety guarantees as well as a real-time, at-a-glance snapshot of the space's status. We present this model by first revisiting the definitions of the three basic entities (sensors, actuators and users) and then deriving at the definition of the operational semantics of a pervasive space and its context. A scenario is provided to demonstrate both how programmers use this model as well as the advantages of the model over other approaches.

Establishing suitable programming models for pervasive spaces is essential in improving the productivity, enhancing the quality of pervasive systems, and creating an open platform for interoperability. Two different models, namely, the context-driven model and the service-oriented model, have been proposed and studied for their feasibilities as the foundation for implementing programmable pervasive spaces. We present these two alternatives and contrast their advantages and disadvantages.

As business transactions become more complex it is important that all participants obey the so called rules of engagement. These rules of engagement can be captured in an interaction protocol or choreography. A choreography provides rules on how various Web services act together, in terms of observable behavior. We investigate how we can extract a protocol from a program and verify whether or not the implementation adheres to the protocol. We derive an algorithm to verify whether a program is operationally compatible with a protocol, meaning the program does not violate the protocol. This guarantees that a program will be from anomalies such as dead lock or failure due to unexpected messages.

In this article we will propose a formal model for smart spaces. The key ingredients of this model are user, sensors and actuators. We show how we can derive a programming model based upon knowledge and software engineering. We describe how to interpret the world using an ontology and use this ontology to describe the intentional effect of available actuators. The model is loosely based on the beliefdesire-intention model and is a significant simplification of other context aware middleware architectures. We demonstrate how we can implement this model using OSGi.

of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy CONTEXT-DRIVEN PROGRAMMING MODEL FOR PERVASIVE SPACES By Erwin Jansen December 2005 Chair: Abdelsalam (Sumi) Helal Major Department: Computer and Information Science and Engineering Our aim was to establish a programming model that can be used by developers who build pervasive applications. Currently there is little to no support for programming pervasive spaces. Every solution is still an ad-hoc solution. Our programming model acknowledges a relationship among sensors, actuators, and software. By making this relationship explicit, we derived a programming model that is geared toward describing knowledge and defining goals. A goal can be accomplished by invoking a series of actuators. We divide the software-engineering process into two distinct phases. In one phase we are concerned with describing behavior. An engineer specifies how a service operates to achieve a particular goal. The other phase is the description of what the service tries to accomplish. It also allows us to reason beforehand about the effect of the invocation of a set of services. This in turn helps a developer determine whether two services intend to accomplish similar goals. This is similar to type-checking, which greatly reduces programming mistakes.

Research groups in both academia and industry have developed prototype systems to demonstrate the benefits of pervasive computing in various application domains. Unfortunately, many first-generation pervasive computing systems lack the ability to evolve as new technologies emerge or as an application domain matures. To address this limitation, the University of Florida's Mobile and Pervasive Computing Laboratory is developing programmable pervasive spaces in which a smart space exists as both a runtime environment and a software library. Service discovery and gateway protocols automatically integrate system components using generic middleware that maintains a service definition for each sensor and actuator in the space. The Gator Tech Smart House in Gainesville, Florida, is the culmination of more than five years of research in pervasive and mobile computing. The project's goal is to create assistive environments such as homes that can sense themselves and their residents and enact mappings between the physical world and remote monitoring and intervention services.

In the past few years the field of pervasive computing has expanded and infiltrated down to everyday consumer activities. Smartness of devices is constantly increasing. Smart products are widespread; not just limited to appliances and electronics. With the availability of such products, there becomes an increased need for a scalable smart environment. The need for real world modeling of such environments is becoming increasingly important. It is very useful to be able to discover the location of a certain device, reason about it, and finally be able to control it remotely. Such self-sensing and delegation of control is needed by many applications. In this paper, we discuss the idea of self-sensing spaces - spaces that can sense themselves in terms of locating and controlling its contents. In addition, we discuss the implementation of smart plugs; a novel way to locate and control smart devices within an real smart house.

Managing fast-growing personal Web information is a time-consuming, laborious task that affects people’s daily lives. A framework is highly desired that will allow people to collect and fuse personal information without dealing with complex emerging technologies. In this paper, we present our E-Service-Based Information Fusion Framework for end users. This framework enables end users to collect scattered information from diverse autonomous sources and to transparently create a repeatable process by which newer instances of the same information can be obtained in the future. By exploiting this framework, users do not need to repeat the manual information-gathering task over and over again. We present our framework and provide some implementation details.

ing sensory data The Smart House obtains information about the world through various sensors and can use this data to undertake certain actions. The typical home likewise relies on sensors to effect changes—for example, if it gets too cold, the thermostat will activate the heater. However, what distinguishes a truly robust context-aware system such as the Smart House is the ability to abstract state information and carry out actions that correspond to these highlevel descriptions.2,3 Most sensors are designed to detect a particular value in one domain. For example, a temperature sensor might determine that it is 95 degrees Fahrenheit in the house, or a light sensor might record 10,000 lux of light coming through the window. However, hard-coding behavior for each possible combination of direct sensor values is difficult to implement, debug, and extend. It is far easier to associate actions with abstractions such as “hot” and “sunny,” which encompass a range of temperature and luminescence values. When it is hot, the system turns on the air conditioning; if it is sunny outside and the television is on, the system closes the blinds to reduce glare. This approach can easily be extended to various contexts—for example, if the resident is on a diet, the system could prevent the smartwave from cooking a greasy pizza. Context management In addition to sensors, the Smart House consists of actuators—physical devices with which people can interact. An actuator can change the state of the world. Sensors, can, in turn, observe an actuator’s effect. For example, a light sensor might determine that the house or resident turned on a lamp. Based upon the observed state of the world, the house or resident might activate an actuator. Every actuator in the Smart House has a certain intentional effect on a domain, which a sensor that senses that particular domain can observe. For example, the intentional effect of turning on the heater is to increase the temperature. Given a clear description of an actuator’s intentional effect, it is possible to determine acceptable behaviors for a given context by examining all possible behaviors in the current state and identifying which intentional effects are mutually exclusive. This guarantees, for example, that the system will C F

ions: widgets, aggregators and interpreters. Context widgets encapsulate information about a single piece of context, aggregators combine a set of widgets together to provide higher level ``widgets,'' and interpreters interpret both of these. An interpreter, for example, can use the identity and location widget to derive that ``Sumi is in his office''. The aim of the toolkit is to hide the complexity of obtaining sensor information. Its value has been proven by several applications that have been built with it. iQueue [8] and iQL [7] are programming models and language for the composition of higher level data from low-level raw data. iQueue differs from iQL in that it is an implementation of the model in java, whereas iQL is a specific programming language resembling a functional language. The programming model is based upon composers that contain a current value computed from input values. These values in turn, stem from various data sources (i.e. sensors), or other composers. The runtime system then advertises these composers to external sources. Every source can either act passively, producing data only on request, or actively producing data whenever new data is available. Using these composers we can construct an acyclic di-graph, often referred to as a context graph, where the nodes contain functions that produce values for nodes higher up in the graph. The Solar framework is similar to the approach described above [4, 6, 3]. Solar allows resources to advertise context sensitive names and allows applications to make context-sensitive name queries. The main aim of this framework is that resources can advertise their existence, others can find the resources, and context-aware applications may indicate how to derive their desired context from these sources. Solar provides a similar mechanism as iQL for the derivation of high-level data from low level sources. Additionally, they provide a querying mechanism for retrieving context information. DFuse [12] is another example of a technology that allows the construction and evaluation of a context graph. The DFuse architecture is designed to optimize mobile device power consumption. In [10] an OSGi based context aware infrastructure is mentioned. This infrastructure is based upon the web ontology language [2]. Context is modeled by making use of ontology, and context providers that interpret sensory values, and produce an OWL representation of these values. Helal et el [15] proposed and implemented an OSGi based reference middleware architecture with a separate physical layer, sensor platform layer, context management, service and knowledge layer, and application layer. The separation of sensor platform and physical layers, with capability similar to plug-and-play, allows smart houses to automatically gather information about, and utilize sensors and actuators. Programmers are free from handling incoming and departing hardware and can focus on actual programming of the house by manipulating software bundles representing these physical entities. The programming model discussed in this paper is a further enhancement of the context management, service and knowledge layers referred in that reference architecture, while the IDE and middleware bundle are the realization of this architecture at the aforementioned layers. 3. Context Driven Model 3.1. Theoretical Background A smart house can be described to be in certain contexts at any given time. To simplify the discussion, let ∏ = j D U represents the current state of the smart space, with j D representing an observable domain of interest within. The adjective “observable” indicates that there is a sensor somewhere capable of observing that domain, whether or not it is inside the smart house. 3.1.1. Actuators. Let i a represent a single actuator, and the set A, where i A ai ∀ ∈ , , represent the collection of all actuators in the house. We further define A Aon ⊂ to be the set of actuators that are activated, and A Aoff ⊂ to be the set of actuators that are deactivated, and A A A off on = ∪ . We will denote activation of an actuator as i a ↑ and deactivation of the same actuator as i a ↓ , and these would be the only two possible actions. This setup further simplifies the model without losing generality, since scalar controls can be simulated with multiple binary actuators. The more complex actions can be represented by combining actions together to form a sequence of action such as 2 1 ; | | :: S S a a S i i ↑ =↓ . Let U A U G on → × : be the function that describes the behavior of the smart space. Note that although this function is unknown due to the ultra complexity of the real world, the contexts before and after the activation of on A , hence the effects of the activations can be observed through sensors. 3.1.2. Sensors. The sensors are modeled as a function that observe particular domains of the smart space and present the observation as readings, which can be expressed as i n i D U f → : .

Following the acceptance by the electorate of a cantonal inititative aimed at protecting these endangered areas (Auen-Schutzpark – für eine bedrohte Lebensgemeinschaft) optimal framework conditions were put into place in 1993 to protect the remaining floodplains in the canton of Argovia. The «floodplain protection park» programme was launched which addressed such issues as areas protection, restoration of remaining waterways, the realisation of re-naturalisation projects,as well as the creation and up-keep of a floodplain protection park. The first phase of the programme will be concluded at the end of 2003. An interim assessment, using Reusstal as an example, shows that most of the goals set out in the management mandate have been reached.

Rapid advancements in processor and networking technologies have led to the evolution of cluster and grid computing frameworks. These high-performance computing environments exploit geographically distributed, diverse resources with the goal of providing efficient computing solutions to all kinds of parallel and distributed applications. OCEAN (Open Computation Exchange and Arbitration Network) provides a scalable market-based infrastructure to such meta-computing frameworks. OCEAN aims to build a marketplace where resources like CPU time, associated memory usage and network bandwidth are the traded commodities. This paper explains the technical challenges faced in the design of OCEAN and discusses our proposed solution. To facilitate finding suitable resources for buyers, we developed efficient matching and evolution protocols for the peer-to-peer matching network. The architecture and various components of OCEAN are described in detail. We implemented OCEAN on Java and .NET platforms and describe results from our preliminary experiments.

In this short paper we shall give an outline how we constructed a lego robot that is capable of searching and retrieving white cans in an arena filled with obstacles. We'll point out that a behaviour based approach is the only feasible solution for the challenge that has been presented.