[ 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
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.
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
- Providing sensor-independence. Sensor data reflecting the
underlying sensor technology must be re-interpreted
according to a device-independent, semantic model. In
this way applications may benefit from envonmental
sensing without depending on a particular sensing
- Eliminating noise. Any noise associated with sensor data
must be removed.
- Adding probabilistic information. Data from sensors may
be inherently subject to error (eg voice recognition), or
the interpretation process may be subject to assumptions
(for example, given data from door sensors indicating
that Fred has entered a room and not left it, you may
then interpret this to mean that Fred is still in the
room, but you need to assume that Fred has not left by
the windows). Interpretation of streams of sensor data
may affect confidence in the current reading.
- Fusing sensor data. Sensor data from different sensor
types may cover the same situational-dimension. For
example, voice recognition may identify a different set
of campanions compared to active badge data.
Probabilistic information may allow discrepancies to be
- Incorporating world knowledge. Common sense and world
knowledge are often needed in order to interpret sensor
data. This is effectively an addditional challenge that
arises during the basic semantic interpretation problem.
(For example knowing the lay out of buildings and the
sensitivity of sensors then we can deduce likely
positions from location sensor data.) We can also make
deductions based on the absence of data: we have not
sensed Fred leaving the room therefore he is still in the
These requirements have to do with the mechanism for
interaction between the SCS and the applications and sensors that
- Push and pull models. Either an application may receive
environmental information at the instigation of the SCS
(push) or the application may solicit environmental
information whenever it needs it (pull). The push model
reduces the likelihood of information being out of date,
the pull model may eliminate redundant processing of
unwanted information. Similarly sensors may push data
into the SCS or the SCS may pull it from sensors. The
sensor push/pull choice may be made independently from
the application push/pull choice. Different sensor and
application types will be better served by different
push/pull arrangements, thus the ideal SCS will support
both mechanisms at both the application and sensor
- Registration and discovery. If applications and sensors
are to be written without prior knowledge of each other
then the SCS must provide an interface by which sensors
can register themselves with the SCS and applications can
discover which sensors are available.
- Latency/ throughput.
- Non-blocking. OS must not be at the mercy of application
or sensor developers.
- Extensibility. Real-time plug and play - addition of new
sensors and applications.
- Registration. Applications contact the SCS to register
their interest in a particular type of situated
information. Sensors contact the SCS to register their
ability to provide situated information of a particular
type. Registration also tells the server where to find
the application or sensor if interaction is to be
according to the pull model. The server interface
provides a way for applications and sensors to describe
situated information type. This requires the management
of a name space for types, whereby each unique type can
be assured of a unique name and can be related to other
registered types according to a type hierarchy. This
leads to some classic distributed system trading issues:
how to ensure a scaleable system that is usable by
autonomous user communities! [See ANSA work on 'Trading'
- Portability. Try to isolate OS specific services such as
those for multi-threading from the SCS code - this makes
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
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.
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:
- Identify and address the challenging, high-level design
issues. A poor solution would shy away from the SCS
research issues. Two major research challenges are to to
provide a type management interface that would continue
to function within a growing community of autonomous
developers and to enable the SCS to manage a network of
- Meet a useful subset of the requirements. A poor solution
would omit features that would be considered essential by
those developing sensors and software for a UPC -
admittedly a subjective issue.
- Allow future extension to provide a complete solution. A
poor solution would be one where the design has to be
abandonned in order for initially excluded features to be
- Address performance issues in an OS independent manner
(isolate OS services from the server code to allow easy
porting or attention to bottleneck services).
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.
ęCopyright Hewlett-Packard 1997-2000.