A State-Based Programming Model for Wireless Sensor Networks

More documents

Recommendations

Info

72 Chapter 4. Event-driven Programming in Practice Choosing the next phase: Branching Often there are several potential next phases in sensor-network programs. The choice of the actual next phase then depends on an input event, the state of a previous computation, or a combination of both. Also, a single phase may be reachable through multiple paths, as in the following example. Start Surge Example 2 Until now our Surge application ignored a failed sending attempt. If sending fails, however, the program may decide to store the data sample in a local buffer (rather then ignoring the failure). The modified program could then, for example, send the stored data sample in the next round together with the new sample. An updated version of the program is depicted in Fig. 4.2. In the new version, the choice of the next phase from SEND depends on the event generated by the send operation (nack or ack). Likewise, the IDLE phase may be reached from two phases, namely SEND and STORE. ✷ INIT SAMPLE init_done sample_done SEND nack ack STORE IDLE store_done timeout Figure 4.2: A more sophisticated version of Surge with five program phases. In this program version a failure while sending the data sample is handled by buffering the data locally. Note that the control flow branches from the SEND phase depending on the events nack and ack. Preemption In sensor-node programs the occurrence of a certain event often interrupts (we say it preempts) a sequence of multiple phases in order to start a new phase. That is, if the event occurs in any phase of a sequence of phases, the control flow of the program is transfered to the new phase. Surge Example 3 Let us now consider yet another variation of the basic Surge program, which is inspired by the modification of Surge as distributed with TinyOS [125]. In this version we introduce a network-command interface that allows a remote user to put the node in sleep mode by sending a sleep message to it. The node then preempts all current activities and sleeps until it receives a subsequent wakeup message. This version of Surge is depicted in Fig. 4.3. ✷ The dashed lines in Fig. 4.3 denote the preemption caused by the sleep event. That is, the control is passed to the SLEEP phase from any of the phases SAMPLE, SEND, and IDLE on the occurrence of the sleep event.
4.2. The Anatomy of Sensor-Node Programs 73 INIT init_done NORMAL_OPERATION SAMPLE sample_done (n)ack timeout SEND wakeup sleep SLEEP IDLE Figure 4.3: The three program phases SAMPLE, SEND, and IDLE are preempted by the sleep event. The execution of the target phase of a preemption takes priority over the preempted phases. Preemption is basically the same as what we have previously called branching, only that preemption has a number of source phases (rather then just one). Preemption is can be considered as handling of exceptions. The phase to which control is transferred to may then be considered the exception handler. Specifying preemption in the event-model requires extensive state management. The difficulty is two-fold: Firstly, on the occurrence of a preempting event, the programmer must first deinitialize the phases that are to be preempted. Special care must be taken if preemption is added during the redesign of a sensornode program. From our experience, proper deinitialization can be easily forgotten. And secondly, (future) events that are caused by computational operations performed before the preemption occurred must be actively ignored. For example, in our example program the (n)ack event is caused by sending a data sample. If the send operation has completed, but a sleep event is received next (i.e., before the (n)ack event), the (n)ack event is nevertheless generated by the OS and thus triggers the associated action. In this action, however, it needs to be ignored. The code fragment in Prog. 4.4 shows a possible implementation of the preemption in the event-driven model. The handler of the sleep event (lines 1- 14) implements the preemption. The preempted phases are deinitialized within the switch statement (lines 3-11). The handler of the nack event first checks the exceptional case when the program is in the SLEEP state (lines 16). Then the nack event is ignored. If the program was coming from the SEND phase (which is the regular case), it behaves as without preemption. Clearly, the complexity of manual state management in the case of preemption is hard to handle for programmers. Even this short program is hard to write and even harder to read. To deduce a programmers intention from the code is next to impossible. Structuring Program Phases: Phase Hierarchies In some cases, it is convenient to think of a set of sequentially composed phases as a single, higher-level program phase. This implies that there is a hierarchy of phases, where phases higher in the hierarchy (which we call super-phases) are composed of one or more sub-phases. Our previous example, Fig. 4.3, is such a case.
Page 1:
Diss. ETH Nr. 17397 A State-Based P
Page 4 and 5:
ii The main idea behind OSM is to e
Page 6 and 7:
iv These, dass ein solches zustands
Page 8 and 9:
vi Contents 2.4.3 Wireless Sensor N
Page 10 and 11:
viii Contents 8.2.4 Program State M
Page 12 and 13:
2 Chapter 1. Introduction This make
Page 14 and 15:
4 Chapter 1. Introduction for senso
Page 16 and 17:
6 Chapter 1. Introduction programmi
Page 18 and 19:
8 Chapter 2. Wireless Sensor Networ
Page 20 and 21:
10 Chapter 2. Wireless Sensor Netwo
Page 22 and 23:
Page 24 and 25:
Page 26 and 27:
Page 28 and 29:
Page 30 and 31:
Page 32 and 33: 22 Chapter 2. Wireless Sensor Netwo
Page 42 and 43: 32 Chapter 3. Programming and Runti
Page 72 and 73: 62 Chapter 4. Event-driven Programm
Page 94 and 95: 84 Chapter 5. The Object-State Mode
Page 110 and 111: 100 Chapter 6. Implementation When
Page 112 and 113: 102 Chapter 6. Implementation speci
Page 114 and 115: 104 Chapter 6. Implementation Progr
Page 116 and 117: 106 Chapter 6. Implementation state
Page 122 and 123: 112 Chapter 6. Implementation runti
Page 124 and 125: 114 Chapter 6. Implementation PROG_
Page 126 and 127: 116 Chapter 6. Implementation the s
Page 128 and 129: 118 Chapter 6. Implementation the i
Page 130 and 131: 120 Chapter 7. State-based Programm
Page 132 and 133:
122 Chapter 7. State-based Programm
Page 134 and 135:
Page 136 and 137:
Page 138 and 139:
Page 140 and 141:
Page 142 and 143:
Page 144 and 145:
Page 146 and 147:
Page 148 and 149:
Page 150 and 151:
140 Chapter 8. Related Work guage.
Page 152 and 153:
142 Chapter 8. Related Work Control
Page 154 and 155:
144 Chapter 8. Related Work and out
Page 156 and 157:
146 Chapter 8. Related Work applica
Page 158 and 159:
148 Chapter 8. Related Work low-lev
Page 160 and 161:
150 Chapter 8. Related Work
Page 162 and 163:
152 Chapter 9. Conclusions and Futu
Page 164 and 165:
Page 166 and 167:
Page 168 and 169:
158 Appendix A. OSM Code Generation
Page 170 and 171:
Page 172 and 173:
Page 174 and 175:
Page 176 and 177:
Page 178 and 179:
Page 180 and 181:
Page 182 and 183:
Page 184 and 185:
Page 186 and 187:
176 Appendix B. Implementations of
Page 188 and 189:
Page 190 and 191:
Page 192 and 193:
182 Bibliography [11] Charles Andr
Page 194 and 195:
184 Bibliography [36] Cormac Duffy,
Page 196 and 197:
186 Bibliography [60] Jason Lester
Page 198 and 199:
188 Bibliography [85] Alan Mainwari
Page 200 and 201:
190 Bibliography [110] Karsten Stre
Page 202 and 203:
192 Bibliography
show all

A State-Based Programming Model for Wireless Sensor Networks

Create successful ePaper yourself

Delete template?

Save as template?