A State-Based Programming Model for Wireless Sensor Networks

More documents

Recommendations

Info

2 Chapter 1. Introduction This makes the multi-threaded model generally less suitable for programming sensor nodes, which are typically limited in resources, and unsuitable for sensor nodes operating at the low end of the resource spectrum (cf. [37, 59]). As a consequence, in the context of sensor networks, event-based systems are very popular with several programming frameworks in existence. These frameworks, particularly TinyOS and nesC, are supported by a large user base. Hence, many sensor-node programmers find it natural to structure their programs according to this paradigm. 1.2 Motivation and Problem Statement While event-driven programming is both simple and efficient, we have found that it suffers from a very important limitation: it lacks an abstraction of state. Very often, the behavior of a sensor-node program not only depends on a particular event—as the event model suggests—but also on the event history and on computational results of previous actions; in other words: program state. We use an example to illustrate this point. In the EnviroTrack [6] middleware for tracking mobile objects with wireless sensor networks, nodes collaboratively track a mobile target by forming a group of spatially co-located nodes around the target. If a node initially detects a target, its reaction to this target-detection event depends on previous events: If the node has previously received a notification (i.e., an event) that a nearby node is already a member in a tracking group, then the node joins that group. If the node has not received such a notification, it forms a new group. In this example, the behavior of a node in reaction to the target-detection event (i.e., creating a new tracking group or joining an existing one) depends on both the detection event itself and the node’s current state (i.e., whether a group has already been formed in the vicinity of the node or not). Since there is no dedicated abstraction to model program state in the eventdriven model, programmers typically save the program state in variables. However, keeping state in variables has two important implications that obscure the structure of program code, severely hamper its modularity, and lead to issues with resource efficiency and correctness. Firstly, to share state across multiple actions, the state-keeping variables must persist over the duration of all those actions. Automatic (i.e., local) variables of procedural programming languages do not meet this requirement, since variable lifetime is bound to functions. Thus the local variable stack is unrolled after the execution of the function that implements an action. Instead, programmers have the choice to use either global variables or to manually store a state structure on the heap. The latter approach is often inapplicable as it requires dynamic memory management, which is rarely found in memory-constrained embedded systems because it is considered error-prone and because it incurs significant memory overhead. The former and by far more typical approach, however, also incurs significant memory overhead. Since global variables also have “global” lifetime, this approach permanently locks up memory—even if the state is used only temporarily, for example, during network initialization. As a result, manual state-keeping makes eventdriven programs memory inefficient since they cannot easily reuse memory for temporary data. This is ironic, since one of the main reasons for introducing the
1.3. Thesis Statement 3 event-driven model has been that its support in the underlying system software can be implementred resource efficiently. Secondly, the association of events to actions is static—there is no explicit support for adopting this association depending on the program state. As a consequence, in actions, programmers must manually dispatch the control flow to the appropriate function based on the current state. The additional code for state management and state-based function demultiplexing can obscure the logical structure of the application and is an additional source of error. Also, it hampers modularity since even minor changes in the state space of a program may require modifying multiple actions and may thus affect much of the program’s code base. While the identified issues are not particularly troublesome in relatively small programs, such as application prototypes and test cases, they pose significant problems in larger programs. But as the field of wireless sensor networks matures, its applications are getting more complex—projects grow and so does the code base and the number of programmers involved. Leaving these issues unsolved may severely hamper the field of wireless sensor networks to mature. 1.3 Thesis Statement Because of the limitations outlined in the previous section, we argue that the simple event/action-abstraction of the event-driven programming model is inadequate for large or complex sensor network programs. The natural question then is, can the inadequacies of the event-driven programming model be repaired without impairing its positive aspects? In this dissertation we answer this question affirmatively. Concretely, we present the Object State Model (OSM), a programming model that extends the event-driven programming paradigm with an explicit abstraction and notion of hierarchical and concurrent program states. Our thesis is that such a state-based model allows to specify well-structured, modular, and memory-efficient sensor-node programs, yet requires as little runtimeresources as the event-driven model. 1.4 Contributions The main contribution of this work then is to show • that OSM provides adequate abstractions for the specification of well structured and highly modular programs, • how OSM supports memory-efficient programming, and, finally, • that OSM does not incur significant overhead in the underlying system software and can thus indeed be implemented on resource-constrained sensor nodes. In this dissertation we present four elements to support our claim: (1) OSM, an abstract, state-based programming model, which is a state-extension to the conventional event-based programming model, (2) an implementation language
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 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 62 and 63:
52 Chapter 3. Programming and Runti
Page 64 and 65:
Page 66 and 67:
Page 68 and 69:
Page 70 and 71:
Page 72 and 73:
62 Chapter 4. Event-driven Programm
Page 74 and 75:
Page 76 and 77:
Page 78 and 79:
Page 80 and 81:
Page 82 and 83:
Page 84 and 85:
Page 86 and 87:
Page 88 and 89:
Page 90 and 91:
Page 92 and 93:
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?