Bristol Wearable Computing

[ Home | Plans | Meetings | Members | Search | Papers | Links | CyberWear | LocoSoft]


Situated Computing Server

The situated computing server (SCS) is a key component of an operating system for an ultra portable computing platform (UPC: a subconciously-portable, personal computing platform capable of responding to its local environment). The server's function is to mediate between applications and environmental sensors so that they can be dynamically plugged into the UPC without need for prior knowledge.

The first situated computing server was developed by Richard Hull at HP Labs, Bristol. Richard has identified a set of requirements for the ideal SCS; these can be split into two groups: Interpretation requirements and System requiments.

Interpretation requirements

The SCS must support the interpretation of sensor interpretion of sensor data into forms that are likely to be useful for applications. This involves solving a range of particular problems:

System requirements

These requirements have to do with the mechanism for interaction between the SCS and the applications and sensors that use it.

Architecture

Not everything registered with the SCS has to be either an application or a sensor - it could be something that takes sensor data from a sensor and refines it to make situated information for use by an application. Consequently the distinction between applications and sensors is a false one. A better model comprises a network of situated information objects any of which can be either consumers of situated information or providers of situated information or both. These objects exist in a data flow network, with situated information flowing from object to object. The SCS becomes the network manager, responsible for establishing and maintaining the links between objects. The network of objects reflects the way in which situated information can be progressively refined as it flows from physical sensors towards applications.

This architecture may come at some performance cost, since it will require many intercommunicating processes. In particular will may be some cases where managing situated information inside a single process allows better performance. Such cases are not so much an argument against the data-flow-inspired architecture, but are rather an argument against defining too many situated information objects that each do too little. The architecture remains valid while object designers have the freedom to choose how much is done within each object.

Success criteria

There are too many challenges here, but then again that is what makes this a research project rather than a straight-forward implementation excercise! The good solution will:


unicrest.gif (4191 bytes)

The material displayed is provided 'as is' and is subject to use restrictions.
For problems or questions regarding this web contact Cliff Randell.
Last updated: January 14, 2000.
logoep.gif (1404 bytes)
ęCopyright Hewlett-Packard 1997-2000.