An increasingly important requirement for mobile and pervasive systems is the capability to adapt at runtime to a changing context; they must be context-aware. Much current work in this field focuses on application-specific solutions and ad-hoc approaches, and the lack of conceptual models for the design of context-aware systems hinders the development of more general and complex systems. In this paper we present a classification framework for the storage and retrieval of context, which supports the development of contextaware systems. We demonstrate the usefulness of the framework by modeling a number of context-aware systems.
Small networked devices like Personal Digital Assistants (PDAs) and mobile phones are rapidly becoming more common in every day living. They are cheaper, smaller, more powerful and more ubiquitous than before. The fast changing environment of these devices – combined with the increasing need for more intelligent and autonomous behavior – requires software that can adapt to changes in its environment. This is what we call context-aware systems: systems that can keep track of their context and change according to context changes.
The specific context of a system depends on its application domain. Schilit [
A controlled and simple way to implement system changes is to stop, update and restart the entire system. However, this is not always desirable or even possible. Multiple reasons for modifying a system while it remains running are: • Mobile: Access to a system may be restricted, for instance when systems are ‘in the field’. In this case systems cannot be updated through offline methods. • Critical: Mission-critical systems need to remain running; they cannot be stopped and restarted. • Extensible: Some systems are capable of integrating third-party software at runtime. This allows for functionality not available at release or startup time. An example is internet browsers that must integrate a plug-in to display a movie inpage. • Comfort: Changing a system without restarting does not block users, and therefore increases usability.
We define systems that change at runtime, i.e. without stopping, as dynamic systems.
To further increase usability, effort is focused on the ability of a system to selfdetect when and what to change, and to make this change autonomously. These selfadaptive systems measure the degree in which they satisfy their requirements runtime; the variation in these measurements is usually due to a changing context.
Based on the above, we conclude that automatic dynamic systems, i.e. systems that automatically change at runtime, need to be context-aware. Furthermore, the environment of mobile devices changes rapidly. Not only the environment of such a device itself changes, but mobile devices may also move out of the environment they were originally designed for, thus facing new environments. Dynamic, context-aware systems should be able to adapt runtime to these unforeseen context changes as well.
A software architecture provides a global perspective on the software system in
question. Architecture-based design of software systems provides major benefits [
The contribution of this paper is an architectural classification framework of the abstractions that designers can use for the development of context storage and retrieval in an application-independent fashion. The framework gives an overview and description of the different possibilities of context storage and retrieval, thereby providing designers with the possible choices and consequently simplifying design decisions. We show the usefulness of this framework with two cases in which we design context-aware systems.
The remainder of the paper is organized as follows. In the next section we present the classification framework for context storage and retrieval. Subsequently, we present the two cases, followed by related work. Finally, the paper is concluded.
The concept of context-awareness in systems can be divided into three separate
phases (see also Figure 1):
1. Monitoring of the environment
2. Interpretation of the monitoring data through the context model
3. Adaptation of the system to a changed context
Probes monitor the environment and output raw data. This monitoring data needs to
be interpreted before it has a meaning useful to the system; without this meaning the
monitoring data rarely holds the context information the system needs. The
interpretation is usually done through a context model, which translates the monitoring data into
context information. The context information is then used to reconfigure the system.
This division is common for most application-specific context-aware systems, for
example in GPS car navigation systems (e.g. Hertz [
Environment monitoring
We present a classification framework for the storage of the context model and the
retrieval of the context information from the context model. For the monitoring of the
environment an excellent framework is given by Dey [
The context model is used to add context meaning to the raw monitoring data, and is thus a necessary element for most context-aware systems. Several options exist for the storage of the context model.
Degree of distribution:
• Central: the context model is stored at one central location, e.g. as one database
as in [
An example is CoolAgent of HP [
Location relative to the system: • Extrinsic: the context model is stored at a different location than the system itself; it is a service for context information. This way, systems are dependent on the service to retrieve their context information. Many location-based contextaware systems use an extrinsic service, as, for instance, a traffic jam information service.
Such extrinsic context information services are useful when the context model is space-consuming and it is not possible to locate the context model within the system, for example in small, handheld devices. Extrinsic context model storage is also useful when the context model needs to be updated transactional and all the different devices must have access to the new context information at the same time. However, systems are dependent on the service for their context information, which introduces an extra reliability risk. • Intrinsic: the context model is stored inside the system itself. This is useful for small context models, if the context model is different for each system, or they may even be necessary if the systems cannot always reach a context service. An example of the latter may occur in a battle situation, in which it is likely that such a context service will at some point become unavailable due to attacks.
After the context model adds meaning to the raw monitoring data, the resulting context information is used by the system. Different aspects in the process of retrieving the context information from the context model are as follows:
Initiative: • Context-push: the system receives its context information without needing to send a request first every time it is needed. This is typical for, for instance, GPS car navigation systems. • Context-pull: the system explicitly requests the current context information, for example, through service requests when the context model is extrinsic, or via a function call when the context model is intrinsic.
Timing: • Event-driven: systems only get their context information when some event occurs. This is usually the case when context information is discrete. An example of this is a context change caused by a person walking into a different room, or a mobile phone moving into a different cell. A non-discrete example is of a running program that has the available system memory as its context. When a second program is started that uses a lot of system memory, less memory is available for the running program. This is the event on which it responds by using less memory-intensive, but slower, versions of its components. • Periodic: at certain scheduled points in time the context information is retrieved or received. This is suitable for continuous context information. History: • Absolute: context information is taken at absolute points; previous context information is not used. GPS navigation systems, for instance, only consider the current location. • Relative: the difference of the context information over time is important.
Therefore the context information history must be stored and must be possible to retrieve. This may be more space and time consuming.
Information presentation: • Explicit: The raw monitoring data is the context information; no context model is needed for interpretation. The raw data presented to the system explicitly states the context information and the system directly uses this data as-it-is. • Implicit: The system infers the context information from its input data by using a context model.
Not always every possible environment of a system can be foreseen at system development time. The environment of a route planner for example includes highways. When new highways are built after deployment of the route planner, the route planner does not show the shorter route that is now possible. These unforeseen changes can result in a context model that no longer interprets the monitoring data accurately. Different degrees of dynamic adaptation capabilities of a context model are: • Static: the context model never changes. This means that the same monitoring data always results in the same context information. • Updatable: it is possible to update the context model. • Dynamic: the environment changes over time, and the context model continuously adapts to these changes at runtime, i.e. it is dynamic. For instance, context models consisting of adaptive neural networks keep on learning during operation. Context
Context retrieval Context model storage Dynamism of context models
Degree of distribution Location relative to system Initiative Timing History Information presentation Static Updatable Dynamic
Central Distributed Extrinsic Intrinsic Context-push Context-pull Event-driven Periodic Absolute Relative Explicit Implicit
In this section we demonstrate how to use the classification framework presented above. We describe two cases of context-aware systems, and for each case we give the corresponding architecture in terms of the framework.
A local government wants to rent handheld devices with city maps to tourists, enabling tourists to find their way to the city’s tourist attractions. The handheld device contains a map of the city, an accurate location sensor, and a digital compass. The tourist simply selects the desired destination, and the handheld device displays directions to get there from wherever the tourist is located, keeping the directions accurate while the tourist is moving.
Furthermore, the city is expanding rapidly, attractions can be closed, walking routes blocked; this would all result in continuously inaccurate directions from the handheld devices. Therefore it would be desirable to update the handheld devices regularly.
The architecture of such a system is given in Figure 3. The system consists of a probe that continuously feeds sensor data to a route component. The route component contains a map component that holds the context model: the city map. The context information is a combination of the current location and the navigation instructions, and is continuously sent to the viewer component. Retrieval of the system’s context can therefore be classified as a periodic context-push. The viewer component displays the route on the display of the handheld device. The context model is stored only in the map component, which lies inside the system, making it a central and intrinsic context model. The context information results implicitly from the monitoring data, as the tourist’s current location and the route to the destination are based on the city map.
To update the context model, only the map component needs to be updated. The probe, the route calculating program and the viewer do not need to be changed. Explicitly locating the context model as the city map simplifies the updating process.
Viewer
System
Context information
Route
Probe
Monitoring
data Map
A museum offers its visitors small handheld devices that automatically display
information about the exhibits exposed in the room the visitor walks around in ([
The system architecture is shown in Figure 4. Each exhibit presents its information explicitly to the handheld device when the latter enters the room. The handheld devices emit a signal, and upon reception of this signal by the exhibit the context information is sent back. The information about the exhibits is directly displayed on the device by the viewer component.
The context information is stored externally: not in the handheld device, but with the exhibits. The context information is also distributed over the different exhibits, as each exhibit only contains information about itself. After a request for information (the signal from the device) the exhibits explicitly present their information; no context model is needed to interpret the exhibit information. Furthermore, this system performs a context-pull based on the event of entering a room. As the context information is explicitly presented by the exhibits, no context model is needed. Therefore nothing needs to be adapted when an exhibit is moved from one room to the other. When a visitor with a handheld enters the new room, the context information from the exhibit is automatically sent again.
System Viewer
context information Exhibit
Exhibit
Exhibit
In 1994 Schilit [
Pascoe [
Similarly, Dey [
Chen [
Sun [
However, most research on context-awareness has focused on creating reference
architectures for specific application domains. Examples of these architectures are the
Context Toolkit [
Context-awareness is a necessary feature of automatic dynamic systems that need to
adapt to context changes. Many current context-aware systems are
applicationspecific, and are often developed in an ad-hoc fashion. However, architectural
abstractions are needed to build large and complex context-aware systems, because not
explicitly modeling context-awareness can result in unnecessary complex
implementations. We divided the concept of context-awareness into three phases: 1)
environment monitoring, 2) interpretation of the monitoring data through the context model,
and 3) adaptation of the system to a changed context. Architectural abstractions exist
for the first and for the third phase, see for example Dey [
This research has been sponsored by ConIPF (Configuration in Industrial Product Families), under contract no. IST-2001-34438. The ConIPF project aims to define and validate methodologies for product derivation that are practicable in industrial applications.