System Support for Smart Spaces

Introduction

On almost any computer, an operating system is required to build applications effectively. In the same way, it is necessary to consider system issues on their own to build smart spaces and pervasive applications. The main aim of ambient intelligence is to devise a unique computer, the smart space, out of the different subsystems in the space (computers, devices, sensors, and so on). In order to correctly achieve such purpose, pervasive services and applications must be provided with system support. Otherwise, we will come across the same pitfalls that were found while implementing applications in the old days, before the adoption of operating systems.

Unless you have appropriate system support for building a smart space, it is very likely that in the end any prototype built will be a mere collection of unrelated services instead of a reasonable and well integrated, operational, system.

The lack of system support leads to implementing the same services multiple times in different parts of the system. In addition, this increases the complexity of the environment and makes it unreliable.

In addition, without this support, it is very hard to add new devices to an already deployed system, because of poor modularity. A consequence is that a smart space may become obsolete quickly as new devices and services become available.

At the center of all this is the need for the system (or systems) used to provide appropriate abstractions for building and deploying services for smart spaces (and pervasive computing in general). For example, issues like naming, protection, and resource management can become almost trivial when proper system support is provided. In the absence of system support, these issues may become cumbersome or even impossible to overcome.

Figure 1 presents the top-level view of a smart space, considering it as a system. The key point is that the requirements necessary to build applications on the Smart Space are supported by a homogeneous system layer (which may be built upon an existing platform or not). Any particular list of requirements depends heavily on the particular set of applications considered. Therefore, enumerating such requirements is not feasible as far as our discussion goes. We will mention some of them as examples later, but a full discussion is outside of the scope of the present chapter.

Figure 1.

Top-level view for a Smart Space as a system

Exploding the previous diagram, we may identify the following components (depicted in figure 2):

Figure 2.

Components and services

• •

  Service Discovery: mechanisms to discover which application services are exported by the subsystems that form the Smart Space.

• •

  Naming: mapping methods for objects and services, so that the application can identify and access the resources.

• •

  Security: authentication and access control schemes for the resources.

• •

  Communication and synchronization: mechanisms for inter-application communication (similar to IPC, but not confined within a single system).

These components are more abstract services than actual components. Depending on the system built, they may be implemented by actual components matching those depicted in the figure or they may be implemented somewhere else. The next section presents several examples.