A State-Based Programming Model for Wireless Sensor Networks

80 Chapter 4. Event-driven Programming in Practice
4.3.1 Automatic State Management
First off all, to avoid manual state management, a sensor-node programming
model requires an explicit abstraction of what we have presented as phases: a
common context in which multiple actions can perform. Furthermore it requires
mechanisms to compose phases sequentially, hierarchically, and concurrently.
A natural abstraction of program phases are states of finite state machines
(FSM). Finite state machines—in their various representations—have been extensively
used for modeling and programming reactive embedded systems. Reactive
embedded systems share many of the characteristics and requirements of
sensor nodes, such as resource efficiency and complex program anatomies.
Particularly the Statecharts model and its many descendants have seen
widespread use. The Statecharts model combines elements form the eventdriven
programming model (events and associated actions) as well as from finite
state machines (states and transitions among states). To these elements it
adds state hierarchy and concurrency. As such, the Statecharts model is well
suited to describe sensor-node programs. Statecharts can help to solve the manual
state-management issues. Particularly, it allows to specify the program’s
control flow in terms of the model’s abstractions (namely transitions between
possibly nested and concurrent states), rather then requiring the programmer to
specify the control flow programmatically. Indeed, we have already used the
graphical Statechart notation to illustrate the flow of control through phases in
the examples throughout this chapter. The Statechart model builds the foundation
for our sensor-node programming model, which we will present in the next
chapter.
4.3.2 Automatic Stack Management
However, neither the Statecharts model nor any of its descendants do solve the
issue of manual stack management. As we have detailed previously, phases of
sensor-node programs have associated data state. Statecharts and Statechartlike
models typically do not provide an abstraction for such data state. The few
models which do, however, lack a mechanism to manage such state automatically,
that is, to initialize the data state upon state entry (e.g., by allocating and
initializing a state specific variable) and to release it upon exit. The same holds
for all (de)initializations related to phases, such as setting up or shutting down
timers, switching on or off radios and sensors, etc. In general, Statechart and
descendant programming models do not support the (de)initialization of states.
To fix these issues, we propose to make two important additions to the basic
Statechart model: Firstly, states have dedicated initialization and deinitialization
functions. These functions are modeled as regular actions. They are associated
with both a state and a transition, and are executed within the context of the
associated state. Secondly, states can have associated data state. This state can
be considered as the local variables of states. The lifetime and scope of state
variables are bound to their state. State variables are an application of general
(de)initialization functions: data state is allocated and initialized in the state’s
initialization function and released upon the state’s exit in its deinitialization
function. (In our proposed model however, initialization and release of state
variables is transparent to the programmer.) However, state variables are more