See discussions, stats, and author profiles for this publication at: [Link]

net/publication/3717837

Software organization for dynamic and adaptable wearable systems

Conference Paper · November 1997

DOI: 10.1109/ISWC.1997.629920 · Source: IEEE Xplore

CITATIONS READS
77 170

3 authors, including:

Gerd Kortuem
Delft University of Technology
166 PUBLICATIONS 5,629 CITATIONS

SEE PROFILE

All content following this page was uploaded by Gerd Kortuem on 03 June 2014.

The user has requested enhancement of the downloaded file.

 Software Organization for
Dynamic and Adaptable Wearable Systems

Stephen Fickas Gerd Kortuem Zary Segall

Computer Science Dept. Computer Science Dept. Computer Science Dept.
University of Oregon University of Oregon University of Oregon
Eugene, OR 97403 Eugene, OR 97403 Eugene, OR 97403
USA USA USA
fickas@[Link] kortuem@[Link] zs@[Link]

Abstract This has lead us to study a middleware layer for a

wearable system that supports dynamic reconfiguration.
There is a growing interest in a class of
systems having dynamic and adaptable 2. The Oregon Wearable Computer
properties. In this paper we discuss our work on
The University of Oregon wearable information system
one subclass of such systems, that of wearable
is a body-worn computer designed for tasks that require
computers. In particular, our interest is in the
hands-free operation. The computer is housed in a
software organization necessary to build
specially designed vest that accommodates the various
wearable computing systems. We will examine
batteries and input devices required. The central
some of the key properties of such a software
processing unit is fitted into a pouch in the small of the
organization such as the ability to rapidly and
back, and cables are run from the CPU out to the front
dynamically reconfigure software to meet both
pockets in the vest. These cables feed the batteries and
physical changes and information changes of the
input devices positioned in the front of the vest. The
wearable system. This has lead us to study a
weight of the batteries and accessories counters the weight
middleware layer for a wearable system that
of the CPU pouch on the back, providing a comfortable fit
supports dynamic reconfiguration. The
(Figure 1 and 2).
middleware approach is studied in the context of
the NETMAN - a network maintenance assistant. 2.1. Hardware Design
Current results from the system evaluations and
the final system requirements and open issues are The design philosophy followed in building the vest
presented. was centered around COTS, or commercial off the shelf
hardware. The COTS approach allowed us to purchase
the parts of our wearable computer through traditional
consumer outlets. The computer itself is a Texas
1. Introduction Instruments Pentium 75, Asentia motherboard. The video
Our group is interested in dynamic, adaptable systems. capture hardware is the inexpensive Snappy from Play
In this paper we discuss our work on one subclass of such Incorporated. A chorded keyboard (Twiddler) was
systems, that of wearable computers. For the past two purchased from Handykey, and the mouse is an Alps glide
years, faculty and students from the University of Oregon point. The monocular heads-up display is constructed
and CMU have worked jointly on the hardware and from a pair of Virtual-IO glasses with a resolution of
software to support a wearable computing environment. 180000 pixels. We choose to modify the V-IO glasses by
For the most part, the Oregon group has focused on the removing one of the eye pieces. This was done to provide
software environment necessary to build wearable an unobstructed and a more natural view for enhanced
computing systems. The remainder of the paper will reality. It was shown that a monocular view could more
describe what we have found to be a key property of the
software environment: the ability to rapidly and This research was supported in part by the National
Science Foundation (NFS) under grant MIP 9403573. The
dynamically reconfigure software to meet both physical
content of this paper does not necessarily reflect the position
changes and information changes of the wearable system. or policy of the NSF or University of Oregon.
 equipment such as routers; performing regularly
