architecture of the context-aware systems. We conclude the paper in Section 5 with a review of our ongoing work.
Context-aware systems are notoriously heterogeneous in terms of device types, context interpretations, and adaptation requirements. We introduce a three-tiered formalism as a solution to this heterogeneity problem. Perception involves the objects perceived, the devices used for observing the objects, and the observational measurements. The objects and the devices are low level abstractions belonging to one tier. The observations of the device signals are converted to symbolic forms. We formally describe the structures composed from elementary symbolic representations using mathematical concepts. This description belongs to one tier, which links the low level abstraction to the high-level adaptation abstraction. Thus we end up with a three-tiered formalism. The architecture that we propose encapsulates the three tiers into two components, one of which deals with context construction and the other deals with context adaptation.
Tier 1 formalism is a description of “see, gather, control, and modify” features of perception abstractions. It describes the assembled symbolic representations of the observations and notifies Tier 2. Tier 2 receives the notification from Tier 1, and constructs contexts that reflect the current awareness. The formal basis of Tier 2 functionality is the context theory explained in [6]. Tier 2 uses the context calculus toolkit provided by the theory to construct general contexts, deconstruct and modify them. Tier 2 notifies current context information to Tier 3. Tier 3 receives current context from Tier 2 and determines the corrections to be made to the current awareness. The modified context information is given to Tier 1 through Tier 2. Figure 1(a) shows the three tiers and their formalisms. Below we give an overview of the formal notation used in the three tiers.
Tier2: Context Calculus
Context Adapter aware(context)
report_change(context)
Context Toolkit Symbolic information
Symbolic information Transformation
Sensing digitalinformation digitalinformation
Verifier3:
Verifier for
Adaptation Verifier2: Reasoning with
Context Verifier1: Verifier for Codesign
CC
E D Codesign
D2
D3
D1 sbuibnsduinmge CA delegate notifies receives T3
Context
S U
T2
T (a) Three-tier Formalism
(b) Architecture of Context-aware System
Tier 1 formalism is a description of “see, gather, control, and modify” features of perception abstractions. It describes the assembled symbolic representations of the observations and notifies Tier 2. In describing Tier 1, we consider the environment, sensing mechanism, and functional transformation of the observed raw data. The entities in the environment seen by Tier 1 include users, programmable parts, sensors, and actuators. We filter away the heterogeneity in the set of entities by encapsulating the behaviour of each entity separately as a Codesign Finite State Machine(CFSM) [1]. The CFSMs communicate asynchronously through message (event) passing. To ensure quality of service, the entire design will be optimally partitioned for software and hardware implementations. In this paper we do not discuss hardware/software partitioning issues.
Tier 2 discusses formalism based on set theory and relations for contexts. The context information is in general multidimensional, where in each dimension there exists several choices to be considered. As an example, a physical context for a braking device includes certain values (rotation per minute for wheels), situation (wheels locked or not), environmental conditions (friction on the road, gradient of road surface), and user characteristics (applying brakes or not). Here we have enumerated four dimensions. In each dimension, there are several possible ways to represent information. We say information in each dimension is tagged, and given the set of dimensions (dimension names), and a tag set for each dimension, then it is easy to see why the context should be defined as a of a finite union of relations. We define contexts as subsets of a union of relations which in turn characterize the possible worlds [6]. The rationale for the choice of formalism is that relational semantics provides a formal basis for supporting the representation and manipulation of different types of contexts that arise in context-aware applications. Contexts arising in both discrete and continuous interaction of entities can be casted as relations. Both descriptive and prescriptive context information can be modelled as relations. Although finiteness is not insisted, in our discussions we deal with contexts having a finite number of dimensions. Hence, both an enumeration syntax and a presentation syntax are used for context presentation. The context toolkit includes the mathematical definition and representation of contexts, context operators, and context expressions.
The adaptive control mechanism in Tier 3 is modelled by an Extended State Machine (ESM) model, which has been used to model real-time reactive systems [5]. At each state, the ESM may receive context information composed by T2, query the context database and/or compute a mathematical function, and output the results to CC. The state transition semantics is si ∧ e ∈ E(si) ∧ varg(si) ∧ cong(si) ∧ tc(t)
si −→e sj ∧ vara(sj) ∧ rtc(t)
where (
In this section we give a component model of the three tiers, following the terminology
and notation in [4]. A component type T = F, A defines a black-box view, called
frame F, and a grey-box view, called architecture A. The type T may include more
than one grey-box view. The black-box defines the interface types, and the particular
grey-box view A as a structured implemented version of F. An interface of a
component is an instance of either notifies-interface type or receives-interface type. The four
kinds of ties between the interfaces of two component instances A and B are as follows:
(
Following the above conventions we describe the architecture construction of a context-aware system. We encapsulate Tier 1 as a component CC, which constructs contexts out of the observables. Component CC is a composition of two components: component E modelling the environment and the primitive component T modelling the transformation unit that constructs elementary contexts from the observables in the environment. Component E is composed from component D modelling the collection of devices, the primitive component U modelling the user, and the primitive component S modelling the sensing mechanism, which is a central unit sensing all the information the system needs. The component D is composed from subcomponents Di, i = 1, . . . , k, where each component modelling one device is primitive. We compose the primitive component T2 corresponding to Tier 2 and the primitive component T3 corresponding to Tier 3. The resulting component CA is the context adapter. A context-aware system is a composition of CC and CA, as shown in Figure 1(b). 4
Case Study - Antilock Braking System (ABS) ABS is a typical example of a context-aware system, in which both situated and environmental information should become part of a context. Our design is more general and formal than the one suggested in [3].
CC
E Codesign
D DW1h.e14l
D21.24
Brake ABS has two types of devices, wheels and braking units. For simplicity, we only consider one wheel (D11) and one brake unit (D21) in the architecture. Environmental contexts such as the road friction and the current wheel speed are sensed by the Sensing mechanism S. They are converted into symbolic form by the transformer and passed as atomic contexts to T2. Applying the operations given by the context calculus toolkit, the atomic contexts are aggregated to a simple context c and passed as a parameter to T3 [6]. The architecture of ABS is shown in Figure 2[a]. The formal behavior model of context adaptation is shown in Figure 2[b]. 5
The main contribution of this paper is a formal approach for developing context-aware
systems. The significant aspects of the architecture are: (
Sensory devices produce signals that are converted to symbolic forms. Necessarily, this process is error-prone, and consequently not all context information will be accurately quantified. In order to guarantee that the design satisfies a desired property, the design methodology should be verification-driven. This aspect of verification-driven design and implementation of context-aware systems is an integral part of our ongoing research.