A State-Based Programming Model for Wireless Sensor Networks

More documents

Recommendations

Info

34 Chapter 3. Programming and Runtime Environments work failures. However, immanent bugs in the nodes’ system software may lead to system crashes that may render an entire WSN useless. Particularly if many or all nodes of the network run identical software or if cluster heads are affected, the network may not recover. Programming frameworks for sensor nodes should support application designers in the specification of reliable and, if possible, verifiable programs. Some of the standard programming mechanisms, like dynamic memory management and multi-threading, are known to be hard to handle and error prone. Therefore some programming frameworks deliberately choose not to offer these services to the application programmer. 3.1.3 Reactivity The main application of WSNs is monitoring the real world. Therefore sensor nodes need to be able to detect events in the physical environment and to react to them appropriately. Also, due to the tight collaboration of the multiple nodes of a WSN, nodes need to react to network messages from other nodes. Finally, sensor nodes need to be able to react to a variety of internal events, such as timeouts from the real-time clock, interrupts generated by sensors, or low battery indications. In many respects sensor nodes are reactive systems. Reactive systems are computer systems that are mainly driven by events. Their progress as a computer system depends on external and internal events, which may occur unpredictably and unexpectedly at any time, in almost any order, and at any rate. Indeed, the philosophy of sensor-node programming frameworks mandates that computations are only performed in reaction to events and that the node remains in sleep mode otherwise in order to conserve power. On the occurrence of events, wireless sensor nodes react by performing computations or by sending back stimuli, for example, through actuators or by sending radio messages. Sensor nodes need to be able to react to all events, no matter when and in which order they occur. Typically reactions to events must be prompt, that is, they must not be delayed arbitrarily. The reactions to events may also have real-time requirements. Since the handling of events is one of the main tasks of a sensor node, programming frameworks for sensor nodes should provide expressive abstractions for the specification of events and their reactions. 3.2 Programming Models Sensor nodes are reactive systems. Programs follow a seemingly simple pattern: they remain in sleep mode until some event occurs, on which they weak up to react by performing a short computation, only to return to sleep mode again. Three programming models have been proposed to support this pattern while meeting the requirements specified previously. These models are the event-driven model, the multi-threaded model, and the control-loop model. The event-driven model is based on the event-action paradigm, while the multithreaded model and the control loop are based on polling for events (in a block-
3.2. Programming Models 35 ing and non-blocking fashion, respectively). 3.2.1 Overview In the control-loop model there is only a single flow of control, namely the control loop. In this loop, application programmers must repeatedly poll for the events that they are interested in and handle them on their detection. Polling has to be non-bocking in order not to bring the entire program to a halt while waiting for a specific event to occur. Then, the computational reaction to an event must be short in order not to excessively delay the handling of next events. In the multi-threaded model, programmers also poll for events and handle them on detection. However, polling can be blocking since programs have several threads with individual flows of control. For the same reason the duration of a computational reaction is not bounded. When one thread is blocking or performing long computations, the operating system takes care of scheduling other threads concurrently, that is, by sharing the processor in time multiplex. In the event-driven model the system software remains the program’s control flow and only passes it shortly to applications to handle events. The system software is responsible to detect the occurrence of an event and then to “call back” a specific event-handling function in the application code. These functions are called actions (or event handlers). They are the basic elements of which applications are composed of. Only within these actions do applications have a sequential flow. The scheduling of actions, however, is dictated by the occurrence of events. These models differ significantly in their expressiveness, that is, the support they provide to a programmer. They also require different levels of support from the runtime environment and thus the amount of system resources that are allocated for the system software. In the following we will analyze these three models regarding their expressiveness and inherent resource consumption. 3.2.2 The Control Loop Some sensor-node platforms (such as the Embedded Wireless Module nodes described in [97] and early versions of Smart-Its nodes [124]) provide programming support only as a thin software layer of drivers between the hardware and the application code. Particularly, these systems typically do not provide a programming abstraction for event-handling or concurrency, such as actions or threads. Rather they only provide a single flow of control. In order to guarantee that a single-threaded program can handle and remains reactive to all events, the program must not block to wait for any single event. Instead, programmers typically poll for the occurrence of events in a non-blocking fashion. Among experienced programmers it is an established programming pattern to group all polling operations in a single loop, the socalled control loop. (In this respect the control-loop model is much more a programming pattern or approach for sensor nodes–or, more generally, for reactive systems–rather than a programming model with explicitly supported abstractions.) The control loop is an endless loop, which continuously polls for the occurrence of events in a non-blocking fashion. If the occurrence of an event
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 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 96 and 97:
Page 98 and 99:
Page 100 and 101:
Page 102 and 103:
Page 104 and 105:
Page 106 and 107:
Page 108 and 109:
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 118 and 119:
Page 120 and 121:
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

Create successful ePaper yourself

Delete template?

Save as template?