A State-Based Programming Model for Wireless Sensor Networks

More documents

Recommendations

Info

70 Chapter 4. Event-driven Programming in Practice SAMPLE phase in order to start sampling. In order to save power the sensor is generally switched off unless actually sampling. Therefore the SAMPLE phase is initialized by switching on the sensor. When the data sample is available, which may considerable time (e.g., for GPS sensors), the sensor is switched off again. Then the SEND phase is started. Similar to the SAMPLE phase the SEND phase first switches on the radio, waits until a connection to the dedicated sink node is established and then sends the data sample acquired in the previous SAMPLE phase. When the reception of the data has been acknowledged by the sink node, the radio is switched off again and the program moves to the IDLE phase. In this initial version of the program we ignore a failed send attempt (e.g, due to collisions or packet loss on a noisy channel) and move to IDLE anyway. The IDLE phase does nothing but wait for the start of the next interval, when the next cycle of sampling and sending is restarted, that is, the program moves to the SAMPLE phase again. In order to sleep for the specified time, a timer is initialized upon entering the IDLE phase and then the CPU is put into sleep mode. The node wakes up again when the timer fires and the program moves to the SAMPLE mode again. In our example, the sampling of the sensor in the SAMPLE state may need to be scheduled regularly. Since both the sample and the send operation may take varying amounts of time, the program needs to adjust the dwell period in the IDLE phase. ✷ Start INIT SAMPLE SEND init_done sample_done (n)ack IDLE timeout Figure 4.1: A simple version of Surge with four program phases. In this version a failure while sending the data sample is ignored. Though this program is rather simple, it has many features of the complex algorithms used in current sensor-node programs. Sequential Composition The four phases of the Surge program are all scheduled strictly sequentially. From our analysis of sensor-node programs we conclude that typically the majority of logical operations (i.e., phases) are performed sequentially (though there is a certain amount of concurrency, as we will discuss in Sect. 4.2.3). Whenever the application at hand permits, architects of sensor-node programs seem to be inclined to schedule these phases sequentially rather then concurrently. This holds true even for many fundamental system services, such as network management, routing, device management, etc. This is in contrast to traditional networks, where most of such services are performed permanently in the background, often by dedicated programs or even on dedicated hardware.
4.2. The Anatomy of Sensor-Node Programs 71 We think that the composition of sensor-node programs predominantly into distinct, sequential phases has two main reasons: Firstly, sequential programs are typically easier to master than concurrent programs, as they require little explicit synchronization. And secondly, and even more importantly, the phases of a sequential program do not require coordination of resources and can thus utilize the node’s limited resources to the full, rather than having to share (and synchronize) between concurrent program parts. One difficulty of distinct, sequential program phases in the event-driven model lies in the specification and the memory efficient storage of variables used only within a phase. As we discussed earlier, such temporary variables must typically be stored as global variables, with global scopes and lifetimes. From the program code it is not clearly recognizable when a phase ends and thus the variables’ memory can be reused. Starting and Completing Phases In sensor-network programs a phase often ends with the occurrence of a particular event, which then also starts the next phase. Often this event is an indication that a previously triggered operation has completed, such as a timeout event triggered by a timer set previously, an acknowledgment for a network message, or the result of a sensing operation. So it can often be anticipated that a particular event will occur, is often hard or impossible to predict when. A phase may also end simply because its computation has terminated, like the INIT phase in the previous example. Then the next operation starts immediately after the computation. It may still be useful to view both phases as distinct entities, particularly if one of them can be (re-)entered along a different event path, as in the above example. The specification of phase transitions in the event-driven programming model poses the aforementioned modularity issue. Since the transition is typically triggered by a single event, both the initialization and deinitialization functions need to be performed within the single associated event handler. Therefore, modifications to the program’s phase structure causes modifications to all event handlers that lead in and out of added and removed phases. Also, phase transitions incur manual state management if different phases are triggered by the same event. Then the associated event handler must be able to determine which phase’s initialization to perform. This can only be done by manually keeping the current program state in a variable and checking the previous state at the beginning of each action. Repeated Rounds of Phases Often phases of sensor-node programs are structured in repeated rounds. A typical example is the cyclic “sample, send and sleep” pattern found in our example application, as well as in many sensor-node programs described in the literature. Examples where repeated rounds of distinct, sequentially scheduled program phases are used are LEACH [55, 56], TinyDB and TAG [83, 84], and many more.
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: 20 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:
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

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?