scheduled maintenance work; troubleshooting of network
faults; repair and replacement of faulty equipment.
Figure 1 and 2 show a network technician performing a
maintenance task on a network closet. Using the heads-up
display he can look up information in remote databases or
use software tools for identifying faults in network
equipment.
A network technician using our wearable device may
Figure 1. be required to roam from an office, to a patch panel, to a
cable tray, and eventually to an individual machine. Each
easily provide content that was unobtrusive, while at the change of location brings with it the need for new
same time allowing the user to switch focus between the information, new peripherals/probes and new sets of
data on the display and the work at hand, without eye software tools. The network maintenance application
strain, or movement of the HMD. embodies all of the properties of a wearable application
2.2. User Interface that stresses the concept of dynamic and adaptable
systems. We call this wearable application NETMAN.
The primary form of user input is speaker dependent
voice controls. The user trains the computer to interpret 3.2. Environment-Directed Computing
voice commands by completing a voice training exercise, Our goal is to design a flexible wearable computer
that familiarizes the user with the various commands system that can automatically adapt to changes of the
available. Alternative forms of user input are provided by user’s task, the availability of computational resources
the Twiddler keyboard, a pointing device, and a barcode (such as network bandwidth), and the situational context.
scanner. The head mounted display provides both auditory Together these factors represent a dynamic working
and visual feedback. environment for the wearable computer. By monitoring
2.3. Networking changes in the environment the computer can adapt its
operation according to predefined or user-defined
The wearable computer is equipped with a wireless guidelines. We call this concept environment-directed
modem that enables access to a campus-wide wireless computing.
network. This network, which is provided by Metricom,
offers a reliable connection to local area networks and the To determine the user’s task and situational context we
Internet with speeds of up to 28800 baud. have designed an infrared beacon system that allows the
wearable computer to perceive its physical environment
An alternative form of network connectivity is by means of infrared signals sent out by physical objects.
provided by an infrared transceiver which allows the To this end, we have augmented part of our lab space with
wearable computer to exchange messages with other IR a net of infrared transmitters which at regular intervals
equipped devices like printer and desktop computers. The send out unique identification tags that can be received by
IR system is also used to determine the wearable the infrared receiver of the wearable device (see also the
computer’s location within a building (see below).

3. NETMAN
3.1. Application Domain
Our primary application domain for wearable
computing is that of network maintenance. Our goal is to
design and develop a wearable system that helps
technicians in their daily task of troubleshooting and
repairing faults in computer network equipment. For
collecting requirements we are working closely with the
University of Oregon Computing Center which is
responsible for maintaining the computer and network
installations throughout campus. Typical tasks of
technicians include: installation of new network Figure 2.
 ways: first, the computer can automatically retrieve and
IR Beacon
Database
Server
display information relevant to the user’s current location
or task (context-dependent computing). For example, the
Beacon ID computer can automatically compile information from
Beacon ID relevant information
[IR network] [radio network]
remote data sources pertaining to the equipment the user
is currently working on instead of requiring the user to
Wearable
Computer
actively query for it. Second, specialized software tools
for troubleshooting network equipment can be
automatically loaded onto the wearable computer
Architecture 1: Information Pull whenever the user approaches an IR equipped network
device. The decision when to load (and unload) software
components to (and from) the wearable computer depends
(ID, location) on and requires knowledge about the current state of
IR Beacon Database
[wired network] Server resources like network bandwidth, remaining battery
lifetime, and disk space.
Computer ID relevant information Figure 3 shows three alternative system architectures
[IR network]
[radio network] for our IR beacon system. In the first architecture, the
Wearable wearable computer actively queries a server for relevant
Computer
information after receiving a beacon from an IR
transmitter (information pull). In architecture 2 and 3
Architecture 2: Information Push relevant information (data and/or software) is sent to the
wearable computer (information push). While architecture
2 uses a server to store information in a central place, in
IR Beacon
the third architecture information is stored in a distributed
fashion in the local memories of IR transceivers. This has
[IR network] relevant information
the advantage that IR transmitters can be completely self-
contained devices that do not require a network
Wearable connection.
Computer
Our current implementation of the IR beacon system
follows the second architecture, but we are actively
Architecture 3: Information Push
working on self-contained IR transmitters.
Figure 3. System Architectures for 3.3. System Properties
Environment-Directed Computing
In summary, the wearable systems that we study have
Active Badge System [15] and Poor’s work at MIT [14]). the following properties:
The beacon system gives the wearable computer the 1. We are working with wearable devices that have
ability to limited capacity in one or more of the following
1. identify individual objects in its immediate areas: main memory, secondary memory, processor
surrounding by identifying their unique signals; speed, power.
2. determine its own location in relation to known 2. We are working with wireless communication that
objects and - by means of a geographical database - has limited capacity in one or more of the following
its absolute location; areas: availability, bandwidth, reliability. Further, we
cannot expect symmetric communication in any of
3. exchange arbitrary information with individual IR these areas, e.g., we may have a high bandwidth,
transmitters; information can be just data, but also reliable connection as a downlink and a low
executable or interpretable code. This makes it bandwidth, unreliable (or non-existent) uplink. Of
possible to automatically load code fragments or course, this symmetry can fluctuate over the life of a
entire applications (applets) from the environment task.
onto the wearable computer as side effect of the
user’s physical movements. 3. Users of a wearable device will move through
different information contexts, e.g., to complete task
The IR beacon system can be used in a number of
 A, a user must first complete sub-task B. Each bandwidth data connection to wired LANs, data on a
