A State-Based Programming Model for Wireless Sensor Networks

More documents

Recommendations

Info

126 Chapter 7. State-based Programming in Practice EnviroTrack Group management Size in Lines of Code Size Reduction NesC OSM with OSM Flow control (state management) 187 (44%) 56 (19%) 70% Program logic 239 (56%) 239 (81%) n/a Total 426 (100%) 295 (100%) 31% Table 7.1: Comparison of program sizes for the implementation of EnviroTrack’s group-management protocol in NesC and OSM. to explicitly specify the program’s control flow, the remaining 5 lines implement the actual program logic. On the other hand, an equivalent program in OSM requires only 56 lines of code, that is, less than one third of the original NesC code size. In OSM, the fraction of code for managing the control flow (56 lines) against the entire program (56+239=295 lines) is down to less then 20%. That is, there is only a single line of code required to express the programs control flow to every 4 lines of program logic (which is implemented in separate files). The results of this comparison are summarized in Tab. 7.1. Note that in NesC programs the implementation of the actual program logic does not use any NesC-specific features; just like in OSM the actual program code is specified using plain C statements and is thus identical in both programming frameworks. In this section we have looked at manual state management in general. In the next section we look at special patterns of manual state management that regularly appear in typical sensor-node programs, namely state-based resource initialization and avoiding accidental concurrency. 7.2.3 Resource Initialization in Context In our analysis of sensor-node programs in Sect. 4.2 we stated that the computations within a program state often utilize a well defined set of resources. Typically these resources are allocated as well as initialized when entering the program state, and released again when leaving the state. To efficiently specify this resource allocation and release, OSM offers incoming and outgoing actions (respectively). Typical examples in sensor networks are the state-based initialization and use of hardware resources, such as sensors and emitters, but also transceivers, external memories, timers, and so on. A special case of a statebound resource is memory that is only used in the context of a state, that is, state variables. We will discuss how state variables are used in practice in Sect. 7.3. As resource initialization and release are bound to state changes, these operations are closely connected to state management. In the following we will show how the state-based approach of OSM helps improving the code structure with regard to resource initialization. To do so, we will again use the EnviroTrack example. Resource Initialization in EnviroTrack In our EnviroTrack example, all states (except FREE) use a timer. The timers in the EnviroTrack group-management protocol always trigger actions specific to
7.2. Modular and Well-Structured Program Design 127 the current state. These actions are either state changes or recurring computational actions within the current state. Therefore, we like to think that conceptually every state uses an individual timer, though both the original NesC and the OSM implementations only use a single hardware timer for all states. The individual timers are always initialized in transitions, either when entering a new state through a transition, or after triggering a recurring action within the current state, that is, in a self transition. Table 7.2 lists the values that are used to initialize the timer in the EnviroTrack example based on the transition parameters, namely the target and source states as well as the trigger event. Using this example, we will now explain how state-bound resources are initialized in both the event-driven and the state-based programming models and then compare both approaches. Target State Source State Trigger Line No. Timeout Value NesC OSM NEW_CANDIDATE LEADER_CANDIDATE FOLLOWER MEMBER LEADER RESIGNING_LEADER FREE join 154 27 wait_random() NEW_CANDIDATE timeout[else] 106 29 wait_recruit() NEW_CANDIDATE timeout[...] 111 36 MEMBER timeout 100 36 MEMBER resign[...] 269 36 FREE recruit OR resign 248 12 LEADER_CANDIDATE leave[else] 200 12 FOLLOWER recruit OR resign 256 12 MEMBER leave 186 12 RESIGNING_LEADER recruit OR candidate 337 12 NEW_CANDIDATE recruit 279 19 NEW_CANDIDATE candidat[...] 284 19 LEADER_CANDIDATE recruit[...] 295 19 LEADER_CANDIDATE candidate[...] 300 19 FOLLOWER join 161 19 MEMBER recruit 264 19 LEADER recruit[...] 313 19 wait_random() wait_threshold() wait_receive() LEADER_CANDIDATE timeout 120 45 wait_random() RESIGNING_LEADER join 169 46 wait_recruit() LEADER timeout 126 47 — ” — LEADER recruit[else] 317 47 — ” — LEADER resign OR candidate 325 47 — ” — RESIGNING_LEADER timeout[...] 135 56 wait_recruit() LEADER leave 209 56 Table 7.2: Timeouts in the EnviroTrack group-management protocol are initialized as part of transitions and predominantly depend on the target state only. The source states and triggers of self transitions are set in italics. Line numbers refer to the source code given in Appendices B.1 and B.2 (for the NesC and OSM version, respectively). The actual timeout value is expressed as the return value of a function. Original NesC Implementation In the NesC implementation of the EnviroTrack group-management protocol, a single timer is used to implement timeouts in all states using a count-down approach. The timer is switched on when the program starts and is never switched off. It fires at a regular interval that never changes. The corresponding timeout
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:
Page 34 and 35:
Page 36 and 37:
Page 38 and 39:
Page 40 and 41:
Page 42 and 43:
32 Chapter 3. Programming and Runti
Page 44 and 45:
Page 46 and 47:
Page 48 and 49:
Page 50 and 51:
Page 52 and 53:
Page 54 and 55:
Page 56 and 57:
Page 58 and 59:
Page 60 and 61:
Page 62 and 63:
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: 76 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 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 168 and 169: 158 Appendix A. OSM Code Generation
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?