A State-Based Programming Model for Wireless Sensor Networks

More documents

Recommendations

Info

32 Chapter 3. Programming and Runtime Environments Programming Framework Programming Tools Programming Model Programming Languages Runtime Environment System Software − Middleware − Libraries − Operating System Kernel Hardware Compiler, Linker, Debugger Language abstractions C, C++, nesC OS and data abstractions RPC, EnviroTrack, TinyDB libC, Berkeley sockets Linux, TinyOS PCs, BTnodes Figure 3.1: Programming frameworks for sensor nodes consist of reusable code and software components, programming languages, software tools to create and debug executable programs. platforms must make an a priori decision which models, abstractions, and system services to support. They are faced with the dilemma to provide an expressive enough programming model without imposing too heavy a burden on the scarce system resources. Resources spent for the system software are no longer available to application programmers. In this chapter we will review state-of-the-art programming models and the programming abstractions supported in current system software for sensor nodes. We start by presenting basic requirements that must be met by the system software and application programs alike in Sect. 3.1. Then, in Sect. 3.2, we present the three basic programming models that have been proposed for sensor-node programming, that is, the event-driven model, the multi-threaded model, and the control loop. We continue our discussion with Sections 3.3 and 3.4 on dynamic memory management and on process models, respectively. Based on our initial requirements (from Sect. 3.1) we analyze these programming models and abstractions with respect to the runtime support they necessitate. Finally, in Sect. 3.4, we summarize state-of-the-art programming frameworks (most of which we have introduced in the previous sections already in order to highlight certain aspects) and present in greater detail two programming frameworks, which represent variations of the basic event-driven model. 3.1 System Requirements In the last chapter we have discussed the unique characteristics of sensor networks. These characteristics result in a unique combination of constraints and requirements that significantly influence the software running on sensor nodes. But this influence is not limited to the choice of application algorithms and data structures. The nodes’ system software, that is, the operating system and other
3.1. System Requirements 33 software to support the operation of the sensor node, is affected as well. In this section we present three main requirements of WSN software. While this is not a comprehensive list of topics, it does identify the most important topics with regard to sensor-node programming. 3.1.1 Resource Efficiency A crucial requirement for all WSN programs is the efficient utilization of the available resources, for example, energy, computing power, and data storage. Since all sensor nodes are untethered by definition, they typically rely on the finite energy reserves from a battery. This energy reserve is the limiting factor of the lifetime of a sensor node. Also, many sensor-node designs are severely constrained in fundamental computing resources, such as data memory and processor speeds. Sensor nodes typically lack some of the system resources typically found in traditional computing systems, such as secondary storage or arithmetic co-processors. This is particularly the case for nodes used in applications that require mass deployments of unobtrusive sensor nodes, as these applications prompt small and low-cost sensor-node designs. In addition to energy-aware hardware design, the node’s system software must use the available memory efficiently and must avoid CPU-cycle intense operations, such as copying large amounts of memory or using floating-point arithmetic. Various software-design principles to save energy have been proposed [41]. On the algorithmic level, localized algorithms are distributed algorithms that achieve a global goal by communicating with nodes in a close neighborhood only. Such algorithms can conserve energy by reducing the number and range of radio messages sent. Adaptive fidelity algorithms allow to trade the quality of the sensing result against resource usage. For example, energy can be saved by reducing the sampling rate of a sensor and therefore increasing the periods where it can be switched off. Resource constraints clearly limit the tasks that can be performed on a node. For example, the computing and memory resources of sensor nodes are often too limited to perform typical signal processing tasks like FFT and signal correlation. Hence, clustered architectures were suggested (e.g., [117]), where the clusterheads are equipped with more computing and memory resources leading to heterogeneous sensor networks. Resource constraints also greatly affect operating system and language features for sensor nodes. The lack of secondary storage systems precludes virtualmemory architectures. Also, instead of deploying strictly layered software architectures, designers of system software often choose cross-layer designs to optimize resource efficiency. Programming frameworks for sensor nodes should support application designers to specify resource efficient and power-aware programs. 3.1.2 Reliability Wireless sensor networks are typically deployed in remote locations. As software failures are expensive or impossible to fix, high reliability is critical. Therefore, algorithms have been proposed that are tolerant to single node and net-
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 44 and 45: 34 Chapter 3. Programming and Runti
Page 72 and 73: 62 Chapter 4. Event-driven Programm
Page 92 and 93:
82 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

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

Delete template?

Save as template?