High Level Definition of Event-Based Applications for Pervasive Systems - Advanced Design Approaches to Emerging Software Systems - page 143

events. Having specified the phenomenon in ESL,
the event specification associates the phenomenon
with customizable application constraints. Con-
figurable execution intervals and appropriate event
handlers have to be assigned. Further, a region
defining the spatial expansion of the phenomenon
can be optionally defined. Each event specification
contains an <EXECUTION> element that states
the frequency of event detection or measurement
data gathering. Appropriate processes, which are
triggered upon positive event evaluation, are listed
in the <CONSEQUENCE> element. To improve
the event specification complexity, the optional
<DIMENSION> element enables to fine tune
the event observation behavior by defining the
expansion of the collaboration region. The col-
laboration region is configured around the node,
e.g., as a circle, ball, square, cube or number of
hops. It contains all devices, allowed to participate
in collaborative event detection.
For configuring several events simultaneously,
attributes are embedded in the <EVENT> element.
The id assigns a globally unique identifier to event
specifications. It enables to associate requests and
updates to a particular event specification. The
version number identifies different versions of the
same event specification. It reduces maintenance
and online reprogramming complexity. Incoming
event specifications with higher version numbers
substitute all older versions of the targeted event
specification, which are deleted to save memory.
For removal of event specifications from a net-
work, an empty event specification containing the
event identifier only is used. The priority attribute
optionally assigns a priority level to the event
specification to support multi-event evaluation.
Consider a sensor network gathering temperature
readings for climate control that is used in parallel
to detect forest fires. In such a setting the detec-
tion of forest fire would have the higher priority
because it is a safety-critical event. Currently, the
ESL provides three priority levels, which are high ,
normal and low , whereas normal is the default
value if not explicitly specified.

To overcome the problems of varying context,
fluctuating environment and node mobility, sen-
sor networks must frequently self-adapt to the
current situation. Especially if nodes collaborate
with each other, these connections may suddenly
be disturbed or not available any longer. Preven-
tion of such changes is hard or even impossible.
To handle those situations, sensor nodes must
provide means to renew or establish collabora-
tion with other sensor nodes in their vicinity. This
again requires a processing and communication
overhead. To customize the adaptiveness and ef-
ficiency of the communication scheme used for
collaboration between neighboring nodes, the
lease and reliableMode attributes are specified.
The lease defines the frequency of adapting col-
laborative relations between neighboring nodes.
It specifies the time-lag between two adaptation
phases as a multiplier of the regular event detec-
tion frequency stated in <EXECUTION>. Short
lease intervals (small lease factor) provide a high
adaptation rate whereas long lease intervals can
significantly reduce the number of messages and
the energy consumption. For example, highly
fluctuating WSNs should apply short lease fac-
tors to cope with changing topology and moving
nodes. In contrast to that, WSNs with static de-
ployment may use long lease factors to reduce the
number of required collaboration messages. The
reliableMode attribute permits to choose between
a higher reliability in data exchange or reduced
energy consumption. It introduces retransmis-
sions on the application level in case of message
loss. Enabling the reliableMode instructs to ex-
plicitly acknowledge every data exchange that is
associated to a certain event. The reliable mode
consequently requires a communication overhead
but enhances the reliability of the application.
Thus, safety-critical events should make use of
the reliable mode, whereas simple data collect-
ing scenarios could omit the required overhead
in favor of less energy consumption. It is quite
obvious that configuration of both parameters
strongly depends on the application as well as