context may require a different information/software wearable system can become out of date. Decisions must
tool set. be made between the use of less than up to date local
information and the use of more accurate remote
4. Users of a wearable device will move through
information.
different physical contexts. This can be tied to
switches in information context (e.g., moving from a Example: NETMAN requires information on the
network closet to an individual machine) as well as current topology of a specific LAN it is troubleshooting.
problems in communication hand-off and loss. There is local topology information that is left over
(cached) from a previous application. This information is
5. The hardware of the wearable device might change as
possibly out of date. Up to date information can be gained
new tasks or information contexts are encountered,
by querying a remote server. However, a wireless
e.g., new probes may be plugged into the wearable as
connection will have to be established with the server. A
a network failure is refined from the LAN level to the
decision is needed.
wire level. Similarly, in some occasions the user
might add a camera and microphone to the wearable Implications: The implication of both requirements 1
computer for remote collaboration with experts. and 2 is that we field a decision support system that can
Because of the additional weight of these components tie the probabilities of a shifting domain (e.g., the
they might be left in the office when not used. probability that the server information is more up to date,
the probability that the information can be downloaded in
6. The wearable environment may be active: other
a timely fashion) to the cost and eventually the value we
physical objects in the world may have the ability to
place on certain tasks being completed, possibly under
send or receive information from the wearable device.
deadline (e.g., what is the most up to date information
These "active devices" may or may not be networked.
worth to us, what is the cost of establishing and sustaining
In the simplest case, a device may simply make its ID
a data connection).
known. In more complex cases, a wearable may carry
on a conversation with an object. Requirement 3: We will need to marshal resources.
We fully expect the individual components of a larger tool
Given these properties, we envision wearable
set needed by a wearable to be distributed among the
computers to have dynamically changing software
wearable itself and one or more remote devices. The
configurations that are updated continuously according to
wearable may or may not know the exact location of each
the user’s current task and situational context. We have
tool, i.e., search is a possibility.
begun to look at the software infrastructure that is
necessary to operate such a wearable system. What we Example: NETMAN is being used to troubleshoot a
describe in this paper are our first attempts to build a non-booting workstation. The current task is to determine
wearable middleware software layer that acts as this connectivity between the workstation and the bootp
infrastructure, and the open research questions that this server. To do so requires a suite of tools (e.g., ping
has raised. service, traceroute, packet analyzer, collaboration tools
which allow the NETMAN user to “talk” with someone
4. Software Infrastructure on the server side). Some of these tools may reside on the
Requirement 1: Given limited processing resources on wearable, some on remote machines.
a wearable system, decisions must be made on out- Implications: We require a means of pulling together
sourcing of processing based on a combination of the tools we need for the task at hand.
available local resources, available remote resources, and
capacity and sustainability of data connections. Requirement 4: We need to manage the resources we
keep on the wearable optimally. Given limited resources
Example: The NETMAN is called upon to analyze a of power, space, processing ability, local resource
collection of packet data for information on why bootp is management is a necessity.
failing. The analysis can be done locally and immediately
with a substantial cost in battery power and a shutdown of Example: A NETMAN troubleshooting session may
other ongoing local tasks. The analysis can be out-sourced stretch over hours or even days. It will typically involve
to an unloaded high-performance computer (HPC) but at moving through a set of sub-tasks as well as a set of
the cost of shipping local data (and/or code) over a physical locations. While each new sub-task may bring the
currently saturated connection. need for a new tool set configuration, it is not uncommon
for configurations to share some set of individual tools.
Requirement 2: Given the lack of constant and high-
 The actual middlelayer consists of four submodules.
