| |
76
Chapter 5. General Concepts, Toolkits, and Frameworks
Software Implementation: Perception API
Implementing the proposed perception model on the hardware described above posed
several interesting challenges. The small memory capacity and low computing power
of the micro-controller, had a large influence on the design of an API implementing
the artifact-based model. Designing a perception API that fits on the devices and
at the same time provides a useful set of functions was a major issue. Also o ering
the API over di erent communication channels (I2C, serial, and RF) put additional
constraints onto the implementation.
There are several issues that have to be solved across di erent layers. First of all,
knowledge about available sensing resources has to be managed. The system needs
the ability to discover sensors that are currently available in the network. It requires
that sensors can report about their abilities and are addressable. Secondly, di erent
types of temporal sensor access are necessary, depending on the requirements of the
actual applications. For example, acceleration values often require a high sampling
frequency whereas for a temperature monitoring system it is su cient to be notified
only when the temperature changes by a significant amount. Thirdly, di erent
filtering and feature calculation functions have to be provided on the devices to
limit extensive bandwidth use.
The following three subsections describe the implementation in more detail on each
of the three layers.
Artifact Layer
The artifact layer deals with properties related to one single artifact. Table 1 gives
an overview over the functionality o ered in this layer: textual description of each
function, exact syntax and classification of the functionality.
The scan i2c and cap i2c functions provide a two-step discovery of available sen-
sors connected to the I2C bus. This two-step approach was chosen to cope with
the memory constraints of the micro-controller platform. First, the scan routine re-
turns all the identifiers of the locally available sensors. Then, in a second step using
the capabilities function, only applicable features (sensor capabilities) for the sensor
given in the parameter are discovered. This saves memory in contrast to a one-step
approach where capabilities returned for all sensors available would consume a lot of
memory. Typically this functionality is used just after start up. It enables sensors to
be added dynamically to a given artifact. To read sensor values from a given sensor
three retrieval types are provided. Single request enables a device to receive only
one single sensor value, or alternatively to poll a series of values. For performance
reasons a prepare operation has been introduced: it allows to initiate the feature
|  |
|
| |
|
|
