A State-Based Programming Model for Wireless Sensor Networks

124 Chapter 7. State-based Programming in Practice
eled explicitly as a NesC-language enumeration. Transitions are modeled by
assigning one of the enumeration constants to the state-keeping variable. (We
use the term “state-keeping variable” as opposed to “state variable” in order to
distinguish them from OSM’s concept of state variables.) The code resembles
the general pattern of event-driven applications as shown in Program 4.2. As
such, it is very structured for an event-driven program.
Program 7.1 is an excerpt of the original NesC code representing a state transition
(see also Appendix B.1, lines 159-164). The MEMBER state is entered from
the FOLLOWER state through a transition triggered by a join event (line 1). In
order to increase the readability of the code, op7() (line 5) serves as a placeholder
for the actual action to be performed on the occurrence of the join event
in state FOLLOWER. Then the transition’s target state is assigned in line 6. Finally,
the timer of the target state MEMBER is initialized in line 7. We will discuss
initialization of state-bound resources, such as timers, in greater detail below.
Program 7.1: NesC code fragment implementing the transition from FOLLOWER
to MEMBER upon a join event. The code also includes the timer
initialization of the target state (line 7).
1 command result_t GroupManagement.join() {
2 switch( _GMStatus.status ) {
3 case ...: // [...]
4 case FOLLOWER:
5 op7();
6 _GMStatus.status = MEMBER;
7 _generalTimer = wait_receive();
8 break;
9 case ...: // [...]
10 default: // [...]
11 }
12 }
OSM Implementation
We have reimplemented EnviroTrack’s group management state machine in
OSM, as shown in Appendix B.2. A small excerpt of the OSM code is shown
in Prog. 7.2, which is the OSM equivalent to the NesC fragment in Prog. 7.1.
Instead of using a state-keeping variable, states are specified explicitly using
OSM states (indicated by the state keyword). Transitions are specified explicitly
within their source state, making switch/case statements obsolete. Unlike
in event-driven programs, control-flow information and implementation are
clearly separated in OSM programs. OSM code only contains the control flow
of the group management protocol. It does not contain any program logic. The
actual program is implemented in the C language in separate files.