Wearable Computer
Application Manager
The Configuration Manager keeps track of hardware
and software components installed on the wearable device
such as memory configuration, sensory devices, system
Application
Application
Application software components, and optional hardware devices like
a camera. In addition, it maintains dependency
information in order to track which software requires
which other software or hardware. This information is
used for resource qualification as described below.
The Resource Manager monitors and makes available
Configuration Decision status information about important resources of the
Manager Maker
wearable device. Resources include disk space, available
Manager
network bandwidth, accessibility of vital remote resources
like servers, remaining battery life, etc.
Cache Resource
Manager The Decision Maker uses probabilistic methods to
reason about the operation of vital system functions. For
example, the decision maker is used to determine whether
to store data and/or software components locally or
remotely. Another typical task of the decision maker is to
Network Layer decide whether a task should be run locally or remotely on
a dedicated compute server. The decisions are made based
on a built-in formal model and the current state of
Figure 4. Wearable Computer monitored system variables such as installed components
Software Architecture and resource availabilities.

Implications: As a wearable user moves among sub- The Cache is a persistent data storage that can be used
tasks and physical settings, she will typically require new by applications to store data locally on the wearable
information and new application configurations. Given device. If the amount of cached data exceeds the available
that it is impossible to pre-load every possible software resources, the Decision Maker can decide to remove
configuration on the wearable device, we are left with individual data items.
devising mechanisms that make the download of new All submodules of the middlelayer provide an
software, either through push or pull means, more application programming interface which allows wearable
efficient. applications to use services provided by the middlelayer.
4.1. System Architecture For example, applications can use the Decision Maker to
decide whether to perform operations locally or to spawn
We have devised and partly implemented a software a subtask on another machine.
infrastructure for a wearable adaptable system. The entire
software organization of the wearable device consists of The network layer finally provides a network interface
four layers as shown in Figure 4. that isolates applications and middlelayer from specific
network characteristics. In particular, it hides the fact
The highest layer is formed by the Application whether communication occurs over wireless radio
Manager, a graphical user-interface that allows the user to network or over a infrared network.
control the execution of individual applications. In
addition, it provides feedback about the status of the 4.2. Resource Qualification
wearable device (battery life, network connection etc.) The information maintained by the resource manager
and ongoing operations. and configuration manager is used for resource
The second layer is represented by the software qualification, a process by which we ensure that
applications currently present on the wearable device. applications and other software components to be loaded
Applications can be loaded or unloaded dynamically. We onto the wearable device do not exceed the available
have devised a mechanism which allows us to load entire resources.
application configurations over a network and install them Resource qualification is performed whenever software
onto the wearable computer.
 Open issues: Using Strategist in the NETMAN
