Gaia: An Operating System to Enable Active Spaces
Manuel Roman, Roy H. Campbell
{mroman1,rhc}@cs.uiuc.edu
Department of Computer Science.
University of Illinois at Urbana-Champaign
1304 West Springfield Avenue
Urbana, IL, 61801
Abstract
Ubiquitous computing promotes physical spaces with hundreds of specialized embedded devices that
increase our productivity, alleviate some specific everyday tasks and provide new ways of interacting
with the computational environment. With all these devices everywhere, personal computers lose the
focus of attention. The users’ view of the computational environment is finally extended beyond the
physical limits of the computer and placed into the physical space that surrounds the user. Applications
will be mapped not only to views associated to specific windows in a monitor but also to the physical
environment. Therefore, the physical space will become the computer system.
We claim that ubiquitous computing requires novel system software capable of seamlessly coordinating
the enormous hidden complexity. Our goal is to extend the model provided by current computer systems
to physical spaces, therefore turning them into “living entities” or Active Spaces.
1. Introduction
Ubiquitous computing promotes the proliferation of embedded devices specialized in specific tasks.
Devices will be everywhere: providing new functionality, enhancing user productivity and leveraging
everyday tasks. One of the main aspects of ubiquitous computing is invisibility. This means that users
perceive the functionality but not the devices that provide this functionality. Physical spaces, and not the
devices they contain, are identified as the providers of services.
We want users to take benefit of the functionality exported by the physical spaces. However this
task requires the definition of a model and a supporting software infrastructure to orchestrate the large
amount of devices contained in the space. Such a model provides a homogeneous interface that can be
customized to the particular requirements of each user.
There are several approaches that provide models for interacting with active spaces [1,2,9].
However, the solutions they provide are customized for particular scenarios or are targeted towards a
specific type of functionality. In this paper we describe a generic model that exports and coordinates the
resources contained in a physical space thereby defining a generic computational environment. The model
we present extends traditional operating systems. It manages heterogeneous computational resources and
exports them uniformly, facilitating the control of physical spaces and the development of arbitrary
applications that run in the context of a space.
The model we present in this paper is called Gaia and it is applied to convert physical spaces into
“living” or autonomous entities. The result of applying the Gaia model to a physical space is what we call
an active space, which is a general case of a computing system. It is important to note that Gaia does not
focus on particular applications or human computer interaction issues. Instead it provides the supporting
infrastructure to build applications. Without this proposed model, applications have to “reinvent the
wheel” to manage the physical space and the entities it contains.
2. Computer Systems and Active Spaces
In the introduction we have defined an active space as a generic computing system. This means that
traditional computing systems such as personal computers are particular cases of active spaces. In this
1
section we map the standard components defined for a traditional computing systems to their active space
counterparts. We assume a personal computer as an example of a standard computing system and an
active office as an example of an active space. We also assume that the active office contains some
personal computers and workstations, video cameras, an overhead projector, devices to detect the location
of users in the office and devices to configure the lights and temperature of the room.
Traditional computing systems can be divided into four components: hardware, operating system,
application programs and users [3]. The hardware component of a personal computer comprises one or
several processing units with their associated volatile memory, permanent storage and several peripherals.
The active office exports, at least, as many processing units as personal computers and workstations are
contained in the office. The active office coordinates all the existing processing units exporting them
uniformly by providing, for example, a multicomputer model composed of weakly coupled processors.
The active office also contains persistent storage. The total amount of persistent storage the active office
exports equals the sum of available persistent storage exported by each computing system contained in
the active office. However, the active office (and in general every active space) defines two types of
persistent storage: permanent persistent storage and temporary persistent storage. Before explaining the
difference between both types of persistent storage, we have to introduce the concept of home active
space. Every entity contained in an active space either belongs to the active space or is “visiting” the
active space. For an entity that belongs to the active space we say that the active space is its home. Every
single entity has at least one home active space. Home active spaces provide permanent persistent storage
to their associated entities, and temporary persistent storage to the “visiting” entities. Permanent persistent
storage stores data as long as required by particular entities. Temporary persistent storage keeps data only
for a specific amount of time. Upon reception of certain configurable events, the data stored in temporary
persistent storage associated to certain entities is flushed to the permanent persistent storage exported by
the home active spaces of those entities. Finally, and still dealing with hardware, come the peripherals. In
the case of the personal computer, there are standard protocols to interact with those peripherals. For
those peripherals attached to internal cards, some of the standards are: PCI, AGP and ISA. They define
the electrical signals required to enable interaction between the personal computer and the cards by means
of the internal bus. The active office also contains, coordinates and exports peripherals. The active office
defines a software bus to enable data distribution among peripherals. This is equivalent to the internal bus
contained in a personal computer. The software bus provides a well-defined protocol to enable
communication among entities contained in the active office. Examples of protocols for the software bus
are IIOP, DCOM and Java RMI. So far we have already introduced the hardware mapping from a
computing system (a personal computer) to an active space (an active office). Thereby we have a physical
space modeled as a computing system. However, it is not an active space yet. It is simply a physical space
with computational capabilities that can host software to control the resources exported by the physical
space. Most of the existing solutions stop at this point.
Initially computing systems did not have an operating system. Therefore, one of the many
problems was that each application had to implement the code to control the hardware devices it required
[3]. Modeling a physical space as a computing system without an operating system poses exactly the
same problems. We have a collection of uncoordinated hardware devices that each application has to
configure appropriately. However, this is not a major problem. Assume now that we have more than one
application running in the same space, or more than one user managing the resources exported by the
space. This is obviously a common situation that will arise in almost every active space. The solution is to
provide a generic software infrastructure to manage the resources contained in a physical space. In other
words, the physical space requires an operating system. This operating system converts the physical space
into an active space, or in other words, into a “living entity” aware of itself, with reactive behavior and
capable of interacting and coordinating the entities it contains.
The last two components of a computing system, Application Programs and Users, fit naturally
in the model presented. However, the traditional way of understanding applications and users changes
once the model is extended. In the context of active space, a user, from the point of view of an entity that
“uses” the operating system is not restricted to a person. It can be any entity in the active space. Consider
2
for example the case of an active car that checks its status continuously and takes specific actions
according to specific events. In this scenario there is no human interaction. Application programs benefit
from the new computational model we define because for their computational purposes they can use any
of the entities exported by the active space, included users. According to our new model users are
exported as resources of the active space.
An active space is thus a physical space with certain computational capabilities plus an operating
system that standardizes the mechanisms required to coordinate those computational capabilities. The
infrastructure we present, Gaia, enables active spaces and models them as generic computing systems.
Therefore it is possible to reuse most of the existing principles associated to standard computing systems.
3. Gaia
In the 1970s James Lovelock formulated and popularized the idea of the Earth - the collective
atmosphere, oceans, lithosphere, and biosphere - as a single, cybernetically self-functioning
superorganism, albeit one without self-consciousness. This global entity he called "Gaia", after the old
Greek Earth-Goddess.
The Gaia project conceives physical spaces as living entities. As such, spaces are aware of all
contained resources (physical and computational) and their status, export a contextual model and provide
a two-way interaction mechanism. Gaia is in fact an operating system that includes a kernel (GAUSS 2k),
an application support framework (GENOMA) and a model of the active space (GASM); these
components are depicted in figure 1. Gaia does not intend to define high-level policies or rules regarding
the behavior of the entities running in the space. It simply provides the tools and a minimum set of lowlevel policies on top of which arbitrary active spaces will be modeled.
Gaia is a distributed metaoperating system that runs on top of existing
native operating systems. Only a small fraction of Gaia has to be
implemented for each OS, while the rest of system services are offered
as CORBA services that can run in any processing unit exported by the
space.
GAUSS2k (GAia Ubiquitous Software System) is the Gaia
operating system kernel. It defines the comPonent mAnagement Core
(PAC) that is native OS dependent, specifies the distributed object
model and provides the core services required by the rest of
Figure 1. GAIA Architecture
components of Gaia. These services are implemented on top of the
distributed object model (CORBA in our case) and are native OS independent. GAUSS2k provides
infrastructure support such as dynamically instantiating and reconfiguring entities, managing inter-entity
dependencies and bootstrapping Gaia on top of native operating systems. It is also responsible for runtime
support tasks such as remote entity interaction, naming, entity notification and security.
GENOMA (Gaia ExecutioN envirOnment Model for Applications) is an extension of the traditional
Model-View-Controller [4] that is the central concept behind traditional multiwindowed interactive
interfaces. This model is a generalization that takes into account the fact that views are not only windows
but any collection of entities (physical or computational) capable of externalizing a model in the most
convenient way. For example, activating a microphone, switching on a set of lights and projecting and
image on a screen is one of the views associated to a videoconferencing model that uses the position of
the user inside the active space as the controller. An active space provides a collection of models (each
entity can be considered as a model) that need to be coordinated. Finally a controller is not only a mouse
or a keyboard but in general any entity contained in the space capable of altering the state of a model or a
view. Also related to the model-view-controller is the task of scheduling the active focus in an Active
Space, resolving conflicts when more than one view needs to be mapped to the same physical region and
delivering events produced by one or more controllers to the active view.
3
GASM (Gaia Active Space Model) is similar to the user-level layer in traditional operating
systems. It is similar in that it hosts the user-defined software running in the space but it provides a
software model of the active space managed by Gaia. In general we use the term entity to denote any
physical and computational object contained in the space. GASM does not enforce any particular
hierarchy of entities but provides mechanisms to manage them. Although the active space model is not
enforced, templates for common active spaces will be provided. GASM is responsible for tasks such as
entity location, user interaction, entity navigation, monitoring, discovery and in general any service
suitable for the particular active space. All the entities implemented at this level are simply built using the
functionality exported by Gaia. They are a clear example of high-level policies.
3.1 Gaia OS Kernel: GAUSS2k
GAUSS2k stands for GAia Ubiquitous System Software. The 2k exponent denotes that GAUSS is built on
2k technology [5]. Therefore, the main architectural aspects of Gaia are inherited from 2k. Briefly, 2k is a
component-based, reflective, adaptable and user-centric metaoperating system. It is based on the premise
“What You Need Is What You Get”
(WYNIWYG) that means that the system
Resource
dynamically reconfigures itself to provide the
Manager
exact functionality required by each particular
application.
QoS
GAUSS2k is a metaoperating componentSecurity
based kernel that runs on top of existing OSes. As
Object
depicted in figure 2, GAUSS2k is composed of two
central components, the PAC (comPonent
Component
mAnagement Core) and the Object Bus, and seven
Repository
PAC
peripheral services built on top of those two
Environment
central ones. The peripheral components are
Service
Bus
implemented according to the Object Bus
Automatic
specification and therefore are native OS
Configuration
independent. On the other hand, the central
Data
Service
components are native OS dependent.
Management
Service
Figure 2. GAUSS2k Architecture
he
PA
C defines the component model, which includes the specification of the execution environment for the
components (Component Containers), a software pattern to enforce and manage inter-component
dependencies [6] and finally an interface to dynamically manage those components, their dependencies
and their execution environments. One of the key design targets of PAC was to make it independent of
the Object Bus specification. For this reason the PAC is unaware of the distributed object model
associated with the components implemented on top of it. Even though we use CORBA, it is possible to
use the PAC with other specifications such as DCOM or Java RMI.
The PAC exports the tools to manage components and defines the low level mechanisms to
implement any Gaia component. However there is still missing a communication bus and its associated
communication protocol. This is the task of the Object Bus, which in our case is CORBA. We are
currently using two CORBA implementations: dynamicTAO [7] for PCs and workstations and LegORB
[8] for handheld and palm-size computers.
From the point of view of handheld, palm-size and in general any embedded device with
computational capabilities, the GAUSS2k architecture expands their functional capabilities. By
implementing the PAC and the Object Bus core (an ORB in our case) they can be integrated in the active
space and therefore have access to any of the exported services. If required, Gaia can dynamically adapt
some of the services to the capabilities of those devices.
4
T
We currently have implemented the PAC and the Object Bus for Windows, and are finishing the
Windows CE implementation. In the future we have plans to port the implementation to PalmOS and
probably also EPOCS.
4. Related Work
There are several projects related to digitally enhancing physical spaces. They provide solutions for
particular scenarios and specific types of applications.
The Microsoft Easy Living project [1] focuses on home and work environments and states that
computing must be as natural as lighting. The main properties of their environments are self-awareness,
casual access and extensibility.
HP is working on CoolTown [2], which proposes adding web presence to physical spaces. The
Web paradigm is extended to physical spaces, which contain infrared beacons that provide URLs related
to the physical space. The web browser is used as the standard application GUI and one of the key aspects
is the dynamic creation of customized web pages according to contextual parameters.
Finally Georgia Tech’s Classroom 2000 [9] preserves and augments electronic notes taken by
students and teachers by attaching and synchronizing audio, video and annotations to class notes.
5. Conclusion
Gaia offers a generic infrastructure to manage arbitrary physical spaces with large collections of
ubiquitous devices. The result is what we call an active space that allows developing applications without
a strict knowledge of the underlying infrastructure provided by the physical space. Gaia is responsible for
mapping those applications to the specific entities of the physical space. We have extended existing
concepts for traditional computing systems to model active spaces. We believe this strategy facilitates the
understanding of this new concept called active space. The generic computing system allows reusing
existing knowledge about traditional computing systems, such as for example theory about operating
systems and the model-view-controller.
When considering a traditional computing system and an active space, it is not correct to consider
the active space as a particular case of the traditional computing system. It has to be understood the other
way around. That is, a traditional computing system is a particular case of an active space. It can be
defined as a micro-active space.
Gaia extends the computational environment beyond the PC, but not only to rooms or buildings
but also to campuses, cities and in general any arbitrary physical space. Active spaces will not exist in
isolation but instead will interoperate among them to provide a distributed computational grid. Entities
will have an associated permanent execution environment independent of particular active spaces that will
be mapped and adapted to different active spaces as the entity moves from one active space to another.
References
[1] The new EasyLiving Project at Microsoft Research.
Steve Shafer, John Krumm, Barry Brumitt, Brian Meyers, Mary Czerwinski,
Daniel Robbins. Microsoft Research
[2] Creating a Web Representation for Places.
Deborah Caswell. Internet Systems and Applications Laboratory
[3] Operating System Concepts.
Silbershatz and Galvin. Addison Wesley, 1994
[4] Applications Programming in Smalltalk-80™: How to use Model-View-Controller.
Steve Burbeck
5
[5] 2k: A Reflective, Component-Based Operating Systems for rapidly changing
environments. F. Kon, A. Singhai, R.H. Campbell, D. Carvalho, R.Moore, and
F.J.Ballesteros. Proceedings of the ECOOP’98 Workshop on Reflective Object Oriented
Programming and Systems, Brussels, Belgium, July 1998.
[6] Dependence Management in Component-Based Distributed Systems.
Fabio Kon and Roy H. Campbell. in IEEE Concurrency, 8(1), February 2000
[7] Design and Implementation of Runtime Reflection in Communication Middleware: the
dynamicTAO Case. Manuel Román, Fabio Kon and Roy Campbell. ICDCS'99 Workshop on
Middleware. Austin, Texas. May 31 - June 5, 1999.
[8] LegORB and Ubiquitous CORBA. Manuel Roman, M. Dennis Mickunas, Fabio Kon and
Roy Campbell. RM200, Workshop on Reflective Middleware. New York, 7-8 April 2000.
[9] Classroom 2000: An experiment with the instrumentation of a living educational
environment. G. D. Abowd. IBM Systems Journal. Vol. 38, No 4 – Pervasive Computing
6