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 → : .
更多
分享
引用