“Navigator” RAM
environment has raised a set of research issues:
1. How is a decision system kept up to date?
Tcl/Tk network
Interpreter modem card
driver A Strategist model is based on event probabilities. In
the wearable environment, these probabilities are often
preference file
“[Link]”
sound
sound card shifting over time. We are beginning to explore the use of
DLL
agents working on behalf of Strategist to maintain model
probabilities. In particular, we have begun to study the
Figure 5. Partial Resource means Strategist can gather information on-demand. Our
Dependency Graph current approach uses agents to retrieve up to date
information when it is needed. Returning to our example
is loaded onto the wearable device, whether it is pulled
of deciding between using out of date but local
from a server by the wearable device itself or is pushed
information versus downloading potentially more up to
onto the wearable device.
date information off of a remote server, one variable
Configuration and resource information is represented influencing the decision will be the time to download.
as resource dependency graphs. A resource dependency This in turn rests on the probability of sustaining a
graph is a labeled graph where nodes denote resources specific bandwidth for a given period of time. We have
and links dependencies between resources. Figure 5 shows written an agent who can probe a communication channel
an excerpt of a dependency graph as used by the for bandwidth statistics and map this into a probability
configuration manager. It expresses the fact that the distribution for use by the Strategist model. Of course,
application “Navigator'” directly or indirectly depends on given that there is no free lunch on a wearable – launching
seven other resources, some of them software and some of and managing agents costs resources – there is the
them hardware resources. Labels (which are not shown in question of how much effort to expend for any particular
Figure 5) are used to qualify the dependency. For example model. We have found that this has close ties to what the
we can express the fact that an application requires 8MB Uncertainty in AI (UAI) community has called the "value
of memory and 2MB of free disk space. of information" issue: what variables in a model are worth
knowing accurately? It is these variables that we may wish
Using resource qualification we can guarantee that
to provide attached agents.
software components to be loaded onto the wearable
device can actually be executed in the local environment 2. When can decision support be implemented by
and that installed software is compatible with the compiled policies?
hardware and software platform. For example, loading
Given that running Strategist on the wearable costs
software that allows two users to communicate using
resources, when can we use Strategist to analyze runtime
voice (such as an Internet phone application) does not
scenarios at compile time, i.e., before the wearable is put
make sense if the wearable computer is not equipped with
into action in the task domain? This will leave us with a
a microphone or speaker.
runtime decision matrix that often takes a fraction of the
5. Experiments resources of the full Strategist runtime system.

5.1. Runtime Decision Support 3. Going meta may be necessary.

We have begun work on hosting a runtime decision Related to both issues 1 and 2 above, it costs resources
support system (DSS) in our middleware layer. The DSS to run Strategist on the wearable. Can we make resource
tool that we are using is Strategist from Prevision [1]. efficient decisions at runtime on whether to invoke a
Strategist is based on influence diagrams, which in turn Strategist decision process or go with a quick-and-dirty
are based on Bayes Nets. Strategist is well suited to compiled solution (e.g., “always get the most up to date
decision problems that involve probabilistic information information”)? Of course, this is a decision process in
tied into utility or value tables. itself.

