A State-Based Programming Model for Wireless Sensor Networks

More documents

Recommendations

Info

50 Chapter 3. Programming and Runtime Environments Particularly the memory subsystem poses serious threads to concurrent programming. Sensor nodes do not provide virtual memory and therefore applications have to make do with the limited physical memory provided on a node. We expect that most non-trivial sensor-node programs occupy most of the systems’ physical memory. It is generally hard to reach a good estimate of even a single program’s memory requirements, particularly with dynamic memory allocation. Multiple competing programs certainly increase the uncertainty of such estimates. If processes require more than the available memory, system crashes or undefined behavior may result. As a consequence, the affected node or even an entire network region connected through that node may be unusable. In sensor networks, concurrency on the process level does not play the same role as in general-purpose systems. Its purpose in traditional operating systems to increase processor utilization is contradictory to the design philosophy of sensor networks. In fact, as we pointed out earlier, most program architectures strive to maximize idle times in order to save power. Also, it is not expected that sensor nodes are used by multiple users to the same degree as traditional computing systems. Though process concurrency may be a useful feature for sensor-network operators and users, we suggest its implementation only in sensor-node design with appropriate protection mechanism and resource provisions. In constrained nodes, however, the are severe reliability issues, which make its support prohibitive. 3.5 Overview and Examples of State-of-the-Art Operating Systems In the previous sections we have discussed the principle programming and process models, as well as dynamic memory-management support of current sensor-node operating systems. The discussion represents the state-of-the-art of sensor-node programming and is based on current literature. The discussion focuses on resource-constrained sensor node platforms. Before presenting two concrete examples of event-driven operating systems in greater detail, we will first summarize the previously discussed state-of-the-art sensor-node operating systems in Tab. 3.1. For each of the eight discussed operating systems, the table lists the system’s programming language, the process and programming model, and the target-device features. The concurrency column under the heading process model denotes if the OS supports running multiple processes concurrently. The dynamic loading column under the same heading denotes if new processes can be loaded and started at runtime without also having to reload and restart the OS itself. Systems supporting dynamic loading of processes typically also support running multiple processes concurrently. The only exception is the Maté virtual machine, which supports dynamic loading of user applications but can only run one of them at a time. Actual operating systems often implement variations of the basic programming models and often differ significantly in the system services provided. We will now present two representatives of current event-based operating systems; our BTnode system software, and the system that is sometimes referred to as the
3.5. Overview and Examples of State-of-the-Art Operating Systems 51 Programming Framework Process Model Programming Model Target Device Operating System TinyOS [45] Maté VM [79] BTnode [21] BTnut [123] SOS [52] Contiki [37] Impala [81] MANTIS [8] Progr. Language Concurrency Dynamic Loading Scheduling Dyn. Mem. processor core, clock, RAM, ROM, secondary storage nesC no no events no Berkeley Motes 8-bit, 8 MHz, 4 Kb, 128 Kb, - Maté bytecode no yes events no Berkeley Motes 8-bit, 8 MHz, 4 Kb, 128 Kb, - C no no events no a BTnode (ver. 1 and 2) 8-bit, 8 MHz, 4 Kb, 128 Kb C no no threads b no a BTnode (ver. 3) 8-bit, 8 MHz, 64 Kb, 128 Kb, 192 Kb RAM C yes yes events yes c Berkeley Motes and others 8-bit, 8 MHz, 4 Kb, 128 Kb, - C yes yes events and threads d n/a n/a n/a prioritized events no a ESB node [47] 16-bit, 1 MHz, 2 Kb, 60 Kb, - yes c ZebraNet node 16-bit, 8 Mhz, 2 Kb, 60 Kb, 512 Kb Flash RAM C yes yes threads d no Mantis node 8-bit, 8 MHz, 4 Kb, 128 Kb, - a Dynamic memory allocation is provided by the standard C library libc for Atmel microcontrollers but is neither used in the OS implementation nor recommended for application programming. b Cooperative multi-threading. c Fixed (i.e., predefined) block sizes only. d Preemptive multi-threading. Table 3.1: Current programming frameworks for resource-constrained sensor nodes. The frameworks’ runtime environment (as provided by the system software) supports different process models and programming models as discussed in sections 3.2 and 3.4. (n/a: feature not specified in the available literature.) de facto standard of sensor-node operating systems, TinyOS. We will discuss their features and their deviations to the basic model in more detail. 3.5.1 The BTnode System Software The BTnode system software (see Fig. 3.3) is a lightweight OS written in C and assembly language that has been initially developed for the first version of the BTnode. The system provides an event-based programming model. It does not provide dynamic loading of processes and has a non-concurrent process model. Though dynamic memory allocation is available, the system software is only using static memory allocation to avoid reliability issues. Application programmers are also strongly discouraged to used dynamic memory allocation. The drivers, which are available for many hardware subsystems and extensions (e.g, the Bluetooth radio and several sensors subsystems), provide convenient, event-driven APIs for application development. The BTnode system is composed of four principal components (see Fig. 3.3): the sensor-node hardware, the drivers, the dispatcher, and an application (which
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 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

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

Delete template?

Save as template?