A State-Based Programming Model for Wireless Sensor Networks

1 Introduction
1.1 Background
Over the past decades, advances in sensor technology, miniaturization and lowcost,
low-power chip design have led to the development of wireless sensor
nodes: small, inexpensive, and programmable devices that combine computing,
sensing, short-range wireless communication, and an autonomous power
supply. This development has inspired the vision of wireless sensor networks—
wireless networks of sensor nodes that can be deployed in the environment at
the large scale to unobtrusively monitor phenomena of the real world. There
is a wide range of applications envisioned for such wireless sensor networks,
including precision agriculture, monitoring of fragile goods and building structures,
monitoring the habitat of endangered species and the animals themselves,
emergency response, environmental and micro-climate monitoring, logistics,
and military surveillance.
The most popular programming model for developing sensor-network applications
today is the event-driven model. Several programming frameworks
based on that model exist, for example, the BTnode system software [21], Contiki
[37], the TinyOS system software [59] and nesC programming language [45],
SOS [52] and Maté [79]. The event-driven model is based on two main abstractions:
events and actions. Events in the context of event-driven programming
can be considered abstractions of real-world events. Events are typically typed
to distinguish different event classes and may contain parameters, for example,
to carry associated event data. At runtime, the occurrence of an event can trigger
the execution of a computational action. Typically, there is a one-to-one association
between event types and actions. Then, an event-driven program consists
of as many actions as there are event types. Actions are typically implemented
as functions of a sequential programming language. They always run to completion
without being interrupted by other actions. In order not to monopolize
the CPU for any significant time, actions need to be non-blocking. Therefore, at
any point in the control flow where an operation needs to wait for some event
to occur (e.g., a reply message or acknowledgment), the operation must be split
into two parts: a non-blocking operation request and an asynchronous completion
event. The completion event then triggers another action, which continues
the operation.
One of the main strengths of the event-driven model is that its support in the
underlying system software incurs very little memory and runtime overhead.
Also, the event-driven model is simple, yet intuitively captures the reactive nature
of sensor-network applications. In contrast, the multi-threaded programming
model, another programming approach that has been applied to wireless
sensor networks, is typically considered to incur too much memory and computational
overhead (mainly because of per-thread stacks and context switches).