High-Level Application Development is Realistic for Wireless Sensor Networks

Abstract

Abstract-Programming Wireless Sensor Network (WSN) applications is known to be a difficult task. Part of the problem is that the resource limitations of typical WSN nodes force programmers to use relatively low-level techniques to deal with the logical concurrency and asynchronous event handling inherent in these applications. In addition, existing general-purpose, nodelevel programming tools only support the networked nature of WSN applications in a limited way and result in application code that is hardly portable across different software platforms. All of this makes programming a single device a tedious and error-prone task.To address these issues we propose a high-level programming model that allows programmers to express applications as hierarchical state machines and to handle events and application concurrency in a way similar to imperative synchronous languages. Our program execution model is based on static scheduling what allows for standalone application analysis and testing. For deployment, the resulting programs are translated into efficient sequential C code. A prototype compiler for TinyOS has been implemented and its evaluation in described in this paper.

Safe system-level concurrency on resource-constrained nodes

“…Request permissions from Permissions@acm.org. SenSys '13, November 11-15, 2013 Synchronous languages [2] have also been adapted to WSNs and offer higher-level compositions of activities with a stepby-step execution, considerably reducing programming efforts [21,22].…”

“…Sharedmemory concurrency is an example of a widely adopted mechanism that typically relies on runtime safety primitives only. For instance, current WSN languages ensure atomic memory access either through runtime barriers, such as mutexes and locks [7,27], or by adopting cooperative scheduling which also requires explicit yield points in the code [21,12]. In either case, there are no additional static guarantees or warnings about unsafe memory accesses.…”

FlowTalk: Language Support for Long-Latency Operations in Embedded Devices

“…For example, taking the scenario example given in Figure 1, it will be perfectly legitimate to perform the two sensors samplings at the same times since the light and magnetism sensors are two different physical components on the motherboard. This is a behavior that may be programmed in nesC and is supported by TinyOS [22].…”

Using Sensor Networks for Pedestrian Detection

“…To implement the pedestrian detection system, we used SOL, a programming language for wireless sensor/actuator networks that raises the level of abstraction of TinyOS and thus makes sensor/actuator network applications easier to program, while maintaining good performance [10]. The NesC code [24] produced by the SOL compiler is fully functional and can be compiled immediately with the NesC compiler and deployed on the motes.…”

“…We describe how such a pedestrian detection system was successfully built using SOL [10], a high-level programming language for wireless sensor/actuator networks that allows programmers to use a fine-grained concurrency model and enables a clear boundary definition between application code and the underlying platform.…”