System Support for Smart Spaces

System Support for Smart Spaces

Francisco J. Ballestero (Universidad Rey Juan Carlos, Spain), Enrique Soriano (Universidad Rey Juan Carlos, Spain) and Gorka Guardiola (Universidad Rey Juan Carlos, Spain)
DOI: 10.4018/978-1-61692-857-5.ch010
OnDemand PDF Download:
$37.50

Abstract

There are some important requirements to build effective smart spaces, like human aspects, sensing, activity recognition, context awareness, etc. However, all of them require adequate system support to build systems that work in practice. In this chapter, we discuss system level support services that are necessary to build working smart spaces. We also include a full discussion of system abstractions for pervasive computing taking in account naming, protection, modularity, communication, and programmability issues.
Chapter Preview
Top

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.

Key Terms in this Chapter

IPC: Inter-process communication. Mechanisms to permit communication among different processes on a system.

RPC: (Remote Procedure Call). Mechanism used to operate on remote services similar to a procedure call from the client perspective (would be equal to a procedure call if argument references and error handling is not considered).

Smart Space: Physical space enhanced with computer software enhancing the behavior of the space for particular users or activities.

ACL: (Access Control List). A mechanism to control access to operations on a resource. It lists which clients may perform which operations on a resource.

Adaptability: Capability of a system to change itself (or at least its behavior) in response to changes in the environment.

Process: Running program.

Synthetic File System: An interface to an entity looking like a file tree. Operations on the entity accessed through the interface happen upon reading, writing, creating, and/or removing files.

Middleware: Software layer in the middle of application and system software.

Complete Chapter List

Search this Book:
Reset