A State-Based Programming Model for Wireless Sensor Networks

136 Chapter 7. State-based Programming in Practice
only reduced by a small amount. Furthermore, CALIBRATION may be an only
transient state itself. Then its (as well as its substate’s) memory resources would
also reused once the state is left. Since CALIBRATION does not compute a result
required in a subsequent state, no additional variables are needed.
Since the OSM compiler compiles OSM program specifications back to regular
event-driven code, one could also object that the mechanism of mapping
variables to overlapping memory regions could also be used manually in the
plain event-driven model. Though possible in principle, programmers would
not only have to manage the program’s state machine manually. They would
also have to manually map the states’ variables to the complex memory representation,
such as the one shown in Prog. 6.5. Even minor changes to states high
in the hierarchy, such as the addition or removal of a layer in the hierarchy, lead
to major modifications of the memory layout. Consequentially, access to elements
of the structure would also change with the structure, requiring changes
throughout the program. Therefore we think that our state-variable approach is
only manageable with the help of a compiler.
7.3.2 General Applicability and Efficiency
Now two question arises: are state variables applicable to real-world sensornode
programs? And, how much memory savings can we expect? We cannot
answer these questions conclusively, as extensive application experience is missing.
However, we have several indications from our own work with sensor-node
programming as well as from descriptions of sensor-node algorithms in the literature
that state variables are indeed useful.
General Applicability of State Variables
Probably the most-generally applicable example where sensor-node programs
are structured into discrete phases of operation is initialization and setup versus
regular operation of a sensor node. Typically sensor nodes need some form
of setup phase before they can engage in their regular operation mode. Often
longer phases of regular operation regularly alternate with short setup phase.
Both phases typically require some amount of temporary data that can be released
once the phase is complete. Setup may involve assigning roles to individual
nodes of the network [56, 98], setting up a network topology (such as
spanning trees [84]), performing sensor calibration, and so on. Once setup is
complete, the node engages in regular operation, which typically involves tasks
like sampling local sensors, aggregating data, and forwarding messages. Regular
operation can also mean to perform one out of several roles that has been
assigned during setup. For the setup phase, temporary data may contain a list
of neighboring nodes with an associated measure of link quality, node features,
as well as other properties of the node for role assignment and topology setup.
Or they may contain a series of local and remote sensor measurements for calibration
(as in our previous example). For regular operation, such variables may
contain aggregation data, messages to be forwarded, and so on.