The decision maker provides an API that allows 5.2. Resource Qualification
applications to make use of its decision making Our first efforts have focused on pulling necessary
capabilities. For example, an application can use Strategist pieces together on the wearable computer. We devised a
to determine whether to run an analysis onboard or pass it recursive descent algorithm that uses the resource
off to a powerful server. dependency graph to locate and download individual
pieces of a tool set that is needed for a specific task at components from the cache.
hand. This has proven sufficient to allow us to run an
We have developed and evaluated a cache replacement
interesting set of NETMAN examples.
strategy that uses two criteria to determine which
Open issues: Having built a suitable infrastructure for components (data items and/or software components)
dynamic configuration management we are now planning should be cached locally and when they should be
to move towards a more open distributed computing removed.
paradigm based upon an integration of CORBA and
Cost: By cost we mean the cost of reloading a
JAVA. This will allow us to turn our attention to a new set
component once it has been removed from the cache. We
of questions:
define cost in two alternative ways:
1. Ties to Application specific scheduling.
1. In the first approach, cost is defined as the time it
Can we tie the problem of marshaling of wearable takes to reload a component once it has been evicted from
resources into the broader question of application level the cache. The reload-time is determined by the size of the
resource management on the Internet? For instance, component and the current available network bandwidth
Wolski [2] is designing an “Internet Weather Service” at to the server the component is stored on. The larger the
UCSD as part of a meta-computing environment. His size of a component and the lower the available
service uses past, current and predicted communication bandwidth the higher the cost. Under this scheme, two
bottlenecks and packet storms (the weather) to bring components with the same size can have different reload-
resources together for an HPC application. We have costs if they are stored on servers with different network
begun to look at tying our local DSS tool into a larger characteristics.
model of the wearable environment supporting application
The cost measure based on reloading-times is not
specific scheduling.
static, but varies over time depending on the current state
2. Quality of Service (QoS). of the network. It is thus necessary to reevaluate the cost
of each component periodically, for example by probing
The notion of levels of quality brings a much needed
the available network bandwidth to the respective servers.
flexibility in the dynamic environments we work in.
Instead of an all or nothing view of the world, we can 2. In the second approach, we define the cost of a
reason about the quality (in terms of information accuracy, component as the amount of energy that is required to
processing resources, connection) we are willing to live reload it. Energy usage is a critical measure that directly
with given the cost to achieve various levels. For example, determines the lifetime of batteries. Many application
we have found ourselves reasoning about the type of domains require uninterrupted usage of the wearable
collaboration tools we will marshal for certain NETMAN computers over several hours which with current
tasks. In some cases the ideal is full audio and video technology can only be achieved by carrying several sets
between the NETMAN user and an expert at a helpdesk. of batteries. Since batteries are bulky and heavy they
However, this makes sense only if we can maintain a level significantly influence the form factor and possible usage
of connection quality. Once this slips below threshold, we of today’s wearable computers.
need to move to a lower quality tool (e.g., audio or even
The energy required for loading a component is
text chat) to match the connectivity resources we have.
directly related to the amount of data that needs to be
Currently we carry out this dynamic adaptation of tools
transferred, but also depends on how often a network
manually. We would eventually like to make it part of the
connection is torn down and needs to be reestablished.
middleware layer, itself.
Establishing a network connection over a dial-up network
5.3. Cache Management is costly.
The idea to reconfigure and adapt a wearable computer Importance: The second criteria we use in managing
by dynamically loading and unloading software the cache is importance. Importance is defined as how
components requires strategies for making efficient use of critical a component is for the functioning of the various
limited resources such as bandwidth, and battery lifetime. hardware and software components of a wearable
We have looked at caching as a means for reducing the computer. For example, in order to use a camera or any
amount of information that has to be transferred between other external device, certain system software components
the wearable computer and its environment. In particular (device drivers etc.) have to be installed on the wearable
we are interested in caching strategies that make decisions computer. Removing such components can render the
based upon the actual costs of loading or unloading wearable computer non-functional, thus they are more
important than, let’s say, a rarely used diagnostic tool.
 More formally, we define importance of a component References
as the number of other components that depend on it. This
information can be extracted from the resource [1] Strategist by Prevision,
[Link]
dependency graph maintained by the configuration
manager; it is equal to the number of incoming [2] F. Berman, R. Wolski, S. Figueira, J. Schopf, and G. Shao,
dependency links in the transitive closure of the "Application-Level Scheduling on Distributed Heterogeneous
dependency graph. The higher the number of incoming Networks," Proceedings of Supercomputing ’96, November,
links, the higher the importance of a component. In 1996.
general, it is preferable to remove the least important [3] F. Bennet, Richardson T. and A. Harter. “Teleporting
components first. Mobile Application”, Proceedings of the Workshop on Mobile
Computing Systems and Applications, December 1994.
The concept of importance is not a mere technical
measure of existing dependencies between hardware or [4] T. Fallmyr. “Adaptable Mobile Systems”, IEEE Workshop
software components. In more than trivial cases the in Future Trends in Distributed Computing, August 1995.
importance of a component can only be evaluated in the [5] D. Goldberg and M. Tso. “How to Program Networked
context of the user’s tasks and goals. More details on this Portable Computers”, Proceedings of the 4th Workshop on
topic can be found in [12]. Workstation Operating Systems (WWOS-IV), October 1993.

