Software Architecture-based Adaptation
for Pervasive Systems
Shang-Wen Cheng, David Garlan, Bradley Schmerl, João Pedro Sousa,
Bridget Spitznagel, Peter Steenkiste, Ningning Hu
School of Computer Science
Carnegie Mellon University
5000 Forbes Ave
Pittsburgh PA 15213 USA
+1 412 268 5056
{zensoul,garlan,schmerl,jpsousa,sprite,prs,hnn}@cs.cmu.edu
Abstract. An important requirement for pervasive computing systems is the
ability to adapt at runtime to handle varying resources, user mobility, changing
user needs, and system faults. In this paper we describe an approach in which
dynamic adaptation is supported by the use of software architectural models to
monitor an application and guide dynamic changes to it. The use of externalized
models permits one to make reconfiguration decisions based on a global per-
spective of the running system, apply analytic models to determine correct re-
pair strategies, and gauge the effectiveness of repair through continuous system
monitoring. We illustrate the application of this idea to pervasive computing
systems, focusing on the need to adapt based on performance-related criteria
and models.
1. Introduction
An important requirement for pervasive computing systems is the ability to adapt
themselves at runtime to handle such things as user mobility, resource variability,
changing user needs, and system faults. In the past, systems that supported self-
adaptation were rare, confined mostly to domains like telecommunications switches
or deep space control software, where taking a system down for upgrades was not an
option, and where human intervention was not always feasible. However, in a perva-
sive computing world more and more systems have this requirement, because they
must continue to run with only minimal human oversight, and cope with variable
resources as a user moves from one environment to another (bandwidth, server avail-
ability, etc.), system faults (servers and networks going down, failure of external
components, etc.), and changing user priorities (high-fidelity video streams at one
moment, low fidelity at another, etc.).
Traditionally system self-repair has been handled within the application, and at the
code level. For example, applications typically use generic mechanisms such as ex-
ception handling or timeouts to trigger application-specific responses to an observed
fault or system anomaly. Such mechanisms have the attraction that they can trap an
error at the moment of detection, and are well-supported by modern programming
languages (e.g., Java exceptions) and runtime libraries (e.g., timeouts for RPC). How-
ever, they suffer from the problem that it can be difficult to determine the true source
of the problem, and hence the kind of remedial action required. Moreover, while they
can trap errors, they are not well-suited to recognizing “softer” system anomalies,
such as gradual degradation of performance over some communication path.
Recently several researchers have proposed an alternative approach in which sys-
tem models – and in particular, software architectural models – are maintained at
runtime and used as a basis for system reconfiguration and repair [25]. An architec-
tural model of a system is one in which the overall structure of a running system is
captured as a composition of coarse-grained interacting components [28]. As a basis
for self-repair the use of architectural models has a number of nice properties: An
architectural model can provide a global perspective on the system allowing one to
determine non-local changes to achieve some property. Architectural models can
make “integrity” constraints explicit, helping to ensure the validity of any change. By
“externalizing” the monitoring and adaptation of a system using architectural models,
it is possible to engineer adaptation mechanisms, infrastructure and policies inde-
pendent of any particular application, thereby reducing the cost and improving the
effectiveness of adding self-adaptation to new systems.
In this paper we illustrate how architecture-based adaptation can be applied to per-
vasive computing systems. Specifically, we show how to use the approach to support
adaptation of applications in a pervasive computing environment. This pervasive
environment consists of a set of mobile users accessing shared information through a
variety of devices. These devices communicate over a heterogeneous communications
infrastructure.
2. Overview of Approach
Our approach is based on the 3-layer view illustrated in Figure 1. The Runtime Layer
Task Model
Architectural
Model
Runtime
System
Model
API
Translator
Architecture
Manager
4
1
3
6
5
Monitoring
Mechanisms
2
Environment
& Runtime
Manager
Runtime
Layer
Model
Layer
Task
Manager
Task
Layer
Req’t
Feedback
Propagation
Task Model
Architectural
Model
Runtime
System
Model
API
Translator
Architecture
Manager
4
1
3
6
5
Monitoring
Mechanisms
2
Environment
& Runtime
Manager
Runtime
Layer
Model
Layer
Task
Manager
Task
Layer
Req’t
Feedback
Propagation
Fig. 1.AdaptationFramework
is responsible for observing a system’s runtime properties and performing low-level
operations to adapt the system. It consists of the system itself, together with its operat-
ing environment (networks, processors, I/O devices, communications links, etc.) (1).
Observed runtime information is propagated upwards using a monitoring infrastruc-
ture that condenses, filters, and abstracts those observations in order to render that
information in architecture-relevant terms (2).
The Model Layer is responsible for interpreting observed system behavior in terms
of higher-level, and more easily analyzed, properties. It forms the centerpiece of the
approach, consisting of one or more architectural models of the system (3), together
with respective architecture managers (4) that determine whether a system’s runtime
behavior is within the envelope of acceptable ranges. An architecture manager in-
cludes a constraint checker and a repair handler. The former determines when archi-
tectural constraints are violated; the latter determines how to adapt the system. Re-
pairs are propagated down to the running system (5).
The Task Layer is responsible for determining the quality of service requirements
for the task(s). A task is a high-level representation of a user’s computational needs,
and indicates the services required, as well as the desired performance profile for
those services. These profiles in turn determine the range of behavior permissible at
an architectural level.
To illustrate how the approach works, consider a set of mobile users interacting
with a pervasive environment, each user currently performing one or more tasks that
require access to shared information. We will assume that this shared information is
provided by a set of server groups distributed over a pervasive network, as illustrated
in Figure 2(a). Each server group consists of a set of replicated servers (Figure 2(b)),
and maintains a queue of requests, which are handled in FIFO order by the servers in
the server group. Individual servers send their results back directly to the requesting
user.
The pervasive computing environment that manages this overall infrastructure
needs to make sure that two inter-related system qualities are maintained. First, to
guarantee the quality of service for each user, the request-response latency for users
must be under a certain threshold, which may vary depending on the task and user.
Second, to keep costs down, the set of currently active servers should be kept to a
Component ServerGrp1
(ServerGrpRep)
Server1 Server2 Server3
User1 User2 User3 User4 User5
User6
ServerGrp1 ServerGrp2 ServerGrp3
Component ServerGrp1
(ServerGrpRep)
Server1 Server2 Server3
User1 User2 User3 User4 User5
User6
ServerGrp1 ServerGrp2 ServerGrp3
(a) (b)
Fig. 2. Deployment Architecture (a) and Software Architecture (b) of the Example System.
minimum, subject to the first constraint.
Achieving these goals requires cooperation from three levels. The Task Layer has
knowledge of the kind of information a user requires and the quality of service re-
quirements for retrieving this information. This knowledge feeds into the Model
Layer, so that relevant analyses can be performed to determine the appropriate con-
figurationwhenanewtaskiscreated.TheModel Layer then makes changes through
the Runtime Layer, to the executing system to fulfill those requirements.
Establishing the correct configuration for the system only when a task is created,
however, is not sufficient in a pervasive computing environment, since resources and
requirements change dynamically. For example, suppose that some user’s task re-
quires her to review a set of images and select some of them to be included in a re-
port. Suppose that initially this user is carrying out the task on a PDA, which commu-
nicates over a wireless network, and which can only display low-resolution grayscale
images. As the user moves through the environment, her PDA may move from a wire-
less cell that has an access point getting good bandwidth to a server group to a cell
that is not. In this case, the environment may need to locate another server group with
a better bandwidth and move her requests to that server group. This change of re-
sources should be sensed automatically and the reconfiguration done transparently, so
that the user is not unnecessarily distracted. Furthermore, this same user might later
move into a resource-rich environment that contains a high-resolution color display.
The task layer may then want to change the user’s bandwidth requirements so that she
can view larger images on this screen. These new bandwidth requirements may force
achangeintheModel Layer, which will invoke a concomitant change in the imple-
mentation.
The approach outlined above has a number of distinct advantages for the systems
builder over current approaches that hardwire adaptation mechanisms into the compo-
nents of the application. First, the use of architectural models permits non-local prop-
erties to be observed, and non-local adaptations to be effected. For example, suitable
monitoring mechanisms can keep track of aggregate average behavior of a set of
components. Second, formal architectural models permit the application of analytical
methods for deriving sound repair strategies. For example, a queuing-theoretic analy-
sis of performance can indicate possible points of adaptation for a performance-driven
application. Third, externalized adaptation (via architectural models) has several im-
portant engineering benefits: adaptation mechanisms can be more easily extended;
they can be studied and reasoned about independently of the monitored applications;
they can exploit shared monitoring and adaptation infrastructure.
3. Architecture-Based Adaptation
The centerpiece of our approach is the use of stylized architectural models [26,28].
Although there are many proposed modeling languages and representation schemes
for architectures, we adopt a simple scheme in which an architectural model is repre-
sented as a graph of interacting components. This is the core architectural representa-
tion scheme adopted by a number of architecture description languages, including
Acme [11], xADL [8], and SADL [23]. Nodes in the graph are termed components.
They represent the principal computational elements and data stores of the system:
clients, servers, databases, user interfaces, etc. Arcs are termed connectors, and repre-
sent the pathways of interaction between the components. A given connector may in
general be realized in a running system by a complex base of middleware and distrib-
uted systems support. For example, in the software architecture illustrated in Figure
2(b), the server group, servers, and users are components. The connector includes the
request queue and the network connections between users and servers.
To account for various behavioral properties of a system we allow elements in the
graph to be annotated with extensible property lists. Properties associated with a con-
nector might define its protocol of interaction, or performance attributes (e.g., delay,
bandwidth). Properties associated with a component might define its core functional-
ity, performance attributes (e.g., average time to process a request, load, etc.) or reli-
ability. In addition we associate with each architecture a set of constraints defined in a
first-order predicate logic augmented with a set of primitives appropriate for architec-
tural specification [22]. These constraints can be attached to components or connec-
tors to express things like the fact that some property value must always lie between a
given range of values.
In our system each architecture is identified with a particular architectural style. An
architectural style defines a set of types for components, connectors, interfaces, and
properties together with a set of rules that govern how elements of those types may be
composed. Requiring a system to conform to a style has many benefits, including
support for analysis, reuse, code generation, and system evolution [10,31,32]. More-
over, the notion of style often maps well to widely-used component integration infra-
structures (such as EJB, HLA, CORBA), which prescribe the kinds of components
allowed and the kinds of interactions that may take place between them.
One of the significant advantages of architectural descriptions is that they provide
opportunities for analysis, including system consistency checking [3], conformance to
architectural style constraints [1], conformance to quality attributes [7], and depend-
ence analysis [30].
We can model our example using a client-server architectural style. The architec-
tural style provides definitions for client, server, and server group components and the
connections between them. Properties include those required for queuing-theoretic
performance analysis, and integrity constraints include the necessity for each client to
be connected to one and only one server group.
As mentioned in our example, the Task Layer sets the performance profile for the
architecture. These profiles can be expressed as threshold constraints in the architec-
ture. These constraints can then be checked dynamically to see if the system is func-
tioning within bounds. In the context of our example, we desire each user to receive
no more than some maximum latency. This can be expressed in the architecture as a
constraint on each of the client’s connections to the server group. In the architecture
of our example, the constraint is of the form:
averageLatency < maxLatency.
This constraint appears on each client’s connection, and needs to be evaluated dy-
namically. In our approach, the Task Layer sets the value for maxLatency;theaver-
ageLatency value is an observed value determined by monitoring.
