[ Home | Plans | Meetings | Members | Search | Papers | Links | CyberWear | LocoSoft]
- Sensor Device - This reperesents and actual sensor that can provide information about
the user's surroundings. For example, GPS or pinger sensors.
- Device Specific Filter - This acts as a layer between the sensor and the EventMan. This
layer can communicate with the EventMan, and is intelligent enough to be able to filter
out most data that is irrelevant, thus reducing bus traffic, usage of the EventMan, and
power consumption. An example of how this layer would work, is that it may not signal an
event unless a user's heart rate exceeds a threshold which is communicated from the
EventMan. When there are no events that need a device, the device can 'sleep' or power
save. These filters can be implemented using PICs of any sort of programmable DSP.
- Sensor Module - These modules are dynmically loaded and linked with the EventMan. The
modules are specific to each device, and all have a standard interface with the EventMan
(See SensorMod.h for specifics). This allows the
EventMan to use any sensor without needing to know the semantics of how the device works
or is implemented. These sensor modules also act as a further filter, evaluating which
events have actually been triggered by the sensor, returning a list of triggered event IDs
to the EventMan. These modules are also responsible for programming the remote Device
Specific Filters as to when to trigger events. As Sensor Modules can be dynamically loaded
at any time, it should be possible for new devices to download these modules via the bus
when they are first plugged in.
- Virtual Sensor - This is actually a Sensor Module, but it acts to detect events on some
internal system. For example, time based events can be detected with a Virtual Sensor that
monitors the real-time clock of the system. Other Virtual Sensors can be used to monitor
file descriptors for events and likewise.
- EventMan - This keeps track of loaded modules, and registered Events. This generally
sleeps, listening on the bus for events. In this way, CPU usage is reduced to a minimum.
When an event is present on the bus, the EventMan calls the appropriate Sensor Module to
process the event. If the Sensor Module returns some event ID's, the EventMan can then
decide which application to signal. For complex events which may involve one or more
conditional expressions, the EventMan serve to evaluate the expression, and to divide it
into sub-events with each Sensor Module. It is interresting to note that the EventMan has
no knowledge or interpretation of sensor data and how to match it as that is left to the
- Application - These modules are also dynamically loaded and linked with the EventMan.
Applications differ to Sensor Modules in the fact that they can call functions in the
EventMan to create new events with different sensors, and they can also request sensor
data. The applications have a standard interface with the EventMan (Detailed in ApplicationMod.h) and also have a standard set
of function available to them from the EventMan (Detailed in EventAPI.h). Furthermore, applications may wish to
export symbols within them, making some of their functionality available to other
applications. This is useful for some system applications such as the NoteServer.
- Control Pipe -Once the EventMan is running it is useful for there to be a way to tell it
to load new applications. The Control Pipe provides this interface.
The key difference between this and the ideal version is the lack of an IO bus.
Instead, sensors are plugged into serial ports on the wearble. The Event Filters are
present as individual applications that read from the serial ports and communicate with
the Sensor Modules by the use of named pipes. This makes startup more complex as it is
important for the Event Filter applications to be started before any on the Sensor Modules
are loaded, but it allows us to test our event driven architecture.
Information about writing EventMan applications can be found at the Event Manager Applications Writers Guide.
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.