Information Technology Reference
In-Depth Information
There are primitive and complex events.
Primitive events describe the exceedance of one
configured threshold by a single sensed value.
Many applications demand detection of simultane-
ous occurrence of several primitive events. This
is particularly true if identification of complex
real-world phenomena is required. A combination
of several primitive events is a complex event. For
example, the occurrence of an event fire should be
denoted as a combination of the primitive events
TinyOS (Levis, Madden, Gay, Polastre, Szewczyk,
Whitehouse, Woo, Hill, Welsh, Brewer, & Culler,
2005). Very similar to that is the COUGAR project
(Yao & Gehrke, 2002), which also supports data
queries in a SQL-like dialect. Both approaches
provide a good abstraction layer to specify data
collection in database-query style but still work
on the node level and hence, require detailed
knowledge about the WSN to be configured.
Based on TinyDB, the Tiny Application Sensor
Kit (TASK) (Buonadonna, Gay, Hellerstein, Hong,
& Madden, 2005) is most closely related to the
aims of this chapter. It is a kit for configuring
low data rate environmental monitoring applica-
tions while remaining “self-explanatory, easy to
configure and easy to maintain”. In addition to
TinyDB, TASK provides a complete application
background from field tools over gateways and
internet connectivity up to support of external
tools for proper sensor data preparation and
network monitoring. Further, it supports inferior
power management and considers fault tolerant
performance in case of node crashes.
All approaches reduce the configuration com-
plexity to a certain amount by transparent high
programming abstraction. Among the available
high-level abstractions TASK is a valuable step
towards a user-centric method for WSN configura-
tion. It provides users with a lot of tools on top of
improving event detection only. However, all ap-
proaches are still unsuitable for non-professional
deployment of WSNs. Besides the unfeasibility
of letting non-professional users apply database
abstractions, these approaches carry some WSN-
related drawbacks along. They make use of a
centralized topology with at least one coordinating
node continuously collecting and evaluating raw
sensor readings. Hence, these approaches trans-
port huge amounts of data, consume much energy
and reduce the responsiveness and throughput of
the network. Further, analyzing collected data at
central nodes inherently creates a Single Point of
Failure (SPoF).
(temperature > 50°C) AND (smoke > 1.1%)
instead of using the primitive events only. Com-
plex events based on different sensing capabilities
indicating the same phenomenon, here temperature
and smoke, gain a higher false alarm immunity and
enhance the reliability of event detection (Shih,
Wang, Yang, & Chang, 2006).
An ease of use for event configuration in a WSN
by non-professional users requires provision of
two major configuration means, i.e., a high level
abstraction for description of events to be detected
and a robust method for autonomous configuration
and detection of defined events. The following
introduces and compares available approaches
for such configuration means.
High Abstraction for Sensor
Network Configuration
Available higher abstractions for sensor network
programming and configuration mainly base upon
programming languages or database-like query-
ing. In case of WSN, configuration is perceived
as setting of detection parameters, e.g., thresholds,
and linking of those. A configuration allows con-
cluding whether actual sensor readings match the
defined settings or not. One of the most famous
approaches using database abstractions for col-
lection and fusion of sensor readings is TinyDB
(Madden, Franklin, Hellerstein, & Hong, 2005).
TinyDB extends SQL to support in-network data
queries on sensor nodes using the operating system
Search WWH ::




Custom Search