Open Issues: We have come to the conclusion that [6] M.F. Kaashoeck, T. Pinckney, and J. A. Tauber. “Dynamic
cache management has to be viewed as one more piece of Documents: Mobile Wireless Access to the WWW”,
Proceedings of the Workshop on Mobile Computing Systems
a dynamically changing and adaptable middleware layer. and Applications, December 1994.
In a dynamic environment it is necessary to reevaluate the
current strategy and adjust it if necessary, instead of using 7] J.J. Kistler and M. Satyanarayanan. “Disconnected Operation
a static policy, fixed at predeployment time. An important in the Coda File System”, Proceedings of the Thirteenth ACM
question for the future is how the various criteria used for Symposium on Operating Systems Principles, Pages 213-225,
1991.
defining a cache replacement strategy (reload time, energy
usage, importance) can be combined effectively into an [8] Sun Microsystems, “Java White Papers”, available at
overall decision model. [Link]

Given this view, how can we adapt our cache strategy [9] B.N. Schilit, N.M. Theimer and B.B. Welch, “Customizing
to meet changing resource availability? For instance, we Mobile Applications”, in Proceedings USENIX Symposium on
Mobile & Location-Independent Computing, Pages 129-138,
may have predictable and sustained “blasts” of bandwidth August 1993.
for short periods of time (e.g., when the NETMAN is able
to plug in to an Ethernet wall socket). Under these [10] T. Watson, “Application Design for Wireless Computing”,
conditions, we may be best off moving to a “standard” in Proceedings of the Workshop on Mobile Computing Systems
cache strategy. Once this connection is lost, other and Applications, December 1994.
strategies will likely be more appropriate. In essence, [11] Steve Fickas, Gerd Kortuem, Zary Segall. Wearable
strategies are needed for managing a cache as a dynamic, Computing Web Site, University of Oregon,
adaptable service. http//[Link]/research/wearables.
[12] Gerd Kortuem, Steve Fickas, Zary Segall, “On-Demand
6. Conclusion Delivery of Software in Mobile Environments”, Nomadic
We have designed, implemented and partially Computing Workshop, 11th International Parallel Processing
evaluated a software infrastructure for wearable computer Symposium, April 1-5, 1997, Geneva, Switzerland. Available at
http//[Link]/wearables/Papers/[Link].
systems. We are emphasizing the dynamic adaptability
requirement for this class of systems. Our results are [13] Steve Fickas, Gerd Kortuem, Zary Segall, “NETMAN:
pointing out the need for a middleware layer capable of Collaborative Network Maintenance with Wearable
presenting a number of run time mechanisms and policies Computers”, submitted to GROUP97, available online at
allowing for dynamic application reconfiguration and out- http//[Link]/wearables/Papers/[Link].
sourcing. Our initial experience and measurements with [14] Poor, R. (1996), “IRX 2.0”, available online at
the NETMAN wearable system shows our approach to be [Link]
sound. Given the novelty of this field we see value in [15] Roy Want, Andy Hopper, Veronica Falcao, Jonathon
pointing out our view on the requirements and the open Gibbons, “The Active Badge Location System”, ACM
research questions related to the optimal structure of the Transactions on Information Systems, Vol. 10, No. 1, January
software organization for wearable information systems. 1992.
View publication stats