Tool support for the design and management of context models

Abstract

A central task in the development of context-aware applications is the modeling and management of complex context information. In this paper, we present the NexusEditor, which can ease this task by providing a graphical user interface to design schemas for spatial and technical context models, interactively create queries, send them to a server and visualize the results. One main contribution is to show how schema awareness can improve such a tool: The NexusEditor dynamically parses the underlying data model and provides additional syntactic checks, semantic checks, and short-cuts based on the schema information. Furthermore, the tool helps to design new schema definitions based on the existing ones, which is crucial for an iterative and user-centric development of context-aware applications. Finally, it provides interfaces to existing information spaces and visualization tools for spatial data like GoogleEarth.

Introduction

In the domain of context-aware computing, applications need information about their user's situation to adapt their presentation, actions, or computation. Examples are location-based services [1], such as tourist guides [2], [3], indoor and outdoor information systems [4], [5] and smart environments [6], which present spatially selected information and services on mobile devices, often adapted to the user's current situations. Adaption based on context is also done in smart environments, where everyday things, enhanced with embedded sensors and computing power, interact with the inhabitants, e.g., in smart homes. Furthermore, adaption on technical layers can be done based on context information, e.g., dynamically switch to the best available wireless network within mobile communication services. To ease the development of context-aware applications, the management of context information should not be done within the application, but within so-called context models [7], which can also be shared between different applications to further decrease the development costs [8]. In general, context models may contain geographical data (e.g., maps), dynamic sensor data (e.g., the position of a moving object), infrastructure data (e.g., the extent and bandwidth of wireless networks), and context-referenced digital information (e.g., documents or web sites that are relevant in a certain context). In a broader sense, context models can additionally contain information on technical context such as available computing nodes or data processing operators and their properties.

We illustrate the general problem of context modeling using the application domain of Smart Factories. With the growing maturity of sensors, wireless communication, and distributed computing environments, pervasive computing enters new application domains. One promising example are production processes in so-called Smart Factories, where we can achieve huge improvements in transparency and efficiency. Here, pervasive computing not only improves usability or safety, but it really saves money. Different applications may run in a Smart Factory: some may measure the attrition of tools and initiate maintenance processes before critical situations occur [9], while others may track different resources and their state to reduce overstocking of resources [10], [11]. Another example could be the monitoring of the overall production process and its energy consumption to improve its overall efficiency. All these application have in common that they need context information about machines, workers, and other resources.

The creation of such context models is a tedious task. First, we have to model the context model schema, which specifies entities relevant for the application, like machines, tools, etc. Secondly, we have to provide the context model data, which represents the concrete instances of specified entities, like the location of the machines, or the state of the tools (e.g., attrition). The context model data can either be static, which means the data is entered once into the system and changed very seldom. Moreover, the data can be dynamic, which means it is sensed and inserted by sensors. Finally, the context of interest for the application (higher-level context) has often to be derived by rules or probabilistic learning approaches from other context model data (so-called lower level context). To reduce the burden of obtaining and maintaining such context models, it is beneficial to share the information between applications. The Nexus project¹ aims at providing shared context models in an open, federated environment: Autonomous data servers and sensors offer different local context models, which are federated into an integrated view over those context models for the applications (the Augmented World Model—AWM) [12]. For this, we developed a spatial query language (Augmented World Query Language—AWQL) following the query-response-paradigm and a serialization and modeling language (Augmented World Modeling Language—AWML), which are used as interchange formats both by applications and by platform components (see Section 4). AWQL is currently being supplemented by the Nexus Plan Graph Model (NPGM), which offers support for a larger number of different data processing operators and for data streams.

This paper is structured as follows: After a discussion of the requirements in Section 2 and the related work in Section 3, we shortly describe the Nexus platform and the Augmented World Model in Section 4, which serves as a central integration schema for the shared context models of applications. In Section 5, we illustrate the main features of the NexusEditor and how it can ease the development of context models, Section 6 describes how the NexusEditor can be used to model technical context relevant in the Nexus platform. Finally, Section 7 concludes the paper.